Éditions compatibles avec cette fonctionnalité : Frontline Standard et Frontline Plus ; Business Plus ; Enterprise Standard et Enterprise Plus ; Education Fundamentals, Education Standard et Education Plus ; Enterprise Essentials Plus. Comparer votre édition
Avant d'essayer de connecter votre client LDAP au service LDAP sécurisé, vous pouvez facultativement effectuer un test de connectivité rapide à l'aide d'outils simples tels que ldapsearch, ADSI ou ldp.exe. Ces outils peuvent également être utilisés à des fins de dépannage si vous rencontrez des erreurs lors de la tentative de connexion de votre client LDAP au service sécurisé.
Les tests décrits dans les sections ci-dessous vous permettent de déterminer si vous rencontrez un problème de configuration, de comprendre les messages d'erreur courants et d'obtenir des recommandations pour résoudre ces problèmes.
Cet article contient les sections suivantes :
- Vérifier la connectivité et exécuter une requête LDAP
L'exécution d'une requête LDAP vous permet de confirmer que vous pouvez vous connecter à LDAP sécurisé et effectuer des requêtes. - Si nécessaire, exécutez un test de connectivité de base.
Si l'exécution d'une requête LDAP échoue, exécutez un test de connectivité de base pour vérifier l'accès au réseau et l'authentification.
Remarque : Si vous devez contacter l'assistance Google Workspace ou l'assistance Cloud Identity Premium pendant cette procédure, veillez à enregistrer le résultat des commandes. Veillez à supprimer toutes les informations permettant d'identifier personnellement l'utilisateur des résultats avant de les partager avec l'équipe d'assistance.
Vérifier la connectivité et exécuter une requête LDAP
Une fois que vous avez configuré le service LDAP sécurisé dans la console d'administration Google, vous pouvez utiliser l'un de ces trois outils simples pour vérifier la connectivité avec LDAP sécurisé : ldapsearch, ADSI ou ldp.exe. Pour obtenir des informations détaillées et des instructions, consultez les sections ci-dessous.
ldapsearch
Utilisez l'utilitaire ldapsearch à partir d'une ligne de commande pour effectuer une requête LDAP de base. Si cette requête LDAP s'exécute avec succès, cela indique que le client LDAP, la session TLS sous-jacente et la connexion TCP fonctionnent comme prévu.
Pour tester la connectivité avec ldapsearch :
- Créez une configuration LDAP et téléchargez le certificat en suivant les instructions de la section Ajouter des clients LDAP.
Remarque : Pour simplifier l'environnement de test, assurez-vous qu'il y a au moins un utilisateur dans l'unité organisationnelle pour laquelle vous autorisez l'accès client LDAP.
- Exécutez une requête LDAP. Cet exemple interroge un utilisateur spécifique (pour en savoir plus, consultez 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})'Remplacez les espaces réservés comme suit :
- {crt_file} : nom du fichier .crt
- {key_file} : nom du fichier .key
- {domain} : chaque partie du nom de domaine (par exemple, "example.com" devient "dc=example,dc=com")
- {user_email} : adresse e-mail principale d'un utilisateur du domaine.
Remarques sur l'utilisation de ldapsearch
- Si aucune valeur BindDN n'est fournie, ldapsearch utilise la clé et le certificat pour autoriser la recherche.
- Si la valeur BindDN est un nom d'utilisateur LDAP que vous avez généré dans la console d'administration, ldapsearch utilisera les autorisations du client LDAP telles qu'elles sont configurées dans la console d'administration.
ldapsearch -H ldaps://ldap.google.com:636 -b dc={domain},dc={domain} -D {ldap_access_credentials_username} -W '(mail={user_email}) - Si la valeur BindDN est une adresse e-mail ou un nom distinctif LDAP d'un utilisateur Workspace, ldapsearch utilisera les identifiants de cet utilisateur pour effectuer une recherche en fonction de ses autorisations.
ldapsearch -H ldaps://ldap.google.com:636 -b dc={domain},dc={domain} -D {workspace_username@domain} -W '(mail={user_email})'
Utiliser ldapsearch avec stunnel
Si votre déploiement nécessite l'utilisation de stunnel, procédez comme suit :
- Dans la console d'administration, générez des identifiants d'accès pour obtenir le nom d'utilisateur et le mot de passe requis par ldapsearch.
- Exécutez la commande suivante :
ldapsearch -x -D "{username}" -w {password} -H ldap://{stunnel_host}:{stunnel_port} -b dc={domain},dc={domain} '(mail={user_email})'Remplacez les espaces réservés comme suit :
- {username} : nom d'utilisateur des identifiants générés dans la console d'administration
- {password} : mot de passe issu des identifiants générés dans la console d'administration
- {stunnel_host} : adresse IP ou nom d'hôte de la machine exécutant stunnel sur votre réseau.
- {stunnel_port} : port sur lequel stunnel est exécuté. Vérifiez la configuration de stunnel.
- {user_email} : adresse e-mail principale d'un utilisateur du domaine
Scénario de réussite de la commande ldapsearch
Si la commande ldapsearch est exécutée avec succès, le résultat listera l'utilisateur avec l'adresse e-mail (telle qu'elle a été spécifiée lors de la création du client LDAP) au format LDIF.
Exemple :
# 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:
Erreurs possibles
- Le client et/ou la bibliothèque OpenLDAP sont compilés sans prise en charge SNI
Le client LDAP (OpenLDAP dans ce cas) doit être compatible avec SNI (Server Name Indication). Si SNI n'est pas disponible, une erreur semblable à celle-ci peut s'afficher :SASL/EXTERNAL authentication startedldap_sasl_interactive_bind_s: Unknown authentication method (-6)additional info: SASL(-4): no mechanism available:
Recommandation :- Si vous utilisez macOS, SASL est activé par défaut et peut être contourné via l'option "-x".
- Ajoutez l'option
-d5à ldapsearch et vérifiez la ligne suivante dans le résultat :TLS certificate verification: depth: 0, err: 18, subject: /OU=No SNI provided; please fix your client.
-
ldapsearch renvoie l'état 0 (réussite), mais aucun utilisateur n'est affiché
L'option ldapsearch-x(utiliser l'authentification SASL) avec des certificats client permet de s'authentifier, mais ne liste pas les utilisateurs du domaine.
Recommandation : supprimez l'option-xet réessayez.
ADSI Edit (Windows)
- Suivez les étapes 1 à 11 de ldp.exe (Windows) pour installer les certificats client.
- Accédez à Action > Connect to (Action > Se connecter à).
- Saisissez les paramètres de connexion suivants :
Nom : saisissez un nom pour votre connexion, par exemple Google LDAP.
Point de connexion : sélectionnez ou saisissez un nom distinctif ou un contexte de dénomination.
Saisissez votre nom de domaine au format DN (par exemple, dc=example,dc=com pour example.com).
Ordinateur : sélectionnez ou saisissez un domaine ou un serveur.
ldap.google.com
Utiliser le chiffrement basé sur SSL : coché - Cliquez sur Avancé…, puis saisissez les informations suivantes :
Spécifier les identifiants : coché
Nom d'utilisateur : nom d'utilisateur des identifiants d'accès dans la console d'administration
Mot de passe : mot de passe des identifiants d'accès dans la console d'administration
Numéro de port : 636
Protocole : LDAP
Authentification par liaison simple : coché - Cliquez sur OK, puis de nouveau sur OK.
- Si la connexion aboutit, le contenu de l'annuaire s'affiche dans le volet de droite dans le format DN de base.
ldp.exe (Windows)
- Installez OpenSSL.
- Convertissez les fichiers de clé et de certificat en un fichier au format PKCS12. À l'invite de commande, saisissez ce qui suit :
openssl pkcs12 -inkey ldap-client.key -in ldap-client.crt -export -out ldap-client.p12
Saisissez un mot de passe pour chiffrer le fichier de sortie. - Accédez au panneau de configuration.
- Dans le champ de recherche, recherchez "certificat", puis cliquez sur Gérer les certificats utilisateur.
- Accédez à Action > All Tasks > Import… (Action > Toutes les tâches > Importer).
- Sélectionnez Current User (Utilisateur actuel), puis cliquez sur Next (Suivant).
- Cliquez sur Browse (Parcourir).
- Dans la liste déroulante File type (Type de fichier) en bas à droite de la boîte de dialogue, sélectionnez Personal Information Exchange (*.pfx;*.p12) (Échange d'informations personnelles [*.pfx;*.p12]).
- Sélectionnez le fichier ldap-client.p12 de l'étape 2, cliquez sur Ouvrir, puis sur Suivant.
- Saisissez le mot de passe de l'étape 2, puis cliquez sur Next (Suivant).
- Sélectionnez le magasin de certificats Personnel, cliquez sur Suivant, puis sur Terminer.
- Exécutez Ldp.exe.
- Accédez à Connexion > Se connecter…
- Saisissez les informations de connexion suivantes :
Serveur : ldap.google.com
Port : 636
Sans connexion : décoché
SSL : coché - Cliquez sur OK.
- Accédez à View > Tree (Affichage > Arborescence).
- Saisissez le nom de domaine de base. Il s'agit de votre nom de domaine au format DN, par exemple dc=example,dc=com pour example.com.
- Cliquez sur OK.
- Si la connexion aboutit, le contenu de l'annuaire s'affiche dans le volet de droite dans le format DN de base.
Si nécessaire, exécutez des tests de connectivité de base.
Si vous n'obtenez pas de résultat positif dans Vérifier la connectivité et exécuter une requête LDAP, suivez les instructions de cette section pour tester la connectivité. Si ldapsearch ne parvient pas à renvoyer l'utilisateur attendu et n'indique pas clairement que la session TLS sous-jacente a réussi, utilisez le client OpenSSL pour vérifier que les couches réseau sur lesquelles repose OpenLDAP fonctionnent comme prévu.
Pour effectuer des tests de connectivité de base :
Installez l'utilitaire client OpenSSL compatible avec votre système d'exploitation.
La plupart des distributions GNU/Linux utilisent le nom de paquet "openssl". Consultez les informations sur les autres systèmes d'exploitation.
Connectez-vous manuellement au service LDAP sécurisé à l'aide du client OpenSSL :
openssl s_client -connect ldap.google.com:636Confirmez que la négociation SSL a réussi en vérifiant la présence de la ligne suivante à la fin du résultat OpenSSL s_client :
Verify return code: 0 (ok)
Erreurs possibles
Le client/la bibliothèque OpenSSL ne sont pas compatibles avec SNI (Server Name Indication)
Pendant le test de connectivité, le résultat suivant peut apparaître :
Verify return code: 18 (self signed certificate)
Le service LDAP sécurisé nécessite un client TLS qui accepte et initie une session TLS à l'aide de l'extension SNI (Server Name Indication). Si le client TLS ne prend pas en charge SNI, le serveur TLS (ldap.google.com) renvoie un certificat autosigné qui ne passera pas les contrôles de validation de l'autorité de certification, pour indiquer que SNI est requis.
Ce comportement peut être confirmé en vérifiant le résultat du client OpenSSL au début de la ligne suivante :
depth=0 OU = "No SNI provided; please fix your client.", CN = invalid2.invalid
Cette erreur peut survenir en raison d'une version OpenSSL n'acceptant pas l'extension SNI ou d'une application utilisant la bibliothèque OpenSSL pour laquelle l'extension SNI est explicitement désactivée.
Connexion refusée
Si le résultat suivant est renvoyé (où {timestamp} est un code temporel UNIX en microsecondes), la connexion TCP est activement refusée avant que la négociation TLS puisse commencer :
{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
Ce problème peut être causé par :
- un pare-feu au niveau de l'application ou du système sur la machine locale ;
- un pare-feu sur le même réseau physique ou réseau en amont.
Afin d'en savoir plus sur ce problème, déterminez quel hôte refuse la connexion à l'aide d'un test tcptraceroute, par exemple, tcptraceroute ldap.google.com 636.