Uso di LDAP su Debian GNU/Linux.

Uso di LDAP su Debian GNU/Linux. Simone Piccardi 28 settembre 2002 Copyright c 2002 Simone Piccardi. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections being, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. i

INDICE iii Indice 1 Prefazione. 1 2 Introduzione. 1 3 Installazione 1 3.1 Ricompilazione dei pacchetti per il supporto TLS/SSL............... 2 3.2 Installazione dei pacchetti............................... 2 3.3 Considerazioni finali.................................. 5 4 Configurazione 5 4.1 La creazione dei certificati............................... 6 4.2 La configurazione lato server............................. 9 4.3 La configurazione lato client.............................. 9 4.4 L infrastruttura di base dell elenco.......................... 11 5 La migrazione del Name Service Switch 12 5.1 Introduzione....................................... 12 5.2 Il file di hosts..................................... 13 5.3 L autententicazione................................... 15 5.4 La migrazione di utenti e gruppi........................... 16

1 1 Prefazione. Ci si può chiedere quale sia il senso di scrivere un ennesimo documento sull uso di LDAP, vista la mole di materiale disponibile in rete (si contano decine di testi, fra HOWTO, manuali ed materiale vario, che coprono gli aspetti più vari). La ragione è una sola, ed esattamente quella riportata sopra: la frammentazione delle informazioni, ed il fatto che non ne ho trovato uno solo che riportasse tutto quello che mi serviva. Per cui, visto che mi sono trovato a dover cercare più volte informazioni sparse qua e là, ho pensato di raccoglierle in questo testo, in modo da non dover ripetere la ricerca, e tener traccia delle esperienze acquisite, essere d aiuto a qualcun altro, e mettere a disposizione qualcosa scritto in italiano. L impostazione del documento è poco più di una descrizione di quanto fatto nel mettere su un server LDAP che servisse a scopi di autenticazione. Il sistema utilizzato è una Debian GNU/Linux, versione stabile (woody). Benché buona parte delle istruzioni siano applicabili anche ad altre distribuzioni, tutto quello che riguarda l installazione dei pacchetti è specifico di Debian. Purtroppo non ho tempo di rendere le istruzioni generiche (usare Debian ed apt rende molto più semplice il procedimento di installazione), se qualcuno vuole contribuire è il benvenuto. 2 Introduzione. LDAP è l acronimo di Lightweight Directory Access Protocol; si tratta di un protocollo che permette di accedere ad un servizio di elenco 1 in versione elettronica, analogo a quello che potrebbe essere un elenco telefonico, ma generalizzato nei contenuti. I servizi di elenco sono stati standardizzati a livello internazionale nello standard X.500, che prevede sia un modello di dati che un protocollo di accesso (il DAP, da Directory Access Protocol). LDAP parte dal modello di dati di X.500 ma implementa un protocollo di accesso semplificato basato su TCP/IP, che è stato standardizzato dall RFC2251. Un elenco è abbastanza simile ad un database; le informazioni sono però memorizzate in forma descrittiva, ed associate a specifici attributi che sono organizzati ad albero, a partire da una radice (di formato standardizzato) che identifica ogni elenco. L albero è costruito su una serie di classi (che sono a loro volta voci all interno dell elenco) al cui interno è possibile inserire ulteriori dati. Il protocollo permette in questa maniera di suddividere le informazioni in maniera gerarchica, ed eventualmente di tenerle separate su diversi alberi, che in generale possono stare su server diversi, gestendo in maniera naturale la distribuzione dei dati. Infine un elenco LDAP è ottimizzato per fornire risposte rapide in lettura, può essere facilmente replicato, e supporta la distribuzione del carico. Per questo il protocollo, contrariamente a quanto è richiesto per i database, considera come accettabili delle inconsistenze temporanee nelle informazioni. 3 Installazione Questa sezione è specifica al sistema da me usato, cioè Debian GNU/Linux, e copre la sezione relativa all installazione di LDAP, ed in particolare copre la ricompilazione dei pacchetti per il supporto TLS/SSL ed l installazione attraverso debconf. 1 non ho trovato una traduzione migliore del termine directory in questo contesto.

2 3 INSTALLAZIONE 3.1 Ricompilazione dei pacchetti per il supporto TLS/SSL Alcune distribuzioni hanno i pacchetti di LDAP già compilati con il supporto per TSL/SSL, in Debian ad oggi non è così pertanto il primo passo da fare è quello di ricompilare OpenLDAP con il supporto per TLS/SSL. 2 Per abilitare il supporto per TLS/SSL occorre specificare l opzione --with-tls in fase di configurazione, la procedura di installazione dai sorgenti è coperta dalle istruzioni ad essi allegate, usando Debian però è più naturale utilizzare i pacchetti sorgente già pronti, in modo di avere pacchetti perfettamente compatibili con il resto della distribuzione. La procedura è piuttosto semplice, anzitutto occorre avere inserito le righe relative ai pacchetti sorgente in /etc/apt/source.lists; queste sono identiche a quelle dei corrispondenti binari, salvo per il fatto che iniziano con deb-src invece che con deb. Per scaricare la versione corrente dei pacchetti sorgente di LDAP occorre eseguire il comando: [root@havnor software]# apt-get source openldap2 che contiene i sorgenti di tutto LDAP, i pacchetti binari sono stati spezzettati in diversi file. Si faccia attenzione a specificare openldap2, dato che openldap è un altro pacchetto che carica la vecchia release 1.x di OpenLDAP. Il comando provvederà a scaricare i file necessari ed a scompattare i sorgenti applicando le patch per Debian; alla fine si troveranno i sorgenti pronti per la compilazione in una directory openldap2-2.0.23 (o quella che è la versione versione usata) nella directory in cui si è eseguito il comando. A questo punto per abilitare TLS/SSL occorre entrare nella directory dei sorgenti e modificare il file debian/rules in detta directory, cambiando l opzione --without-tls in --with-tls nelle righe iniziali in cui sono specificate tutte le opzioni di compilazione; si poi si potrà ricompilare tutto, tornando nella directory di partenza, con: [root@havnor software]# apt-get source openldap2 --compile questo comando genererà i seguenti pacchetti binari: libldap2 2.0.23-9 i386.deb contiene la libreria usata da qualunque client per accedere ad un server con il protocollo LDAP. ldap-utils 2.0.23-9 i386.deb contiene i programmi usati sul lato client per leggere e modificare le informazioni memorizzate su un server LDAP. slapd 2.0.23-9 i386.deb è il server LDAP vero e proprio. ldap-gateways 2.0.23-9 i386.deb contiene vari programmi per l invio di posta, fax ed altro usando i dati del server LDAP. libldap2-dev 2.0.23-9 i386.deb contiene gli header file e quanto necessario per compilare programmi che usano la libreria libldap2. 3.2 Installazione dei pacchetti Dei cinque pacchetti creati ricompilando OpenLDAP quelli che servono realmente sono soltanto i primi tre, gli altri due contengono rispettivamente dei programmi accessori e gli header file per compilare con la libreria di libldap, che di norma non vengono utilizzati. Sul server si dovranno installare tutti e tre i pacchetti menzionati, il terzo contiene il server, i primi due contengono la libreria per l accesso ed i programmi client che servono anche sul 2 il mantainer ha intenzione di predisporre i pacchetti con TLS/SSL abilitato, per cui in un breve futuro tutto questo potrebbe divenire non necessario.

