6
Cisco UCM und LDAP-Authentifizierung
Hi,
diese Frage wird jetzt länger. Ich versuche das möglichst zu strukturieren.
Mein Hoffnung ist, dass jemand von Euch die u.g. konkrete Situation kennt und mir da Tipps geben kann, oder dass mir jemand von Euch bzgl. der von mir u.g. Alternative helfen kann.
Oder, falls ich den Wald vor lauter Bäumen nicht sehen sollte, gerne auch mit der Axt.
Wir haben mit einem Cisco Unified Communications Manager (CUCM) von jetzt auf gleich Problem mit der Authentifizierung über LDAP. Seit gestern früh. Der Kollege macht es sich leicht und schiebt es auf den LDAP Server. An diesem wurde aber nichts geändert und es betrifft auch nicht alle Benutzer, welche über diesen authentifiziert werden.
Als LDAP für die Authentifizierung kommt ein LD DS ("ADAM") unter Win2016 zum Einsatz ("Proxy-LDAP"). Grund dafür ist, dass wir einen AD Forest mit mehreren Domänen haben und Benutzer aus mehreren dieser Domänen sich am CUCM anmelden können sollen. Die Konfiguration des CUCM lässt aber unter "LDAP Authentifizierung" nur eine "Searchbase" in der Konfiguration zu. Also einen DistinguishedName eines Containers, in welchem die zu authentifizierenden Benutzer gesucht werden.
Wir synchronisieren also die betreffenden Benutzer aus den verschiedenen Domänen dieses einen Forest in das LD DS. Dort werden sie als "userProxy"-Objekte angelegt.
Gemäß Anleitung: How to Configure Unified Communications Manager Directory Integration in a Multi-Forest Environment
Dieses Synchronisation funktioniert tadellos.
Der CUMC selbst synchronisiert die Benutzer direkt aus dem AD. An dieser Stelle kann man im CUCM mehrere Quellen (Domänen) angeben. Im LD DS landen die Benutzer aus den verschiedenen Domänen dann in einem Baum.
Auch das funktioniert tatdellos.
Die Authentifizierung von Benutzern aus einer dieser Domänem am CUCM funktioniert. (Direkt am Portal oder über Jabber.)
Die von Benutzern aus einer anderen dieser Domänen hingegen nicht. Seit gestern nicht mehr.
Proxy-LDAP und Domaincontroller dieser beiden Domänen befinden sich im selben Subnetz. Die LDAP-Ports (mit und ohne SSL) sind erreichbar. Alle betreffenden Server wurden auch schon einmal durchgestartet. Die letzten Änderungen an der Software (WSUS-Updates) sind >1 Woche her. Dazwischen hat alles noch funktioniert.
Im o.g. von mir verlinkten Artikel wird von "Multi-Forest" gesprochen. In anderen Foren (ich finde das leider nicht mehr) wurde genannt, dass es bei mehreren Domänen in nur einem Forest eigentlich nicht notwendig wäre, einen LDAP-Proxy dazwischenzuschalten, sondern dass man dann Benutzer aus allen Domänen dieses einen Forest über nur einen DC dieses Forest authentifizieren könne. Das konnten wir jedoch damals (bei der ursprünglichen Installation des CUCM) so nicht reproduzieren. Deshalb der Weg über den LDAP-Proxy.
Kennt jemand dieses Szenario und hat Tipps?
Alternative
Ich will jetzt beweisen, dass der LDAP-Proxy weiterhin funktioniert und die synchronisierten Benutzer aus den verschiedenen Domänen weiterhin über LDAP authentifizieren kann.
Könnt Ihr mir ein anderes System nennen, mit welchem ich das testen könnte? Ich schätze, dass müsste dann eines aus dem Linux-Umfeld sein, wovon ich aber keine Ahnung habe. Falls Linux, dann bräuchte ich eine "wasserdichte" Anleitung. Lesen kann ich selbst.
Irgend ein "fertiges Ding", was man dafür schnell aufziehen und damit die LDAP-Authentifizierung testen könnte.
Beim CUCM ist das so angeben:
Ich brauche also etwas, wo ich das analog angeben muss.
E.
diese Frage wird jetzt länger. Ich versuche das möglichst zu strukturieren.
Mein Hoffnung ist, dass jemand von Euch die u.g. konkrete Situation kennt und mir da Tipps geben kann, oder dass mir jemand von Euch bzgl. der von mir u.g. Alternative helfen kann.
Oder, falls ich den Wald vor lauter Bäumen nicht sehen sollte, gerne auch mit der Axt.
Wir haben mit einem Cisco Unified Communications Manager (CUCM) von jetzt auf gleich Problem mit der Authentifizierung über LDAP. Seit gestern früh. Der Kollege macht es sich leicht und schiebt es auf den LDAP Server. An diesem wurde aber nichts geändert und es betrifft auch nicht alle Benutzer, welche über diesen authentifiziert werden.
Als LDAP für die Authentifizierung kommt ein LD DS ("ADAM") unter Win2016 zum Einsatz ("Proxy-LDAP"). Grund dafür ist, dass wir einen AD Forest mit mehreren Domänen haben und Benutzer aus mehreren dieser Domänen sich am CUCM anmelden können sollen. Die Konfiguration des CUCM lässt aber unter "LDAP Authentifizierung" nur eine "Searchbase" in der Konfiguration zu. Also einen DistinguishedName eines Containers, in welchem die zu authentifizierenden Benutzer gesucht werden.
Wir synchronisieren also die betreffenden Benutzer aus den verschiedenen Domänen dieses einen Forest in das LD DS. Dort werden sie als "userProxy"-Objekte angelegt.
Gemäß Anleitung: How to Configure Unified Communications Manager Directory Integration in a Multi-Forest Environment
Dieses Synchronisation funktioniert tadellos.
Der CUMC selbst synchronisiert die Benutzer direkt aus dem AD. An dieser Stelle kann man im CUCM mehrere Quellen (Domänen) angeben. Im LD DS landen die Benutzer aus den verschiedenen Domänen dann in einem Baum.
Auch das funktioniert tatdellos.
Die Authentifizierung von Benutzern aus einer dieser Domänem am CUCM funktioniert. (Direkt am Portal oder über Jabber.)
Die von Benutzern aus einer anderen dieser Domänen hingegen nicht. Seit gestern nicht mehr.
Proxy-LDAP und Domaincontroller dieser beiden Domänen befinden sich im selben Subnetz. Die LDAP-Ports (mit und ohne SSL) sind erreichbar. Alle betreffenden Server wurden auch schon einmal durchgestartet. Die letzten Änderungen an der Software (WSUS-Updates) sind >1 Woche her. Dazwischen hat alles noch funktioniert.
Im o.g. von mir verlinkten Artikel wird von "Multi-Forest" gesprochen. In anderen Foren (ich finde das leider nicht mehr) wurde genannt, dass es bei mehreren Domänen in nur einem Forest eigentlich nicht notwendig wäre, einen LDAP-Proxy dazwischenzuschalten, sondern dass man dann Benutzer aus allen Domänen dieses einen Forest über nur einen DC dieses Forest authentifizieren könne. Das konnten wir jedoch damals (bei der ursprünglichen Installation des CUCM) so nicht reproduzieren. Deshalb der Weg über den LDAP-Proxy.
Kennt jemand dieses Szenario und hat Tipps?
Alternative
Ich will jetzt beweisen, dass der LDAP-Proxy weiterhin funktioniert und die synchronisierten Benutzer aus den verschiedenen Domänen weiterhin über LDAP authentifizieren kann.
Könnt Ihr mir ein anderes System nennen, mit welchem ich das testen könnte? Ich schätze, dass müsste dann eines aus dem Linux-Umfeld sein, wovon ich aber keine Ahnung habe. Falls Linux, dann bräuchte ich eine "wasserdichte" Anleitung. Lesen kann ich selbst.
Irgend ein "fertiges Ding", was man dafür schnell aufziehen und damit die LDAP-Authentifizierung testen könnte.
Beim CUCM ist das so angeben:
Ich brauche also etwas, wo ich das analog angeben muss.
E.
- CUCM
- Version 11.5.1.14900-11 (alt, ich weiß - kann laut Kollege nicht einfach so geändert werden)
- AD
- alle DC mit Windows Server 2016
- Forest Function Level: Win2016
- LDAP-Proxy
- Win2016
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 23409655063
Url: https://administrator.de/contentid/23409655063
Ausgedruckt am: 24.11.2024 um 15:11 Uhr
6 Kommentare
Neuester Kommentar
Moin,
Gruß,
Dani
Als LDAP für die Authentifizierung kommt ein LD DS ("ADAM") unter Win2016 zum Einsatz ("Proxy-LDAP").
Wie klein doch die Welt ist. Wir nutzen anstatt AD LDS eben OpenLDAP auf einem Linux.Kennt jemand dieses Szenario und hat Tipps?
Interessant wäre auf jeden Fall, woran sich der CUCM verschluckt. Sprich meint dieser dass die Zugangsdaten nicht korrekt sind (username or password false) oder wird das Objekt gar nicht gefunden (username unkown)?Ich will jetzt beweisen, dass der LDAP-Proxy weiterhin funktioniert und die synchronisierten Benutzer aus den verschiedenen Domänen weiterhin über LDAP authentifizieren kann.
Reicht dir dafür ein kostenloser LDAP Browser von Softerra? Alternativ müsst es unter Linux mit ldapsearch möglich sein.Gruß,
Dani
Hallo,
diverse Sicherheitslösungen haben eine LDAP Option. Z.B. ESET Management Server oder eine Fortigate. Vielleicht hast Du ja etwas passendes. Nachteil: gelegentlich nur rudimentäre Logs.
Wenn Du LADPs verwendest, ist der Export und Import des Serverzertifikats eigentlich das „schwerste“.
Grüße
lcer
diverse Sicherheitslösungen haben eine LDAP Option. Z.B. ESET Management Server oder eine Fortigate. Vielleicht hast Du ja etwas passendes. Nachteil: gelegentlich nur rudimentäre Logs.
Wenn Du LADPs verwendest, ist der Export und Import des Serverzertifikats eigentlich das „schwerste“.
Grüße
lcer
Hi,
Ist es klar getestet, dass der Zugriff nur aus einer der Domänen funktioniert und aus anderen nicht, oder gibt es gemischte Ergebnisse? Also Benutzer aus einer Domäne, die sich authentifizieren können und andere nicht?
Die Authentifizierung von Benutzern aus einer dieser Domänem am CUCM funktioniert. (Direkt am Portal oder über Jabber.)
Die von Benutzern aus einer anderen dieser Domänen hingegen nicht. Seit gestern nicht mehr.
Die von Benutzern aus einer anderen dieser Domänen hingegen nicht. Seit gestern nicht mehr.
Ist es klar getestet, dass der Zugriff nur aus einer der Domänen funktioniert und aus anderen nicht, oder gibt es gemischte Ergebnisse? Also Benutzer aus einer Domäne, die sich authentifizieren können und andere nicht?
Zitat von @SoerBjoern:
Ist es klar getestet, dass der Zugriff nur aus einer der Domänen funktioniert und aus anderen nicht, oder gibt es gemischte Ergebnisse? Also Benutzer aus einer Domäne, die sich authentifizieren können und andere nicht?
Eindeutig.Ist es klar getestet, dass der Zugriff nur aus einer der Domänen funktioniert und aus anderen nicht, oder gibt es gemischte Ergebnisse? Also Benutzer aus einer Domäne, die sich authentifizieren können und andere nicht?
Heute hat sich die Lösung ergeben.
Aus mir völlig unklarem Grund wendet CUCM bei der LDAP-Authentifizierung den selben LDAP-Filter an, wie er beim Import der Benutzer aus dem AD verwendet wird.
Bei der betreffenden Domäne, wo die Anmeldung nicht funktionierte, war der AD-Import-Filter auf "None" gestellt. (Soviel zum Thema: "Es wurde überhaupt nichts geändert ....")
Damit wird der Standardfilter angewendet, der da lautet:
Die Objekt im LDAP des LDAP-Proxy sind aber von der Klasse "userProxy", welche nicht von "user" abgeleitet ist und deshalb der Filter keinen Treffer liefern kann.
Danke trotzdem für Euren Input!
Aus mir völlig unklarem Grund wendet CUCM bei der LDAP-Authentifizierung den selben LDAP-Filter an, wie er beim Import der Benutzer aus dem AD verwendet wird.
Bei der betreffenden Domäne, wo die Anmeldung nicht funktionierte, war der AD-Import-Filter auf "None" gestellt. (Soviel zum Thema: "Es wurde überhaupt nichts geändert ....")
Damit wird der Standardfilter angewendet, der da lautet:
(&(&(objectclass=user)(!(objectclass=computer)))(!(UserAccountControl:1.2.840.113556.1.4.803:=2))
Bei der Authentifizierung in Kombination mit dem Anmeldename dann"(&(&(&(objectclass=user)(!(objectclass=computer)))(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))(sAMAccountName=testbenutzer))”
Die Objekt im LDAP des LDAP-Proxy sind aber von der Klasse "userProxy", welche nicht von "user" abgeleitet ist und deshalb der Filter keinen Treffer liefern kann.
- Wie blöd ist das denn von Cisco?
- Ich werde dem Admin danken, dass er "nichts" geändert hat.
Danke trotzdem für Euren Input!
1
Hallo,
kleiner Nachtrag zum Testen von LDAP: Wenn man die RSAT (für ADDS-Rollen) installiert, bekommt man das Tool ldp.exe installiert. https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windo ... Da kann man quasi mit Bordmitteln den Zugriff auf LDAP testen.
Grüße
lcer
kleiner Nachtrag zum Testen von LDAP: Wenn man die RSAT (für ADDS-Rollen) installiert, bekommt man das Tool ldp.exe installiert. https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windo ... Da kann man quasi mit Bordmitteln den Zugriff auf LDAP testen.
Grüße
lcer
