Windows Server

Reanimação de Objetos de Exclusões do Active Directory

Gil Kirkpatrick

Visão geral:

• Como os objetos excluídos são armazenados no Active Directory
• Uso de LDP e ADRESTORE para localizar e restaurar marcas para exclusão
• Atributos de objeto e systemFlags

Embora este talvez não seja o seu assunto favorito, a perda acidental de dados acontece e, como profissional de TI, você deve estar preparado para todos os cenários de recuperação. Na edição de abril de 2007 da TechNet Magazine, analisei a importância de se ter um plano em

vigor para a recuperação de usuários e grupos do Active Directory®. Nesse artigo, disponível em technetmagazine.com/issues/2007/04/ADRecovery, abordei as mecânicas de vinculação de objeto, de replicação, de exclusão e de restauração autoritativa. Infelizmente, a função de restauração autoritativa exige que você inicie um DC (controlador de domínio) no DSRM (Directory Service Restore Mode). Isso torna o DC indisponível durante a operação de restauração.

Há uma outra abordagem que você deve conhecer. A reanimação de marcas para exclusão proporciona a única forma de recuperação dos objetos excluídos sem que o DC permaneça offline, além de ser a única maneira de recuperar as informações sobre a identidade de um objeto excluído como, por exemplo, seus atributos objectGUID e objectSid. Ela resolve de maneira interessante o problema da recriação de um usuário ou grupo excluído e da correção de todas as referências antigas de acesso à ACL (lista de controle de acesso), que contêm o objectSid do objeto excluído. Apenas não se esqueça de que a reanimação de marcas para exclusão tem suas próprias limitações, as quais abordarei, e você continuará querendo manter as restaurações autoritativas na manga.

A reanimação de marcas para exclusão foi introduzida no Windows Server® 2003 Active Directory para simplificar determinados cenários de recuperação dos dados. Esse recurso se aproveita do fato de que o Active Directory mantém os objetos excluídos no banco de dados durante um certo período antes de removê-los fisicamente. Neste artigo, eu fornecerei uma descrição detalhada de como o Active Directory exclui e reanima os objetos e mostrarei como é possível recuperar objetos excluídos usando as ferramentas padrão da Microsoft.

O que é uma marca para exclusão?

Quando exclui um objeto do diretório, o Active Directory não o remove fisicamente do banco de dados. Na verdade, o Active Directory marca o objeto como excluído ao definir o atributo isDeleted do objeto como TRUE, ao remover grande parte dos atributos do objeto, ao renomear o objeto e ao movê-lo para um contêiner especial no NC (contexto de nomenclatura) do objeto chamado CN=Deleted Objects. O objeto, agora chamado de marca para exclusão, é invisível para operações normais de diretório. Ele não aparece em nenhum snap-in do MMC (Console de Gerenciamento Microsoft®), e a maioria dos utilitários do protocolo LDAP (Lightweight Directory Access Protocol) ignora a existência das marcas para exclusão. Para todos os efeitos e finalidades, a marca para exclusão já era. No entanto, os dados ainda estão lá – apenas invisíveis. E por que o Active Directory mantém marcas para exclusão, outrora objetos excluídos, no banco de dados?

Embora seja invisível para os demais processos, uma marca para exclusão é visível para o processo de replicação do Active Directory. Para ter a certeza de que a exclusão foi executada em todos os DCs que hospedam o objeto excluído, o Active Directory replica a marca para exclusão aos demais DCs. Por isso, a marca para exclusão é usada na replicação da exclusão em todo o ambiente do Active Directory.

O tempo de vida de uma marca para exclusão

O Active Directory normalmente exclui um objeto do diretório em resposta a uma operação de exclusão do protocolo LDAP ou do SAM (Gerenciador de Contas de Segurança). Essa operação é chamada de exclusão originadora e é diferente das operações de exclusão executadas pelo processo de replicação do Active Directory. Observe que esta descrição não leva em conta os objetos dinâmicos, que têm um mecanismo de exclusão diferente e que são excluídos diretamente pelo Active Directory quando a TTL (vida útil) expira.

Quando recebe a operação de exclusão, o Active Directory inicialmente confere uma lista de verificação para ter a certeza de que o objeto pode ser excluído. Esse processo está surpreendentemente envolvido, já que ele verifica se todos os seguintes critérios são verdadeiros:

