Nur aktive Personen per LDAP auslesen
Um bei einer LDAP Abfrage Richtung Active Directory (AD) nur die Aktiven User als Ergebnis zu bekommen, kann als LDAP Suchstring (Serarchstring bei englischer DIALit Oberfläche oder DataPump ) ein Teil des Attribut userAccountControl als Filter verwendet werden.
Beispiel Suchstring (Searchstring) für Alle Personen die nicht deaktiviert sind: WHERE objectCategory = ‚person‘ and not ‚userAccountControl:1.2.840.113556.1.4.803:’=’2‘
Unterstützen DIALit, JServer und DataPump Secure LDAP?
Mit einem Windows Server Update, das im Jahr 2020 für alle unterstützen Versionen von Windows Server erscheinen wird, leitet Microsoft das Ende von unverschlüsselten LDAP-Verbindungen ein.
DIALit ab Version 4.4 und DataPump ab Version 4.4 sind dahingehend geprüft und freigegeben. Diese verwenden auf aktuellen Windows Betriebssystemen bereits die verschlüsselte LDAP Kommunikation.
DIALit und DataPump 4.4:
Man muss bzw. darf keine Änderungen in der Konfiguration vornehmen (den LDAP Pfad nicht auf LDAPS:// ändern und Port nicht ändern bzw. explizit angeben).
JServer :
(Betrifft Connectoren für Avaya und Unify Anlagen die LDAP Abfragen verwenden)
Ab JServer 4.4.1.2 ist „Secure“ einschaltbar. Dokumentiert ist die Konfiguration in jserver_de.pdf welches im entsprechenden Setup-Kit enthalten ist.
Kann man im MOC/Lync Skype for Business Adapter die LDAP Suchbasis, Suchfeld und Suchstring anpassen?
Ja, das geht ab Version 4.3.0.7
Als Suchbasis wird zunächst nichts spezielles verwendet. Es wird versucht über die Windows Anmeldung einen AD Zugriff zu erhalten der die Auflösung der SIP Adresse ermöglicht. Gelingt dies nicht, wird die LDAP Suchbasis (ggf. User und Passwort) aus der DIALit Konfiguration verwendet. Übersteuern kann man dies, indem man manuell diesen Registry Eintrag erzeugt:
hkcu\software\cti\dialit\ldap\moc_suchbasis (als Zeichen) Wert Bsp: LDAP:192.168.2.161:389/DC=compyny,DC=local
Gesucht wird standardmäßig in dem AD Feld msRTCSIP-PrimaryUserAddress. Übersteueren kann man dies, indem man folgenden Registry Eintrag erzeugt:
hkcu\software\cti\dialit\ldap\moc_suchfeld (als Zeichen) Wert Bsp: SipAddresses
Die Reihenfolge der ausgegebenen Telefonnummern ist vorgegeben: pager,otherhomephone,homephone,othermobile,mobile,othertelephone,telephonenumber in umgekehrter Reihenfolge. Übersteueren kann man dies, indem man folgenden Registry Eintrag erzeugt:
hkcu\software\cti\dialit\ldap\moc_suchstring (als Zeichen) Wert Bsp: telephonenumber,homephone (nur Geschäft und Home werden ausgegeben)
Der LDAP Zugriff im OOFJService zum Holen der Aliase klappt nicht.
OOFJService ist der OutOfOffice und Calendar Connector für Exchange und Domino.
Da OOFJService als Dienst läuft kann er sich nicht wie ein angemeldeter User anonym an einem ADS anmelden.
Daher muss bei der Schreibweise der LDAP Searchbase der Server und Port mit angegeben werden:
LDAP://Server:389/ou=dings,ou=da
Außerdem wird ein Benutzer vermutlich mit Passwort erwartet.
Die Schreibweise des Benutzers ist entweder domain\benutzer oder user@domain
Wie muss eine LDAP Abfrage geschrieben sein, wenn nur Datensätze angezeigt werden sollen bei denen ein bestimmtes Attribut leer ist?
WHERE objectCategory = ‚person‘ and not extensionAttribute14=’*‘
Die LDAP Anbindung funktioniert nicht.
Testen Sie den Zugang zu dem Directory zuerst ohne die Anrufersuche im Cache-Betrieb, also direkt in der Registerkarte durch Suchen eines Namens. Damit ist es einfacher die richtigen Parameter zu ermitteln. Anschließend kann ggf. der Cache Betrieb aktiviert werden.
Wenn Sie eine Suchabfrage ausführen erscheint ggf. unten in der Statuszeile eine Fehlermeldung.
LDAP Query failed:
Unbekannter Fehler – Vermutlich haben Sie ein Feldattribut benutzt das es nicht gibt oder nicht bei allen Datensätzen gibt. Reduzieren Sie auf ein Feld und fügen dann weiter hinzu bis das fehlerverursachende Feld herausgefunden wurde. Verwenden Sie auch einen LDAP-Browser um das nachzuprüfen.
Tabelle nicht vorhanden – Die LDAP Suchbasis stimmt nicht. Mit LDAP Browser überprüfen. Achtung LDAP Groß schreiben!
Zugriff verweigert – Benutzer oder Passwort stimmen nicht.
Ändern Sie nach und nach Teile der Konfiguration um zu sehen, ob sich die Meldungen ändern, um dann Schritt für Schritt zum Ziel zu kommen.
Worauf muss man bei der Anbindung eines Estos Metadirectoy per LDAP achten?
Ein estos Metadirectory wird wie jedes andere LDAP-Directory auch angebunden. Es gibt jedoch Besonderheiten, auf die man achten muss:
1. estos verwendet u.U. einen anderen LDAP Port als 389. Stattdessen wir 712 verwendet. Um diesen zu nutzen, wird der LDAP-Server im Format LDAP://<Servername> oder <IP Adresse>:712/DC=meta angegeben.
2. Im LDAP-Suchstring verwendet man WHERE objectClass = ‚*‘
3. Im Feld „Name (Suchstring)“ darf man nicht das Feld „displayName“ verwenden. Stattdessen kann z.B. das Feld „sn“ oder „cn“ verwendet werden. Ansonsten bekommt man bei der Suche einen unbekannten Fehler. Sollten weitere unbekannte Fehler kommen, deaktivieren Sie Felder wie telephonecar usw. bis das/die fehlerverursachende/n Feld/er gefunden wurden. Sollte auch mit sn und/oder cn ein Fehler auftreten, versuchen Sie zunächst andere Attribute wie givenname oder lastname. Warum speziell estos Attribute Fehler verursachen ist noch nicht abschließend geklärt.
Bei LDAP Cache in einer NDS bekommen wir doppelte Datensätze.
Aktivieren Sie in DIALit die Option "Import Blockweise nach Alphabet…"
Kann man einen OpenLDAP Server anbinden?
Ja, das geht. Mit einem LDAP Browser (aus unserem Downloadbereich) die Struktur und Feldnamen rausfinden, und unter LDAP entsprechend in DIALit eintragen. Bei großen Verzeichnissen den Haken „blockweises Holen“ aktiivieren (in DIALit).
Achten Sie auf Groß-Kleinschreibung bei der Suchbasis. Auch LDAP:// muss groß geschrieben werden!
Warum geht der LDAP Zugriff bei openLDAP nicht?
Achten Sie bei der Eingabe der Suchbasis auf Groß/Kleinschreibung, so muss z.B. auch LDAP:// groß geschrieben sein.