Aprovisionamiento de Identidad - Tareas #5708 · Aprovisionamiento de Identidad - Tareas #5708 No funciona la autenticación en nube.xxx 2017-06-13 11:57 - Daniel Viñar Ulriksen

Aprovisionamiento de Identidad - Tareas #5708

No funciona la autenticación en nube.xxx

06/13/2017 11:57 AM - Daniel Viñar Ulriksen

Status: Resuelta Start date: 06/13/2017

Priority: Normal Due date:

Assignee: Daniel Viñar Ulriksen % Done: 80%

Category: Estimated time: 0.00 hour

Target version: Spent time: 10.00 hours

Description

En nube.cci.edu.uy y en nube.interior.edu.uy, desde hoy de mañana está fracasando la autenticación de usuarios que usan el backend

ldap.interior.edu.uy

Related issues:

Related to Aprovisionamiento de Identidad - Tareas # 5000: Verificar conexion... En curso 11/24/2015

Related to Aprovisionamiento de Identidad - Tareas # 5796: Error de autentica... Cerrada 09/08/2017

History

#1 - 06/13/2017 12:01 PM - Daniel Viñar Ulriksen

Desde pandeazucar, el servidor de nube.cci.edu.uy, la autenticación en ldap funciona:

root@pandeazucar:# ldapwhoami -H ldap://ldap.interior.edu.uy/ -vv -D cn=ulvida,ou=gente,dc=udelar,dc=edu,dc=uy -W