• o atributo isDeleted do objeto ainda não está definido como TRUE. (Não é possível excluir um objeto que já tenha sido excluído!)
• o sinalizador de controle do descritor de segurança específico do recurso "objeto privado" não está definido no descritor de segurança do objeto. (Esse parece ser um "recurso" não documentado. O sinalizador do objeto privado é o bit 1 do byte Sbz1 da estrutura do descritor de segurança.)
• o bit de "desautorização da exclusão" (0x80000000) não está definido no atributo systemFlags do objeto.
• o atributo isCriticalSystemObject do objeto ainda não está definido como TRUE.
• o descritor de segurança do objeto concede os direitos de acesso apropriados para o usuário excluir o objeto. (Mais especificamente, o usuário tem a permissão para excluir o próprio objeto e um filho do objeto pai.)
• o objeto não é um objeto de referência cruzada (objectClass = crossRef) para um contexto de nomenclatura existente.
• o objeto não tem nenhum objeto subordinado. (Se a operação de exclusão do protocolo LDAP incluir a identificação do objeto de controle "exclusão de árvore", o Active Directory também excluirá automaticamente os objetos subordinados, a menos que eles tenham o atributo isCriticalSystemObject definido como TRUE. Isso impede que os objetos de sistema críticos sejam excluídos acidentalmente como parte de uma operação de exclusão da árvore. É claro que você pode excluir esses objetos individualmente.)
• o objeto não é um objeto interno crítico (por exemplo, não se trata do objeto nTDSDSA do DC ou de objetos de espaço reservado para ancestrais dos títulos do NC).

Além desses critérios serem verdadeiros, o Active Directory também deve estar em um estado apropriado para processar a operação de exclusão. Por exemplo, se estiver no processo de renomeação de um domínio, o Active Directory não excluirá uma conta de confiança do domínio ou um objeto crossRef.

Caso seja determinado que o objeto possa, de fato, ser excluído, o Active Directory continua transformando-o em uma marca para exclusão. O Active Directory inicialmente remove os atributos desnecessários do objeto, deixando os especificados na Figura 1 e os definidos no esquema a ser retido na marca para exclusão. (Consulte a seção "Recuperando atributos do objeto" para obter mais informações sobre isso.) Em seguida, ele altera o RDN (nome distinto relativo) do objeto para CN=<old RDN>\0ADEL:<objectGUID>, em que \0A indica o caractere de avanço de linha ASCII e <objectGUID> é o objectGUID expressado como uma cadeia de caracteres. Em seguida, o atributo lastKnownParent é definido como sendo o DN (nome distinto) do contêiner pai do objeto e o atributo isDeleted é definido como TRUE. Então, o Active Directory remove todos os atributos de vínculo progressivo e regressivo do objeto. Por fim, caso o atributo systemFlag do objeto não tenha o bit de "desautorização de movimentação ao excluir" definido, o Active Directory move o objeto para o contêiner CN=Deleted Objects do NC. (Consulte a barra lateral "Atributo systemFlags e comportamento do objeto" para obter mais informações sobre o assunto.)

Figure 1 Atributos salvos em uma marca para exclusão

Você deve observar que a pasta CN=Deleted Objects é simples e não tem nenhuma hierarquia de objetos. Você pode pensar que isso causaria conflitos de nome se você excluísse dois objetos diferentes com o mesmo CN. Só que não é este o caso. Como o objectGUID está incorporado no RDN de todas as marcas para exclusão, o RDN de cada marca é único dentro do contêiner CN=Deleted Objects.

É claro que os objetos não permanecem no contêiner CN=Deleted Objects para sempre. O tempo de vida padrão da marca para exclusão é de 60 dias para florestas criadas inicialmente com o Windows® 2000 e o Windows Server 2003 e de 180 dias para florestas criadas inicialmente com o Windows Server 2003 SP1. É possível alterar o tempo de vida da marca para exclusão definindo o atributo tombstoneLifetime do objeto CN=Directory Service,CN=Windows NT, CN=Services,CN=Configuration, DC=<domínio raiz>.

A cada 12 horas, todos os controladores de domínio iniciam um processo de coleta de lixo. (Isso pode ser alterado com a definição de um novo valor para o atributo garbageCollPeriod do objeto CN=Directory Service,CN=Windows NT, CN=Services,CN=Configuration,DC=<domínio raiz>.) Essa coleta de lixo examina todas as marcas para exclusão no DC e exclui fisicamente todas as que ultrapassarem o tempo de vida da marca para exclusão.

Usando o LDP para localizar marcas para exclusão

