Corrigir ‘Falha na Relação de Confiança entre a Estação de Trabalho e o Domínio Primário’

Uma das principais dificuldades que afligem os administradores de sistemas Windows é quando os computadores do Active Directory parecem sair do domínio. O infame erro “a relação de confiança entre esta estação de trabalho e o domínio principal falhou” é muito comum.

Neste guia, você aprenderá todos os truques que encontrei ao longo dos meus mais de 20 anos gerenciando o Active Directory e como automatizá-los com o PowerShell.

Mensagem de erro “A relação de confiança entre esta estação de trabalho e o domínio principal falhou“

Quando um domínio AD não confia mais em um computador, é provável que seja porque a senha do computador local não corresponde à senha armazenada no Active Directory.

As duas senhas devem estar sincronizadas para que o AD confie em um computador. Se não estiverem sincronizadas, você receberá a famosa mensagem de erro “a relação de confiança entre esta estação de trabalho e o domínio principal falhou“.

Infelizmente, nunca houve uma solução única que eu ou outros administradores de sistemas encontrassem que funcionasse 100% do tempo. É por isso que escrevi este guia.

Este guia pretende ser um único repositório para todas as maneiras de corrigir esse problema de uma vez por todas e automatizar o processo com o PowerShell.

Senhas de Contas de Computadores do Active Directory

Quando um novo computador é adicionado ao Active Directory, uma conta de computador é criada com uma senha. Essa senha é válida por padrão por 30 dias. Após 30 dias, ela é alterada automaticamente. Se ela mudar e a senha do cliente não mudar, você receberá a mensagem de erro “a relação de confiança entre esta estação de trabalho e o domínio principal falhou”.

Visualizando Políticas Existente

Você pode visualizar a política em toda a domínio abrindo o Console de Gerenciamento de Diretiva de Grupo (GPMC). Dentro do GPMC, clique na Política de Domínio Padrão, e navegue até Configuração do Computador –> Configurações do Windows –> Configurações de Segurança > Políticas Locais > Opções de Segurança.

Uma vez em Opções de Segurança, procure pela política chamada Membro do Domínio: Idade máxima da senha da conta da máquina.

Em um computador associado ao AD, abra o regedit e vá para a chave do registro HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters e encontre o valor MaximumPasswordAge conforme mostrado abaixo.

Enquanto estiver lá, você pode desabilitar o computador local de alterar a senha completamente, configurando o valor DisablePasswordChange para 1.

Quando a conta do computador muda, tanto o computador local quanto a conta do AD devem alterar suas senhas juntos. O AD conhece a atual e a anterior, caso elas fiquem fora de sincronia por um curto período.

O Processo de Alteração de Senha da Conta do Computador

Quando as coisas estão funcionando normalmente, usando o serviço Netlogon do Windows, o computador inicia automaticamente uma alteração de senha. Isso ocorre durante a reinicialização do computador ou quando o objeto do computador precisa se autenticar no AD.

Usando o serviço Netlogon do Windows, o computador local inicia uma sequência de alteração de senha. O computador primeiro inicia uma alteração de senha em um controlador de domínio. Se for bem-sucedido, ele tenta então alterar a senha local para coincidir com a chave de registro HKLM\SECURITY\Policy\Secrets<hostname>.ACC.

Normalmente, esse processo funciona muito bem, mesmo se o computador for desligado ou estiver offline por mais de 30 dias, porque o computador local inicia uma alteração de senha.

No entanto, um problema ocorre quando:

• o computador altera a conta do computador no AD, mas não consegue alterar a senha local
• o computador é reimaged sem executar o Sysprep
• o sistema operacional é reinstalado e está tentando se autenticar com a conta de computador antiga, habilitada, no AD
• e mais?

Se qualquer uma das situações acima ocorrer, você verá a mensagem de erro “a relação de confiança entre esta estação de trabalho e o domínio principal falhou.”

Verificando o Problema

