Documentazione<Precedenti | Contenuti | Succ.>
1.7. Controllo degli accessi
La gestione del tipo di accesso (lettura, scrittura, ecc.) agli utenti dovrebbe essere concesso alle risorse è nota come
controllo di accesso. Le direttive di configurazione coinvolte sono chiamate elenchi di controllo di accesso o ACL.
Quando abbiamo installato il pacchetto slapd, vari ACL sono stati impostati automaticamente. Esamineremo alcune importanti conseguenze di tali impostazioni predefinite e, così facendo, avremo un'idea di come funzionano gli ACL e di come sono configurati.
Per ottenere l'ACL effettivo per una query LDAP, è necessario esaminare le voci ACL del database interrogato e quelle dell'istanza del database frontend speciale. Gli ACL appartenenti a quest'ultimo fungono da default nel caso in cui quelli del primo non corrispondano. Il database frontend è il secondo ad essere consultato e l'ACL da applicare è il primo a trovare corrispondenza ("first match wins") tra queste 2 sorgenti ACL. I seguenti comandi forniranno, rispettivamente, gli ACL del database mdb ("dc=example,dc=com") e quelli del database frontend:
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcDatabase={1}mdb)' olcAccess
dn: olcDatabase={1}mdb,cn=config
olcAccess: {0}to attrs=userPassword da auto scrivi da autenticazione anonima da * nessuno olcAccess: {1}to attrs=shadowLastChange da auto scrivi da * leggi
olcAccess: {2}a * di * letto
Il rootDN ha sempre tutti i diritti sul suo database e non ha bisogno di essere incluso in nessun ACL.
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcDatabase={-1}frontend)' olcAccess
dn: olcDatabase={-1}frontend,cn=config
olcAccess: {0}to * di dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
,cn=auth Manage by * break
olcAccess: {1}to dn.exact="" di * read
olcAccess: {2}to dn.base="cn=Subschema" di * read
I primi due ACL sono cruciali:
olcAccess: {0}to attrs=userPassword da auto scrivi da autenticazione anonima da * nessuno olcAccess: {1}to attrs=shadowLastChange da auto scrivi da * leggi
Questo può essere rappresentato in modo diverso per una più facile digestione:
attrs=userPassword
da solo scrivere
per autenticazione anonima per * none
to attrs=shadowLastChange tramite autoscrittura
da * leggi
Questi ACL impongono quanto segue:
• L'accesso anonimo 'autorizza' è fornito al password utente attributo in modo che gli utenti possano autenticarsi, o legare. Forse controintuitivamente, è necessario "per autenticazione anonima" anche quando l'accesso anonimo al DIT è indesiderato, altrimenti questo sarebbe un problema di gallina e uova: prima dell'autenticazione, tutti gli utenti sono anonimi.
• Il da solo scrivere ACL concede l'accesso in scrittura al password utente attribuire agli utenti che si sono autenticati come dn dove vive l'attributo. In altre parole, gli utenti possono aggiornare il password utente attributo delle proprie voci.
• Il password utente L'attributo è altrimenti inaccessibile da tutti gli altri utenti, ad eccezione del rootDN, che ha sempre l'accesso e non ha bisogno di essere menzionato esplicitamente.
• Affinché gli utenti possano modificare la propria password, utilizzando passwd o altre utilità, proprie dell'utente ombraUltima modifica l'attributo deve essere scrivibile. Tutti gli altri utenti della directory possono leggere il contenuto di questo attributo.
Questo DIT può essere cercato in modo anonimo a causa di 'to * by * read' in questo ACL, che garantisce l'accesso in lettura a tutto il resto, da chiunque (incluso l'anonimo):
a *
da * leggi
Se ciò non è desiderato, è necessario modificare gli ACL. Per forzare l'autenticazione durante una richiesta di collegamento è possibile in alternativa (o in combinazione con l'ACL modificato) utilizzare la direttiva 'olcRequire: authc'.
Come accennato in precedenza, non esiste un account amministrativo ("rootDN") creato per il database slapd-config. Esiste, tuttavia, un'identità SASL a cui è concesso l'accesso completo. Rappresenta il superutente del localhost (root/ sudo). Ecco qui:
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=esterno,cn=auth
Il seguente comando visualizzerà gli ACL del database slapd-config:
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcDatabase={0}config)' olcAccess
dn: olcDatabase={0}config,cn=config
olcAccess: {0}a * da dn.exact=gidNumber=0+uidNumber=0,cn=peercred, cn=esterno,cn=auth gestisci da * break
Poiché si tratta di un'identità SASL, è necessario utilizzare un SASL meccanismo quando si invoca l'utility LDAP in questione e l'abbiamo vista molte volte in questa guida. È il meccanismo ESTERNO. Vedere il comando precedente per un esempio. Notare che:
1. Devi usare sudo per diventare l'identità radice affinché l'ACL corrisponda.
2. Il meccanismo ESTERNO funziona tramite IPC (Socket di dominio UNIX). Ciò significa che è necessario utilizzare il ldapi
formato dell'URI.
Un modo succinto per ottenere tutti gli ACL è il seguente:
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcAccess=*)' olcAccess olcSuffix
C'è molto da dire sul tema del controllo degli accessi. Vedi la pagina man di slapd.access4.