• Artigo

Administração do Windows

Recuperação de desastres: usuários e grupos do Active Directory

Gil Kirkpatrick

 

Visão geral:

  • Mecânica da replicação e vinculação de objeto
  • Usando o NTDSUTIL para backup e restauração
  • Restaurações autoritativas e não autoritativas

O Active Directory é um dos serviços mais importantes em uma rede do Windows. Para evitar o tempo de inatividade e a perda de produtividade, é fundamental que você tenha planos eficientes de recuperação de desastres em vigor para os problemas relacionados ao Active Directory. Isso pode parecer óbvio, mas é

impressionante como muitos administradores não têm um plano para um dos cenários de falha mais comuns do Active Directory®: a exclusão acidental de dados.

A exclusão acidental de objetos é uma das causas básicas mais comuns de falha do serviço. Quando sou palestrante em seminários e conferências, pergunto freqüentemente quem já teve uma falha do Active Directory devido à exclusão acidental de dados. E, sempre, quase todos levantam as mãos.

Para compreender por que a recuperação de dados é tão complexa, primeiro é necessário compreender o seguinte: como o Active Directory armazena e replica objetos, como ele exclui objetos e a mecânica das restaurações autoritativas e não autoritativas.

Armazenando objetos

O Active Directory é um banco de dados especializado em objetos, o qual implementa o modelo de dados X.500/LDAP. O armazenamento de dados (denominado árvore de informações de diretórios ou DIT [Directory Information Tree]) tem como base o ESE (Extensible Storage Engine, mecanismo de armazenamento extensível), um mecanismo de banco de dados ISAM (Indexed Sequential Access Method, método de acesso seqüencial indexado). Conceitualmente, o Active Directory armazena a DIT em duas tabelas: a tabela de dados (que contém os reais objetos e atributos do Active Directory) e a tabela de vínculo (que contém as relações entre os objetos).

Cada objeto do Active Directory é armazenado em uma linha separada na tabela de dados, com uma coluna por atributo. A tabela de dados contém todas as entradas para todas as réplicas armazenadas no DC (Domain Controller, controlador de domínio). Em um controlador de domínio normal, a tabela de dados contém entradas de um NC (naming context, contexto de nomenclatura) de domínio, da configuração e do esquema. Em um catálogo global, a tabela de dados contém entradas para cada objeto na floresta.

O Active Directory utiliza a marca de nome distinto (DNT, Distinguished Name Tag) – um inteiro de 32 bits – para identificar exclusivamente cada linha na tabela de dados. O DNT, utilizado para consultar objetos internamente, é muito menor do que outros identificadores, como o nome distinto (DN, Distinguished Name) e o GUID do objeto (uma estrutura binária de 16 bytes). Mas ao contrário do GUID do objeto, o DNT é um identificador local e é diferente em cada controlador de domínio.

Como o Active Directory vincula os objetos

O Active Directory gerencia dois tipos de relações entre os objetos na DIT: a relação pai-filho (também chamada de relação de recipiente) e a relação de referência (também chamada de relação de vínculo). Para implementar a relação pai-filho, o Active Directory armazena uma coluna adicional na tabela de dados denominada marca de nome distinto pai ou PDNT. Essa coluna sempre contém o DNT do pai do objeto.

Cada atributo do Active Directory é definido por um objeto attributeSchema no recipiente Schema do Active Directory. Certos atributos no Active Directory são definidos como atributos de vínculo, conforme determinado por um valor par e que não seja zero no atributo linkID do objeto attributeSchema. Os atributos de vínculo estabelecem uma relação entre os objetos no diretório e podem ter um valor único ou valores múltiplos. O atributo de membro de um objeto de grupo é um exemplo de um atributo de vínculo com valores múltiplos – ele estabelece um vínculo entre o objeto de grupo e seus objetos membro.

Mesmo que pareça que o atributo de membro de um grupo tenha os DNs dos membros (como exibido pelo snap-in de usuários e computadores do Active Directory, por exemplo), essa não é a forma como o Active Directory os armazena. Quando você adiciona o DN de um objeto membro a um atributo de membro de um grupo, o Active Directory armazena o DNT do objeto, não o seu DN. Como o DNT não é alterado, mesmo quando um objeto é renomeado, é possível renomear um objeto de usuário; além disso, o Active Directory não precisará classificar todos os grupos no sistema para atualizar o DN em cada um dos atributos de membro. É assim que o Active Directory mantém a integridade de referência no DIT. A Figura 1 mostra uma representação, embora muito simplificada, de como a tabela de dados e a tabela de vínculos se relacionam. Essas tabelas mostram que os três objetos de usuário – Molly Clark, Alexander Tumanov e Makoto Yamagishi – são todos membros do grupo de Engenheiros seniores.

Figure 1 Como os dados e as tabelas de vínculo estão relacionados

Tabela de dados      
DNT PDNT Classe de objeto Cn
14529 14401 organizationalUnit Engenheiros
14530 14529 Grupo Engenheiros seniores
14531 14529 Usuário Molly Clark
14532 14529 Usuário Alexander Tumanov
14533 14529 Usuário Makoto Yamagishi
Tabela de vínculos      
Atributo DNT Vínculo progressivo  
Membro 14530 14531  
Membro 14530 14532  
Membro 14530 14533  