LDP é um utilitário ao estilo Windows Explorer a ser usado com o Active Directory. O LDP foi projetado originalmente pela equipe de desenvolvimento do Active Directory para testar seu código LDAP enquanto o Active Directory estava sendo desenvolvido. Agora parte das ferramentas de suporte do Windows Server 2003, o LDP passou a ser uma ferramenta robusta a ser usada com o Active Directory.

Muito embora as marcas para exclusão sejam invisíveis para operações de diretório normais, é possível localizar objetos de marca para exclusão no Active Directory usando as operações de pesquisa e as extensões especiais do LDAP, chamadas de controles. Os controles formam um mecanismo, definido no padrão LDAP, usado para estender o protocolo LDAP e fornecer funcionalidades adicionais que vão além da definição no padrão LDAP ao mesmo tempo em que permanecem compatíveis com os demais softwares adequados ao LDAP. O Active Directory dá suporte a 22 controles, incluindo o controle Return Deleted Objects. Quando usado para estender a operação de pesquisa LDAP, esse controle recupera objetos excluídos que normalmente estariam invisíveis.

Para demonstrar como isso funciona, eu fiz o logon no domínio foo.local com as credenciais de Administrador Corporativo e usei o snap-in do MMC ADUC (Usuários e Computadores do Active Directory) para criar um objeto do usuário (CN=John Smith,CN=Users,DC=foo, DC=local), como mostra a Figura 2. Em seguida, excluí o objeto do usuário usando novamente o ADUC.

Figura 2** Usando o ADUC para criar um usuário **(Clique na imagem para aumentar a exibição)

Agora eu posso executar o programa LDP e usá-lo para exibir a marca de exclusão do usuário removido. A primeira etapa é conectar o LDP a um DC específico e autenticá-lo usando as credenciais apropriadas. Para me conectar ao DC, eu apenas seleciono a opção Connect (Conectar) no menu Connection (Conexão). Como estou executando o LDP no DC, eu apenas pressiono OK para me conectar ao DC local. Caso esteja executando o LDP remotamente, você deve especificar o nome do DC ao qual deseja se conectar. Depois de me conectar com êxito, o LDP exibe os atributos de rootDSE – ele contém os atributos que descrevem o estado e a configuração do próprio DC (consulte a Figura 3).

Figura 3** LDP conectado a um DC **(Clique na imagem para aumentar a exibição)

Agora, para me autenticar no DC usando as credenciais de administrador corporativo ou de domínio, eu seleciono Bind (Ligar) no menu Connection. Como já fiz o logon como Administrador Corporativo na floresta (por padrão, Administradores de Domínio e Administradores Corporativos têm os direitos de listar e reanimar objetos do contêiner CN=Deleted Objects), eu apenas deixo vazios Username (Nome de usuário) e Password (Senha) na caixa de diálogo Bind e pressiono OK. Do contrário, eu poderia inserir as credenciais apropriadas na caixa de diálogo Bind.

Em seguida, desejo listar o conteúdo do contêiner CN=Deleted Objects,DC=foo,DC=local. Você normalmente não verá o contêiner CN=Deleted Objects porque ele próprio está marcado como excluído. A única forma de pesquisar o contêiner CN=Deleted Objects é usando o controle Return Deleted Objects do LDAP.

Para usá-lo com o LDP, vá para o menu Browse (Procurar) e selecione Search (Pesquisar). A caixa de diálogo de pesquisa mostrada na Figura 4 será exibida. O campo Base Dn (Dn Base) permite que você especifique onde começar a pesquisar dentro da árvore de diretório. Eu insiro o DN do contêiner Deleted Objects do domínio – neste exemplo, o DN é CN=Deleted Objects,DC=foo,DC=local.

Figura 4** Caixa de diálogo Search do LDP **

No campo Filter (Filtro), eu especifico os critérios de pesquisa que o LDP usará. O valor padrão é (objectClass=*), que instrui a pesquisa a retornar todos os objetos que tenham um valor referente ao atributo objectClass. Como mesmo os objetos excluídos no Active Directory têm um valor de objectClass, o filtro padrão retornará todos os objetos dentro do escopo da pesquisa. Neste exemplo, eu altero o filtro para (objectClass=user), o que limita a pesquisa a objetos do usuário. Isso nos permitirá encontrar mais facilmente o usuário excluído John Smith em meio às possíveis milhares de marcas para exclusão no contêiner CN=Deleted Objects.

