Säker LDAP-anslutningstestning

Utgåvor som stöds för den här funktionen: Frontline Standard och Frontline Plus; Business Plus; Enterprise Standard och Enterprise Plus; Education Fundamentals, Education Standard och Education Plus; Enterprise Essentials Plus. Jämför din utgåva

Innan du försöker ansluta din LDAP-klient till Secure LDAP-tjänsten kan du eventuellt göra ett snabbt anslutningstest med enkla verktyg som ldapsearch , ADSI eller ldp.exe . Dessa verktyg kan också användas för felsökning om du stöter på fel när du försöker ansluta din LDAP-klient till tjänsten.

Testerna som beskrivs i avsnitten nedan gör det möjligt för dig att förstå om du har ett konfigurationsproblem, vanliga felmeddelanden och rekommendationer för hur dessa problem kan åtgärdas.

Den här artikeln innehåller följande avsnitt:

Obs! Om du behöver kontakta Google Workspace-supporten eller Cloud Identity Premium-supporten under den här processen, se till att spara utdata från kommandona. Se till att du tar bort all personligt identifierbar information från utdata innan du delar den med supportteamet.

Verifiera anslutningen och kör en LDAP-fråga

När du har konfigurerat tjänsten Secure LDAP i Googles administratörskonsol kan du använda ett av dessa tre enkla verktyg för att verifiera anslutningen till Secure LDAP: ldapsearch , ADSI eller ldp.exe . Mer information och instruktioner finns i avsnitten nedan.

ldapsearch

Använd verktyget ldapsearch från en kommandorad för att göra en grundläggande LDAP-fråga. Ett lyckat LDAP-frågeresultat indikerar att LDAP-klienten och den underliggande TLS-sessionen och TCP-anslutningen fungerar som avsett.

För att testa anslutningen med ldapsearch :

  1. Skapa en LDAP-konfiguration och ladda ner certifikatet enligt instruktionerna i Lägg till LDAP-klienter .

    Obs! För att förenkla testmiljön, se till att det finns minst en användare i organisationsenheten som du ger LDAP-klientåtkomst för.

  2. Kör en LDAP-fråga. Det här exemplet frågar en specifik användare (för mer information, se 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})'

    Ersätt platsmarkörer enligt följande:

    • {crt_file} Namnet på .crt-filen
    • {key_file} Filnamnet på .key-filen
    • {domän} Varje del av domännamnet, till exempel: example.com skulle bli "dc=example,dc=com"
    • {user_email} Primär e-postadress för en användare i domänen.

Anmärkningar om användning av ldapsearch

  • Om inget BindDN-värde anges använder ldapsearch nyckeln och certifikatet för att auktorisera sökningen.
  • Om BindDN-värdet är ett LDAP-användarnamn som du genererade i administratörskonsolen kommer ldapsearch att använda LDAP-klientens behörigheter som konfigurerats i administratörskonsolen.

    ldapsearch -H ldaps://ldap.google.com:636 -b dc={domain},dc={domain} -D {ldap_access_credentials_username} -W '(mail={user_email})

  • Om BindDN-värdet är en e-postadress eller ett unikt LDAP-namn för en arbetsyteanvändare, kommer ldapsearch att använda användarens inloggningsuppgifter för att söka baserat på deras behörigheter.

    ldapsearch -H ldaps://ldap.google.com:636 -b dc={domain},dc={domain} -D {workspace_username@domain} -W '(mail={user_email})'

Använd ldapsearch med stunnel

Om din distribution kräver att du använder stunnel , följ dessa steg:

  1. Generera åtkomstuppgifter i administratörskonsolen för att skapa användarnamnet och lösenordet som ldapsearch behöver.
  2. Använd följande kommando:

    ldapsearch -x -D "{username}" -w {password} -H ldap://{stunnel_host}:{stunnel_port} -b dc={domain},dc={domain} '(mail={user_email})'

    Ersätt platsmarkörer enligt följande:

    • {användarnamn} Användarnamn från de genererade inloggningsuppgifterna i administratörskonsolen
    • {password} Lösenord från de genererade inloggningsuppgifterna i administratörskonsolen
    • {stunnel_host}: IP-adress eller värdnamn för den maskin som kör stunnel i ditt nätverk.
    • {stunnel_port} : porten där stunnel körs, kontrollera din stunnel-konfiguration
    • {user_email} Primär e-postadress för en användare i domänen

Lyckat scenario med ldapsearch-kommandot

En lyckad utdata från kommandot ldapsearch listar användaren med e-postadressen (som angavs när LDAP-klienten skapades) i LDIF-format.

Till exempel:

# 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öjliga fel

  • OpenLDAP-klient och/eller bibliotek kompileras utan SNI-stöd

    SNI (Server Name Indication) måste stödjas av LDAP-klienten (i det här fallet OpenLDAP ). Om SNI inte är tillgängligt kan du se ett fel som liknar följande:

    SASL/EXTERNAL authentication started

    ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
    additional info: SASL(-4): no mechanism available:

    Rekommendation:
    • Om du använder MacOS är SASL aktiverat som standard och kan kringgås med alternativet "-x".
    • Lägg till alternativet -d5 i ldapsearch och kontrollera utdata för följande rad:

      TLS certificate verification: depth: 0, err: 18, subject: /OU=No SNI provided; please fix your client.
  • ldapsearch returnerar status 0 (lyckat) men inga användare visas i utdata.

    Om du anger ldapsearch-alternativet -x (använd SASL-autentisering) med klientcertifikat autentiseras den utan problem, men användare i domänen listas inte.

    Rekommendation: Ta bort alternativet -x och försök igen.

