Pregunta Autentificación OpenLDAP TLS


Estoy tratando de implementar TLS según https://help.ubuntu.com/lts/serverguide/openldap-server.html Cuando intento modificar la base de datos cn = config con este archivo 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

Obtuve el siguiente error:

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é estoy haciendo mal?

EDITAR: Cuando trato de usar autenticación simple recibí el siguiente error:

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

9
2017-07-10 08:31


origen


Compruebe los permisos en los archivos de certificado. Y también eliminar la contraseña si se establece tal. - zeridon
Gracias por la rápida respuesta. Los permisos están establecidos en 644, excepto para el archivo .key que está en 600 ¿Cómo verifico / elimino la contraseña? No recuerdo haber configurado ninguna contraseña para cn = config. - Amar Prasovic
Me refiero a la contraseña en el certificado en sí (no en cn = config). Comprobar: mnx.io/blog/removing-a-passphrase-from-an-ssl-key - zeridon
No, ese no fue el caso. El archivo clave fue creado sin contraseña. - Amar Prasovic
puede intentar cargar el ldiff con autenticación simple (no -Y EXTERNAL) - zeridon


Respuestas:


Estaba siguiendo la misma guía y tenía el mismo problema. Funcionará si realiza los pasos para "Ajustar la propiedad y los permisos" enumerados después del comando ofensivo ldapmodify primero, a saber:

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

y

sudo systemctl restart slapd.service

13
2018-06-19 19:58



¡Esto funcionó para mí también! - sonicwave
En mi caso tuve que usar chgrp openldap. De todos modos, es un problema de permiso. +1 - xonya
también el directorio privado debe ser ejecutable también para atravesar. sudo chgrp ssl-cert /etc/ssl/private && sudo chmod g+X /etc/ssl/private - Jeff Puckett


Como seguimiento a Respuesta de A. Gutiérrez, la mejor manera de verificar el acceso para cada archivo es ejecutar sudo -u openldap cat <filename>. Miré todos los archivos varias veces y parecían tener los permisos configurados correctamente. Resultó ser un problema de grupo para openldap. Una vez que finalmente me di cuenta de eso, un simple sudo usermod -a -G ssl-cert openldap lo resolvió por mi


2
2018-05-28 13:03





Bueno, no sé si esto es una solución o solo una solución alternativa, pero logré que funcionara.

Primero detuve el slapd con:

service slapd stop

Entonces lo empecé en modo de depuración:

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

Es importante iniciarlo SOLAMENTE con ldapi: /// URL. Después de que se inició, ejecuté el comando ldapmodify y se importaron los atributos.

Al final detuve el modo de depuración y comencé el slapd normalmente.


1
2017-07-10 13:03





A veces, el problema está en el perfil de apparmor para el servicio slapd. Asegúrese de que el perfil de apparmor haya permitido las rutas de certificado para el daemon.

Es bastante visual en /etc/apparmor.d/usr.sbin.slapd. Por defecto, este perfil permite leer certificados en ubicaciones predeterminadas.

Apparmor debería evitar acciones no especificadas para el ejecutable del daemon, a pesar de los permisos adecuados de Unix.


1
2017-09-12 11:21



Si utiliza letsencrypt, esta es la solución. Agrega las siguientes líneas a /etc/apparmor.d/usr.sbin.slapd: / etc / letsencrypt / r, / etc / letsencrypt / ** r, y vuelva a cargar los perfiles de apparmor. - Bernhard


Tengo este problema también. El problema es que el usuario que ejecuta slapd no tiene acceso a los archivos certs. Echa un vistazo a que el propietario de esos archivos es un usuario openldap.


0
2018-01-27 12:30





Para mí, el problema estaba en el orden incorrecto de los registros. Aquí está el que funcionó:

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
2017-12-14 16:27





Desafortunadamente, este parece ser el error "predeterminado" que se obtiene por casi cualquier cosa. La respuesta de @Wulfsdad por lo general lo arregla.

Otra cosa que siempre olvido es que, de forma predeterminada, en ubuntu slapd quiere que la clave esté en formato openssl. Regularmente, pero PCKS # 8 ingresa y espera que solo funcione (lo cual para ser justo debería). Si probó todas las respuestas anteriores, también asegúrese de que la clave tenga el formato correcto. Cuando busques en Google el error, por lo general lees sobre los permisos incorrectos y frota la cabeza por qué apache funciona con la clave que a slapd no le gusta.


0
2018-01-23 18:25