11.7. Directory LDAP

OpenLDAP è un'implementazione del protocollo LDAP; in altre parole, si tratta di un database progettato con lo speciale scopo di conservare directory. Il caso d'uso più comune, è l'impiego di un server LDAP per permettere di centralizzare la gestione degli account utente ed i relativi permessi. Inoltre, un database LDAP è facilmente replicato, cosa che permette di impostare sincronizzazioni multiple con altri server LDAP. Quando la rete e la base utenti crescono velocemente, il carico può essere bilanciato tra i vari server.

I dati di LDAP sono strutturati e gerarchici. La struttura è definita attraverso "schemi" che descrivono il tipo di oggetti che il database può contenere, con una lista di tutti i loro possibili attributi. La sintassi usata per riferirsi ad un particolare oggetto nel database è basata su questa struttura, cosa che spiega la sua complessità.

11.7.1. Installazione

Il pacchetto slapd contiene il server OpenLDAP. Il pacchetto ldap-utils include strumenti a riga di comando per interagire con i server LDAP.

L'installazione di slapd necessita normalmente soltanto della password dell'amministratore e il database risultante è improbabile che soddisfi le proprie esigenze. Fortunatamente un semplice dpkg-reconfigure slapd vi permetterà di riconfigurare il database LDAP con maggiori dettagli:

Omettere la configurazione del server OpenLDAP? No, naturalmente vogliamo configurare questo servizio.
Nome di dominio DNS: “falcot.com”.
Nome dell'organizzazione: “Falcot Corp”.
Dev'essere inserita una password amministrativa.
Database di backend da usare: “MDB”.
Eliminare il database in caso di rimozione completa di slapd? No. Non ha senso rischiare di perdere il database in caso di uno sbaglio.
Spostare il vecchio database? Questa domanda è posta solamente quando viene tentata un configurazione ed un database è già presente. Rispondere "si" se si desidera ricominciare da un database pulito, per esempio se si esegue dpkg-reconfigure slapd subito dopo la prima installazione.

Un database minimale è attualmente configurato, come dimostra la seguente richiesta:

$ ldapsearch -x -b dc=falcot,dc=com
# extended LDIF
#
# LDAPv3
# base <dc=falcot,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# falcot.com
dn: dc=falcot,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: Falcot Corp
dc: falcot

# admin, falcot.com
dn: cn=admin,dc=falcot,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

La richiesta restituisce due oggetti: l'organizzazione stessa e l'utente amministrativo.

11.7.2. Riempire la directory

Dato che un database vuoto non è particolarmente utile, ci apprestiamo ad inserire al suo interno tutte le directory esistenti; inclusi i database degli utenti, dei gruppi, dei servizi e degli host.

Il pacchetto migrationtools fornisce un insieme di script dedicati ad estrarre i dati dalle directory standard di Unix (/etc/passwd, /etc/group, /etc/services, /etc/hosts e così via), convertire questi dati ed inserirli all'interno del database LDAP.

Dopo averlo installato il pacchetto il file /etc/migrationtools/migrate_common.ph dev'essere modificato. Le opzioni IGNORE_UID_BELOW e IGNORE_GID_BELOW devono essere abilitate (è sufficiente decommentarle), e DEFAULT_MAIL_DOMAINDEFAULT_BASE devono essere aggiornate.

La reale operazione di migrazione è gestita dal comando migrate_all_online.sh, come segue:

# cd /usr/share/migrationtools
# PERL5LIB="${PERL5LIB}:/etc/migrationtools" LDAPADD="/usr/bin/ldapadd -c" ETC_ALIASES=/dev/null ./migrate_all_online.sh

migrate_all_online.sh rivolge alcune domande a proposito del database LDAP nel quale si vogliono migrare i dati. Tabella 11.1 riassume le risposte fornite nel caso d'uso della Falcot.

Tabella 11.1. Le risposte fornite alle domande poste dallo script migrate_all_online.sh

Domanda	Risposta
X.500 naming context	`dc=falcot,dc=com`
Nome host del server LDAP	`localhost`
Manager DN	`cn=admin,dc=falcot,dc=com`
Bind credentials	la password amministrativa
Create DUAConfigProfile	no

Da notare che è stata estesa la variabile PERL5LIB. Questo è dovuto al bug report Debian #982666.

→ https://bugs.debian.org/982666

