Cum se configurează autentificarea LDAP în ownCloud Infinite Scale

Ce înseamnă autentificarea LDAP în Infinite Scale?

ownCloud Infinite Scale (oCIS) autentifică sesiunile de browser și de client prin OpenID Connect (OIDC). LDAP poate furniza utilizatorii și acreditările directorului în spatele furnizorului de identitate oCIS încorporat sau poate fi utilizat în spatele unui furnizor OIDC extern, cum ar fi Keycloak. Configurația corectă depinde de nevoia de o implementare mică, cu un flux de conectare simplu, sau de o platformă de identitate de producție cu controale mai ample.

Această distincție este utilă deoarece oCIS nu este ownCloud Server Classic. Tutorialele clasice care configurează LDAP prin pagina de administrare web sau occ ldap:*nu configurează oCIS. În oCIS, setările sunt variabile de mediu de implementare sau configurația serviciilor, iar mai multe servicii pot necesita o vizualizare consistentă a aceluiași director.

Documentația serviciului IDP versionat al ownCloud precizează că furnizorul încorporat poate utiliza un backend LDAP extern. Ghidul său de securitate recomandă un furnizor OIDC extern pentru instalări mai mari sau de producție. Acest ghid utilizează documentația oCIS 8.2; verificați documentația corespunzătoare pentru versiunea instalată înainte de a aplica variabile, deoarece valorile implicite și exemplele de implementare se pot schimba.

Ce design de autentificare ar trebui să alegeți?

Dacă deja rulați Keycloak sau un alt furnizor OIDC, conectarea acestuia la director este de obicei ruta de producție mai curată. Dacă aceasta este o implementare mică și limitele furnizorului încorporat sunt acceptabile, configurați backend-ul LDAP al IDP-ului și testați-l înainte de a deschide accesul utilizatorilor.

Ce ar trebui să aduni înainte de a edita oCIS?

• Versiunea exactă oCIS și metoda de implementare, cum ar fi Docker Compose, Kubernetes sau un proces binar supervizat.
• Numele DNS al serverului LDAP, lanțul de certificate TLS și punctul final LDAPS. Se preferă ldaps://validarea certificatelor; nu dezactivați validarea pentru a ascunde o problemă de încredere.
• Un cont cu privilegii minime obligatorii și numele său distinctiv complet (DN). Contul ar trebui să poată căuta în ramurile de utilizatori și grupuri de care are nevoie oCIS, fără permisiuni de scriere inutile.
• DN-ul de bază al căutării utilizatorului, domeniul de căutare, atributul de conectare, clasa obiectului, atributele de e-mail și nume afișat și un atribut stabil de ID utilizator unic. Confirmați acestea cu intrările reale din director.
• DN-ul de bază al grupului și atributul de apartenență dacă grupurile LDAP ale utilizatorilor ar trebui să apară în oCIS.
• O copie de rezervă a configurației oCIS curente și o autentificare de administrator testată care nu depinde de modificarea LDAP.

Maparea stabilă a identității merită o atenție deosebită. Un nume afișat sau o adresă de e-mail se poate schimba; un ID unic ar trebui să rămână atașat aceleiași persoane. Dacă oCIS vede un identificator diferit după modificare, o persoană existentă poate apărea ca un cont nou în loc să moștenească identitatea și accesul așteptate.

Cum conectezi IDP-ul încorporat la un server LDAP extern?

Pentru o implementare mică care utilizează IDP-ul încorporat al oCIS, setați variabilele LDAP cu domeniul IDP în configurația mediului sau a serviciului utilizată de implementare. Valorile de mai jos sunt doar exemple. Înlocuiți numele gazdei, numerelor de nume (DN), calei certificatului și schemei cu valori din directorul dvs.

IDP_LDAP_URI=ldaps://ldap.example.net:636
IDP_LDAP_TLS_CACERT=/etc/ocis/certs/directory-ca.pem
IDP_LDAP_BIND_DN=uid=ocis-reader,ou=service,dc=example,dc=net
IDP_LDAP_BIND_PASSWORD=<load-from-your-secret-store>
IDP_LDAP_BASE_DN=ou=people,dc=example,dc=net
IDP_LDAP_SCOPE=sub
IDP_LDAP_LOGIN_ATTRIBUTE=uid
IDP_LDAP_EMAIL_ATTRIBUTE=mail
IDP_LDAP_NAME_ATTRIBUTE=displayName
IDP_LDAP_UUID_ATTRIBUTE=entryUUID
IDP_LDAP_UUID_ATTRIBUTE_TYPE=text
IDP_LDAP_OBJECTCLASS=inetOrgPerson

Referința IDP documentează aceste setări, inclusiv URI-ul, certificatul CA, DN-ul și parola de legare, DN-ul bazei de utilizatori, domeniul de aplicare, atributul de conectare, atributul UUID și clasa obiectului. Exemplul presupune că directorul oferă un text entryUUID; Active Directory și alte scheme pot necesita mapări diferite. Nu copiați entryUUIDdoar pentru că apare aici.

