Compartilhar via

Um controlador de domínio do Windows Server registra o evento 2095 dos Serviços de Diretório quando encontra uma reversão de 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.

Número original do KB: 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 da Microsoft.

Resumo

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

Quando ocorre uma reversão de 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 ter uma cópia atualizada do banco de dados do Active Directory, as 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 dos Serviços de Diretório no log de eventos dos Serviços de Diretório quando detectam uma reversão de 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 se recuperar de uma reversão de 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 executam o Windows Server 2012 e versões posteriores

O Windows Server 2012 adiciona suporte para o Hyper-Visor Generation ID (GenID). 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 tivesse sido restaurado de um backup. Em seguida, ele gera um novo ID de invocação. Usando a nova ID de Invocação, a instância do banco de dados pode reinserir com segurança a replicação na floresta.

Esse é um dos cenários abordados em 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 executam o Windows Server 2003 ou versões posteriores do Windows Server

Durante o 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 momento. Ou talvez seja necessário reverter elementos do sistema operacional host de um controlador de domínio, incluindo o Active Directory, para um ponto válido.

A seguir estão os métodos com suporte 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 use APIs fornecidas e testadas pela Microsoft. Essas APIs restauram de forma não autoritativa ou autoritativa um backup de estado do sistema. O backup restaurado deve ser originado 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 use APIs do Serviço de Cópias de Sombra de Volume da Microsoft. Essas APIs fazem backup e restauram o estado do sistema do controlador de domínio. O Serviço de Cópias de Sombra de Volume oferece suporte à criação de cópias de sombra pontuais únicas de um ou vários volumes em computadores que executam o Windows Server 2003, o Windows Server 2008 ou o Windows Server 2008 R2. As cópias de sombra de um único ponto no tempo também são conhecidas como instantâneos. Para obter mais informações, pesquise "Serviço de cópias de sombra de volume" no Suporte da Microsoft.

  • Restaure o estado do sistema. Avalie se existem backups de estado do sistema válidos para esse controlador de domínio. Se um backup de estado do sistema válido tiver sido feito antes que o controlador de domínio revertido tenha sido 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 controlar as 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 dos 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á sendo executado 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 da 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 é 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 geração de imagens, 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 de USN:

    1. Promova um controlador de domínio em um ambiente de hospedagem virtual.
    2. Crie um instantâneo ou uma versão alternativa do ambiente de hospedagem virtual.
    3. Permita que o controlador de domínio continue a replicar de entrada e a replicar 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 EMC VMWARE. 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 considerar 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. Promova um controlador de domínio. Localize o arquivo Ntds.dit em um subsistema de disco que possa 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: Iniciando o Active Directory a partir de outras unidades em um espelho quebrado

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

Mesmo que não seja intencional, 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 de reverter o conteúdo do Active Directory ou o 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 originado da mesma instalação do sistema operacional e do mesmo computador físico ou virtual que está sendo restaurado.

A Microsoft não oferece suporte a nenhum outro processo que tire um instantâneo dos elementos do estado do sistema de um controlador de domínio do Active Directory e copie elementos desse estado do sistema para uma imagem do sistema operacional. A menos que um administrador intervenha, esses processos causam uma reversão de USN. Essa reversão de 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 de USN

Quando ocorrem reversões de USN, modificações em objetos e atributos não são replicados de entrada por controladores de domínio de destino que tenham visto anteriormente o USN.

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

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

As etapas a seguir mostram a sequência de eventos que podem causar uma reversão de USN. Uma reversão de 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 de replicação direta. DC1 e DC3 não são parceiros de replicação direta, mas recebem atualizações de origem transitivamente por meio do DC2.

  2. Um administrador cria 10 contas de usuário que correspondem aos 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. Essa imagem tem um registro de objetos que correspondem aos 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 aos USNs 11 a 20. Todas as 10 senhas atualizadas são replicadas para DC2 e DC3.
    • 10 novas contas de usuário que correspondem aos USNs 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 aos USNs 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 aos USNs 41 a 50 são criados no DC1. Esses 10 grupos de segurança são replicados para DC2 e DC3.

  5. O DC1 apresenta uma falha de hardware ou de software. O administrador usa um utilitário de imagem de disco para copiar a imagem do sistema operacional criada na etapa 3 no local. O DC1 agora começa com um banco de dados do Active Directory que tem conhecimento dos 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 o mesmo 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 que ocorrem 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 replicam de entrada as alterações que correspondem ao USN local 11 a 50 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 ao 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 são autenticadas 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 erros. 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 executam o Windows Server não indicam nenhuma falha 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 com a partição em DC1. A diferença é o conjunto de alterações mapeadas para as alterações de USN de 11 a 50 na etapa 4.

      Observação

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

    • As 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 no DC2 e DC3. As contas de usuário que apresentam 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 de entrada as atualizações de origem que correspondem a números USN maiores que 50 do DC1. Essa replicação prossegue normalmente sem intervenção administrativa porque o limite do vetor de atualização registrado anteriormente, USN 50, foi excedido. (USN 50 foi o USN vetorial de atualização registrado para DC1 em DC2 e DC3 antes de DC1 ser colocado offline e restaurado.) No entanto, as novas alterações que corresponderam aos 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 de USN pode ter nas contas de usuário e computador, uma reversão de 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, as alocações de RID (identificador relativo) e as funções de mestre de operações. (As funções de mestre de operações também são conhecidas como operações de mestre único flexíveis ou FSMO.)

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

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

  • Registro de registro DNS em zonas DNS integradas do Active Directory

