Servizio directory con LDAP [4]: ​​OpenLDAP (I)

Ciao amici!. Mettiamoci al lavoro e, come consigliamo sempre, leggiamo i tre articoli precedenti della serie:

• Servizio di directory con LDAP. introduzione.
• Servizio directory con LDAP [2]: NTP e dnsmasq.
• Servizio directory con LDAP [3]: Isc-DHCP-Server e Bind9.

DNS, DHCP e NTP sono i servizi minimi essenziali per la nostra semplice directory basata su OpenLDAP nativo, funziona correttamente su Debian 6.0 "Squeeze", o in Ubuntu 12.04 LTS "Precise Pangolin".

Rete di esempio:

Lan: 10.10.10.0/24
Dominio: amigos.cu
Servidor: mildap.amigos.cu
Sistema Operativo Servidor: Debian 6 "Squeeze
Dirección IP del servidor: 10.10.10.15
Cliente 1: debian7.amigos.cu
Cliente 2: raring.amigos.cu
Cliente 3: suse13.amigos.cu
Cliente 4: seven.amigos.cu

Nella prima parte vedremo:

• Installazione di OpenLDAP (schiaffeggiato 2.4.23-7.3)
• Controlli dopo l'installazione
• Indici da tenere in considerazione
• Regole di controllo dell'accesso ai dati
• Generazione di certificati TLS in Squeeze

mentre nella seconda parte continueremo con:

• Autenticazione utente locale
• Popolare il database
• Gestisci il database utilizzando le utilità della console
• Riepilogo finora ...

Installazione di OpenLDAP (schiaffeggiato 2.4.23-7.3)

Il server OpenLDAP viene installato utilizzando il pacchetto schiaffo. Dobbiamo anche installare il pacchetto ldap-utils, che ci fornisce alcuni strumenti lato client, oltre a utilità proprie di OpenLDAP.

: ~ # aptitude install slapd ldap-utils

Durante il processo di installazione, il debconf Ci chiederà la password dell'amministratore o dell'utente «Admin«. Inoltre vengono installate numerose dipendenze; l'utente viene creato apri l'app; viene creata la configurazione del server iniziale e la directory LDAP.

Nelle versioni precedenti di OpenLDAP, la configurazione del daemon schiaffo è stato eseguito interamente tramite il file /etc/ldap/slapd.conf. Nella versione che stiamo utilizzando e successivamente, la configurazione viene eseguita nella stessa schiaffo, ea questo scopo a DIT «Albero delle informazioni della directory»Oppure albero delle informazioni della directory, separatamente.

Il metodo di configurazione noto come RTC «Configurazione in tempo reale»Configurazione in tempo reale o come metodo cn = config, ci consente di configurare dinamicamente il file schiaffo senza richiedere un riavvio del servizio.

Il database di configurazione è costituito da una raccolta di file di testo nel formato LDIF «Formato di interscambio dati LDAP»Formato LDAP per scambio dati, situato nella cartella /etc/ldap/slapd.d.

Per avere un'idea dell'organizzazione delle cartelle schiaffo.d, corriamo:

: ~ # ls -lR /etc/ldap/slapd.d/
/etc/ldap/slapd.d/: totale 8 drwxr-x --- 3 openldap openldap 4096 16 febbraio 11:08 cn = config -rw ------- 1 openldap openldap 407 16 febbraio 11:08 cn = config.ldif /etc/ldap/slapd.d/cn=config: totale 28 -rw ------- 1 openldap openldap 383 16 febbraio 11:08 cn = module {0} .ldif drwxr-x --- 2 openldap openldap 4096 16 febbraio 11:08 cn = schema -rw ------- 1 openldap openldap 325 16 febbraio 11:08 cn = schema.ldif -rw ------- 1 openldap openldap 343 16 febbraio 11:08 olcBackend = {0} hdb.ldif -rw ------- 1 openldap openldap 472 16 febbraio 11:08 olcDatabase = {0} config.ldif -rw ------- 1 openldap openldap 586 16 febbraio 11:08 olcDatabase = {- 1} frontend.ldif -rw ------- 1 openldap openldap 1012 16 febbraio 11:08 olcDatabase = {1} hdb.ldif /etc/ldap/slapd.d/cn = config / cn = schema: totale 40 -rw ------- 1 openldap openldap 15474 16 febbraio 11:08 cn = {0} core.ldif -rw ------- 1 openldap openldap 11308 16 febbraio 11:08 cn = {1} cosine.ldif -rw ------- 1 openldap openldap 6438 16 febbraio 11:08 cn = {2} nis.ldif -rw ------- 1 openldap openldap 2802 16 febbraio 11:08 cn = {3} inetorgperson.ldif

