Corrigir ‘Falha na Relação de Confiança Entre a Estação de Trabalho e o Domínio Principal’

Brazilian Portuguese
Uma das questões mais comuns que afligem os administradores de sistema do Windows é a aparente perda de confiança dos computadores do Active Directory no domínio. O infame erro “a relação de confiança entre esta estação de trabalho e o domínio primário falhou” é lamentavelmente comum.

Neste guia, você vai aprender todos os truques que eu encontrei em 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 primário falhou“

Quando um domínio do 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 mensagem de erro famosa “a relação de confiança entre esta estação de trabalho e o domínio primário falhou”.

Infelizmente, nunca houve uma solução única que eu e outros sysadmins encontramos que funcione 100% do tempo. Por isso, escrevi este guia.

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

Senhas de Conta de Computador do Active Directory

Quando um novo computador é adicionado ao Active Directory, uma conta de computador é criada com uma senha. Essa senha é válida por 30 dias, por padrão. Após 30 dias, ela muda 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 Existentes

Você pode visualizar a política em todo o domínio abrindo o Console de Gerenciamento de Política de Grupo (GPMC). Dentro do GPMC, clique na Política Padrão de Domínio, 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 a política chamada Membro do Domínio: Idade máxima da senha da conta de máquina.

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

Enquanto estiver lá, você pode desativar a mudança de senha do computador local definindo o valor DisablePasswordChange como 1.

Quando a conta do computador muda, tanto o computador local quanto a conta do AD devem mudar suas senhas juntos. O AD conhece a senha atual e a anterior no caso de ficarem fora de sincronia por um breve período.

O Processo de Mudança 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 troca 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 troca de senha. O computador primeiro inicia uma troca de senha em um controlador de domínio. Se isso for bem-sucedido, ele tenta então alterar a senha local para coincidir com a chave do registro HKLM\SECURITY\Policy\Secrets<hostname>.ACC.

Geralmente, esse processo funciona muito bem, mesmo se o computador estiver desligado ou offline por mais de 30 dias, pois o computador local inicia uma troca de senha.

No entanto, um problema ocorre quando:

• o computador altera a conta de computador no AD, mas não consegue alterar a senha local
• o computador é recriado sem executar o Sysprep
• o sistema operacional é reinstalado e está tentando se autenticar com a conta de computador AD antiga e ativada
• 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 saber que o problema existe, 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 levantar da minha mesa!

Vamos construir um script que podemos 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”.

Em primeiro lugar, como estamos assumindo que a autenticação de domínio não está funcionando, você precisará conhecer uma conta de usuário local no grupo de administradores. Espero que você saiba a senha do 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 de um computador. Essa ferramenta é instalada quando você instala RSAT ou está disponível diretamente em um controlador de domínio.

Você pode verificar a relação de confiança em um computador ao fazer login no mesmo, 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, resultando em um erro de acesso negado.

O netdom (Ferramenta de Linha de Comando)

netdom é outra ferramenta de linha de comando que você pode usar para verificar um relacionamento de confiança. Essa 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 a ser verificado
• 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 * 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 nenhum parâmetro. 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 de Repair, mas vamos deixar a demonstração disso para a seção de correção.

Se você conhece a senha do administrador local desses computadores que deseja verificar e a Remoção do PowerShell está habilitada neles, também pode usar o cmdlet Invoke-Command. Usando o cmdlet Invoke-Command, você pode executar remotamente Test-ComputerSecureChannel em um ou vários computadores de uma 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, retornará Offline. Se estiver, 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 conserta? 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.

Há muitas “soluções” 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 interface gráfica, via PowerShell ou por meio de ferramentas de linha de comando mais antigas.

1. Reinicie a senha da conta do computador no AD
2. Redefina a senha da conta local do computador
3. Desvincule e reconecte o computador com o Windows
4. Remova completamente a conta do computador e reconecte com o Windows

Isso oferece muitas opções! Neste guia, vamos nos concentrar em resolver esse problema com PowerShell e ferramentas de linha de comando (por uma 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 senha da conta do computador
• * é um espaço reservado para a senha da conta do 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 desejar especificar um DC específico para a redefinição, você pode fazê-lo usando o parâmetro Server juntamente com uma opção de credencial (ele usará o usuário local por padrão).

O exemplo abaixo solicitará um nome de usuário e 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 o PowerShell Remoting estiver disponível no computador. Abaixo, estou obtendo o nome de usuário e senha da conta de administrador local no computador. Também estou obtendo a credencial que tem direitos para redefinir a senha da conta AD deste computador. Em seguida, estou passando $domainCredential para a sessão remota usando o construtor $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. Criar uma conta de computador com o mesmo nome e Reset-ComputerMachinePassword garantirá que a senha seja sincronizada.

Redefinindo Senhas da Conta de Computador Local em Massa

Quer resolver o erro “o relacionamento de confiança entre esta estação de trabalho e o domínio principal falhou” em muitos computadores de uma só vez? Sem problemas. Usando um prático loop 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 consigo perceber, este 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
 
})

Corrigindo o Problema: Reassociando ao Domínio

Se redefinir as senhas das contas de computador não funcionar para você, há sempre a opção nuclear. Você pode associar novamente um computador ao domínio do Active Directory. Embora nem sempre seja necessário, houve momentos em que tive que usar essa abordagem.

Observe que ouvi relatos de que não é necessário desassociar. Talvez seja possível apenas forçar uma nova associação. Os resultados podem variar.

Você pode:

• fazer login no computador através de uma conta administrativa local
• ir para Propriedades do Sistema
• clicar em Alterar
• definir como um grupo de trabalho
• reiniciar
• definir de volta para o domínio

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

Existem duas maneiras que encontrei de 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 o PowerShell (e desassociá-lo) usando a classe CIM Win32_ComputerSystem. Esta classe possui dois métodos que permitem desassociar e associar um computador a um domínio chamados UnJoinDomainOrWorkgroup() e JoinDomainOrWorkGroup.

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

Já que se trata de CIM, você pode executar isso tanto remotamente quanto localmente com a mesma facilidade. Como presumo que você prefira executar isso remotamente do conforto de sua mesa, aqui está um trecho de código que faz exatamente isso.

O erro “o relacionamento de confiança entre esta estação de trabalho e o domínio primário 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. Escolhi especificar 4 aqui. Isso realiza o comportamento padrão ao desassociar um computador manualmente. Essa opção desabilita a conta de computador no Active Directory (se puder encontrar uma). Se você preferir não ter esse comportamento, pode usar a opção 0 aqui.

Depois que o computador for desassociado, você pode então associá-lo 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. Optei por especificar 3 aqui. Isso realiza o comportamento padrão ao ingressar manualmente em 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 por meio da documentação JoinDomainOrWorkgroup.

DICA: Você também pode desassociar e associar vários computadores de uma vez usando este método, especificando vários computadores por meio do parâmetro ComputerName no Get-CimInstance.

Usando os Cmdlets Remove-Computer e Add-Computer

Você também pode usar os 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 desvincular um computador com o 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 desvincular o computador. Você também pode especificar o parâmetro Restart para forçar uma reinicialização após a desvinculaçã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 vincular 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, espero 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

Desvincular e Vincular Automagicamente ao Domínio

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

• Desvincular o computador
• Reiniciar e esperar voltar
• Vincular o computador
• Reiniciar e esperar voltar

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ê desenvolvesse algumas soluções próprias para o problema de computadores saindo do domínio!

Leitura Adicional

Certifique-se de verificar outros posts relacionados!

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