A página Especifique a Diretiva de Replicação de Senha do Assistente de Instalação dos Serviços de Domínio Active Directory é exibida quando você cria uma conta de RODC (controlador de domínio somente leitura), mas somente se você marcar a caixa de seleção Usar a instalação em modo avançado na página Assistente de Instalação dos Serviços de Domínio Active Directory do assistente.

Como funciona a Diretiva de Replicação de Senha

A PRP (Diretiva de Replicação de Senha) determina como um RODC executa o armazenamento de credenciais em cache. O cache de credenciais é o armazenamento de credenciais de usuário ou computador.

Quando os usuários ou computadores de um site servido por um RODC tentam se autenticar no domínio, por padrão o RODC não pode validar suas credenciais. O RODC encaminha a solicitação de autenticação para um controlador de domínio gravável. No entanto, pode haver um conjunto de entidades de segurança que podem precisar se autenticar em um site servido por um RODC, mesmo nos casos em que elas não têm conectividade com os controladores de domínio graváveis.

Por exemplo, pode haver um conjunto de usuários e computadores em uma filial, os quais você deseja autenticar, mesmo que não haja conectividade entre a filial e os sites que contêm os controladores de domínio graváveis. Para resolver esse problema, você pode configurar a PRP para esse RODC, permitindo que as senhas desses usuários sejam armazenadas em cache no RODC. Se as senhas de conta forem armazenadas em cache no RODC, este poderá autenticar essas contas quando a conectividade com os controladores de domínio graváveis não estiver disponível.

A PRP age como uma ACL (lista de controle de acesso). Ele determina se um RODC pode armazenar em cache as credenciais de uma conta. Após receber uma solicitação de logon de um usuário ou computador, o RODC tenta replicar as credenciais dessa conta a partir de um controlador de domínio gravável que execute o Windows Server 2008 ou o Windows Server 2008 R2. O controlador de domínio gravável refere-se à PRP para determinar se as credenciais da conta devem ser armazenadas em cache. Se a PRP permitir que a conta seja armazenada em cache, o controlador de domínio gravável replicará as credenciais dessa conta para o RODC e este as armazenará em cache. Durante os logons subsequentes dessa conta, o RODC poderá autenticar a conta referindo-se às credenciais que ele armazenou em cache. O RODC não precisa contatar o controlador de domínio gravável.

A PRP em operação

A PRP é definida por dois atributos de valores múltiplos do Active Directory, os quais contêm entidades de segurança (usuários, computadores e grupos). Cada conta de computador RODC tem estes dois atributos:

  • msDS-Reveal-OnDemandGroup, também conhecido como Lista Permitida

  • msDS-NeverRevealGroup, também conhecido como Lista Negada

Para ajudar a gerenciar a PRP, dois outros atributos relacionados à PRP são mantidos para cada RODC.

  • msDS-RevealedUsers, também conhecido como Lista Revelada

  • msDS-AuthenticatedToAccountList, também conhecido como Lista Autenticado para

O atributo msDS-Reveal-OnDemandGroup especifica quais entidades de segurança podem ter senhas armazenadas em cache em um RODC. Por padrão, esse atributo tem um valor, que é o Grupo de Replicação de Senha RODC Permitido. Como esse grupo de domínio local não possui membros por padrão, nenhuma senha de conta pode ser armazenada em cache em qualquer RODC, por padrão.

Esta seção explica como são utilizados os atributos Lista Permitida, Lista Negada, Lista de Revelados e Lista Autenticado para.

Quando um RODC faz uma solicitação para replicar a senha de um usuário, o controlador de domínio gravável do Windows Server 2008 contactado pelo RODC permite ou nega a solicitação. Para permitir ou negar a solicitação, o controlador de domínio gravável examina os valores da Lista Permitida e da Lista Negada do RODC que apresenta a solicitação.

Se o RODC estiver solicitando a senha de uma conta que esteja na Lista Permitida (em vez da Lista Negada) desse RODC, a solicitação será permitida.

A ilustração a seguir mostra como essa operação funciona.

Processo de aplicação de uma Diretiva de Replicação de Senha

A Lista Negada tem precedência sobre a Lista Permitida.

Por exemplo, suponha que uma organização tenha um grupo de segurança para administradores chamado Admins. A organização tem um site denominado S1 e um grupo de segurança denominado Emp_S1 que contém funcionários do site. A organização tem outro site denominado S2 e um grupo de segurança denominado Emp_S2 que contém funcionários do site.

O site S2 tem somente um RODC. Bob é o administrador que trabalha no site S2. Portanto, ele pertence aos grupos Emp_S2 e Admins. Quando o RODC do site S2 é instalado, os grupos de segurança listados na tabela a seguir são adicionados à PRP.