3.2 Installazione dei pacchetti 3 server per potere immettere i dati nel server e verificarne il contenuto. Sui client basterà invece installare i primi due, ed in particolare la liberia, che serve anche ad eventuali programmi terzi (un esempio è gq, un editor grafico per gli alberi LDAP) che debbano accedere al server. Figura 1: Selezione del metodo di inizializzazione dell elenco. Il server LDAP è gestito dal demone slapd. All installazione del relativo pacchetto (con dpkg -i) debconf chiederà di settare le impostazioni iniziali, la prima scelta da effettuare (vedi fig. 1) è se inizializzare l elenco automaticamente o attraverso un file.ldif, dato l inizializzazione automatica crea pure un database iniziale che va sostanzialmente bene, useremo questa opzione. Alternativamente è possibile usare uno degli script del pacchetto migrationtools per generare un file.ldif (vedi sez. 4.4). Figura 2: Selezione del suffisso usato come radice dell elenco. La seconda scelta è relativa alla scelta di quale suffisso usare come radice dell elenco; come

4 3 INSTALLAZIONE accennato in sez. 2 infatti ogni elenco LDAP è organizzato in una struttura ad albero alla cui base sta il suffisso radice da cui partono tutte le ricerche. Questo può essere determinato in vari modi, a seconda di come si vuole strutturare l albero; i due stili principali sono quello che va per hostname, in cui si mette come suffisso un certo dominio, e quello che va per localizzazione, in cui si parte da uno stato (identificato con il solito codice di due lettere) ed una organizzazione. Nel nostro caso occorre selezionare il primo (vedi fig. 2). Figura 3: Immissione del nome di dominio. Scelto di usare lo stile basato sui domini, occorre inserire il dominio da cui si intende partire con la normale notazione dei nomi di dominio (vedi fig. 3). Questo sarà automaticamente convertito nel formato usato da LDAP. Figura 4: Immissione della password. Infine la configurazione chiede di immettere la password dell utente di amministrazione di

3.3 Considerazioni finali 5 LDAP (il valore predefinito è identificato dal common name admin, aggiunto immediatamente sotto la radice appena definita), che deve essere confermata (vedi fig. 4 e fig. 5) Figura 5: Conferma della password. Fatto questo verrà generato il file di configurazione per il server in /etc/ldap/slapd.conf, e creati i file del database con la struttura essenziale appena citata (in Debian di default viene usato ldbm) in /var/lib/ldap. La configurazione si cura anche di creare un utente di amministrazione del database e le access list relative. L utente è identificato come cn=admin,dc=gnulinux,dc=it, la password è quella immessa nella configurazione. Verrà inoltre creato il file /etc/ldap.secret che contiene la password (in chiaro, quindi occorre verificare che i permessi siano sempre settati a 600) per l accesso dell amministratore al database. Si tenga presente che la password deve essere sempre seguita da un a capo. 3.3 Considerazioni finali Si tenga presente che l uso di apt-get può interferire con tutta la procedura appena illustata, infatti in un upgrade verrebbero reinstallati i pacchetti originali. Per evitare che accada tutto ciò è opportuno mettere in hold i pacchetti ricompilati subito dopo averli installati. Qualora si volesse installare un versione successiva del pacchetto si può ripetere la procedura della ricompilazione, ma non sarà necessario (a meno di cambiamenti drastici nel pacchetto che richiedano una reinstallazione completa) ripetere la parte relativa alla auto-configurazione. 4 Configurazione Dato che l installazione di base e la configurazione iniziale fatta attraverso debconf è basata su pacchetti che non prevedono l utilizzo di TLS/SSL, prima di poter utilizzare effettivamente LDAP occorrerà effettuare una serie di ulteriori configurazioni (fra cui la generazione e la firma dei certificati) che sono coperte in questa sezione.

