Um controlador de domínio do Windows Server registra o evento 2095 do Directory Services quando encontra uma reversão da USN

  • Artigo

Este artigo descreve como detectar e recuperar se um controlador de domínio do Windows Server for revertido incorretamente usando uma instalação baseada em imagem do sistema operacional.

Aplica-se a: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Número de KB original: 875495

Observação

Este artigo destina-se apenas a agentes de suporte técnico e profissionais de TI. Se você estiver procurando ajuda com um problema, pergunte à Comunidade microsoft.

Resumo

Este artigo descreve uma falha silenciosa de replicação do Active Directory causada por uma reversão de número de sequência de atualização (USN). Uma reversão da USN ocorre quando uma versão mais antiga de um banco de dados do Active Directory é incorretamente restaurada ou colada no local.

Quando ocorre uma reversão da USN, as modificações em objetos e atributos que ocorrem em um controlador de domínio não são replicadas para outros controladores de domínio na floresta. Como os parceiros de replicação acreditam que eles têm uma cópia atualizada do banco de dados do Active Directory, ferramentas de monitoramento e solução de problemas, como Repadmin.exe não relatam erros de replicação.

Os controladores de domínio registram o Evento 2095 do Directory Services no log de eventos dos Serviços de Diretório quando detectam uma reversão usn. O texto da mensagem de evento direciona os administradores para este artigo para saber mais sobre as opções de recuperação.

Exemplo de entrada de log do Evento 2095

Log Name:      <Service name> Service  
Source:        Microsoft-Windows-ActiveDirectory_DomainService  
Date:          <DateTime>
Event ID:      2095  
Task Category: Replication  
Level:         Error  
Keywords:      Classic  
User:          <USER NAME>  
Computer:      SERVER.contoso.com  
Description:

During an Active Directory Domain Services replication request, the local domain controller (DC) identified a remote DC which has received replication data from the local DC using already-acknowledged USN tracking numbers.

Because the remote DC believes it is has a more up-to-date Active Directory Domain Services database than the local DC, the remote DC will not apply future changes to its copy of the Active Directory Domain Services database or replicate them to its direct and transitive replication partners that originate from this local DC.

If not resolved immediately, this scenario will result in inconsistencies in the Active Directory Domain Services databases of this source DC and one or more direct and transitive replication partners. Specifically the consistency of users, computers and trust relationships, their passwords, security groups, security group memberships and other Active Directory Domain Services configuration data may vary, affecting the ability to log on, find objects of interest and perform other critical operations.

To determine if this misconfiguration exists, query this event ID using http://support.microsoft.com or contact your Microsoft product support.

The most probable cause of this situation is the improper restore of Active Directory Domain Services on the local domain controller.

User Actions:

If this situation occurred because of an improper or unintended restore, forcibly demote the DC.

Os tópicos a seguir discutem como detectar e recuperar de uma reversão da USN em um controlador de domínio baseado no Windows Server.

Métodos com suporte para fazer backup do Active Directory em controladores de domínio que estão executando Windows Server 2012 e versões posteriores

Windows Server 2012 adiciona suporte para o GenID (ID de Geração Hyper-Visor). Isso permite que o convidado virtual detecte os volumes de disco que têm uma nova ID e responda ao novo GenID. No Active Directory, os Serviços de Diretório reagem como se o controlador de domínio fosse restaurado de um backup. Em seguida, ele gera uma nova ID de Invocação. Usando a nova ID de Invocação, a instância do banco de dados pode reentrar com segurança na replicação na floresta.

Esse é um dos cenários abordados na Implantação e Configuração do Controlador de Domínio Virtualizado.

Métodos com suporte para fazer backup do Active Directory em controladores de domínio que estão executando o Windows Server 2003 ou versões posteriores do Windows Server

Ao longo do ciclo de vida de um controlador de domínio, talvez seja necessário restaurar ou "reverter", o conteúdo do banco de dados do Active Directory para um bom ponto conhecido no tempo. Ou talvez você precise reverter elementos do sistema operacional host de um controlador de domínio, incluindo o Active Directory, para um ponto bom conhecido.

