Aprovisionamiento de Identidad - Tareas #5708 · Aprovisionamiento de Identidad - Tareas #5708 No...
Transcript of Aprovisionamiento de Identidad - Tareas #5708 · Aprovisionamiento de Identidad - Tareas #5708 No...
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 )
Enter LDAP Password:
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)
---
#2 - 06/13/2017 12:43 PM - Daniel Viñar Ulriksen
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
#3 - 06/13/2017 12:55 PM - Daniel Viñar Ulriksen
- Status changed from Nueva to En curso
- % Done changed from 0 to 10
#4 - 06/13/2017 01:02 PM - Daniel Viñar Ulriksen
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
#6 - 06/13/2017 02:44 PM - Daniel Viñar Ulriksen
- % Done changed from 10 to 50
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
ldap_initialize( ldap://ldap.interior.edu.uy:389/??base )
Enter LDAP Password:
dn:cn=andres,ou=gente,dc=udelar,dc=edu,dc=uy
07/23/2020 3/7
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_initialize( ldap://ldap.interior.edu.uy:389/??base )
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.
#9 - 06/14/2017 11:44 AM - Daniel Viñar Ulriksen
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
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)
---
#10 - 06/14/2017 11:45 AM - Daniel Viñar Ulriksen
- Status changed from En curso to Resuelta
- % Done changed from 50 to 70
Ahora sólo queda por verificar que, dentro de 3 meses, los certificados letsencrypt se renuevan automáticamente.
#11 - 09/08/2017 02:26 PM - Daniel Viñar Ulriksen
- 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
ldap_initialize( ldap://ldap.interior.edu.uy:389/??base )
Enter LDAP Password:
dn:cn=andres,ou=gente,dc=udelar,dc=edu,dc=uy
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_initialize( ldaps://ldap.interior.edu.uy:636/??base )
Enter LDAP Password:
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
...
Verify return code: 10 (certificate has expired)
07/23/2020 5/7
...
Solución
Detenemos el firewall:
/usr/local/etc/wschebor.csic.edu.uy.fw stop
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
...
Verify return code: 0 (ok)
...
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
ldap_initialize( ldaps://ldap.interior.edu.uy:636/??base )
Enter LDAP Password:
dn:cn=andres,ou=gente,dc=udelar,dc=edu,dc=uy
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
/usr/local/etc/wschebor.csic.edu.uy.fw stop
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
- % Done changed from 70 to 80
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
Verify return code: 10 (certificate has expired)
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
Verify return code: 0 (ok)
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