Esses vínculos são denominados progressivos. Do mesmo modo, o Active Directory também fornece atributos de vínculo regressivo. Eles fornecem uma referência a partir do objeto vinculado de volta ao objeto a que se refere, representando o objeto com o vínculo progressivo. O atributo memberOf attribute para usuários e grupos é um exemplo de um atributo de vínculo regressivo. O objeto attribute-Schema que descreve um atributo de vínculo regressivo tem um valor linkID, o qual é maior que o valor linkID com número par do atributo de vínculo progressivo correspondente. Por exemplo, o atributo de membro no esquema do Windows Server® 2003 R2 tem um valor linkID de 2; o atributo memberOf que serve como vínculo regressivo tem um valor linkID de 3. Para obter mais informações, a Figura 2 fornece uma lista de atributos vinculados, definidos por padrão no esquema do Windows Server 2003 R2.

Figure 2 Atributos de vínculo no esquema do Windows Server 2003 R2

Atributo do vínculo progressivo linkID Atributo do vínculo regressivo Vinculado
membro 2 memberOf 3
gerente 42 directReports 43
proprietário 44 ownerBL 45
siteObject 46 siteObjectBL 47
nonSecurityMember 50 nonSecurityMemberBL 51
queryPolicyObject 68 queryPolicyBL 69
privilegeHolder 70 isPrivilegeHolder 71
managedBy 72 managedObjects 73
hasPartialReplicaNCs 74    
hasMasterNCs 76 masteredBy 77
syncMembership 78    
serverReference 94 serverReferenceBL 95
bridgeheadTransportList 98 bridgeheadServerListBL 99
netbootServer 100 netbootSCPBL 101
frsComputerReference 102 frsComputerReferenceBL 103
fRSMemberReference 104 fRSMemberReferenceBL 105
fRSPrimaryMember 106    
siteLinkList 142    
siteList 144    
msCOM-PartitionLink 1040 msCOM-PartitionSetLink 1041
msDS-NC-Replica-Locations 1044    
msFRS-Hub-Member 1046    
msCOM-UserPartitionSetLink 1048 msCOM-UserLink 1049
msDS-SDReferenceDomain 2000    
msDS-HasInstantiatedNCs 2002    
msDS-NonMembers 2014 msDS-NonMembersBL 2015
msDS-MembersForAzRole 2016 msDS-MembersForAzRoleBL 2017
msDS-OperationsForAzTask 2018 msDS-OperationsForAzTaskBL 2019
msDS-TasksForAzTask 2020 msDS-TasksForAzTaskBL 2021
msDS-OperationsForAzRole 2022 msDS-OperationsForAzRoleBL 2023
msDS-TasksForAzRole 2024 msDS-TasksForAzRoleBL 2025
msDS-HasDomainNCs 2026    
msSFU30PosixMember 2030 msSFU30PosixMemberOf 2031
msDS-hasMasterNCs 2036 msDs-masteredBy 2037
msDS-ObjectReference 2038 msDS-ObjectReferenceBL 2039
msDFSR-ComputerReference 2050 msDFSR-ComputerReferenceBL 2051
msDFSR-MemberReference 2052 msDFSR-MemberReferenceBL 2053

Os atributos de vínculo regressivo são sempre de valores múltiplos e são mantidos automaticamente pelo Active Directory. Na verdade, não é possível modificar diretamente um atributo de vínculo regressivo. Mesmo que pareça possível modificar o atributo memberOf de um usuário ou grupo usando o snap-in do MMC de usuários e computadores do Active Directory, na verdade o snap-in está modificando o atributo de membro do grupo correspondente, e o Active Directory atualiza o atributo memberOf em segundo plano. É por esse motivo que não são necessárias permissões no objeto de usuário para adicionar o usuário a um grupo; você só estará realmente modificando o atributo de membro do objeto de grupo. Como cada controlador de domínio gerencia seus atributos de vínculo regressivo localmente, as alterações aos vínculos regressivos nunca são replicadas. Somente a alteração ao atributo de vínculo progressivo, como o atributo de membro de um grupo, é replicada.

Em um controlador de domínio normal, a tabela de dados contém entradas de objetos de domínio, bem como de objetos dos recipientes Configuration e Schema. Mas alguns tipos de grupo podem ter referências a objetos que residem em outro domínio. Como o Active Directory armazena um DNT de um objeto que não está na tabela de dados? A resposta depende do proprietário de função de FSMO (Flexible Single Master Operations, operação flutuante de mestre único) de mestre de infra-estrutura e de algo chamado de objeto fantasma.

Objetos fantasma

Quando você adiciona um membro de um domínio a um grupo em outro domínio, o Active Directory cria automaticamente um objeto especial na tabela de dados denominado fantasma, o qual contém o objectGUID, objectSid e DN do novo membro. Isso fornece um DNT que pode ser armazenado no atributo de membro do grupo. Se um controlador de domínio for um catálogo global, ele não precisará criar um fantasma, pois já tem uma entrada em sua tabela de dados para cada objeto na floresta.

O controlador de domínio que detém a função de FSMO de infra-estrutura verifica periodicamente as entradas na sua tabela de dados em comparação a um catálogo global; quando ele detecta que um objeto foi transferido, renomeado ou excluído, ele atualiza os fantasmas na tabela de dados e replica a alteração para os outros DCs no domínio. E devido a uma contagem de referência, o mestre de infra-estrutura também pode remover fantasmas que não são mais mencionados por qualquer atributo de vínculo progressivo no domínio.