Veja a seguir os métodos compatíveis que você pode usar para reverter o conteúdo do Active Directory:

  • Use um utilitário de backup e restauração com reconhecimento do Active Directory que usa APIs fornecidas pela Microsoft e testadas pela Microsoft. Essas APIs restauram de forma não autoritativa ou autoritativa um backup de estado do sistema. O backup restaurado deve se originar da mesma instalação do sistema operacional e do mesmo computador físico ou virtual que está sendo restaurado.

  • Use um utilitário de backup e restauração com reconhecimento do Active Directory que usa APIs do Serviço de Cópia de Sombra do Microsoft Volume. Essas APIs faz backup e restauram o estado do sistema do controlador de domínio. O Serviço de Cópia de Sombra de Volume dá suporte à criação de cópias de sombra pontual única de volumes únicos ou múltiplos em computadores que estão executando o Windows Server 2003, Windows Server 2008 ou Windows Server 2008 R2. Cópias de sombra pontual única também são conhecidas como instantâneos. Para obter mais informações, pesquise "Serviço de Cópia de Sombra de Volume" em Suporte da Microsoft.

  • Restaure o estado do sistema. Avalie se existem backups de estado válidos do sistema para este controlador de domínio. Se um backup de estado do sistema válido foi feito antes que o controlador de domínio revertido fosse restaurado incorretamente e, se o backup contiver alterações recentes feitas no controlador de domínio, restaure o estado do sistema do backup mais recente.

Comportamento típico que ocorre quando você restaura um backup de estado do sistema com reconhecimento do Active Directory

Os controladores de domínio do Windows Server usam USNs junto com as IDs de invocação para acompanhar atualizações que devem ser replicadas entre parceiros de replicação em uma floresta do Active Directory.

Os controladores de domínio de origem usam USNs para determinar quais alterações já foram recebidas pelo controlador de domínio de destino que está solicitando alterações. Os controladores de domínio de destino usam USNs para determinar quais alterações devem ser solicitadas de controladores de domínio de origem.

A ID de invocação identifica a versão ou a instanciação do banco de dados do Active Directory que está em execução em um determinado controlador de domínio.

Quando o Active Directory é restaurado em um controlador de domínio usando as APIs e os métodos que a Microsoft projetou e testou, a ID de invocação é redefinida corretamente no controlador de domínio restaurado. os controladores de domínio na floresta recebem notificação da redefinição de invocação. Portanto, eles ajustam seus altos valores de marca d'água de acordo.

Software e metodologias que causam reversões de USN

Quando os seguintes ambientes, programas ou subsistemas são usados, os administradores podem ignorar as verificações e validações que a Microsoft projetou para ocorrer quando o estado do sistema do controlador de domínio for restaurado:

  • Iniciar um controlador de domínio do Active Directory cujo arquivo de banco de dados do Active Directory foi restaurado (copiado) no local usando um programa de imagem como o Norton Ghost.

  • Iniciando uma imagem de disco rígido virtual salva anteriormente de um controlador de domínio. O cenário a seguir pode causar uma reversão da USN:

    1. Promova um controlador de domínio em um ambiente de hospedagem virtual.
    2. Crie uma versão instantâneo ou alternativa do ambiente de hospedagem virtual.
    3. Deixe que o controlador de domínio continue a replicar de entrada e a replicação de saída.
    4. Inicie o arquivo de imagem do controlador de domínio que você criou na etapa 2.

  • Exemplos de ambientes de hospedagem virtualizados que causam esse cenário incluem o Microsoft Virtual PC 2004, o Microsoft Virtual Server 2005 e o VMWARE do EMC. Outros ambientes de hospedagem virtualizados também podem causar esse cenário.

  • Para obter mais informações sobre as condições de suporte para controladores de domínio em ambientes de hospedagem virtual, consulte Coisas a serem consideradas ao hospedar controladores de domínio do Active Directory em ambientes de hospedagem virtual.

  • Iniciar um controlador de domínio do Active Directory localizado em um volume em que o subsistema de disco é carregado usando imagens salvas anteriormente do sistema operacional sem exigir uma restauração do estado do sistema do Active Directory.

    • Cenário A: Iniciando várias cópias do Active Directory localizadas em um subsistema de disco que armazena várias versões de um volume

      1. Promover um controlador de domínio. Localize o arquivo Ntds.dit em um subsistema de disco que pode armazenar várias versões do volume que hospeda o arquivo Ntds.dit.
      2. Use o subsistema de disco para criar um instantâneo do volume que hospeda o arquivo Ntds.dit para o controlador de domínio.
      3. Continue permitindo que o controlador de domínio carregue o Active Directory do volume que você criou na etapa 1.
      4. Inicie o controlador de domínio que o banco de dados do Active Directory salvou na etapa 2.

    • Cenário B: Iniciar o Active Directory de outras unidades em um espelho quebrado

      1. Promover um controlador de domínio. Localize o arquivo Ntds.dit em uma unidade espelhada.
      2. Quebre o espelho.
      3. Continue a replicar e replicar a saída de entrada usando o arquivo Ntds.dit na primeira unidade do espelho.
      4. Inicie o controlador de domínio usando o arquivo Ntds.dit na segunda unidade no espelho.