Come si sarà notato è stata deliberatamente ignorata la migrazione del file /etc/aliases dato che lo schema standard, come fornito da Debian, non include le strutture che utilizza questo script per descrivere gli alias delle email. Se si dovessero integrare questi dati nella directory, il file /etc/ldap/schema/misc.schema dovrebbe essere aggiunto allo schema standard.

Notare altresì l'uso dell'opzione -c con il comando ldapadd: questa opzione richiede che l'elaborazione non si interrompa in caso di errori. Utilizzare questa opzione è necessario poiché convertire il database /etc/services genera spesso qualche errore che può essere ignorato senza conseguenze.

11.7.3. Gestire gli account con LDAP

Ora il database LDAP contiene diverse informazioni utili ed è giunto il momento di sfruttarle. Questa sezione si concentra su come configurare un sistema Linux per far sì che le varie directory di sistema utilizzino il database LDAP.

11.7.3.1. Configurare NSS

Il sistema NSS (Name Service Switch, si veda il riquadro APPROFONDIMENTO NSS ed i database di sistema) è un sistema modulare progettato per definire o recuperare informazioni sulle directory di sistema. Utilizzare LDAP come sorgente di dati per NSS richiede l'installazione del pacchetto libnss-ldap. La sua installazione pone alcune domande; le risposte sono riassunte nella Tabella 11.2.

Tabella 11.2. Configurare il pacchetto libnss-ldap:

Domanda	Risposta
URI (Uniform Resource Identifier) del server LDAP	`ldapi://ldap.falcot.com`
Il nome distintivo per la base di ricerca	`dc=falcot,dc=com`
La versione di LDAP da utilizzare	`3`
L'account LDAP per root	`cn=admin,dc=falcot,dc=com`
La password per l'account root di LDAP	la password amministrativa
Permettere all'account amministrativo LDAP di agire come root?	`yes`
Il database LDAP deve richiedere il login?	no

Il file /etc/nsswitch.conf deve quindi essere modificato per poter configurare NSS in modo che utilizzi il modulo ldap appena installato. Si può usare l'esempio fornito in /usr/share/doc/libnss-ldap/examples/nsswitch.ldap o modificare la configurazione esistente.

Esempio 11.23. Il file /etc/nsswitch.conf

#ident $Id: nsswitch.ldap,v 2.4 2003/10/02 02:36:25 lukeh Exp $
#
# An example file that could be copied over to /etc/nsswitch.conf; it
# uses LDAP conjunction with files.
#
# "hosts:" and "services:" in this file are used only if the
# /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports.

# the following lines obviate the "+" entry in /etc/passwd and /etc/group.
passwd:         files ldap
shadow:         files ldap
group:          files ldap

# consult DNS first, we will need it to resolve the LDAP host. (If we
# can't resolve it, we're in infinite recursion, because libldap calls
# gethostbyname(). Careful!)
hosts:          dns ldap

# LDAP is nominally authoritative for the following maps.
services:   ldap [NOTFOUND=return] files
networks:   ldap [NOTFOUND=return] files
protocols:  ldap [NOTFOUND=return] files
rpc:        ldap [NOTFOUND=return] files
ethers:     ldap [NOTFOUND=return] files

# no support for netmasks, bootparams, publickey yet.
netmasks:   files
bootparams: files
publickey:  files
automount:  files

# I'm pretty sure nsswitch.conf is consulted directly by sendmail,
# here, so we can't do much here. Instead, use bbense's LDAP
# rules ofr sendmail.
aliases:    files
sendmailvars:   files

# Note: there is no support for netgroups on Solaris (yet)
netgroup:   ldap [NOTFOUND=return] files

Il modulo ldap è generalmente inserito prima degli altri, e sarà di conseguenza richiamato per primo. L'unica eccezione degna di nota è il servizio hosts dato che contattare il server LDAP richiede prima la consultazione del DNS (per risolvere ldap.falcot.com). Senza questa eccezione, la richiesta cercherebbe di contattare il server LDAP; questo causerebbe un tentativo di risoluzione del nome per il server LDAP, e così via in un ciclo infinito.

Se il server LDAP dev'essere considerato autoritativo (e i file locali utilizzati dal modulo files ignorati) i servizi possono essere configurati con la seguente sintassi:

servizio: ldap [NOTFOUND=return] files.

Se l'entità richiesta non esiste nel database LDAP, la richiesta restituirà una risposta "non esistente" anche se la risorsa esiste in uno dei file locali: questi file locali saranno utilizzati unicamente quando il servizio LDAP non è raggiungibile.

