Mês: setembro 2010

Por dentro do Active Directory

Arquitetura do Data Store(armazenamento de dados) do Active Directory

 

O armazenamento de dados do Active Directory consiste de vários componentes que juntos fornecem serviço de diretório para clientes e outros servidores de diretório. Esses componentes incluem três serviços, quatro interfaces e um arquivo de banco de dados onde os dados são armazenados.

A figura abaixo ilustra a arquitetura do armazenamento de dados do Active Directory

clip_image001

A tabela abaixo descreve cada componente

Componente

Descrição

Interfaces: Lightweight Directory Access Protocol (LDAP), replication (REPL) and domain controller management interface, Messaging API (MAPI), Security Accounts Manager (SAM))

As interfaces de armazenamento de dados fornecem um caminho para clientes e outros servidores de diretório a acessarem os dados do diretório. Ou seja, é através das interfaces que se obtém acesso aos objetos do Active Directory.

Directory System Agent (DSA) (Ntdsa.dll)

(Agente do Serviço de Diretório)

O DSA, o qual é executado como Ntds.dll em cada Controlador de domínio, fornece as interfaces através das quais os clientes e outros servidores de diretório ganham acesso ao banco de dados do diretório.

Database layer (Camada de banco de dados)

A camada de banco de dados é uma API que reside em Ntds.dll e fornece uma interface entre a aplicação e o banco de dados de diretório, este mecanismo protege o banco de dados ser acessado diretamente por aplicações.

Extensible Storage Engine (ESE) (Esent.dll)

(Mecanismo de armazenamento Extensível)

O ESE, o qual é executado como Esent.dll, gerencia as tabelas de registros – cada um com uma ou mais colunas – Essas tabelas compõem o banco de dados de diretório.

Database files (arquivos de banco de dados)

Os dados do diretório são armazenados em um único arquivo chamado Ntds.dit. Adicionalmente são utilizados arquivos de log, os quais são temporariamente utilizados para escrita de transações não comitadas.

Protocolos utilizados pelo Data Store(Armazenamento de dados)

O principal protocolo utilizado pelo Active Directory é o LDAP (Lightweight Directory Access Protocol),o qual é executado sobre a pilha TCP/IP. Adicionalmente o Armazenamento de usa RPC(Chamada de procedimento Remoto) para tarefas como:MAPI, replicação e gerenciamento do controlador de domínio. O protocolo SMTP é suportado para replicação entre controladores de domínio onde não existe uma conexão constante, embora não seja recomendável essa arquitetura.

A figura abaixo ilustra os protocolos e interfaces que são usados pelo Armazenamento de dados(Data Store).

Protocolos do Data Store

clip_image002

Protocolo

Descrição

LDAP

O LDAP é um protocolo de serviço de diretório que especifica a comunicação com o diretório. Ele é executado diretamente sobre a pilha TCP/IP, e também pode ser executado sobre UDP. Clientes LDAP podem criar,atualizar,deletar e consultar informações que são armazenadas no diretório que é acessado através da porta TCP 389. O Active Directory suporta LDAP v2 e LDAP v3, os quais são padrões de indústria e pode ser usado como qualquer serviço de diretório que implementa o protocolo LDAP. Historicamente o LDAP é uma simplificação (“lightweight” leve) da versão do DAP, que é um protocolo utilizado para acessar diretórios X.500.

A seguir as características chaves do LDAP:

· O protocolo roda diretamente sobre TCP para conexões orientadas(recebimento de dados é confirmado) e sobre UDP para conexões sem confirmação.

· A maioria dos elementos de dados podem ser codificados como uma cadeia de caracteres, por exemplo distinguished names.

· Referencias para outros servidores podem ser retornadas para os clientes.

· O mecanismo SASL(Simple Authentication and Security Layer) pode ser utilizado com o LDAP para fornececer segurança de acesso ao diretório.

· Valores de atributos e distinguished names podem ser traduzidos através do uso de conjunto de caracteres ISO 10646.

· O protocolo pode ser estendido para o suporte a novas operações.

