Come configurare l'autenticazione LDAP esterna per Zimbra

Quali modifiche all'autenticazione LDAP esterna vengono introdotte in Zimbra?

L'autenticazione LDAP esterna consente a Zimbra di verificare la password di un utente rispetto a una directory esterna, anziché utilizzare la password memorizzata nel sistema LDAP interno di Zimbra. La Guida di amministrazione di Zimbra Daffodil (v10) attualmente in vigore afferma che l'autenticazione LDAP esterna viene configurata per dominio e che il metodo esterno tenta di connettersi alla directory specificata con le credenziali utente fornite. Se la connessione ha esito positivo, la password viene considerata valida.

Questo non trasforma automaticamente una directory LDAP esterna nel database degli account di Zimbra. Zimbra continua a memorizzare i dati degli account specifici di Zimbra nella propria directory. La guida alla versione 10 specifica esplicitamente che gli utenti devono normalmente esistere sia in Zimbra che nella directory esterna, a meno che non si configuri separatamente il provisioning automatico.

Per la documentazione aggiornata del prodotto, consultare la Guida dell'amministratore di Zimbra Daffodil v10 e la Guida alla configurazione di Zimbra v10 .

Lista di controllo per una pianificazione rapida

• Conferma il dominio Zimbra che desideri modificare, ad esempio example.com.
• Verifica che gli stessi utenti esistano già in Zimbra, oppure pianifica l'auto-provisioning separatamente.
• È necessario conoscere il nome host LDAP esterno, la porta, il metodo TLS e la catena di certificati.
• Scopri come un nome di accesso Zimbra viene mappato a un DN utente in LDAP.
• Se il DN non può essere costruito direttamente dal nome di accesso, preparare una base di ricerca, un filtro di ricerca e un account di ricerca con privilegi minimi.
• Durante i test, mantieni aperta una sessione di amministrazione di Zimbra in modo da poter ripristinare rapidamente la versione precedente.

Scegli prima il metodo di mappatura più adatto

La Guida di configurazione v10 attuale definisce ancora gli attributi search-base, search-bind, search-filter e external-DN per account. Il materiale ufficiale precedente dello Zimbra Tech Center spiega come vengono utilizzate queste mappature nella pratica. Poiché tale materiale è precedente a Daffodil, si consiglia di considerarlo come un contesto operativo e di verificarne i dettagli rispetto alla versione installata prima di applicare una migrazione di grandi dimensioni. Consultare le note ufficiali dello Zimbra Tech Center relative all'LDAP esterno .

Passaggio 1: Registra le impostazioni di autenticazione del dominio correnti

Eseguire i comandi amministrativi come zimbrautente del sistema operativo. Prima di apportare qualsiasi modifica, acquisire i valori di dominio esistenti:

su - zimbra

zmprov gd example.com \
  zimbraAuthMech \
  zimbraAuthLdapURL \
  zimbraAuthLdapBindDn \
  zimbraAuthLdapSearchBase \
  zimbraAuthLdapSearchFilter \
  zimbraAuthFallbackToLocal

Salva l'output nel tuo record di modifiche. La Guida alla configurazione v10 elenca i valori validi per zimbraAuthMech, inclusi zimbra, ldap, ad, e meccanismi Kerberos o personalizzati. Per questa guida, il meccanismo di destinazione è ldap.

Passaggio 2: Verificare la raggiungibilità della rete e il TLS prima di modificare Zimbra

Non eseguire la risoluzione dei problemi di mappatura dell'autenticazione finché non si ha la certezza che la connettività di base funzioni. Dal server Zimbra, verificare la risoluzione DNS e che l'endpoint LDAP sia raggiungibile. Per LDAPS, è possibile ispezionare la catena di certificati con OpenSSL:

openssl s_client -connect ldap.example.net:636 \
  -servername ldap.example.net -showcerts

Per una directory che utilizza LDAP standard più StartTLS, testa l'endpoint compatibile con StartTLS con un client LDAP appropriato per il tuo sistema operativo. Se ldapsearchè installato, un controllo dell'account di ricerca potrebbe apparire in questo modo:

ldapsearch -x -H ldap://ldap.example.net:389 -ZZ \
  -D "cn=zimbra-search,ou=svc,dc=example,dc=net" -W \
  -b "ou=people,dc=example,dc=net" \
  "(uid=alice)" dn