ldap_initialize( ldap://ldap.interior.edu.uy:389/??base )

Enter LDAP Password:

dn:cn=ulvida,ou=gente,dc=udelar,dc=edu,dc=uy

Result: Success (0)

Pero en ldaps fracasa:

root@pandeazucar:# ldapwhoami -H ldaps://ldap.interior.edu.uy/ -vv -D cn=ulvida,ou=gente,dc=udelar,dc=edu,dc=uy -W

ldap_initialize( ldaps://ldap.interior.edu.uy:636/??base )


ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Podemos verificar que el certificado de ldap.interior.edu.uy expiró:

root@pandeazucar:~# openssl s_client -showcerts -connect ldap.interior.edu.uy:636

....

Server certificate

subject=/O=Universidad de la Republica (UdelaR)/CN=ldap.interior.edu.uy

issuer=/C=UY/ST=Montevideo/O=Universidad de la Rep\xC3\x83\xC2\xBAblica (UdelaR)/OU=Red de Unidades Inform\xC3\x83\xC2\xA1ticas

del Interior/CN=interior.edu.uy/[email protected]

---

No client certificate CA names sent

---

SSL handshake has read 4022 bytes and written 483 bytes

---

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384

Server public key is 4096 bit

07/23/2020 1/7

Secure Renegotiation IS supported

Compression: NONE

Expansion: NONE

SSL-Session:

Protocol : TLSv1.2

Cipher : ECDHE-RSA-AES256-GCM-SHA384

Session-ID: FDD1610FBCDE9D5E86164E8A51B1CE61FF37F29A12AA648D1AAFF908373F1606

Session-ID-ctx:

Master-Key:

FA6EC25BCCE256FB23B2DE05D3384C3A1C8820EF5D55CC1146BE76D794F3112A3ECC5B59A599D0A7E69FEC4BC89C5E6B

Key-Arg : None

PSK identity: None

PSK identity hint: None

SRP username: None

Start Time: 1497365927

Timeout : 300 (sec)

Verify return code: 10 (certificate has expired)

---


Ya que estamos, mejor reemplazar los certificados autofirmados por certificados válidos y firmados por autoridad letsencrypt.

Agregamos el repositoriod e backports al @/etc/apt/sources.list

Actualizamos e instalamos certbot

(Aprovechamos para actualizar la debian...)

Debemos parar el firewall (que luego actualizaremos) para que letsencrypt pueda acceder al puerto 80:

/usr/local/etc/wschebor.csic.edu.uy.fw stop

Y entonces creamos el certificado con:

certbot certonly --standalone -d ldap.interior.edu.uy -d wschebor.csic.edu.uy


- Status changed from Nueva to En curso

- % Done changed from 0 to 10


La [[sauce:Instalar_servidor_LDAP#5-Configurar-SSLTLS|configuración SSL/TLS está documentada acá]].

#5 - 06/13/2017 02:08 PM - Andrés Pías

- Related to Tareas #5000: Verificar conexiones LDAP en TLS added



07/23/2020 2/7

Ejemplo de caso similar y procesamiento.

En tls.ldif ponemos:

dn: cn=config

changetype: modify

replace: olcTLSCACertificateFile

olcTLSCACertificateFile: /etc/letsencrypt/live/ldap.interior.edu.uy/fullchain.pem

-

replace: olcTLSCertificateFile

olcTLSCertificateFile: /etc/letsencrypt/live/ldap.interior.edu.uy/cert.pem

-

replace: olcTLSCertificateKeyFile

olcTLSCertificateKeyFile: /etc/letsencrypt/live/ldap.interior.edu.uy/privkey.pem

El ldapmodify da error:

root@wschebor:~/ldifs# ldapmodify -Y EXTERNAL -H ldapi:/// -f tls.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)

Pero la autenticación en la nube empieza a andar...

#7 - 06/13/2017 07:58 PM - Andrés Pías

Camino de solución

El error que no funcionaba el LDIF se debía a un tema de permisos, lo vi en varios lados como aquí. Los permisos se solucionan así:

chown -R openldap:openldap /etc/letsencrypt/

(Probé ser menos permisivo pero no funcionó)

Luego si podes correr el ldif sin problemas:

root@wschebor:/etc/letsencrypt# ldapmodify -Y EXTERNAL -H ldapi:/// -f /root/ldifs/tls_letsencrypt.ldif

SASL/EXTERNAL authentication started

SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth

SASL SSF: 0

modifying entry "cn=config"

Reiniciamos el servicio slapd por las dudas.

Sin embargo luego seguía sin andar la nube.interior.

Entonces desde Wschebor hago un par de verificaciones locales.

Conectarse sin TLS es exitoso:

root@wschebor:/etc/letsencrypt# ldapwhoami -vv -H ldap://ldap.interior.edu.uy:389/ -D cn=andres,ou=gente,dc=udelar,dc=edu,dc=uy -W



dn:cn=andres,ou=gente,dc=udelar,dc=edu,dc=uy

07/23/2020 3/7

https://serverfault.com/questions/777017/using-lets-encrypt-certificates-with-openldap

https://www.dahlem.uk/display/deb/Configure+and+enable+TLS+for+OpenLDAP

Result: Success (0)

Pero la conexión TLS no funciona dando un error poco entendible:

root@wschebor:/etc/letsencrypt# ldapwhoami -vv -H ldap://ldap.interior.edu.uy:389/ -D cn=andres,ou=gente,dc=udelar,dc=edu,dc=uy -ZZW


ldap_start_tls: Connect error (-11)

additional info: (unknown error code)

Viendo foros como este se me ocurrió cambiar el certificado para TLS que es indicado en /etc/ldap/ldap.conf (el cual es CAcert_interior.edu.uy.pem) por

el recientemente creado con letsencrypt (/etc/letsencrypt/live/ldap.interior.edu.uy/fullchain.pem):

TLS_CACERT /etc/letsencrypt/live/ldap.interior.edu.uy/fullchain.pem

Luego reinicié el servicio slapd y logré la conexión en TLS.

Tengo la fuerte sospecha que lo que realmente caducó fue el CAcert_interior.edu.uy.pem y no todo lo demás

Luego de eso la nube no funcionaba. Lo que pasa es que faltaba copiar el nuevo certificado TLS a Halley y despositarlo en /etc/ssl/certs y cambiar la

config de /etc/ldap/ldap.conf de la misma manera que se hizo en Wschebor:

TLS_CACERT /etc/ssl/certs/wschebor-letsencrypt-fullchain.pem

Luego se reinició apache en Halley y finalmente se logró el acceso a nube.interior.

#8 - 06/14/2017 09:45 AM - Daniel Viñar Ulriksen

El certificado de autoridad de letsencrypt, o los que lo han "cross signed", están desplegados en todos los servidores con el paquete ca-certificates. Por

ende, en los servidores clientes (como [[servidores:Halley]], [[servidores:PanDeAzucar]], [[servidores:Oort]], en el /etc/ldap/ldap.conf, se puede poner

simplemente la configuración por omisión:

TLS_CACERT /etc/ssl/certs/ca-certificates.crt

Luego de reiniciar apache en en el servidoir cliente y se logra la autenticación ldap.


El certificado presentado por el servidor ldap es válido:

root@pandeazucar:~# openssl s_client -showcerts -connect ldap.interior.edu.uy:636

...

Server certificate

subject=/CN=ldap.interior.edu.uy

issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

---

No client certificate CA names sent

---

SSL handshake has read 3067 bytes and written 483 bytes

---

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384

Server public key is 2048 bit

Secure Renegotiation IS supported

Compression: NONE

Expansion: NONE

SSL-Session:

Protocol : TLSv1.2

Cipher : ECDHE-RSA-AES256-GCM-SHA384

Session-ID: B1C2214FF9E6CBB134A0BEE34F652993735D40DC76CC372F39EDFA218556201B

07/23/2020 4/7

https://www.questarter.com/q/using-lets-encrypt-certificates-with-openldap-1_777017.html

Session-ID-ctx:

Master-Key:

1C2716A11BD1ED03AD6A1A1A209B807704BBDB7A7D251F1602D64A3F4D1683DE68DE6F55D69191D5E2BB16D2AC206ADF

Key-Arg : None

PSK identity: None

PSK identity hint: None

SRP username: None

Start Time: 1497451426

Timeout : 300 (sec)

Verify return code: 0 (ok)

---


- Status changed from En curso to Resuelta


Ahora sólo queda por verificar que, dentro de 3 meses, los certificados letsencrypt se renuevan automáticamente.


- Related to Tareas #5796: Error de autenticación en identidad.interior.edu.uy added

#12 - 11/10/2017 12:49 PM - Andrés Pías

Daniel Viñar Ulriksen escribió:

Ahora sólo queda por verificar que, dentro de 3 meses, los certificados letsencrypt se renuevan automáticamente.

Hoy no andaban los servicios basados en LDAP, sobre todo las nubes, debibo a que se vencieron los certificados. O sea, no quedó funcionando la

renovación automática.

Sintomas

Probamos conexión sin SSL y anda:

apias@wschebor:~$ ldapwhoami -H ldap://ldap.interior.edu.uy/ -vv -D cn=andres,ou=gente,dc=udelar,dc=edu,dc=uy -W




Result: Success (0)

Probamos conexión con SSL y no anda:

apias@wschebor:~$ ldapwhoami -H ldaps://ldap.interior.edu.uy/ -vv -D cn=andres,ou=gente,dc=udelar,dc=edu,dc=uy -W



ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Vemos estado del certificado y vemos que expiró:

apias@wschebor:~$ openssl s_client -showcerts -connect ldap.interior.edu.uy:636

...


07/23/2020 5/7

...

Solución

Detenemos el firewall:


Renovamos el certificado

certbot certonly --standalone -d ldap.interior.edu.uy -d wschebor.csic.edu.uy

service slapd restart

/usr/local/etc/wschebor.csic.edu.uy.fw start

Verificamos el estado del certificado:

apias@wschebor:~$ openssl s_client -showcerts -connect ldap.interior.edu.uy:636

...


...

Despues funciona la autenticación https

root@wschebor:/etc/letsencrypt/live/ldap.interior.edu.uy# ldapwhoami -H ldaps://ldap.interior.edu.uy/ -vv -D

cn=andres,ou=gente,dc=udelar,dc=edu,dc=uy -W




Result: Success (0)

Encontré que en /etc/cron.d/certbot hay un script definido para correr cada 12 horas haciendo la renovación del certificado en caso de que sea necesaria.

En los logs vemos que corre cada 12 horas:

Nov 10 12:00:01 wschebor systemd[1]: Starting Certbot...

Nov 10 12:00:02 wschebor CRON[18703]: (root) CMD (test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' &&

certbot -q renew)

Nov 10 12:00:04 wschebor kernel: [6582077.400446] RULE 7 -- DENY IN=eth0 OUT= MAC=52:54:00:fc:71:7e:00:0c:42:cf:c9:97:08:00

SRC=36.66.214.155 DST=164.73.68.30 LEN

=40 TOS=0x00 PREC=0x40 TTL=228 ID=60259 PROTO=TCP SPT=54826 DPT=6695 WINDOW=1024 RES=0x00 SYN URGP=0

Nov 10 12:00:06 wschebor kernel: [6582079.801028] RULE 7 -- DENY IN=eth0 OUT= MAC=52:54:00:fc:71:7e:00:0c:42:cf:c9:97:08:00

SRC=36.66.214.155 DST=164.73.68.30 LEN

Puede ser que no funcione debido al firewall entonces le agrego líneas para para y levantar el firewall. El script quedó así:

# /etc/cron.d/certbot: crontab entries for the certbot package

#

# Upstream recommends attempting renewal twice a day

#

# Eventually, this will be an opportunity to validate certificates

# haven't been revoked, etc. Renewal will only occur if expiration

# is within 30 days.

SHELL=/bin/sh

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin


0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew

/usr/local/etc/wschebor.csic.edu.uy.fw start

#13 - 02/08/2018 02:45 PM - Andrés Pías


Hoy no funcionaba la Nube ni el PWM, por problemas del LDAP.

07/23/2020 6/7

Desde Wschebor comprobamos se deba a un tema de certificados expirados:

openssl s_client -showcerts -connect ldap.interior.edu.uy:636


Sin embargo, a la vez se comprueba que los archivos/certificados han sido descargados. Hay recientes, del 9 de enero:

root@wschebor:/etc/letsencrypt/live/ldap.interior.edu.uy# ls -altr

total 12

-rw-r--r-- 1 openldap openldap 543 jun 13 2017 README

drwx------ 4 openldap openldap 4096 jun 13 2017 ..

lrwxrwxrwx 1 root root 47 ene 9 12:15 privkey.pem -> ../../archive/ldap.interior.edu.uy/privkey5.pem

lrwxrwxrwx 1 root root 49 ene 9 12:15 fullchain.pem -> ../../archive/ldap.interior.edu.uy/fullchain5.pem

lrwxrwxrwx 1 root root 45 ene 9 12:15 chain.pem -> ../../archive/ldap.interior.edu.uy/chain5.pem

lrwxrwxrwx 1 root root 44 ene 9 12:15 cert.pem -> ../../archive/ldap.interior.edu.uy/cert5.pem

Luego de varias vueltas, probamos reiniciar el OpenLDAP para ver si era el problema:

service slapd restart

Esto funcionó:

openssl s_client -showcerts -connect ldap.interior.edu.uy:636


De esta manera comprobamos que luego de que se bajan automáticamente los certificados, para que OpenLDAP se entere hay que reiniciarlo.

Configuramos el script del cron de letscript (/etc/cron.d/certbot) para que quede de esta manera:

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew && service slapd restart

Esperemos que ahora esto funcione bien y que no sea necesario intervenir de forma manual en 3 meses.

07/23/2020 7/7

Documents

Aprovisionamiento de Identidad - Tareas #5708 · Aprovisionamiento de Identidad - Tareas #5708 No funciona la autenticación en nube.xxx 2017-06-13 11:57 - Daniel Viñar Ulriksen