Depois de identificar o problema, como replicá-lo ou pelo menos ter um método para determinar quais computadores têm o problema? Você poderia tentar fazer login interativamente em cada computador, mas isso não é escalável e eu não quero sair da minha mesa!

Vamos construir um script que possamos executar tanto localmente quanto remotamente para determinar quais computadores no domínio têm esse problema e erradicar de vez a mensagem de erro “a relação de confiança entre esta estação de trabalho e o domínio principal falhou”.

Primeiramente, como você está assumindo que a autenticação de domínio não está funcionando, será necessário saber uma conta de usuário local no grupo de administradores. Espero que saiba a senha do seu administrador local!

O nltest (Ferramenta de Linha de Comando)

nltest é uma ferramenta de linha de comando antiga que testará a relação de confiança para um computador. Essa ferramenta é instalada quando você instala RSAT ou está disponível diretamente em um controlador de domínio.

Você pode verificar uma relação de confiança em um computador quando estiver logado nele, executando:

> nltest /sc_verify:<your domain FQDN>

AVISO: Este método não é recomendado porque o nltest só funciona no contexto do usuário em que foi iniciado. Se o computador tiver uma relação de confiança quebrada e você estiver logado como usuário local, ele tentará se conectar ao domínio usando as credenciais do usuário local. Isso resultará em um erro de acesso negado.

netdom (Ferramenta de Linha de Comando)

netdom é outra ferramenta de linha de comando que você pode usar para verificar um relacionamento de confiança. Esta ferramenta também é instalada quando você instala RSAT ou está disponível diretamente em um controlador de domínio.

Relacionado:Como Instalar e Importar o Módulo Active Directory do PowerShell

Você pode verificar um relacionamento de confiança usando netdom verify fornecendo:

• o nome do computador para verificar
• FQDN do domínio
• nome de usuário para autenticar a solicitação
• senha da conta do usuário

Abaixo está um exemplo:

> netdom verify MYCOMPUTER /Domain:domain.local /UserO:abertram /PasswordO:*

Ao fornecer o valor de * para o parâmetro PasswordO, netdom solicitará a senha.

Test-ComputerSecureChannel (PowerShell)

Uma das melhores maneiras de resolver o problema “o relacionamento de confiança entre esta estação de trabalho e o domínio principal falhou” é usar o cmdlet Test-ComputerSecureChannel. Este cmdlet do PowerShell vem com o Windows 10 e é mais fácil de usar.

O cmdlet Test-ComputerSecureChannel funciona localmente em um computador com Windows 10. Quando estiver conectado ao computador de forma interativa, abra um console do PowerShell e execute Test-ComputerSecureChannel sem parâmetros. Ele retornará True ou False dependendo se a confiança é válida.

PS51> Test-ComputerSecureChannel
True

Você também pode especificar um controlador de domínio específico para confirmar se as senhas estão sincronizadas usando o parâmetro Server.

PS51> Test-ComputerSecureChannel -Server 'DC.domain.local'
False

Este cmdlet é fácil de usar e possui uma opção Repair, mas vamos deixar a demonstração disso para a seção de correção.

Se você souber a senha do administrador local desses computadores que deseja verificar e a Remoção do PowerShell estiver habilitada neles, você também pode usar o cmdlet Invoke-Command. Usando o cmdlet Invoke-Command, você pode executar remotamente Test-ComputerSecureChannel em um ou muitos computadores de uma só vez.

PS51> Invoke-Command -ComputerName PC1, PC2, PC3 -ScriptBlock { Test-ComputerSecureChannel }

Verificação de Relacionamentos de Confiança em Massa

Agora que você sabe como verificar remotamente um relacionamento de confiança, aqui está um trecho de código que você pode usar para verificar todos os seus computadores AD! Neste script, primeiro estou testando para garantir que o computador esteja online. Se não estiver, ele retornará Offline. Se sim, ele executará Test-ComputerSecureChannel em cada computador e retornará True ou False.

