O login do serviço Kerberos só é possível por 30 minutos após a execução do ktpass.exe

Question

Estou tentando executar o Kerberize em um servidor Apache e permitir que o servidor criado entre no servidor Active Directory. Eu segui um dos numerosos tutoriais disponíveis online, e parece funcionar bem. Eu estou no lado do Linux do projeto e a TI corporativa está do lado do Windows.

A TI me forneceu uma conta de serviço e uma entidade de serviço para ela. Neste exemplo, vou me referir a ele como HTTP/[email protected]. Eles me forneceram um arquivo keytab para o dito principal, que envolve a execução de uma ferramenta chamada ktpass.exe no servidor AD.

Eu verifiquei que os KVNOs do AD / KDC e do arquivo keytab correspondem. Tudo está bem.

Existe um registro A do DNS apropriado para o nome do host e um registro PTR adequado para o IP. Ambos os servidores estão sincronizados no tempo.

Eu posso solicitar um ticket do AD / KDC para o principal de serviço mencionado acima com o arquivo keytab emitido, assim:

kinit -k -t http.keytab HTTP/[email protected]

Isso funciona. Eu obtenho um ticket e posso usar esse ticket para coisas como consultar o diretório do AD / LDAP. O keytab também funciona muito bem para a execução de um site Single Signon Apache, que é parcialmente o objetivo deste exercício.

Meia hora passa.

As tentativas de efetuar logon com o comando kinit acima agora falharão com esta mensagem:

Client not found in Kerberos database

Não consigo autenticar como o principal de serviço, como se o principal fosse excluído no servidor do AD.

Agora fica estranho, pelo menos para mim:

Por solicitação, o administrador do AD executa a ferramenta ktpass.exe novamente, criando um novo arquivo keytab para o meu serviço. O KVNO (Key Version Number) é incrementado no servidor, fazendo com que nosso servidor de teste Apache pare de validar a conexão única do Kerberos. Isso é esperado com a minha configuração atual. O que surpreendeu a todos nós foi que agora o comando kinit funcionava de novo. Nós nos compramos mais meia hora, e depois parou de funcionar novamente.

Nosso departamento de TI está perdido aqui, e eles estão especulando que isso é um problema com o próprio servidor do AD. Eu estou pensando que é configuração, mas de acordo com eles, não há limites de meia hora em qualquer configuração.

Eu segui o link (consulte a seção 7), mas o método parece ser o mesmo em toda a documentação que eu ve encontrado. Não encontrei nenhuma referência a limites de tempo em entidades de serviço.

EDIT: Este parece ser um problema de replicação. Embora nenhum erro seja relatado no processo de replicação, o valor de SPN da conta de serviço é alterado (revertido?) De "HTTP/[email protected]" para "[email protected] "depois de 30 minutos.

    

Answer 1

Obrigado por todas as suas opiniões, pessoal. Temos a Microsoft a bordo e eles nos ajudaram a depurar o processo de autenticação no lado AD. Tudo funcionou como deveria, mas falhou depois de trinta minutos.

Enquanto estávamos fazendo uma sessão de depuração remota, um dos participantes notou que o UPN / SPN da conta de serviço foi repotado de repente de HTTP/[email protected] para < strong> [email protected] . Depois de um monte de pesquisas, incluindo a depuração do AD, encontramos o culpado:

Alguém fez um script que era executado periodicamente (ou provavelmente por evento, já que eram exatamente trinta minutos depois de executar o ktpass.exe), que atualizou o UPN / PSN para "garantir a conectividade da nuvem" . Eu não tenho nenhuma informação suplementar sobre as razões para isso.

O script foi alterado para permitir que os valores UPN / SPN existentes terminassem em @ mycorp.com , solucionando efetivamente o problema.

Dicas para depurar problemas como este:

• Assegure-se de que todos os participantes na autenticação suportem os mesmos tipos de criptografia. Evite DES - está desatualizado e inseguro.
• Certifique-se de ativar a criptografia AES-128 e AES-256 na conta de serviço
• Lembre-se de que habilitar o DES na conta de serviço significa "usar APENAS DES para esta conta" , mesmo se você ativou alguma das criptografias AES. Faça uma pesquisa por UF_USE_DES_KEY_ONLY para obter detalhes sobre isso.
• Verifique se o valor de UPN / SPN está ativo e corresponde ao valor no arquivo keytab emitido (por exemplo, por meio de uma consulta LDAP)
• Certifique-se de que o KVNO (Key Version Number) no arquivo keytab corresponde ao on no servidor
• Inspecionar o tráfego entre o servidor e o cliente (ou seja, com tcpdump e / ou WireShark)
• Ativar a depuração da autenticação no lado do AD - inspecionar registros
• Ative a depuração da replicação no lado do AD - inspecione os registros

Mais uma vez, obrigado pela sua contribuição.

    

Answer 2

Eu também aprendi o Kerberos começando com o tutorial mod_auth_kerb de Achim Grolms, realmente uma boa documentação.

O arquivo keytab apenas substitui a autenticação por senha. A senha é codificada no arquivo e esses bytes são usados no desafio de autenticação com o KDC. Qualquer alteração de senha na conta de serviço invalidará a autenticação do keytab e também aumentará o número do kvno.

Para confirmar se um SPN da conta de serviço está disponível, geralmente faço a autenticação com a senha da conta de serviço:

kinit HTTP/[email protected]

Se falhar, para confirmar que a conta do serviço não está desativada, tente a autenticação básica:

kinit account

Se a autenticação falhar, basta excluir a conta e criar uma nova com outro nome de login para evitar problemas.

Há uma grande chance de que outro software - por exemplo, outro sistema com um antigo keytab gerado para o mesmo SPN - tente se autenticar nessa conta de serviço e desative a conta devido a uma senha inválida.

Ao configurar o Kerberos SSO, operações muito rápidas podem levar a inconsistências no Active Directory. Minha diretriz geral quando preso no processo de configuração é seguir estes passos:

• excluir contas de serviço "antigas" ou "com falha" para sistemas de teste e produção
• verifique com kvno o SPN que você espera configurar não existe mais no território
• verifique com setspn -X se não há SPN conflitante em várias contas
• crie uma conta de serviço por sistema, dedicada a um único SPN totalmente qualificado, com um novo nome de login
• impede alteração de senha e expiração de senha na conta de serviço
• vamos aguardar um pouco pela sincronização de DC
• definir senha como ktpass opção ao gerar keytab
• verifique o FNDN SPN e os aliases com setspn -l account

Aqui está um conjunto de comandos para configurar a conta de serviço no DC:

ktpass -princ HTTP/[email protected] -mapuser [email protected]
  -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL
  -pass long!$longp2ass3word -out c:\temp\http-mysite-mycorp-com.keytab
setspn -a HTTP/mysite mysiteAccount
setspn -l mysiteAccount

Se operações são feitas muito rápido em diferentes DCs entre o MMC e o ktpass para geração de keytab em uma linha de comando administrativa, então a sincronização de DCs pode levar a resultados inesperados como aquele que você descreve. Então, vamos esperar um pouco entre a criação da conta e, em seguida, ktpass e qualquer comando setspn adicional.

E comandos para rodar no Linux para verificar se tudo funciona corretamente:

kinit [email protected]
kinit HTTP/[email protected]
kinit -k -t http-mysite-mycorp-com.keytab HTTP/[email protected]
kvno HTTP/mysite.mycorp.com
kvno HTTP/mysite