Gestionez o rețea LAN cu o listă de utilizatori care accesează casele lor partajate prin NFS în timp ce sunt autentificați prin NIS/YP (clienți și servere bazate pe CentOS/Fedora).
Sunt într-un proces dureros de migrare din NIS/YP (care este eliminat treptat, dar ireversibil pe Red Hat și altele asemenea) către ceea ce părea înlocuitorul cel mai puțin dificil de configurat pentru partea de autentificare, SSSD (pentru clienții) și LDAP (pentru baza de date a utilizatorilor de pe servere).
După o serie de încercări, am ajuns la ceea ce pare a fi o configurație de funcționare acceptabilă și am început să mă gândesc la o întărire a securității, dar există ceva care mă tot eluda.
În mare parte peste tot, ACL-urile standard pentru interogarea unei baze de date LDAP pentru a autentifica utilizatorii care se conectează sunt ceva de acest fel:
olcAccess: {0}to attrs=userParola de sine stătătoare prin autorizare anonimă de * niciunul
olcAccess: {1}to attrs=shadowLastChange by self scrie prin * read
olcAccess: {2}pentru a * prin * citire
si totul functioneaza fara probleme.
Deoarece prefer să nu las utilizatorii să se uite în înregistrările celuilalt, am modificat-o pe ultima astfel:
olcAccess: {2}la * de * niciunul
Apoi am găsit „olcRequires: authc” care ar trebui să dezactiveze legăturile anonime la LDAP (pare o îmbunătățire a securității, nu?) și l-am activat și totul pare să continue.
Apoi, din nou, privind primul ACL, vedeți că autentificarea anonimă împotriva unei parole de utilizator este încă autorizată (ceea ce pare redundant dacă regula anterioară este în vigoare) și am încercat să o elimin:
olcAccess: {0}to attrs=userPassword by self =wx by * none
si nimic nu mai functioneaza.
Continuând să citesc, am descoperit că problema este că SSSD trebuie să poată interoga în mod minim baza de date pentru a prelua suficientă structură pentru a converti un nume de utilizator precum „foo” într-un nume distinctiv LDAP ca „uid=foo,ou=People,dc”. =example,dc=com' pe care LDAP îl poate procesa apoi.
Înțeleg că SSSD poate folosi un „utilizator proxy” pentru a face exact asta, așa că am adăugat un astfel de utilizator în baza mea de date, configurat SSSD să-l folosească:
ldap_default_bind_dn = cn=autobind,dc=exemplu,dc=com
ldap_default_authtok = parolă foarte secretă
și, m-am gândit, am adăugat ACL-urile necesare pentru a-l lăsa să-și facă treaba:
olcAccess: {0}to attrs=userPassword by self =wx by dn="cn=autobind,dc=example,dc=com" =x by * none
olcAccess: {1}to attrs=shadowLastChange by self write by dn="cn=autobind,dc=example,dc=com" read by * none
olcAccess: {2}to * by dn="cn=autobind,dc=example,dc=com" citit de * none
Inutil să spun că nu funcționează - nu numai pentru autentificare, ceea ce ar putea foarte bine să fie configurat greșit de SSSD, dar baza de date în sine devine indiscutabilă, returnând eroarea 49 (acreditări invalide) chiar și prin intermediul ldapsearch.
Readăugând prin autorizare anonimă îl face să funcționeze din nou; evident, este ceva ce nu înțeleg corect.
Înțeleg că nu pare mare lucru, în afară de acel „anonim” care apare în ACL-urile mele care mă enervează foarte tare, dar nu pare să poată accesa ceva important.
Deci, întrebările mele sunt: este o configurație mai sigură, în care accesul „anonim” este complet eliminat în ACL-urile pentru baza mea de date cu utilizatori LDAP, înlocuind în cele din urmă funcțiile necesare cu cele ale unui utilizator proxy specific utilizării SSSD? Dacă nu, ce ați face pentru a întări și mai mult securitatea?
