Objetos Remanescentes no Active Directory

  • Article

 

Um assunto um tanto desconhecido e um tanto interessante e muito importante e fundamental na manutenção da saúde do Active Directory é a identificação e o tratamento dos “Objetos Remanescentes” , também conhecido como “Lingering Objects”, ou seja todos os objetos que “ficaram, sobraram ou restaram” por algum motivo após serem excluídos no passado.

Para entedermos porque isso ocorre, primeiro precisamos compreender o que ocorre quando um objeto é excluído no Active Directory. Na verdade, quando um objetivo é excluído ele não é excluído fisicamente no banco (NTDS.DIT) , e sim marcado para exclusão, na verdade o que ocorre é que um atributo escondido chamado isDeleted é marcado como True, essa alteração (marcado para exclusão, esse valor é conhecido como Tombstone Life Time) por padrão é de 60 dias para controladores de domíno 2000 e 2003 RTM e 180 dias para controladores de domínio 2003 com SP1, DC 2008 e 2008 R2, após este perído, o objeto é removido definitivamente através de um processo conhecido por Garbage Collection (Coleta de Lixo) .

O Garbage Collection desempenha duas funções vitais. Primeiro, ele limpa os objetos que foram marcados para exclusão e a segunda função é fazer a desfragmentação online da base de dados (NTDS.DIT). Por padrão, esse processo é executado a cada 12 horas em cada DC. No entanto, você pode alterar essa freqüência, modificando o atributo garbageCollPeriod no caminho CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, DC =sub_dominio,DC =dominio.

Para enterdermos vamos imaginar um ambiente com dois controladores de domínio, DC1 e DC2 que executam Windows Server 2003 SP1, isso significa que se um objeto for excluído ele ficará marcado para exclusão por 180 dias. Vamos supor que a replicação entre estes servidores deixou de funcionar por mais de 180 dias, então se hoje eu removo o usuário GilsonBanin do DC1 ele é marcado para exclusão e tenta replicar esta informação para o DC2 mas não consegue, passado 180 dias o Garbage Collection excluirá definitvamente este objeto da base e alguns dias depois o DC2 volta em operação e a replicação reestabelece ! Já deu para perceber o que vai ocorrer ? o objeto GilsonBanin ainda existe no DC2 mas não será replicado como alteração para o DC1 porque não há mais nenhuma referência e UPN ( Update Sequence Number ) deste objeto no DC1, então o DC2 acha que é um objeto novo e recria o usuário GilsonBanin no DC1 e ele renasce como a ave Fenix da Mitologia Grega que quando morria em auto-combustão e, passado algum tempo, renascia das próprias cinzas.

Se você tem um desses sintomas abaixo, saiba que você deve ter muitos objetos remanescentes na sua árvore de domínios do Active Directory :

    • Um usuário excluído ou conta de grupo permanece na lista de endereços global (GAL) em servidores Exchange. Portanto, embora o nome de conta aparece na GAL, tenta enviar e-mail mensagens resulta em erros.
  • Várias cópias de um objeto aparecem na lista de objetos ou GAL para um objeto que deve ser exclusivo na floresta. As vezes aparecem com nomes alterados, causando confusão em pesquisas de diretório. Por exemplo, se o nome distinto relativo de dois objetos não podem ser resolvidos, a resolução anexa conflito "* CNF: GUID" para o nome, onde * representa um caractere reservado, CNF é uma constante que indica a resolução de conflitos, e GUID representa o objectGUID atributo de valor.
  • Mensagens de correio eletronico não são entregues a um usuário cujo nomes parecem serem iguais. Depois de um controlador de domínio desatualizados ou servidor de catálogo global torna-se restabelecida, as duas instâncias do objeto de usuário aparecem no catálogo global. Como ambos os objetos têm o mesmo endereço de e-mail, mensagens de correio eletronico não pode ser entregue.
  • Um grupo universal que não existe mais continua a aparecer no token de acesso de um usuário. Embora o grupo não existe mais, se uma conta de usuário ainda tem o grupo em seu token de segurança, o usuário pode ter acesso a um recurso que pretendia estar indisponível para esse usuário (falha de segurança).
  • Um novo objeto ou caixa de correio do Exchange não pode ser criada, mas você não vê o objeto no Active Directory. Um erro de mensagem informa que o objeto já existe.
    Pesquisas que usam atributos de um objeto existente incorretamente encontrar várias cópias de um objeto com o mesmo nome. Um objeto foi excluído do domínio, mas ela permanece em um servidor de catálogo global isolado.
  • Se for feita uma tentativa de atualizar um objeto persistente que reside em uma partição de diretório gravável, os eventos são registrados no controlador de domínio de destino. No entanto, se a única versão de um objeto persistente existe em uma partição de diretório somente leitura em um servidor de catálogo global, o objeto não pode ser atualizado e esse tipo de evento não será disparado

A imagem abaixo mostra o resultado de uma pesquisa com objetos com conflitos que se iniciam com CNF (Conflict)