Testing trust relationships in bulk
$localCredential = Get-Credential
 
@(Get-AdComputer -Filter *).foreach({
 
   $output = @{ ComputerName = $_.Name }
 
   if (-not (Test-Connection -ComputerName $_.Name -Quiet -Count 1)) { $output.Status = 'Offline'
   } else {
       $trustStatus = Invoke-Command -ComputerName $_.Name -ScriptBlock { Test-ComputerSecureChannel } -Credential $localCredential
       $output.Status = $trustStatus
   }
 
   [pscustomobject]$output
 
})

Saber e entender o problema é o primeiro passo, mas como você o corrige? Agora você sabe que precisa fazer com que a conta do computador armazenada no computador local seja a mesma que a conta do computador armazenada no AD.

Existem muitas “soluções” diferentes disponíveis para o problema “a relação de confiança entre esta estação de trabalho e o domínio principal falhou”. Essas soluções podem ser executadas por meio da GUI, por meio do PowerShell ou por meio de ferramentas de linha de comando antigas.

1. Redefinir a senha da conta de computador no AD
2. Redefinir a senha da conta de computador local
3. Remover e reintegrar o computador Windows
4. Remover completamente a conta de computador e reintegrar o computador Windows

São muitas opções! Neste guia, vamos nos concentrar em resolver esse problema com o PowerShell e ferramentas de linha de comando (por questão de completude). Se você ainda não está usando o PowerShell, deveria!

Resolvendo o problema: Redefinindo senhas de computador

netdom (Ferramenta de Linha de Comando)

A trust can be repaired and the “the trust relationship between this workstation and the primary domain failed” error message can be eliminated by using the old-school netdom command-line tool. If you’re logged into the computer locally as an administrative user, you can run netdom resetpwd to initiate the password reset sequence as shown below.

Neste exemplo:

• DC é o nome do controlador de domínio
• abertram é o nome da conta de usuário do Active Directory com direitos para redefinir a conta de computador
• * é um espaço reservado para a senha da conta de usuário, que solicitará a senha.

> netdom resetpwd /s:DC /ud:abertram /pd:*

Reset-ComputerMachinePassword (PowerShell)

Uma das melhores maneiras de corrigir uma relação de confiança é usar o cmdlet Reset-ComputerMachinePassword. Esse cmdlet é executado no computador local e iniciará uma sequência de redefinição de senha. Sua sintaxe não poderia ser mais simples.

PS51> Reset-ComputerMachinePassword

Se você deseja especificar um DC específico para redefinir, pode especificá-lo usando o parâmetro Server junto com uma credencial opcional (que será o usuário local por padrão).

O exemplo abaixo solicitará um nome de usuário e uma senha do AD e tentará redefinir a senha no computador local e no controlador de domínio DC.

PS51> Reset-ComputerMachinePassword -Server DC -Credential (Get-Credential)

Isso também pode ser executado remotamente usando Invoke-Command se PowerShell Remoting estiver disponível no computador. Abaixo, estou obtendo o nome de usuário e a senha da conta de administrador local no computador. Também estou obtendo a credencial que tem direitos para redefinir a senha da conta do AD deste computador. Em seguida, estou passando $domainCredential para a sessão remota usando a construção $using.

$localAdminCredential = Get-Credential
$domainCredential = Get-Credential

PS51> Invoke-Command -Computername MYCOMPUTER -Credential $localAdminCredential -ScriptBlock { Reset-ComputerMachinePassword -Server DC -Credential $using:domainCredential }

Observe que isso também funciona mesmo se a conta do computador tiver sido removida do Active Directory. Crie uma conta de computador com o mesmo nome e Reset-ComputerMachinePassword garantirá que a senha seja sincronizada.

Redefinindo Senhas de Conta de Computador Local em Massa

