Fehlerbehebung bei Problemen mit der Suche im Cisco Jabber-Verzeichnis

Einführung

In diesem Dokument wird beschrieben, wie Sie bei der Konfiguration von Secure Socket Layer (SSL) ein Problem bei der Suche im Cisco Jabber-Verzeichnis beheben können.

Mitarbeiter: Khushbu Shaikh, Cisco TAC Engineers. Bearbeitet von Sumit Patel und Jasmeeting Sandhu

Voraussetzungen

Anforderungen

Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:

• Jabber für Windows
• Wireshark

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Problem

Die Suche im Jabber-Verzeichnis funktioniert nicht, wenn SSL konfiguriert ist.

Jabber-Protokollanalyse 

Jabber-Protokolle zeigen diesen Fehler an:

Directory searcher LDAP://gbllidmauthp01.sealedair.corp:389/ou=Internal,ou=Users,o=SAC not found, adding server gbllidmauthp01.sealedair.corp to blacklist.

2016-10-21 08:35:47,004 DEBUG [0x000034ec] [rdsource\ADPersonRecordSourceLog.cpp(50)] [csf.person.adsource] [WriteLogMessage] - ConnectionManager::GetDirectoryGroupSearcher - Using custom credentials to connect [LDAP://gbllidmauthp02.sealedair.corp:389] with tokens [1]



2016-10-21 08:35:47,138 DEBUG [0x000034ec] [rdsource\ADPersonRecordSourceLog.cpp(50)] [csf.person.adsource] [WriteLogMessage] - ConnectionManager::GetDirectoryGroupSearcher - failed to get a searcher - COMException [0x80072027]

Paketerfassungsanalyse 

Bei dieser Paketerfassung ist zu erkennen, dass die TCP-Verbindung (Transmission Control Protocol) zum Active Directory (AD)-Server erfolgreich ist, der SSL-Handshake zwischen dem Client und dem Lightweight Directory Access Protocol (LDAP)-Server jedoch fehlschlägt. Dies veranlasst Jabber, eine FIN-Nachricht anstatt des verschlüsselten Sitzungsschlüssels für die Kommunikation zu senden.

  

Das Problem besteht weiterhin, obwohl das signierte AD-Zertifikat in den Trust Store des Client-PCs hochgeladen wird.

Weitere Analysen der Paketerfassung zeigen, dass die Serverauthentifizierung im Abschnitt "Enhanced Key Usage" des AD-Serverzertifikats vorkommt.

Lösung

Ein Szenario wurde mit einem Zertifikat neu erstellt, das über die Serverauthentifizierung unter Verwendung erweiterter Schlüssel verfügt, wodurch das Problem behoben wurde. Vergleichen Sie die Bilder der Zertifikate.

Der Serverauthentifizierungsbezeichner im Zertifikat ist eine Voraussetzung für einen erfolgreichen SSL-Handshake.

Zugehörige Informationen

https://www.petri.com/enable-secure-ldap-windows-server-2008-2012-dc