Confiança do domínio falhou após um mês offline? Verifique primeiro

Um portátil fica seis semanas fora da VPN, regressa, e o utilizador não consegue iniciar sessão com uma conta de domínio. O erro menciona uma relação de confiança, por isso alguém repõe a conta de computador, ou força o utilizador para o túnel completo, e o problema parece desaparecer. Nenhuma das ações provou o que estava avariado. Um membro Windows pode ficar offline muito além do intervalo habitual da palavra-passe da máquina sem perder a confiança automaticamente, pelo que a primeira tarefa é separar uma falha de alcance de uma verdadeira divergência do segredo.

O erro parece de confiança, mas três estados parecem-se

Um utilizador pode iniciar sessão com informações de domínio em cache, a estação de trabalho pode não localizar nenhum controlador de domínio, ou o membro e o domínio podem discordar realmente sobre a conta de computador. Só o terceiro é uma relação de confiança quebrada em sentido estrito.

O estado da replicação do AD é uma quarta observação, e não diz respeito a esta estação de trabalho. Descreve o acordo entre controladores de domínio, e um painel de replicação saudável não prova que o segredo local desta máquina corresponde à sua conta de computador.

O conhecido valor predefinido de 30 dias é uma política de alteração, não um prazo de expiração offline. A explicação da Microsoft sobre a palavra-passe da conta de máquina descreve um processo de alteração coordenado, e uma organização pode configurar um intervalo diferente.

Um ícone de VPN não prova nada sobre o canal seguro

A conetividade tem de ser suficientemente boa para alcançar os serviços de domínio antes de qualquer teste significar algo. Isso significa o resoluvedor DNS de domínio previsto, um controlador localizável, serviços de autenticação acessíveis e um relógio suficientemente próximo para Kerberos.

O túnel completo pode ser um desenho perfeitamente válido aqui. Passar para túnel dividido não é um pré-requisito para uma relação de domínio saudável, e tratá-lo como tal transforma um diagnóstico numa alteração de arquitetura. Verifique que controlador a estação de trabalho escolhe realmente, e guarde esse nome junto ao erro.

nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -Verbose

Anote o servidor DNS, o controlador resolvido e o texto exato do erro. Um cliente VPN que diz estar ligado informa que o túnel existe, não que o caminho para o domínio funciona. Um controlador que responde na porta Kerberos mas não na porta de diretório é um achado de firewall, não um achado de confiança.

Teste o membro antes de o reparar

Num membro de domínio Windows autorizado, Test-ComputerSecureChannel -Verbose é uma verificação apenas de leitura do canal entre a máquina e o domínio. Execute-a no contexto da máquina que está a investigar, não a partir de um controlador de domínio, que tem outro papel e outras regras de recuperação. Registe a saída e o estado de saída em vez da palavra passou ou falhou. Se o cmdlet faltar nessa compilação, o módulo é um problema separado.

O resultado ainda precisa de contexto. Se a máquina não conseguir alcançar ou autenticar-se no controlador escolhido, um teste falhado não é prova independente de que uma palavra-passe offline expirou. Guarde o erro real e o controlador utilizado, e repita o teste quando o caminho for conhecido como bom.

Correlacione os eventos Netlogon no membro e no controlador relevante em torno do incidente. Guarde o nome da máquina, o endereço de origem, a hora e qualquer evidência de alteração de conta. Um início de sessão com êxito de outro utilizador, ou um painel de controlador saudável, não podem substituir a troca desta máquina.

Repare apenas a relação que provou

Assim que a conetividade estiver estável e um administrador tiver confirmado que uma reparação é adequada, o modo -Repair do cmdlet com credenciais autorizadas é uma operação suportada para uma estação de trabalho membro. Altera a relação, e não é outro teste apenas de leitura.

Tenha uma conta local de recuperação aprovada e um caminho de gestão disponíveis antes da alteração. Os controladores de domínio têm outro papel de recuperação e este procedimento não os deve tratar como estações de trabalho comuns. Use o fluxo de recuperação da organização em vez de executar várias ferramentas de reposição em sequência e esperar que uma delas seja a correta.

Após a reparação, verifique um novo teste do canal seguro e a operação de domínio original. Preserve os perfis de utilizador e o estado das aplicações, e não faça da remoção-e-reassociação a primeira ação sem explicação.

O que verificar quando a falha regressa

Se a falha regressar, olhe para a reversão, a identidade duplicada e o momento das alterações de conta em vez de repor novamente a mesma conta. Uma imagem restaurada, um instantâneo, uma identidade de máquina clonada ou uma reposição de conta de computador feita noutro local merecem todos investigação.

Uma reposição bem-sucedida temporária é evidência de recuperação útil, mas não é prova de que uma VPN intermitente causou a divergência original. A ocorrência seguinte é a que lhe diz se a causa chegou a ser removida.

Escreva o controlador, o servidor DNS e a saída do teste no ticket. Esse registo é o que distingue uma falha de confiança real de um portátil que simplesmente não conseguiu encontrar o domínio.