Quer resolver aquele erro “a relação de confiança entre esta estação de trabalho e o domínio primário falhou” em vários computadores de uma vez? Sem problemas. Usando um prático laço foreach, também podemos executar Reset-ComputerMachinePassword em massa.

Resetting computer account passwords in bulk
$localAdminCredential = Get-Credential
$domainCredential = Get-Credential
 
@(Get-AdComputer -Filter *).foreach({
 
   $output = @{ ComputerName = $_.Name }
 
   if (-not (Test-Connection -ComputerName $_.Name -Quiet -Count 1)) { $output.Status = 'Offline'
   } else {
       $pwChangeOutput = Invoke-Command -Computername $_.Name -Credential $localAdminCredential -ScriptBlock { Reset-ComputerMachinePassword -Server DC -Credential $using:domainCredential }
       $output.PasswordChangeOutput = $pwChangeOutput
   }
 
   [pscustomobject]$output
 
})

Test-ComputerSecureChannel -Repair (PowerShell)

Outra maneira de iniciar o processo de alteração de senha é executar Test-ComputerSecureChannel, mas desta vez usando a opção Repair. Pelo que posso perceber, esse processo é idêntico ao uso de Reset-ComputerMachinePassword. No console do computador, utilize os parâmetros Repair e Credential.

PS51> Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Certifique-se de sempre usar o parâmetro Credential aqui. Se não o fizer, semelhante à utilidade nltest, ele tentará usar a conta local e não funcionará.

Reparar Relacionamentos de Confiança em Massa

Insira este comando no prático loop foreach que temos usado e está feito!

Resetting computer account passwords in bulk
$localAdminCredential = Get-Credential
$domainCredential = Get-Credential
 
@(Get-AdComputer -Filter *).foreach({
 
   $output = @{ ComputerName = $_.Name }
 
   if (-not (Test-Connection -ComputerName $_.Name -Quiet -Count 1)) { $output.Status = 'Offline'
   } else {
       $repairOutput = Invoke-Command -Computername $_.Name -Credential $localAdminCredential -ScriptBlock { Test-ComputerSecureChannel -Repair -Credential $using:domainCredential }
       $output.RepairOutput = $repairOutput
   }
 
   [pscustomobject]$output
 
})

Resolvendo o Problema: Reassociando ao Domínio

Se redefinir as senhas da conta do computador não funcionar para você, há sempre a opção nuclear. Você pode reintegrar um computador ao domínio do Active Directory. Embora não seja necessário o tempo todo, houve momentos em que tive que usar essa abordagem.

Observe que ouvi relatos de que uma desassociação não é necessária. Você pode conseguir apenas forçando uma nova associação. YMMV.

Você poderia:

• logar no computador via uma conta administrativa local
• ir para Propriedades do Sistema
• clicar em Alterar
• definir para um grupo de trabalho
• reiniciar
• definir de volta para o domínio

Observe como eu menciono que poderia. Não faça isso. É uma perda de tempo quando você pode automatizar com o PowerShell.

Existem duas maneiras que eu encontrei que você pode usar o PowerShell para desassociar um domínio e usar o PowerShell para associar um domínio.

Usando CIM

Você pode associar um domínio com PowerShell (e desassociá-lo) usando a classe CIM Win32_ComputerSystem. Esta classe tem dois métodos que permitem desassociar e associar um computador a um domínio chamados UnJoinDomainOrWorkgroup() e JoinDomainOrWorkGroup.

Relacionado:Aproveite os Cmdlets WMI do PowerShell para Explorar Qualquer Computador com Windows

Como isso é CIM, você pode executar isso tão facilmente remotamente quanto localmente. Como eu presumo que você prefira executar isso remotamente do conforto de sua mesa, aqui está um trecho de código que faz exatamente isso.

Erro “o relacionamento de confiança entre esta estação de trabalho e o domínio principal falhou” desapareça!

$computername = 'PITA'

$instance = Get-CimInstance -ComputerName $computername -ClassName 'Win32_ComputerSystem'