Se guardiamo un po 'l'output precedente, vediamo che il file BACKEND utilizzato in Squeeze è il tipo di database hdb, che è una variante di bdb "Berkeley Database", e che è completamente gerarchico e supporta la ridenominazione dei sottoalberi. Per saperne di più sul possibile backend che supporta OpenLDAP, visita http://es.wikipedia.org/wiki/OpenLDAP.

Vediamo anche che vengono utilizzati tre database separati, ovvero uno dedicato alla configurazione, un altro a Frontende l'ultimo che è il database hdb di per sé.

Inoltre, schiaffo è installato di default con gli schemi Nucleo, coseno, Nis e persona di internet.

Controlli dopo l'installazione

In un terminale eseguiamo e leggiamo con calma le uscite. Verificheremo, soprattutto con il secondo comando, la configurazione desunta dall'elenco della cartella schiaffo.d.

: ~ # ldapsearch -Q -LLL -Y ESTERNO -H ldapi: /// -b cn = config | altro: ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b cn = config dn
dn: cn = config dn: cn = module {0}, cn = config dn: cn = schema, cn = config dn: cn = {0} core, cn = schema, cn = config dn: cn = {1} coseno , cn = schema, cn = config dn: cn = {2} nis, cn = schema, cn = config dn: cn = {3} inetorgperson, cn = schema, cn = config dn: olcBackend = {0} hdb, cn = config dn: olcDatabase = {- 1} frontend, cn = config dn: olcDatabase = {0} config, cn = config dn: olcDatabase = {1} hdb, cn = config

Spiegazione di ogni uscita:

• cn = config: Parametri globali.
• cn = modulo {0}, cn = config: Modulo caricato dinamicamente.
• cn = schema, cn = config: Contiene il file hardcoded a livello degli schemi di sistema.
• cn = {0} core, cn = schema, cn = config: L' hardcoded dello schema del kernel.
• cn = {1} coseno, cn = schema, cn = config: Lo schema Coseno.
• cn = {2} nis, cn = schema, cn = config: Lo schema Nis.
• cn = {3} inetorgperson, cn = schema, cn = config: Lo schema persona di internet.
• olcBackend = {0} hdb, cn = config: BACKEND tipo di archiviazione dei dati hdb.
• olcDatabase = {- 1} frontend, cn = config: Frontend del database e parametri di default per gli altri database.
• olcDatabase = {0} config, cn = config: database di configurazione di schiaffo (cn = config).
• olcDatabase = {1} hdb, cn = config: la nostra istanza del database (dc = amici, dc = cu)

: ~ # ldapsearch -x -LLL -H ldap: /// -b dc = esempio, dc = com dn
dn: dc = amici, dc = cu dn: cn = admin, dc = amici, dc = cu

• dc = amici, dc = cu: Albero delle informazioni della directory di base DIT
• cn = admin, dc = friends, dc = cu: Amministratore (rootDN) del DIT dichiarato durante l'installazione.

Nota: Il suffisso di base dc = amici, dc = cu, l'ha preso debconf durante l'installazione da FQDN dal server Milap.amigos.cu.

Indici da tenere in considerazione

L'indicizzazione delle voci viene effettuata per migliorare le prestazioni delle ricerche sul DIT, con criteri di filtro. Gli indici che prenderemo in considerazione sono i minimi consigliati in base agli attributi dichiarati negli schemi di default.

Per modificare dinamicamente gli indici nel database, creiamo un file di testo nel formato LDIFe successivamente lo aggiungiamo al database. Creiamo il file olcDbIndex.ldif e lo lasciamo con il seguente contenuto:

: ~ # nano olcDbIndex.ldif
dn: olcDatabase = {1} hdb, cn = config changetype: modify add: olcDbIndex olcDbIndex: uidNumber eq - aggiungi: olcDbIndex olcDbIndex: gidNumber eq - aggiungi: olcDbIndex olcDbIndex: memberUidbIndex eq olcDbInde, olcDbIndex, olcDbInde, olcDbIndex: : loginShell eq, olcDbIndex: login - aggiungi: olcDbIndex olcDbIndex: uid pres, sub, eq - aggiungi: olcDbIndex olcDbIndex: cn pres, sub, eq - aggiungi: olcDbIndex olcDbIndex: sn pres, sub, eqDbIndex add: olcDbIndex , ou pres, eq, sub - aggiungi: olcDbIndex olcDbIndex: displayName pres, sub, eq - aggiungi: olcDbIndex olcDbIndex: default sub - aggiungi: olcDbIndex olcDbIndex: mail eq, subinitial - aggiungi: olcDbIndex olcDbIndex: dcDbIndex

