Controladores de domínio do Windows Server 2008 R2: Planeje cuidadosamente os RODCs
Paul Yu
Quando segurança física está faltando, é essencial aumentar o foco na segurança de dados. O Windows Server 2008 e o R2 fornecem algumas maneiras de fazer isso que parecem serem feitas para os ambientes como escritórios remotos onde a segurança física pode não ser forte. Os controladores de domínio somente leitura (RODCs) são um novo recurso dos Serviços de Domínio do Active Directory (AD DS) nos sistemas do Windows Server. Eles representam uma mudança fundamental no modo típico que você utiliza os controladores de domínio (DCs).
Como muitas das novas capacidades dos RODCs impactam aspectos importantes do processo de implantação e design, é importante entender como você aproveitá-los em sua empresa. Há também considerações de planejamento e design que você deve levar em conta antes de introduzi-los no seu ambiente. Os RODCs são DCs que hospedam cópias completas de somente leitura de partições de banco de dados do Active Directory, uma cópia somente leitura de SYSVOL e um conjunto de atributos filtrados (FAS) que restringe a replicação interna de certos dados do aplicativo de DCs graváveis.
Por padrão, os RODCs não armazenam seletivamente as credenciais de contas de usuário e do computador, mas você pode configurá-lo para que faça essa tarefa. Só isso em geral justifica o uso de RODCs em escritórios remotos ou redes de perímetro com falta de segurança física geralmente encontrada em intranets de datacenter. Os RODCs fornecem também outros recursos menos conhecidos, como uma conta especial de concessão de tíquete Kerberos que endereça ataques baseados em tíquetes associados ao próprio RODC o qual se torna comprometido.
Embora a preocupação com segurança seja o motivo mais comum para implantar RODCs, eles fornecem também uma várias outras vantagens, como capacidade de gerenciamento e escalabilidade. Em termos gerais, os RODCs foram feitos para ambientes que exigem autenticação local e autorização, mas falta a segurança física para utilizar com segurança os DCs graváveis. Portanto, os RODCs são comuns em rede de perímetro de datacenter ou locais de escritórios.
Um exemplo de bom uso de RODCs é um datacenter que exige AD DS, mas devido às restrições de segurança não pode aproveitar a floresta corporativa de AD DS na rede de perímetro. Nesse caso, os RODCs podem atender aos requisitos de segurança importantes, portanto alterar o escopo de infraestrutura da implementação de AD DS. Esse tipo de cenário provavelmente será mais frequente. Isso também reflete os atuais modelos de AD DS de melhores práticas para redes de perímetro, como o modelo de floresta corporativo estendido.
Ramificando com RODCs
Os ambientes mais comuns para RODCs que utilizam AD DS são ainda as filiais. Esses tipos de ambientes são tipicamente os pontos da extremidade em uma topologia hub e spoke de rede. Eles são amplamente distribuídos geograficamente, em grandes quantidades e hospedam individualmente pequenas populações de usuários, conectam-se a sites de hub por links de rede não confiáveis e lentos, além da falta frequente de administradores locais com experiência.
Para filiais que já hospedam DCs graváveis, provavelmente é desnecessário implantar RODCs. Nesse cenário, entretanto, os RODCs podem não apenas atender aos requisitos relacionados ao AD DS existente, mas também excedê-los considerando a segurança mais forte, o gerenciamento aprimorado, a arquitetura simplificada e o custo total de propriedade mais baixo (TCO). Para os locais em que a segurança e os requisitos de capacidade de gerenciamento proíbem o uso de DCs, os RODCs podem ajudá-lo a introduzir os DCs no ambiente e fornecer vários serviços localizados e benéficos.
Embora os novos recursos e benefícios tornem a avaliação de RODCs interessante, não há fatores adicionais para considerar, como problemas de compatibilidade de aplicativo e condições de impacto no serviço. Isso pode fazer com que as implantações de RODC sejam inaceitáveis para certos ambientes.
Por exemplo, devido a muitos aplicativos habilitados para diretórios e serviços lerem dados do AD DS, eles devem continuar a funcionar e trabalhar com um RODC. Entretanto, se certos aplicativos exigirem acesso gravável todas as vezes, um RODC poderá não ser aceitável. Os RODCs também dependem da conectividade de rede para um DC gravável de operações de gravação. Entretanto, falha nas operações de gravação podem ser a causa da maioria dos problemas mais conhecidos relacionados a aplicativo, há outros problemas para considerar, como operações de leitura ineficientes ou com falha, operações de gravação com falha e outras falhas de aplicativos em geral associadas ao próprio RODC.
Além das questões com os aplicativos, as operações fundamentais de usuário e computador podem ser afetadas quando a conectividade para um DC gravável é interrompida ou perdida. Por exemplo, serviços de autenticação básicos poderão falhar se as senhas das contas não forem atualizáveis e atualizadas localmente no RODC. Você pode facilmente minimizar o problema tornando as contas atualizáveis através da Diretiva de Replicação de Senha (PRP) e atualizando as senhas através população prévia. A realização dessas etapas também exige conectividade para um DC gravável.
Juntamente com outros problemas de autenticação, expirações de senhas e bloqueios de contas são impactados significativamente quando a conectividade para um DC gravável não está disponível. As solicitações de alteração de senhas e quaisquer tentativas de desbloquear uma conta bloqueada continuarão falhando até que a conectividade para um DC gravável seja recuperada. O entendimento dessas dependências e alterações subsequentes no comportamento operacional é importante para garantir os seus requisitos e quaisquer contratos de nível de serviço (SLAs).
Há diversos cenários nos quais, em geral, você pode implantar RODCs. Eles são úteis em locais que não existem DCs ou em locais que hospedam atualmente DCs, mas que podem ser substituídos ou atualizados para uma versão mais nova do Windows. Apesar de haver considerações de planejamento abrangentes e específicas para cada cenário, focaremos aqui em abordagens não específicas. No entanto, são diferentes das RODCs, em vez de DCs graváveis tradicionais.
Planejamento prévio
Antes de iniciar qualquer planejamento formal de RODC, você deverá conduzir um nível adequado de cuidado necessário e planejamento prévio fundamental de AD DS. Esse planejamento deve incluir tarefas importantes como validação da estrutura lógica existente de AD DS e garantia do modelo de administração e da estrutura física de AD DS com suporte dos requisitos técnicos e comerciais presentes. Você terá que considerar também os requisitos de hardware, estratégias de atualização de software e problemas conhecidos do sistema operacional aplicável, além de avaliar os prerrequisitos do AD DS do RODC. Essas informações serão essenciais para os processos de planejamento e implantação. Você as encontrará bem documentadas em listas detalhadas de verificação de implantação.
Instalação e gerenciamento
Há um recurso substancial de capacidade de gerenciamento nos RODCs chamado Separação da Função do Administrador (ARS). Esse recurso delega aos administradores sem serviço a capacidade de instalar e administrar servidores RODC, sem conceder direitos do Active Directory. É uma alteração significativa nas considerações tradicionais a respeito do design do servidor DC, delegação da administração e procedimentos de implantação. Essa separação de função se torna cada vez mais importante com aplicativos essenciais que exigem instalação direta em um DC ou para locais que hospedem servidores únicos multifuncionais.
Funções adicionais do servidor
Como regra geral, você deverá eliminar do servidor todas as funções não exigidas para que o RODC funcione. Portanto, as únicas funções que você deverá adicionar ao RODC são as de DNS e servidor de catálogo global. A instalação da função de servidor DNS em cada RODC deverá ser feita para que os clientes locais DNS possam realizar resolução DNS quando a conectividade de rede para um DC gravável não estiver disponível. Entretanto, se a função de servidor DNS não tiver sido instalada através de Dcpromo.exe, você terá que instalá-la depois. Você terá que usar o Dnscmd.exe para inscrever o RODC nas partições de diretório de aplicativos do DNS que hospedam as zonas integradas do Active Directory. Você terá também que configurar os RODCs como servidores de catálogos globais para que possam realizar as consultas de catálogo global e de autenticação utilizando apenas o RODC. Do ponto de vista da autenticação, se a função de catálogo global não for uma opção, você poderá utilizar o cache de grupo universal. O sucesso da autenticação para um RODC será em última análise dependente da configuração PRP do RODC.
Posicionamento de RODC:
O posicionamento do DC foi alterado consideravelmente desde a introdução da PRP do RODC. Os RODCs devem ser capazes de replicar a partição de domínio de um DC gravável que executa o Windows Server 2008 ou o Windows Server 2008 R2 no mesmo domínio porque somente esses DCs podem impor as PRPs para os RODCs. Para garantir replicação adequada, o DC gravável deverá ser posto no site do AD DS que possui o link de site com o custo mais baixo para o site que contém o RODC.
Se você não puder estabelecer essa configuração, a replicação do RODC precisará depender da opção Ponte para todos os links de site, o que significa transitividade de link de site, ou de pontes de links de site entre qualquer link de site que contém o site do RODC e o site do DC gravável. Se a transitividade do site ou as pontes de links de site não forem uma opção, você poderá criar links de site novos para conectar diretamente o site do RODC e o site do DC gravável.
Como melhor prática recomendada em geral, você não deverá por outros DCs no mesmo site do AD DS como o RODC porque as operações de clientes podem se tornar inconsistentes e o comportamento do cliente será imprevisível. Operações básicas como autenticação, leituras e gravações LDAP e alterações de senha poderão se comportar de modo diferente dependendo das configurações distintas do RODC, da versão do Windows de um DC gravável e se há ou não conectividade de rede disponível para outros DCs graváveis. Você deverá também manter todos os usuários e recursos de um domínio único em um site do RODC. Os RODCs não armazenam senhas confiáveis e exigem autorização entre domínios para futuras solicitações de autenticação para diferentes DCs graváveis em cada domínio. Supondo-se que DCs graváveis residam em sites diferentes, todas as solicitações de autenticação entre domínios serão dependentes da conectividade de rede e não funcionarão no evento de falha dessa conectividade.
Escalabilidade e replicação
Os RODCs também oferecem benefícios de escalabilidade úteis para implementações maiores ou mais complexas de AD DS. Por exemplo, os RODCs fornecem replicação unidirecional. Portanto, a implantação de RODCs em filiais reduz a carga de desempenho dos servidores bridgehead do site do hub que processa normalmente a replicação de entrada para DCs de filiais. A partir da perspectiva de TCO, há redução na quantidade de objetos de conexão que você precisa para criar e gerenciar. Poderá também haver redução na quantidade exigida de DCs do site de hub.
Os RODCs oferecem também melhorias de balanceamento de carga que ajudam a distribuir automaticamente objetos de conexão de saída de modo uniforme através de servidores bridgehead do site de hub. Com versões anteriores do Windows, é necessário intervenção manual de rotina. Agora, quando o KCC (Knowledge Consistency Checker) em um RODC detectar que um servidor bridgehead foi adicionado ou removido em um site de hub, ele determinará se muda os parceiros de replicação para um novo servidor bridgehead. Ele fará isso executando um algoritmo e o balanceamento de carga provável. Se os RODCs forem adicionados em locais de filiais, o KCC irá ponderar também as conexões de entrada através de servidores bridgehead de sites do hub existentes.
Cache de credenciais
Uma PRP de RODC determina se as contas são armazenáveis naquele RODC em particular. Por padrão, a lista de “permissão” na PRP especifica que você não pode armazenar nenhuma senha. E também nega explicitamente que certas contas sejam armazenadas. Isso tem precedência sobre configurações de “permissão” feitas manualmente. Como mencionado antes, você precisará configurar as PRPs em cada RODC para permitir que as senhas das contas possam ser armazenáveis.
Tome cuidado com essa etapa, já que as modificações de PRP têm impactos de disponibilidade de serviços e segurança. Por exemplo, o cenário padrão de nenhuma conta armazenável resulta em alta segurança, mas nenhum acesso offline no evento de conectividade de rede para um DC gravável se torna indisponível. De forma oposta, quando um grande percentual de contas forem armazenáveis (por exemplo, grupo de usuários de domínio), a segurança será muito mais baixa se o RODC estiver comprometido, mas haverá um nível maior de disponibilidade de serviços para as contas armazenáveis. Devido aos exclusivos requisitos técnicos e de negócios através de diversos ambientes de infraestrutura, os designs de PRP serão diferentes de uma empresa para outra.
Após estabelecer um modelo de PRP, você terá que configurar a PRP em cada RODC para armazenar as contas apropriadas. Como melhor prática recomendada, configure a PRPs com permissões explícitas e não modifique a lista de negações padrão. A lista de negação é fundamental porque evita que credenciais de contas críticas (como administradores de serviço AD DS) nunca sejam armazenadas em RODCs.
Outro aspecto importante do design de PRP é determinar se contas armazenáveis serão populadas previamente com senhas. Por padrão, as credenciais de contas armazenáveis não são na verdade armazenadas até após o logon inicial para um RODC, quando a solicitação de autenticação é encaminhada para um DC gravável do Windows Server 2008 ou Windows Server 2008 R2 e as credenciais são replicadas para o RODC. Isso significa que se a conectividade de rede para um DC gravável se tornar indisponível antes das contas armazenáveis serem autenticadas em um RODC, o logon falhará mesmo que as contas tenham sido configuradas como armazenáveis.
Para resolver esse problema, você poderá popular previamente e de modo manual o cache de senha tão logo a PRP estiver configurada e as contas marcadas como armazenáveis. Essa operação requer também conectividade de rede entre um DC gravável do Windows Server 2008 ou Windows Server 2008 R2 e o RODC. Você poderá fazer isso antecipadamente durante o processo de implantação, bem antes dos usuários armazenáveis acessarem pela primeira vez.
Você poderá utilizar essa importante orientação de design de arquitetura como base para seu planejamento de RODC. Com a abordagem das principais considerações de design, este artigo fornece um ponto de partida efetivo para o planejamento de uma solução detalhada e abrangente para RODC. Não é um processo simples e exige certo tempo para reconciliar novos recursos e considerações de design com o ambiente e os requisitos exclusivos da sua empresa.
Paul Yu* (Paul.Yu@microsoft.com) é um consultor experiente da Microsoft Consulting Services e trabalha na Microsoft há dez anos, fornecendo soluções de infraestrutura corporativa para empresas e organizações do setor público.*