11.7.3.2. Configurare PAM

Questa sezione descrive una configurazione di PAM (si veda il riquadro DIETRO LE QUINTE /etc/environment e /etc/default/locale) che consentirà alle applicazioni di eseguire le autenticazioni richieste attraverso il database LDAP.

Il modulo LDAP per PAM è fornito dal pacchetto libpam-ldap. L'installazione di questo pacchetto pone alcune domande molto simili a quelle viste con libnss-ldap: alcuni parametri di configurazione (come l'URI del server LDAP) sono in realtà persino condivisi con il pacchetto libnss-ldap. Le risposte sono riassunte in Tabella 11.3.

Tabella 11.3. Configurazione di libpam-ldap

Domanda	Risposta
Permettere all'account amministrativo LDAP di agire come root?	Sì. Questo ci consente di utilizzare il comando `passwd` per cambiare le password conservate nel database LDAP.
Il database LDAP richiede il login?	no
L'account LDAP per root:	`cn=admin,dc=falcot,dc=com`
Password amministrativa LDAP:	La password amministrativa del database LDAP
Algoritmo di crittografia locale da utilizzare per le password:	`crypt`
Profili PAM da abilitare:	L'autenticazione LDAP è tra i profili abilitati

L'installazione di libpam-ldap adatta automaticamente la configurazione predefinita di PAM contenuta nei file /etc/pam.d/common-auth, /etc/pam.d/common-password e /etc/pam.d/common-account. Questo meccanismo utilizza lo strumento dedicato pam-auth-update (fornito con il pacchetto libpam-runtime). Questo strumento può anche essere eseguito dall'amministratore qualora desideri abilitare o disabilitare dei moduli PAM.

11.7.3.3. Mettere al sicuro lo scambio dati di LDAP

In via predefinita il protocollo LDAP transita sulla rete come testo in chiaro: questo include le password (cifrate). Poiché le password cifrate possono essere estratte dalla rete rimangono vulnerabili ad attacchi a dizionario. Questo può essere evitato utilizzando uno strato di cifratura addizionale: abilitare questo strato è l'argomento di questa sezione.

11.7.3.3.1. Configurazione del server

Il primo passo richiede la creazione di una coppia di chiavi (comprensiva di chiave pubblica e chiave privata) per il server LDAP. Gli amministratori della Falcot riutilizzano easy-rsa per generarla (vedere Sezione 10.2.2, «Infrastruttura a chiave pubblica: easy-rsa»). L'esecuzione di ./easyrsa build-server-full ldap.falcot.com nopass richiederà il "nome comune". La risposta deve essere il nome di dominio pienamente qualificato del server LDAP; nel nostro caso ldap.falcot.com.

Questo comando crea un certificato nel file pki/issued/ldap.falcot.com.crt; la corrispondente chiave privata è conservata nel file pki/private/ldap.falcot.com.key.

Ora questi tasti devono essere installati nella loro posizione standard, e dobbiamo fare in modo che il file privato sia leggibile dal server LDAP che gira sotto l'identità utente openldap:

# adduser openldap ssl-cert
Adding user `openldap' to group `ssl-cert' ...
Adding user openldap to group ssl-cert
Done.
# mv pki/private/ldap.falcot.com.key /etc/ssl/private/ldap.falcot.com.key
# chown root.ssl-cert /etc/ssl/private/ldap.falcot.com.key
# chmod 0640 /etc/ssl/private/ldap.falcot.com.key
# mv pki/issued/ldap.falcot.com.crt /etc/ssl/certs/ldap.falcot.com.pem
# chown root.root /etc/ssl/certs/ldap.falcot.com.pem
# chmod 0644 /etc/ssl/certs/ldap.falcot.com.pem

Bisogna anche dire al demone slapd di usare queste chiavi per la crittografia. La configurazione del server LDAP è gestita dinamicamente: la configurazione può essere aggiornata con le normali operazioni LDAP sulla gerarchia di oggetti cn=config, ed il server aggiornerà /etc/ldap/slapd.d in tempo reale per rendere la configurazione persistente. ldapmodify è quindi lo strumento giusto per aggiornare la configurazione:

Esempio 11.24. Configurare slapd per la cifratura