Os fantasmas permitem que os DCs gerenciem referências a objetos em outros domínios na floresta; porém, os atributos de vínculo progressivo também podem fazer referência a objetos externos à floresta – por exemplo, em um domínio confiável. Nesse caso, o Active Directory cria um objeto denominado FSP (Foreign Security Principal, entidade de segurança estrangeira) no recipiente CN=ForeignSecurityPrincipals no NC de domínio. A FSP contém o SID (Security Identifier, identificador de segurança) do objeto e outros atributos que identificam o objeto no domínio estrangeiro, mas não há um processo para garantir que a FSP se mantenha atualizada. Para fins de recuperação de dados, tratamos as FSPs como faríamos com qualquer outro objeto do Active Directory.

Excluindo objetos

Nesta seção, meu foco principal será a restauração de usuários e de suas associações de grupo. No entanto, os mesmos princípios se aplicam à recuperação de outros atributos vinculados.

Quando o Active Directory exclui um objeto, ele não o exclui fisicamente da DIT. Em vez disso, ele marca o objeto como excluído, definindo o seu atributo isDeleted como true (verdadeiro), o que resulta no processamento “invisível” do objeto nas operações normais do diretório. O Active Directory remove todos os atributos que não devam ser salvos, como definido pelo esquema, e altera o RDN (Relative Distinguished Name, nome distinto relativo) do objeto para <old RDN>\0aDEL:<objectGUID>. Em seguida, ele move o objeto para o recipiente CN=Deleted Objects do NC. (Há algumas classes de objetos no NC Configuration que o Active Directory não move para o recipiente Deleted Objects.) O Active Directory remove todos os vínculos progressivos a outros objetos que o objeto excluído detenha – o que reduz a sua contagem de referência na tabela de vínculo. Se houver outros objetos que tenham os vínculos progressivos para o objeto agora excluído, o Active Directory também removerá esses vínculos.

O objeto resultante é denominado marca para exclusão. O Active Directory replica essa marca para exclusão para outros DCs, nos quais as mesmas alterações tenham sido feitas. Observe que o Active Directory não replica as alterações feitas nos vínculos progressivos que se refiram ao objeto excluído. Cada controlador de domínio efetua localmente a alteração equivalente; portanto, não há necessidade de replicá-la. Isso apresenta conseqüências para a recuperação de associações de grupo, como abordarei posteriormente no artigo.

O Active Directory mantém objetos marcados para exclusão na DIT, como determinado pelo atributo tombstoneLifetime do objeto CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<root domain>. O processo de coleta de lixo em cada controlador de domínio remove as marcas de exclusão que forem mais antigas do que a vida útil configurada da marca de exclusão. Por padrão, a vida útil da marca de exclusão é de 60 dias para o Windows® 2000, o Windows Server 2003 e o Windows Server 2003 R2. Para o Windows Server 2003 SP1, a vida útil é de 180 dias.

A vida útil da marca de exclusão tem um importante significado no processo de restauração. Não é possível restaurar de um backup que seja mais antigo do que a vida útil da marca de exclusão. Como os objetos que foram excluídos e, em seguida, passaram pela coleta de lixo do domínio não têm mais marcas de exclusão, a operação de exclusão nunca replicará novamente para o controlador de domínio restaurado. Então, os objetos excluídos permanecerão no controlador de domínio restaurado como objetos remanescentes; o controlador de domínio restaurado nunca convergirá adequadamente com os outros DCs no domínio.

Replicando objetos

Sempre que um controlador de domínio executar uma operação de atualização de qualquer tipo – por exemplo, acrescentar um objeto ou modificar um atributo – o controlador de domínio atribui um número exclusivo de 64 bits para a operação de atualização denominado USN (Update Sequence Number, número de atualização de seqüência). O Active Directory marca os objetos e atributos que são atualizados com o USN, a fim de ajudar a determinar se eles precisam ser replicados.

O Active Directory replica objetos por atributo. Ou seja, se você modificar um atributo de um objeto, o Active Directory replicará somente esse atributo, não todo o objeto. Para fazer isso, o Active Directory controla as alterações feitas por ele em cada atributo com metadados de replicação. Os metadados de replicação de um atributo incluem:

  • O USN local, que identifica a operação de alteração no controlador de domínio local.
  • O invocationID do controlador de domínio que originou a alteração (especificamente, o atributo invocationID do objeto nTDSSettings correspondente do controlador de domínio), o que identifica uma geração específica da DIT em um controlador de domínio.
  • O USN da operação original da mesma forma que ele existe no controlador de domínio de origem.
  • Um carimbo de data/hora que contém o horário do sistema do controlador de domínio de quando a alteração de origem foi realizada.
  • Um número de versão seqüencial de 32 bits, o qual será incrementado sempre que o valor for alterado.

Quando um controlador de domínio de destino solicita alterações de seu parceiro de controlador de domínio de origem, ele envia o USN da última alteração replicada com êxito para o controlador de domínio de origem, juntamente com um vetor de atualização, o qual inclui o maior USN de origem visualizado pelo controlador de domínio de destino, a partir de cada controlador de domínio com uma réplica do NC sendo replicado. O controlador de domínio de origem utiliza essa informação, a fim de enviar somente as atualizações que o controlador de domínio de destino ainda não tenha visualizado.

