Product SiteDocumentation Site

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

DomandaRisposta
X.500 naming contextdc=falcot,dc=com
Nome host del server LDAPlocalhost
Manager DNcn=admin,dc=falcot,dc=com
Bind credentialsla password amministrativa
Create DUAConfigProfileno
Da notare che è stata estesa la variabile PERL5LIB. Questo è dovuto al bug report Debian #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

The NSS system (Name Service Switch, see sidebar APPROFONDIMENTO NSS ed i database di sistema) is a modular system designed to define or fetch information for system directories. Using LDAP as a source of data for NSS requires installing the libnss-ldapd package.
The /etc/nsswitch.conf file then needs to be modified, so as to configure NSS to use the freshly-installed ldap module.

Esempio 11.23. Il file /etc/nsswitch.conf

# /etc/nsswitch.conf
#
# 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.
The LDAP module for PAM is provided by the libpam-ldapd package. Installing this package asks a few questions very similar to those in libnss-ldapd; some configuration parameters (such as the URI for the LDAP server) are even actually shared with the libnss-ldapd package.
Installing libpam-ldapd automatically adapts the default PAM configuration defined in the /etc/pam.d/common-auth, /etc/pam.d/common-password and /etc/pam.d/common-account files. This mechanism uses the dedicated pam-auth-update tool (provided by the libpam-runtime package). This tool can also be run by the administrator should they wish to enable or disable PAM modules.

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
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
On the client side, the configuration for the libpam-ldapd and libnss-ldapd modules needs to be modified to use an ldaps:// URI.
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