Aggiungiamo gli indici al database e controlliamo la modifica:

: ~ # ldapmodify -Y ESTERNO -H ldapi: /// -f ./olcDbIndex.ldif

: ~ # ldapsearch -Q -LLL -Y ESTERNO -H ldapi: /// -b \ cn = config '(olcDatabase = {1} hdb)' olcDbIndex

dn: olcDatabase = {1} hdb, cn = config olcDbIndex: objectClass eq olcDbIndex: uidNumber, gidNumber eq olcDbIndex: memberUid eq, pres, sub olcDbIndex: loginShell eq olcDbIndex: uid pres, olc pres, pres, eq olcDbIndex: sn pres, sub, eq olcDbIndex: givenName, ou pres, eq, sub olcDbIndex: displayName pres, sub, eq olcDbIndex: default sub olcDbIndex: mail eq, subinitial olcDbIndex: dc eq

Regole di controllo dell'accesso ai dati

Le regole che vengono stabilite in modo che gli utenti possano leggere, modificare, aggiungere ed eliminare i dati nel database della Directory sono chiamate Controllo degli accessi, mentre chiameremo Elenchi di controllo degli accessi o «Elenco di controllo degli accessi ACL»Ai criteri che configurano le regole.

Per sapere quale ACL sono stati dichiarati per impostazione predefinita durante il processo di installazione di schiaffo, eseguiamo:

: ~ # ldapsearch -Q -LLL -Y ESTERNO -H ldapi: /// -b \
cn = config '(olcDatabase = {1} hdb)' olcAccess

: ~ # ldapsearch -Q -LLL -Y ESTERNO -H ldapi: /// -b \
cn = config '(olcDatabase = {- 1} frontend)' olcAccess

: ~ # ldapsearch -Q -LLL -Y ESTERNO -H ldapi: /// -b \
cn = config '(olcDatabase = {0} config)' olcAccess

: ~ # ldapsearch -Q -LLL -Y ESTERNO -H ldapi: /// -b \
cn = config '(olcAccess = *)' olcAccess olcSuffix

Ciascuno dei comandi precedenti ci mostrerà il file ACL che fino ad ora abbiamo dichiarato nel nostro Directory. Nello specifico, l'ultimo comando li mostra tutti, mentre i primi tre ci danno le regole di controllo degli accessi per tutti e tre. DIT coinvolti nel nostro schiaffo.

Sul tema ACL e per non fare un articolo molto più lungo, consigliamo di leggere le pagine di manuale uomo schiaffo.accesso.

Per garantire l'accesso degli utenti e degli amministratori per aggiornare le loro voci di loginShell y Gechi, aggiungeremo il seguente ACL:

## Creiamo il file olcAccess.ldif e lo lasciamo con il seguente contenuto: ~ # nano olcAccess.ldif
dn: olcDatabase = {1} hdb, cn = config changetype: modify add: olcAccess olcAccess: {1} to attrs = loginShell, gecos by dn = "cn = admin, dc = friends, dc = cu" write by self write by * leggere

## Aggiungiamo l'ACL
: ~ # ldapmodify -Y EXTERNAL -H ldapi: /// -f ./olcAccess.ldif

# Controlliamo le modifiche
ldapsearch -Q -LLL -Y ESTERNO -H ldapi: /// -b \
cn = config '(olcAccess = *)' olcAccess olcSuffix

Generazione di certificati TLS in Squeeze

Per avere un'autenticazione sicura con il server OpenLDAP, dobbiamo farlo tramite una sessione crittografata che possiamo ottenere utilizzando il TLS «Sicurezza del livello di trasporto» o Secure Transport Layer.

Il server OpenLDAP ei suoi client sono in grado di utilizzare l'estensione contesto TLS per fornire protezione in materia di integrità e riservatezza, nonché per supportare un'autenticazione LDAP sicura tramite il meccanismo SASL «Autenticazione semplice e livello di sicurezza« Esterno.

I moderni server OpenLDAP favoriscono l'uso di */ StartTLS /* o Avvia un Secure Transport Layer per /LDAPS: ///, che è obsoleto. Per qualsiasi domanda, visita * Avvia TLS v. ldaps: // * en http://www.openldap.org/faq/data/cache/605.html

Lascia il file come installato per impostazione predefinita / etc / default / slapd con la dichiarazione SLAPD_SERVICES = »ldap: /// ldapi: ///», con l'obiettivo di utilizzare un canale crittografato tra il client e il server, e le stesse applicazioni ausiliarie per gestire gli OpenLDAP installati localmente.

Il metodo qui descritto, basato sui pacchetti gnutls-bin y SSL-cert è valido per Debian 6 "Squeeze" e anche per Ubuntu Server 12.04. Per Debian 7 "Wheezy" un altro metodo basato su OpenSSL.

