LDAP Linux HOWTO Luiz Ernesto Pinheiro Malère In questo documento sono presenti informazioni su come installare, configurare ed utilizzare un Server LDAP (Lightweight Directory Access Protocol) su una macchina Linux. Il documento inoltre presenta dettagli su come creare database LDAP, aggiungere, aggiornare e cancellare informazioni nella directory. Questo HOWTO è in gran parte basato su informazioni riprese dalla documentazione LDAP dell'università del Michigan e dalla Guida dell'Amministatore OpenLDAP. Traduzione e aggiornamenti a cura di Giulio Daprelà giulio@pluto.it. Revisione a cura di Hugh Hartmann hhartmann@libero.it _________________________________________________________ Sommario 1. Introduzione 1.1. Che cosa è LDAP? 1.2. Come lavora LDAP? 1.3. LDAP backend, oggetti e attributi 1.4. Nuove versioni di questo documento 1.5. Opinioni e Suggerimenti 1.6. Ringraziamenti 1.7. Copyright e Disclaimer 2. Installazione del server LDAP 2.1. Pre-Requisiti 2.2. Scaricare il pacchetto 2.3. Spacchettare il Software 2.4. Configurare il Software 2.5. Compilazione del Server 3. Configurazione del server LDAP 3.1. Formato del file di configurazione 3.2. Istruzioni globali 3.3. Direttive generali di backend 3.4. Direttive generali del database 3.5. Direttive del database BDB 3.6. Direttive del database LDBM 3.7. Esempi di Access Control 3.8. Esempio del file di configurazione 4. Eseguire il server LDAP 4.1. Opzioni della linea di comando 4.2. Avviare il server LDAP 4.3. Terminare il server LDAP 5. Creazione e manutenzione del database 5.1. Creazione di un database on line 5.2. Creare un database off line 5.3. Maggiori informazioni sul formato LDIF 5.4. Le utilità ldapsearch, ldapdelete e ldapmodify 6. Caratteristiche e informazioni aggiuntive 6.1. LDAP Migration Tools 6.2. Autenticazione usando LDAP 6.3. Configurazione di SASL : Digest - MD5 6.4. Strumenti grafici di LDAP 6.5. Log 7. Riferimenti 7.1. URL 7.2. Libri 7.3. RFC Lista delle Tabelle 3-1. Livelli di debugging 3-2. Database Backend 4-1. Livelli di debug _________________________________________________________ Capitolo 1. Introduzione Lo scopo principale di questo documento è installare ed utilizzare un server di directory LDAP sulla propria macchina Linux. Si imparerà come installare, configurare, far funzionare e manutenere un server LDAP. Dopo di che si potrà anche imparare come poter immagazzinare, richiamare e aggiornare le informazioni sul proprio server usando i client e i programmi di utilità di LDAP. Il demone per il directory server LDAP è denominato slapd e funziona su molte piattaforme UNIX differenti. C'è un altro demone che si occupa della replica fra i server LDAP. Esso è denominato slurpd e per il momento non ci si deve preoccupare del suo funzionamento. In questo documento si fa funzionare uno slapd che fornisce il servizio directory soltanto per il proprio dominio locale, senza replica, quindi senza slurpd. Le informazioni complete sulla replica sono disponibili nella: Guida dell'Amministatore OpenLDAP La messa a punto del dominio locale rappresenta una scelta semplice per la configurazione del proprio server, utile per cominciare, ma con cui è facile passare ad un'altra configurazione, se lo si desidera. Le informazioni presentate in questo documento rappresentano un buon inizio per l'uso del server LDAP. Probabilmente, dopo aver letto questo documento ci si sentirà incoraggiati ad espandere le capacità del proprio server e perfino scrivere proprie applicazioni client, usando i kit di sviluppo già disponibili per C, C++ e Java. _________________________________________________________ 1.1. Che cosa è LDAP? LDAP sta per Lightweight Directory Access Protocol. Come il nome suggerisce, è un protocollo leggero client-server per l'accesso ai servizi di directory, in particolare ai servizi di directory basati sullo standard X-500. LDAP funziona sopra il protocollo TCP/IP o su altri protocolli di rete orientati alla connessione. LDAP è definito nel documento RFC2251 "The Lightweight Directory Access Protocol (v3). Un servizio di directory è simile a un database, ma tende a contenere le informazioni sugli attributi in maniera più descrittiva. L'informazione in una directory è letta generalmente molto più spesso di quanto sia scritta. I servizi di directory sono ottimizzati per dare una rapida risposta ad accessi in grande quantità o per operazioni di ricerca. Possono avere la capacità di replicare ampiamente le informazioni, al fine di aumentare la disponibilità e l'affidabilità, mentre riducono il tempo di risposta. Quando l'informazione della directory è replicata, le inconsistenze momentanee fra le repliche possono essere tollerate, finchè non vengono finalmente sincronizzate. Ci sono molti modi differenti di gestire un servizio di directory. Diverse metodologie permettono a generi differenti di informazioni di essere immagazzinate nelle directory, pongono differenti requisiti su come queste informazioni possano essere consultate, interrogate ed aggiornate, su come sono protette da accessi non autorizzati, ecc. Alcuni servizi di directory sono locali, forniscono cioè il servizio ad un contesto limitato (per esempio, il servizio finger su una singola macchina). Altri servizi di directory sono globali, e forniscono il servizio ad un contesto molto più ampio. _________________________________________________________ 1.2. Come lavora LDAP? Il servizio di directory LDAP è basato su un modello client-server. Uno o più server LDAP contengono i dati che costituiscono l'albero di directory di LDAP o il database LDAP sottostante. Un client LDAP si collega ad un server LDAP e fa una domanda. Il server o risponde, o indica al client dove poter ottenere maggiori informazioni (tipicamente, un altro server LDAP). Non importa a quale server LDAP un client si connette poiché esso avrà sempre la stessa vista dell'albero di directory; lo stesso nome su server LDAP diversi identifica un unico oggetto. Ciò è una caratteristica molto importante di un servizio di directory globale, come appunto LDAP. _________________________________________________________ 1.3. LDAP backend, oggetti e attributi Il demone del server LDAP è chiamato Slapd. Slapd supporta una varietà di differenti database backends utilizzabili. Essi includono come scelta primaria BDB, un database backend transazionale ad alte prestazioni; LDBM, un backend leggero basato su DBM; SHELL, un'interfaccia di backend per script di shell arbitrari e PASSWD, una semplice interfaccia di backend per il file passwd(5). BDB utilizza Sleepycat Berkeley DB 4. LDBM utilizza Berkeley DB o GDBM. Il backend transazionale BDB è adatto per l'accesso a database di lettura/scrittura in modalità multiutente, con qualunque mix di operazioni lettura/scrittura. BDB è usato nelle applicazioni che richiedono: * Transazioni, compresi cambiamenti multipli di database effettuati in modo atomico e il rollback di eventuali modifiche non completate, quando necessario. * Capacità di ripristino da crash del sistema e da guasti hardware senza perdere nessuna transazione completata. In questo documento si suppone che venga scelto il database BDB. Per importare ed esportare le informazioni tra directory server basati su LDAP, o per descrivere un insieme di cambiamenti da apportare alla directory, si usa tipicamente il formato file LDIF (LDAP Data Interchange Format). Un file LDIF memorizza informazioni in strutture gerarchiche orientate agli oggetti. Il pacchetto di programmi di LDAP che si avrà è fornito di un programma di utilità per convertire i files LDIF in formato BDB. Un file LDIF comune è simile a questo: dn: o=TUDelft, c=NL o: TUDelft objectclass: organization dn: cn=Luiz Malere, o=TUDelft, c=NL cn: Luiz Malere sn: Malere mail: malere@yahoo.com objectclass: person Come si può vedere ogni voce è identificata unicamente in base a un nome distinto, o DN. Il DN è composto dal nome della voce più un percorso di nomi che risalgono dalla voce all'indietro fino in cima alla struttura gerarchica della directory (come in un albero). In LDAP, una classe oggetto definisce la collezione degli attributi che possono essere usati per definire una voce. Lo standard di LDAP fornisce questi tipi base di classi oggetto: * Gruppi nella directory, che includono liste non ordinante di singoli oggetti o gruppi di oggetti. * Locazioni, come il nome di un paese e una descrizione. * Organizzazioni nella directory. * Persone nella directory. Una voce può appartenere a più di una classe oggetto. Per esempio, la voce per una persona è definita dalla classe oggetto person, ma può anche essere definita dagli attributi delle classi inetOrgPerson, groupOfNames e organization. La struttura di classi oggetto del server (il suo schema) determina la lista totale degli attributi obbligatori e permessi per ogni singola voce. I dati della directory sono rappresentati come coppie di attributi-valori. Qualsiasi informazione specifica è associata a un attributo descrittivo. Per esempio, l'attributo commonName, o cn, è usato per immagazzinare il nome della persona. Una persona chiamata Jonas Salk può essere rappresentata nella directory come cn: Jonas Salk Ogni persona che è inserita nella directory è definita da una serie di attributi nella classe person. Altri attributi usati per definire questa voce potrebbero essere: givenname: Jonas surname: Salk mail: jonass@airius.com Gli attributi obbligatori includono gli attributi che devono essere presenti nella voce in quanto appartenenti ad una specifica classe. Tutte le voci richiedono l'attributo objcetClass, che elenca le classi cui l'oggetto appartiene. Gli attributi consentiti includono gli attributi che possono essere presenti nelle voci che usano una classe oggetto. Per esempio, nella classe oggetto person, gli attributi cn e sn sono obbligatori. Gli attributi descrizione, telephoneNumber, seeAlso e userpassword sono consentiti ma non sono obbligatori. Ogni attributo ha una corrispondente definizione di sintassi. La definizione di sintassi descrive il tipo di informazione fornita dall'attributo, per esempio: * bin: tipo binario. * ces: case exact string (durante il confronto le maiuscole/minuscole devono corrispondere). * cis: case ignore string (durante il confronto maiuscole/minuscole sono ignorate). * tel: telephone number string (come cis ma gli spazi in bianco ed il ` - ' sono ignorati durante i confronti). * dn: distinguished name. Nota: di solito le definizioni delle classi oggetto e degli attributi risiedono nei file di schema, nella sottodirectory schema sotto la directory di installazione di OpenLDAP. _________________________________________________________ 1.4. Nuove versioni di questo documento Questo documento può subire delle correzioni e aggiornamenti basati su feedback ricevuti dai lettori. Si può visitare l'url: http://www.tldp.org/HOWTO/LDAP-HOWTO.html per avere nuove versioni di questo HOWTO. _________________________________________________________ 1.5. Opinioni e Suggerimenti Se si ha qualunque genere di dubbio circa le informazioni presenti in questo documento, ci si metta in contatto con me al seguente indirizzo di email: malere@yahoo.com Se avete commenti e/o suggerimenti, fatemi sapere! _________________________________________________________ 1.6. Ringraziamenti Questo Howto è il risultato di una internship fatta da me all'interno dell'università di TUDelft - Paesi Bassi. desidero ringraziare le persone che mi hanno incoraggiato a redigere questo documento: Rene van Leuken e Wim Tiwon. Grazie molto. Inoltre sono fan di Linux, proprio come me. Desidero ringraziare anche Thomas Bendler, autore del Ldap-Howto tedesco, per il suo contributo al mio documento, e anche Joshua Go, grande volontario sul progetto LDP. Karl Lattimer merita un premio, per il suo grande contributo sulle questioni relative a SASL. E grazie a Dio! _________________________________________________________ 1.7. Copyright e Disclaimer Copyright (c) 1999 Luiz Ernesto Pinheiro Malère. 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, 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". Se avete domande, visitate il seguente url: http://www.gnu.org/licenses/fdl.txt e mettetevi in contatto con il coordinatore di Linux HOWTO, a: guylhem@metalab.unc.edu _________________________________________________________ Capitolo 2. Installazione del server LDAP Sono necessarie cinque fasi per installare il server LDAP: * Installare i pacchetti pre-requisiti (se non già installati). * Scaricare l'applicazione server. * Spacchettare il software. * Configurare i Makefile. * Compilare il server. _________________________________________________________ 2.1. Pre-Requisiti Per essere pienamente conformi alle specifiche di LDAPv3, i client e i server OpenLDAP richiedono l'installazione di qualche pacchetto addizionale. Per scrivere questo documento, ho usato una distribuzione Mandrake 9.0 con un Kernel 2.4.20, installando manualmente il pacchetto Berkeley BDB e le librerie SASL. Librerie SASL OpenSSL TLS Le librerie OpenSSL TLS sono normalmente parte del sistema base o costituiscono un componente software opzionale. l'url ufficiale OpenSSL TLS è: http://www.openssl.org Servizi di Autenticazione Kerberos I client e i server OpenLDAP supportano i servizi di autenticazione basati su Kerberos. In particolare OpenLDAP supporta il meccanismo di autenticazione SASL/GSSAPI usando i pacchetti Heimdal o MIT Kerberos V. Se si desidera usare l'autenticazione SASL/GSSAPI basata su kerberos, bisogna installare o heimdal o MIT kerberos V. Heimdal kerberos è disponibile all'indirizzo http://www.pdc.kth.se/heimdal MIT Kerberos è disponibile all'indirizzo http://web.mit.edu/kerberos/www L'uso di servizi di autenticazione forti, simili a quelli forniti da Kerberos, è fortemente raccomandato. Cyrus's Simple Authentication e Security Layer Libraries Le librerie SASL del progetto Cyrus fanno parte normalmente del sistema di base o costituiscono un componente software opzionale. Cyrus SASL è disponibile all'indirizzo http://asg.web.cmu.edu/sasl/sasl-library.html. Cyrus SASL userà le librerie Kerberos/GSSAPI e OpenSSL se preinstallate. Al momento in cui sto scrivendo, ho usato Cyrus SASL 2.1.12. Database Software Il principale database backend di slapd, BDB, richiede la versione 4 dello Sleepycat Software Berkeley DB. Se non sarà disponibile al momento della configurazione, non potrete compilare lo slapd con il database backend principale. Il vostro sistema operativo può contenere il DB di Berkeley, versione 4, nel sistema di base o come componente software opzionale. Altrimenti ci sono parecchie versioni disponibili su Sleepycat. Al momento in cui sto scrivendo, è consigliato l'utilizzo dell'ultima versione 4.1.25. Il backend LDBM del server slapd di OpenLDAP supporta una varietà di database manager, come Berkeley DB (versione 3) e GDBM. GDBM è disponibile dal sito di download della FSF ftp://ftp.gnu.org/pub/gnu/gdbm/. Thread Il supporto thread è quasi certamente parte integrante del proprio sistema linux di base. OpenLDAP è progettato per trarre vantaggi dai thread. OpenLDAP supporta i POSIX pthread, i Mach Cthread, e un certo numero di altre varietà. Lo script configure protesterà se non troverà un sottosistema thread adatto. Se questo dovesse accadere, siete pregati di consultare la sezione software - Installation - Platform Hints dell'OpenLDAP FAQ: http://www.openldap.org/faq/. TCP Wrapper Slapd supporta TCP wrapper (filtri di controllo di accesso a livello IP) se preinstallati. L'uso dei TCP wrapper o di altri filtri di accesso a livello IP (come quelli forniti da una firewall a livello IP) è raccomandato per i server che contengono informazioni non pubbliche. _________________________________________________________ 2.2. Scaricare il pacchetto Ci sono due distribuzioni libere di server LDAP: LDAP server dell'Università del Michigan e OpenLDAP server. C'è anche il Netscape directory server, che è libero solo sotto qualche condizione (gli istituti scolastici possono averlo liberamente per esempio). OpenLDAP server è basato sull'ultima versione del Server dell'Università del Michigan e ci sono mailing list e documentazione supplementare disponibile per esso. Questo documento assume che si stia usando il server OpenLDAP. L'ultima versione tar.gzip è disponibile al seguente indirizzo: http://www.openldap.org Se si vuole l'ultima versione del server dell'Università del Michigan, si vada al seguente indirizzo: ftp://terminator.rs.itd.umich.edu/ldap Per scrivere questo documento, ho usato la versione 2.1.16 del pacchetto OpenLDAP. Il mio sistema operativo è un Mandrake Linux 9.0 con kernel 2.4.20. Sul sito di OpenLDAP potete sempre trovare le ultime versioni di sviluppo e stabili del server Open LDAP. Quando questo documento è stato aggiornato, l'ultima versione stabile era openldap-stable-20030317.tgz (versione 2.1.16). l'ultima versione sviluppata era invece openldap-2.1.16.tgz. _________________________________________________________ 2.3. Spacchettare il Software Ora che si ha il pacchetto tar.gzip sulla propria macchina locale, si può spacchettarlo. Prima copiare il pacchetto in una directory di proprio gradimento, per esempio /usr/local. Poi usare il comando seguente: tar xvzf openldap-2.1.16.tgz Si può usare anche questo comando, equivalente: gunzip openldap-2.1.16.tgz | tar xvf - _________________________________________________________ 2.4. Configurare il Software I sorgenti del server OpenLDAP sono distribuiti con uno script di configurazione per impostare opzioni quali le directory di installazione, i flag del compilatore e del linker. Eseguire il seguente comando nella directory in cui si è spacchettato il software: ./configure --help Tutte le opzioni che si potranno personalezzare si otterranno con lo script di configurazione prima di copiare il software. Alcune opzioni utili sono: -- prefix=pref, -- exec-prefix=eprefix e -- bindir=dir, per impostare le directory di installazione. Normalmente se si lancia lo script di configurazione senza opzioni, esso rileverà le impostazioni appropriate e preparerà l'installazione nei percorsi di default. Quindi digitare semplicemente: ./configure E guardare l'output per controllare se va tutto bene Suggerimento: a volte bisogna passare delle opzioni specifiche al proprio script di configurazione, come per esempio -- with-tls (per permettere allo slapd di utilizzare un canale sicuro: LDAPS://). In questo caso, potrebbe darsi che le proprie librerie SSL/TLS risiedano in una directory non standard del proprio sistema. Si può informare lo script di configurazione dell'ubicazione delle librerie cambiando le proprie variabili d'ambiente, utilizzando il comando env. Esempio: si supponga di aver installato il pacchetto openssl sotto /usr/local/openssl. Il seguente comando compilerà slapd con il supporto SSL/TLS: env CPPFLAGS=-I/usr/local/openssl/include \ LDFLAGS=-L/usr/local/openssl/lib \ configure --with-tls ... si possono specificare le seguenti variabili d'ambiente con il comando env prima dello script di configurazione: * CC: specifica un compilatore C alternativo. * CFLAGS: specifica i flag addizionali per il compilatore. * CPPFLAGS: specifica i flag per il Preprocessore C. * LDFLAGS: specifica i flag per il linker. * LIBS: specifica delle librerie addizionali. _________________________________________________________ 2.5. Compilazione del Server Dopo aver configurato il software si può iniziare a compilarlo. Prima compilare le dipendenze, usando il comando: make depend Dopo compilare il server, usando il comando: make Se tutto va bene, il server sarà compilato come da configurazione. Altrimenti, ritornare al punto precedente per rivedere le impostazioni di configurazione. Bisognerebbe leggere i file di README e di INSTALL situati nella directory in cui si è spacchettato il software. Inoltre controllare i suggerimenti specifici dello script di configurazione, situati nel percorso doc/install/configure sotto la directory dove si è spacchettato il software. Per assicurare una corretta compilazione bisognerebbe lanciare la procedura di test (impiegherà alcuni minuti): make test I test che si applicano alla propria configurazione verranno eseguiti e dovrebbero essere superati. Alcune prove, quale la prova della replica, possono essere saltate. Ora installare i file binari e le man page. Si può avere bisogno di essere super-user per fare questo (a seconda di dove si stanno installando le cose): su root -c 'make install' Questo è tutto; ora si ha il file binario del server e i file binari di parecchi altri programmi di utilità. Andare al Capitolo 3 per vedere come configurare il funzionamento del proprio server LDAP. _________________________________________________________ Capitolo 3. Configurazione del server LDAP Una volta che il software è stato installato e compilato, si è pronti a configurarlo per l'uso che se ne deve fare. Tutta la configurazione runtime dello slapd è compiuta attraverso il file slapd.conf, installato nella directory prefix che si è specificato nello script di configurazione o di default in /usr/local/etc/openldap. Questa sezione specifica in dettaglio le istruzioni di configurazione comunemente usate per slapd.conf. Per una lista completa, vedere la pagina di manuale di slapd.conf(5). Le istruzioni del file di configurazione sono divise in tre tipologie: global, backend specific e database specific. Qui si troveranno le descrizioni delle istruzioni, insieme ai loro valori di default (se ci sono) ed agli esempi di uso. _________________________________________________________ 3.1. Formato del file di configurazione Il file slapd.conf consta di tre tipi di informazioni di configurazione: global, backend specific, e database specific. Le informazioni globali sono specificate per prime, seguite dalle informazioni associate con un particolare tipo di backend, a loro volta seguite dalle informazioni associate ad una particolare istanza di database. Le istruzioni globali possono essere sovrascritte da istruzioni di backend e/o di database, e le istruzioni di backend possono essere sovrascritte dalle istruzioni di database. Le linee in bianco e le linee di commento che cominciano con il carattere '#' sono ignorate. Se una linea comincia con uno spazio viene considerata continuazione della riga precedente. Il formato generale di slapd.conf è il seguente: # direttive globali di configurazione # definizione backend backend # definizione primo database & direttive di configurazione database # definizione secondo database & direttive di configurazione database # definizione secondo database "typeA" & direttive di configurazione database # backend successivo & definizioni database & direttive di configurazio ne ... Un'istruzione di configurazione può avere argomenti. In questo caso sono separati da spazio bianco. Se un argomento contiene uno spazio bianco, deve essere racchiuso tra doppi apici "come questo". Se una discussione contiene un doppio apice o il carattere di backslash `\', il carattere dovrebbe essere preceduto da un altro backslash `\'. La distribuzione contiene un file di configurazione di esempio che sarà installato nella directory /usr/local/etc/openldap. Un certo numero di file che contengono le definizioni dello schema (tipi di attributo e classe oggetto) sono forniti nella directory /usr/local/etc/openldap/schema. _________________________________________________________ 3.2. Istruzioni globali Le istruzioni descritte in questa sezione si applicano a tutti i backends e database a meno che non siano specificamente sovrascritte in una definizione di backend o di database. Gli argomenti che dovrebbero essere sostituiti dal testo effettivo sono indicati tra parentesi angolari < >. access to [ by ]+ Questa istruzione garantisce l'accesso (specificato da ) ad un insieme di voci e/o attributi (specificati da ) per uno o più richiedenti (specificati da ). Vedere gli esempi della la Sezione 3.7 per maggiori dettagli. Importante: se non è specificata alcuna direttiva di accesso, la politica di controllo accesso di default, accesso * in * lettura, consente accesso in lettura sia agli utenti autenticati che a quelli anonimi. attributetype Questa direttiva definisce un tipo di attributo. Controllare il seguente URL per maggiori dettagli: Schema Specification idletimeout Specifica il numero di secondi di attesa prima di chiudere forzatamente una connessione client non utilizzata. Un idletimeout pari a 0, il default, disabilita questa caratteristica. include Questa istruzione implica che lo slapd legga le informazioni supplementari di configurazione dal file in questione prima di continuare con la linea successiva del file corrente. Il file incluso dovrebbe seguire le normali disposizioni del file config dello slapd. Il file è usato comunemente per includere file che contengono le specifiche dello schema. Nota: si dovrebbe fare attenzione quando si usa questa istruzione - non c'è un limite basso al numero di direttive include annidate e non viene fatto nessun controllo di loop. loglevel Questa direttiva specifica il livello al quale dovrebbero essere inviate al file syslog le informazioni statistiche e i messaggi di debug (attualmente i messaggi vengono inviati al syslogd(8) con il servizio LOCAL4). Bisogna aver configurato OpenLDAP con l';opzione --enable-debug (di default) affinché questo funzioni (tranne per i due livelli di statistica, che sono sempre permessi). I livelli di log sono cumulativi. Per visualizzare quali numeri corrispondono a quale tipo di debug, richiamare lo slapd con -? o consultare la tabella sottostante. I valori possibili per sono: Tabella 3-1. Livelli di debugging Livello Descrizione -1 attiva tutti i livelli di debug 0 nessun debug 1 traccia le chiamate a funzione 2 debug del trattamento del pacchetto 4 tracciamento pesante 8 gestione della connessione 16 scrittura dei pacchetti spediti e ricevuti 32 eleborazione dei filtri di ricerca 64 elaborazione del file di configurazione 128 elaborazione dela lista di controllo d'accesso 256 statistiche delle connessioni-operazioni-risultati 512 statistiche degli oggetti inviati 1024 scrittura della comunicazione con la shell di backend 2048 scrittura di debug del parsing degli oggetti Esempio: loglevel 255 or loglevel -1 Questo farà sì che vengano loggate moltissime informazioni di debug. Default: loglevel 256 objectclass Questa informazione definisce una classe oggetto. Controllare il seguente URL per maggiori informazioni: Schema Specification referral Questa istruzione specifica il riferimento da restituire quando lo slapd non può trovare un database locale per trattare una richiesta. Esempio: referral ldap://root.openldap.org Questa istruzione rinvierà interrogazioni non-locali alla root globale del server LDAP del progetto OpenLDAP. Client LDAP intelligenti possono riformulare la richiesta a quel server, ma notare che la maggior parte di questi client stanno solo cominciando a capire come gestire semplici URL LDAP che contengono una parte con il nome dell'host e facoltativamente una parte con il Distiguished Name. sizelimit Questa istruzione specifica il numero massimo di oggetti che si otterranno dall'operazione di ricerca. Default: sizelimit 500 timelimit Questa istruzione specifica il numero massimo di secondi (in tempo reale) che slapd impiegherà per rispondere alla richiesta di ricerca. Se una richiesta non è conclusa in questo lasso di tempo, il risultato sarà una segnalazione di superamento del tempo limite. Default: timelimit 3600 _________________________________________________________ 3.3. Direttive generali di backend Le direttive contenute in questa sezione si applicano soltanto al backend nel quale sono definite. Sono sostenute da ogni tipo di backend. le istruzioni di backend si applicano a tutte le istanze di database dello stesso tipo e, secondo l'istruzione, possono essere sovrascritte dalle istruzioni del database. backend Questa istruzione contrassegna l'inizio di una definizione backend. dovrebbe essere o bdb o uno degli altri tipi di backend supportati ed elencati di seguito: Tabella 3-2. Database Backend Tipo Descrizione bdb Berkeley DB transactional backend dnssrv DNS SRV backend ldbm Lightweight DBM backend ldap Lightweight Directory Access Protocol (Proxy) backend meta Meta Directory backend monitor Monitor backend passwd Fornisce l'accesso in sola lettura a passwd(5) perl Perl Programmable backend shell Shell (extern program) backend sql SQL Programmable backend tcp TCP Programmable backend Esempio: backend bdb Ciò contrassegna l'inizio di nuova definizione backend BDB _________________________________________________________ 3.4. Direttive generali del database Le direttive contenute in questa sezione si applicano soltanto ai database in cui esse sono definite. Sono supportate da ogni tipo di database. database Questa istruzione contrassegna l'inizio di nuova definizione di istanza di database. dovrebbe essere uno dei tipi backend elencati al punto precedente. Esempio: database ldbm Ciò contrassegna l'inizio di un detabase backend LDBM. readonly { on | off } Questa istruzione pone il database in modalità "read-only". Ogni tentativo di modificare il database restituirà l'errore "unwilling to perform". Default: readonly off replica host=[:] [bindmethod={ simple | kerberos | sasl }] ["binddn="] [mech=] [authcid=] [authzid=] [credentials=] [srvtab=] Questa direttiva specifica un luogo di replica per questo database. Il parametro uri= specifica uno schema, un host e facoltativamente una porta a cui l'istanza slave slapd può essere trovata. Un nome completo di dominio o un indirizzo IP può essere usato per l'. Se non è dato, viene usato il numero di porta standard di LDAP (389 o 636). Il parametro bindnn= fornisce il DN con cui collegarsi allo slapd secondario per gli aggiornamenti. Dovrebbe essere un DN che ha accesso in lettura /scrittura al database dello slapd secondario, impostato tipicamente come un root dn nel file di configurazione dello slapd secondario. Deve anche accordarsi con la direttiva update dn nel file di configurazione dello slapd secondario. Generalmente questo DN non deve essere lo stesso del rootdn del master database. Poiché i DN contengono facilmente spazi, l'intera stringa "binddn=" deve essere racchiusa tra doppi apici. L'istruzione bindmethod accetta come argometo i valori simple o Kerberos o sasl, a seconda che nella connessione allo slapd secondario si usi per l'autenticazione il metodo semplice basato su password o Kerberos o SASL. L'autenticazione simple non dovrebbe essere usata a meno che non siano in funzione adeguate protezioni di segretezza e di integrità (per esempio TLS o IPSEC). L'autenticazione simple richiede la descrizione dettagliata di binddn e dei parametri delle credenziali. L'autenticazione Kerberos è deprecata a favore dei meccanismi di autenticazione SASL, in particolare i meccanismi di GSSAPI e di KERBEROS_V4. L'autenticazione Kerberos richiede i parametri srvtab e binddn. L'autenticazione SASL è generalmente raccomandata. L'autenticazione SASL richiede la specifica di un meccanismo usando il parametro saslmech. A seconda del meccanismo, un'identità e/o delle credenziali di autenticazione possono essere specificate usando authcid e le rispettive credenziali. Il parametro authzid può essere usato per specificare un'identità di autorizzazione. Controllare questo URL per dettagli aggiuntivi: Replication with Slurpd. replogfile Questa direttiva specifica il nome del file di log della replica in cui lo slapd registrerà i cambiamenti. Il log della replica è tipicamente scritto da slapd e letto da slurpd. Normalmente, questa direttiva è usata soltanto se slurpd è stato usato per replicare il database. Tuttavia, si può anche usare per generare un log di transazione, se lo slurpd non sta funzionando. In questo caso, dovrete troncare periodicamente il file, altrimenti crescerebbe indefinitamente. Controllare questo URL per vedere dettagli addizionali: Replication with Slurpd. rootdn Questa direttiva specifica il DN che non è soggetto a restrizioni di controllo di accesso o di limiti amministrativi per le operazioni su questo database. Il DN non ha bisogno riferirsi ad un oggetto nella directory. Il DN può riferirsi ad un'identità di SASL. Entry-based Esempio: rootdn "cn=Manager, dc=example, dc=com" SASL-based Esempio: rootdn "uid=root@EXAMPLE.COM" rootpw Questa direttiva può essere usata per specificare una password per il rootdn (quando il rootdn è impostato a DN all'interno del database). Esempio: rootpw secret È anche permesso fornire l'hash della password in forma RFC 2307. slappasswd può essere usato per generare l'hash della password. Esempio: rootpw {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN L'hash è stato generato usando il comando slappasswd -s secret. suffix Questa direttiva specifica il suffisso DN delle interrogazioni che saranno passate a questo database backend. Possono essere date più linee di suffisso e per ogni definizione di database è necessaria ce ne sia almeno una. Esempio: suffix "dc=example, dc=com" Le interrogazioni con un DN che termina in "dc=example, dc=com" saranno passate a questo backend. Nota: quando viene selezionato il backend a cui passare una interrogazione, lo slapd guarda alla/e linee di suffisso in ogni definizione del database nell'ordine che compaiono nel file. Quindi, se un suffisso di database è un prefisso di un altro, deve comparire dopo esso nel file di configurazione. syncrepl Questa direttiva può essere usata per tenere sincronizzato un database replicato con il database master, in modo che il contenuto del database replicato sia aggiornato con il contenuto del master. Questo documento non copre in dettaglio questa direttiva, poiché si configura un server LDAP singolo. Per maggiori informazioni su questa direttiva, visitare: LDAP Sync Replication. updatedn Questa direttiva è applicabile soltanto a uno slapd secondario. Essa specifica il DN a cui è permesso di apportare modifiche alla replica. Questo può essere il DN con cui si connette slurpd quando apporta modifiche alla replica o il DN associato con un'identità SASL. Entry-based Esempio: updatedn "cn=Update Daemon, dc=example, dc=com" SASL-based Esempio: updatedn "uid=slurpd@EXAMPLE.COM" Controllare questo URL per maggiori dettagli: Replication with Slurpd. updateref Questa istruzione è applicabile soltanto in uno slapd secondario. Essa Specifica l'URL da restituire ai client che inoltrano richieste di aggiornamento alla replica. Se specificato più volte, viene fornito ogni URL. Esempio: update ldap://master.example.net _________________________________________________________ 3.5. Direttive del database BDB Le direttive in questa categoria riguardano soltanto un database BDB. Cioè, esse devono seguire una linea del "database bdb" e venire prima di ogni successiva linea di "backend" o "database". directory Questa istruzione specifica la directory dove risiedono i file BDB contenenti il database e gli indici associati. Default: directory /usr/local/var/openldap-data sessionlog Questa direttiva specifica un archivio del log di sessione nel server del provider di replica syncrepl, che contiene informazioni sulle voci che sono state portate fuori dal contenuto di replica identificato da . La prima richiesta di ricerca syncrepl avente lo stesso valore nel cookie stabilisce l'archivio del log di sessione nel server del provider. Il numero di voci nell'archivio del log di sessione è limitato da . Le voci in eccesso sono rimosse dall'archivio in ordine FIFO. Sia che sono interi non negativi. ha non più di tre cifre decimali. L'operazione di sincronizzazione del contenuto di LDAP che cade in una sessione preesistente può usare l'archivio del log di sessione allo scopo di ridurre l'ammontare di traffico di sincronizzazione. Se la replica non è troppo datata e può essere aggiornata dalle informazioni nell'archivio sessione, lo slapd provider invierà allo slapd consumer le identità delle voci eliminate assieme alle voci aggiunte o modificate nel contenuto di replicazione. Se lo stato della replica è troppo superato e oltre la copertura dell'archivio storico, allora lo slapd provider invierà le identità delle voci in ingresso non mutate assieme a quella delle voci cambiate. Lo slapd consumer quindi rimuoverà quelle voci nella replica che non sono identificate come presenti nel contenuto del provider. Per maggiori informazioni su syncrepl, visitare: LDAP Sync Replication. _________________________________________________________ 3.6. Direttive del database LDBM Le direttive contenute in questa categoria si applicano soltanto al database di backend LDBM. Cioè, esse devono seguire una linea "database ldbm" e venire prima di ogni altra linea di "database" o "backend". cachesize Questa direttiva specifica la quantità di oggetti per la memoria cache gestita dall'istanza di database backend LDBM. Default: cachesize 1000 dbcachesize Questa istruzione specifica la dimensione in byte della memoria cache connessa associata ad ogni file indice aperto. Se non è supportata dal metodo del database sottostante, questa direttiva è ignorata senza commenti. Aumentando questo numero viene usata più memoria, ma questo può causare un notevole aumento di prestazioni, particolarmente durante modifiche o quando vengono costruiti gli indici. Default: dbcachesize 100000 dbnolocking Questa opzione, se presente, disabilita il blocco del database. Abilitare questa opzione può migliorare le prestazioni a scapito della protezione dei dati. dbnosync Questa opzione fa si che i contenuti del database su disco non siano immediatamente sincronizzati con le continue modifiche in memoria. Abilitare questa opzione può migliorare le prestazioni a scapito della protezione dei dati. directory Questa istruzione specifica la directory dove risiedono i file LDBM contenenti il database e gli indici associati. Default: directory /usr/local/var/openldap-ldbm index { | default} [pres,eq,approx,sub,none] Questa direttiva specifica gli indici da mantenere per il dato attributo. Se viene fornito un solo , vengono mantenuti gli indici di default. Esempio: index default pres,eq index uid index cn,sn pres,eq,sub index objectClass eq La prima linea imposta l'insieme degli indici di default da mantenere per present ed equality. La seconda linea fa sì che l'insieme degli indici di default (pres, eq) sia mantenuto per il tipo di attributo uid. La terza linea fa sì che gli indici di present, equality e substring siano mantenuti per i tipi di attributo cn e sn. La quarta linea crea un indice equality per l'attributo di tipo objectClass. Di default, non è mantenuto nessun indice. Generalmente si raccomanda come minimo di mantenere un indice equality sugli objectClass. index objectClass eq mode Questa direttiva specifica i permessi di accesso che i file indice del database generato ex novo dovrebbero avere. Default: mode 0600 _________________________________________________________ 3.7. Esempi di Access Control La funzione di access control fornita dalla direttiva access è abbastanza potente. Questa sezione mostra alcuni esempi di utilizzo. In primo luogo, alcuni esempi semplici: access to * by * read Questa direttiva di accesso garantisce accesso in lettura a tutti. Il seguente esempio mostra l'uso di una espressione regolare per selezionare le voci per DN in due direttive di accesso dove l'ordinamento è importante. access to dn=".*, o=U of M, c=US" by * search access to dn=".*, c=US" by * read L'accesso in lettura è assegnato alle voci sotto il sottoalbero c=US, tranne quelle voci sotto il sottoalbero ""o=U of M, c=US", a cui è garantito l'accesso in ricerca. Nessun accesso è assegnato ai c=US, perché nessuna direttiva di accesso corrisponde a questo DN. Se l'ordine di queste direttive di accesso fosse invertito, la direttiva specifica U-M non troverebbe mai corrispondenza, poiché tutti i campi U-m sono anche campi c=US. Un altro modo di implementare lo stesso controllo di accesso è: access to dn.children="dc=example,dc=com" by * search access to dn.children="dc=com" by * read L'accesso in lettura è consentito alle voci nel sottoalbero dc=com, tranne per quelle voci nel sottoalbero dc=example,dc=com, a cui è consentito accesso in ricerca. Non è consentito l'accesso a dc=com, poiché nessuna direttiva di accesso corrisponde a questo DN. Se l'ordine di queste direttive di accesso fosse invertito, la direttiva trascinata non verrebbe mai raggiunta, poiché tutte le voci sotto; dc=example,dc=com sono anche voci dc=com. Nota: notare anche che se nessuna direttiva di accesso o nessuna clausola "by " corrisponde, l'accesso è negato. Questo significa che ogni direttiva access to termina con una clausola implicita by * none , e ciascun elenco di accesso termina con una direttiva implicita access to * by * none. L'esempio seguente mostra ancora l'importanza dell'ordinamento, sia delle direttive di accesso che delle clausole "by ". Inoltre mostra l'uso di un selettore di attributo per garantire l'accesso a un attributo specifico e vari selettori . access to dn.subtree="dc=example,dc=com" attr=homePhone by self write by dn.children=dc=example,dc=com" search by peername=IP:10\..+ read access to dn.subtree="dc=example,dc=com" by self write by dn.children="dc=example,dc=com" search by anonymous auth Questo esempio riguarda le voci nel sottoalbero "dc=example,dc=com". A tutti gli attributi tranne homePhone, una voce può scrivere su se stessa, le voci nei campi example.com possono cercare da queste, nessun altro ha accesso (implicito by * none) tranne per autenticazione/autorizzazione (che è sempre fatta anonimamente). L'attributo homePhone è scrivibile dalla voce, ricercabile dai campi sotto example.com, leggibile dai client che si connettono dalla rete 10, e non è altrimenti leggibile (implicito by * none). Tutti gli altri accessi sono negati dall'implicito access to * by * none. A volte è utile per consentire a un particolare DN di aggiungere o rimuovere se stesso da un attributo. Per esempio, se si volesse creare un gruppo di utenti e concedere loro di aggiungere e rimuovere soltanto il proprio DN dall'attributo membro, si potrebbe fare ciò tramite un'istruzione di accesso come questa: access to attr=member,entry by dnattr=member selfwrite Il selettore dnattr comunica che l'accesso si applica agli oggetti elencati nell'attributo membro. Il selettore di accesso del selfwrite comunica che tali membri possono aggiungere o cancellare soltanto il loro proprio DN dall'attributo, e non altri valori. L'aggiunta del campo attributo è necessaria poiché l'accesso alla voce è necessario per accedere a qualunque attributo dell'oggetto. C'è abbondanza di informazioni sui controllo di accesso sulla Guida dell'Amministratore OpenLDAP. Consultare: Access Control per maggiori informazioni su questo argomento. _________________________________________________________ 3.8. Esempio del file di configurazione Quello che segue è un esempio di file di configurazione, suddiviso con testo esplicativo. Definisce due database per gestire le parti differenti dell'albero X.500; entrambe sono istanze di database BDB. I numeri della linea indicati sono forniti soltanto come riferimento e non sono inclusi nel file reale. In primo luogo, la sezione di configurazione globale: 1. # example config file - global configuration section 2. include /usr/local/etc/schema/core.schema 3. referral ldap://root.openldap.org 4. access to * by * read La linea 1 è un commento. La linea 2 include un altro file di config il quale contiene le definizioni dello schema del nucleo. La direttiva di rinvio nella linea 3 significa che le domande non locali ad uno dei database definiti sotto si riferiranno al server LDAP che funziona sulla porta standard (389) all'host root.openldap.org. La linea 4 è un controllo di accesso globale. Si applica a tutti i campi (dopo qualsiasi comando di accesso al database-specifico applicabile). La sezione successiva del file di configurazione definisce un backend BDB che gestirà le domande per cose nella porzione dell'albero "dc=example,dc=com". Il database viene replicato su due slapd slave, una sui truelies, l'altra su judgmentday. Gli indici devono essere mantenuti per numerosi attributi e l'attributo userPassword deve essere protetto da accessi non autorizzati. 5. # BDB definition for the example.com 6. database bdb 7. suffix "dc=example,dc=com" 8. directory /usr/local/var/openldap-data 9. rootdn "cn=Manager,dc=example,dc=com" 10. rootpw secret 11. # replication directives 12. replogfile /usr/local/var/openldap/slapd.replog 13. replica uri=ldap://slave1.example.com:389 14. binddn="cn=Replicator,dc=example,dc=com" 15. bindmethod=simple credentials=secret 16. replica uri=ldaps://slave2.example.com:636 17. binddn="cn=Replicator,dc=example,dc=com" 18. bindmethod=simple credentials=secret 19. # indexed attribute definitions 20. index uid pres,eq 21. index cn,sn,uid pres,eq,sub 22. index objectClass eq 23. # database access control definitions 24. access to attr=userPassword 25. by self write 26. by anonymous auth 27. by dn.base="cn=Admin,dc=example,dc=com" write 28. by * none 29. access to * 30. by self write 31. by dn.base="cn=Admin,dc=example,dc=com" write 32. by * read La linea 5 è un commento. L'inizio della definizione del database è contrassegnato dalla parola chiave del database alla linea 6. La linea 7 specifica il suffisso di DN per le domande da passare a questo database. La linea 8 specifica la directory in cui i file del database saranno presenti. Le linee 9 e 10 identificano la voce "super user" del database e la password collegata. Questo campo non è soggetto a controllo di accesso o a limitazioni di scadenza o di formato. Ricordare di cifrare il rootpw usando slappasswd. Esempio: rootpw{SSHA}Jq4xhhkGa7weT/0xKmaecT4HEXsdqiYA Le linee da 11 a 18 sono per la replica. Vedere il link Replication per maggiori informazioni su queste direttive. Le linee da 20 a 22 indicano gli indici da mantenere per i vari attributi. Le linee da 24 a 32 specificano il controllo di accesso per i campi in questo database. Poiché questo è il primo database, i controlli si applicano anche ai campi non contenuti in alcun database (come la Root DSE). Per tutti i campi applicabili, l'attributo di userPassword è scrivibile dall'oggetto stesso e dall'oggetto "admin". Può essere usato per scopi di autenticazione/autorizzazione, ma non è altrimenti leggibile. Tutti gli altri attributi sono scrivibili dall'oggetto e dall'oggetto "admin" ma possono essere letti da tutti gli utenti (autenticati o no). La sezione successiva dell'esempio del file di configurazione definisce un altro database BDB. Questo gestisce le domande che riguardano il sottoalbero dc=example,dc=net, ma è gestito dalla stessa entità del primo database. Si noti che senza la linea 39, l'accesso in lettura verrebbe concesso grazie alla regola globale di accesso contenuta nella linea 4. 33. # BDB definition for example.net 34. database bdb 35. suffix "dc=example,dc=net" 36. directory /usr/local/var/openldap-data-net 37. rootdn "cn=Manager,dc=example,dc=com" 38. index objectClass eq 39. access to * by users read _________________________________________________________ Capitolo 4. Eseguire il server LDAP Il demone slapd di LDAP è progettato per funzionare come server stand-alone. Questo permette al server di avere i vantaggi del caching, gestire i problemi di concorrenza con il database sottostante, e conservare risorse di sistema. Il funzionamento da inetd(8) non è previsto. _________________________________________________________ 4.1. Opzioni della linea di comando Slapd supporta un certo numero di opzioni della linea di comando, come dettagliato nella pagina di manuale. Questa sezione specifica alcune opzioni comunemente usate: -f Questa opzione specifica un file di configurazione alternativo per slapd. Il default è normalmente /usr/local/etc/openldap/slapd.conf. -h Questa opzione specifica le configurazioni alternative dell' ascoltatore. Il default è ldap:/// che comporta LDAP sopra TCP su tutte le interfacce sulla porta LDAP di default 389. Si possono specificare le coppie host-porta o altri schemi di protocollo (quali ldaps:// o ldapi://). Per esempio, -h "ldaps:// ldap://127.0.0.1:667" genererà due ascoltatori: uno per LDAP sopra SSL su tutte le interfacce sulla porta 636 di default LDAP/SSL ed uno per LDAP sopra TCP sull'interfaccia del localhost (loopback) sulla porta 667. Gli host possono essere specificati usando il formato IPV4 punto-decimale usando i nomi di host. I valori delle porte devono essere numerici. -n questa opzione specifica il nome del servizio usato per fare il log e per altri scopi. Il nome del servizio di default è slapd. -l Questa opzione specifica l'utente locale per il servizio syslog(8). I valori possono essere LOCAL0, LOCAL1, LOCAL2... e LOCAL7. Il default è LOCAL4. Questa opzione potrebbe non essere supportata su tutti i sistemi. Vedere i la Sezione 6.5 per maggiori dettagli. -u user -g group Queste opzioni specificano rispettivamente l'utente e il gruppo necessari per fare funzionare lo slapd. L'utente può essere o un username o uid. Il gruppo può essere un nome gruppo o gid. -r directory Questa opzione specifica una directory run-time. Slapd eseguirà chroot(2) in questa directory dopo aver aperto gli ascoltatori, ma prima di leggere qualunque file di configurazione o di inizializzare qualunque backend. -d | ? Questa opzione regola il livello di debug di slapd a . Quando il livello è un carattere `?', i vari livelli di debug sono stampati e slapd esce, incurante di qualsiasi altra opzione data. I livelli correnti di debug sono: Tabella 4-1. Livelli di debug Livello Descrizione -1 abilita tutto il debug 0 nessun debug 1 traccia le chiamate alle funzioni 2 debug il packet handling 4 heavy trace debugging 8 gestione della connessione 16 stampa i pacchetti inviati e ricevuti 32 processamento del filtro di ricerca 64 processamento del file di configurazione 128 processamento lista di controllo accesso 256 stats log connections/operations/results 512 stats log entries sent 1024 stampa la comunicazione con i backend della shell 2048 print entry parsing debugging Si possono permettere livelli multipli specificando l'opzione di debug ogni volta per ogni livello voluto. O, poiché i livelli di debug sono additivi, si possono fare i calcoli da sè. Quindi se si vogliono tracciare le chiamate alle funzioni e verificare che il file di configurazione venga processato si può impostare il livello come la somma di questi due livelli (in questo caso, - d 65). O si può lasciare che slapd faccia il calcolo, (per esempio - d 1 - d 64). Consultare per maggiori dettagli. Nota: lo slapd deve essere compilato con - DLDAP_DEBUG definito in modo che tutte le informazioni di debug oltre i due livelli di stat siano disponibili. _________________________________________________________ 4.2. Avviare il server LDAP in generale, slapd si avvia così: /usr/local/etc/libexec/slapd [