Versioni supportate per questa funzionalità: Frontline Standard; Business Plus; Enterprise Standard ed Enterprise Plus; Education Fundamentals, Education Standard, Teaching and Learning Upgrade ed Education Plus; Enterprise Essentials Plus. Confronta la tua versione
Prima di provare a connettere il client LDAP al servizio LDAP sicuro potresti eseguire (facoltativamente) un breve test di connettività utilizzando strumenti semplici quali ldapsearch, ADSI o ldp.exe. Puoi utilizzare questi strumenti anche per la risoluzione di problemi qualora riscontrassi errori durante il tentativo di connessione del tuo client LDAP al servizio.
Nelle sezioni seguenti sono descritti i test che ti permettono di capire se il problema di configurazione è dal tuo lato e interpretare messaggi di errore comuni, oltre a consigli su come risolvere tali problemi.
Questo articolo contiene le seguenti sezioni:
- Verificare la connettività ed eseguire una query LDAP
L'esecuzione di una query LDAP consente di confermare che puoi collegarti a LDAP sicuro ed eseguire query.
- Eseguire il test di connettività di base (se necessario)
Se l'esecuzione di una query LDAP dà esito negativo, esegui i test di connettività di base per provare l'accesso alla rete e l'autenticazione.
Nota: se nel corso di questo processo devi contattare l'assistenza di Google Workspace o l'assistenza di Cloud Identity Premium, accertati di salvare l'output dei comandi e di rimuovere le informazioni che consentono l'identificazione personale dall'output prima di condividerlo con il team di assistenza.
Verificare la connettività ed eseguire una query LDAP
Dopo aver configurato il servizio LDAP sicuro nella Console di amministrazione Google, puoi utilizzare uno di questi tre semplici strumenti per verificare la connettività con LDAP sicuro: ldapsearch, ADSI o ldp.exe. Per i dettagli e le istruzioni, vedi le sezioni seguenti.
ldapsearchUtilizza l'utilità ldapsearch da una riga di comando per eseguire una query LDAP di base. Una query LDAP con esito positivo indica che il client LDAP, la sessione TLS sottostante e la connessione TCP funzionano come previsto.
Per testare la connettività con ldapsearch:
- Crea una configurazione LDAP e scarica il certificato seguendo le istruzioni descritte in 1. Aggiungere i client LDAP.
Nota: per semplificare l'ambiente di test, accertati che nell'unità organizzativa sia presente almeno un utente per cui hai autorizzato l'accesso al client LDAP.
- Esegui una query LDAP.
Il seguente comando è un esempio di come utilizzare lo strumento a riga di comando ldapsearch per eseguire una query per un particolare utente (per maggiori dettagli vedi OpenLDAP lapsearch):
LDAPTLS_CERT={crt_file} LDAPTLS_KEY={key_file} ldapsearch -H ldaps://ldap.google.com:636 -b dc={domain},dc={domain} '(mail={user_email})'Sostituisci i seguenti segnaposto:
{crt_file}: il nome del file .crt
{key_file}: il nome file del file .key
{domain}: le singole parti del nome di dominio, ad esempio: example.com diventa "dc=example,dc=com"
{user_email}: l'indirizzo email principale di un utente del dominio.
Utilizzare ldapsearch con stunnel
Se il tuo deployment richiede l'impiego di stunnel, utilizza i seguenti comandi:
ldapsearch -H ldap://{stunnel_host}:{stunnel_port} -b
dc={domain},dc={domain} '(mail={user_email})'
Sostituisci i segnaposto stunnel specifici:
{stunnel_host}: l'indirizzo IP o nome host del computer che esegue stunnel nella tua rete.
{stunnel_port}: la porta su cui è in esecuzione stunnel; verifica nella tua configurazione di stunnel.
Scenario di esito positivo del comando ldapsearch
Un output con esito positivo del comando ldapsearch elencherà l'utente con l'email, come specificato al momento di creare il client LDAP, in formato LDIF.
Ad esempio:
# 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:
Possibili errori
- Il client e/o la libreria OpenLDAP sono compilati senza supporto SNI
Il client LDAP (in questo caso OpenLDAP) deve supportare SNI (Server Name Indication). Se SNI non è disponibile potrebbe essere visualizzato un errore simile al seguente:
SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
additional info: SASL(-4): no mechanism available:
Consiglio:- Se utilizzi MacOS, SASL è abilitato per impostazione predefinita e può essere bypassato con l'opzione "-x".
- Aggiungi l'opzione
-d5a ldapsearch e controlla l'output della riga seguente:
TLS certificate verification: depth: 0, err: 18, subject: /OU=No SNI provided; please fix your client.
-
ldapsearch restituisce lo stato 0 (riuscito), ma non viene restituito nessun utente come output
Se viene specificata l'opzione ldapsearch-x(utilizzando l'autenticazione SASL) con i certificati client, l'autenticazione andrà a buon fine ma non saranno elencati gli utenti del dominio.
Consiglio: rimuovi l'opzione-xe riprova.
- Segui i passaggi 1–11 in ldp.exe (Windows) per installare i certificati client.
- Vai ad Action > Connect to… (Azione > Connetti a).
- Inserisci le seguenti impostazioni di connessione:
Nome: digita un nome per la connessione, ad esempio Google LDAP.
Connection Point Punto di connessione: "Select or type a Distinguished Name or Naming Context" (Seleziona o digita un nome distinto o un contesto di denominazione)
Inserisci il nome di dominio nel formato DN, ad esempio, dc=example,dc=com per example.com.
Computer: "Select or type a domain or server" (Seleziona o digita un dominio o un server)
ldap.google.com
Use SSL-based Encryption (Usa crittografia basata su SSL): selezionato
- Fai clic su Advanced… (Avanzate) e inserisci i dettagli seguenti:
Specify credentials (Specifica credenziali): selezionato
Username (Nome utente): il nome utente delle credenziali di accesso della Console di amministrazione
Password: la password delle credenziali di accesso dalla Console di amministrazione
Port Number (Numero porta): 636
Protocol (Protocollo): LDAP
Simple bind authentication (Autenticazione di binding semplice): selezionato
- Fai clic su OK, quindi di nuovo su OK.
- Se la connettività ha esito positivo, i contenuti della directory nel DN di base sono visualizzati nel riquadro a destra.
- Installa OpenSSL.
- Converti i file della chiave e del certificato client in un file in formato PKCS12. Al prompt dei comandi, inserisci quanto segue:
openssl pkcs12 -inkey ldap-client.key -in ldap-client.crt -export -out ldap-client.p12
Inserisci una password per criptare il file di output.
- Vai al Pannello di controllo.
- Nella casella di ricerca, cerca "certificate" (certificato) e fai clic su Manage user certificates (Gestisci certificati utente).
- Vai ad Action > All Tasks > Import… (Azione > Tutte le attività > Importa).
- Seleziona Current User (Utente corrente) e fai clic su Next (Avanti).
- Fai clic su Browse… (Sfoglia)
- Nell'elenco a discesa File type (Tipo di file) nell'angolo inferiore destro della finestra di dialogo, seleziona Personal Information Exchange (*.pfx;*.p12) (Scambio di informazioni personali).
- Seleziona il file ldap-client.p12 del passaggio 2, fai clic su Open (Apri) e quindi su Next (Avanti).
- Inserisci la password utilizzata al passaggio 2 e fai clic su Next (Avanti).
- Seleziona l'archivio certificati Personal (Personale), fai clic su Next (Avanti) e quindi su Finish (Fine).
- Esegui Ldp.exe.
- Vai a Connection > Connect… (Connessione > Connetti).
- Inserisci i seguenti dati di connessione:
Server: ldap.google.com
Port (Porta): 636
Connectionless (Senza connessione): deselezionato
SSL: selezionato
- Fai clic su OK.
- Vai a View > Tree (Visualizza > Struttura).
- Inserisci il DN di base, ovvero il tuo nome dominio in formato DN, ad esempio dc=example,dc=com per example.com.
- Fai clic su OK.
- Se la connettività ha esito positivo, i contenuti della directory nel DN di base sono visualizzati nel riquadro a destra.
Eseguire il test di connettività di base (se necessario)
Se non riesci a ottenere un risultato positivo dalle procedure indicate in Verificare la connettività ed eseguire una query LDAP, segui le istruzioni di questa sezione per eseguire un test di connettività. Se ldapsearch non restituisce l'utente previsto e non dà un'indicazione chiara che la sessione TLS sottostante sia riuscita, utilizza il client OpenSSL per verificare che i livelli della rete su cui si basa OpenLDAP funzionino come previsto.
Per eseguire il test di connettività di base:
- Installa l'utilità client openssl per il tuo sistema operativo.
La maggior parte delle distribuzioni GNU/Linux utilizza il nome di pacchetto "openssl". Vedi i dettagli su altri sistemi operativi.
-
Crea manualmente una connessione al servizio LDAP sicuro utilizzando il client openssl:
openssl s_client -connect ldap.google.com:636
Verifica che la negoziazione SSL abbia avuto esito positivo controllando che in fondo all'output di openssl s_client sia presente questa riga:
Verify return code: 0 (ok)
Possibili errori
Il client o la libreria OpenSSL non supporta SNI (Server Name Indication)
Durante il test di connettività potrebbe essere restituito il seguente output:
Verify return code: 18 (self signed certificate)
Il servizio LDAP sicuro richiede un client TLS che supporti e avvii una sessione TLS utilizzando SNI (Server Name Indication). Se il client TLS non supporta SNI, il server TLS (ldap.google.com) restituisce un certificato autofirmato che non supera i controlli di convalida CA, a indicare che è necessario SNI.
Per confermare questo comportamento, controlla che nella parte iniziale dell'output del client OpenSSL sia presente questa riga:
depth=0 OU = "No SNI provided; please fix your client.", CN = invalid2.invalid
Alcune possibili cause di questo errore sono: una versione OpenSSL che non supporta SNI oppure un'applicazione che utilizza la libreria OpenSSL in cui SNI è esplicitamente disattivato.
Connessione rifiutata
Se viene restituito il seguente output, in cui {timestamp} è un timestamp UNIX in microsecondi, la connessione TCP viene rifiutata attivamente prima ancora dell'avvio della negoziazione TLS:
{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
Le cause potrebbero essere le seguenti:
- Un firewall a livello di applicazione o a livello di sistema sulla macchina locale
- Un firewall sulla stessa rete fisica o rete di upstream
Per approfondire, utilizza tcptraceroute per determinare quale host rifiuta la connessione, ad esempio tcptraceroute ldap.google.com 636.