La generazione dei certificati in Squeeze viene eseguita come segue:

1.- Installiamo i pacchetti necessari
: ~ # aptitude install gnutls-bin ssl-cert

2.- Creiamo la chiave primaria per l'autorità di certificazione
: ~ # sh -c "certtool --generate-privkey> /etc/ssl/private/cakey.pem"

3.- Creiamo un modello per definire la CA (Autorità di certificazione)
: ~ # nano /etc/ssl/ca.info cn = Cuban Friends ca cert_signing_key

4.- Creiamo il certificato autofirmato o autofirmato CA per i clienti
: ~ # certtool --generate-self-signed \ --load-privkey /etc/ssl/private/cakey.pem \ --template /etc/ssl/ca.info \ --outfile / etc / ssl / certs / cacert.pem

5.- Generiamo una chiave privata per il server
: ~ # certtool --generate-privkey \ --bits 1024 \ --outfile /etc/ssl/private/mildap-key.pem

Nota: Sostituisci "Mildap"nel nome del file sopra per il tuo server. Assegnare un nome al certificato e alla chiave, sia per il server che per il servizio che lo utilizza, ci aiuta a mantenere le cose chiare.

6.- Creiamo il file /etc/ssl/mildap.info con il seguente contenuto:
: ~ # nano /etc/ssl/mildap.info organization = Cuban Friends cn = mildap.amigos.cu tls_www_server encryption_key signing_key expiration_days = 3650

Nota: Nel contenuto precedente si dichiara che il certificato è valido per un periodo di tempo di 10 anni. Il parametro deve essere regolato secondo la nostra convenienza.

7.- Creiamo il certificato del server
: ~ # certtool --generate-certificate \ --load-privkey /etc/ssl/private/mildap-key.pem \ --load-ca-certificate /etc/ssl/certs/cacert.pem \ --load- ca-privkey /etc/ssl/private/cakey.pem \ --template /etc/ssl/mildap.info \ --outfile /etc/ssl/certs/mildap-cert.pem

Finora abbiamo generato i file necessari, dobbiamo solo aggiungere alla Directory la posizione del certificato autofirmato cacert; quella del certificato server milap-cert.pem; e la chiave privata del server chiave-milap.pem. Dobbiamo anche modificare le autorizzazioni e il proprietario dei file generati.

: ~ # nano /etc/ssl/certinfo.ldif
dn: cn = config add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem - aggiungi: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/mildap-cert.pem / privateSCertificate ecc. -key.pem

8.- Aggiungiamo: ~ # ldapmodify -Y EXTERNAL -H ldapi: /// -f /etc/ssl/certinfo.ldif

9.- Regoliamo proprietario e autorizzazioni
: ~ # adduser openldap ssl-cert: ~ # chgrp ssl-cert /etc/ssl/private/mildap-key.pem: ~ # chmod g + r /etc/ssl/private/mildap-key.pem: ~ # chmod o /etc/ssl/private/mildap-key.pem

Il certificato cacert È quello che dobbiamo copiare in ogni client. Affinché questo certificato possa essere utilizzato sul server stesso, dobbiamo dichiararlo nel file /etc/ldap/ldap.conf. Per fare ciò, modifichiamo il file e lo lasciamo con il seguente contenuto:

: ~ # nano /etc/ldap/ldap.conf
BASE dc = friends, dc = cu URI ldap: //mildap.amigos.cu TLS_CACERT /etc/ssl/certs/cacert.pem

Infine, anche per verifica, riavviamo il servizio schiaffo e controlliamo l'output di syslog dal server, per scoprire se il servizio è stato riavviato correttamente utilizzando il certificato appena dichiarato.

: ~ # service slapd riavvio
: ~ # tail / var / log / syslog

Se il servizio non si riavvia correttamente o si osserva un grave errore nel file syslog, non scoraggiamoci. Possiamo provare a riparare il danno o ricominciare da capo. Se decidiamo di ricominciare da zero l'installazione del file schiaffo, non è necessario formattare il nostro server.

Per cancellare tutto ciò che abbiamo fatto finora per un motivo o per l'altro, dobbiamo disinstallare il pacchetto schiaffoe quindi elimina la cartella / var / lib / ldap. Dobbiamo anche lasciare il file nella sua versione originale /etc/ldap/ldap.conf.

È raro che tutto funzioni correttamente al primo tentativo. 🙂

Ricorda che nella prossima puntata vedremo:

• Autenticazione utente locale
• Popolare il database
• Gestisci il database utilizzando le utilità della console
• Riepilogo finora ...

A presto amici !.