Autentificarea LDAP din OpenVPN funcționează, dar verificarea grupului eșuează: unde să te uiți

Autentificarea poate trece în timp ce verificarea grupului respinge pe toată lumea. Parcurge pe rând blocul Authorization, atributul de apartenență și punctul final al directorului.

Datele de autentificare trec, tunelul începe să urce, iar apoi sesiunea eșuează cu un mesaj despre grup și nu despre parolă. Această combinație plasează defectul în a doua jumătate a muncii pluginului LDAP: legarea și verificarea parolei au reușit, iar decizia de apartenență care urmează nu. Ambele jumătăți citesc din același bloc de configurare, de aceea o corectare într-un loc poate lăsa cealaltă neatinsă. Începe cu linia de jurnal care numește pasul, nu cu contul cu care testezi din întâmplare.

Tratează respingerea ca pe un răspuns de autorizare

Pluginul efectuează o legare de serviciu, caută contul, verifică parola furnizată și apoi întreabă dacă acel cont aparține unui grup permis. Sunt patru operațiuni distincte, și doar ultima este despre grupuri. Așadar o respingere care sosește după o legare reușită nu spune nimic despre parolă, chiar și când clientul afișează o eroare generică de autentificare. Ridicarea nivelului de jurnal al pluginului înainte de a schimba configurarea este ceea ce le separă pe cele patru în ieșire.

Caută evaluarea grupului însăși. Când nu apare deloc nicio interogare de grup, blocul de autorizare nu este atins, ceea ce înseamnă de obicei că o directivă stă în afara blocului care o deține sau că lipsește o opțiune obligatorie. Când interogarea apare și nu returnează nimic, punctul final sau filtrul răspunde la o altă întrebare decât cea pe care o aveai în minte.

Decide dacă apartenența trăiește în filtru sau într-un bloc de grup

Există două forme acceptate, iar amestecarea lor este modul în care o configurare funcțională încetează să funcționeze. Prima împinge apartenența în căutarea utilizatorilor cerând un atribut pe obiectul utilizator; a doua lasă căutarea utilizatorilor în pace și îl lasă pe plugin să caute obiectul de grup după aceea. Alege una pentru fiecare implementare și notează pe care ai ales-o.

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(&(sAMAccountName=%u)(memberOf=CN=VPN Access,OU=Groups,DC=example,DC=org))"
    RequireGroup false
</Authorization>

Cu acea formă filtrul decide totul, așa că RequireGroup trebuie să fie false, altfel pluginul pleacă să caute un obiect de grup pe care filtrul nu l-a menționat niciodată. Atributul din filtru trebuie să existe pe obiectul utilizator și să fie completat, ceea ce nu este garantat odată ce grupurile sunt imbricate.

Cealaltă formă păstrează căutarea simplă și adaugă o căutare de grup după ea. Obiectul de grup este numit explicit, iar pluginul compară utilizatorul cu membrii pe care directorul îi returnează pentru el. Nimic din filtrul de utilizator nu se schimbă, ceea ce face această formă mai ușor de auditat când grupul este administrat de altă echipă.

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(sAMAccountName=%u)"
    RequireGroup true
    Group        "CN=VPN Access,OU=Groups,DC=example,DC=org"
</Authorization>

Punctul orb este comun: o comparație simplă de apartenență nu extinde grupurile imbricate, așa că un cont al cărui acces vine printr-un grup părinte eșuează în timp ce consola arată în continuare apartenența. Active Directory expune member pe grup, alte scheme folosesc uniqueMember, iar indicarea atributului greșit returnează un rezultat gol în loc de o eroare.

Alege un punct final care conține obiectul de grup

URL-ul decide cărui director îi adresează întrebarea pluginul, iar un controler de domeniu pe portul 389 răspunde doar pentru propriul context de nume. Un catalog global pe portul 3268 răspunde pentru întreaga pădure, doar în citire și cu un set parțial de atribute. Când conturile sunt într-un domeniu, iar grupul VPN în altul, o interogare pe un singur domeniu poate găsi utilizatorul și totuși rata apartenența. Acesta este cazul în care mutarea URL-ului pe portul catalogului rezolvă respingerea, și este totodată cazul în care oamenii generalizează prea mult.

Setul parțial de atribute este limita: un atribut pe care catalogul nu îl conține nu poate fi filtrat, așa că aceeași modificare poate face o implementare să funcționeze și alta să returneze nimic. Confirmă ce returnează punctul final pentru utilizatorul și grupul reale înainte de a rescrie blocul. Referințele și TLS sunt din nou subiecte separate, fiindcă o referință trebuie urmată, iar un punct final care cere TLS are nevoie de fișierele de încredere potrivite.

Ține starea contului și aria de căutare în câmpurile lor

Marcajul de dezactivare aparține filtrului, nu verificării grupului. În Active Directory este al doilea bit al userAccountControl, iar fără această condiție un cont dezactivat cu o parolă validă se autentifică și apoi eșuează la pasul grupului, ceea ce arată ca un defect de autorizare. Aria de căutare aparține DN-ului de bază, fiindcă pornirea din rădăcina domeniului este mai lentă și poate potrivi obiecte din afara unității organizaționale pe care voiai să o acoperi.

Ține înguste și drepturile contului de legare. Drepturile largi în director transformă un filtru configurat greșit într-o interogare reușită și ascund defectul până când cineva auditează contul. Schimbă apartenența în directorul însuși, niciodată într-o listă locală de excepții, astfel încât dezactivarea contului să fie suficientă pentru a elimina accesul. Dacă altă echipă administrează grupul, conveniți asupra atributului pe care îl completează înainte de a scrie un filtru pe el.

Dovedește rezultatul cu trei conturi

Rulează configurarea împotriva a trei identități: un membru permis, un cont valid din afara grupului și un cont care a fost dezactivat. Dacă toate trei sunt respinse, legarea sau interogarea de grup sunt stricate; dacă toate trei sunt acceptate, nu se aplică nicio condiție de grup. Un rezultat mixt este singurul care dovedește că configurarea distinge cazurile care contează pentru tine.

Citește aceleași trei răspunsuri direct din director înainte de a da vina pe plugin. Prima interogare arată atributul de grup de care depinde filtrul, iar a doua arată valoarea de control al contului. Înlocuiește cu propriul DN de bază, cont și punct final:

ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=alice)" memberOf
ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=bob)" userAccountControl

Un utilizator al cărui memberOf se întoarce gol este un fapt al directorului, nu un defect al pluginului, iar un cont care se autentifică în continuare după dezactivare înseamnă că filtrului îi lipsește condiția de control al contului. Corectează mai întâi acea dovadă, apoi rulează din nou testul cu trei conturi. Ține linia de jurnal care a numit pasul eșuat lângă modificarea de configurare, astfel încât următoarea persoană să poată separa autorizarea de autentificare fără a repeta căutarea.

Articole similare