Autenticazione TLS OpenLDAP

10

Sto cercando di implementare TLS secondo https://help.ubuntu.com/lts/serverguide/openldap-server.html Quando provo a modificare il database cn = config con questo file ldif:

dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/test-ldap-server_cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/test-ldap-server_key.pem

Ottengo il seguente errore:

ldapmodify -Y EXTERNAL -H ldapi:/// -f certinfo.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"
ldap_modify: Other (e.g., implementation specific) error (80)

Che cosa sto facendo di sbagliato?

EDIT: quando provo ad usare l'autent semplice ho ricevuto il seguente errore:

ldapmodify -x -D cn=admin,dc=example,dc=com -W -f certinfo.ldif
Enter LDAP Password:
ldap_bind: Invalid DN syntax (34)
        additional info: invalid DN

openldap tls

— Amar Prasovic
fonte

Controlla le autorizzazioni sui file del certificato. E rimuovi anche la password se tale è impostata.

— Zeridon,

Grazie per la risposta rapida. Le autorizzazioni sono impostate su 644 ad eccezione del file .key che è su 600 Come posso controllare / rimuovere la password? Non ricordo di aver impostato alcuna password per cn = config ..

— Amar Prasovic,

2

Intendo la password sul certificato stesso (non su cn = config). Controlla: mnx.io/blog/removing-a-passphrase-from-an-ssl-key

— zeridon

No, non era così. Il file chiave è stato creato senza password.

— Amar Prasovic,

puoi provare a caricare ldiff con semplice auth (non -Y EXTERNAL)

— zeridon,

17

Stavo seguendo la stessa guida e ho avuto lo stesso problema. Funzionerà se esegui i passaggi per "Restringere la proprietà e le autorizzazioni" elencati dopo prima il comando offensivo ldapmodify, ovvero:

sudo adduser openldap ssl-cert
sudo chgrp ssl-cert /etc/ssl/private
sudo chgrp ssl-cert /etc/ssl/private/ldap01_slapd_key.pem
sudo chmod g+X /etc/ssl/private
sudo chmod g+r /etc/ssl/private/ldap01_slapd_key.pem

e

sudo systemctl restart slapd.service

— Hildigerr
fonte

1

Questo ha funzionato anche per me!

— sonicwave,

2

Nel mio caso ho dovuto usare chgrp openldap. Comunque, è un problema di autorizzazione. +1

— xonya,

anche la directory privata deve essere eseguibile per poter attraversare. sudo chgrp ssl-cert /etc/ssl/private && sudo chmod g+X /etc/ssl/private

— Jeff Puckett,

3

Beh, non so se questa è una soluzione o solo una soluzione alternativa, ma sono riuscito a farlo funzionare.

Per prima cosa ho fermato lo slapd con:

service slapd stop

Quindi l'ho avviato in modalità debug:

slapd -h ldapi:/// -u openldap -g openldap -d 65 -F /etc/ldap/slapd.d/ -d 65

È importante avviarlo SOLO con ldapi: /// URL. Dopo l'avvio, ho eseguito il comando ldapmodify e gli attributi sono stati importati.

Alla fine ho interrotto la modalità debug e ho avviato lo slapd normalmente.

— Amar Prasovic
fonte

2

Come seguito alla risposta di A. Gutierrez , il modo migliore per verificare l'accesso per ciascun file è quello di eseguire sudo -u openldap cat <filename>. Ho guardato tutti i file più volte e hanno cercato di avere le autorizzazioni impostate correttamente. Si è rivelato essere un problema di gruppo per openldap. Una volta finalmente capito, un semplice sudo usermod -a -G ssl-cert openldaprisolto per me.

— Rob Archibald
fonte

2

A volte il problema è nel profilo apparmor per il servizio slapd. Assicurati che il profilo apparmor abbia consentito i percorsi dei certificati per il demone.

È abbastanza visivamente dentro /etc/apparmor.d/usr.sbin.slapd. Per impostazione predefinita, questo profilo consente di leggere i certificati nelle posizioni predefinite.

Apparmor dovrebbe impedire azioni non specificate per l'eseguibile del demone, nonostante le autorizzazioni unix appropriate.

— vskubriev
fonte

Se usi letsencrypt, questa è la soluzione. Aggiungi le seguenti righe a /etc/apparmor.d/usr.sbin.slapd: / etc / letsencrypt / r, / etc / letsencrypt / ** r e ricarica i profili di apparmor.

— Bernhard

1

Come riportato in questo bug su Ubuntu Launchpad , questo problema può anche essere causato da apparmor. Di solito questo verrà mostrato nel syslog come rifiuto di accesso.

La correzione sta inserendo la seguente riga in /etc/apparmor.d/usr.sbin.slapd:

/etc/letsencrypt/** r,

e quindi aggiornando il profilo:

# apparmor_parser -vr usr.sbin.slapd
# service apparmor restart

— Tarek Loubani
fonte

0

Ho anche questo problema. Il problema è che l'utente che esegue slapd non ha accesso ai file certs. Controlla che il proprietario di quei file sia un utente openldap.

— A. Gutierrez
fonte

0

Per me il problema era nell'ordine sbagliato dei registri - ecco quello che ha funzionato:

dn: cn=config
changetype: modify
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cm_ca_cert.pem
-
# This never worked for me, no idea why
#add: olcTLSCipherSuite
#olcTLSCipherSuite: TLSv1+RSA:!NULL
#-
replace: olcTLSVerifyClient
olcTLSVerifyClient: never
-
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/cm_server.pem
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/cm_server.key

— Arie Skliarouk
fonte

0

Purtroppo questo sembra essere l'errore "predefinito" che si ottiene praticamente per qualsiasi cosa. La risposta di @ wulfsdad di solito lo risolve.

Un'altra cosa che dimentico sempre è che per impostazione predefinita su Ubuntu slapd vuole la chiave in formato openssl. Sono abituale, ma PCKS # 8 si inserisce e mi aspetto che funzioni (il che dovrebbe essere giusto). Se hai provato tutte le risposte sopra, assicurati anche che la chiave abbia il formato giusto. Quando si cerca su Google l'errore che si legge di solito su autorizzazioni errate e si sfrega la testa perché Apache funziona con lo slapd chiave non piace.

— user3240383
fonte