CNF

Isso ocorre principalmente quando os controladores de domínio ficam mais tempo sem replicar do que o TombStone Life Time (60 ou 180 dias). Os servidores Windows 2000 não tinham nenhum tipo de defesa e os objetos eram simplesmente ressuscitados, já no Windows Server 2003/2008/2008 R2 existe uma chave de registro que bloqueia a replicação para outros servidores e o event ID 1388 e 1988 surgirá.

  • Caminho : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
  • Chave: Strict Replication Consistency
  • Tipo / Valor : Dword 1

Você tem duas opções para eliminar essa inconsistência :

A) Despromover o controlador de domínio e promovê-lo novamente

B) Remover os objetos remanescentes através da ferramenta repadmin /removelingeringobjects

Se optar pela opção B) a sintaxe é a seguinte

C:\repadmin /removelingeringobjects <dest_dc_list> <source_dc_GUID> <NC> [/Advisory_Mode]

  • <des_dc_list> = controlador de domínio que contém os lingering objects
  • <source_dc_GUID> = GUID do controlador de domínio saudável ( para identificar basta executar o comando “C:\repadmin /showrepl dcname” como a figura abaixo, normalmente um bom candidato é o PDC emulator)

Lingering1

  • <NC> = é a partição que você quer pesquisar, os objetos mais comuns ficam na partição de domínio, um exemplo para o domíno CONTOSO.COM o <NC> ficaria DC=contoso,DC=com
  • /Advisory_Mode = Usado somente para listar os objetos mas não os exclui, para removê-los basta não informar esta opção

Um exemplo usando a imagem acima o DC saudável chama-se DC2003 e o GUID dele é ee96ccd0-9830-4a92-a13e-61fa9c3d17a4 e o DC2003LO (LO de Lingering Objects) é o DC com os objectos remanescentes siga as instruções abaixo :

OBS : Das 5 partições do AD somente a de Schema os lingerings não podem ficar alojados, então desconsidere o comando para a partição CN=Schema, DC=contoso,DC=com

Para identificar os lingering objects localizados na partição de domínio execute o seguinte comando :

C:\repadmin /removelingeringobjects dc2003lo ee96ccd0-9830-4a92-a13e-61fa9c3d17a4 dc=contoso,dc=com /advisory_mode

Para identificar os lingering objects localizados na partição de configuração execute o seguinte comando :

C:\repadmin /removelingeringobjects dc2003lo ee96ccd0-9830-4a92-a13e-61fa9c3d17a4 cn=configuration,dc=contoso,dc=com /advisory_mode

Para identificar os lingering objects localizados na partição de aplicação de dns de domínio execute o seguinte comando :

C:\repadmin /removelingeringobjects dc2003lo ee96ccd0-9830-4a92-a13e-61fa9c3d17a4 dc=domaindnszones,dc=contoso,dc=com /advisory_mode

Para identificar os lingering objects localizados na partição de aplicação de dns de floresta execute o seguinte comando :

C:\repadmin /removelingeringobjects dc2003lo ee96ccd0-9830-4a92-a13e-61fa9c3d17a4 nc=forestdnszones,dc=contoso,dc=com /advisory_mode

Após a execução vá até o Event View e localiza os eventos ID 1946 e ID 1942, eles mostrarão todos os objetos encontrados.

Agora para removê-los definitivamente execute o mesmo comando acima sem o parâmetro /Advisory_Mode. Quando o processo de exclusão for concluído procure pelos eventos IDs 1937, 1945 e 1939 eles mostrarão o total de objetos removidos. Aguarde o próximo ciclo de replicação e veja se através do comando REPADMIN /SHOWREPL se as partições estão replicando agora com sucesso.

Para maiores informações acesse o link https://technet.microsoft.com/en-us/library/cc780362(WS.10).aspx

Comments

  • Anonymous
    October 15, 2010
    Usar o BurFlags para recriar as informações num DC seria uma opção?

  • Anonymous
    October 15, 2010
    Artigo muito bom!! Gilson, só um detalhe....os objetos não são listados no arquivo de saída resultado.log, e sim no Event Viewer sob o ID 1946, o ID 1942 relata a conclusão da verificação. Os IDs 1937, 1945 e 1939 são listados quando executado o processo de exclusão. Deixo a dica para citar também o parâmetro dc_list.

  • Anonymous
    October 25, 2010
    Banin, otimo artigo sobre LO!!! Fica ai uma duvida postada pelo nosso grande amigo  Emilio, sempre usei o processo D2,D4 para problemas de replicaçao FRS, sysvol, Journal Wrapping, para casos de LO nao sei se seria valido, eu acho que não. Fica ai esta grande duvida para nosso amigo Banin responder se possivel. Abraços

  • Anonymous
    August 10, 2013
    Muito bom o Artigo, consegui resolver um problema de replicação mexendo na chave do registro que vc informou.

  • Anonymous
    February 03, 2016
    Obrigado Gilson, este post ajudou muito.