Unterstützte Versionen für diese Funktion: Frontline Standard und Frontline Plus; Business Plus; Enterprise Standard und Enterprise Plus; Education Fundamentals, Education Standard und Education Plus; Enterprise Essentials Plus. Versionen vergleichen
Bevor Sie versuchen, Ihren LDAP-Client mit dem Secure LDAP-Dienst zu verbinden, können Sie optional einen schnellen Verbindungstest mit einfachen Tools wie ldapsearch, ADSI oder ldp.exe durchführen. Diese Tools lassen sich auch zur Behebung von Fehlern einsetzen, die ggf. beim Verbinden Ihres LDAP-Clients mit dem Dienst auftreten.
Mithilfe der in den folgenden Abschnitten beschriebenen Tests können Sie herausfinden, ob bei Ihnen ein Konfigurationsproblem vorliegt. Außerdem finden Sie dort häufige Fehlermeldungen und Empfehlungen zur Behebung dieser Probleme.
Dieser Artikel enthält die folgenden Abschnitte:
- Verbindung prüfen und LDAP-Abfrage ausführen
Wenn Sie eine LDAP-Abfrage ausführen, können Sie prüfen, ob Sie eine Verbindung zu Secure LDAP herstellen und Abfragen ausführen können. - Bei Bedarf grundlegende Konnektivitätstests ausführen
Wenn eine LDAP-Abfrage fehlschlägt, führen Sie grundlegende Konnektivitätstests aus, um den Netzwerkzugriff und die Authentifizierung zu testen.
Hinweis:Wenn Sie sich während dieses Vorgangs an den Google Workspace-Support oder den Cloud Identity Premium-Support wenden müssen, speichern Sie die Ausgabe der Befehle. Entfernen Sie alle personenbezogenen Daten aus der Ausgabe, bevor Sie sie mit dem Supportteam teilen.
Konnektivität prüfen und eine LDAP-Abfrage ausführen
Nachdem Sie den Secure LDAP-Dienst in der Admin-Konsole eingerichtet haben, können Sie die Verbindung mit Secure LDAP mit einem der folgenden drei einfachen Tools testen: ldapsearch, ADSI oder ldp.exe. Weitere Informationen und Anleitungen finden Sie in den nächsten Abschnitten.
ldapsearch
Verwenden Sie das Dienstprogramm ldapsearch über eine Befehlszeile, um eine einfache LDAP-Abfrage zu stellen. Ist sie erfolgreich und liefert ein Ergebnis, wissen Sie, dass der LDAP-Client und die zugrunde liegenden TLS-Sitzungen und TCP-Verbindungen wie vorgesehen funktionieren.
So testen Sie die Verbindung mit ldapsearch:
- Erstellen Sie eine LDAP-Konfiguration und laden Sie das Zertifikat herunter. Folgen Sie dazu der Anleitung unter LDAP-Clients hinzufügen.
Hinweis:Um die Testumgebung zu vereinfachen, sollte sich mindestens ein Nutzer in der Organisationseinheit befinden, für die Sie den LDAP-Clientzugriff autorisieren.
- Führen Sie eine LDAP-Abfrage aus. In diesem Beispiel wird ein bestimmter Nutzer abgefragt. Weitere Informationen finden Sie unter OpenLDAP ldapsearch.
LDAPTLS_CERT={crt_file} LDAPTLS_KEY={key_file} ldapsearch -H ldaps://ldap.google.com:636 -b dc={domain},dc={domain} '(mail={user_email})'Ersetzen Sie die Platzhalter wie folgt:
- {crt_file}: Der Name der CRT-Datei
- {key_file}: Der Dateiname der .key-Datei
- {domain}: Jeder Teil des Domainnamens, z. B. „beispiel.de“ wird zu „dc=beispiel,dc=de“.
- {user_email}: Primäre E‑Mail-Adresse eines Nutzers in der Domain.
Hinweise zur Verwendung von ldapsearch
- Wenn kein BindDN-Wert angegeben ist, verwendet ldapsearch den Schlüssel und das Zertifikat, um die Suche zu autorisieren.
- Wenn der BindDN-Wert ein LDAP-Nutzername ist, den Sie in der Admin-Konsole generiert haben, verwendet ldapsearch die Berechtigungen des LDAP-Clients, wie in der Admin-Konsole konfiguriert.
ldapsearch -H ldaps://ldap.google.com:636 -b dc={domain},dc={domain} -D {ldap_access_credentials_username} -W '(mail={user_email}) - Wenn der BindDN-Wert eine E-Mail-Adresse oder ein LDAP-DN eines Workspace-Nutzers ist, verwendet „ldapsearch“ die Anmeldedaten dieses Nutzers, um basierend auf seinen Berechtigungen zu suchen.
ldapsearch -H ldaps://ldap.google.com:636 -b dc={domain},dc={domain} -D {workspace_username@domain} -W '(mail={user_email})'
ldapsearch mit stunnel verwenden
Wenn für Ihr Deployment stunnel erforderlich ist, gehen Sie so vor:
- Generieren Sie in der Admin-Konsole Anmeldedaten, um den Nutzernamen und das Passwort zu erhalten, die für „ldapsearch“ erforderlich sind.
- Verwenden Sie den folgenden Befehl:
ldapsearch -x -D "{username}" -w {password} -H ldap://{stunnel_host}:{stunnel_port} -b dc={domain},dc={domain} '(mail={user_email})'Ersetzen Sie die Platzhalter so:
- {username}: Nutzername aus den generierten Anmeldedaten in der Admin-Konsole
- {password}: Passwort aus den generierten Anmeldedaten in der Admin-Konsole
- {stunnel_host}: IP-Adresse oder Hostname des Computers, auf dem stunnel in Ihrem Netzwerk ausgeführt wird.
- {stunnel_port}: Port, an dem Stunnel ausgeführt wird. Überprüfen Sie Ihre Stunnel-Konfiguration.
- {user_email}: primäre E-Mail-Adresse eines Nutzers in der Domain
Erfolgreiches Szenario des Befehls „ldapsearch“
Bei einer erfolgreichen Ausgabe des Befehls ldapsearch wird der Nutzer mit der E-Mail-Adresse (wie beim Erstellen des LDAP-Clients angegeben) im LDIF-Format aufgeführt.
Beispiel:
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# example.com
dn: dc=example,dc=com
objectClass: top
objectClass: domain
objectClass: dcObject
dc: example
# admin-group, Groups, example.com
dn: cn=admin-group,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: groupOfNames
objectClass: posixGroup
cn: admin-group
displayName: admin-group
description:
gidNumber: 12345
member: uid=admin,ou=Users,dc=example,dc=com
memberUid: admin
googleAdminCreated: FALSE
# example-user, Users, example.com
dn: uid=example-user,ou=Users,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
uid: example-user
googleUid: example-user
posixUid: example-user
cn: example-user
cn: FirstName LastName
sn: FirstName
displayName: FirstName LastName
givenName: FirstName
mail: example-user@example.com
uidNumber: 12345
gidNumber: 12345
homeDirectory: /home/example-user
loginShell: /bin/bash
gecos:
Mögliche Fehler
- OpenLDAP-Client und/oder -Bibliothek werden ohne SNI-Unterstützung kompiliert
SNI (Server Name Indication) muss vom LDAP-Client (in diesem Fall OpenLDAP) unterstützt werden. Wenn SNI nicht verfügbar ist, wird möglicherweise ein Fehler wie der folgende angezeigt:SASL/EXTERNAL authentication startedldap_sasl_interactive_bind_s: Unknown authentication method (-6)additional info: SASL(-4): no mechanism available:
Empfehlung:- Wenn Sie MacOS verwenden, ist SASL standardmäßig aktiviert und kann mit der Option „-x“ umgangen werden.
- Fügen Sie die Option
-d5zu ldapsearch hinzu und prüfen Sie die Ausgabe auf die folgende Zeile:TLS certificate verification: depth: 0, err: 18, subject: /OU=No SNI provided; please fix your client.
-
ldapsearch gibt den Status 0 (Erfolg) zurück, aber es werden keine Nutzer ausgegeben
Wenn Sie die ldapsearch-Option-x(SASL-Authentifizierung verwenden) mit Clientzertifikaten angeben, wird die Authentifizierung erfolgreich durchgeführt, aber es werden keine Nutzer in der Domain aufgeführt.
Empfehlung:Entfernen Sie die Option-xund versuchen Sie es noch einmal.
ADSI Edit (Windows)
- Folgen Sie der Anleitung unter ldp.exe (Windows), um die Clientzertifikate zu installieren.
- Gehen Sie zu Action > Connect to… (Aktion > Verbinden mit…).
- Geben Sie die folgenden Verbindungseinstellungen ein:
Name:Geben Sie einen Namen für die Verbindung ein, z. B. Google LDAP.
Connection Point (Verbindungspunkt): „Select or type a Distinguished Name or Naming Context“ (Wählen Sie einen Distinguished Name oder Naming Context aus oder geben Sie ihn ein)
Geben Sie Ihren Domainnamen im DN-Format ein, z. B. dc=beispiel,dc=de für beispiel.de.
Computer (Computer): „Select or type a domain or server“ (Wählen Sie eine Domain oder einen Server aus oder geben Sie sie ein)
ldap.google.com
Use SSL-based Encryption (SSL-basierte Verschlüsselung verwenden): Aktiviert - Klicken Sie auf Erweitert… und geben Sie die folgenden Details ein:
Anmeldedaten angeben:Aktiviert
Nutzername:Der Nutzername der Anmeldedaten aus der Admin-Konsole
Passwort:Das Passwort der Anmeldedaten aus der Admin-Konsole
Portnummer:636
Protokoll:LDAP
Einfache Bindungsauthentifizierung:Aktiviert - Klicken Sie auf OK und dann noch einmal auf OK.
- Wenn die Verbindung erfolgreich war, werden im rechten Fensterbereich die Inhalte des Verzeichnisses im Basis-DN angezeigt.
ldp.exe (Windows)
- Installieren Sie OpenSSL.
- Konvertieren Sie die Zertifikats- und Schlüsseldateien in eine Datei im PKCS12-Format. Geben Sie an der Eingabeaufforderung Folgendes ein:
openssl pkcs12 -inkey ldap-client.key -in ldap-client.crt -export -out ldap-client.p12
Geben Sie ein Passwort zum Verschlüsseln der Ausgabedatei ein. - Gehen Sie zum Steuerfeld.
- Suchen Sie im Suchfeld nach „Zertifikat“ und klicken Sie auf Nutzerzertifikate verwalten.
- Gehen Sie zu Action > All Tasks > Import… (Aktion > Alle Aufgaben > Importieren…).
- Wählen Sie Current User (Aktueller Nutzer) aus und klicken Sie auf Next (Weiter).
- Klicken Sie auf Browse… (Durchsuchen…).
- Wählen Sie rechts unten im Dialogfeld über die Drop-down-Liste file type (Dateityp) die Option Personal Information Exchange (*.pfx;*.p12) (Austausch personenbezogener Daten (*.pfx;*.p12)) aus.
- Wählen Sie die Datei ldap-client.p12 aus Schritt 2 aus, klicken Sie auf Öffnen und dann auf Weiter.
- Geben Sie das Passwort aus Schritt 2 ein und klicken Sie auf Next (Weiter).
- Wählen Sie den Zertifikatspeicher Persönlich aus, klicken Sie auf Weiter und dann auf Fertigstellen.
- Führen Sie Ldp.exe aus.
- Klicken Sie auf Verbindung > Verbinden…
- Geben Sie die folgenden Verbindungsdetails ein:
Server:ldap.google.com
Port:636
Verbindungslos:Nicht aktiviert
SSL:Aktiviert - Klicken Sie auf OK.
- Gehen Sie zu View > Tree (Ansicht > Baum).
- Geben Sie den Basis-DN ein. Dies ist Ihr Domainname im DN-Format, z. B. dc=beispiel,dc=de für beispiel.de.
- Klicken Sie auf OK.
- Wenn die Verbindung erfolgreich war, werden im rechten Fensterbereich die Inhalte des Verzeichnisses im Basis-DN angezeigt.
Bei Bedarf grundlegende Konnektivitätstests ausführen
Wenn Sie in Verbindung prüfen und LDAP-Abfrage ausführen kein erfolgreiches Ergebnis erhalten, folgen Sie der Anleitung in diesem Abschnitt zum Testen der Verbindung. Wenn ldapsearch den erwarteten Nutzer nicht zurückgibt und nicht eindeutig darauf hinweist, dass die zugrunde liegende TLS-Sitzung erfolgreich ist, verwenden Sie den OpenSSL-Client, um zu prüfen, ob die Netzwerkschichten, auf die OpenLDAP angewiesen ist, wie erwartet funktionieren.
So führen Sie grundlegende Konnektivitätstests durch:
Installieren Sie für Ihr Betriebssystem den Client OpenSSL.
Für die meisten GNU-/Linux-Distributionen brauchen Sie das Paket „openssl“. Weitere Informationen zu anderen Betriebssystemen
Stellen Sie mithilfe von openssl eine manuelle Verbindung zu Secure LDAP her:
openssl s_client -connect ldap.google.com:636Prüfen Sie, ob die SSL-Verhandlung erfolgreich war. Suchen Sie dazu am Ende der Ausgabe von „openssl s_client“ nach der folgenden Zeile:
Verify return code: 0 (ok)
Mögliche Fehler
Der OpenSSL-Client/die OpenSSL-Bibliothek unterstützt SNI (Server Name Indication) nicht
Während des Konnektivitätstests kann es zu folgenden Ausgaben kommen:
Verify return code: 18 (self signed certificate)
Secure LDAP erfordert einen TLS-Client, der SNI unterstützt und damit eine TLS-Sitzung initiiert. Wenn der TLS-Client SNI nicht unterstützt, gibt der TLS-Server (ldap.google.com) ein selbst signiertes Zertifikat zurück, das die CA-Validierungsprüfungen nicht besteht. Dies weist darauf hin, dass SNI erforderlich ist.
Dieses Verhalten können Sie prüfen, indem Sie am Anfang der Ausgabe des OpenSSL-Clients nach der folgenden Zeile suchen:
depth=0 OU = "No SNI provided; please fix your client.", CN = invalid2.invalid
Denkbare Ursachen für diesen Fehler sind eine OpenSSL-Version, die SNI nicht unterstützt, oder eine Anwendung, die die OpenSSL-Bibliothek verwendet und für die SNI explizit deaktiviert ist.
Verbindung abgelehnt
Wenn die folgende Ausgabe zurückgegeben wird, wobei {timestamp} ein UNIX-Zeitstempel in Mikrosekunden ist, wird die TCP-Verbindung aktiv abgelehnt, bevor die TLS-Aushandlung beginnen kann:
{timestamp}:error:0200206F:system library:connect:Connection refused:crypto/bio/b_sock2.c:110:
{timestamp}:error:2008A067:BIO routines:BIO_connect:connect error:crypto/bio/b_sock2.c:111:connect:errno=111
Das kann folgende Ursachen haben:
- Firewall auf Anwendungs- oder Systemebene auf dem lokalen Computer
- Firewall im selben physischen Netzwerk oder in einem Upstream-Netzwerk
Zur Untersuchung dieses Fehlers können Sie mit tcptraceroute bestimmen, welcher Host die Verbindung ablehnt, z. B. mit tcptraceroute ldap.google.com 636.