· O esquema do diretório é publicado através de um atributo no directory root object (rootDSE) para ser usado pelos clientes.

RPC

O Data Store usa o RPC para replicação e gerenciamento de controladores de domínio, comunicações MAPI e operações relacionadas ao SAM. RPC é um poderoso,robusto e eficiente mecanismo de comunicação entre processos(IPC), que possibilita a troca de dados e chamada de funcionalidades entre diferentes processos. Os processos podem estar no mesmo computador, em uma rede local ou até mesmo na internet.

SMTP

O Data Store pode utilizar SMTP para replicação entre controladores de domínio que não possuem uma comunicação permanente. Embora não seja uma prática recomendada.

Interfaces do Data Store

Como mostrado na figura anterior “Arquitetura do Data Store”, clientes de rede outros servidores de diretório obtém acesso ao diretório através de uma das interfaces que são descritas na tabela abaixo.

Interface

Description

LDAP

LDAP é a principal interface do Data Store. Clientes de diretório usam LDAP v3 para conectar ao DSA através da interface LDAP. A interface LDAP é implementada através da DLL Wldap32.dll. LDAP v3 é compatível com LDAP v2.

REPL

A principal funcionalidade desta interface é prover todos os recursos necessários para replicação de dados entre diretórios.

MAPI

Clientes de messageria podem ter acesso ao serviço de diretório através da interface MAPI.

SAM

SAM é uma interface proprietária para clientes Windows NT 4.0 ou anterior se conectarem ao DSA. Esses clientes usam APIs de rede do Windows NT 4.0 para conectar ao DSA, replicações com BDCs também usam esta interface.

Estrutura lógica do Data Store

O Active Directory armazena os dados de acordo com o modelo de informações do LDAP. Adicionalmente os dados são organizados em partições lógicas que podem sem replicadas independentemente, sendo assim, um controlador de domínio precisará somente armazenar dados referentes ao domínio no qual ele reside.

Modelo de informações do LDAP

O modelo de informações do LDAP é baseado em entradas, as quais contêm informações referentes a algum objeto, por exemplo, uma pessoa ou computador.

A implementação do modelo de informação é chamada de schema, o qual é um conjunto de classes e atributos que definem a estrutura e conteúdo de cada objeto que pode ser criado no diretório.

Árvore de Diretório

O Active Directory organiza os seus objetos em uma hierarquia de estrutura em árvore. A estrutura da hierarquia é derivada do schema, e o serviço de diretório implementa essa hierarquia.

Cada objeto no Active Directory tem exatamente um pai, e a referencia ao objeto pai é armazenada com o objeto. Como um resultado dessa referencia ao objeto pai, a hierarquia de objetos que é gerenciada pelo Active Directory forma a estrutura em árvore. Os objetos que populam o Active Directory criam essa estrutura de acordo com as regras do schema.

As restrições de arquitetura e requisitos da árvore de diretório são listadas abaixo:

· Objetos do tipo Domain, os quais são containers, podem somente serem filhos de outros objetos domain. Por exemplo, um domínio não pode ser filho de uma Unidade Organizacional.

· O objeto raiz da árvore de diretório é chamado de DSA-specifc Entry(DSE), ou rootDSE. O rootDSE não tem nome hierárquico ou classe schema, más ele tem um conjunto de atributos que identificam o conteúdo do controlador de domínio no qual ele resido. Sendo assim, o rootDSE constitui a raiz da árvore de diretório da perspectiva do controlador de domínio no qual ele está.

· Abaixo do rootDSE, cada diretório tem um domínio raiz, o qual é o primeiro que é criado na floresta. Este domínio sempre tem um contêiner filho chamado Configuration, o qual contém os dados de configuração da floresta.

clip_image004

Tipo de dado

Descrição

Dados do domínio

· Dados específicos do domino são armazenados na partição de domínio.

· Uma cópia completa e gravável é replicada para cada controlador de domínio no domínio.

Dados da floresta

· Dados da floresta são armazenados em duas partições: partição de configuração e partição de schema.