À medida que o controlador de domínio de destino processar as atualizações do atributo de entrada, ele verifica o número de versão de cada atributo. Se o número de versão de um atributo de entrada for maior que a versão que o controlador de domínio já tem para esse atributo, o controlador de domínio armazenará o valor de entrada. Se o número de versão de entrada for igual à versão que o controlador de domínio já tem, o controlador de domínio comparará os carimbos de data/hora e utilizará o atributo com o carimbo de data/hora mais recente. Se os carimbos de data/hora forem os mesmos, o controlador de domínio de destino escolherá o valor com o maior invocationID. Isso garante que cada controlador de domínio eventualmente definirá o mesmo valor para cada atributo replicado.

Replicação de valor vinculado

No Windows 2000, o Active Directory replicava atributos com valores múltiplos da mesma maneira que com os atributos de valor único. Isso causou problemas para grandes objetos de grupo dinâmico, cujo atributo de membro com valores múltiplos poderia ser alterado com freqüência em diferentes controladores de domínio. Se um administrador acrescentasse um usuário a um grupo em um controlador de domínio, e outro administrador acrescentasse um usuário diferente ao grupo em outro controlador de domínio na janela de latência de replicação, o Active Directory escolheria a última adição e perderia completamente a adição anterior. A Microsoft solucionou esse problema no Windows Server 2003 com um processo denominado LVR (Linked Value Replication, replicação de valor vinculado).

Com o nível funcional de floresta ou nível funcional de floresta provisório do Windows Server 2003, o Active Directory replica separadamente os valores individuais de atributos de vínculo progressivo com valores múltiplos, com cada valor tendo seus próprios metadados de replicação. Isso soluciona efetivamente o problema detectado no Windows 2000, no qual a maior parte das atualizações simultâneas de associação de grupo em controladores de domínios diferentes poderia causar a perda dos dados.

No entanto, há um ponto a ser considerado. A elevação do nível funcional de floresta não corrige atualmente os atributos de vínculo com valores múltiplos com os novos metadados de replicação. Somente os valores adicionados depois da elevação do nível funcional de floresta terão os novos metadados. Isso terá um efeito significativo na recuperação de associações de grupo, como você verá a seguir.

Efetuando backup

O Windows inclui o utilitário muito básico NTBACKUP, o qual pode ser utilizado para executar um backup de estado do sistema de um controlador de domínio. O estado de sistema de um controlador de domínio inclui o seu Registro, SYSVOL, arquivos de DIT do Active Directory e arquivos fundamentais do sistema. A maioria dos utilitários de backup de terceiros também tem o recurso de backup e restauração do estado do sistema de um controlador de domínio.

Para executar um backup do estado do sistema para um arquivo de disco, utilize o seguinte comando:

NTBACKUP backup systemstate /F “<filename>”

Nesse caso, <filename> é o nome do arquivo de backup a ser criado e deve utilizar a extensão .bkf.

Executando uma restauração não autoritativa

A restauração de objetos excluídos do Active Directory a partir do backup é um processo de duas etapas. Primeiramente, reinicialize o controlador de domínio no DSRM (Directory Services Restore Mode, modo de restauração dos serviços de diretório); em seguida, restaure toda a DIT do Active Directory a partir do backup do estado do sistema usando o utilitário NTBACKUP do Windows ou um produto equivalente de terceiros. Esse processo substituirá toda a DIT.

Há duas formas de inicializar um controlador de domínio no DSRM. Se você tiver acesso ao console do sistema do controlador de domínio, desligue e reinicie o controlador de domínio e pressione F8 quando solicitado, a fim de ativar o menu de inicialização do Windows. No menu, selecione Restauração dos Serviços de Diretório e digite a senha do DSRM.

Se você estiver gerenciando o servidor remotamente, você não poderá acessar o menu de inicialização do Windows. Em vez disso, você pode alterar as opções de inicialização do sistema selecionando Propriedades em Meu Computador, clicando na guia Avançado e pressionando o botão Configurações, localizado em Inicialização e recuperação. Pressione o botão Editar na seção Inicialização do sistema para editar o arquivo boot.ini e acrescente a opção /SAFEBOOT:DSREPAIR ao final da linha, como mostrado na Figura 3. (Para obter mais informações sobre as opções do boot.ini, consulte microsoft.com/technet/ sysinternals/information/bootini.mspx.)

Figura 3 Definindo as opções de inicialização para o DSRM

Figura 3** Definindo as opções de inicialização para o DSRM **(Clique na imagem para aumentar a exibição)

Quando você reinicializar o servidor, ele será reinicializado no DSRM. Lembre-se de que, quando reinicializar o controlador de domínio no modo normal, será necessário remover a opção /SAFEBOOT do boot.ini.

Assim que você tiver efetuado logon usando a senha do DSRM, restaure o backup do estado de sistema usando novamente o comando NTBACKUP, mas sem especificar quaisquer parâmetros. (Não é possível executar uma restauração usando o NTBACKUP a partir da linha de comando.) Quando o assistente for iniciado, selecione Restaurar arquivos e configurações e clique em Avançar. Em seguida, selecione o arquivo de backup e marque a caixa Estado do Sistema, como mostrado na Figura 4.

Figura 4 Usando o Assistente de backup ou restauração para restaurar o estado do sistema

Figura 4** Usando o Assistente de backup ou restauração para restaurar o estado do sistema **(Clique na imagem para aumentar a exibição)