Mesmo que não pretendido, cada um desses cenários pode fazer com que os controladores de domínio revertam para uma versão mais antiga do banco de dados do Active Directory por métodos sem suporte. A única maneira com suporte para reverter o conteúdo do Active Directory ou do estado local de um controlador de domínio do Active Directory é usar um utilitário de backup e restauração com reconhecimento do Active Directory para restaurar um backup de estado do sistema que se originou da mesma instalação do sistema operacional e do mesmo computador físico ou virtual que está sendo restaurado.

A Microsoft não dá suporte a nenhum outro processo que leve uma instantâneo dos elementos do estado do sistema de um controlador de domínio do Active Directory e copia elementos desse estado do sistema para uma imagem do sistema operacional. A menos que um administrador intervenha, esses processos causam uma reversão da USN. Essa reversão da USN faz com que os parceiros de replicação direta e transitiva de um controlador de domínio restaurado incorretamente tenham objetos inconsistentes em seus bancos de dados do Active Directory.

Os efeitos de uma reversão da USN

Quando ocorrem reversões usn, modificações em objetos e atributos não são de entrada replicadas por controladores de domínio de destino que já viram a USN anteriormente.

Como esses controladores de domínio de destino acreditam que estão atualizados, nenhum erro de replicação é relatado em logs de eventos do Serviço de Diretório ou por ferramentas de monitoramento e diagnóstico.

A reversão da USN pode afetar a replicação de qualquer objeto ou atributo em qualquer partição. O efeito colateral mais observado é que contas de usuário e contas de computador criadas no controlador de domínio de reversão não existem em um ou mais parceiros de replicação. Ou, as atualizações de senha originadas no controlador de domínio de reversão não existem em parceiros de replicação.

