Configura el servidor LDAP de Freston para que utilice el protocolo ldaps:// a la vez que el ldap:// utilizando el certificado x509 de la práctica de HTTPS o solicitando el correspondiente a través de gestiona. Realiza las modificaciones adecuadas en el cliente LDAP de Freston para que todas las consultas se realicen por defecto utilizando ldaps://
Si quieres saber como instalar un servidor LDAP, puedes consultar este post.
Si queremos configurar Freston para que utilice el protocolo ldaps:// y que así la información viaje cifrada y de manera segura, lo primero que debemos hacer es solicitar el certificado. En mi caso, voy a solicitar un certificado wildcard ya que posteriormente voy a necesitar utilizarlo en otras máquinas que se encuentran bajo el mismo dominio que Freston (xxxxx.javierpzh.gonzalonazareno.org).
Para crear este certificado, vamos a crear una clave privada de 4096 bits, para ello vamos a utilizar openssl. Vamos a guardar esta clave en el directorio /etc/ssl/private/. Para crear esta clave privada empleamos el siguiente comando:
root@freston:~# openssl genrsa 4096 > /etc/ssl/private/freston.key Generating RSA private key, 4096 bit long modulus (2 primes) .........................................++++ ...........................................................................................................................++++ e is 65537 (0x010001)
Debemos cambiarle los permisos a la clave privada a 400, así únicamente el propietario podrá leer el contenido. Para ello, haremos uso de la herramienta chmod:
root@freston:/etc/ssl/private# ls -l total 4 -rw-r--r-- 1 root root 3243 Dec 18 08:59 freston.key root@freston:/etc/ssl/private# chmod 400 /etc/ssl/private/freston.key root@freston:/etc/ssl/private# ls -l total 4 -r-------- 1 root root 3243 Dec 18 08:59 freston.key
Pero claro, también hay que pensar que el usuario de LDAP debe poder leer esta clave, así que, para ello, he decidido crear una ACL para que únicamente este usuario, llamado openldap tenga acceso a la clave privada. Para ello instalamos el paquete acl:
apt install acl -y
Y creamos la ACL adecuada:
root@freston:# setfacl -m u:openldap:r-x /etc/ssl/private/ root@freston:# setfacl -m u:openldap:r-x /etc/ssl/private/freston.key
Lo siguiente sería generar una solicitud de firma de certificado, es decir, un fichero .csr, que posteriormente enviaremos a la entidad del Gonzalo Nazareno para que nos lo firmen.
Para generar nuestro archivo .csr:
root@freston:~# openssl req -new -key /etc/ssl/private/freston.key -out /root/wildcard.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:ES State or Province Name (full name) [Some-State]:Sevilla Locality Name (eg, city) []:Dos Hermanas Organization Name (eg, company) [Internet Widgits Pty Ltd]:IES Gonzalo Nazareno Organizational Unit Name (eg, section) []:Informatica Common Name (e.g. server FQDN or YOUR name) []:*.javierpzh.gonzalonazareno.org Email Address []:javierperezhidalgo01@gmail.com Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: root@freston:~# ls wildcard.csr
Como Freston es una instancia del cloud, voy a pasarme este fichero wildcard.csr a mi máquina anfitriona para enviárselo a la entidad certificadora, que en este caso es el Gonzalo Nazareno.
Si quieres entender mejor la estructura del escenario donde estamos trabajando puedes echarle un vistazo a este post, Modificación del escenario de trabajo en OpenStack.
Por tanto, pasaré este archivo a mi equipo mediante scp.
Una vez tenemos el certificado firmado por la entidad certificadora, lo pasamos a Freston. También hemos tenido que descargar el certificado de la entidad Gonzalo Nazareno. Por tanto lo vamos a mover también a Freston.
root@freston:~# ls gonzalonazareno.crt wildcard.crt wildcard.csr
Lógicamente, estos certificados no debemos dejarlos en este directorio, por lo que, los vamos a mover a la ruta /etc/ssl/certs:
root@freston:~# mv gonzalonazareno.crt /etc/ssl/certs/ root@freston:~# mv wildcard.crt /etc/ssl/certs/
Es importante que ambos archivos, posean a root como usuario y grupo propietario, por tanto le cambio el propietario y el grupo:
root@freston:/etc/ssl/certs# chown -R root:root wildcard.crt root@freston:/etc/ssl/certs# chown -R root:root gonzalonazareno.crt
Aquí podemos ver el resultado:
root@freston:~# ls -l /etc/ssl/certs/ | grep gonzalo -rw-r--r-- 1 root root 3634 Dec 18 09:34 gonzalonazareno.crt root@freston:~# ls -l /etc/ssl/certs/ | grep wildcard -rw-r--r-- 1 root root 10119 Dec 18 09:29 wildcard.crt
Vamos a crear de nuevo las ACL adecuadas para que el usuario openldap pueda leer estos archivos:
root@freston:~# setfacl -m u:openldap:r-x /etc/ssl/certs/gonzalonazareno.crt root@freston:~# setfacl -m u:openldap:r-x /etc/ssl/certs/wildcard.crt
Ya tenemos todos los certificados almacenados correctamente y con los usuarios/grupos/permisos adecuados.
Es la primera vez que estoy utilizando LDAP, y me ha sorprendido mucho la manera en la que se realiza su configuración, ya que no vamos a llevar a cabo las modificaciones en unos ficheros de configuración como es lo habitual, sino que vamos a crear un fichero .ldif, como los que creamos para introducir objetos. Esto se debe a que, de esta manera, podremos manipular la configuración sin tener que reiniciar el servicio, por tanto, nunca dejaría de funcionar.
Creamos el fichero .ldif e introducimos las siguientes líneas:
dn: cn=config changetype: modify replace: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/gonzalonazareno.crt - replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/freston.key - replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/wildcard.crt
Una vez creado, vamos a hacer uso del siguiente comando para aplicar los cambios y modificar la configuración:
root@freston:~# ldapmodify -Y EXTERNAL -H ldapi:/// -f configuracion.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config"
Para ver si hemos introducido y se han aplicado correctamente los cambios, vamos a introducir el siguiente comando:
root@freston:~# slapcat -b "cn=config" | grep -E "olcTLS" olcTLSCACertificateFile: /etc/ssl/certs/gonzalonazareno.crt olcTLSCertificateKeyFile: /etc/ssl/private/freston.key olcTLSCertificateFile: /etc/ssl/certs/wildcard.crt
Vemos que nos muestra las tres líneas que hemos añadido con nuestro fichero .ldif. En el caso de que la salida no nos mostrara nada, significaría que no se han llevado a cabo los cambios.
Vale, una vez hemos importado el fichero .ldif destinado a la configuración, nos quedaría hacer una modificación en el fichero /etc/default/slapd, ya que por defecto, el protocolo ldaps:// no viene habilitado. Para habilitarlo, debemos buscar la línea SLAPD_SERVICES y añadir el valor ldaps://, de manera que quedaría así:
SLAPD_SERVICES="ldap:/// ldapi:/// ldaps:///"
Reiniciamos el servidor LDAP para aplicar los cambios:
systemctl restart slapd.service
Por último, en la parte del cliente (en mi caso, se trata de la misma máquina), debemos realizar una modificación en el fichero de configuración /etc/ldap/ldap.conf. Hay que descomentar el apartado llamado URI. Quedaría así:
URI ldaps://localhost
Esto hará, que el cliente utilice de manera predeterminada el protocolo ldaps://.
Debemos copiar el certificado de la entidad certificadora a la ruta /usr/local/share/ca-certificates, y luego ejecutar el comando update-ca-certificates. Esta herramienta, lo que hará, es que, sobre los certificados almacenados, se cree un enlace simbólico a la ruta /etc/ssl/certs/.
root@freston:~# cp /etc/ssl/certs/gonzalonazareno.crt /usr/local/share/ca-certificates/
Ejecutamos el siguiente comando:
root@freston:~# update-ca-certificates Updating certificates in /etc/ssl/certs... rehash: warning: skipping duplicate certificate in gonzalonazareno.crt 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... done.
Para finalizar, vamos a realizar una consulta. Para realizar consultas en LDAP se utiliza la herramienta ldapsearch:
root@freston:~# ldapsearch -x -b "dc=javierpzh,dc=gonzalonazareno,dc=org" # extended LDIF # # LDAPv3 # base <dc=javierpzh,dc=gonzalonazareno,dc=org> with scope subtree # filter: (objectclass=*) # requesting: ALL # # javierpzh.gonzalonazareno.org dn: dc=javierpzh,dc=gonzalonazareno,dc=org objectClass: top objectClass: dcObject objectClass: organization o: javierpzh.gonzalonazareno.org dc: javierpzh # admin, javierpzh.gonzalonazareno.org dn: cn=admin,dc=javierpzh,dc=gonzalonazareno,dc=org objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator # Personas, javierpzh.gonzalonazareno.org dn: ou=Personas,dc=javierpzh,dc=gonzalonazareno,dc=org objectClass: top objectClass: organizationalUnit ou: Personas # Grupos, javierpzh.gonzalonazareno.org dn: ou=Grupos,dc=javierpzh,dc=gonzalonazareno,dc=org objectClass: top objectClass: organizationalUnit ou: Grupos # search result search: 2 result: 0 Success # numResponses: 5 # numEntries: 4
La salida es correcta y por tanto ya habríamos configurado LDAPs.