Nesse caso, se você reinicializasse o controlador de domínio de volta no modo normal, o processo de replicação do Active Directory ativaria o controlador de domínio restaurado novamente para a sincronização com os outros controladores de domínio no domínio, e todos os dados restaurados seriam substituídos pelos dados atuais. Sem dúvida, esse não é o seu objetivo. Em vez disso, você precisa de um modo para forçar os objetos sendo restaurados a se replicarem em outros controles de domínio no domínio.

Executando uma restauração autoritativa

O NTDSUTIL também aumenta em 100.000 o número de versão de cada atributo para cada dia entre a data do backup e a data da restauração. A menos que haja mais atributos sendo atualizados mais de 100.000 vezes por dia (um cenário muito improvável), o número de versão dos atributos restaurados será muito maior que os números de versão mantidos por outros controladores de domínio; além disso, o objeto restaurado de modo autoritativo se replicará para outros controladores de domínio. Os outros objetos que foram restaurados de forma não autoritativa a partir do backup serão, por fim, substituídos pelos dados existentes a partir de outros controladores de domínio.

Depois de concluir a restauração não autoritativa, mas antes de reinicializar em modo normal, use o programa NTDSUTIL para executar uma restauração autoritativa dos objetos que deseja recuperar. Apesar do nome, a restauração de modo autoritativo de um objeto não o “restaura”; ela simplesmente garante que o Active Directory replicará o objeto em outros controladores de domínio. Para fazer isso, o NTDSUTIL atribui a próxima variável USN ao USN local dos atributos do objeto. Isso faz com que o objeto seja enviado para parceiros de replicação na próxima vez que eles efetuarem a sincronização. Para restaurar um único objeto, certifique-se de que o controlador de domínio seja inicializado no DSRM e siga estas etapas:

  1. Abra uma janela de comando e digite:
ntdsutil
  1. No prompt ntdsutil, digite:
authoritative restore
  1. No prompt de restauração autoritativa, digite:
restore object “<DN of object to be restored>”
  1. Por exemplo, se você quiser restaurar a conta de Molly Clark a partir da unidade organizacional de engenharia no domínio DRNET, você deveria digitar:
restore object “CN=Molly Clark,OU=Eng,DC=DRNET,DC=com”
  1. Se quiser restaurar de modo autoritativo toda a subárvore do diretório (por exemplo, uma unidade organizacional), então você deveria digitar:
restore subtree “OU=Eng,DC=DRNET,DC=com”
  1. (O NTDSUTIL também fornece um comando de restauração de banco de dados, o qual restaura de modo autoritativo todo o domínio, bem como os NCs de configuração e esquema.) A restauração de todo o domínio é muito perigosa; portanto, não recomendo o uso dessa opção. Se você precisar restaurar um domínio completo, restaure um controlador de domínio e promova novamente os outros controladores de domínio no domínio, como descrito em “Planejando a recuperação de floresta do Active Directory”,
  2. Quando solicitado, confirme se a restauração autoritativa deve aumentar os números de versão dos respectivos objetos e seus atributos.
  3. Saia do ntdsutil (você não precisará digitar “quit” duas vezes).
  4. Reinicialize o controlador de domínio no modo normal do Active Directory.

Na próxima vez que o controlador de domínio se replicar com seus parceiros, o usuário restaurado será replicado. No entanto, a restauração do objeto de usuário é somente uma parte do problema. Quando você introduz vínculos de objeto como aqueles entre um grupo e seus membros, a situação é mais complicada. Há alguns problemas fundamentais a serem enfrentados durante e depois da restauração, os quais descreverei nas próximas seções.

Primeiramente, vamos rever o que acontece quando você exclui um objeto com vínculos regressivos. Digamos que você exclua um objeto de usuário que seja um membro de um ou mais grupos. Cada controlador de domínio que tiver uma cópia do objeto de usuário o converterá para uma marca de exclusão, bem como removerá quaisquer referências da tabela de vínculos; portanto, o objeto de usuário será removido de quaisquer associações de grupo no domínio do usuário. (Lembre-se de que remover o usuário das associações de grupo não é uma alteração replicada, pois cada controlador de domínio atualiza a associação de grupo localmente. O número de versão e o USN local do atributo de membro do grupo permanecem inalterados.) Pouco tempo depois, os objetos fantasma serão removidos das tabelas de vínculo em outros domínios, sem atualizar os metadados de replicação do atributo de membro do grupo.

Quando você restaurar de forma não autoritativa a DIT em um controlador de domínio no domínio do usuário, você pode recuperar o objeto de usuário junto com todas as outras associações de grupo no domínio, de forma que o controlador de domínio restaurado seja autoconsistente. E depois que você usar o utilitário NTDSUTIL para restaurar de forma autoritativa o usuário, o objeto de usuário será replicado em todos os outros controladores de domínio no domínio.

Porém, como os metadados de replicação dos grupos atuais no domínio estão inalterados, os atributos de membro dos grupos no controlador de domínio restaurados são inconsistentes com aqueles nos outros controladores de domínio. Além disso, não há nada a ser feito para a convergência deles em um estado comum. Dessa forma, as associações de usuário não serão restauradas nos outros controladores de domínio no domínio.

O problema: as associações de grupo no domínio não são restauradas