$invCimParams = @{
    MethodName = 'UnjoinDomainOrWorkGroup'
    Arguments = @{ FUnjoinOptions=0;Username="Administrator";Password="mypassword" }
}
$instance | Invoke-CimMethod @invCimParams

Observe o parâmetro FUnjoinOptions acima. Eu escolhi especificar 4 aqui. Isso executa o comportamento padrão ao desassociar um computador manualmente. Esta opção desativa a conta do computador no Active Directory (se encontrar uma). Se você preferir não ter esse comportamento, pode usar a opção 0 aqui.

Depois que o computador é desassociado, você pode então associar novamente ao domínio usando o método JoinDomainOrWorkGroup().

$computername = 'PITA'

$instance = Get-CimInstance -ComputerName $computername -ClassName 'Win32_ComputerSystem'

$invCimParams = @{
    MethodName = 'JoinDomainOrWorkGroup'
    Arguments = @{ FJoinOptions=3;Name=mydomain.local;Username="mydomain\domainuser";Password="mypassword" }
}
$instance | Invoke-CimMethod @invCimParams

Observe o parâmetro FJoinOptions acima. Eu optei por especificar 3 aqui. Isso realiza o comportamento padrão ao ingressar manualmente um computador. Essa opção cria uma conta de computador AD. Você pode encontrar algumas outras opções, como adicionar a uma OU específica via documentação JoinDomainOrWorkgroup.

DICA: Você também pode desassociar e reassociar muitos computadores de uma vez via este método, especificando vários computadores através do parâmetro ComputerName em Get-CimInstance.

Usando os Cmdlets Remove-Computer e Add-Computer

Você também pode usar cmdlets integrados do PowerShell para desassociar e associar um computador a um domínio com PowerShell. Você pode usar os cmdlets Remove-Computer e Add-Computer.

Para desassociar um computador com PowerShell, faça login no console do computador e use o cmdlet Remove-Computer. Forneça as credenciais de domínio com permissões para desassociar o computador. Você também pode especificar o parâmetro Restart para forçar uma reinicialização após a desassociação e Force para não solicitar confirmação.

PS51> Remove-Computer -UnjoinDomaincredential (Get-Credential) -Restart -Force

Depois que o computador for reiniciado, você poderá usar o cmdlet Add-Computer para associar o computador ao domínio com o PowerShell. Você pode usar o cmdlet Add-Computer remotamente fornecendo o parâmetro ComputerName. Você também usará credenciais de usuário local para fazer a conexão e as credenciais de domínio para autenticar no domínio.

Quando ele voltar, esperamos que você não receba mais a mensagem de erro “o relacionamento de confiança entre esta estação de trabalho e o domínio principal falhou”.

$localCredential = Get-Credential
$domainCredential = Get-Credential

Add-Computer -ComputerName PITA -LocalCredential $localCredential -DomainName domain.local -Credential $domainCredential -Restart -Force

Desassociação e Reassociação Automática do Domínio

Como tive que fazer este processo muitas vezes, criei um script PowerShell que faz tudo para você. Se você fornecer o nome do computador, ele irá:

• Desassociar o computador
• Reiniciar e aguardar a reinicialização
• Associar o computador
• Reiniciar e aguardar a reinicialização

Você pode experimentar este script via GitHub.

Resumo

Você deve agora ter uma compreensão completa do problema e várias soluções para a infame mensagem de erro “A relação de confiança entre esta estação de trabalho e o domínio primário falhou“. Espero que este guia tenha fornecido algumas ideias e permitido que você encontrasse algumas soluções próprias para o problema de computadores saindo do domínio!

Leitura Adicional

Não deixe de conferir alguns outros posts relacionados!

• Scripts do Active Directory em Abundância: Venha e Pegue!
• Get-AdUser: Encontrando usuários do Active Directory com PowerShell
• Como Sincronizar o AD usando PowerShell e um Arquivo CSV