Você talvez ache que há mais objetos no contêiner CN=Deleted Objects do que os retornados pelo Active Directory em uma única operação de pesquisa. Para resolver esse problema, você normalmente usaria uma pesquisa paginável do LDAP, que retorna os resultados de um grupo por vez. No entanto, o LDP não permite que você especifique uma pesquisa paginável e estendida ao mesmo tempo. Dessa forma, você terá que refinar o filtro do LDAP para localizar o objeto desejado.

Os botões de opção Scope (Escopo) permitem que você especifique o nível de pesquisa na árvore de diretório. Uma pesquisa básica retornará apenas o objeto especificado pelo campo Base Dn. A pesquisa em um nível retornará objetos imediatamente subordinados ao objeto Base Dn. E uma pesquisa em subárvore retornará todos os objetos subordinados ao objeto Base Dn. Como a pasta CN=Deleted Objects é simples, eu uso a pesquisa em um nível para recuperar todas as marcas para exclusão.

Até agora, eu apenas descrevi uma pesquisa convencional do LDAP. Se eu fosse executá-lo agora, o LDP exibiria um erro indicando que CN=Deleted Objects,DC=foo,DC=com não existe, por ele estar marcado como excluído. Eu ainda preciso incluir o controle Return Deleted Objects do LDAP na operação de pesquisa. Para isso, eu clico no botão Options (Opções) da caixa de diálogo Search e seleciono Extended (Estendido) para Search Call Type (Tipo de Chamada de Pesquisa), como mostra a Figura 5. Essa opção me permite especificar os controles da operação de pesquisa. Aqui, eu também altero a lista Attributes (Atributos) para *. Isso faz com que o LDP exiba todos os atributos normais de cada objeto recuperado, e não o conjunto de atributos padrão do LDP.

Figura 5** Caixa de diálogo Search Options do LDP **

Agora eu pressiono o botão Controls (Controles) para exibir a caixa de diálogo Controls. Como a caixa de diálogo Controls do LDP é um pouco estranha, não se esqueça de seguir estas etapas com cuidado ao adicionar o controle Return Deleted Objects.

Abra a lista suspensa Load Predefined (Carregar Predefinições), selecione Return deleted objects (Retornar objetos selecionados) e pressione o botão Check in. Isso adiciona o OID (identificador de objeto) do controle Return Deleted Objects (1.2.840.113556.1.4.417) à lista Active Controls (Controles Ativos), como mostra a Figura 6. Em seguida, o LDP adiciona o controle a todas as operações de pesquisa estendida subseqüentes. Pressione OK para salvar as configurações e OK novamente para fechar a caixa de diálogo Search Options (Opções de Pesquisa).

Figura 6** Adicionando o controle Return Deleted Objects **

A caixa de diálogo Controls tem um comportamento peculiar. Especificamente, muito embora apareça um OID na lista Active Controls, isso não significa necessariamente que o controle esteja, de fato, em vigor. Às vezes, você precisa fazer o check-out de um controle e fazer o check-in novamente para garantir que ele seja usado na próxima operação do FDAP.

Agora estou pronto para executar a minha pesquisa. Pressiono o botão OK na caixa de diálogo LDP Search (Pesquisa do LDP), e o LDP recupera todos os objetos do usuário que estejam no contêiner CN=Deleted Objects do domínio. A Figura 7 mostra os meus resultados.

Figura 7** Resultados do contêiner CN=Deleted Objects **(Clique na imagem para aumentar a exibição)

Examinando os resultados do LDP

Minha pesquisa retornou dois objetos de marca para exclusão. Inicialmente, é possível ver o DN da primeira marca para exclusão: CN=John Smith\0ADEL:41800281-6bc4-42c3-a99b-b283022b3af8,CN=Deleted Objects,DC=foo,DC=local. O objectGUID do objeto excluído é representado como uma cadeia de caracteres (41800281-6bc4-42c3-a99b-b283022b3af8). Abaixo do DN está uma lista dos atributos que mostram os valores de objectClass, cn, distinguishedName, etc. É possível ver que o valor do atributo isDeleted é TRUE, o que significa que o objeto foi, de fato, excluído. Você também verá que o objectSid foi preservado na marca para exclusão – isso é importante para recuperar marcas para exclusão de usuários e grupos, como analisarei depois. O atributo lastKnownParent, que representa o DN do objeto que continha o objeto excluído antes de se tornar uma marca para exclusão, também é extremamente importante durante a recuperação das marcas para exclusão.