La Guida di amministrazione di Zimbra v10 afferma che un ldaps:endpoint richiede che il certificato del server LDAP sia considerato attendibile da Zimbra. Non ignorare la convalida del certificato solo per superare il test. Installa l'autorità di certificazione (CA) o la catena di certificati appropriata seguendo la procedura di truststore specifica per la tua versione di Zimbra.

Passaggio 3: Configurare un modello bind-DN ​​diretto quando i DN degli utenti sono prevedibili

Questo è lo schema più semplice. Supponiamo che la directory esterna memorizzi gli utenti come uid=alice,ou=people,dc=example,dc=nete che il login di Zimbra sia alice@example.com. Configura il dominio in questo modo:

zmprov md example.com zimbraAuthMech ldap

zmprov md example.com \
  zimbraAuthLdapURL "ldaps://ldap.example.net:636"

zmprov md example.com \
  zimbraAuthLdapBindDn "uid=%u,ou=people,dc=example,dc=net"

La Guida dell'amministratore descrive zimbraAuthLdapBindDncome una stringa di formato utilizzata per determinare il DN utilizzato per l'autenticazione esterna. La documentazione ufficiale del Centro assistenza tecnica di Zimbra descrive i valori di sostituzione comuni, come %uper la parte locale del nome di accesso e %nper il nome di accesso completo.

Utilizzare un modello DN solo quando identifica in modo deterministico l'oggetto directory corretto. Se gli utenti si trovano in unità organizzative diverse o il loro DN non deriva dal nome di accesso, utilizzare invece il modello di filtro di ricerca.

Passaggio 4: Utilizzare la mappatura del filtro di ricerca quando il DN non può essere costruito direttamente

La mappatura dei filtri di ricerca consente a Zimbra di individuare innanzitutto la voce dell'utente e quindi di autenticarsi rispetto al DN restituito. La Guida alla configurazione v10 definisce gli attributi di dominio necessari relativi alla ricerca.

Una tipica configurazione in stile OpenLDAP è la seguente:

zmprov md example.com \
  zimbraAuthLdapSearchBase "ou=people,dc=example,dc=net"

zmprov md example.com \
  zimbraAuthLdapSearchFilter "(uid=%u)"

zmprov md example.com \
  zimbraAuthLdapSearchBindDn \
  "cn=zimbra-search,ou=svc,dc=example,dc=net"

Per evitare di inserire la password di una directory direttamente nella cronologia della shell, è necessario prima memorizzarla in una variabile temporanea della shell:

read -s LDAP_BIND_PASSWORD
zmprov md example.com \
  zimbraAuthLdapSearchBindPassword "$LDAP_BIND_PASSWORD"
unset LDAP_BIND_PASSWORD

L'account di ricerca dovrebbe avere solo i permessi di lettura necessari per trovare gli utenti nella directory di base configurata. Non necessita di ampi privilegi di amministrazione della directory.

Per Active Directory, un filtro potrebbe utilizzare sAMAccountNameo userPrincipalName, a seconda della convenzione di accesso. Zimbra fornisce anche un meccanismo di autenticazione Active Directory esterno, quindi è consigliabile utilizzare il meccanismo specifico di AD quando si adatta meglio alla propria implementazione, anziché forzare ogni ambiente AD a utilizzare impostazioni LDAP generiche.

Passaggio 5: Verificare cosa Zimbra ha effettivamente memorizzato

Leggi gli attributi del dominio dopo la modifica:

zmprov gd example.com \
  zimbraAuthMech \
  zimbraAuthLdapURL \
  zimbraAuthLdapBindDn \
  zimbraAuthLdapSearchBase \
  zimbraAuthLdapSearchFilter \
  zimbraAuthLdapSearchBindDn \
  zimbraAuthFallbackToLocal

Verifica la presenza di errori di virgolette, un DN di base errato, un nome host inatteso o una vecchia mappatura rimasta da un tentativo precedente. Non stampare la password di search-bind nella documentazione, negli screenshot, nei ticket o nelle trascrizioni della shell.

Fase 6: Eseguire un test con un utente controllato prima del lancio su larga scala.

Scegli un account di test non amministratore che esista sia in Zimbra che nella directory esterna. Esegui i seguenti test in modo mirato:

