Autenticación OpenLDAP TLS


10

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 intento usar autenticación simple, aparece 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

Verifique los permisos en los archivos de certificado. Y también elimine la contraseña si está configurada.
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

2
Me refiero a la contraseña en el certificado en sí (no en cn = config). Compruebe: mnx.io/blog/removing-a-passphrase-from-an-ssl-key
zeridon

No, ese no fue el caso. El archivo de clave se creó sin contraseña.
Amar Prasovic

¿Puedes intentar cargar el ldiff con autenticación simple (no -Y EXTERNA)
zeridon

Respuestas:


17

Estaba siguiendo la misma guía y tuve el mismo problema. Funcionará si realiza primero los pasos para "Ajustar la propiedad y los permisos" enumerados después del comando ofensivo ldapmodify, 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

1
¡Esto funcionó para mí también!
sonicwave

2
En mi caso tuve que usar chgrp openldap. De todos modos, es un problema de permiso. +1
xonya

El directorio privado también debe ser ejecutable para poder atravesarlo. sudo chgrp ssl-cert /etc/ssl/private && sudo chmod g+X /etc/ssl/private
Jeff Puckett

3

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

Primero detuve la bofetada con:

service slapd stop

Luego lo comencé en modo de depuración:

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

Lo importante es comenzar SOLO con ldapi: /// URL. Después de que comencé, ejecuté el comando ldapmodify y los atributos fueron importados.

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


2

Como seguimiento a la 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 permisos configurados correctamente. Resultó ser un problema grupal para openldap. Una vez que finalmente lo descubrí, un simple sudo usermod -a -G ssl-cert openldapme lo resolvió.


2

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

Es bastante visualmente adentro /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 demonio, a pesar de los permisos adecuados de Unix.


Si usa letsencrypt, esta es la solución. Agregue 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 el

1

Como informé en este error en Ubuntu Launchpad , este problema también puede ser causado por apparmor. Por lo general, esto se mostrará en el registro del sistema como una denegación de acceso.

La solución es insertar la siguiente línea en /etc/apparmor.d/usr.sbin.slapd:

/etc/letsencrypt/** r,

y luego refrescando el perfil:

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

0

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

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

Desafortunadamente, este parece ser el error "predeterminado" que obtienes por casi cualquier cosa. La respuesta de @wulfsdad generalmente lo arregla.

Otra cosa que siempre olvido es que, de manera predeterminada, ubuntu slapd quiere la clave en formato openssl. Regularmente, pero PCKS # 8 ingresa y espero que funcione (lo que para ser justo debería ser). Si probó todas las respuestas anteriores, también asegúrese de que la clave tenga el formato correcto. Cuando buscas en Google el error, generalmente lees sobre permisos incorrectos y te frotas la cabeza por qué apache funciona con la misma tecla que a slapd no le gusta.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.