A restauração de forma autoritativa do objeto de usuário não recupera as associações de grupo de usuário. Por que não? Como a relação de associação é armazenada e replicada usando o atributo de membro dos objetos de grupo (os vínculos progressivos), não o atributo memberOf do usuário (o vínculo regressivo). O problema é como localizar as associações do grupo anterior de usuário e, assim que souber quais são, como recuperá-las corretamente.

A Microsoft efetuou aprimoramentos graduais no processo de recuperação de associações de um grupo de usuário, de forma que a técnica utilizada depende da versão do Active Directory que você estiver executando. A seção a seguir aplica-se principalmente ao Active Directory do Windows 2000.

É muito fácil determinar as associações de grupo anterior do usuário: basta inspecionar o atributo de vínculo regressivo no controlador de domínio restaurado – nesse caso, o atributo memberOf do objeto de usuário. O atributo memberOf terá todas as associações a grupos locais e globais no domínio de usuário. Você pode usar o snap-in do MMC de usuários e computadores do Active Directory (ADUC, Active Directory Users and Computers) ou usar o utilitário LDIFDE, o qual está incluído no Windows Server, a fim de obter uma lista das associações de grupo de usuário.

A linha de comando do LDIFDE a seguir apresentará uma lista dos grupos no domínio DRNET ao qual Molly Clark pertence como membro, armazenando os resultados no arquivo output.ldf:

C:\> ldifde –r “(distinguishedName=CN=Molly Clark,
OU=Engineering,DC=DRNET,DC=Local)” –l memberOf –p Base –f output.ldf

Observe que você deve reinicializar o controlador de domínio no modo normal, a fim de usar quaisquer ferramentas LDAP e, novamente, deve desabilitar a replicação de entrada; caso contrário, os dados restaurados serão substituídos. A forma mais fácil de desabilitar a replicação de entrada é usar o comando REPADMIN:

REPADMIN /options <dcname>+DISABLE_INBOUND_REPL

Aqui, <dcname> é o nome do controlador de domínio para o qual você está restaurando. Além disso, quando tiver concluído, não se esqueça de habilitar novamente a replicação utilizando –DISABLE_INBOUND_REPL.

Se você estiver recuperando apenas alguns usuários, é muito fácil adicionar manualmente o usuário de volta aos grupos usando o ADUC. Se você estiver recuperando um número maior de usuários, existem algumas ferramentas que podem automatizar parte do processo. O utilitário GROUPADD da Microsoft (disponível a partir do Atendimento Microsoft) pode aceitar o arquivo LDIF que você criou, a fim de obter uma lista das associações de grupo anterior de usuário e, por sua vez, gerar um arquivo LDIF, o qual recria essas associações. Por exemplo, você utilizaria esse comando GROUPADD para processar o arquivo LDIF que criamos no exemplo anterior para Molly Clark:

C:\> groupadd /after_restore output.ldf

Esse comando criará um novo arquivo LDIF para cada domínio no qual Molly Clark tiver associações de grupo com o nome groupadd_<domain>.ldf (onde <domain> é o nome de domínio totalmente qualificado cujos grupos serão atualizados). Você importaria o arquivo LDIF criado acima com o comando a seguir:

C:\> ldifde –i –k –f groupadd_child.drnet.net.ldf

Com o Windows Server 2003, a Microsoft aprimorou o NTDSUTIL para aproveitar os metadados adicionais presentes no atributo de membro, a fim de oferecer suporte à replicação de LVR (Linked Value Replication, replicação de valor vinculado). Se o objeto de usuário restaurado tiver sido um membro de qualquer grupo no domínio e a associação de grupo de usuário tiver sido armazenada nos metadados da LVR, o NTDSUTIL aumentará o número de versão do valor correspondente do atributo de membro, o que então faz com que a associação restaurada se replique.

A versão do Windows Server 2003 SP1 do NTDSUTIL incorpora as funções GROUPADD e criará automaticamente arquivos LDIF, à medida que ele executar a restauração autoritativa do objeto de usuário. A Figura 5 mostra a nova versão do NTDSUTIL; a Figura 6 exibe o conteúdo do arquivo LDIF criado automaticamente.

Figure 6 Conteúdo do arquivo LDIF criado pelo NTDSUTIL

dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-

Figura 5 Novo NTDSUTIL com recursos GROUPADD internos

Figura 5** Novo NTDSUTIL com recursos GROUPADD internos **(Clique na imagem para aumentar a exibição)

Se você estiver restaurando uma unidade organizacional completa que tenha vários usuários e grupos, o acréscimo manual de usuários de volta para os seus grupos será um tanto tedioso. Outra forma de recuperar as associações de grupo restauradas é restaurar de forma autoritativa os próprios grupos.

Entretanto, há dois problemas com a restauração de forma autoritativa de grupos. O primeiro problema é razoavelmente óbvio: se você restaurar um grupo, a associação nesse grupo reverterá para o seu estado durante o backup. Isso significa que quaisquer alterações que você tiver feito no grupo desde o último backup precisarão ser aplicadas novamente no grupo. O segundo problema é um pouco mais sutil e tem a ver com a forma como a replicação funciona no Active Directory. Depois de uma restauração autoritativa de usuários e grupos, não há garantia sobre qual ordem eles serão replicados. Se um objeto de grupo se replicar para um controlador de domínio antes do objeto de usuário, o controlador de domínio da replicação removerá automaticamente a referência de usuário do grupo, pois o objeto de usuário ainda não existe nesse controlador de domínio. Quando o objeto de usuário for replicado posteriormente, ele não será adicionado ao grupo.

