ek-soft FAQ
LDAP
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‘
Letzte Änderung am: 23.06.2021, 15:46 Uhr
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.
Letzte Änderung am: 04.05.2020, 10:00 Uhr
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.
Letzte Änderung am: 19.01.2016, 15:15 Uhr
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)
Letzte Änderung am: 19.01.2016, 11:10 Uhr
Hier ein Beispiel für Suse Linux OpenExchange 4.1.
Der Eintrag bei User muß so lauten wie beschrieben, wobei „mast“ der eigentliche Username ist. Wenn man nur „mast“ einträgt funktioniert es nicht.
Letzte Änderung am: 11.10.2014, 10:34 Uhr
Die Anrufersuche sollte auch im Nativmode gehen, sofern die Rufnummern in Ihrem LDAP-Verzeichnis bereinigt vorliegen, also z.B. „0711123123“. Was noch geht ist einen Prefix zu verwenden (konfigurierbar) z.B. wenn alle Nr. im LDAP-Verzeichnis mit „+49(711)123-xxx“ eingetragen sind, dann kann man als Prefix „+49(711)123-“ eintragen, wenn ein interner Anruf kommt, dann wird immer der Prefix davor gehängt und der Anrufer wird gefunden. Sollte das alle nicht gehen, probieren Sie bitte ein aktuelle Version mind. 3.3.0.7 aus.
Als Prefix kann auch ein * verwendet verden. Das ist als Wildcard zu sehen, die Suche ist dann allerdings langsamer.
Letzte Änderung am: 11.10.2014, 10:34 Uhr
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!
Letzte Änderung am: 11.10.2014, 10:34 Uhr
Achten Sie bei der Eingabe der Suchbasis auf Groß/Kleinschreibung, so muss z.B. auch LDAP:// groß geschrieben sein.
Letzte Änderung am: 11.10.2014, 10:34 Uhr
Aktivieren Sie in DIALit die Option "Import Blockweise nach Alphabet…"
Letzte Änderung am: 11.10.2014, 10:34 Uhr
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.
Letzte Änderung am: 11.10.2014, 10:34 Uhr
WHERE objectCategory = ‚person‘ and not extensionAttribute14=’*‘
Letzte Änderung am: 11.10.2014, 10:34 Uhr
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
Letzte Änderung am: 11.10.2014, 10:34 Uhr