Estou tentando Kerberizar um servidor Apache e permitir que o servidor principal criado entre no Active Directory. Segui um dos vários tutoriais disponíveis online e parece funcionar bem. Estou no lado Linux do projeto e a TI corporativa está no lado 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/[e-mail protegido]. Eles me forneceram um arquivo keytab para o referido principal, que envolve a execução de uma ferramenta chamada ktpass.exe no servidor AD.
Verifiquei que os KVNOs do AD/KDC e o arquivo keytab correspondem. Tudo está bem.
Existe um registro DNS A adequado para o nome do host e um registro PTR adequado para o IP. Ambos os servidores estão sincronizados com o horário.
Consigo solicitar um ticket do AD/KDC para a entidade de serviço mencionada acima com o arquivo keytab emitido, assim:
kinit -k -t http.keytab HTTP/[email protected]
Isso funciona. Eu obtenho um tíquete e posso usá-lo para coisas como consultar o diretório AD/LDAP. O keytab também funciona muito bem para executar um site Apache Single Signon, que é parcialmente o objetivo deste exercício.
Meia hora se passa.
As tentativas de fazer logon com o comando kinit acima agora falham com esta mensagem:
Client not found in Kerberos database
Não consigo autenticar como principal de serviço, como se o principal tivesse sido excluído no servidor AD.
Agora fica estranho, pelo menos para mim:
Mediante solicitação, o administrador do AD executa a ferramenta ktpass.exe novamente, criando um novo arquivo keytab para meu serviço. O KVNO (número de versão da chave) é incrementado no servidor, fazendo com que nosso servidor de teste Apache pare de validar o logon único do Kerberos. Isso é esperado com minha configuração atual. O que surpreendeu a todos nós foi que agora o comando kinit funcionou novamente. Ganhamos mais meia hora e então ele parou de funcionar novamente.
Nosso departamento de TI está perdido aqui e especula que isso é um problema com o próprio servidor AD. Estou pensando que é configuração, mas segundo eles não há limite de meia hora em nenhum lugar da configuração.
eu seguihttp://www.grolmsnet.de/kerbtut/(veja a seção 7), mas o método parece ser o mesmo em toda a documentação que encontrei. Não encontrei nenhuma referência a limites de tempo para 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 SPN da conta de serviço é alterado (revertido?) de "HTTP/[e-mail protegido]" para "[e-mail protegido]" depois de 30 minutos.
Responder1
Agradeço-vos o valioso contributo, pessoal. Contamos com a participação da Microsoft e eles nos ajudaram a depurar o processo de autenticação no lado do AD. Tudo funcionou como deveria, mas falhou depois de trinta minutos.
Enquanto estávamos realizando uma sessão de depuração remota, um dos participantes percebeu que o UPN/SPN da conta de serviço foi reiniciado repentinamente.http/[e-mail protegido]para[e-mail protegido]. Depois de muita pesquisa, incluindo depuração da replicação do AD, encontramos o culpado:
Alguém criou um script executado periodicamente (ou provavelmente por evento, já que foi exatamente trinta minutos após a execução do ktpass.exe), que atualizou o UPN/PSN para"garantir a conectividade na nuvem". Não tenho nenhuma informação suplementar sobre as razões para fazer isso.
O script foi alterado para permitir valores UPN/SPN existentes que terminem em@mycorp.com, resolvendo efetivamente o problema.
Dicas para depurar problemas como este:
- Certifique-se de que todos os participantes da 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
- Esteja ciente de que ativar o DES na conta de serviço significa"use SOMENTE DES para esta conta", mesmo se você tiver ativado qualquer uma das criptografias AES. Faça uma pesquisa porUF_USE_DES_KEY_ONLYpara obter detalhes sobre isso.
- Certifique-se de que o valor UPN/SPN esteja correto e corresponda ao valor no arquivo keytab emitido (ou seja, por meio de uma pesquisa LDAP)
- Certifique-se de que o KVNO (número de versão da chave) no arquivo keytab corresponda ao do servidor
- Inspecione o tráfego entre servidor e cliente (ou seja, com tcpdump e/ou WireShark)
- Habilite a depuração de autenticação no lado do AD - inspecione os logs
- Habilite a depuração da replicação no lado do AD - inspecione os logs
Mais uma vez, obrigado pela sua contribuição.
Responder2
Também aprendi Kerberos começando com mod_auth_kerbo tutorial de Achim Grolms, realmente uma boa documentação.
O keytabarquivo substitui apenas a autenticação por senha. A senha é codificada no arquivo e esses bytes são usados no desafio de autenticação com KDC. Qualquer alteração de senha na conta de serviço invalidará a autenticação keytab e também aumentará o número kvno.
Para confirmar se um SPN da conta de serviço está disponível, geralmente autentico com a senha da conta de serviço:
kinit HTTP/[email protected]
Se falhar, para confirmar que a conta de serviço não está desativada, tente a autenticação básica:
kinit account
Se não conseguir autenticar, simplesmente exclua a conta e crie uma nova com outro nome de login para evitar problemas.
Há uma grande chance de que outro software - por exemplo, outro sistema com um keytab antigo gerado para o mesmo SPN - tente se autenticar nesta conta de serviço e desabilite a conta devido a uma senha inválida.
Ao configurar o SSO do Kerberos, operações muito rápidas podem levar a inconsistências no Active Directory. Minha orientação geral quando travado no processo de configuração é seguir estas etapas:
- excluir contas de serviço "antigas" ou "com falha" para sistemas de teste e produção
- verifique se
kvnoo SPN que você espera configurar não existe mais no domínio - verifique se
setspn -Xnã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
- evitar alteração de senha e expiração de senha na conta de serviço
- vamos esperar um pouco pela sincronização DC
- definir senha como
ktpassopção ao gerar keytab - verifique FQDN SPN e 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 as operações forem feitas muito rapidamente em DCs diferentes entre o MMC e a execução do ktpass para geração de keytab em uma linha de comando administrativo, a sincronização dos DCs poderá levar a resultados inesperados como o que você descreve. Então, vamos esperar um pouco entre a criação da conta e ktpassquaisquer setspncomandos adicionais.
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