A autenticação Kerberos falha com a alteração forçada de senha

Question

Eu configurei a autenticação do PAM para usar o Kerberos e posso autenticar corretamente com meus principais usando suas credenciais do Kerberos.

Eu tive problemas quando tentei criar um principal com uma senha expirada:

kadmin: addprinc +needchange test_principal

Quando tentei fazer o login (a partir de um VT ou do saudador gráfico), depois de inserir corretamente a senha, recebi a mensagem esperada de que a senha expirou e o sistema solicitou que eu criasse uma nova. Depois que eu fiz isso, a autenticação falhou com esse erro no kdc.log :

krb5kdc[...](info): TGS_REQ (4 etypes {18 17 16 23}) 192.168.0.200: NO PREAUTH: authtime 0, [email protected] for host/[email protected], Generic error (see e-text)

e o seguinte (não tão surpreendente) erro em /var/log/auth.log :

pam_krb5(gdm3:auth): (user test_principal) credential verfication failed: KDC returned error string: NO PREAUTH

Algumas notas

• Listar os atributos do principal (via getprinc in kadmin.local ) mostra 0 tentativas de login com falha
• Se eu criar a conta sem o sinalizador +needchange , posso autenticar corretamente.
• Se eu adicionar o sinalizador +needchange (via modprinc in kadmin.local ) depois que o usuário tiver autenticado com êxito uma vez, obtenho o comportamento esperado; ou seja, o usuário é solicitado a alterar sua senha e, em seguida, sua autenticação é bem-sucedida.
• Esse principal não tem entrada equivalente em /etc/passwd , mas é feito backup por uma entrada LDAP.

• Como sugerido em outro lugar, tentei criar meu diretor assim:

  kadmin: addprinc -requires_preauth +needchange test_principal
  

  Isso não fez diferença.

Meu caso de uso

Estou migrando de um antigo sistema NIS e quero oferecer continuidade aos meus usuários. Eu gostaria de tê-los digitar suas senhas antigas, mas ser forçado a alterá-las para obedecer a regras de política de senha mais rígidas que pretendo impor através do Kerberos.

Por favor, informe.

Estou executando o MIT Kerberos V no Debian Wheezy.

    

Answer 1

Encontrei a resposta e é muito estranha!

Eu usei o comando getprinc em kadmin para obter os atributos do principal do problema e do principal que foi criado sem +needchange e que estava sendo autenticado corretamente.

A diferença era que o principal autenticando corretamente tinha o atributo REQUIRES_PRE_AUTH definido enquanto o principal do problema não o tinha, então a solução é criar o principal desta forma:

kadmin: addprinc +needchange +requires_preauth test_principal