O tamanho da falha de USN pode representar centenas, milhares ou até mesmo dezenas de milhares de alterações em usuários, computadores, relações de confiança, senhas e grupos de segurança. (O buraco de USN é definido pela diferença entre o número de USN mais alto 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 colocado offline.)

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

Como uma reversão de USN é difícil de detectar, um controlador de domínio do Windows Server 2003 SP1 ou 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 de origem exclusivas do Active Directory sejam criadas no controlador de domínio restaurado incorretamente, o serviço Logon de Rede está em pausa. Quando o serviço de Logon de Rede é 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 íntegro quando fizerem atualizações em objetos no Active Directory.

Em um controlador de domínio, as mensagens de evento semelhantes às seguintes serão registradas se as seguintes condições forem verdadeiras:

  • Um controlador de domínio de origem envia um número de USN confirmado anteriormente para um controlador de domínio de destino.
  • Não há 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, elas podem ser substituídas antes de serem observadas por um administrador.

Você pode suspeitar que ocorreu uma reversão de USN. No entanto, você não vê os eventos correlacionados no log de eventos do Serviço de Diretório. Nesse cenário, verifique a entrada do Registro Dsa Not Writable. Essa entrada fornece evidências forenses de que uma reversão de USN ocorreu.

  • 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 Not Writable 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 de USN. As partições do Active Directory no controlador de domínio de reversão ficarão permanentemente inconsistentes com parceiros de replicação direta e transitiva na mesma floresta do Active Directory.

Recuperar de uma reversão de USN

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

  • Remova o Controlador de Domínio do domínio. Para fazer isso, siga estas etapas:

    1. Remova o Active Directory do controlador de domínio para forçá-lo a ser um servidor autônomo. Para obter mais informações, consulte Os controladores de domínio não são rebaixados normalmente quando você usa o Assistente de Instalação do Active Directory para forçar o rebaixamento.

    2. Desligue o servidor rebaixado.

    3. Em um controlador de domínio íntegro, limpe os metadados do controlador de domínio rebaixado. Para obter mais informações, consulte Limpar metadados do servidor do Controlador de Domínio do Active Directory.

    4. Se o controlador de domínio restaurado incorretamente hospeda funções de mestre de operações, transfira essas funções para um controlador de domínio íntegro. Para obter mais informações, consulte Transferir ou capturar funções de Mestre de Operação nos Serviços de Domínio Active Directory.

    5. Reinicie o servidor rebaixado.

    6. Se for necessário, instale o Active Directory novamente no servidor autônomo.

    7. Se o controlador de domínio anteriormente era um catálogo global, configure o controlador de domínio para ser um catálogo global. Para obter mais informações, consulte Como criar ou mover um catálogo global.

    8. Se o controlador de domínio anteriormente hospedou funções de mestre de operações, transfira as funções de mestre de operações de volta para o controlador de domínio. Para obter mais informações, consulte Transferir ou capturar funções de Mestre de Operação nos Serviços de Domínio Active Directory.

  • Restaure o estado do sistema de um bom backup.

    Avalie se existem backups de estado do sistema válidos para esse controlador de domínio. Se um backup de estado do sistema válido tiver sido feito antes de o controlador de domínio revertido ter sido restaurado incorretamente e o backup contiver alterações recentes feitas no controlador de domínio, restaure o estado do sistema com base no backup mais recente.

  • Restaure o estado do sistema sem backup do estado do sistema.

    Você pode usar o instantâneo como uma fonte de backup. Ou você pode definir o banco de dados para fornecer a si mesmo uma nova ID de invocação usando o procedimento na seção Para restaurar uma versão anterior de um VHD de controlador de domínio virtual sem backup de dados de estado do sistema de Executando controladores de domínio no Hyper-V.

Referências