• La password LDAP esterna corretta consente l'accesso a Zimbra.
• Una password LDAP esterna errata viene rifiutata.
• Un account di directory disabilitato o bloccato si comporta in base ai criteri di directory in vigore.
• Un account Zimbra inesistente non può accedere a meno che non sia stata configurata la funzionalità di auto-provisioning.
• Un errore del server LDAP o della rete produce il comportamento di errore previsto.

L'ultimo test è importante perché zimbraAuthFallbackToLocalè un'opzione di dominio separata. La documentazione della versione 10 afferma che il suo valore predefinito è FALSE. L'abilitazione del fallback può essere utile per una migrazione progettata con cura, ma può anche vanificare l'aspettativa che la disabilitazione o la modifica di una password nella directory esterna blocchi immediatamente l'accesso se una vecchia password locale di Zimbra rimane valida. Considera il fallback come una decisione relativa alle politiche di sicurezza, non come un interruttore generico per la risoluzione dei problemi.

Passaggio 7: Decidi se hai bisogno anche del provisioning automatico

L'autenticazione esterna e il provisioning degli account sono funzioni distinte. Se i nuovi utenti della directory devono ricevere automaticamente gli account Zimbra, è necessario configurare il provisioning automatico di Zimbra separatamente. La Guida dell'amministratore v10 documenta le modalità EAGER, LAZY e MANUAL e i relativi zimbraAutoProv*attributi.

Non riutilizzare ciecamente le impostazioni di autenticazione per il provisioning automatico. Il provisioning automatico prevede opzioni separate per URL, binding, base di ricerca, filtro, mappatura del nome account e mappatura degli attributi. Prima di tutto, rendi affidabile l'autenticazione esterna per un utente esistente; poi progetta il provisioning come una seconda modifica.

Schemi di guasto comuni e cosa controllare

Piano di annullamento

Se la configurazione della directory esterna impedisce la normale autenticazione utente, ripristinare l'autenticazione interna di Zimbra utilizzando una sessione amministratore già aperta:

zmprov md example.com zimbraAuthMech zimbra

Quindi verifica il valore:

zmprov gd example.com zimbraAuthMech

Non eliminare gli attributi LDAP esterni durante un rollback di emergenza, a meno che non vi sia un valido motivo per farlo. Mantenerli consente di analizzare più facilmente la causa dell'errore e di riprovare dopo aver corretto il mapping o il problema TLS.

Riepilogo di riferimento pratico

• zimbraAuthMech: seleziona il meccanismo di autenticazione per il dominio.
• zimbraAuthLdapURL: endpoint LDAP esterno; da utilizzare ldaps:per LDAP su SSL.
• zimbraAuthLdapBindDn: formato utilizzato per costruire il DN utente per il collegamento diretto.
• zimbraAuthLdapSearchBase: sottostruttura in cui Zimbra cerca l'utente esterno.
• zimbraAuthLdapSearchFilterFiltro LDAP utilizzato per individuare l'utente.
• zimbraAuthLdapSearchBindDne zimbraAuthLdapSearchBindPassword: credenziali utilizzate per la ricerca quando la ricerca anonima non è appropriata.
• zimbraAuthLdapExternalDn: mappatura DN esterna esplicita per un singolo account Zimbra.
• zimbraAuthFallbackToLocal: controlla se Zimbra ricorre all'autenticazione locale in caso di errore dell'autenticazione esterna.

Lista di controllo per la convalida finale

• L'endpoint LDAP esterno è raggiungibile dal server di posta elettronica Zimbra.
• La convalida del certificato TLS ha esito positivo senza ricorrere a soluzioni alternative non sicure.
• Il modello bind-DN ​​o il filtro di ricerca selezionato associa un login a una sola voce di directory.
• L'utente di test esiste in Zimbra oppure l'auto-provisioning è configurato intenzionalmente.
• I test con password corrette e non corrette si comportano come previsto.
• Il comportamento di fallback corrisponde alla tua policy di sicurezza.
• Le impostazioni di dominio originali e il comando di rollback sono documentati.

Per le modifiche in produzione, è preferibile un'implementazione graduale con un dominio di test o un piccolo gruppo di utenti. L'autenticazione LDAP esterna è semplice quando la mappatura delle identità è prevedibile; i problemi più complessi derivano dalla mappatura del DN, dalla fiducia nei certificati o dalla confusione tra autenticazione e provisioning dell'account.