Sem dúvida alguma esta é uma ótima novidade no Windows Server 2008, pois simplifica estruturas de Active Directory utilizadas em ambientes de “branch office”.
Ate o Windows 2003 estes ambientes eram complexos, “de segurança frágil” e “caros”, pois o número de servidores nos sites HUB era grande (necessários para a replicação a partir dos escritórios remotos), a necessidade de permisões de “domain admins” para possiveis aplicações instaladas nestes DC’s remotos e a complexidade na administração da replicação do Active Directory eram grandes e demandavam um grupo de profissionais com grande skill no gerenciamento de grandes implementações do Active Directory.
Eu tive a oportunidade de participar de um projeto onde a Floresta possuia 9 dominios e cerca de 2200 DC’s (é isso mesmo, dois mil e duzentos domain controllers) e cuidar da replicação deste ambiente não era fácil, principalmente das localidades com links de baixa qualidade.
Quais são os principais pontos para adoção de um RODC?
Como o RODC é um DC apenas leitura, nenhuma solicitacão de modificação em um objeto é realizada nele (se lembra dos BDC’s na época do NT?) e sim encaminhada a um DC “gravável” (um dc que permite tanto a leitura quanto gravação, ou seja o já conhecido DC que utilizavamos). Com esta mudança de comportamento, o número de bridge head’s nos sites HUB tende a ser menor, pois não precisa “buscar” (toda replicação de entrada é serializada) informações nos DC’s localizados nos pontos remotos, apenas servem como origem (replicação de saida é paralela) para os RODC’s.
No quesito segurança a evolução tambem é perceptivel, pois caso uma aplicação precisasse de direitos administrativos, obrigatoriamente ela seria administradora do Active Directory, o que tornava frágil a administração do mesmo. Isso sem falar que os administradores destes sites remotos precisavam ter direitos de administrador nos servidores para suporte, comprometendo ainda mais a “estabilidade” do AD. Para finalizar com “chave de ouro” informações sensíveis como senha de usuários e a senha do serviço de Kerberos não são replicadas para estes RODC’s a menos que explicitamente configurado pelo Administrador, o que diminui a chance de um RODC comprometido ser utilizado para capturar senhas dos usuários no AD.
Bom depois destes (bons) argumentos acredito que podemos verificar como instalar e suportar estes novos DC’s, então mãos a obra.
Pré-Requisitos
Bom, são poucos os pré-requisitos para a existencia de RODC em uma floresta do Active Directory, são eles:
· Nivel funcional da floresta (e consequentemente dos dominios) definido como “Windows 2003”;
· Ao menos um DC rodando o Windows 2008 por dominio que ira manter o RODC (de preferencia o PDCE);
· Preparar a floresta para suportar o RODC. Para tal, basta executar o X:\support\adprep\adprep.exe /rodcprep (uma vez por floresta);
· Como melhores práticas, a Microsoft recomenda que a instalação de um RODC seja exclusiva em um site, ou seja nenhum outro DC (RODC ou não) de nenhum dominio seja instalado no mesmo site que possua um RODC. Isto é apenas uma melhor prática e não uma restrição técnica. Para maiores informações, consulte o documento (http://go.microsoft.com/fwlink/?LinkID=122172);
Tendo estes requisitos e recomendações atendidos, podemos partir para a instalação de RODC’s em nossa floresta, vamos la.
Instalação
A instalação de um RODC não é diferente de um DC “normal”, a única diferença é marcar a opção “Read-only domain controller (RODC)” na tela “Additional Domain Controller Options” do assistente de instalação do Active Directory.
1. Mãos a obra:
· Clicar em Start/Run e digitar dcpromo, em seguida clicar em OK;
· Após validar/instalar a role de Active Directory, a tela de instalação será mostrada, basta clicar em Next;
· Em seguida sera mostrado um aviso informando sobre uma politica de segurança nova no Windows 2008, leia com atenção para verificar se o seu ambiente pode ser impactado e em seguida clique em Next;
· Na tela “Choose a Deployment Configuration” selecione “Existing forest” e “Add a domain controller to an existing domain” e clique em Next;
· Informe o nome de um dominio na floresta em que este novo DC será configurado e informe as credenciais necessárias, em seguida clique em Next;
· Selecione o dominio que este novo DC fará parte e clique em Next;
· Caso o schema não tenha sido preparado para suportar RODC voce verá uma mensagem “You will not be able to install a read-only domain controller in this domain because adprep /rodcprep was not yet run, caso contrario esta mensagem não sera mostrada;
· Informe o site em que este DC deverá ser criado, ou marque a opção “Use the site that corresponds to the IP address of this computer” para que esta definição seja feita mediante informações de sub-net no AD;
· Na tela “Additional Domain Controller Options”, selecione as opções DNS Server, Global catalog, “Read-only domain controller (RODC)” e clique em Next;
· Na tela “Delegation of RODC Installation and Administration” voce pode definir o grupo ou usuário que terá permissões de administrador no servidor (não no Active Directory). Esta configuração pode ser alterada posteriormente através do ”Active Directory Users and Computers”, clicando na conta do DC com o botao direito, propriedades na TAB “Managed By”;
· Informe o caminho para a base, logs e sysvol e clique em Next;
· Informe a senha para acesso ao “Directory Services Restore mode” e clique em Next;
· Valide na tela “Summary” se todas as informações estão corretas e clique em Next. Caso queira salvar estas informações para criação não assistida (unattend) de outro DC no mesmo dominio, basta clicar no botão “Export settings” e informar um nome para o arquivo;
· Finalmente dará inicio a configuração do Active Directory e em seguida será solicitado que o mesmo seja reiniciado.
Pronto a instalação do RODC esta feita, agora vamos mostrar como fazer uma “pré-promoção” de um RODC utilizando os novos recursos do Windows 2008.
No branch office guide do Windows Server 2003 existe um capitulo mostrando como construir um staging-site, ou seja uma “fábrica de DC’s”, pois é, dai que saem os DC’s já promovidos que serão instalados nos sites remotos. O problema é que nem sempre os DC’s são ligados dentro do periodo de “Tombstone Lifetime” o que pode causar um enorme transtorno para a replicação do AD. Informações sobre tombstone em (http://jsathler.spaces.live.com/blog/cns!40CBF5E035DEF7B3!146.entry).
Com o Windows 2008 é possivel delegar uma fase da instalação do Active Directory em um RODC para o administrador do site remoto sem que o mesmo tenha permissão de administrador no AD . Isso é sensacional não é? Vamos ver como faze-lo.
1. A partir de um DC Windows 2008:
· Abra o mmc ”Active Directory Users and Computers”, expanda a OU “Domain controllers” e com o botão direito selecione a opção “Pre-create Read-only Domain Controller account...”;
· A tela de instalação do Active Directory será mostrada, basta clicar em Next;
· Em seguida sera mostrado um aviso informando sobre uma politica de segurança nova no Windows 2008, leia com atenção para verificar se o seu ambiente pode ser impactado e em seguida clique em Next;
· Informe uma credencial que possua permissão de administrador no AD, em seguida clique em Next;
· Informe o nome do novo RODC e clique em Next. Atenção o nome informado não pode ser um nome de computador já existente no Active Directory;
· Informe o site em que este DC deverá ser criado, em seguida clique em Next;
· Na tela “Additional Domain Controller Options”, selecione as opções DNS Server, Global catalog, e clique em Next. Veja que a opção “Read-only domain controller (RODC)” já esta marcada e não pode ser desmarcada;
· Na tela “Delegation of RODC Installation and Administration” informe o grupo ou usuário que terá permissões para concluir a segunda fase desta instalação. Caso nenhuma conta seja informada neste momento, apenas usuarios com perfil de administrador no AD conseguirá concluir a segunda fase da instalação. Esta informação pode ser alterada posteriormente através do ”Active Directory Users and Computers”, clicando na conta do DC com o botao direito, propriedades na TAB “Managed By”;
· Valide na tela “Summary” se todas as informações estão corretas e clique em Next. Caso queira salvar estas informações para criação não assistida (unattend) de outro DC no mesmo dominio, basta clicar no botão “Export settings” e informar um nome para o arquivo;
· Pronto a primeira fase esta finalizada.
2. A partir do RODC (a ser feito pelo administrador do site remoto)
· Após iniciar o servidor que será o RODC, basta clicar em Start/Run e digitar “dcpromo /UseExistingAccount:Attach”;
· A tela de instalação do Active Directory será mostrada, basta clicar em Next;
· Informe o nome de um dominio na floresta em que este novo DC será configurado e informe as credenciais necessárias, em seguida clique em Next. Esta credencial pode ser de um administrador do AD ou de um usuário que recebeu a delegação na fase 01;
· Caso o nome do novo RODC coincida com o nome criado na fase 1, ele será mostrado agora. Selecione a conta criada e clique em Next. Caso nenhum nome coincida, será necesário abortar o programa de instalação do AD e fazer os passos mostrados anteriormente na fase 1;
· Informe o caminho para a base, logs e sysvol e clique em Next;
· Informe a senha para acesso ao “Directory Services Restore mode” e clique em Next;
· Valide na tela “Summary” se todas as informações estão corretas e clique em Next. Caso queira salvar estas informações para criação não assistida (unattend) de outro DC no mesmo dominio, basta clicar no botão “Export settings” e informar um nome para o arquivo;
· Finalmente dará inicio a configuração do Active Directory e em seguida será solicitado que o mesmo seja reiniciado.
Utilizando este recurso de “staging” evitamos problemas de replicação no AD durante o transporte deste novo DC ate o site remoto.
Politica de replicação de senha
Agora que temos um (ou vários, depende da sua estrutura) RODC instalado, vamos verificar algumas atividades que podem (e a principio precisam) ser realizadas para garantir o perfeito funcionamento do site remoto.
O primeiro deles é definir quais credenciais poderão ser replicadas para o RODC. Vamos entender melhor isso.
O RODC não recebe durante a replicação nenhuma credencial de usuário/computador, portanto durante o processo de logon os usuários de um site remoto que autenticam no RODC será “encaminhado” para validação de um DC que possua as credenciais do usuário e do computador que ele esta utilizando para o logon, após esta validação o acesso é ou não liberado para o usuário e um ticket Kerberos é emitido para o usuário/computador. Ai vem a pergunta “mas e se o link estiver indisponível?”, a resposta é simples, o usuário não conseguirá o acesso.
Para permitir que um RODC faça cache de uma credencial é necesário informar a ele quais usuários/grupos/computadores podem ter suas credenciais armazenadas localmente e isso é realizado através da PRP – Password Replication Policy.
Como definir esta politica de replicação?
Existem duas formas de fazer esta configuração. A primeira delas é adicionando os usuários/grupos ou computadores no grupo “Allowed RODC Password Replication Group”, porem qualquer RODC poderá armazenar as credenciais e não um RODC específico. Isso ocorre porque por padrão todos os membros deste grupo podem ter suas credenciais armazenadas por um RODC.
A segunda delas é através do mmc “Active Directory Users and Computers”, vejamos:
· Através do mmc “Active Directory Users and Computers”, expandir a OU “Domain Controllers”, obter as propriedades da conta do RODC e finalmente abrir a TAB “Password Replication Policy”;
· Clicar em ADD, selecionar a politica requerida (Permitir ou Negar) e adicionar um grupo que contenha os objetos que podem (ou não, caso a politica escolhida tenha sido Negar) ter suas senhas armazenadas por um RODC. É possivel tambem incluir um objetos de usuário/computador ao invés do grupo;
· Pronto, a partir de agora quando os membros deste grupo fizer o logon, as credenciais serão armazenadas no RODC que recebeu a solicitação de logon.
É possivel visualizar quais objetos tiveram suas credenciais armazenadas no RODC ou os usuários que já fizeram logon em um RODC e pela PRP não puderam ter suas credenciais armazenadas localmente.
· Através do mmc “Active Directory Users and Computers”, expandir a OU “Domain Controllers”, obter as propriedades da conta do RODC e finalmente abrir a TAB “Password Replication Policy”;
· Clicar no botão Advanced e verificar as TAB’s “Policy Usage”.
Outra visualização interessante é a possibilidade de verificar se as credenciais de um usuário pode ou não ser armazenada no RODC selecionado.
· Através do mmc “Active Directory Users and Computers”, expandir a OU “Domain Controllers”, obter as propriedades da conta do RODC e finalmente abrir a TAB “Password Replication Policy”;
· Clicar no botão Advanced e na TAB’s “Resultant Policy” verificar qual é a politica efetiva para um usuário.
Para finalizar vamos ver uma opção interessante no gerenciamento de um RODC.
O que fazer se diagnosticarmos que um RODC foi comprometido? (sabemos que nem todos os escritórios possuem segurança fisica adequada), basta através do mmc “Active Directory Users and Computers”, expandir a OU “Domain Controllers”, selecionar a conta do RODC e clicar em delete, o assistente de exclusão irá perguntar se voce deseja resetar a senha de todos os usuários/computadores que tiveram suas credenciais armazenadas no RODC e ainda fará o metadata cleanup para voce. Demais isso não é?
Administradores locais
Outro recurso interessante é a possibilidade de definir administradores locais no RODC e que não tenham permissão de administrador no Active Directory.
Esta “delegação” pode ser feita de duas formas, através da opção “Managed By” nas propriedades da conta do RODC (ja mencionado anteriormente) ou através do ntdsutil em cada RODC.
Vamos mostrar o procedimento através do ntdsutil.
· No RODC abra o ntdsutil e digite “local roles”;
· Para saber quais sao as locais roles permitidas (na verdade quais são os grupos que voce pode inserir o usuário) basta digitar “list roles”;
· Para inserir um usuário em uma role, digite “add dominio\usuario role”. Ex. “add jsathler\jsathler administrators”;
· Para remover um usuário de uma role digite: “remove dominio\usuario role”. Ex. “remove jsathler\jsathler administrators”;
Todo direito concedido através do ntdsutil é gravado em uma chave no registro que pode ser editada manualmente. Alias caso o RODC seja despromovido, estas chaves não são excluidas, o que pode causar um problema de segurança posteriormente caso ele seja novamente promovido a RODC.
É isso ai pessoal, ate a próxima.
Juliano Sathler com mais de 8 anos de experiência na área de TI. Trabalha atualmente com suporte/projetos de Exchange Server e Active Directory em uma multinacional no interior de SP. Possui atualmente as certificações MCSA/MCSE +M +S em Windows 2000 e 2003, MCTS/MCITP em Exchange 2007 e MCT.
**Este artigo foi escrito por um membro da comunidade técnica, a Microsoft não oferece quaisquer garantias sobre o conteúdo aqui descrito.