No meu exemplo, o LDP exibiu dois objetos de marca para exclusão, os quais ambos eram objetos do usuário com o nome CN=John Smith que vinham originalmente do contêiner CN=Users,dc=foo,dc=local. Como posso separar objetos com o mesmo RDN e que vêm do mesmo contêiner? A explicação é muito simples. Antes de executar o LDP para procurar marcas para exclusão, eu criei o objeto do usuário CN=John Smith no contêiner CN=Users,DC=foo,DC=local e o excluí. Em seguida, criei outro objeto de usuário com todos os atributos iguais e também o excluí. Como eu já tinha excluído o primeiro objeto do usuário CN=John Smith, era perfeitamente razoável criar o segundo, muito embora ele tivesse o mesmo nome. Mas esses são objetos separados, únicos, diferenciados por seus objectGUIDs. Como o Active Directory incorpora o objectGUID ao DN da marca para exclusão, eles aparecem como sendo objetos separados no contêiner CN=Deleted Objects.

Como uma marca para exclusão é reanimada

O Active Directory oferece um mecanismo para restaurar uma marca para exclusão como sendo um objeto normal. Isso é efetivamente uma função para desfazer a exclusão de objetos excluídos. A função é de uma operação de modificação do LDAP formada especialmente e que deve incluir duas modificações de atributo específicas: ela deve remover o atributo isDeleted (não apenas defini-lo como FALSE) e mover o objeto para outro contêiner alterando o distinguishedName do objeto. O novo distinguishedName normalmente (mas não necessariamente) usa o atributo lastKnownParent como o contêiner e mantém o mesmo RDN menos o componente \0ADEL:<objectGUID>que o Active Directory adicionou ao criar a marca para exclusão.

Antes de reanimar a marca para exclusão, o Active Directory verifica se determinadas condições necessárias são todas verdadeiras. O usuário deve ter o direito de acesso estendido para reanimar marcas para exclusão definido no título do NC que contém a marca para exclusão. O usuário não pode reanimar seu próprio objeto. O atributo isDeleted da marca para exclusão deve estar definido como TRUE. E o SID (Identificador de Segurança) do objeto do proprietário, conforme a definição no descritor de segurança, deve ter um SID de um dos domínios da floresta ou de um domínio confiável.

Caso o objeto em questão esteja nos NCs Configuration ou Schema, os bits FLAG_CONFIG_ALLOW_RENAME e FLAG_ CONFIG_ALLOW_MOVE devem estar definidos no atributo systemFlags da marca para exclusão. Caso o objeto esteja nos NCs Configuration ou Schema e o sinalizador FLAG_CONFIG_ALLOW_LIMITED_MOVE esteja definido, o objeto só pode ser movido para um contêiner que tenha o mesmo avô – em outras palavras, o objeto deve manter seu bisavô depois da movimentação. E caso o objeto esteja em um NC de domínio ou em uma partição do aplicativo, os bits FLAG_DOMAIN_DISALLOW_RENAME e FLAG_DOMAIN_DISALLOW_MOVE não devem ser definidos no atributo systemFlags da marca para exclusão.

O usuário deve ter os direitos, conforme a definição no descritor de segurança, para modificar o RDN (normalmente o CN, mas nem sempre) e adicionar o objeto ao novo contêiner pai. E novo contêiner pai deve ser superior ao objectClass da marca para exclusão, conforme definição do esquema. Embora as movimentações para dentro ou para fora do contêiner System não sejam normalmente permitidas (a menos que o valor de registro da subárvore do sistema Unlock seja diferente de zero), a reanimação de uma marca para exclusão no contêiner System é permitida.

Jamais é permitido reanimar um objeto de esquema. No entanto, isso não é realmente um problema, já que é possível excluir legitimamente um objeto do NC Schema.

Caso todas as verificações tenham êxito e os requisitos necessários sejam atendidos, o Active Directory realiza as seguintes etapas na marca para exclusão para reanimar o objeto:

• O atributo isDeleted é removido.
• Caso não tenha prescrito na operação de modificação, o objectCategory é definido para o objectClass mais específico indicado na marca para exclusão.
• O RDN é alterado, e o objeto é gravado no novo contêiner pai.

Depois da reanimação, o objeto tem os mesmos atributos objectGUID e objectSid que tinha originalmente. Isso significa que as referências externas ao objeto, por exemplo, nas ACLs, não precisam ser redefinidas como acontece caso você recrie um objeto excluído. O objeto reanimado parece e age como fazia antes de ser excluído. Só que há uma diferença importante: o objeto restaurado perde todos os atributos que não foram salvos na marca para exclusão.

Uso do LDP para reanimar marcas para exclusão

Atributo systemFlags e comportamento do objeto