· Uma cópia completa e gravável da partição de configuração é replicada para cada controlador de domínio na floresta.

· Uma cópia somente leitura da partição de schema é replicada para cada controlador de domínio na floresta. A partição de schema é gravável somente no controlador de domínio que tem a função de mestre de operação de schema.

· Além de uma cópia completa gravável de um único domínio (o domínio para o qual o controlador de domínio é autoritativo), controladores de domínio especiais que são designados como servidores de catálogo global, também armazenam cópias parciais somente leitura de todas as outras partições de diretório de domínio da floresta. (As cópias somente leitura no catálogo global são "parciais" porque eles armazenam apenas alguns dos atributos de cada objeto). Um controlador de domínio que é um servidor de catálogo global pode ser consultado para encontrar qualquer objeto na floresta.

Dados de aplicação

· Aplicações podem utilizar a partição de diretório para armazenar dados específicos de seu interesse.

Estrutura física do Data Store

A estrutura física do data store consiste do arquivo de banco de dados do Active Directory (Ntds.dit) e seus arquivos de log associados bem como os arquivos temporários. Os dados contidos no arquivo de banco de dados são classificados como estáticos e dinâmicos.

Data Store Physical Structure

clip_image005

Componente

Descrição

NTDS.DIT

O arquivo de banco de dados no qual todos os dados do diretório são armazenados. Este arquivo consiste de três tabelas internas: A Data Table, Link Table e Security Descriptor (SD)

EDB.LOG

O arquivo de log no qual as transações de diretórios são escritas antes de serem comitadas (gravadas) no arquivo de banco de dados.

EDB.CHK

O arquivo que é usado para controlar quais transações no arquivo de log já foram gravadas no banco de dados.

RES1.LOG, RES2.LOG

Arquivos que são usados como espaço reserve para arquivos de log adicionais, caso EDB.LOG venha tornar-se cheio.

Banco de dados do Active Directory

Dados do Active Directory são armazenados no arquivo Ntds.dit. O Banco de dados do Active Directory (Ntds.dit), contém três tabelas internas: Data Table, Link Table e SD Table.

Duas cópias do Ntds.dit estão presentes em locais separados em um controlador de domínio, systemrootNTDS and systemrootSystem32:

· systemrootNTDSNtds.dit armazena o banco de dados que é usado pelo controlador de domínio. Ele contém os valores para o domínio e para a floresta.

· systemrootSystem32Ntds.dit contém uma cópia de distribuição do diretório padrão, o qual é usado na instalação do Active Directory.

Data Table

O data table contém todas as informações do Active Directory: Usuários, computadores,grupos, dados de aplicação, e qualquer dado que tenha sido armazenado após a sua instalação.

Link Table

O link table contém dados que representam links de atributos, os quais contém valores que referem a outros objetos no Active Directory. Por exemplo o atributo MemberOf do objeto usuário, este atributo contém valores que referenciam grupos dos quais o usuário é membro.

SD Table

O SD Table contém dados que representam descritores de segurança herdados para cada objeto.

clip_image007

Arquivos de log

Arquivo de log

Descrição

Edb.log

Este arquivo armazena as transações do diretório antes delas serem escritas no arquivo Ntds.dit. este arquivo tem um tamanho fixo de 10MB

Edb00001.log, Edb00002.log, Edb00003.log, and so on

O Active Directory cria arquivos de log adicionais quando necessário, ou seja, quando o arquivo de log padrão tornar-se cheio, cada novo arquivo de log tem um tamanho fixo de 10MB.

Edb.chk

Este arquivo mantém o controle sobre quais transações no arquivo de log já foram comitadas(gravadas) no arquivo Ntds.dit

Espaço mínimo requerido

· Ntds.dit e arquivos de log em partições separadas: Mínimo de 500 MB livre em cada partição.

· Ntds.dit e arquivos de log na mesma partição: Mínimo de 1 GB livre na partição.

Objetos e capacidade