As etapas a seguir mostram a sequência de eventos que podem causar uma reversão da USN. Uma reversão usn ocorre quando o estado do sistema do controlador de domínio é revertido no tempo usando uma restauração de estado do sistema sem suporte.

  1. Um administrador promove três controladores de domínio em um domínio. (Neste exemplo, os controladores de domínio são DC1, DC2 e DC2, e o domínio é Contoso.com.) DC1 e DC2 são parceiros de replicação direta. DC2 e DC3 também são parceiros diretos de replicação. DC1 e DC3 não são parceiros diretos de replicação, mas recebem atualizações de origem transitivamente por meio do DC2.

  2. Um administrador cria 10 contas de usuário que correspondem a USNs 1 a 10 no DC1. Todas essas contas são replicadas para DC2 e DC3.

  3. Uma imagem de disco de um sistema operacional é capturada no DC1. Esta imagem tem um registro de objetos que correspondem a USNs locais de 1 a 10 no DC1.

  4. As seguintes alterações são feitas no Active Directory:

    • As senhas de todas as 10 contas de usuário criadas na etapa 2 são redefinidas no DC1. Essas senhas correspondem a USNs 11 a 20. Todas as 10 senhas atualizadas são replicadas para DC2 e DC3.
    • 10 novas contas de usuário que correspondem a USNs de 21 a 30 são criadas no DC1. Essas 10 contas de usuário são replicadas para DC2 e DC3.
    • 10 novas contas de computador que correspondem a USNs de 31 a 40 são criadas no DC1. Essas 10 contas de computador são replicadas para DC2 e DC3.
    • 10 novos grupos de segurança que correspondem às USNs 41 a 50 são criados no DC1. Esses 10 grupos de segurança replicam para DC2 e DC3.

  5. O DC1 enfrenta uma falha de hardware ou uma falha de software. O administrador usa um utilitário de imagem de disco para copiar a imagem do sistema operacional criada na etapa 3. O DC1 agora começa com um banco de dados do Active Directory que tem conhecimento de USNs 1 a 10.

    Como a imagem do sistema operacional foi copiada no local e um método com suporte para restaurar o estado do sistema não foi usado, o DC1 continua a usar a mesma ID de invocação que criou a cópia inicial do banco de dados e todas as alterações até USN 50. DC2 e DC3 também mantêm a mesma ID de invocação para DC1, bem como um vetor atualizado de USN 50 para DC1. (Um vetor atualizado é o status atual das atualizações de origem mais recentes a ocorrer em todos os controladores de domínio para uma determinada partição de diretório.)

    A menos que um administrador intervenha, DC2 e DC3 não ingressam replicando as alterações que correspondem ao USN 11 a 50 local que se originam do DC1. Além disso, de acordo com a ID de invocação que o DC2 usa, o DC1 já tem conhecimento das alterações que correspondem a USN 11 a 50. Portanto, o DC2 não envia essas alterações. Como as alterações na etapa 4 não existem no DC1, as solicitações de logon falham com um erro de "acesso negado". Esse erro ocorre porque as senhas não correspondem ou porque a conta não existe quando as contas mais recentes se autenticam aleatoriamente com DC1.

  6. Os administradores que monitoram a integridade da replicação na floresta observam as seguintes situações:

    • A Repadmin /showreps ferramenta de linha de comando relata que a replicação bidirecional do Active Directory entre DC1 e DC2 e entre DC2 e DC3 está ocorrendo sem erro. Essa situação dificulta a detecção de qualquer inconsistência de replicação.

    • Os eventos de replicação nos logs de eventos do serviço de diretório de controladores de domínio que estão executando o Windows Server não indicam falhas de replicação nos logs de eventos do serviço de diretório. Essa situação dificulta a detecção de qualquer inconsistência de replicação.

    • Usuários e Computadores do Active Directory ou a Ferramenta de Administração do Active Directory (Ldp.exe) mostram uma contagem diferente de objetos e metadados de objeto diferentes quando as partições de diretório de domínio em DC2 e DC3 são comparadas à partição em DC1. A diferença é o conjunto de alterações que mapeiam para USN altera de 11 a 50 na etapa 4.

      Observação

      Neste exemplo, a contagem de objetos diferente se aplica a contas de usuário, contas de computador e grupos de segurança. Os diferentes metadados de objeto representam as diferentes senhas da conta de usuário.

    • Solicitações de autenticação de usuário para as 10 contas de usuário que foram criadas na etapa 2 ocasionalmente geram um erro de "acesso negado" ou "senha incorreta". Esse erro pode ocorrer porque existe uma incompatibilidade de senha entre essas contas de usuário no DC1 e as contas em DC2 e DC3. As contas de usuário que experimentam esse problema correspondem às contas de usuário criadas na etapa 4. As contas de usuário e as redefinições de senha na etapa 4 não foram replicadas para outros controladores de domínio no domínio.

  7. DC2 e DC3 começam a replicar atualizações originárias de entrada que correspondem a números usn maiores que 50 de DC1. Essa replicação prossegue normalmente sem intervenção administrativa porque o limite de vetor atualizado anteriormente registrado, USN 50, foi excedido. (USN 50 foi o vetor atualizado USN registrado para DC1 em DC2 e DC3 antes de DC1 ser retirado offline e restaurado.) No entanto, as novas alterações que corresponderam às USNs 11 a 50 no DC1 de origem após a restauração sem suporte nunca serão replicadas para DC2, DC3 ou seus parceiros de replicação transitiva.