A solução mais fácil para esse problema é executar uma segunda vez a restauração autoritativa dos grupos. Depois de executar a primeira restauração autoritativa, reinicialize em modo normal e certifique-se de que a replicação seja realizada corretamente. Em seguida, reinicialize novamente no DSRM e execute o NTDSUTIL, a fim de realizar uma restauração autoritativa dos grupos nos quais o usuário era um membro. Isso garante que, quando você inicializar novamente no modo normal, o objeto de usuário será replicado antes que os objetos de grupo fazendo referência a ele se repliquem.

O problema: as associações de grupo em outros domínios não são restauradas

O problema “a quais grupos esse usuário pertencia como membro” é de fato mais difícil do que eu descrevi. O usuário que você estiver restaurando pode ter sido um membro dos grupos de domínio local e universais em outros domínios; essas associações de grupo não serão restauradas quando você efetuar a restauração não autoritativa. Portanto, como você sabe a quais grupos o usuário pertencia em outros domínios? A resposta está no catálogo global. Junto com seus próprios dados do domínio, o catálogo global contém uma cópia somente leitura dos dados de outros domínios na floresta.

Para aproveitar os dados abrangendo toda a floresta do catálogo global, você deve executar a restauração não autoritativa em um catálogo global, o que significa que você já deve ter feito backup de um catálogo global com o qual começará. Agora, quando você executar o LDIFDE para identificar as associações de grupo de usuário, você pode localizar as associações de grupo universal de outros domínios.

Quando você relacionar a lista das associações de grupo de usuário que está recuperando, conecte a porta 3268 do catálogo global em vez da porta 389 padrão e especifique o domínio-raiz da floresta como a base da pesquisa. O LDIFDE exibirá as associações de grupo de usuário recuperadas, inclusive a associação nos grupos universais em todos os domínios na floresta. Veja como fazer isso:

C:\> ldifde –r “(distinguishedName=CN=Don Clark,
OU=Engineering,DC=DRNET,DC=Local)” -t 3268 –l memberOf –p Base –f output.ldf

Se você executar o GROUPADD ou o novo NTDSUTIL em um catálogo global, você produzirá um arquivo LDIF para cada domínio no qual o usuário restaurado era membro de um grupo universal. Quando você importar esses arquivos LDIF, você irá restaurar todas as associações de grupo do usuário. Bem, quase tudo – o que nos apresenta o próximo problema.

O problema: recuperar associações de grupo local de domínio em outros domínios

Há três tipos de grupos em um ambiente do Active Directory do Windows. Os grupos globais podem conter somente membros no mesmo domínio, mas podem ser usados como membro em grupos locais de domínio em seu próprio domínio e em outros domínios na floresta. O atributo de membro dos grupos globais não aparece no catálogo global, mas não é um problema, pois os grupos globais contêm somente membros de seu próprio domínio. Os grupos universais podem conter membros de qualquer domínio e podem ser usados como membros em outros grupos universais na floresta, bem como em grupos locais de domínio em seu próprio domínio e em outros domínios na floresta. O atributo de membro de grupos universais é replicado em catálogos globais. Os grupos locais de domínio podem conter membros de qualquer domínio na floresta, mas não podem ser usados como membros em grupos em outros domínios. Mais importante, o atributo de membro dos grupos globais de domínio, como o dos grupos globais, não aparece no catálogo global. O resultado é que não há uma forma mais fácil de recuperar a associação de usuário nos grupos locais de domínio em outros domínios.

Antes do Windows Server 2003 SP1, a única forma de recuperar as associações de grupo local de domínio em domínios estranhos era restaurar um controlador de domínio em cada domínio, procurando manualmente os dados de domínio de quaisquer grupos locais de domínio que tivessem o usuário restaurado e, em seguida, adicionar o usuário de volta aos grupos identificados. Em um amplo ambiente com muitos domínios, essa abordagem é extremamente demorada.

A versão do Windows Server 2003 SP1 do NTDSUTIL pode auxiliar. Quando você executar o NTDSUTIL em um controlador de domínio, o utilitário cria um arquivo de texto que contém o DN e o GUID dos objetos de usuário restaurados. Dessa forma, para cada domínio estrangeiro, agora você pode restaurar de forma não autoritativa um único controlador de domínio, copiar o arquivo de texto no controlador de domínio e executar o NTDSUTIL, a fim de gerar um novo arquivo LDIF específico de domínio, o qual adiciona o usuário recuperado de volta nos grupos locais de domínio do qual ele era membro.

Para fazer isso, execute as etapas a seguir em um controlador de domínio em cada domínio estrangeiro:

  1. Inicialize o controlador de domínio no domínio estrangeiro no DSRM.
  2. Use o NTBACKUP para restaurar uma cópia da DIT, a qual contém as associações de grupo de usuário restauradas.
  3. Copie o arquivo .txt criado pelo NTDSUTIL no atual controlador de domínio.
  4. Abra uma janela de comando e digite “ntdsutil”.
  5. Digite “authoritative restore”.
  6. Digite “create LDIF file(s) from <file name>” (onde <file name> é o nome do arquivo de texto).
  7. Digite “quit” duas vezes para sair do ntdsutil.
  8. Reinicialize o controlador de domínio no modo normal do Active Directory.
  9. Digite “ldifde –i –f <ldif filename>” (onde <ldif filename> é o nome do arquivo LDIF que você acabou de criar).