Não existe um limite prático para o número máximo de objetos que podem ser armazenados no Active Directory. Um banco de dados do Active Directory foi testado com até 60 milhões de objetos. O teste revelou o mesmo desempenho de um logon em um diretório com 10 mil objetos, 100 mil objetos e 1 milhão de objetos; isto é, o serviço de diretório mostrou-se altamente escalável.

Observações

· Em um ambiente de domínio misto, onde existe BDCs do Windows NT 4.0, o limite recomendado de objetos é de 40 mil por domínio. Este limite é devido à capacidade de armazenamento do banco de dados SAM.

Dados do Active Directory

 

As principais características dos dados armazenados por qualquer serviço de diretório são o seu tamanho e o tempo de replicação. Um serviço de diretório deve armazenar objetos que não são tão grandes que impeçam a replicação. Portanto, grandes conjuntos de dados não estruturados não são adequados para o armazenamento do Active Directory. Dados de domínio e dados de configuração são geralmente estáticos por natureza.

 

Anúncios

Guia para a replicação do Active Directory.

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.

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.

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.

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.

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.

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.

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:
  1. 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.
  2. 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:
  3. 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..

 
 

Definindo um DC como Global Catalog

O Global Catalog é um repositório de dados distribuído que contain parte de cada objeto de cada domínio de uma floresta do Active Directory. O Global Catalog é armazenada em cada DC que está definido como Global Catalog. Todas consultas são feitas nos Global Catalog porque eles são rápidos porque têm as informações de todos os domínios de forma simplicada (poucos atributos de cada objeto).

Um Domain Controller pode ser um Global Catalog, mas um Global Catalog sempre é um Domain Controller.

Para verificamos os FSMOs  devemos efetuar os seguintes passos:

  1. Ir em Start e depois em Run
  2. Digitar dssite.msc
  3. Expandir Sites
  4. Expandir <Site> (o Site é definido pelo Administrador)
  5. Expandir <Servidor>
  6. Botão direito sobre NTDS Settings e clicar em Properties
  7. Na guia General definimos se a máquina é ou não um Global Catalog, caso o checkbox Global Catalog esteja marcado ela é, caso esteja desmarcado ela é apenas um Domain Controller.

 

Efetuando BAckup do Serviço DNS

 

Todos sabemos de que através do backup do system state efetuamos backup do dns também, mais existem casos de que necessitamos efetuar um backup somente do Serviço de DNS, até mesmo para melhor recuperação dos dados.

Para isso estou postando uma forma rápida de backup do Serviço de DNS, testada em ambiente 2003.

 

Segue passos a serem executados para Backup

1 – Interrrompa o serviço do DNS.

2 – inicie o Regedit e vá para HKEY_LOCAL_MACHINESystemCurrentControlSetServicesDNS.

3 – Dê um clique com o botão do mouse sogre a pasta DNS e selecione Export. Atribua um nome com BKPDNS1 e salve em um lugar seguro.

4 – Agora vá para HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionDNS Server.

5 – Dê um clique com o botão direito do mouse sobre a pasta DNS Server e selecione Export. Chame o arquivo de BKPDNS2 e salve em um lugar seguro.

Você acaba de criar dois arquivos de Registro chamados BKPDNS1.reg e BKPDNS2.reg.

6 – Examine o diretório WindowsSystem32DNS e copie todos os arquivos com a extensão .dns para o mesmo local onde você armazenou os arquivos .reg.

Agora você tem um backup do seu DNS.

Aumentar o nível funcional do domínio

Aplica-se a: Windows Server 2008, Windows Server 2008 R2

Ao instalar o AD DS (Serviços de Domínio Active Directory) em um servidor executando o Windows Server 2008 R2, um conjunto de recursos básicos do Active Directory é ativado por padrão. Além dos recursos básicos do Active Directory em controladores de domínio individuais, há novos recursos de domínio e de floresta quando todos os controladores em um domínio ou uma floresta executam o Windows Server 2008 R2.

