Cum se configurează autentificarea LDAP externă pentru Zimbra

Ce modificări ale autentificării LDAP externe în Zimbra

Autentificarea LDAP externă permite Zimbra să verifice parola unui utilizator în raport cu un alt director, în loc de parola stocată în LDAP-ul intern al Zimbra. Ghidul actual al administratorului Zimbra Daffodil (v10) precizează că autentificarea LDAP externă este configurată per domeniu și că metoda externă încearcă să se lege la directorul specificat cu acreditările utilizatorului furnizate. Dacă legarea reușește, parola este considerată validă.

Aceasta nu transformă automat un director LDAP extern în baza de date de conturi Zimbra. Zimbra stochează în continuare datele contului specifice Zimbra în propriul director. Ghidul v10 menționează în mod explicit că utilizatorii trebuie în mod normal să existe atât în ​​Zimbra, cât și în directorul extern, cu excepția cazului în care configurați separat aprovizionarea automată.

Pentru documentația curentă a produsului, consultați Ghidul administratorului Zimbra Daffodil v10 și Ghidul de configurare Zimbra v10 .

Listă de verificare rapidă pentru planificare

• Confirmați domeniul Zimbra pe care doriți să îl modificați, de exemplu example.com.
• Confirmați că aceiași utilizatori există deja în Zimbra sau planificați separat aprovizionarea automată.
• Cunoașteți numele de gazdă LDAP extern, portul, metoda TLS și lanțul de certificate.
• Aflați cum un nume de utilizator Zimbra se mapează cu un DN de utilizator în LDAP.
• Dacă DN-ul nu poate fi construit direct din numele de utilizator, pregătiți o bază de căutare, un filtru de căutare și un cont de căutare cu cele mai puține privilegii.
• Păstrați o sesiune de administrator Zimbra deschisă în timpul testării, pentru a putea reveni rapid la versiunea inițială.

Alegeți mai întâi metoda de cartografiere potrivită

Ghidul de configurare v10 actual definește în continuare atributele search-base, search-bind, search-filter și per-account external-DN. Materialele oficiale mai vechi ale Centrului Tehnic Zimbra explică modul în care aceste mapări sunt utilizate în practică. Deoarece materialul respectiv este anterior versiunii Daffodil, tratați-l ca fundal operațional și verificați detaliile în raport cu versiunea instalată înainte de a aplica o migrare extinsă. Consultați notele oficiale LDAP externe ale Centrului Tehnic Zimbra .

Pasul 1: Înregistrați setările curente de autentificare a domeniului

Executați comenzi administrative ca zimbrautilizator al sistemului de operare. Înainte de a modifica orice, capturați valorile existente ale domeniului:

su - zimbra

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

Salvați rezultatul în înregistrarea modificărilor. Ghidul de configurare v10 listează valori valide pentru zimbraAuthMech, inclusiv zimbra, ldap, adși Kerberos sau mecanisme personalizate. Pentru acest ghid, mecanismul țintă este ldap.

Pasul 2: Verificați accesibilitatea rețelei și TLS înainte de a schimba Zimbra

Nu depanați mapările de autentificare până când nu se știe că funcționează conectivitatea de bază. De pe serverul Zimbra, confirmați rezoluția DNS și că endpoint-ul LDAP este accesibil. Pentru LDAPS, puteți inspecta lanțul de certificate cu OpenSSL:

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

Pentru un director care utilizează LDAP standard plus StartTLS, testați endpoint-ul compatibil cu StartTLS cu un client LDAP adecvat sistemului dvs. de operare. Dacă ldapsearcheste instalat, o verificare a contului de căutare poate arăta astfel:

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

Ghidul administratorului Zimbra v10 precizează că un ldaps:endpoint necesită ca certificatul serverului LDAP să fie considerat de încredere de către Zimbra. Nu ocoliți validarea certificatului doar pentru a trece testul. Instalați CA-ul sau lanțul de certificate corespunzător conform procedurii de stocare a informațiilor de încredere pentru versiunea exactă a Zimbra.

Pasul 3: Configurați un șablon DN de legare directă atunci când DN-urile utilizatorilor sunt previzibile

Acesta este cel mai simplu model. Să presupunem că directorul extern stochează utilizatorii ca uid=alice,ou=people,dc=example,dc=netși datele de autentificare Zimbra sunt alice@example.com. Configurați domeniul astfel:

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"

Ghidul administratorului descrie zimbraAuthLdapBindDnun șir de format utilizat pentru a determina DN-ul utilizat pentru legarea externă. Documentația oficială a Centrului Tehnic Zimbra descrie valori de substituție comune, cum ar fi %upentru partea locală a numelui de utilizator și %npentru numele de utilizator complet.

Folosește un șablon DN numai atunci când acesta identifică în mod determinist obiectul director corect. Dacă utilizatorii se află în unități organizaționale diferite sau DN-ul lor nu este derivat din numele de utilizator, folosește în schimb modelul de filtru de căutare.

Pasul 4: Utilizați maparea filtrului de căutare atunci când DN-ul nu poate fi construit direct

Maparea filtrelor de căutare permite Zimbra să localizeze mai întâi intrarea utilizatorului, apoi să se autentifice în funcție de DN-ul returnat. Ghidul de configurare v10 definește atributele de domeniu necesare legate de căutare.

O configurație tipică în stil OpenLDAP este:

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"

Pentru a evita introducerea unei parole de director direct în istoricul shell-ului, citiți-o mai întâi într-o variabilă shell temporară:

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

