Eu executo a autenticação Kerberos/LDAP em uma rede pequena há anos. Kerberos é mantido em LDAP, que por sua vez é replicado para outro site. As máquinas no segundo site são autenticadas na réplica, o site antigo é autenticado no servidor original. Recentemente, adicionei algumas novas contas de usuário.
No site original, tudo funciona perfeitamente. Os novos usuários podem fazer login no sistema sem nenhum problema.
No segundo site o uso da réplica kinit usertambém funciona sem problemas. Porém, login userafirma que a senha expirou e deverá ser alterada imediatamente. Depois de alterar a senha, o usuário está logado corretamente.
Verificar as configurações na réplica do KDC com kadmin.localtudo parece bom para mim:
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]
Portanto, nem as senhas nem os principais expiram. E assim kinitfunciona como esperado:
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
No entanto, loginafirma que a senha expirou e deve ser alterada:
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:~$
Após este login os principais Last password changee Last modifiedsão atualizados. Last successful authenticationnão muda. Também não muda após o sucesso kinit. Mas isso muda para clientes bem-sucedidos loginou kinitoriginais. Este pode ser outro problema, mas acontece da mesma forma com os usuários antigos, que funcionam perfeitamente nos dois sites. Usando, getprincnão consigo identificar nenhuma diferença entre os usuários antigos e os novos.
Para loginas seguintes configurações do PAM devem ser efetivas, authou accountseja, os padrões de uma instalação 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
Configurei um novo cliente Bullseye, que usa o Kerberos original e LDAP por meio de VPN. Ele mostra o mesmo comportamento. Eu fiz algumas depuração do 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)
Os usuários antigos, que funcionam bem em todos os sistemas, não possuem entrada (login:account)e, portanto, não alteram a senha, é claro. Portanto, não parece estar relacionado à replicação. Ainda mais estranho que existam sistemas que loginfuncionam bem para esses usuários. Eu verifiquei /etc/pam.d/common-accounte é idêntico em ambos os sistemas.
Agradeço qualquer idéia sobre o que verificar.
Obrigado pela ajuda.
Responder1
O motivo real não estava relacionado ao Kerberos. As contas com falha foram shadowMaxconfiguradas no LDAP. Embora eu não soubesse dessa configuração, as credenciais são relatadas como expiradas, mesmo que shadowLastChangeo plus shadowMaxainda esteja atrasado em relação à data atual. Definir shadowMaxcomo -1 ou excluir completamente o valor corrige o problema.
Isto não explica por que razão a configuração no outro local aparentemente ignora completamente o valor, mas isto é outra história.