Grupo de segurança Configuração da PRP

Admins

Negado

Emp_S2

Permitido

De acordo com a diretiva especificada, as credenciais que podem ser armazenadas em cache no RODC do site S2 são somente as credenciais de membros do grupo Emp_S2 que não pertencem a Admins. As credenciais dos membros dos grupos Emp_S1 e Admins nunca serão armazenadas em cache no RODC. As credenciais dos membros dos grupos Emp_S1 e Admins nunca serão armazenadas em cache no RODC. As credenciais de Bob nunca serão armazenadas em cache no RODC.

Configurações padrão da PRP

Cada RODC tem uma PRP que define quais contas podem ter suas senhas replicadas para o RODC e as contas cuja replicação de senha para o RODC é explicitamente negada. A diretiva padrão especifica os grupos e as configurações na tabela a seguir.

Nome do grupo Configuração da PRP

Administradores

Negar

Opers. de servidores

Negar

Operadores de backup

Negar

Opers. de contas

Negar

Grupo de Replicação de Senha RODC Negado

Negar

Grupo de Replicação de Senha RODC Permitido

Permitir

Por padrão, o Grupo de Replicação de Senha RODC Negado contém estes membros da conta do domínio:

  • Editores de certificados

  • Admins. do domínio

  • Administradores de empresa

  • Controladores de domínio de empresa

  • Controladores de domínio de empresa somente leitura

  • Proprietários criadores de diretiva de grupo

  • krbtgt

  • Administradores de esquemas

Por padrão, o Grupo de Replicação de Senha RODC Permitido não contém membros.

A PRP padrão melhora a segurança de uma instalação do RODC garantindo que nenhuma senha de conta seja armazenada por padrão e que o armazenamento das senhas de contas sensíveis à segurança (como as de membros do grupo Admins. do Domínio) no RODC seja explicitamente negado.

Modificando a PRP padrão

Você pode modificar a PRP padrão ao criar uma conta para o RODC ou após a criação dessa conta. Para modificar a PRP padrão após a criação da conta RODC, clique com o botão direito do mouse na conta RODC da unidade organizacional (UO) Controladores de Domínio no snap-in Usuários e Computadores do Active Directory, clique em Propriedades e na guia Diretiva de Replicação de Senha. (Para abrir o snap-in Usuários e Computadores do Active Directory, clique em Iniciar, aponte para Ferramentas Administrativas e clique em Usuários e Computadores do Active Directory).

Para adicionar contas à PRP padrão ao criar a conta RODC, clique em Adicionar na página Especifique a Diretiva de Replicação de Senha do assistente e especifique se o armazenamento de senhas da conta no RODC deve ser permitido ou negado. Use a caixa de diálogo Selecionar Usuários, Computadores ou Grupos para selecionar as contas a serem adicionadas.

É necessário incluir as contas de usuário, computador e serviço adequadas na PRP, para permitir que o RODC atenda às solicitações de autenticação e tíquete de serviço localmente. Se as contas de computador que os usuários da filial utilizam para fazer logon na rede não forem incluídas na Lista Permitida, o RODC não poderá atender às solicitações de tíquetes de serviço localmente e dependerá do acesso a um controlador de domínio gravável para atender a essas solicitações. Se a rede de longa distância (WAN) estiver offline, isso pode causar interrupções no serviço.

A configuração Negar tem precedência sobre a configuração Permitir. Se ambas as configurações forem especificadas para determinado usuário—direta ou indiretamente, porque o usuário é membro de um grupo de segurança especificado (ou está aninhado em um grupo de segurança especificado)—a senha do usuário não poderá ser armazenada no RODC. Entretanto, é importante observar que um usuário cuja senha não pode ser armazenada no RODC ainda pode usar o RODC para fazer logon, caso a conexão WAN a um controlador de domínio gravável esteja disponível. A senha do usuário não é replicada no RODC, mas o logon pode ser autenticado pelo controlador de domínio gravável na WAN.

A tabela a seguir descreve as vantagens e desvantagens de três exemplos de configurações de uma PRP.

Exemplo Prós Contras

Nenhuma conta em cache (padrão).

Mais seguro: os usuários são autenticados por um controlador de domínio gravável e obtêm sua Diretiva de Grupo no RODC, para rápido processamento da diretiva.

Ninguém tem acesso offline: uma WAN é necessária para logon.

A maioria das contas são armazenadas em cache.

Facilidade de gerenciamento de senhas: esta opção destina-se às organizações que se preocupam mais com as melhorias na capacidade de gerenciamento do RODC e não com a segurança.

Mais senhas podem estar potencialmente expostas a um RODC.

