Confiança entre territórios entre o Active Directory e o MIT Kerberos

1

Atualmente, estou no processo de estender meu ambiente de desenvolvimento, que costumava executar servidores Linux até o momento, adicionando máquinas que executam o Windows Server 2016. O processo de autenticação é tratado pelo MIT Kerberos. Para as novas máquinas Windows, estou planejando usar o Active Directory. Como não desejo gerenciar usuários em dois sistemas, estou configurando uma relação de confiança entre domínios entre o Windows AD e a instalação já existente do MIT Kerberos.

Para fazer isso, eu segui este guia: link .

Agora, notei que posso obter um ticket do Windows AD para um usuário do AD em uma máquina linux muito bem: a execução de kinit [email protected] é concluída sem erros e me fornece um ticket como esperado.

Por outro lado, não consigo fazer login em nenhuma das máquinas do Windows usando uma conta da configuração do MIT Kerberos. Tentar efetuar login usando minha conta de teste ( [email protected] da região MIT realm DOMAIN.LOCAL) gera o seguinte erro:

"O banco de dados de segurança no servidor não possui uma conta de computador para essa relação de confiança da estação de trabalho".

Outra coisa que estou percebendo é que quando tento verificar a relação de confiança usando o comando netdom trust DOMAIN.LOCAL /Domain:AD.DOMAIN.LOCAL /Kerberos /verbose /verify , estou recebendo a seguinte mensagem de erro:

"Não é possível entrar em contato com o domínio DOMAIN.LOCAL. O comando não foi concluído com êxito."

Parece que o Windows AD não consegue se comunicar com a instalação do MIT Kerberos, o que parece estranho, porque aparentemente funciona ao contrário. Já verifiquei novamente se todos os registros DNS (domain.local, ad.domain.local e os FQDNs para os KDCs) são resolvidos para os endereços IP corretos. Ao pesquisar o problema, me deparei com esse post link , o que pareceu promissor no começo, mas não conseguiu me ajudar a resolver meu problema. Qualquer ajuda é muito apreciada!

    
por Alexander Richter 05.10.2018 / 16:56

1 resposta

1

Aviso justo, meu conhecimento nesta área é extremamente datado neste momento. Como no início de 2000, o Windows 2003 era o Active Directory. Então, as coisas podem funcionar de maneira diferente agora.

O principal problema é que o Windows não sabe como encontrar o KDC para o seu reino MIT por padrão (ironicamente, ele não usará apenas o DNS para procurar como no AD). Há um utilitário chamado ksetup.exe que permite mapear um nome de região para um ou mais servidores KDC. Por fim, esse utilitário está apenas definindo alguns valores do Registro. Assim, você pode automatizar isso com a Diretiva de Grupo, se necessário.

Atualização: @grawity mencionou que o Windows pode realmente encontrar os KDCs via DNS, contanto que existam registros SRV apropriados e o ksetup tenha sido usado para pelo menos definir o domínio.

Também tivemos essencialmente contas "shadow" no AD que correspondiam aos usuários definidos no reino do MIT. As senhas nessas contas não importavam, elas simplesmente tinham que existir. Também podemos ter definido alguns atributos adicionais, como UPN ou SPN, relacionados ao reino do MIT de alguma forma. A memória é nebulosa embora.

Outra coisa a ter em conta são os tipos de criptografia suportados entre o AD e seu território do MIT. Se ambos são muito recentes, você provavelmente ficará bem. Mas quando estávamos fazendo isso, nosso reino do MIT era antigo e tivemos que adicionar a Política de Grupo no AD para adicionar alguns tipos de criptografia legados que o reino do MIT suportava.

Espero que isso aconteça na direção certa.

    
por 05.10.2018 / 17:42