Stocați parola de legare ca secret de implementare sau în mecanismul secret recomandat pentru platforma dvs. Evitați să o salvați într-un fișier, depozit sau tichet public Compose. Mențineți certificatul CA lizibil de către procesul oCIS și păstrați verificarea certificatului. INSECURESetarea IDP dezactivează validarea certificatului LDAP TLS și nu este destinată în mod explicit producției.

De asemenea, potriviți comportamentul de dezactivare a contului cu directorul dvs. Documentația IDP listează IDP_USER_ENABLED_ATTRIBUTE; implicit este un nume de atribut specific ownCloud. Dacă directorul dvs. utilizează un alt indicator de activare/dezactivare, mapați acel atribut real. Examinați USERS_LDAP_DISABLE_USER_MECHANISMși serviciile utilizatorilor. În funcție de director, opțiunile documentate sunt gestionarea bazată pe atribute, gestionarea bazată pe grupuri sau none; alegeți în mod deliberat, astfel încât un cont dezactivat să nu fie tratat ca activ din cauza unei nepotriviri de schemă.

Căutările de utilizatori și grupuri necesită și setări LDAP?

Adesea, da. Verificarea cu succes a parolei și descoperirea utilizatorilor sunt sarcini corelate, dar separate. IDP-ul autentifică datele de conectare; utilizatorii oCIS și serviciile Graph furnizează informații despre utilizatori și grupuri platformei. Dacă utilizați un director extern ca sursă de identitate a oCIS, configurați backend-urile utilizatorilor și Graph LDAP pentru a citi același director și a mapa aceiași utilizatori în mod consecvent.

Pentru serviciul utilizatori, examinați USERS_DRIVER=ldapși setările sale la nivel de serviciu, cum ar fi USERS_LDAP_URI, USERS_LDAP_CACERT, USERS_LDAP_BIND_DN, USERS_LDAP_BIND_PASSWORD, USERS_LDAP_USER_BASE_DN, USERS_LDAP_USER_SCHEMA_ID, și USERS_LDAP_USER_SCHEMA_USERNAME. Setați variabilele de e-mail, nume afișat, domeniu și grup atunci când implementarea le necesită. Numele exacte ale schemei trebuie să corespundă directorului, nu unui exemplu generic.

Serviciul Graph are propriile setări LDAP. Pentru un director existent pe care oCIS ar trebui să îl citească fără a-l gestiona, setați GRAPH_LDAP_SERVER_WRITE_ENABLED=falseși configurați conexiunea și schema LDAP Graph. ownCloud documentează acest lucru ca model doar de citire pentru conectarea la un server LDAP existent. Lăsați scrierile dezactivate, cu excepția cazului în care ați pregătit în mod deliberat o schemă LDAP compatibilă și doriți ca oCIS să creeze sau să modifice obiecte de director.

Folosiți cu atenție prefixele variabilelor specifice serviciului sau OCIS_LDAP_*variabilele globale documentate. Variabilele globale pot afecta mai multe servicii simultan. Pentru o primă integrare, setările explicite per serviciu facilitează identificarea serviciului care eșuează și previn o presupunere neintenționată de scriere sau schemă. Referința serviciului utilizatorului și referința serviciului Graph listează numele și valorile implicite specifice versiunii.

Cum aplici setările în siguranță?

1. Salvați o copie a fișierului de mediu curent, a unității de serviciu sau a configurației Compose. Înregistrați cum să o anulați.
2. Adăugați variabilele LDAP la definiția serviciului oCIS propriu-zis. Nu înlocuiți restul unui bloc de mediu Compose existent cu acest exemplu; îmbinați setările în implementarea pe care o rulați deja.
3. Verificați dacă fișierul certificat există în interiorul containerului sau al spațiului de nume al gazdei unde serviciul oCIS îl citește. O cale către gazdă nu este vizibilă automat în interiorul unui container.
4. Validați contul de legătură și baza de căutare în funcție de LDAP înainte de a reporni oCIS. Folosiți același nume de gazdă al serverului, același DN de bază și același atribut de conectare configurat pentru serviciu.
5. Reporniți oCIS folosind procesul normal al implementării, astfel încât serviciile să primească noul mediu. Într-o implementare cu mai multe servicii sau mai multe noduri, confirmați că serviciile relevante de pe fiecare instanță utilizează configurația dorită.
6. Testați cu un cont LDAP permis și un cont care nu ar trebui să se conecteze. Mențineți deschisă o sesiune de administrator existentă până când noua cale de conectare a fost verificată.

Pentru o verificare directă a directorului, ldapsearchputeți testa filtrul de bind și de utilizator fără a introduce parola în linia de comandă:

ldapsearch -H ldaps://ldap.example.net:636 \
  -D 'uid=ocis-reader,ou=service,dc=example,dc=net' -W \
  -b 'ou=people,dc=example,dc=net' '(uid=alice)' dn uid entryUUID mail

Folosește atributul de conectare și DN-ul de bază pe care intenționezi să le configurezi. O interogare reușită confirmă comportamentul rețelei, TLS, al legăturii și al căutării pentru interogarea respectivă; nu dovedește că fiecare serviciu oCIS utilizează aceeași mapare.

De unde știi că configurația funcționează?

Evaluați rezultatul în funcție de mai multe aspecte decât simpla apariție a unei pagini de conectare. Conectați-vă prin fluxul web oCIS normal cu un utilizator de director de testare, deschideți un fișier și confirmați numele de utilizator și detaliile profilului așteptate. Dacă grupurile gestionează partajări sau acces la spațiu, verificați și un membru cunoscut al unui grup. Apoi, testați o parolă greșită și un cont LDAP care este dezactivat sau în afara căutării de utilizatori permise. Aceste conturi nu ar trebui să aibă acces.

Verificați jurnalele de servicii oCIS pentru erori de conexiune LDAP, TLS, legare și căutare utilizator. O legare LDAP validă urmată de o autentificare oCIS eșuată indică adesea o nepotrivire de filtru de căutare, DN de bază, identificator de utilizator sau mapare OIDC-utilizator. Într-un pilot de producție, verificați fișierele, partajările și accesul bazat pe grup al unui utilizator existent înainte de a migra un grup mai mare. O verificare de autentificare reușită nu verifică singură dacă identitatea și autorizarea contului existent au fost păstrate.

Ce ar trebui să schimbi dacă autentificarea tot eșuează?

• Erori TLS sau de conexiune: Confirmați că gazda oCIS rezolvă problema și ajunge la serverul LDAP, că portul și schema se potrivesc și că fișierul CA conține lanțul de certificate emitente. Mențineți verificarea activată.
• Legarea a reușit, dar nu a fost găsit niciun utilizator: Testați DN-ul exact al bazei de utilizatori, domeniul de aplicare, clasa obiectului, atributul de conectare și filtrul. Un DN de legare corect nu implică faptul că căutarea se face în ramura corectă.
• LDAP acceptă parola, dar oCIS nu poate rezolva problema contului: Comparați identificatorul de conectare IDP și numele de utilizator al serviciului utilizatorilor sau maparea stabilă a ID-ului. Păstrați un identificator stabil și nu treceți de la numele de utilizator la adresa de e-mail în mod aleatoriu.
• Autentificarea funcționează, dar accesul bazat pe grup este greșit: Verificați utilizatorii și numele de utilizator de bază al grupului Graph, clasa obiectului de grup, atributul membrului și dacă backend-ul Graph este configurat doar pentru citire sau pentru scriere, așa cum este prevăzut.
• Aveți nevoie de MFA, sesiuni centralizate sau controale de identitate mai ample: Mutați autentificarea LDAP la un furnizor OIDC extern și configurați oCIS să aibă încredere în emitentul respectiv. IDP-ul încorporat este limitat în mod intenționat; ownCloud recomandă un furnizor extern pentru instalări mai mari și observă că furnizorul încorporat nu oferă toate capacitățile unui serviciu de identitate extern.

Nu activați PROXY_ENABLE_BASIC_AUTHca scurtătură pentru conectarea la un browser de producție. Documentația proxy listează Autentificarea de bază ca o schemă de solicitare acceptată, dar specifică utilizarea acesteia doar pentru dezvoltare, nu pentru producție. Pentru conectarea standard la oCIS, utilizați furnizorul OIDC încorporat numai acolo unde se încadrează limitele sale sau conectați un furnizor de identitate OIDC extern susținut de LDAP.

Ce este în afara acestei configurații?

Autentificarea LDAP nu face automat disponibile toate funcțiile administrative LDAP în oCIS. Provisionarea utilizatorilor și grupurilor, sincronizarea grupurilor, accesul la scriere, modificările parolelor, regulile pentru conturile dezactivate și maparea utilizatorilor existenți necesită propriile setări de servicii compatibile și o schemă LDAP. Pentru auto-provisionarea OIDC externă, ownCloud necesită, de asemenea, o revendicare de utilizator stabilă și un backend Graph activat pentru scriere atunci când fluxul ales creează conturi. Consultați documentația proxy înainte de a activa acest comportament.

Faceți o modificare pe rând, testați cu un set mic de conturi și confirmați atât autentificarea, cât și maparea identității înainte de implementarea pe scară largă. Dacă versiunea oCIS, schema LDAP sau furnizorul de identitate diferă de ipotezele din exemplu, urmați exact referința de configurare a acelei versiuni, în loc să reutilizați exemplul nemodificat.