Agora você restaurou todas as associações de grupo de usuário excluídas.

Passo a passo

A recuperação de usuários e suas associações de grupo do Active Directory, especialmente em um ambiente com vários domínios, é complicada. As etapas específicas necessárias para recuperar adequadamente as associações de grupo dependem da versão do Windows que você está executando.

Se você estiver executando o Windows 2003 SP1, você executaria as seguintes etapas:

  1. Inicialize um catálogo global no DSRM e execute uma restauração do estado do sistema usando um backup que contenha o usuário excluído.
  2. Use o NTDSUTIL para executar uma restauração autoritativa do usuário excluído. O NTDSUTIL criará um arquivo de texto contendo os DNs e GUIDs do objeto restaurado, bem como um ou mais arquivos LDIF para restaurar as associações de grupo de usuário.
  3. Use LDIFDE –i –f <LDIF filename> (onde <LDIF filename> é o nome dos arquivos LDIF criados na etapa 2) para importar as associações de grupo no domínio atual e em outros domínios.
  4. Reinicialize o catálogo global no modo normal.
  5. Em um controlador de domínio em cada domínio estrangeiro, inicialize no DSRM e execute uma restauração do estado do sistema usando um backup que contenha as associações de grupo do usuário restaurado.
  6. Execute o NTDSUTIL usando o comando “create ldif files”.
  7. Reinicialize o controlador de domínio no modo normal.
  8. Usando LDIFDE –i –f <filename> (onde <filename> é o nome do arquivo LDIF criado na etapa 6) para restaurar as associações de grupo no domínio estrangeiro.
  9. Nesse momento, você pode, opcionalmente, forçar a replicação com REPADMIN /syncall.

Se você estiver executando uma versão do Windows Server 2003 sem o SP1 instalado ou se estiver executando o Windows 2000, há algumas etapas adicionais envolvidas. Como a versão anterior do NTDSUTIL não cria arquivos LDIF, use o utilitário GROUPADD para criá-los. O processo é:

  1. Inicialize um catálogo global no DSRM e execute uma restauração do estado do sistema usando um backup que contenha o usuário excluído.
  2. Desabilite a placa de interface de rede ou desconecte o cabo para impedir a replicação de entrada.
  3. Reinicialize o catálogo global no modo normal.
  4. Use LDIFDE –r "(distinguishedName=<dn>)" -t 3268 -l memberOf –p Base -f membership.ldf para despejar a associação do usuário com o nome distinto <dn>.
  5. Use GROUPADD /after_restore membership.ldf para criar arquivos LDIF.
  6. Use LDIFDE –i –f <filename> (onde <LDIF filename> é o nome do arquivo LDIF criado pelo GROUPADD na etapa 5) para importar as associações de grupo no domínio atual e em outros domínios.
  7. Habilite novamente a replicação de entrada usando as REPADMIN /options <dcname> -DISABLE_INBOUND_REPL.
  8. Em um controlador de domínio em cada domínio estrangeiro, inicialize no DSRM e execute uma restauração do estado do sistema usando um backup que contenha as associações de grupo do usuário restaurado.
  9. Reinicialize o controlador de domínio no modo normal.
  10. Usando LDIFDE –i –f <filename> (onde <filename> é o nome do arquivo LDIF criado pelo GROUPADD na etapa 5) para restaurar as associações de grupo no domínio estrangeiro.
  11. Nesse momento, você pode, opcionalmente, forçar a replicação com REPADMIN /syncall.

A única coisa que falta agora para o ambiente anterior ao Windows Server 2003 SP1 é recuperar as associações de grupo local de domínio estranho do usuário restaurado. As suas únicas opções são: restaurar manualmente as associações de grupo local de domínio; ou restaurar um controlador de domínio do backup e restaurar de forma autoritativa os grupos locais de domínio.

Resumo

Apesar de ser relativamente fácil excluir acidentalmente usuários ou até mesmo unidades organizacionais do Active Directory, a recuperação adequada de usuários excluídos e suas associações de grupo pode ser surpreendentemente complexa, demorada e propensa a erro. Para garantir que seja possível recuperar a partir desses tipos de desastres o mais rápido possível, é necessário compreender a mecânica do vínculo de objetos, da replicação, da exclusão e das restaurações autoritativas.

Você acha que consegue realizar todas as etapas no seu ambiente de produção na primeira tentativa? Para certificar-se de que você esteja pronto na próxima vez em que precisar recuperar o objeto de usuário do presidente, tenha um plano por escrito preparado para a recuperação de objetos excluídos. Além disso, certifique-se pôr o plano em prática pelo menos uma ou duas vezes antes de tentar executá-lo em dados reais. O seu chefe (e o seu presidente) agradecerá!

Recursos adicionais

Gil Kirkpatrick é Diretor de tecnologia da NetPro e trabalha com o desenvolvimento de software para o Active Directory desde 1996. Juntamente com Guido Grillenmeier, da HP, ele apresenta os conhecidos workshops sobre Recuperação de desastres do Active Directory. Gil também é fundador da Directory Experts Conference (Conferência de especialistas do Active Directory) (www.dec2007.com).

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..