systemFlags é um atributo opcional definido para a classe superior, o que torna systemFlags um atributo opcional para todas as classes do Active Directory. Trata-se de um bitmask de inteiro de 32 bits que controla o comportamento das movimentações e das exclusões do objeto. Aqui está um resumo rápido de sinalizadores importantes.

FLAG_DISALLOW_DELETE (0x80000000)

Se esse sinalizador estiver definido, o sistema não permitirá que o objeto seja excluído ou movido para outro domínio.

FLAG_CONFIG_ALLOW_RENAME (0x40000000)

Os objetos nos NCs Configuration e Schema não podem ser renomeados, a menos que esse sinalizador esteja definido no atributo systemFlags.

FLAG_CONFIG_ALLOW_MOVE (0x20000000)

Os objetos nos NCs Configuration e Schema não podem ser movidos, a menos que esse sinalizador esteja definido no atributo systemFlags.

FLAG_CONFIG_ALLOW_LIMITED_MOVE (0x10000000)

Os objetos nos NCs Configuration e Schema não podem ser movidos, a menos que esse sinalizador esteja definido no atributo systemFlags. Esse sinalizador impõe mais uma restrição no contêiner de destino da operação de movimentação – o contêiner de destino deve ter o mesmo avô do contêiner atual.

FLAG_DOMAIN_DISALLOW_RENAME (0x08000000)

Por padrão, os objetos em um NC de domínio ou de aplicativo não podem ser renomeados. No entanto, se esse sinalizador estiver definido no atributo systemFlags do objeto, o sistema não permitirá que o objeto seja renomeado.

FLAG_DOMAIN_DISALLOW_MOVE (0x04000000)

Por padrão, os objetos em um NC de domínio ou de aplicativo não podem ser movidos para outro contêiner. No entanto, se esse sinalizador estiver definido no atributo systemFlags do objeto, o sistema não permitirá que o objeto seja movido.

FLAG_DISALLOW_MOVE_ON_DELETE (0x02000000)

Se esse sinalizador estiver definido, o sistema não moverá o objeto para o contêiner CN=Deleted Objects do seu contexto de nomenclatura. Ele irá simplesmente definir o atributo isDeleted, renomear o objeto e remover os atributos não designados no esquema a ser salvo. Isso significa que nem todos os objetos excluídos aparecem no contêiner CN=Deleted Objects do contexto de nomenclatura; alguns permanecem no contêiner pai original.

Agora que eu já mostrei os detalhes práticos da reanimação de marcas para exclusão, quero demonstrar como é possível usar o LDP para restaurar o usuário CN=John Smith que excluí. Primeiramente, eu me conecto a um DC e me autentico. Agora eu posso executar uma operação de modificação usando o LDP. Nos parâmetros de operação da modificação, eu posso remover o atributo isDeleted e especificar um novo DN ao mesmo tempo.

Como estou operando em uma marca para exclusão, eu tenho que especificar o controle Return Deleted Objects do LDAP. Para definir esse controle para a operação de modificação no LDP, selecione Controls no menu de opções, selecione Return deleted objects na lista suspensa Load Predefined, pressione o botão Check in e OK para salvar as configurações do controle.

Agora eu seleciono Modify (Modificar) no menu Browse para abrir a caixa de diálogo Modify e insiro o DN do objeto de marca para exclusão que desejo restaurar. A forma mais fácil de fazer isso é copiando e colando o DN dos resultados da operação de pesquisa que executei antes.

Em seguida, preciso inserir uma lista das operações de atributo a serem executadas. A reanimação de uma marca para exclusão exige duas operações de atributo: excluir o atributo isDeleted e substituir o atributo distinguishedName pelo DN desejado da marca para exclusão reanimada. Então eu digito isDeleted no campo Attribute (Atributo) e seleciono o botão de opção Delete (Excluir). Quando pressiono o botão Enter, a operação de atributo é adicionada à Entry List (Lista de Entradas), como mostra a Figura 8.

Figura 8** Especificando as operações de atributo a serem executadas **

Em seguida, eu insiro distinguishedName no campo Attribute, seleciono o botão de opção Replace (Substituir) e digito o novo DN do objeto no campo Values (Valores). Nesse caso, eu uso o distuiguishedName original do usuário, CN=John Smith,CN=Users,DC=foo,DC=local. Quando pressiono o botão Enter, a operação de modificação é adicionada à Entry List.

