Authentification TLS OpenLDAP


10

J'essaie d'implémenter TLS selon https://help.ubuntu.com/lts/serverguide/openldap-server.html Lorsque j'essaie de modifier la base de données cn = config avec ce fichier 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

J'obtiens l'erreur suivante:

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)

Qu'est-ce que je fais mal?

EDIT: lorsque j'essaie d'utiliser l'authentification simple, j'ai eu l'erreur suivante:

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

Vérifiez les autorisations sur les fichiers de certificat. Et supprimez également le mot de passe s'il est défini.
zeridon

Merci pour la réponse rapide. Les autorisations sont définies sur 644, sauf pour le fichier .key qui se trouve sur 600 Comment vérifier / supprimer le mot de passe? Je ne me souviens pas avoir défini de mot de passe pour cn = config ..
Amar Prasovic

2
Je veux dire mot de passe sur le certificat lui-même (pas sur cn = config). Vérifier: mnx.io/blog/removing-a-passphrase-from-an-ssl-key
zeridon

Non, ce n'était pas le cas. Le fichier de clés a été créé sans mot de passe.
Amar Prasovic

pouvez-vous essayer de charger le ldiff avec une authentification simple (pas -Y EXTERNAL)
zeridon

Réponses:


17

Je suivais le même guide et avais le même problème. Cela fonctionnera si vous effectuez les étapes pour "Resserrer la propriété et les autorisations" répertoriées après la commande ldapmodify incriminée en premier - à savoir:

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

et

sudo systemctl restart slapd.service

1
Cela a fonctionné pour moi aussi!
sonicwave

2
Dans mon cas, j'ai dû utiliser chgrp openldap. Quoi qu'il en soit, c'est un problème de permission. +1
xonya

le répertoire privé doit également être exécutable pour pouvoir être parcouru. sudo chgrp ssl-cert /etc/ssl/private && sudo chmod g+X /etc/ssl/private
Jeff Puckett

3

Eh bien, je ne sais pas s'il s'agit d'une solution ou simplement d'une solution de contournement, mais j'ai réussi à le faire fonctionner.

J'ai d'abord arrêté le slapd avec:

service slapd stop

Ensuite, je l'ai démarré en mode débogage:

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

L'important est de le démarrer UNIQUEMENT avec ldapi: /// URL. Après son démarrage, j'ai exécuté la commande ldapmodify et les attributs ont été importés.

À la fin, j'ai arrêté le mode débogage et démarré le slapd normalement.


2

Pour faire suite à la réponse d'A. Gutierrez , la meilleure façon de vérifier l'accès à chaque fichier est de l'exécuter sudo -u openldap cat <filename>. J'ai regardé tous les fichiers plusieurs fois et ils avaient l'air d'avoir des autorisations correctement définies. Il s'est avéré être un problème de groupe pour openldap. Une fois que j'ai finalement compris cela, un simple sudo usermod -a -G ssl-cert openldapproblème l'a résolu pour moi.


2

Parfois, le problème se trouve dans le profil de l'aparmeur pour le service slapd. Assurez-vous que le profil de l'apparmeur a autorisé les chemins de certificat pour le démon.

C'est assez visuellement /etc/apparmor.d/usr.sbin.slapd. Par défaut, ce profil permet de lire les certificats dans les emplacements par défaut.

Apparmor devrait empêcher les actions non spécifiées pour l'exécutable du démon, malgré les autorisations Unix appropriées.


Si vous utilisez letsencrypt, c'est la solution. Ajoutez les lignes suivantes à /etc/apparmor.d/usr.sbin.slapd: / etc / letsencrypt / r, / etc / letsencrypt / ** r, et rechargez les profils de l'apparmeur.
Bernhard

1

Comme je l'ai signalé dans ce bug sur Ubuntu Launchpad , ce problème peut également être causé par l'apparmeur. Habituellement, cela apparaîtra dans le syslog comme un refus d'accès.

Le correctif insère la ligne suivante dans /etc/apparmor.d/usr.sbin.slapd:

/etc/letsencrypt/** r,

puis actualiser le profil:

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

0

J'ai aussi ce problème. Le problème est que l'utilisateur exécutant slapd n'avait pas accès aux fichiers de certificats. Vérifiez que le propriétaire de ces fichiers est un utilisateur openldap.


0

Pour moi, le problème était dans le mauvais ordre des enregistrements - voici celui qui a fonctionné:

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

0

Malheureusement, cela semble être l'erreur "par défaut" que vous obtenez pour à peu près n'importe quoi. La réponse de @ wulfsdad le corrige généralement.

Une autre chose que j'oublie toujours, c'est que par défaut sur ubuntu slapd veut la clé au format openssl. J'ai l'habitude mais les touches PCKS # 8 dedans et je m'attends à ce que ça marche (ce qui pour être juste devrait). Si vous avez essayé toutes les réponses ci-dessus, assurez-vous également que la clé a le bon format. Lorsque vous recherchez l'erreur sur Google, vous lisez généralement les mauvaises autorisations et vous vous demandez pourquoi apache fonctionne avec la clé que slapd n'aime pas.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.