ADSI-redigering (Windows)

  1. Följ steg 1–11 i ldp.exe (Windows) för att installera klientcertifikaten.
  2. Gå till Åtgärd > Anslut till…
  3. Ange följande anslutningsinställningar:

    Namn: Skriv ett namn för din anslutning, till exempel Google LDAP .
    Kopplingspunkt: "Välj eller skriv ett unikt namn eller en namngivningskontext"
    Ange ditt domännamn i DN-format (till exempel dc=example, dc=com för example.com ).

    Dator: "Välj eller skriv en domän eller server"
    ldap.google.com

    Använd SSL-baserad kryptering: Markerad
  4. Klicka på Avancerat... och ange följande information:

    Ange inloggningsuppgifter: Markerad
    Användarnamn: Användarnamnet för åtkomstuppgifter från administratörskonsolen
    Lösenord: Lösenordet för åtkomstuppgifterna från administratörskonsolen
    Portnummer: 636
    Protokoll: LDAP
    Enkel bindningsautentisering: Kontrollerad
  5. Klicka på OK och klicka sedan på OK igen.
  6. Om anslutningen lyckas visas kataloginnehållet i bas-DN i den högra rutan.

ldp.exe (Windows)

  1. Installera OpenSSL .
  2. Konvertera certifikat- och nyckelfilerna till en PKCS12-formaterad fil. Ange följande i kommandotolken:

    openssl pkcs12 -inkey ldap-client.key -in ldap-client.crt -export -out ldap-client.p12

    Ange ett lösenord för att kryptera utdatafilen.
  3. Gå till Kontrollpanelen.
  4. I sökrutan söker du efter "certifikat" och klickar på Hantera användarcertifikat .
  5. Gå till Åtgärd > Alla uppgifter > Importera…
  6. Välj Nuvarande användare och klicka på Nästa .
  7. Klicka på Bläddra…
  8. I rullgardinsmenyn för filtyper längst ner till höger i dialogrutan väljer du Utbyte av personlig information (*.pfx;*.p12) .
  9. Välj filen ldap-client.p12 från steg 2, klicka på Öppna och klicka sedan på Nästa .
  10. Ange lösenordet från steg 2 och klicka på Nästa .
  11. Välj det personliga certifikatarkivet, klicka på Nästa och sedan på Slutför .
  12. Kör Ldp.exe .
  13. Gå till Anslutning > Anslut...
  14. Ange följande anslutningsuppgifter:

    Server: ldap.google.com
    Hamn: 636
    Anslutningslös: Omarkerad
    SSL: Kontrollerad
  15. Klicka på OK .
  16. Gå till Visa > Träd .
  17. Ange bas-DN. Detta är ditt domännamn i DN-format. (till exempel dc=example, dc=com för example.com ).
  18. Klicka på OK .
  19. Om anslutningen lyckas visas kataloginnehållet i bas-DN i den högra rutan.

Kör grundläggande anslutningstester om det behövs

Om du inte kan få ett lyckat resultat i Verifiera anslutning och köra en LDAP-fråga , följ instruktionerna i det här avsnittet för anslutningstestning. Om ldapsearch inte lyckas returnera den förväntade användaren och inte ger en tydlig indikation på att den underliggande TLS-sessionen är lyckad, använd OpenSSL-klienten för att verifiera att nätverkslagren som OpenLDAP förlitar sig på fungerar som förväntat.

För att utföra grundläggande anslutningstester:

  1. Installera klientverktyget openssl för ditt operativsystem.

    De flesta GNU/Linux-distributioner använder paketnamnet "openssl". Se detaljer om andra operativsystem .

  2. Gör en manuell anslutning till Secure LDAP-tjänsten med hjälp av openssl- klienten:

    openssl s_client -connect ldap.google.com:636
    

    Bekräfta att SSL-förhandlingen har lyckats genom att följande rad finns i slutet av openssl s_client-utdata:

    Verify return code: 0 (ok)
    

Möjliga fel

OpenSSL-klienten/biblioteket stöder inte SNI (Server Name Indication)

Under anslutningstestet kan följande utdata returneras:

Verify return code: 18 (self signed certificate)

Tjänsten Secure LDAP kräver en TLS-klient som stöder och initierar en TLS-session med SNI (Server Name Indication). Om TLS-klienten inte stöder SNI returnerar TLS-servern (ldap.google.com) ett självsignerat certifikat som inte klarar CA-valideringskontroller, för att indikera att SNI krävs.

Detta beteende kan bekräftas genom att kontrollera OpenSSL-klientens utdata för följande rad nära början av utdata:

depth=0 OU = "No SNI provided; please fix your client.", CN = invalid2.invalid

Orsaker till det här felet kan vara en OpenSSL-version som inte stöder SNI, eller ett program som använder OpenSSL-biblioteket med SNI explicit inaktiverat.

Anslutning nekad

Om följande utdata returneras – där {timestamp} är en UNIX-tidsstämpel i mikrosekunder – nekas TCP-anslutningen aktivt innan TLS-förhandlingen kan starta:

{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

Detta kan orsakas av följande:

  • En brandvägg på applikationsnivå eller systemnivå på den lokala datorn
  • En brandvägg på samma fysiska nätverk eller uppströms nätverk

För att undersöka detta, använd tcptraceroute för att avgöra vilken värd som vägrar anslutningen—till exempel tcptraceroute ldap.google.com 636 .