Como tenho que incluir o controle Return Deleted Objects do LDAP na operação de modificação, eu preciso usar uma modificação de LDAP estendida. Para isso, eu marco a caixa de seleção Extended. Depois que estiver tudo definido, como mostra a Figura 9, eu pressiono o botão Run (Executar) para fazer as alterações. O LDP exibe os resultados em uma janela de texto grande.

Figura 9** Alterar o distinguishedName **

Quando retornar ao snap-in do MMC Usuários e Computadores do Active Directory e examinar o contêiner CN=Users, eu verei o usuário que foi excluído de volta ao lugar de onde ele veio. Mas o objeto terá algumas diferenças importantes em relação ao seu estado original, as quais observarei em breve.

Usando o ADRESTORE para reanimar marcas para exclusão

Depois que você sabe como usar o LDP, reanimar uma marca para exclusão não é algo terrivelmente difícil. Mas também não é muito prático. Felizmente, o bom pessoal da Sysinternals (uma empresa que hoje faz parte da Microsoft) desenvolveu uma ferramenta de linha de comando para simplificar o processo de reanimação. Essa ferramenta, chamada de ADRESTORE, está disponível no site da Microsoft em microsoft.com/technet/ sysinternals/utilities/AdRestore.mspx. A instalação é simples. Basta copiar o executável para um diretório apropriado do seu computador, por exemplo, o diretório C:\WINDOWS\SYSTEM32.

O ADRESTORE é executado em dois modos. Se você executá-lo sem parâmetros, ele listará todas as marcas para exclusão no contêiner CN=Deleted Objects do domínio padrão. É possível adicionar uma cadeia de caracteres de pesquisa à linha de comando para selecionar os objetos a serem exibidos, por exemplo:

C:\> adrestore John

Isso exibirá todos os objetos de marca para exclusão no contêiner CN=Deleted Objects com a cadeia de caracteres "John" em seu CN ou atributo OU – ele usa os filtros de pesquisa do LDAP cn=*John* e ou=*John*. Não se trata exatamente da maneira mais flexível de pesquisar objetos de marca para exclusão, embora funcione na maioria das situações. A Figura 10 mostra a saída retornada pela minha pesquisa no ADRESTORE.

Figura 10** Atributos salvos em uma marca para exclusão **(Clique na imagem para aumentar a exibição)

Caso queira reanimar uma marca para exclusão, e não apenas localizá-la, você precisa especificar a opção –r com uma cadeia de caracteres opcional como a seguinte:

C:\> adrestore –r John

Esse comando solicitará que você reanime todos os objetos de marca de exclusão correspondentes. O ADRESTORE sempre reanima o objeto no contêiner dado pelo atributo lastKnownParent da marca para exclusão – não há como especificar um contêiner diferente.

O ADRESTORE fornece uma interface de linha de comando prática para o uso da funcionalidade de reanimação do Active Directory. Embora não seja muito flexível, ele é bem mais fácil de usar do que o LDP. Ainda assim, o ADRESTORE não evita dois problemas significativos em relação à reanimação das marcas para exclusão: a recuperação dos atributos removidos do objeto quando ele foi excluído pela primeira vez e a recuperação dos objetos excluídos do NC Configuration.

Recuperando atributos do objeto

Em termos de recuperação de dados, a reanimação de marcas para exclusão tem uma grande vantagem em relação à execução de uma restauração autoritativa: a reanimação de marcas para exclusão não exige que o DC permaneça offline. E reanimar marcas para exclusão é muito melhor do que apenas recriar uma nova versão de um objeto excluído. Se você recriar um objeto, ele sempre receberá novos atributos objectGUID e objectSid (se ele for uma entidade de segurança como, por exemplo, um usuário). Dessa forma, todas as referências externas ao objeto como, por exemplo, as ACLs terão que ser atualizadas para refletir a nova identidade do objeto. Isso pode ser uma grande dor de cabeça.

Alguns atributos são removidos quando um objeto é excluído, e estes não são recuperados com a reanimação de marcas para exclusão. Mas o Active Directory salva alguns atributos principais na marca para exclusão, dentre os quais os mais importantes são os relacionados à identidade como, por exemplo, objectGUID e objectSid. Por padrão, ele também salva muitos outros atributos (veja a Figura 1). A maioria dos atributos codificados para serem salvos não é muito interessante, especialmente em uma avaliação da recuperação de objetos de usuário excluídos. Mas é possível especificar atributos adicionais a serem salvos na marca para exclusão definindo o bit 3 (0x00000008) do atributo searchFlags do objeto attributeSchema correspondente no esquema do Active Directory. Alguns atributos já têm esse bit definido no esquema no Windows Server 2003 R2 (eles também são mostrados na Figura 1).