Poucas contas estão armazenadas em cache.

Permite o acesso offline dos usuários que precisam disso, mas oferece mais segurança do que o armazenamento da maioria das contas em cache.

Este método requer uma administração mais detalhada. Pode ser necessário mapear os usuários e computadores para cada filial que tenha um RODC. Também é possível usar ferramentas, como repadmin /prp, para mover as contas que foram autenticadas em um RODC para um grupo que está na Lista Permitida, ou então usar o Identity Lifecycle Manager (ILM) para automatizar esse processo.

As seções a seguir explicam cada exemplo em mais detalhes.

Nenhuma conta em cache

Este exemplo fornece a opção mais segura. Nenhuma senha é replicada no RODC, exceto a conta de computador RODC e sua conta especial krbtgt. No entanto, a autenticação de usuário e computador depende da disponibilidade da WAN. A vantagem deste exemplo é que ele requer pouca ou nenhuma configuração administrativa adicional das configurações padrão.

Você pode optar por adicionar à Lista Negada os seus próprios grupos de usuários sensíveis à segurança. Embora nenhuma conta seja armazenada em cache por padrão, a inclusão desses grupos na Lista Negada pode protegê-los contra a inclusão acidental na Lista Permitida e o posterior armazenamento em cache de suas senhas no RODC.

Observe que a conta de administrador do RODC delegado não é adicionada automaticamente à Lista Permitida. Como prática recomendada, adicione a conta de administrador do RODC delegado à Lista Permitida, para garantir que um administrador delegado sempre possa fazer logon no RODC, independentemente de uma conexão da WAN com um controlador de domínio gravável estar disponível.

A maioria das contas estão armazenadas em cache

Este exemplo é o modo administrativo mais simples, e ele remove a dependência da disponibilidade da WAN para autenticação de usuário e computador. Aqui, você preenche a Lista Permitida para todos os RODCs com grupos que representam uma parte significativa da população de usuários e computadores. A Lista Negada não permite que os grupos de usuários sensíveis à segurança, como Admins. do Domínio, tenham suas senhas armazenadas em cache. No entanto, as senhas da maioria dos outros usuários podem ser armazenadas em cache por demanda. Você pode optar por adicionar à Lista Negada os seus próprios grupos de usuários sensíveis à segurança.

Esta configuração é mais adequada para ambientes em que a segurança física do RODC não esteja em risco. Por exemplo, você pode configurar a PRP dessa maneira para um RODC que você implantou em um local seguro, principalmente para aproveitar os seus requisitos reduzidos de replicação e administração.

Importante

Também é possível adicionar as contas de computador dos usuários à Lista Permitida, para que esses usuários possam fazer logon na filial quando a WAN estiver offline.

Poucas contas estão armazenadas em cache

Este exemplo restringe as contas que podem ser armazenadas em cache. Em geral, você define isso de forma distinta para cada RODC: cada RODC tem um conjunto diferente de contas de usuário e de computador que ele pode armazenar em cache. Este exemplo é geralmente para um conjunto de usuários que trabalham em um determinado local físico.

A vantagem deste exemplo é que um conjunto de usuários poderá fazer logon na rede e ser autenticado pelo RODC na filial se a WAN estiver offline. Ao mesmo tempo, o escopo da exposição de senhas é limitado pelo número reduzido de usuários cujas senhas podem ser armazenadas em cache.

Há uma sobrecarga administrativa associada à população da Lista Permitida e da Lista Negada neste exemplo. Não há nenhum método automatizado padrão para ler as contas da lista conhecida de entidades de segurança que foram autenticadas em um determinado RODC, e não há nenhum método padrão para preencher a Lista Permitida com essas contas. Você pode usar o comando repadmin /prp move para mover essas contas para um grupo que está na Lista Permitida ou pode usar scripts ou aplicativos como o ILM para criar um processo.

Embora seja possível adicionar contas de usuário ou de computador diretamente à Lista Permitida, em vez disso você deve criar um grupo de segurança para cada RODC, adicioná-lo à Lista Permitida e, em seguida, adicionar as contas de usuário e de computador ao grupo de segurança. Dessa maneira, você pode usar ferramentas de gerenciamento de grupo padrão, como o snap-in Usuários e Computadores do Active Directory, ou as ferramentas da linha de comando Dsadd ou Dsmod para gerenciar as contas que podem ser armazenadas em cache no RODC.

O comando repadmin /prp move requer a especificação de um grupo de segurança. Se o grupo especificado não existir, ele criará o grupo e o adicionará à Lista Permitida.

Assim como no exemplo anterior, também é necessário adicionar contas de computador adequadas à Lista Permitida.


Sumário