Um guia para a replicação do Active Directory
Laura E. Hunter
Visão geral:
- Transição para o Active Directory
- Manutenção da consistência
- Resolução de conflitos
- Alterações no Windows Server 2008
Antes da introdução do Windows 2000 Server e do Active Directory, muitos ambientes corporativos contavam com o Windows NT para sua infra-estrutura de servidores e gerenciamento de identidades e acessos
. Quando o Windows NT® 4.0 foi lançado, ele era uma opção consistente no espaço NOS (sistema operacional de rede), mas tinha algumas desvantagens que dificultavam a implantação em uma grande empresa.
Para os iniciantes, o Windows NT usava um namespace simples para armazenar os recursos, o que significava que não havia uma boa forma de separar os recursos em subconjuntos menores ou de configurar um tipo de administração granular. Você não podia, por exemplo, configurar um contêiner por departamento para os recursos do departamento de marketing ou configurar um administrador local que tivesse direitos para redefinir senhas dos usuários apenas dentro desse departamento. Dessa forma, a segurança do Windows NT era muito na base do tudo ou nada; se quisesse delegar tarefas administrativas a um engenheiro de suporte desktop, você normalmente era forçado a conceder muito mais permissões do que normalmente faria.
Além disso, o Windows NT armazenava todas as informações em um banco de dados SAM (Gerente de Contas de Segurança) que não podia crescer além dos 40 MB. Caso o banco de dados SAM crescesse além desse máximo recomendado (isso acontecia próximo dos 25 mil a 40 mil objetos, dependendo da configuração), você precisava dividir o ambiente em vários domínios separados, o que complicava a administração da rede e o fornecimento de acesso aos recursos para os usuários. Cada domínio do NT apresentava um PDC (controlador de domínio primário), que contava com a única cópia de leitura/gravação do banco de dados SAM; embora você pudesse implantar um ou mais BDCs (controladores de domínio de backup) para tolerância a falhas, esses BDCs eram somente leitura e não podiam realizar nenhuma atualização como, por exemplo, alterar a senha de um usuário, que exigia uma operação de gravação.
Por fim, o Windows NT contava com a resolução de nomes NetBIOS, que era baseada em difusão e costumava gerar muito tráfego à medida que os usuários procuravam recursos de rede, especialmente se eles precisassem fazer isso em um link WAN lento ou muito usado.
Surge um novo modelo
No ano 2000, a Microsoft lançou o Windows® 2000, que incluía uma revisão substancial das opções do NOS anterior. O novo serviço NOS, o Active Directory®, era mais diferente do Windows NT do que você podia imaginar. Em vez de contar com um namespace simples, o Active Directory foi criado de acordo com o padrão X.500, que criava uma estrutura organizacional hierárquica; você podia organizar os recursos em várias unidades organizacionais dentro de um único domínio e delegar a administração de cada OU em um nível baseado em tarefa.
Outra mudança significativa em relação ao Windows NT foi o novo modelo de replicação de vários mestres. O PDC único gravável e seus BDCs associados eram coisa do passado; no Active Directory, cada controlador de domínio tinha a possibilidade de gravar no banco de dados do Active Directory.
No entanto, embora desse muita flexibilidade em termos de suporte a um ambiente grande e descentralizado, isso também criava novos desafios para a manutenção da integridade do Active Directory. Caso John Smith e Jane Dow façam uma alteração no mesmo objeto em escritórios em pontos distantes do país, o que acontece se essas alterações entrarem em conflito? O modelo de replicação do Active Directory define as formas pelas quais as atualizações são comunicadas a todos os controladores de domínio em um ambiente, bem como lidar com os conflitos que podem surgir como resultado dessa capacidade de vários mestres de fazer alterações praticamente a partir de qualquer lugar.
A mecânica da replicação do Active Directory
Tendo em vista esses exemplos, nós abordaremos apenas a replicação intra-site. Basicamente, a replicação intra-site foi projetada para replicar rapidamente as alterações para DCs dentro do mesmo local e é realizada usando a notificação de alterações. No caso da replicação intra-site, o DC1 notificará o DC2 de que ele tem alterações a serem replicadas, após as quais o DC2 obterá essas alterações do DC1. Da mesma forma, o DC2 notificará o DC1 quando tiver alguma alteração; depois disso, o DC1 obterá essas alterações do DC2. Como é possível ver, toda a replicação do Active Directory acontece em operações de recepção, e não de envio.
Como o Active Directory pode ser dimensionado para centenas de milhares ou até mesmo milhões de objetos, ele é necessário para criar o banco de dados Active Directory em seções, chamadas de contextos de nomenclatura. No mínimo, cada controlador de domínio armazena três NCs em sua cópia local do banco de dados Active Directory.
NC Schema O NC é replicado para todos os demais controladores de domínio da floresta. Ele contém informações sobre o esquema do Active Directory, que, por sua vez, define as classes e os atributos diferentes do objeto dentro do Active Directory.
NC Configuration Também replicado para todos os demais DCs da floresta, o NC contém informações sobre a configuração de toda a floresta pertencente ao layout físico do Active Directory, bem como informações sobre especificadores de exibição e cotas do Active Directory de toda a floresta.
NC de domínio O NC é replicado para todos os demais DCs dentro de um único domínio do Active Directory. Esse é o NC que contém os dados do Active Directory mais acessados: os usuários reais, os grupos, os computadores e os demais objetos que residem dentro de um determinado domínio do Active Directory.
Para otimizar ainda mais o tráfego de replicação, todos os contextos de nomenclatura são replicados separadamente para que um NC que não é alterado com muita freqüência — como o NC Schema —consuma a largura de banda da rede necessária ao NC de domínio, que deve ser alterado com muito mais freqüência.
Como as alterações no diretório podem ser feitas de qualquer DC do Active Directory, há dois tipos de operações de gravação que a replicação do Active Directory precisa controlar. Um tipo é a gravação de origem, quando uma determinada alteração foi realizada diretamente em um determinado DC. Por exemplo, caso você se conecte ao DC1 e altere a senha de um usuário, essa alteração é considerada uma gravação de origem no DC1. O Active Directory também deve controlar as gravações replicadas – como você pode imaginar, isso significa que uma determinada alteração foi replicada de outro controlador de domínio. A alteração considerada uma gravação de origem feita no DC1 será considerada uma gravação replicada quando essa alteração for replicada para DC2, DC3 e todos os demais DCs do domínio.
Os controladores de domínio do Active Directory gerenciam a transmissão de alterações feitas no diretório durante todo o uso dos metadados de replicação. Isso significa que, além de comunicar os dados reais alterados de um DC para outro (a descrição de John Smith foi alterada para "Diretor de RH"), o Active Directory também transmite as informações adicionais sobre essa alteração para permitir que os controladores de domínio gerenciem a replicação da maneira mais eficiente como, por exemplo, o DC de origem da alteração, a hora em que ela foi feita e os demais tipos de informações.
O primeiro item dos metadados de replicação que abordaremos é o USN (número de atualização de seqüência). Todos os controladores de domínio mantêm um USN específico. Sempre que é feita uma alteração no Active Directory nesse DC, o USN é incrementado em 1. Dessa forma, caso um DC tenha um USN igual a 1000 às 11h00 e um 1005 às 11h30, você sabe que foram feitas cinco alterações no banco de dados do Active Directory desse DC. No que se refere ao USN, não importa o que fossem essas alterações — você poderia ter modificado cinco objetos diferentes, criado cinco objetos, excluído cinco objetos ou uma combinação disso — e o USN do DC ainda assim será aumentado em cinco. Além disso, os USNs são internos apenas em um determinado controlador de domínio e não têm nenhuma relevância quando comparados aos demais DCs. Um DC em um domínio pode fazer uma alteração às 11h30, o que atribui um USN 1051, e um segundo DC no mesmo domínio pode fazer uma alteração exatamente no mesmo momento em que atribui um USN igual a 5084. Embora esses dois DCs tenham USNs totalmente diferentes para uma alteração feita mais ou menos na mesma hora, esse fato é irrelevante para a forma com que essas alterações são replicadas; o número de atualização de seqüência de um DC não tem nenhum significado para todos os demais DCs em termos comparativos entre as alterações.
Mas essa não é a única forma com a qual o USN de um DC pode ser incrementado. Não se esqueça de que uma alteração feita no banco de dados Active Directory pode consistir em uma gravação de origem ou uma gravação replicada. O número de atualização de seqüência de um controlador de domínio é incrementado por ambos os tipos de operações de gravação, o que significa que ele é incrementado sempre que as alterações são replicadas de outro DC. Agora, claramente cada DC precisa de uma forma para controlar as alterações que já foram replicadas; do contrário, ele permaneceria enviando todo o banco de dados do Active Directory pela rede a cada replicação. Para impedir isso, todos os controladores de domínio do Active Directory mantêm um valor chamado HWMV (high watermark vector) para todos os demais controladores de domínio que o usam na replicação. Cada DC associará esse HWMV ao GUID (identificador global exclusivo) do DC remoto, para evitar qualquer confusão caso o controlador de domínio remoto seja renomeado ou removido do diretório.
Comecemos com um exemplo simples, no qual você tem dois controladores de domínio configurados no domínio contoso.com, dc1.contoso.com e dc2.contoso.com. Como há apenas dois DCs no domínio contoso.com, DC1 e DC2 só são replicados entre si. (Observe que se trata de um exemplo simplificado que ainda não aborda toda a história da replicação do Active Directory; à medida que formos detalhando, acrescentaremos mais informações.)
Também vamos dizer que o USN atual do DC1 seja 3000, o USN do DC2, 4500, e que esses dois DCs estejam totalmente atualizados um em relação ao outro quando começarmos o nosso exemplo:
Etapa 1: DC1 e DC2 estão atualizados um relação ao outro. DC1 tem um HWMV igual a 4500 para DC2, e DC2 tem um HWMV igual a 3000 para DC1, como mostra a Figura 1.
.gif)
Figura 1 Estado atual dos dois DCs
Etapa 2: um administrador cria um novo objeto no DC1, e o USN do DC1 é incrementado para 3001, como mostra a Figura 2. Observe que o HWMV de DC1 não foi alterado no DC2, porque o DC1 ainda não notificou o DC2 de que há alterações em espera.
.gif)
Figura 2 Um novo objeto é adicionado
Etapa 3: DC1 notifica DC2 de que há alterações disponíveis. Em seguida, DC2 inicia a replicação com DC1 para solicitar todas as atualizações disponíveis. Como parte dessa solicitação, DC2 envia para DC1 o HWMV armazenado para DC1, como mostra a Figura 3.
.gif)
Figura 3 Notificação das alterações (Clique na imagem para aumentar a exibição)
Etapa 4: DC1 envia para DC2 a alteração correspondente a USN 3001, ou seja, o objeto criado no DC1 durante a Etapa 2. DC2 atualiza o seu próprio USN para 4501 e seu HWMV de DC1 para 3001, como mostra a Figura 4.
.gif)
Figura 4 Alterações e atualizações (Clique na imagem para aumentar a exibição)
Até aqui tudo bem, certo? Mas agora há um problema: DC2 tem uma alteração que deve ser replicada. Se a única coisa a continuar fossem os USNs e os HWMVs, neste ponto, o DC2 entraria em contato com o DC1 para replicar a mesma alteração para DC1 que este acabou de replicar para DC2, o que criaria um ciclo infinito de replicação e consumiria cada vez mais largura de banda. Para combater isso, adicionamos mais algumas peças ao quebra-cabeça, e a primeira é o UTDV (vetor UTD, ou vetor de atualização).
O UTDV é outra parte dos metadados de replicação usados para interromper a propagação, ou seja, sua finalidade é impedir que a mesma alteração cause a perda da largura de banda ao ser replicada repetidas vezes em toda a rede. Cada DC mantém uma tabela UTDV para todos os demais DCs que armazena uma réplica do contexto de nomenclatura em questão. Para o NC de domínio, todos os DCs de um domínio mantêm um UTDV para cada DC; já para os NCs Configuration e Schema NC, ele é mantido para todos os DCs da floresta. A tabela UTDV controla não apenas o USN mais alto recebido em cada um dos DCs dos parceiros de replicação, mas também o valor USN mais alto recebido de todos os DCs que estejam replicando em um determinado NC. Para permitir isso, todas as alterações replicadas também incluem as seguintes informações:
- o GUID do DC que está replicando a alteração. Essa pode ser uma alteração replicada como gravação de origem ou gravação replicada.
- o USN do DC que está replicando a alteração. Mais uma vez, essa pode ser uma alteração replicada como gravação de origem ou gravação replicada.
- o GUID do DC que originou a alteração. Caso esse GUID seja o mesmo do DC que está replicando a alteração, trata-se de uma gravação de origem. Do contrário, a tabela UTDV vem à tona.
- o USN do DC que originou a alteração. Novamente, caso esse USN seja o mesmo do DC que está replicando a alteração, trata-se de uma gravação de origem. Senão, a tabela UTDV é desconsiderada.
Para melhor ilustrar esse processo, aumentaremos a complexidade do nosso exemplo adicionando um terceiro controlador de domínio, DC3. Nesse exemplo, DC1, DC2 e DC3 são todos parceiros de replicação entre si; DC1 replica com DC2 e DC3, DC2 com DC1 e DC3 e DC3 com DC1 e DC2:
Etapa 1: DC1, DC2 e DC3 estão todos atualizados um relação ao outro.
Etapa 2: DC3 realiza uma gravação de origem simples redefinindo a senha da conta do usuário jsmith. DC3 notifica DC1 e DC2 de que há alterações disponíveis. DC1 e DC2 recebem a gravação de origem do DC3 e atualizam as tabelas HWMV e UTDV de DC3 como mostra a Figura 5.
.gif)
Figura 5 Atualizando as tabelas HWMV e UTDV (Clique na imagem para aumentar a exibição)
Etapa 3: aqui é onde o UTDV aparece. DC2 notifica DC1 de que há alterações disponíveis. Em seguida, DC1 entra em contato com DC2 que está solicitando todas as novas alterações enviando para ele as seguintes informações:
- A HWMV de DC1 para DC2, nesse caso, é de 4501.
- A tabela UTDV do DC1 (mostrada na Figura 6) que indica o USN de origem mais alto é recebida de todos os DCs, inclusive do DC3.
Figure 6 Tabela UTDV
| Todos os DCs que replicam este NC |
UTDV |
| <GUID de DC2> |
4501 |
| <GUID de DC3> |
7002 |
| |
|
Com base no HWMV igual a 4501, o DC2 vê que não replicou a alteração em questão para DC1 (consulte a Figura 7).
Figure 7 Uma alteração que precisa ser replicada
| Propriedade |
Valor |
GUID de DC local |
USN local |
GUID de DC de origem |
USN de origem |
| Propriedade de senha de jsmith |
%#FH%2rfg2 |
<GUID de DC2> |
4501 |
<GUID de DC3> |
7002 |
| |
|
|
|
|
|
No entanto, com base na tabela UTDV transmitida pelo DC1 antes do início da replicação, o DC2 determina que o DC1, na verdade, não exige essa alteração, uma vez que DC1 já recebeu a alteração de DC3. Nesse ponto, o DC1 apenas atualiza a entrada HWMV do DC2 para refletir o USN incrementado, como mostra a Figura 8. No entanto, para manter largura de banda, os dados reais não são enviados pela rede.
.gif)
Figura 8 Interrupção da propagação (Clique na imagem para aumentar a exibição)
Etapa 4: essa mesma interrupção da propagação ocorrerá quando o DC2 notificar o DC3 de que há alterações disponíveis e quando o DC1 notificar, da mesma forma, DC2 e DC3. Todos os três DC3s atualizarão suas respectivas entradas HWMV dos parceiros de replicação como mostra a Figura 8, mas os dados reais não passarão pela rede mais uma vez porque já foram transmitidos para todos os DCs na Etapa 2.
Resolução de conflitos em um ambiente com vários mestres
Até aqui, os nossos exemplos são de um mundo perfeito, em que apenas um administrador está fazendo alterações em um DC por vez e ninguém jamais se intromete nas coisas de outra pessoa. No mundo real, nós sabemos que isso raramente acontece. Como as atualizações feitas em um objeto do Active Directory podem vir de qualquer controlador do domínio, o que acontece se dois administradores fizerem atualizações conflitantes em dois controladores de domínio diferentes? Há três tipos de conflitos que podem ocorrer em um ambiente do Active Directory, e cada um deles usa um método diferente na resolução de conflitos.
Alterações conflitantes nas propriedades . Esse conflito ocorre caso dois administradores atualizem o mesmo objeto de maneira conflitante: um administrador define a descrição de um usuário como "Marketing" e outro, em um DC diferente, define a descrição desse usuário como "Vendas e Marketing".
Criando objetos conflitantes . Esse conflito ocorre caso dois administradores criem um objeto com o mesmo nome simultaneamente como, por exemplo, dois usuários com o nome jsmith.
Movendo um objeto para um contêiner excluído . Esse tipo de conflito é muito mais raro e ocorre caso um administrador crie ou mova um objeto dentro de um contêiner como, por exemplo, uma OU, ao mesmo tempo em que outro administrador, em um DC diferente, exclui esse contêiner.
Para corrigir os dois primeiros tipos de conflito, é hora de apresentarmos mais duas partes dos metadados de replicação usados principalmente na resolução de conflitos. O valor versionID é atribuído a cada atributo individual de um objeto, com um valor inicial igual a 1 quando o objeto é criado pela primeira vez. versionID é incrementado em 1 sempre que um atributo individual é modificado em qualquer DC. Dessa forma, se o atributo de descrição de um determinado usuário for atualizado em relação ao valor padrão (em branco ou <não definido>) para "Departamento de Marketing", o atributo terá um versionID igual a 2. Se a descrição for modificada mais tarde para "Departamento de Vendas e Marketing", o atributo de descrição terá um versionID igual a 3 e assim por diante. Esse versionID é incluído em todas as entradas de replicação com as demais partes dos metadados que já apresentamos.
versionID também pode ser usado para reduzir ainda mais o tráfego de replicação. Por exemplo, se um administrador no DC2 tiver feito várias alterações em um único atributo (talvez ele tenha digitado incorretamente a alteração algumas vezes), de forma que o DC2 tenha gravações de origem correspondentes a versionIDs 2, 3, 4 e 5, o DC2 só replicará a gravação que corresponder à mais recente, versionID 5. Como as alterações anteriores seriam substituídas de qualquer forma, isso proporcionaria um atalho para reduzir o uso desnecessário da largura de banda.
Todas as alterações feitas no Active Directory também incluem a segunda parte adicional dos metadados usados na resolução dos conflitos, um carimbo de data e hora, como parte dos metadados de replicação, que indica quando a modificação foi feita.
O atributo do carimbo de data e hora também é usado como uma medida proativa de integridade da replicação do Active Directory. Se um DC não vir nenhuma alteração com um carimbo de data e hora relativamente recente de um determinado DC, ele começará a gerar mensagens de erro indicando que talvez tenha havido um problema com o DC em questão.
E como esses dois atributos são usados na resolução de conflitos? Examinemos cada tipo de conflito por vez.
Resolvendo alterações em propriedades conflitantes
Considere o exemplo do objeto do usuário jsmith no domínio contoso.com. Um administrador no DC1 altera a descrição de jsmith para "Marketing". Praticamente ao mesmo tempo, um administrador em DC3 altera a mesma descrição do usuário para "Vendas e Marketing". Nesse ponto, as informações de DC1 e DC3 sobre o atributo de descrição de jsmith são semelhantes às mostradas na Figura 9.
Figure 9 Alterações praticamente simultâneas
| Servidor |
Propriedade |
Valor |
VersionID |
Timestamp |
GUID de DC local |
USN local |
GUID de DC de origem |
USN de origem |
| DC1 |
Propriedade de descrição de jsmith |
"Marketing" |
2 |
2007-06-07 14:03:25 |
<GUID de DC1> |
3003 |
<GUID de DC1> |
3003 |
| DC3 |
Propriedade de descrição de jsmith |
"Vendas e Marketing" |
2 |
2007-06-07 14:04:57 |
<GUID de DC3> |
7003 |
<GUID de DC3> |
7003 |
Se o DC2 receber ambas as alterações simultaneamente, será claramente necessário determinar qual delas é a alteração "vencedora". A ordem dos desempates para a resolução dos conflitos é a seguinte:
- A modificação com versionID maior será aceita como sendo a alteração "vencedora"; a alteração "perdedora" será substituída. Nesse caso, como versionID é 2 em ambos os registros, nós precisamos passar ao segundo desempate.
- Se ambos os registros tiverem o mesmo versionID, a alteração com o maior carimbo de data e hora será aceita como sendo a alteração vencedora; a alteração perdedora será substituída. Nesse caso, como o carimbo de data e hora da gravação de origem do DC3 é posterior, a descrição de jsmith será definida como "Vendas e Marketing". Nas raras instâncias em que o versionID e o carimbo de data e hora são idênticos, nós precisamos de um terceiro e definitivo desempate:
- Se ambos os registros tiverem versionID e carimbo de data e hora iguais, a gravação originada pelo DC com o GUID de menor número será a vencedora; a gravação do GUID de maior número será substituída. Portanto, se o GUID do DC1 fosse 1234567890 e o GUID do DC3 fosse 2345678901, a gravação de origem do DC1 seria a vencedora caso o versionID e o carimbo de data e hora fossem idênticos.
Você deve estar pensando, "não seria mais lógico se o carimbo de data e hora fosse o primeiro desempate"? Não é tão simples assim como você talvez esteja pensando. Se o carimbo de data e hora fosse o primeiro desempate na resolução de conflitos do Active Directory, a única coisa que um administrador mal-intencionado precisaria fazer para propagar suas alterações seria voltar o relógio de um determinado DC para que ele sempre ganhasse em meio aos carimbos de data e hora.
Resolvendo a criação de objetos conflitantes
Nos casos em que dois objetos forem criados com o mesmo nome, o Active Directory usará os mesmos três desempates descritos na seção anterior para determinar qual deles é o objeto "vencedor". No entanto, diferentemente da seção anterior, o objeto "perdedor" não é substituído. Na verdade, o objeto perdedor é renomeado usando os caracteres CNF (para o objeto conflitante), seguidos de uma vírgula e o GUID do objeto "perdedor". Isso permite que os administradores determinem de maneira mais metódica quais objetos devem ser mantidos e quais devem ser excluídos.
Resolvendo uma transferência de objeto para um contêiner excluído
Conforme mencionei, resolver uma transferência de objeto para um contêiner excluído é um conflito relativamente raro, que só ocorre em dois cenários. Em um, um administrador em um DC cria um objeto dentro de um determinado contêiner, por exemplo, a OU Training, ao mesmo tempo em que um administrador em outro DC exclui a OU. O segundo cenário por ocorrer quando um administrador em um DC move um objeto para um contêiner ao mesmo tempo em que um administrador em outro DC exclui o contêiner.
Nesse caso, a resolução é bem simples: o Active Directory move o objeto "órfão" para um contêiner especial dentro do Active Directory projetado originalmente com essa finalidade, o contêiner LostAndFound que está fora da raiz de cada domínio do Active Directory. Para o domínio contoso.com, o contêiner LostAndFound seria encontrado no seguinte caminho LDAP: LDAP://cn=LostAndFound,dc=contoso,dc=com. Caso você não veja o contêiner LostAndFound ao abrir o snap-in Usuários e Computadores do Active Directory, basta clicar em Exibir | Recursos Avançados.
Protegendo-se da reversão do USN
Uma das situações mais graves que é possível encontrar em um ambiente do Active Directory também é a mais simples de evitar, uma vez compreendida a causa e como contorná-la. A reversão do USN é uma condição de erro que pode desligar completamente a replicação na rede, e é causada pela permissão para que um controlador de domínio permaneça offline por muito tempo e depois retorne ao serviço ou pela restauração de um controlador de domínio usando um método não suportado.
Uma causa da reversão do USN está relacionada à forma como as exclusões do objeto são processadas no ambiente de vários mestres do Active Directory. Quando um objeto é excluído de um DC, em vez de ser apenas removido imediatamente, ele é marcado para exclusão para que possa ser replicado para os demais DCs, o que os notifica da exclusão. O mais comum é que um objeto marcado para exclusão possua um atributo isDeleted definido como TRUE. Para poder reduzir o tamanho do objeto marcado para exclusão, a maioria dos valores contidos no objeto como, por exemplo, a descrição, as informações pessoais e a associação de grupo de um objeto do usuário, é removida (para obter mais informações sobre esse processo, consulte o artigo de Gil Kirkpatrick "Reanimação de Objetos de Exclusões do Active Directory", disponível online em
technetmagazine.com/issues/2007/09).
A reversão do USN pode ocorrer porque esses objetos marcados para exclusão não permanecem ociosos indefinidamente. Por padrão, eles são totalmente limpos do banco de dados do Active Directory depois de 60 ou 180 dias (dependendo da versão do Windows Server
® que você estava executando quando criou pela primeira vez o ambiente do Active Directory.) Esse período de 60 ou 180 dias é chamado de tempo de vida da marca para exclusão. Todos os controladores de domínio precisam ser capazes de replicar pelo menos uma vez durante esse período, ou eles se tornam piores do que inúteis; eles criam uma oportunidade para a reversão do USN. Basicamente, a reversão do USN ocorre quando um controlador de domínio está tão desatualizado que "perdeu" um ou mais objetos marcados para exclusão e, por isso, é incapaz de manter sua cópia do banco de dados do Active Directory totalmente atualizada em relação aos demais DCs. Para se proteger contra isso, qualquer controlador de domínio que tenha ficado offline por mais tempo do que o ciclo de vida da marca para exclusão não deve retornar ao serviço; na verdade, ele deve ser recriado do zero após a remoção dos metadados antigos do DC do Active Directory usando as etapas descritas no artigo 216498 da Base de Dados de Conhecimento Microsoft (
support.microsoft.com/kb/216498).
A segunda causa da reversão do USN ocorre quando um controlador de domínio foi restaurado usando um método não suportado, mais freqüentemente uma ferramenta de clonagem ou de geração de imagens de disco. Quando isso ocorre, o banco de dados restaurado do Active Directory não percebe que ele sumiu "em tempo", porque o método de restauração não reconhecia o Active Directory. A reversão do USN era difícil de detectar no Windows 2000 e na versão inicial do Windows Server 2003, mas o Windows Server 2003 SP1 (e o próximo Windows Server 2008) têm controles integrados para detectar quando um DC foi restaurado incorretamente. Nessas versões mais recentes do sistema operacional, um DC registrará as identificações de evento 1115, 2095, 2103 e 2110 no log de eventos dos Serviços de diretório; o texto desses eventos, bem como as etapas necessárias à recuperação da reversão do USN, podem ser encontrados no artigo 875495 da Base de Dados de Conhecimento Microsoft (
support.microsoft.com/kb/875495) referentes ao Windows Server 2003. (É possível encontrar informações sobre como lidar com a reversão do USN no Windows 2000 in no artigo 885875 da Base de Dados de Conhecimento Microsoft, disponível em
support.microsoft.com/kb/885875.)
Atualizando o modelo de vários mestres em 2008
Na próxima versão do Windows Server 2008 a Microsoft incluiu uma pequena alteração no modelo de vários mestres com a instrução do RODC (controlador de domínio somente leitura). O RODC foi projetado essencialmente para implantações de filial ou para cenários em que você não tem uma equipe de TI dedicada no local em uma determinada localização e precisa de mais etapas para assegurar a integridade de um DC em particular. Embora pudéssemos passar um artigo inteiro abordando todos os detalhes técnicos do RODC, revisemos os pontos principais com os quais você deve estar familiarizado.
Como o próprio nome indica, a cópia do banco de dados do Active Directory que reside em um RODC é somente leitura. É possível se conectar a um RODC para ler praticamente todas as informações necessárias, mas você não poderá realizar nenhuma operação de gravação em um RODC.
Em segundo lugar, um RODC não realiza nenhuma replicação de saída. Trata-se de uma mudança fundamental em relação ao modelo de replicação de vários mestres que abordamos até agora. Um RODC receberá a replicação de entrada de todos os demais DCs do Windows Server 2008 graváveis, mas não replicará nenhuma informação para os demais DCs. Isso cria uma camada adicional de segurança de forma que, mesmo se um usuário mal-intencionado pudesse modificar de alguma forma o Active Directory em relação ao RODC, essas modificações não seriam propagadas para o restante do ambiente.
E talvez o mais interessante de tudo, o RODC não replica as senhas de usuário por padrão. Quando o banco de dados do Active Directory é replicado para um RODC de um DC gravável, todos os objetos do usuário são replicados sem as informações sobre a senha. Isso ainda proporciona outra camada de segurança em um ambiente de filial, de forma que se um DC "criasse pernas e saísse andando", não haveria nenhuma informação sobre a senha residindo no disco rígido do DC. Vistas como um todo, essas alterações na idéia original da replicação do Active Directory de vários mestres criam um modelo muito mais aprimorado para proteger os controladores de domínio em filiais ou outros locais remotos.
Laura E. Hunter ganhou quatro vezes o prêmio Microsoft MVP na área de sistema de rede do Windows Server. Ela tem dez anos de experiência no setor de TI e é a autora e co-autora de vários livros, artigos e white papers relacionados ao setor, inclusive o Active Directory Cookbook (Manual do Active Directory, Segunda Edição; O’Reilly, 2006).
© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..
Poveda Cloud 