Para que os novos recursos de domínio sejam ativados, todos os controladores de domínio no domínio devem estar executando o Windows Server 2008 R2, e o nível funcional do domínio deve ser aumentado para o Windows Server 2008 R2.

Ser membro do grupo Admins. do Domínio ou Administrador corporativo, ou equivalente, é o mínimo necessário para concluir este procedimento. Revise os detalhes sobre o uso de contas e associações a grupos apropriadas em http://go.microsoft.com/fwlink/?LinkId=83477.

Para aumentar o nível funcional do domínio

1.     Abra Domínios e Relações de Confiança do Active Directory. Para abrir Domínios e Relações de Confiança do Active Directory, clique em Iniciar, Ferramentas Administrativas e Domínios e Relações de Confiança do Active Directory.

2.     Na árvore de console, clique com o botão direito do mouse no domínio para o qual você deseja aumentar o nível funcional e clique em Aumentar Nível Funcional do Domínio.

3.     Em Selecione um nível funcional de domínio disponível, siga um destes procedimentos:

·         Para aumentar o nível funcional de domínio para o Windows Server 2008, clique em Windows Server 2008 e em Aumentar.

·         Para aumentar o nível funcional de domínio para o Windows Server 2008 R2, clique em Windows Server 2008 R2 e em Aumentar.

Cuidado

Não aumente o nível funcional de domínio para uma versão mais recente (como o Windows Server 2008 ou o Windows Server 2008 R2) se houver algum controlador de domínio executando uma versão anterior do Windows Server.

Importante

Após a definição do nível funcional de domínio para um valor determinado, não será possível reverter ou diminuir o nível funcional de domínio, com uma exceção: ao elevar o nível funcional de domínio para Windows Server 2008 R2 e se o nível funcional de floresta for Windows Server 2008 ou inferior, você terá a opção de reverter o nível funcional de domínio para Windows Server 2008. Você pode diminuir o nível funcional de domínio apenas de Windows Server 2008 R2 para Windows Server 2008. Se o nível funcional de domínio estiver definido como Windows Server 2008 R2, ele não poderá ser revertido, por exemplo, para Windows Server 2003.

 