# cat >ssl.ldif <<END
dn: cn=config
changetype: modify
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldap.falcot.com.key
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldap.falcot.com.pem
END
# ldapmodify -Y EXTERNAL -H ldapi:/// -f ssl.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"
# systemctl restart slapd.service
# ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config -s base | grep TLS
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
olcTLSCertificateFile: /etc/ssl/certs/ldap.falcot.com.pem
olcTLSCertificateKeyFile: /etc/ssl/certs/ldap.falcot.com.key

STRUMENTO ldapvi per modificare una directory LDAP

Con il comando ldapvi, è possibile visualizzare un output LDIF di qualsiasi parte della directory LDAP, apportare alcune modifiche nell'editor di testo, e lasciare che lo strumento faccia le operazione LDAP per voi.

E' quindi un modo conveniente per aggiornare la configurazione del server LDAP, semplicemente modificando la gerarchia cn=config.

# ldapvi -Y EXTERNAL -h ldapi:/// -b cn=config

L'ultimo passo per abilitare la cifratura richiede la modifica della variabile SLAPD_SERVICES nel file /etc/default/slapd. Inoltre, per essere prudenti, si renderà necessario disabilitare l'LDAP non sicuro.

Esempio 11.25. Il file /etc/default/slapd

# Default location of the slapd.conf file or slapd.d cn=config directory. If
# empty, use the compiled-in default (/etc/ldap/slapd.d with a fallback to
# /etc/ldap/slapd.conf).
SLAPD_CONF=

# System account to run the slapd server under. If empty the server
# will run as root.
SLAPD_USER="openldap"

# System group to run the slapd server under. If empty the server will
# run in the primary group of its user.
SLAPD_GROUP="openldap"

# Path to the pid file of the slapd server. If not set the init.d script
# will try to figure it out from $SLAPD_CONF (/etc/ldap/slapd.d by
# default)
SLAPD_PIDFILE=

# slapd normally serves ldap only on all TCP-ports 389. slapd can also
# service requests on TCP-port 636 (ldaps) and requests via unix
# sockets.
# Example usage:
# SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///"
SLAPD_SERVICES="ldaps:/// ldapi:///"

# If SLAPD_NO_START is set, the init script will not start or restart
# slapd (but stop will still work).  Uncomment this if you are
# starting slapd via some other means or if you don't want slapd normally
# started at boot.
#SLAPD_NO_START=1

# If SLAPD_SENTINEL_FILE is set to path to a file and that file exists,
# the init script will not start or restart slapd (but stop will still
# work).  Use this for temporarily disabling startup of slapd (when doing
# maintenance, for example, or through a configuration management system)
# when you don't want to edit a configuration file.
SLAPD_SENTINEL_FILE=/etc/ldap/noslapd

# For Kerberos authentication (via SASL), slapd by default uses the system
# keytab file (/etc/krb5.keytab).  To use a different keytab file,
# uncomment this line and change the path.
#export KRB5_KTNAME=/etc/krb5.keytab

# Additional options to pass to slapd
SLAPD_OPTIONS=""

11.7.3.3.2. Configurare il client

Sul client, la configurazione per i moduli libpam-ldap e libnss-ldap deve essere modificata per usare un URI ldaps://.

I cliet LDAP devono anche essere in grado di autenticare il server. In un'infrastruttura a chiave pubblica X.509, i certificati pubblici sono firmati con una chiave di un'autorità di certificazione (CA). Con easy-rsa, gli amministratori Falcot hanno creato la propria CA ed ora hanno bisogno di configurare il sistema per rendere fidate (trusted) le firme della CA di Falcot. Questo può essere fatto mettendo il certificato della CA in /usr/local/share/ca-certificates ed eseguendo update-ca-certificates.

# cp pki/ca.crt /usr/local/share/ca-certificates/falcot.crt
# update-ca-certificates
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...

Adding debian:falcot.pem
done.
done.

Ultimo ma non meno importante, l'URI LDAP predefinito e la base DN predefinita utilizzati dai vari strumenti della riga di comando possono essere modificati in /etc/ldap/ldap.conf. Ciò farà risparmiare un bel po' di battitura.

Esempio 11.26. Il file /etc/ldap/ldap.conf

#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

#BASE   dc=example,dc=com
#URI    ldap://ldap.example.com ldap://ldap-provider.example.com:666

#SIZELIMIT      12
#TIMELIMIT      15
#DEREF          never

# TLS certificates (needed for GnuTLS)
TLS_CACERT      /etc/ssl/certs/ca-certificates.crt