Instalar determinados aplicativos pode alterar o bit 3 de searchFlags dos atributos existentes ou mesmo adicionar novos atributos que tenham o bit 3 definido. O Exchange Server, por exemplo, configura vários atributos adicionais a serem salvos na marca para exclusão.

O Active Directory não salvará atributos de vínculo progressivo ou regressivo na marca para exclusão, mesmo que você especifique isso no atributo searchFlags do objeto do esquema. Em especial, o Active Directory não salva coisas como o atributo member de um grupo ou o atributo memberOf de um usuário. Por isso, a reanimação de marcas para exclusão não oferece uma solução para a recuperação de associações de grupo no Active Directory. A respeito disso, consulte o meu artigo "Recuperação de desastres: usuários e grupos do Active Directory" em technetmagazine.com/issues/2007/04/ADRecovery. Portanto, você continuará precisando fornecer um mecanismo alternativo para recuperar as informações ao reanimar as marcas para exclusão.

Se quiser usar a reanimação de marcas para exclusão como parte da estratégia de recuperação dos dados, você precisará ter certeza de que os atributos importantes estão salvos na marca ou apresentar outra forma de salvar e recuperar atributos importantes como, por exemplo, usando o LDIFDE ou outro esquema de backup e restauração. Entre as demais opções estão produtos de terceiros para recuperação de dados do Active Directory que oferecem um mecanismo para fazer o backup e restaurar atributos que não estão salvos e não são recuperados da marca para exclusão.

Reanimando objetos do contexto de nomenclatura Configuration

Uma outra limitação substancial da qual a reanimação de marcas para exclusão padece é que, de maneira geral, não é possível reanimar objetos que foram excluídos do NC Configuration. Esses objetos estão sujeitos às regras especiais em relação à movimentação e à nova nomenclatura, conforme definição do atributo systemFlags. A menos quando especificado o contrário pelo atributo systemFlags, os objetos no NC Configuration não podem ser movidos ou renomeados. O Active Directory impõe determinados valores para o atributo systemFlags ao criar objetos de classes específicas, conforme definição na Figura 11. Observe que o Active Directory aplica a operação OR lógica bit a bit a esses valores em combinação com qualquer valor systemFlags especificado na operação de adição. Dessa forma, mesmo se o aplicativo especificar um valor diferente para o atributo systemFlags, os bits necessários serão definidos corretamente.

Figure 11 Configurações systemFlags padrão

Os únicos objetos do NC Configuration que é possível reanimar em condições normais são os objetos de servidor. Curiosamente, quando o Active Directory exclui um objeto de servidor, a marca para exclusão não é movida para o contêiner CN=Deleted Objects do NC Configuration; a marca para exclusão simplesmente permanece onde está o objeto. Isso permite que o KCC (Knowledge Consistency Checker), que é o processo responsável por calcular a topologia de replicação do Active Directory, se recupere automaticamente de determinados cenários em que objetos de servidor excluídos possam inibir a replicação adequada. Caso esteja tentando reanimar um objeto de servidor, lembre-se de que você não o encontrará no contêiner CN=Deleted Objects.

Reanimação no seu plano de recuperação

A reanimação de marcas para exclusão deve ser uma parte essencial do seu kit de ferramentas. Esse mecanismo é a única forma de recuperação dos objetos excluídos sem que o DC permaneça offline, e, igualmente importante, é a única maneira de recuperar as informações sobre a identidade de um objeto excluído. Isso resolve de maneira interessante o problema da recriação de um usuário ou grupo excluído e da correção de todas as referências antigas de acesso à ACL.

Mas a reanimação da marca para exclusão é uma solução incompleta. Você precisa fornecer o seu próprio mecanismo para a recuperação dos atributos que o Active Directory não mantém em objetos de marca para recuperação, e a sua capacidade de recuperar os objetos excluídos do NC Configuration está limitada. Não se esqueça de que se optar por reanimar um usuário ou grupo excluído, você ainda precisará recuperar as associações de grupo e todos os demais atributos vinculados que talvez sejam necessários.

Gil Kirkpatrick é o Diretor de Tecnologia (CTO) da NetPro e desenvolve softwares para Active Directory desde 1996. Com Guido Grillenmeier, da HP, ele apresenta os conhecidos workshops sobre recuperação de desastres do Active Directory. Gil também é o fundador da Directory Experts Conference (www.dec2007.com).

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