6 4 CONFIGURAZIONE 4.1 La creazione dei certificati Per poter usare SSL occorre fornire al server un certificato valido. Se poi si vuole anche avere l autenticazione del server da parte dei client e viceversa occorre anche creare una CA (Certification Authority che firmi i certificati delle varie macchine. Per far questo si possono usare gli strumenti forniti con SSL; il pacchetto Debian relativo è openssl che contiene l omonimo programma, più uno script in perl, /usr/lib/ssl/misc/ca.pl, che permette di semplificare la creazione della CA, facendo da interfaccia ad openssl per la gestione delle varie operazioni che eseguiremo con la nostra personale CA. In generale è buona norma creare i certificati e le chiavi su una macchina dedicata, non connessa alla rete e tenuta in luogo sicuro. L accesso alle chiavi della CA permette infatti di compromettere tutte le comunicazioni. Non disponendo di una macchina dedicata ho eseguito l operazione su un portatile isolato dalla rete, ho salvato tutti i file su un dischetto, stampando per ulteriore precauzione certificati e chiavi, poi ho cancellato il tutto (usando wipe, installabile dall omonimo pacchetti, per maggior sicurezza). Lo script genera i certificati usando alcuni valori predefiniti che sono impostati all inizio dello stesso. In particolare può essere interessante modificare la durata del certificato cambiando il valore della variabile $DAYS, che viene utilizzata per specificare di quanti giorni deve essere la validità del certificato generato. Modificare la riga relativa in: $DAYS="-days 1095"; permette di specificare tre anni (1095 giorni) al posto dell anno (365 giorni) utlizzato come valore predefinito. Il primo passo della procedura è quello di creare certificati e chiavi per la nostra nuova Certification Authority personale. Questo si fa con l opzione -newca, l output del comando è: [root@havnor software]# /usr/lib/ssl/misc/ca.pl -newca CA certificate filename (or enter to create) Making CA certificate... Using configuration from /usr/lib/ssl/openssl.cnf Generating a 1024 bit RSA private key...++++++...++++++ writing new private key to./democa/private/cakey.pem Enter PEM pass phrase: Verifying password - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter., the field will be left blank. ----- Country Name (2 letter code) [AU]:IT State or Province Name (full name) [Some-State]:Italia Locality Name (eg, city) []:Firenze Organization Name (eg, company) [Internet Widgits Pty Ltd]:GaPiL Organizational Unit Name (eg, section) []:Hacking Lab. Common Name (eg, YOUR name) []:roke.gnulinux.it Email Address []:piccardi@gnulinux.it premendo invio si genera un certificato con il nome standard. Lo script richiede poi una password per la chiave segreta della CA, che va confermata. Infine si devono immettere le informazioni previste dallo standard X.509, che saranno riportate nel certificato, procedendo come

4.1 La creazione dei certificati 7 mostrato nell uscita a video del comando riportata qui sopra. Tutti i file verranno creati in una sottodirectory./democa di quella in cui si esegue lo script: la chiave segreta verrà creata in./democa/private/cakey.pem ed il certificato con la chiave pubblica in./democa/cacert.pem. Il passo seguente è quello di creare i certificati per ciascuna macchina che dovrà essere autenticata. Se si vuole semplicemente assicurarsi una trasmissione criptata questo non è necessario e basta creare un certificato per il server, lo diventa qualora si intenda autenticare il server presso i client e viceversa. Il primo passo per creare un nuovo certificato, è quello di generare un certificato di richiesta; questo si fa usando l opzione -newreq, l output del comando è: [root@havnor software]# /usr/lib/ssl/misc/ca.pl -newreq Using configuration from /usr/lib/ssl/openssl.cnf Generating a 1024 bit RSA private key...++++++...++++++ writing new private key to newreq.pem Enter PEM pass phrase: Verifying password - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter., the field will be left blank. ----- Country Name (2 letter code) [AU]:IT State or Province Name (full name) [Some-State]:Italia Locality Name (eg, city) []:Firenze Organization Name (eg, company) [Internet Widgits Pty Ltd]:GaPiL Organizational Unit Name (eg, section) []:Hacking Lab. Common Name (eg, YOUR name) []:roke.gnulinux.it Email Address []:piccardi@gnulinux.it Please enter the following extra attributes to be sent with your certificate request A challenge password []: An optional company name []: Request (and private key) is in newreq.pem lo script prima chiede la password per la chiave privata, da confermare, poi passa alla richiesta dei dati dello standard X.509 da inserire nel certificato. In questo caso occorre essere precisi nella definizione del Common Name, esso infatti deve corrispondere esattamente al FQDN (Fully Qualified Domain Name, il nome completo dell estensione di domino) della macchina su cui si installerà il certificato, altrimenti l autenticazione non funzionerà. Alla fine delle operazioni il certificato di richiesta e la chiave privata ad esso associata saranno memorizzati nel file newreq.pem. Si può controllare il certificato di richiesta con il comando: openssl req -text -noout < newreq.pem Una volta creato il certificato di richiesta, questo deve essere firmato dalla Certification Authority, in modo da ottenere un certificato valido. Questo si fa con l opzione -sign, l output del comando è: [root@havnor software]# /usr/lib/ssl/misc/ca.pl -sign Using configuration from /usr/lib/ssl/openssl.cnf Enter PEM pass phrase: Check that the request matches the signature

8 4 CONFIGURAZIONE Signature ok The Subjects Distinguished Name is as follows countryname :PRINTABLE: IT stateorprovincename :PRINTABLE: Italia localityname :PRINTABLE: Firenze organizationname :PRINTABLE: GaPiL organizationalunitname:printable: Hacking Lab. commonname :PRINTABLE: roke.gnulinux.it emailaddress :IA5STRING: piccardi@gnulinux.it Certificate is to be certified until Aug 12 14:42:10 2003 GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated Signed certificate is in newcert.pem il comando chiederà la password della CA per firmare il certificato, e chiederà conferma riguardo la firma e la memorizzazione del nuovo certificato (lo script mantiene tutti i file necessari alla CA per tenere traccia dei vari certificati firmati, che vanno in./democa/newcerts). Il certificato firmato sarà salvato nel file newcert.pem. Perché slapd possa usare il certificato occorre però anche la sua chiave privata, e, non potendo essere effettuata una richiesta di password nel lancio di un demone, questa deve essere fornita in chiaro, pertanto occorrerà convertire la chiave contenuta in newreq.pem, che è crittata, con il comando: [root@havnor software]# openssl rsa < newreq.pem > newkey.pem dando la password del certificato. Si tenga presente che il file newkey.pem contiene la chiave provata in chiaro, e pertanto deve essere protetto scrupolosamente, cambiandone immediatamente in permessi in 400 (sola lettura per il proprietario) ed assegnato a root. Qualora si voglia usare una macchina che ha più nomi la cosa si complica, con SSL non è possibile infatti usare più certificati. In tal caso allora occorre far uso di una estensione prevista dallo standard X.509v3, che permette di specificare in uno stesso certificato nomi alternativi. Questo comporta alcune modifiche alla procedura appena illustrata. Anzitutto occorre settare openssl perché quando si firmano i certificati in essi venga inserito il campo relativo ai nomi alternativi. Questa procedura purtroppo non si può automatizzare 3 per cui per ciascun certificato si dovrà editare il file di configurazione di openssl (in Debian è /etc/ssl/openssl.cnf). Quello che va fatto, prima di firmare il certificato di richiesta, 4 è di inserire nella sezione [ usr cert ] di openssl.cnf una riga analoga alla seguente: subjectaltname = DNS:ldap.gnulinux.it,DNS:*.replica.gnulinux.it dove si indica la lista di nomi alternativi, che deve essere specificata con il suddetto formato, inserendo la lista separata da virgole dei FQDN, preceduti dall indicatore l indicatore DNS: 5 oppure, come nell esempio, specificando tutto un sottodominio con il metacarattere *. In questo modo, una volta firmato il certificato, il nome alternativo sarà inserito nel file newcert.pem, dove potremo verificare la presenza di un campo aggiuntivo del tipo: X509v3 Subject Alternative Name: DNS:ldap.gnulinux.it 3 perlomeno non sono riuscito a trovare una modalità che lo permettesse. 4 lo si può fare anche prima di creare la richiesta, la cosa è ininfluente al fine di avere il valore nel certificato finale. 5 si possono usare anche altri indicatori, come email: o URL: quando il certificato viene usato per pagine web o indirizzi di posta elettronica, e questi vari tipi di indicatori possono essere mescolati fra loro.

4.2 La configurazione lato server 9 4.2 La configurazione lato server Una volta creati i certificati si può passare alla configurazione di slapd; il primo passo è copiarli sulla macchina che ospiterà il server. Io li ho messi nella insieme agli altri file della configurazione di SSL, nella directory deputata ai certificati, /etc/ssl/certs, rinominandoli opportunamente come: [root@havnor certs]# ls -l total 16 -r--r--r-- 1 root root 1326 Aug 13 16:16 cacert.pem -r--r--r-- 1 root root 3711 Aug 13 16:16 ldapcert.pem -r-------- 1 root root 887 Aug 13 16:16 ldapkey.pem -r-------- 1 root root 1720 Aug 13 16:16 ldapreq.pem Dopo di che si tratta di configurare slapd per l uso di detti certificati. Questo è stato fatto aggiungendo al file di configurazione (/etc/ldap/slapd.conf) le seguenti righe: # For SSL/TSL authentication TLSCertificateFile /etc/ssl/certs/ldapcert.pem TLSCertificateKeyFile /etc/ssl/certs/ldapkey.pem TLSCipherSuite HIGH TLSCACertificateFile /etc/ssl/certs/cacert.pem #TLSVerifyClient 1 scommentando l ultima riga se si vuole imporre l autenticazione del client. Infatti se essa è settata, fintanto che il client non è opportunamente configurato (vedi sez. 4.3) per essere riconosciuto dal server, sarà impossibile qualunque interrogazione. Di norma questa opzione non viene utilizzata, in quanto (vedi quanto esposto in sez. 4.3) non esiste una modalità per permettere ad un utente generico l accesso ad un certificato. La verifica dell identità del client si gioca pertanto tutta sul suo essere in grado di autenticarsi presso il server come utente dell elenco. L ultimo passo è modificare lo script che attiva/disattiva il server, nel caso di Debian questo è /etc/init.d/slapd, che deve essere predisposto per lanciare slapd per l ascolto solo su SSL; questo si fa con la seguente modifica: start-stop-daemon --start --quiet --pidfile "$pf" --exec /usr/sbin/slapd\ -- -h ldaps:/// che aggiunge il parametro -h ldaps:/// all avvio di slpad. 4.3 La configurazione lato client Il file di configurazione delle libererie per l accesso al database, che vengono usate da tutti i vari client, compresi quelli del pacchetto ldap-utils, è /etc/ldap/ldap.conf. 6 In questo file va specificato quale è il server a cui si fa riferimento: è preferibile usare la direttiva uri, specificando al solito l indirizzo come ldaps://ldap.gnulinux.it ed eliminando le direttive host e port. Inoltre il file deve anche indicare il certificato della Certification Authority e la direttiva che impone il riconoscimento del server. Un esempio del contenuto del file è il seguente: BASE URI dc=gnulinux, dc=it ldaps://ldap.gnulinux.it 6 per RedHat invece è /etc/openldap/ldap.conf, lo segnalo perché altri potrebbero farsi trarre in inganno dalla (assai discutibile) presenza del file /etc/ldap.conf che invece è il file di configurazione di libnss-ldap.

10 4 CONFIGURAZIONE tls_checkpeer yes tls_cacertfile /etc/ssl/certs/cacert.pem rootbinddn cn=admin,dc=chl,dc=it e l ultima direttiva (rootbinddn) è quella che dice su quale utente devono essere mappate le richieste effettuate da root (di norma sono fatte in maniera anonima. É anche possibile, con le direttive binddn e bindpw specificare un collegamento al database attraverso uno specifico utente, di cui occorre fornire, come nell esempio, il Distinguished Name e la password (in chiaro). Nel caso dell utente associato root questa viene mantenuta a parte nel file /etc/ldap.secret i cui permessi devono essere settati a 0400. Se si è attivata la richiesta di verifica del client da parte di slapd occorre settare il client per l utilizzo dei certificati. Per ciascun client si dovranno pertanto ripetere le operazioni viste in sez. 4.1, per creare un certificato firmato dalla stessa CA del server. Anche qui si abbia cura di usare come Common Name il FQDN del client. Questi andranno copiati nella stessa directory /etc/ssl/certs/ con gli stessi permessi visti in precedenza. Fatto questo si deve indicare al client di usare questi certificati. Purtroppo questo non può essere fatto dal file di configurazione generale, ma deve essere specificato per ciascun utente nell opportuno file di configurazione personale.ldaprc, 7 in cui devono essere inserite le righe: TLS_CACERT TLS_CERT TLS_KEY TLS_REQCERT /etc/ssl/certs/cacert.pem /etc/ssl/certs/newcert.pem /etc/ssl/certs/newkey.pem hard (la prima è opzionale se il file della CA è già stato settato in ldap.conf. Una volta fatto questo si potrà verificare l accesso all elenco, il comando base che permette di fare delle ricerche è ldapsearch, se invocato senza parametri, con un comando del tipo: [root@havnor root]# ldapsearch -x e questo accederà al server specificato in ldap.conf per effettuare una ricerca generica, con accesso anonimo. L opzione -x serve a specificare che l autenticazione deve essere effettuata in modalità semplice. 8 Ulteriori opzioni utili sono: -H permette di specificare la locazione del server nella forma -H ldap://ldap.server.org o -H ldaps://ldap.server.org. -D permette di specificare il Distinguished Name (cioè il nome completo) di un utente con cui collegarsi all elenco, nella forma -D "cn=simone,ou=people,dc=gnulinux,dc=it". -w permette di specificare la password sulla riga di comando, nella forma -w password. -W chiede la password al prompt. Purtroppo allo stato delle cose non è possibile una modalità di autenticazione generica per del client nei confroti del server. Questo perché la modalità specificata funziona soltanto finché si ha l accesso alla chiave privata del certificato del client, data da TLS KEY, e questa deve essere 7 in realtà il file di configurazione può essere uno qualunque fra $HOME/.ldaprc, $HOME/ldaprc e $HOME/$LDAPRC, oppure si può usare la veriabile di ambiente LDAPRC per specificare un file a piacere. 8 LDAP supporta vari schemi di autenticazione, come Kerberos, SASL e una simple authentication che viene effettuata con password che vengono trasmesse in chiaro e confrontate con il relativo hash memorizzato nel campo, userpassword. Si è scelto quest ultima per la sua semplicità, dato che comunque tutte le comunicazioni fra client e server sono crittate.

4.4 L infrastruttura di base dell elenco 11 in chiaro, e non è pensabile che gli utenti possano accedere ad un certificato che identifica una macchina. Se pertanto se deve autenticare il client rispetto al server occorrerà fornire ciascun utente di un suo proprio certificato, rendendo ovviamente la cosa molto più macchinosa. 4.4 L infrastruttura di base dell elenco La configurazione base di LDAP, fatta da debconf all installazione del pacchetto slapd, crea un elenco iniziale che contiene una infrastruttura minimale, con soltanto la radice del dominio e l utente usato per l amministrazione. Per poter inserire le ulteriori informazioni sull elenco occorre predisporre una infrastruttura di base che permetta di inserirle in appropriati rami separati dell albero. Per inserire i dati nell elenco faremo uso degli script di migrazione che, oltre alla infrastruttura di base, permettono anche di convertire le varie informazioni riguardo password, hostname, servizi, ecc. in opportuni file.ldif da immettere nell elenco. Il pacchetto che fornisce detti script è migrationtools, e si può installare direttamente con apt-get. Prima di poter utilizzare gli script di migrazione, che vengono installati in /usr/share/migrationtools/ occorre preparare il file /etc/migrationtools/migrate common.ph, che contiene le impostazioni di base dell elenco, adattando le righe seguenti al proprio caso: # Default DNS domain $DEFAULT_MAIL_DOMAIN = "gnulinux.it"; # Default base $DEFAULT_BASE = "dc=gnulinux,dc=it"; dopo di che il file deve essere copiato in /usr/share/migrationtools/ insieme agli altri script, o essere referenziato con un link simbolico. Per usare gli script di conversione ci si dovrà porre in detta directory. A questo punto si può creare l infrastruttura base per il nostro elenco. Lo script migrate base.pl permette di creare un file.ldif che contiene quanto necessario; il comando è: [root@havnor migrationtools]#./migrate_base.pl > base.ldif L infrastruttura è basata su una serie di campi ou (della classe organizationalunit) che devono essere inseriti nell albero per fare da radice delle varie sezioni al cui interno inseriremo i dati relativi ai servizi che possono essere spostati su LDAP. Un esempio di una queste voci, estratta da base.ldif è: dn: ou=hosts,dc=gnulinux,dc=it ou: Hosts objectclass: top objectclass: organizationalunit che definisce la radice della sezione di albero su cui verrà mantenuto l elenco degli host che sostituirà quello di /etc/hosts. Alcune delle nuove voci sono superflue, inoltre sono previste delle voci per NIS (che certamente non interessano in quanto lo sostituiremo con LDAP) inoltre alcune voci possono essere duplicate (come People e la base dell albero) impedendo il funzionamento del comando di importazione. Per questo conviene comunque modificare base.ldif per adattarlo ai propri scopi, dopo di che si potranno inserire le nuove voci nell elenco con il comando: ldapadd -x -D"cn=admin,dc=gnulinux,dc=it" -W -f base.ldif dove il significato delle varie opzioni è lo stesso che abbiamo già visto in sez. 4.3 per ldapsearch, tranne per l ultima (-f) che in questo caso specifica il file che contiene le voci da aggiungere.

12 5 LA MIGRAZIONE DEL NAME SERVICE SWITCH 5 La migrazione del Name Service Switch Affronteremo in questa sezione le tematiche relative alla migrazione su LDAP delle informazioni del sistema che di norma sono gestite dal cosiddetto Name Service Switch (password, hosts, gruppi, ecc.). Ovviamente sarà opportuno migrare su LDAP solo le informazioni che ha senso mantenere in maniera centralizzata. 5.1 Introduzione Nelle librerie del C ci sono una serie di funzioni che permettono di ottenere informazioni riguardo l ambiente locale (password, nomi degli utenti, nomi delle macchine, corripondenze fra numeri di porta e nomi dei servizi). Tradizionalmente le fonti di queste informazioni erano mantenute un una singola modalità ben definita (in genere negli opportuni file di configurazione) ma con l introduzione di servizi come il DNS e NIS, incominciarono ad essere disponibili modalità alternative per ottenere le stesse informazioni. Nasceva così il problema di come indicare in maniera pulita dove le varie funzioni di libreria dovessero prendere le informazioni. All inizio questo veniva fatto introducendo tutta la casistica possibile dentro l implementazione delle funzioni stesse, con degli ovvi problemi di estendibilità e compatibilità. Per risolvere questo problema è stata introdotta una interfaccia apposita, il Name Service Switch, che permettesse di demandare a delle librerie esterne, configurabili in maniera indipendente, le modalità con cui queste informazioni vengono ottenute. Il grande vantaggio del Name Service Switch è che diventa possibile definire in maniera modulare ed estendibile sia delle classi di informazioni (cosicché qualora si debba fornire qualche nuovo servizio si ha l infrastruttura già pronta) che il supporto (file, database o quello che si vuole, come LDAP, per esempio) su cui queste informazioni sono mantenute. Le modalità di funzionamento del Name Service Switch vengono gestite attraverso il file di configurazione /etc/nsswitch.conf, che specifica come le varie informazioni vengono recuperate; il formato del file prevede una riga per ogni classe di informazione, la prima colonna indica la la classe ed è seguita da :, sono possibili valori come hosts, group, passwd, aliases, protocols (che permettono di sostituire gli analoghi file sotto /etc; per l elenco completo si veda la pagina di manuale con man nsswitch.conf). Il resto della riga indica la procedura con cui dette informazioni vengono cercate sui vari supporti possibili (i file, un database, NIS, il DNS o LDAP), identificate da parole chiave come files, db, nis, dns e ldap con la possibilità di specificare l ordine in cui detti supporti verranno esaminati e una eventuale reazione ai risultati della ricerca. Un estratto del file installato in un sistema base Debian GNU/Linux è il seguente: # /etc/nsswitch.conf # # Example configuration of GNU Name Service Switch functionality. # If you have the glibc-doc and info packages installed, try: # info libc "Name Service Switch" for information about this file. passwd: group: shadow: hosts: networks: protocols: compat compat compat files dns files db files

5.2 Il file di hosts 13 services: ethers: rpc: netgroup: db files db files db files nis Con le GNU libc il sistema è completamente modulare in quanto è possibile inserire un nuovo tipo di supporto semplicemente fornendo una libreria dinamica nel /lib/libnss SERVICE.so.X 9, dove SERVICE corrisponde alla parola chiave specificata in /etc/nsswitch.conf; così per utilizzare il supporto di LDAP per il Name Service Switch basterà installare il pacchetto libnss-ldap, che fornisce la libreria dinamica /lib/libnss ldap.so.2. Il pacchetto permette di inserire le informazioni relativa ad una qualunque delle classi gestite dal Name Service Switch su LDAP; ad esempio se si vogliono spostare la informazioni di /etc/hosts su LDAP (come vedremo in sez. 5.2) dovremo inserire in /etc/nsswitch.conf una riga del tipo: hosts: files dns ldap L accesso all elenco è controllato dal file di configurazione /etc/libnss-ldap.conf, 10 che ha la stessa sintassi di ldap.conf. Lì cui vanno riportate le informazioni di base; la configurazione automatica di debconf non prevede l uso di TLS, per cui occorrerà impostarla a mano. Il file installato di default non attiva nessun servizio, e vedremo più avanti come dovrà essere modificato, tutto quello che deve essere fatto in generale è allora indicare in maniera adeguata all uso di TLS il server da utilizzare. In sostanza, rispetto alla configurazione base, occorre rimuovere la linea che specifica il server con la direttiva host, ed usare invece la direttiva uri, occorre definire l utente con il quale ci si vuole autenticare presso il server quando l utente è root (che di norma è lo stesso specificato in /etc/ldap/ldap.conf), e inserire le solite righe che specificano la locazione del certificato della CA utilizzato per autenticare il server; un esempio di /etc/libnss-ldap.conf è pertanto: #host ldap.gnulinux.it base dc=gnulinux,dc=it uri ldaps://ldap.gnulinux.it rootbinddn cn=admin,dc=gnulinux,dc=it scope one tls_checkpeer yes tls_cacertfile /etc/ssl/certs/cacert.pem Come detto occorre commentare la configurazione standard che prevede solo l indicazione di un host, per settare la comunicazione con il server su TLS/SSL direttamente con la direttiva uri. Deve essere indicata la radice dell elenco, con la direttiva base, e l utente a cui devono essere collegate le interrogazioni fatte da root, con la direttiva rootbinddn. La direttiva scope definisce l ambito della ricerca, il valore one indica che questa va effettuata su un solo dalla base dell elenco; valori alternativi possono essere base, che parte sempre sub che effettua la ricerca su tutti i livelli successivi. Infine va richiesto il controllo dell identità del server fornendo la locazione del certificato della CA con cui il controllo deve essere effettuato. 5.2 Il file di hosts Il primo servizio che migreremo su LDAP è quello degli hostname di /etc/hosts, questa è una modalità comoda per mantenere gli indirizzi delle macchine di una rete privata locale, che 9 dove X serve a distinguere fra le varie versioni, e vale 1 per le glibc 2.0 e 2 per le glibc 2.1. 10 come riportato in precedenza RedHat usa invece il file /etc/ldap.conf.

14 5 LA MIGRAZIONE DEL NAME SERVICE SWITCH vengono modificati spesso senza dover stare a configurare un DNS per un dominio fittizio. Il relativo script di migrazione è migrate hosts.pl, che si esegue con il comando: [root@havnor migrationtools]#./migrate_hosts.pl /etc/hosts hosts.ldif Questo genera il file hosts.ldif con le voci relative a ciascuna macchina presente in /etc/hosts, una voce del tipo di: 192.168.1.152 roke.gnulinux.it roke sarà trasformata in: dn: cn=roke.gnulinux.it,ou=hosts,dc=gnulinux,dc=it objectclass: top objectclass: iphost objectclass: device iphostnumber: 192.168.1.152 cn: roke.gnulinux.it cn: roke Dato che in /etc/hosts sono normalmente presenti anche gli indirizzi multicast di IPv6, installati di default con la distibuzione, conviene di nuovo modificare a mano il file per togliere questi e tutti gli eventuali indirizzi che non si vogliono inserire nell elenco; inoltre vanno rimosse anche tutte le voci duplicate (altrimenti l importazione si bloccherà quando si cercherà di inserirle). Effettuata la pulizia si potranno di nuovo immettere i dati con il comando: [piccardi@havnor ldap]$ ldapadd -x -D"cn=admin,dc=gnulinux,dc=it" -W -f hosts.ldif Ed a questo punto si può verificare che le informazioni immesse siano effettivamente disponibili, usando il comando: [piccardi@havnor ldap]$ ldapsearch -x -LL "(cn=roke)" Una volta effettuata la migrazione dei dati occorrerà settare il sistema per leggere i dati da LDAP. Per questo si deve essere già stato installato libnss-ldap (vedi sez. 5.1), alla configurazione base ci sarà da aggiungere l informazione specifica che riguarda la lettura delle informazioni degli host; questo si fa aggiungendo 11 a libnss-ldap.conf la riga: nss_base_hosts ou=hosts,dc=chl,dc=it?one la configurazione infatti supporta una serie di direttive del tipo nss base XXXX, che permettono di specificare, come nel caso, in quale sezione dell albero sono mantenute le informazioni relative ai vari servizi (XXXX può essere hosts, passwd, group, ecc.) specificando la radice della stessa (nel caso ou=hosts,dc=chl,dc=it) e l ambito (nel caso?one, che dice che le informazioni sono direttamente accessibili al livello immediatamente sottostante la radice). Una volta settato libnss-ldap occorrerà indicare al sistema di utilizzare LDAP per le ricerche sugli host, questo va fatto modificando opportunamente /etc/nsswitch.conf per fargli prendere i dati da LDAP, questo si fa con una riga tipo: hosts: files dns ldap facendo attenzione che la macchina su cui sta il server LDAP sia risolvibile senza l uso di LDAP, (è pertanto escluso di utilizzare come primo supporto ldap) altrimenti si avrebbe un segmentation fault, dato che di creerebbe un ciclo ricorsivo in cui libnss-ldap chiama gethostbyname che a sua volta richiama libnss-ldap. In questo modi si potrà verificare che tutto funzioni con: 11 nel caso di Debian scommentando e modificando le righe che sono predisposte da debconf.

5.3 L autententicazione 15 [piccardi@havnor piccardi]$ ping roke PING roke.gnulinux.it (192.168.1.152): 56 data bytes 64 bytes from 192.168.1.152: icmp_seq=0 ttl=255 time=9.5 ms 64 bytes from 192.168.1.152: icmp_seq=1 ttl=255 time=11.4 ms 64 bytes from 192.168.1.152: icmp_seq=2 ttl=255 time=8.0 ms 64 bytes from 192.168.1.152: icmp_seq=3 ttl=255 time=8.2 ms --- roke.gnulinux.it ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 8.0/9.2/11.4 ms controllando che il server sia contattato. Attenzione: al momento la cosa sembra funzionare solo per le chiamate a gethostbyname, programmi che usano (come ssh, telnet, ecc.) getaddrinfo non funzionano. 5.3 L autententicazione Uno degli usi più interessanti di LDAP è quello che permette di sostituire l elenco degli utenti e gruppi di un computer, al posto dei classici file /etc/passwd e /etc/groups; essendo il protocollo trasparente alla rete questo può essere immediatamente esteso ad un gruppo di macchine diverse, diventando una alternativa praticabile al posto di NIS, quando si debba gestire un sistema di autenticazione centralizzata di uno stesso gruppo di utenti su macchine diverse. Rispetto a NIS infatti LDAP presenta numerosi vantaggi: anzitutto l informazione mantenuta nel database può essere utilizzata anche per altri scopi (come per la gestione degli account di posta o di altre informazioni generali), inoltre LDAP permette un controllo di accesso alle varie informazioni memorizzate nell elenco molto più dettagliato attraverso l uso di access list, ed infine supporta la replicazione e la ridondanza, ed è pertanto in grado di rispondere ad esigenze di resistenza agli incidenti. Il vantaggio più importante rispetto a NIS però è quello della sicurezza: LDAP può essere utilizzato attraverso TSL/SSL, consentendo la trasmissione crittata dei dati, la autenticazione di client e server, e la verifica dell integrità dei dati. Per gestire i dati di autenticazione convenieno creare un utente dedicato sull elenco, da tenere separato dall utente usato come amministratore per tutto l elenco. Questo permette di avere un maggiore controllo su quanto i vari client potranno fare, limitando l accesso alle sole informazioni che riguardano l autenticazione. Per questo definiremo un apposito utente authuser che avrà il permesso di accedere ai dati che ci interessano. Il primo passo è di inserire i suoi dati nell elenco, per farlo usiamo il solito comando ldapadd, con il file user.ldif, al cui interno inseriremo i dati, del tipo: dn: cn=authuser,dc=gnulinux,dc=it cn: authuser sn: authuser objectclass: top objectclass: person userpassword: {SSHA}l/J+F07gZ/bgPAuHan2YjyBf35F6F+1S che creerà il nuovo utente direttamente sotto la radice del nostro elenco; l ultimo dato è la password criptata, che può essere generata con il comando slappasswd, di default, come nel caso, il comando chiede due volte la password dal terminale e poi stampa il relativo hash, pronto all uso per essere inserito nel file con un taglia e incolla, usando l algorimo SHA. Si possono richiedere algoritmi alternativi con l opzione -h, ad esempio il comando:

16 5 LA MIGRAZIONE DEL NAME SERVICE SWITCH [root@havnor migrationtools]# slappasswd -h {md5} New password: Re-enter new password: {MD5}DIgCi/OqamoUPthG8r4epA== genera la password con l algoritmo MD5. A questo punto su può aggiungere il nuovo utente con: [root@havnor migrationtools]# ldapadd -x -D cn=admin,dc=gnulinux,dc=it -W -f user.ldif Enter LDAP Password: adding new entry "cn=authuser,dc=gnulinux,dc=it" ma restano da assegnarli i privilegi. Questo si fa andando ad aggiungere le access list che servono in slapd.conf; in particolare occorerà dare accesso alle password; questo si fa con le righe: access to attribute=userpassword by dn="cn=admin,dc=chl,dc=it" write by dn="cn=authuser,dc=chl,dc=it" read by anonymous auth by self write by * none Il tipo di privilegio da assegnare al nuovo utente riguardo al campo userpassword dipende da come si vuole utilizzare il modulo pam-ldap. Al solo scopo di autenticazione basta il privilegio di lettura, come nell esempio, 12 in questo caso però gli utenti non saranno in grado di cambiare la loro password con passwd e dovranno ricorrere esplicitamente a ldapmodify. Il problema è che la password che permette di collegarsi al server LDAP dai client è mantenuta in chiaro nel file ldap.secret; questo è un problema in quanto chiunque abbia accesso fisico alle macchine ha la possibilità di leggere questo file. Fintanto che si utilizza l utente authuser in sola lettura questo non è particolarmente grave, in quanto è sostanzialmente equivalente a consentire la lettura delle password criptate per tutti gli utenti, cosa comunque inevitabile se si vuole poterli autenticare in maniera centralizzata su una macchina. Il problema nasce per l accesso in scrittura; in questo modo chiunque abbia l accesso come root ad una qualunque delle macchine client diventa in grado di cambiare le password per tutti gli utenti sul server e quindi avere un incidenza anche su tutte le altre. Per questo motivo si è mantenuto il permesso in sola lettura, se però si vuole che gli utenti possano utilizzare i normali tool di gestione, come passwd, occorrerà assegnare anche il privilegio di scrittura. 5.4 La migrazione di utenti e gruppi Il primo passo è migrare i gruppi, al solito si usano gli script di migrazione del pacchetto migrationtools, con lo script migrate group.pl si effettua la migrazione dei gruppi; il comando da utilizzare è: [root@havnor migrationtools]#./migrate_group.pl /etc/group group.ldif che crea le voci relative a tutti i gruppi presenti in /etc/group in group.ldif. Il problema è che in /etc/group sono presenti anche tutti i gruppi di sistema (come mail, news, ecc.) che non ha senso migrare (e possono essere molto diversi da ditribuzione a distribuzione). Per questo motivo è opportuno modificare il file lasciando solo voci relative a gruppi effettivi; ad esempio per i gruppi personali degli utenti queste saranno della forma: 12 attenzione a non inserire commenti a metà di una direttiva access, perché in tal caso le access list non vengono lette bene.

5.4 La migrazione di utenti e gruppi 17 dn: cn=piccardi,ou=group,dc=gnulinux,dc=it objectclass: posixgroup objectclass: top cn: piccardi userpassword: {crypt}x gidnumber: 1000 mentre se abbiamo dei gruppi utilizzati come gruppi di lavoro avremo qualcosa del tipo di: dn: cn=cvsusers,ou=group,dc=gnulinux,dc=it objectclass: posixgroup objectclass: top cn: cvsusers userpassword: {crypt}x gidnumber: 103 memberuid: claudioc memberuid: dariar memberuid: diegods memberuid: francescog memberuid: marcop memberuid: paolomu memberuid: piccardi memberuid: riccardog memberuid: riccardom memberuid: simonepi Una volta migrati i gruppi si potrà ripetere il procedimento con gli utenti, in questo caso lo script da utilizzare è migrate passwd.pl, ed il comando usato è: [root@havnor migrationtools]#./migrate_passwd.pl /etc/passwd passwd.ldif Anche in questo caso occorrerà provvedere ad eliminare dall elenco tutti gli utenti di sistema (come root, daemon, ecc.) che di norma sono locali alle varie macchine e non devono (specie root) essere messi sul server. Un esempio di voce relativa ad un utente è la seguente: dn: uid=simonepi,ou=people,dc=gnulinux,dc=it uid: piccardi cn::u2ltb25lifbpy2nhcmrp objectclass: account objectclass: posixaccount objectclass: top objectclass: shadowaccount userpassword: {crypt}$1$7idw9tn0$/qvjor4cnuqptwlmtgiqa0 shadowlastchange: 11354 shadowmax: 99999 shadowwarning: 7 loginshell: /bin/bash uidnumber: 1002 gidnumber: 1002 homedirectory: /home/piccardi gecos: Simone Piccardi,,, Una volta ripuliti entrambi i file si potrà passare alla immissione dei dati nell elenco con il solito comando ldapadd, e cioè con i comandi:

18 5 LA MIGRAZIONE DEL NAME SERVICE SWITCH ldapadd -x -D"cn=admin,dc=gnulinux,dc=it" -W -f group.ldif ldapadd -x -D"cn=admin,dc=gnulinux,dc=it" -W -f passwd.ldif Dopo di che occorrerà abilitare il Name Server Switch a cercare l informazione su LDAP; il primo passo è allora di modificare /etc/nsswitch.conf per abilitare la ricerca su LDAP, aggiungendo modificando le righe: passwd: group: shadow: compat ldap compat ldap compat ldap dopo di che occorre settare /etc/libnss-ldap.conf per fargli mappare adeguatamente le informazioni sull elenco con quelle che servono per i servizi, questo si fa con le righe: nss_base_passwd nss_base_shadow nss_base_group ou=people,dc=chl,dc=it?one ou=people,dc=chl,dc=it?one ou=group,dc=chl,dc=it?one e a questo punto si può verificare che le informazioni vengano viste correttamente con i comandi: [root@havnor libpam-ldap]# getent passwd root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh... piccardi:x:1000:1000:simone Piccardi,,,:/home/piccardi:/bin/bash claudioc:x:1001:1001:claudio Cicali,,,:/home/claudioc:/bin/bash simonepi:x:1002:1002:simone Piccardi,,,:/home/simonepi:/bin/bash... [root@havnor libpam-ldap]# getent group root:x:0: daemon:x:1: bin:x:2:... piccardi:x:1000: claudioc:x:1001: simonepi:x:1002:... [root@havnor libpam-ldap]# getent shadow root:$1$jjgu2tk$jhjvqbp/xb6bmubzmt7ubjy:11376:0:99999:7::: daemon:*:11376:0:99999:7::: bin:*:11376:0:99999:7:::... piccardi:$1$jjfmgltbsmtk$jhjvqezgr8qt7ujyj1:11348::99999:7:::0 claudioc:$1$isjgu2$gdexzwmbqkltk$jhjvgeaey0:11354::99999:7:::0 simonepi:$1$tgfjd$gpmbp/xvqezgr8qb6bmubzhxl:11354::99999:7:::0... Verificato che le informazioni sono raggiunte in maniera corretta si può passare ai settaggi relativi a LDAP; anzitutto occorre le opzioni relative a PAM in ldap.conf, queste sono: pam_filter objectclass=posixaccount pam_login_attribute uid pam_member_attribute gid

5.4 La migrazione di utenti e gruppi 19 pam_template_login_attribute uid pam_password crypt Infine occorre predisporre per l uso di pam-ldap i vari servizi; per ciascuno di essi PAM prevede la presenza di un file nella directory /etc/pam.d, per abilitare il supporto per l autenticazione su LDAP vanno aggiunte le righe: auth account session password sufficient pam_ldap.so sufficient pam_ldap.so sufficient pam_ldap.so sufficient pam_ldap.so prima 13 delle equivalenti che usano pam unix.so, in modo da utilizzare le informazioni su LDAP se ci sono, e altrimenti passare al meccanismo classico di autenticazione di Unix. 13 la direttiva sufficient specifica che se il meccanismo di autenticazione funziona non c è bisogno di proseguire oltre per provare i successivi. Per questo questa deve essere specificata prima delle altre richieste (che di norma sono con required).