Adiciona um novo servidor ao Gerenciador de Servidores, obtém o erro Kerberos 0x80090322

Question

Estou configurando um ambiente de laboratório do Windows. Ele tem um controlador de domínio Win2012R2 (srv001) e gostaria de adicionar outro servidor Win2012R2 ao domínio (srv003). Na verdade, tudo vai bem. Eu dei ao novo servidor um endereço IP estático na mesma sub-rede que o DC, apontei para o servidor DNS correto e adicionei o servidor ao domínio.

No entanto, quando eu adiciono o novo servidor ao Gerenciador do Servidor, recebo um erro do Kerberos: 0x80090322. Eu tenho uma mensagem de erro bastante longa que postarei abaixo. Fiz alguns testes e descobri que sou realmente capaz de configurar uma sessão remota do Powershell para o servidor usando a autenticação Kerberos:

$s = New-PSSession -ComputerName srv003 -Authentication Kerberos
$s | Enter-PSSession

Sem problemas aqui. Eu corri Enable-PSRemoting no servidor remoto, sem problemas também.

Por que o Gerenciador de Servidores não gosta do meu novo servidor? Especialmente porque é possível configurar um Powershell remoto usando o mesmo protocolo que o Gerenciador do Servidor está reclamando.

A mensagem de erro que pertence ao código de erro 0x80090322:

A atualização da configuração falhou com o seguinte erro: Os metadados não puderam ser recuperados do servidor, devido ao seguinte erro: O WinRM não pode processar a solicitação. O seguinte erro com errorcode 0x80090322 ocorreu ao usar a autenticação Kerberos: Ocorreu um erro de segurança desconhecido. Causas possíveis são:

1. O nome do usuário ou a senha especificada são inválidos.
2. O Kerberos é usado quando nenhum método de autenticação e nenhum nome de usuário são especificados.
3. O Kerberos aceita nomes de usuário de domínio, mas não nomes de usuários locais.
4. O nome principal do serviço (SPN) para o nome do computador remoto e a porta não existe.
5. O cliente e os computadores remotos estão em domínios diferentes e não há confiança entre os dois domínios.

Após verificar os problemas acima, tente o seguinte:

6. Verifique o Visualizador de Eventos para eventos relacionados à autenticação.
7. Altere o método de autenticação; adicione o computador de destino à configuração de configuração WinRM TrustedHosts ou use o transporte HTTPS. Observe que os computadores na lista TrustedHosts podem não ser autenticados.
8. Para obter mais informações sobre a configuração do WinRM, execute o seguinte comando: winrm help config.

Para voltar aos itens numerados na mensagem de erro:

1. Eu uso uma conta de administrador de domínio para fazer isso.
2. Não sei como alterar isso no Gerenciador do Servidor, portanto, suponho que o padrão seja necessário.
3. Estou correndo dentro do domínio, iniciando o Gerenciador de servidores como administrador de domínio.
4. O servidor realmente tem os seguintes SPNs que eu não toquei:
   1. Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04 / srv003.rwwilden01.local
   2. TERMSRV / SRV003
   3. TERMSRV / srv003.rwwilden01.local
   4. WSMAN / srv003
   5. WSMAN / srv003.rwwilden01.local
   6. RestrictedKrbHost / SRV003
   7. HOST / SRV003
   8. RestrictedKrbHost / srv003.rwwilden01.local
   9. HOST / srv003.rwwilden01.local
5. Os dois computadores estão no mesmo domínio.
6. Nenhum evento na máquina do cliente.
7. Não deveria ser necessário fazer isso.

Answer 1

Ok, finalmente percebi. Dei outra boa olhada no log de eventos do servidor remoto. Ele continha um erro com o seguinte texto de erro:

O cliente Kerberos recebeu um erro KRB_AP_ERR_MODIFIED do servidor srv003. O nome de destino usado foi HTTP / srv003.rwwilden01.local. Isso indica que o servidor de destino não conseguiu descriptografar o ticket fornecido pelo cliente. Isso pode ocorrer quando o nome principal do servidor de destino (SPN) está registrado em uma conta diferente da conta que o serviço de destino está usando. Certifique-se de que o SPN de destino esteja registrado somente na conta usada pelo servidor. Esse erro também pode acontecer se a senha da conta de serviço de destino for diferente daquela configurada no Centro de Distribuição de Chaves Kerberos para esse serviço de destino. Assegure-se de que o serviço no servidor e no KDC esteja configurado para usar a mesma senha. Se o nome do servidor não estiver completo e o domínio de destino (RWWILDEN01.LOCAL) for diferente do domínio do cliente (RWWILDEN01.LOCAL), verifique se há contas de servidor com nome idêntico nesses dois domínios ou use o nome completo para identificar o servidor.

Parece que eu adicionei uma conta de serviço gerenciado uma semana antes com o SPN HTTP/srv003.rwwilden.local . Não tenho certeza porque o Gerenciador de Servidores tenta esse nome de destino primeiro, mas aparentemente isso não funciona. Faz sentido, pois este SPN tem pouco a ver com o servidor real.

Depois que eu removi a conta de serviço, tudo começou a funcionar como eu pretendia.

    

Answer 2

Eu tive esse problema há não muito tempo, fui apontado para o culpado usando a ferramenta "setspn". Entendi melhor os SPNs lendo este artigo: link

    

Answer 3

Teve o mesmo erro e tentou várias soluções diferentes. O que ajudou foi usar endereço IPv4 explícito em vez de nome de domínio.

    

Answer 4

Eu não pude adicionar um comentário (novo emprego, nova conta, sem pontos) ao post que eu queria, então estou respondendo. A razão pela qual usar um IP ajuda / resolve o problema é porque quando um IP é usado, o Kerberos não é usado. O Kerb só é tentado quando um FQDN é usado (ou um nome de NBT, mas isso é apenas porque ele anexa o nome de domínio, tornando-o fqdn de qualquer maneira). De um modo geral, a maioria dos erros do Kerberos se deve à nomeação OU ao SPN que não está sendo definido ou configurado corretamente para o serviço de que você precisa. Cnames não funcionam a menos que você desative a verificação de nomes estritos e, mesmo assim, não funcionará sob algumas circunstâncias, então eu sugiro que você fique longe deles pelo menos enquanto estiver diagnosticando. Mas honestamente ... a melhor abordagem para descobrir esse tipo de coisa (porque os logs do Windows e o Curb não são tão úteis) é usar o Wireshark. você verá a negociação e verá por que ela falha, o que está tentando etc. Além disso, se você ativar logs "analíticos e de depuração" no Visualizador de Eventos, obterá logs de depuração adicionais para o Curb que podem ser ativados, que são um pouco mais úteis . Ainda assim ... Wireshark é sempre seu amigo imho!

    

Answer 5

Eu também tive um problema com o Kerberos. Acabou sendo uma relação de confiança quebrada entre domínio e servidor. Depois de corrigir isso com o PowerShell, tudo correu bem novamente.