Embora os sintomas mencionados na etapa 6 representem parte do efeito que uma reversão da USN pode ter em contas de usuário e computador, uma reversão da USN pode impedir que qualquer tipo de objeto em qualquer partição do Active Directory seja replicado. Esses tipos de objeto incluem o seguinte:

  • A topologia e a agenda de replicação do Active Directory

  • A existência de controladores de domínio na floresta e as funções que esses controladores de domínio mantêm

    Observação

    Essas funções incluem o catálogo global, alocações de RID (identificador relativo) e operações master funções. (As funções de master de operações também são conhecidas como operações de master simples flexíveis ou FSMO.)

  • A existência de partições de domínio e aplicativo na floresta

  • A existência de grupos de segurança e suas associações de grupo atuais

  • Registro de DNS em zonas DNS integradas ao Active Directory

O tamanho do buraco usn pode representar centenas, milhares ou até mesmo dezenas de milhares de alterações para usuários, computadores, trusts, senhas e grupos de segurança. (O buraco USN é definido pela diferença entre o número mais alto de USN que existia quando o backup de estado do sistema restaurado foi feito e o número de alterações de origem que foram criadas no controlador de domínio revertido antes de ser retirado offline.)

Detectar uma reversão usn em um controlador de domínio do Windows Server

Como uma reversão de USN é difícil de detectar, um windows Server 2003 SP1 ou posterior do controlador de domínio da versão posterior registra o evento 2095 quando um controlador de domínio de origem envia um número USN reconhecido anteriormente para um controlador de domínio de destino sem uma alteração correspondente na ID de invocação.

Para impedir que atualizações exclusivas de origem para o Active Directory sejam criadas no controlador de domínio restaurado incorretamente, o serviço Net Logon é pausado. Quando o serviço Net Logon é pausado, as contas de usuário e computador não podem alterar a senha em um controlador de domínio que não replicará essas alterações de saída. Da mesma forma, as ferramentas de administração do Active Directory favorecerão um controlador de domínio saudável quando fizerem atualizações para objetos no Active Directory.

Em um controlador de domínio, as mensagens de evento que se assemelham ao seguinte são registradas se as seguintes condições forem verdadeiras:

  • Um controlador de domínio de origem envia um número USN reconhecido anteriormente para um controlador de domínio de destino.
  • Não há nenhuma alteração correspondente na ID de invocação.

Esses eventos podem ser capturados no log de eventos do Serviço de Diretório. No entanto, eles podem ser substituídos antes de serem observados por um administrador.

Você pode suspeitar que ocorreu uma reversão da USN. No entanto, você não vê os eventos de correlação no log de eventos do Serviço de Diretório. Nesse cenário, marcar para a entrada do registro Dsa Não Gravável. Esta entrada fornece evidências forenses de que ocorreu uma reversão da USN.

  • Subchave do Registro: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
  • Entrada do Registro: Dsa Não Gravável
  • Valor: 0x4

Excluir ou alterar manualmente o valor de entrada do registro Dsa Não Gravável coloca o controlador de domínio de reversão em um estado permanentemente sem suporte. Portanto, essas alterações não têm suporte. Especificamente, modificar o valor remove o comportamento de quarentena adicionado pelo código de detecção de reversão da USN. As partições do Active Directory no controlador de domínio de reversão serão permanentemente inconsistentes com parceiros de replicação diretos e transitivos na mesma floresta do Active Directory.

Recuperar-se de uma reversão da USN

Há três abordagens para se recuperar de uma reversão da USN.

Referências