Contul de căutare ar trebui să aibă doar accesul de citire necesar pentru a găsi utilizatori în baza configurată. Nu necesită privilegii extinse de administrare a directoarelor.

Pentru Active Directory, un filtru ar putea utiliza sAMAccountNamesau userPrincipalName, în funcție de convenția de conectare. Zimbra oferă, de asemenea, un mecanism extern de autentificare Active Directory, așadar utilizați mecanismul specific AD atunci când se potrivește mai bine implementării dvs., în loc să forțați fiecare mediu AD prin setări LDAP generice.

Pasul 5: Verificați ce a stocat efectiv Zimbra

Citiți atributele domeniului după modificare:

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

Verificați dacă există greșeli de citare, un DN de bază incorect, un nume de gazdă neașteptat sau o mapare veche rămasă de la o încercare anterioară. Nu afișați parola search-bind în documentație, capturi de ecran, tichete sau transcrieri shell.

Pasul 6: Testați cu un utilizator controlat înainte de lansarea pe scară largă

Alegeți un cont de testare non-administrator care există atât în ​​Zimbra, cât și în directorul extern. Testați aceste cazuri în mod deliberat:

• Parola LDAP externă corectă permite conectarea la Zimbra.
• O parolă LDAP externă incorectă este respinsă.
• Un cont de director dezactivat sau blocat se comportă conform politicii dvs. de director.
• Un cont Zimbra care nu există nu se poate conecta decât dacă a fost configurată aprovizionarea automată.
• O eroare a serverului LDAP sau a rețelei produce comportamentul de eroare așteptat.

Ultimul test contează deoarece zimbraAuthFallbackToLocaleste o opțiune separată pentru domeniu. Documentația v10 precizează că valoarea implicită este FALSE. Activarea opțiunii de rezervă poate fi utilă pentru o migrare atent concepută, dar poate, de asemenea, să elimine așteptarea că dezactivarea sau modificarea unei parole în directorul extern blochează imediat accesul dacă o parolă Zimbra locală veche rămâne validă. Tratați opțiunea de rezervă ca pe o decizie de politică de securitate, nu ca pe o opțiune generică de depanare.

Pasul 7: Decideți dacă aveți nevoie și de aprovizionare automată

Autentificarea externă și furnizarea de conturi sunt funcții diferite. Dacă noii utilizatori ai directorului ar trebui să primească automat conturi Zimbra, configurați separat furnizarea automată Zimbra. Ghidul administratorului v10 actual documentează modurile EAGER, LAZY și MANUAL și propriile zimbraAutoProv*atribute.

Nu reutilizați setările de autentificare orbește pentru aprovizionarea automată. Aprovizionarea automată are opțiuni separate pentru URL, legătură, bază de căutare, filtru, mapare nume cont și mapare atribute. Mai întâi, asigurați fiabilitatea autentificării externe pentru un utilizator existent; apoi proiectați aprovizionarea ca o a doua modificare.

Modele comune de defecțiuni și ce trebuie verificat

Plan de revenire

Dacă configurația directorului extern împiedică autentificarea normală a utilizatorilor, comutați domeniul înapoi la autentificarea internă Zimbra utilizând o sesiune de administrator deja deschisă:

zmprov md example.com zimbraAuthMech zimbra

Apoi verificați valoarea:

zmprov gd example.com zimbraAuthMech

Nu ștergeți atributele LDAP externe în timpul unei reveniri de urgență decât dacă aveți un motiv anume. Păstrarea lor facilitează inspectarea erorilor și reîncercarea după corectarea problemei de mapare sau TLS.

Rezumat de referințe practice

• zimbraAuthMech: selectează mecanismul de autentificare pentru domeniu.
• zimbraAuthLdapURL: punct final LDAP extern; se utilizează ldaps:pentru LDAP prin SSL.
• zimbraAuthLdapBindDn: format folosit pentru a construi DN-ul utilizatorului pentru legare directă.
• zimbraAuthLdapSearchBase: subarbore în care Zimbra caută utilizatorul extern.
• zimbraAuthLdapSearchFilterFiltru LDAP folosit pentru localizarea utilizatorului.
• zimbraAuthLdapSearchBindDnși zimbraAuthLdapSearchBindPassword: acreditările utilizate pentru căutare atunci când căutarea anonimă nu este potrivită.
• zimbraAuthLdapExternalDnmapare DN externă explicită pentru un singur cont Zimbra.
• zimbraAuthFallbackToLocal: controlează dacă Zimbra revine la autentificarea locală în cazul în care autentificarea externă eșuează.

Lista de verificare finală pentru validare

• Punctul final LDAP extern este accesibil de pe serverul de cutii poștale Zimbra.
• Validarea certificatului TLS are succes fără soluții alternative nesigure.
• Șablonul bind-DN ​​sau filtrul de căutare ales mapează o singură intrare în director.
• Utilizatorul de test există în Zimbra sau aprovizionarea automată este configurată intenționat.
• Testele pentru parole corecte și incorecte se comportă conform așteptărilor.
• Comportamentul de rezervă corespunde politicii dvs. de securitate.
• Setările originale ale domeniului și comanda de rollback sunt documentate.

Pentru modificările de producție, este de preferat o implementare în etape, cu un singur domeniu de testare sau un grup mic de utilizatori. Autentificarea LDAP externă este simplă atunci când maparea identității este previzibilă; cele mai dificile eșecuri provin din maparea DN, încrederea în certificate sau confuzia dintre autentificare și furnizarea contului.