Considerações adicionais

 

  • Também é possível aumentar o nível funcional de domínio clicando com o botão direito do mouse em um domínio no snap-in Usuários e Computadores do Active Directory e em Aumentar Nível Funcional do Domínio.
  • O nível funcional de domínio atual é exibido em Nível funcional atual do domínio, na caixa de diálogo Aumentar nível funcional do domínio.
  • Para executar este procedimento, você deve ser um membro do grupo Admins. do Domínio ou Administradores Corporativos no AD DS, ou a autoridade adequada deve ter sido delegada a você. Como uma prática recomendada de segurança, é aconselhável usar Executar como para executá-lo. Para obter mais informações, pesquise "usando executar como" na Ajuda e Suporte.
  • Também é possível executar a tarefa deste procedimento usando o módulo Active Directory para o Windows PowerShell™. Para abrir o Módulo Active Directory, clique em Iniciar, clique em Ferramentas Administrativas e em Módulo Active Directory para o Windows PowerShell. Para obter mais informações, consulte (em inglês) Raise the Domain Functional Level (http://go.microsoft.com/fwlink/?LinkId=137825). Para obter mais informações sobre o Windows PowerShell, consulte (em inglês) Windows PowerShell (http://go.microsoft.com/fwlink/?LinkID=102372).

 

Atualizar permissões de Diretiva de Grupo

Aplica-se a: Windows Server 2008, Windows Server 2008 R2

Modelagem de Diretiva de Grupo é um recurso do GMPM (Console de Gerenciamento de Diretiva de Grupo) que simula o conjunto de diretivas resultante para determinada configuração. A simulação é realizada por um serviço executado nos controladores de domínio baseado em Windows Server 2008. Para realizar a simulação nos domínios, o serviço precisa ter acesso de leitura a todos os GPOs (objetos de Diretiva de Grupo) da floresta.

 

Observação

O procedimento dessa seção só será necessário se você estiver atualizando os domínios do Windows 2000 Active Directory para Windows Server 2008. Se você estiver atualizando os domínios do Windows Server 2003 Active Directory para Windows Server 2008, o grupo Controladores de Domínio de Empresa automaticamente terá acesso de leitura a todos os GPOs recém-criados e a todos os GPOs criados antes da atualização.

 

Em um domínio do Windows Server 2008 que foi atualizado de Windows Server 2003 ou foi instalado recentemente, o grupo Controladores de Domínio de Empresa automaticamente terá acesso de leitura a todos os GPOs recém-criados. Isso garante que o serviço possa ler todos os GPOs da floresta.

No entanto, se o domínio do Windows Server 2008 tiver sido atualizado de Windows 2000, o grupo Controladores de Domínio de Empresa não terá acesso de leitura aos GPOs existentes criados antes da atualização. O GPMC faz essa detecção quando você clica em um GPO e, em seguida, ele notifica o usuário que o grupo Controladores de Domínio de Empresa não tem acesso de leitura a todos os GPOs desse domínio. Para solucionar esse problema, use o script de amostra chamado GrantPermissionOnAllGPOs.wsf que é fornecido com o GPMC. Esse script atualizará as permissões em todos os GPOs do domínio. Para fazer download de scripts de amostra do GPMC (inclusive do GrantPermissionOnAllGPOs.wsf), consulte Scripts de amostra do Console de Gerenciamento de Diretiva de Grupo (http://go.microsoft.com/fwlink/?LinkId=106342) (essa página pode estar em inglês). Após a conclusão do download, será criada a pasta %programfiles%Microsoft Group PolicyGPMC Sample Scripts.

O mínimo necessário para concluir este procedimento é ser membro do grupo Admins. do Domínio ou equivalente. Revise os detalhes sobre o uso de contas e associações a grupos apropriadas em http://go.microsoft.com/fwlink/?LinkId=83477 (a página pode estar em inglês).

Para atualizar as permissões em todos os GPOs de um domínio

1.     No prompt de comando, digite o seguinte e pressione ENTER:

cd /d %programfiles%Microsoft Group PolicyGPMC Sample Scripts

2.     Digite o seguinte comando e pressione ENTER:

GrantPermissionOnAllGPOs.wsf “Enterprise Domain Controllers” /permission:read /domain:DNSDomainName /Replace

Use a opção Replace para remover as permissões existentes do grupo ou do usuário antes de fazer a alteração. Se já tiver sido concedido a um grupo ou usuário um tipo de permissão superior ao novo tipo de permissão e você não especificar Replace, nenhuma alteração será feita.

 

Desabilitar o UAC usando Group Policy

O Windows Vista tanto como o Windows 7 usa um recurso chamado User Account Control, ou UAC limita os privilégios das contas de usuários regulares, aqueles não administrativos. O UAC garante que todas as contas de usuários que não fazem parte do grupo de administradores locais executem sem privilégios administrativos. Esse recurso é ativado por padrão, porém em algumas situações pode ser necessário desativá-lo.

 
Exitem outras maneiras de ser desativado, todas estão contidas no artigo anterior (Inglês).
 
Um deste método é usando a Diretiva de Grupo (Group Policy).

 
1.Clique em Iniciar e clique em Executar.
2.Type gpedit.msc e clique em OK. Isto irá abrir o Group Policy Editor.
3.Navegue para Configuração do Computador | Configurações de Segurança | | Configurações do Windows Opções de segurança | Políticas Locais.
4.In o painel de detalhes, localize o usuário políticas de controle de acesso.
5.Right clique em cada uma das seguintes políticas e alterar o valor conforme indicado abaixo:
1.User Account Control: Detectar instalações de aplicativos e alerta para a elevação – Deficientes
2.User Account Control: Comportamento do prompt de elevação para usuários padrão – No prompt
3.User Account Control: Executar todos os administradores em Admin Aprovação Mode – Deficientes

Feche a janela Group Policy Editor.

Você pode ativar o UAC novamente, alterando as políticas acima para seus valores padrão