Ejecuto la autenticación Kerberos/LDAP en una red pequeña durante años. Kerberos se guarda en LDAP, que a su vez se replica en otro sitio. Las máquinas en el segundo sitio se autentican en la réplica, el sitio anterior se autentica en el servidor original. Recientemente, agregué un par de cuentas de usuario nuevas.
En el sitio original, todo funciona sin problemas. Los nuevos usuarios pueden iniciar sesión en el sistema sin ningún problema.
En el segundo sitio usar la réplica kinit usertambién funciona sin problemas. Sin embargo, login userafirma que la contraseña ha caducado y deberá cambiarse inmediatamente. Después de cambiar la contraseña, el usuario inicia sesión correctamente.
Verificar la configuración en la réplica del KDC con kadmin.localtodo me parece bien:
kadmin.local: getprinc user
Principal: [email protected]
Expiration date: [never]
Last password change: Di Nov 22 21:06:35 CET 2022
Password expiration date: [never]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Di Nov 22 21:06:35 CET 2022 ([email protected])
Last successful authentication: Di Nov 22 21:19:27 CET 2022
Last failed authentication: So Nov 13 09:05:17 CET 2022
Failed password attempts: 0
Number of keys: 8
[ ... ]
Attributes: REQUIRES_PRE_AUTH
Policy: [none]
Por lo tanto, ni las contraseñas ni los principales caducan. Y así kinitfunciona como se esperaba:
root@client:~# kinit user
Password for [email protected]:
root@client:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]
Valid starting Expires Service principal
22.11.2022 21:25:17 23.11.2022 07:25:17 krbtgt/[email protected]
renew until 23.11.2022 21:25:11
Sin embargo, loginafirma que la contraseña ha caducado y debe cambiarse:
root@ganesha:~# login user
Password:
Sie müssen Ihr Passwort sofort ändern (Passwortablauf).
Current Kerberos password:
Enter new Kerberos password:
Retype new Kerberos password:
Linux client 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Letzte Anmeldung: Dienstag, den 22. November 2022, 20:59:02 CET auf pts/5
user@client:~$
Después de esto, inicie sesión en el director Last password changey Last modifiedse actualizan. Last successful authenticationno cambia. Tampoco cambia después de tener éxito kinit. Pero sí cambia para los clientes exitosos logino kinitoriginales. Este puede ser otro problema, pero pasa igual con los usuarios antiguos, que funcionan perfectamente en ambos sitios. Usando getprincno puedo notar ninguna diferencia entre los usuarios antiguos y nuevos.
Las loginsiguientes configuraciones de PAM deberían ser efectivas para authlos accountvalores predeterminados de una instalación de Debian:
auth optional pam_faildelay.so delay=3000000
auth requisite pam_nologin.so
auth [success=2 default=ignore] pam_krb5.so minimum_uid=1000
auth [success=1 default=ignore] pam_unix.so nullok try_first_pass
auth requisite pam_deny.so
auth required pam_permit.so
auth optional pam_group.so
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
account requisite pam_deny.so
account required pam_permit.so
account required pam_krb5.so minimum_uid=1000
Configuré un nuevo cliente Bullseye, que utiliza Kerberos y LDAP originales a través de VPN. Muestra el mismo comportamiento. Hice algo de depuración de PAM:
Jan 23 21:32:44 psyche login[2861]: pam_krb5(login:auth): user user authenticated as [email protected]
Jan 23 21:32:44 psyche login[2861]: pam_unix(login:account): expired password for user user (password aged)
Jan 23 21:32:53 psyche login[2861]: pam_krb5(login:chauthtok): user user changed Kerberos password
Jan 23 21:32:53 psyche login[2861]: pam_unix(login:session): session opened for user user(uid=10##) by admin(uid=0)
Los usuarios antiguos, que funcionan bien en todos los sistemas, no tienen una entrada (login:account)y, por lo tanto, no pueden cambiar la contraseña, por supuesto. Por tanto, no parece estar relacionado con la replicación. Aún más extraño es que haya sistemas que loginfuncionen bien para esos usuarios. Lo verifiqué /etc/pam.d/common-accounty es idéntico en ambos sistemas.
Agradezco cualquier idea sobre qué comprobar.
Gracias por tu ayuda.
Respuesta1
El motivo real no estaba relacionado con Kerberos. Las cuentas fallidas se habían shadowMaxconfigurado en LDAP. Si bien no estaba al tanto de esta configuración en primer lugar, las credenciales se informan como caducadas incluso si shadowLastChangeplus shadowMaxtodavía está atrasado con la fecha actual. Establecer shadowMaxen -1 o eliminar el valor por completo soluciona el problema.
Esto no explica del todo por qué la configuración en el otro sitio aparentemente ignora el valor por completo, pero esa es otra historia.