O futuro do WindowsServiços de diretório no Windows Server "Longhorn"
Byron Hynes
Esta coluna se baseia em uma versão de pré-lançamento do Windows Server, de codinome "Longhorn". Todas as informações deste artigo estão sujeitas a alterações.
Vários aperfeiçoamentos do Active Directory surgirão na próxima versão do Windows Server, cujo codinome é "Longhorn". Algumas dessas alterações são significativas e abrem novas e interessantes possibilidades de melhor gerenciamento e eficiência. Uma das alterações mais óbvias do Active Directory é a nomeação de recursos e funções. Tudo o que diz respeito ao gerenciamento de identidades agora está agrupado sob a bandeira do Active Directory®. Aquilo que você e eu chamávamos de Active Directory no Microsoft® Windows Server® 2003 agora é o ADDS (Active Directory Domain Services) e existem vários outros serviços adicionais, incluindo o ADFS (Active Directory Federation Services ), o ADLDS (Active Directory Lightweight Directory Services), chamado anteriormente de ADAM (Active Directory/Application Mode), o ADCS (Active Directory Certificate Services) e o ADRMS (Active Directory Rights Management Services ADRMS).
Cada um desses serviços representa uma função do servidor - um novo conceito do Windows Server "Longhorn". Você pode optar por ter um computador dedicado a uma ou várias funções de servidor, e pode administrar as funções de servidor usando o gerenciador de servidores mostrado na Figura 1. Desse ponto em diante você pode adicionar funções, encontrar ajuda e executar outras tarefas administrativas necessárias.
Figura 1** Gerenciador de servidores **(Clique na imagem para aumentar a exibição)
Como você pode ver, a nova abordagem organiza as funções e os recursos do dia-a-dia em grupos lógicos que podem ser acessados no gerenciador de servidores.
Níveis funcionais
O Windows Server "Longhorn" apresenta um novo nível funcional para florestas e domínios. O nível funcional de floresta do Windows Server "Longhorn" (que será renomeado no lançamento) não acrescenta nenhuma funcionalidade nova própria, mas garante que todos os domínios da floresta estejam no nível funcional de domínio do Windows Server "Longhorn", que permite dois novos aperfeiçoamentos. O primeiro é o uso do mais recente mecanismo de replicação do DFS (Sistema de arquivos distribuídos) para compartilhamento de SYSVOL, que é mais avançado, granular e eficiente. O segundo é o suporte adicional à criptografia AES (Padrão avançado de criptografia) de 256 bits para o protocolo de autenticação Kerberos. O uso do mais recente nível funcional permite o melhor desempenho, mas você pode continuar operando em níveis funcionais mais inferiores ao migrar para o Windows Server "Longhorn".
Várias extensões de esquema para oferecer suporte a diversos recursos também foram introduzidas, e todas são totalmente compatíveis com os esquemas em uso no momento. Os controladores de domínio que executam o Windows Server "Longhorn" podem coexistir e interoperar sem problemas com os controladores de domínio que executam o Windows Server 2003.
Suporte ao Server Core
O Active Directory Domain Services é uma das funções de servidor que funcionará em uma instalação do Server Core no Windows Server "Longhorn". O Server Core, que não é abordado com detalhes neste artigo, é uma opção de instalação mínima na qual apenas a funcionalidade de núcleo do servidor é conservada. O Server Core não instala o shell do Windows e não utiliza uma interface gráfica do usuário, reduzindo consideravelmente a sobrecarga.
Controlador de domínio somente leitura
Em alguns ambientes, o recurso mais significativo para o ADDS do Windows Server "Longhorn" é um RODC (Controlador de domínio somente leitura), que permite implantar facilmente um controlador de domínio que hospeda uma réplica somente leitura do banco de dados do domínio. Isso é adequado para locais onde a segurança física do controlador de domínio não pode ser garantida, ou onde outros aplicativos devem ser executados no controlador de domínio e serem mantidos por um administrador (que idealmente não é membro do grupo de administradores de domínio). Os dois cenários são comuns nas implantações em filiais.
Um controlador de domínio somente leitura é instalado simplesmente ativando uma caixa de seleção no Assistente de instalação, como mostra a Figura 2.
Figura 2** Instalação de controlador de domínio somente leitura **(Clique na imagem para aumentar a exibição)
Antes do lançamento do Windows Server "Longhorn", se os usuários tivessem que se autenticar em um controlador de domínio de uma localização diferente, o tráfego teria que atravessar o link de uma WAN (Rede de longa distância). Os links de WAN quase sempre são mais lentos e mais caros do que as conexões LAN (Rede local) e, às vezes, estão mais sujeitos a interrupções de serviço. Uma solução possível era implantar um controlador de domínio em um local remoto ou filial. Entretanto, isso apresentava outros problemas, incluindo o tráfego de replicação e a necessidade de manter a segurança física no controlador de domínio da filial - algo que sempre falta em filiais pequenas e remotas. Em outros casos, as filiais têm pouca largura de banda conectada a um site de hub, aumentando a quantidade de tempo necessária para o logon.
Com exceção das senhas de conta (a menos que seja configurado o contrário), um RODC tem todos os objetos e atributos de ADDS que um controlador de domínio gravável tem. Entretanto, as alterações originadas localmente não podem ser feitas na réplica armazenada no RODC. Em vez disso, as alterações são feitas em um controlador de domínio gravável e são replicadas de volta no RODC. Isso evita que as alterações feitas em locais de filiais tenham o potencial de poluir ou corromper a floresta por meio da replicação, eliminando assim uma via de ataque.
Os aplicativos locais que solicitam acesso de leitura às informações do diretório de domínio podem obter acesso diretamente do RODC, enquanto os aplicativos LDAP (Lightweight Directory Access Protocol) que solicitam acesso de gravação recebem uma resposta de referência LDAP. Essa resposta de referência os direciona para um controlador de domínio gravável, normalmente em um site de hub.
Como nenhuma alteração é gravada diretamente no RODC, nenhuma alteração se origina no RODC. Da mesma forma, os controladores de domínio graváveis que são parceiros de replicação não precisam tirar alterações do RODC. Isso reduz a carga de trabalho dos servidores ponte do hub e o esforço necessário para monitorar a replicação. A replicação unidirecional RODC aplica-se ao ADDS e à replicação do DFS. O RODC executa a replicação normal de recebimento para as alterações do ADDS e replicação DFS.
No banco de dados de domínio, cada entidade de segurança tem um conjunto de cerca de 10 senhas ou segredos chamados credenciais. Um RODC não armazena credenciais de usuário ou computador, exceto pela sua própria conta de computador e uma conta "krbtgt" especial (conta usada para a autenticação do Kerberos) em cada RODC. O RODC é anunciado como KDC (Centro de distribuição de chaves) para seu site (em geral o escritório da filial). Quando o RODC assina ou criptografa uma solicitação TGT (Ticket-Granting Ticket), ele utiliza uma conta krbtgt e uma senha diferentes daquelas do KDC em um controlador de domínio gravável.
Quando há uma primeira tentativa de se autenticar uma conta em um RODC, este envia a solicitação para um controlador de domínio gravável no site do hub. Se a autenticação for feita com êxito, o RODC também solicita uma cópia das credenciais apropriadas. O controlador de domínio gravável reconhece que a solicitação é proveniente de um RODC e consulta a diretiva de replicação de senhas em vigor para aquele RODC.
A diretiva de replicação de senhas determina se as credenciais têm permissão para serem replicadas e armazenadas no RODC. Assim, um controlador de domínio gravável envia as credenciais ao RODC, e este faz seu cache, como mostra o quadro "Como funciona um controlador de domínio somente leitura".
Após o cache das credenciais no RODC, da próxima vez que aquele usuário tentar fazer logon, a solicitação pode ser atendida diretamente pelo RODC até que as credenciais sejam alteradas. Quando um TGT é assinado com a própria conta krbtgt do RODC (krbtgt), o RODC reconhece que tem uma cópia em cache das credenciais. Se o TGT tiver sido assinado por outro DC, o RODC encaminhará as solicitações para um controlador de domínio gravável.
Quando o cache de credenciais é limitado apenas aos usuários que se autenticaram no RODC, a exposição potencial das credenciais por um comprometimento do RODC também é limitada.
Por padrão, nenhuma senha de usuário ficará em cache em um RODC, mas esse não é necessariamente o cenário mais eficiente. Normalmente, apenas alguns usuários de domínio precisam ter credenciais em cache em determinado RODC, comparados ao número total de usuários de um domínio. Você pode usar a diretiva de replicação de senhas para especificar até mesmo quais grupos de usuários podem ser considerados para cache. Por exemplo, limitando o cache do RODC apenas aos usuários que estão com freqüência na filial, ou evitando o cache de credenciais de valor alto, como administradores, é possível reduzir a exposição potencial.
Assim, em caso do RODC ser roubado ou comprometido de alguma outra forma, apenas as credenciais que estão em cache precisam ser redefinidas e, como discutiremos, você saberá exatamente quais são essas contas, como mostra a Figura 3.
Figura 3** Informação de conta em cache **(Clique na imagem para aumentar a exibição)
Separação da função de administrador
Em muitas filiais, um controlador de domínio recebe funções de servidor adicionais ou tarefas a serem executadas, tais como atuar como um arquivo ou um servidor de impressão. Em outros casos, um aplicativo de linha de negócios é instalado em um controlador de domínio sem necessidade. Isso cria um problema: para administrar aplicativos e servidores, um funcionário da filial precisa ter credenciais administrativas. E todos que podem administrar um controlador de domínio do Windows Server 2003 podem administrar todo o domínio.
No Windows Server "Longhorn", um administrador pode receber permissão para gerenciar apenas determinado RODC, sem precisar do acesso que permitiria gerenciar outros controladores de domínio e sem precisar se tornar um membro do grupo de segurança de administradores de domínio desnecessariamente.
Interface do usuário e aperfeiçoamentos da ferramenta
Para suportar as funções de um RODC e facilitar a monitoração da replicação de senhas, uma nova guia de diretiva de replicação de senhas é exibida na página de propriedades de um controlador de domínio de Usuários e computadores do Active Directory, como mostra a Figura 4.
Figura 4** Guia Password Replication Policy **(Clique na imagem para aumentar a exibição)
Clicando no botão Advanced dessa guia, é possível ver quais senhas foram enviadas para o RODC, quais estão armazenadas nele e quais contas foram autenticadas naquele RODC, como mostra a Figura 5. Como a lista inclui contas que foram autenticadas, mesmo que elas estejam fora de grupos com permissão de replicação de suas senhas, você pode usar essas informações para resolver quais grupos devem ser incluídos na diretiva de replicação de senhas.
Figura 5** Diretiva de replicação de senha avançada **(Clique na imagem para aumentar a exibição)
Várias alterações foram feitas no respeitável utilitário dcpromo, conhecido mais formalmente como o Assistente de instalação de serviços de domínio do Active Directory. Este assistente pode ser iniciado como um aplicativo gráfico completo, selecionando o comando Add Roles na página ICT (Tarefas de configuração iniciais) que é executada imediatamente após a instalação do sistema operacional. Selecione Add Roles e, em seguida, ADDS no Gerenciador de servidores ou chame dcpromo em uma linha de comando ou caixa Executar.
Após usar o assistente no modo gráfico, você observará uma organização melhor dos elementos e opções, uma vez que os itens relacionados são agrupados. Também existem outras opções. Você pode acessar o modo avançado da interface do usuário sem usar a chave /adv para executar tarefas como criação de uma nova árvore de domínio, instalação de uma mídia (para reduzir a replicação inicial em uma WAN) ou seleção do controlador de domínio de origem para replicação inicial.
Alguns aperfeiçoamentos foram feitos para facilitar seu trabalho e reduzir os erros frustrantes. Por exemplo, se você está usando o assistente para criar um novo controlador em um domínio ou floresta existente, pode pesquisar domínios existentes em vez de digitar o nome NetBIOS.
Foram adicionadas novas páginas para especificar opções adicionais, que permitem a configuração do controlador de domínio como um servidor global de catálogos, como um servidor de DNS e um RODC. No assistente também é possível configurar a seleção de local, definir os níveis funcionais, criar uma diretiva de replicação de senha para os RODCs e configurar a delegação de DNS.
Como ferramenta de linha de comando, o dcpromo pode ser executado de forma completamente autônoma. Ao contrário da mesma ferramenta do Windows Server 2003, uma instalação autônoma não exige uma resposta em nenhum aviso de interface do usuário, como a necessidade de reinicializar o computador. Isso facilita o uso do ADDS nas instalações do Server Core do Windows Server "Longhorn".
Auditoria do ADDS
A Microsoft adiciona muito mais funcionalidades para a auditoria dos serviços de diretório do Windows Server "Longhorn". No Windows Server 2003, era possível ligar ou desligar a auditoria de acesso a diretórios, mas mesmo que a auditoria de êxito completo estivesse ligada, o controle de auditoria não incluía as informações alteradas. Agora, ele inclui.
No Windows Server "Longhorn", a diretiva de auditoria do ADDS tem as quatro subcategorias seguintes:
- Acesso ao serviço de diretório
- Alterações no serviço de diretório
- Replicação do serviço de diretório
- Replicação detalhada do serviço de diretório
Para a maioria dos profissionais de TI, existem dois fatos principais a serem lembrados sobre as alterações. Em primeiro lugar, a auditoria de acesso ao serviço de diretório fornece essencialmente as mesmas informações que eram fornecidas no Windows Server 2003, mas o ID de evento mudou de 566 para 4662. Anote essa alteração se usar ferramentas para analisar o log de eventos de segurança. Em segundo lugar, a nova categoria de registros de alterações nos serviços de diretório registra o valor anterior e o valor atual do atributo alterado.
Para implementar a auditoria no ADDS, você usa a Diretiva global de auditoria, as SACLs (Lista de controle de acesso do sistema) e o esquema do ADDS. Os componentes funcionam juntos para permitir flexibilidade e estrutura de auditoria abrangente.
Os controles da diretiva global de auditoria controlam se a auditoria é realizada ou não no ADDS. Caso a auditoria esteja ativada, a diretiva global controla qual das quatro subcategorias de acesso (listadas anteriormente) são auditadas. Em geral, a diretiva global de auditoria se aplica ao objeto de diretiva de grupo dos controladores de domínio padrão, portanto, ela se aplica a todo o diretório do controlador de domínio.
Embora as ferramentas da diretiva de grupo possam ligar ou desligar a diretiva global de auditoria, você deve usar a ferramenta de linha de comando Auditpol.exe para visualizar ou configurar as subcategorias. Elas não são expostas na interface gráfica do usuário.
Uma SACL faz parte do descritor de segurança de um objeto. Ao especificar entradas da SACL, você informa ao sistema duas coisas: com quais ações e quais usuários (ou entidades de segurança) você se importa. Em outras palavras, você especifica os usuários e as ações que devem ser registrados no log de eventos. Assim, se quiser registrar alterações nos objetos User feitas pelo administrador do domínio, mas não pelos usuários propriamente ditos, você poderá controlar isso com as SACLs. É aplicada uma SACL a um objeto (pode ser definida para objetos novos e herdada de objetos contêineres).
Também é possível configurar o esquema ADDS para limitar a auditoria de alterações a determinados atributos. Como as SACLs são aplicadas ao objeto por padrão, o acesso ou as alterações de todo atributo são registrados. Isso poderia gerar muita atividade de log e talvez nem todos os atributos sejam interessantes para você. Assim, no nível de atributo, você pode definir um sinalizador para evitar o registro das alterações daquele atributo.
SearchFlags é um atributo definido na classe que define os atributos e, portanto, é um atributo de um atributo. Ele também é uma máscara de bit, na qual cada bit de um valor de um byte representa uma configuração liga/desliga diferente. Você pode achar mais fácil pensar nele como uma propriedade de um atributo. No Windows Server 2003, sete desses valores são usados para controlar diversas configurações, incluindo a indexação e a replicação GC do atributo. No Windows Server "Longhorn", o oitavo bit (com um valor de 128) é usado para determinar se as alterações são registradas o não. Se esse bit estiver definido, o ADDS não registrará os eventos de alteração quando forem feitas modificações naquele atributo. Isso se aplica a todos os objetos que contêm o atributo. Na versão Beta 2, você não pode usar a interface gráfica do usuário para definir o oitavo bit.
Por padrão, no Windows Server "Longhorn", a diretiva global de auditoria está ligada e as alterações nos serviços de diretório estão definidas para registrar alterações com êxito.
ADDS reinicializável
No Windows Server "Longhorn" o ADDS é um serviço reinicializável. Isso significa simplesmente que o ADDS Services pode ser interrompido e inicializado sem reinicialização do controlador de domínio. Isso permite aos administradores executarem funções que não podem ser realizadas enquanto o serviço está em execução (como uma desfragmentação offline do banco de dados) com mais facilidade e sem entrar no modo de restauração dos serviços de diretório.
Existem três estados possíveis para um controlador de domínio que executa o Windows Server "Longhorn": ADDS inicializado, ADDS interrompido e Modo de restauração dos serviços de diretório. Vamos examinar cada um desses estados.
ADDS iniciado O controlador de domínio está operando normalmente.
ADDS interrompido O servidor tem características de controlador de domínio no modo de restauração dos serviços de diretório e servidor membro associado de domínio.
Assim como no modo de restauração dos serviços de diretório, o banco de dados do ADDS (Ntds.dit) está offline. A senha do modo de restauração dos serviços de diretório pode ser usada para logon local, caso outro controlador de domínio não possa ser contactado para logon.
Assim como acontece com um servidor membro, o servidor é associado ao domínio. Os usuários podem fazer logon interativo pela rede, usando outro controlador de domínio para o logon de domínio. Entretanto, um controlador de domínio não deve permanecer nesse estado durante um período longo, porque ele não pode atender as solicitações de logon e nem fazer a replicação em outros controladores de domínio.
Modo de restauração dos serviços de diretório Este modo (ou estado) não mudou desde o Windows Server 2003.
O fluxograma da Figura 6 mostra como um controlador de domínio que executa o Windows Server "Longhorn" pode fazer a transição entre esse três estados possíveis.
Figura 6** Um controlador de domínio no Windows Server 'Longhorn' Can Transition between Three States **
Procurando mais?
É impossível em um artigo curto explicar a profundidade dos novos recursos do ADDS no Windows Server "Longhorn". Mas, como você viu, os novos recursos do Active Directory solucionarão vários problemas que anteriormente você precisava contornar ou com os quais simplesmente tinha que conviver. À medida que se aproxima o lançamento da versão final do produto e você quer saber mais, tenha certeza de que haverá documentação adicional disponibilizada publicamente. Por enquanto, o melhor lugar para procurar por atualizações durante a fase de versão beta é o site do Windows Server "Longhorn".
Byron Hynes trabalha no grupo de Assistência ao usuário do Windows Server da Microsoft. Ele já trabalhou como consultor e instrutor, e tem uma ampla experiência que inclui a administração de um backbone de Internet regional, solução de problemas de cliente e servidor e aplicativos ativados para Web, e a criação de esquemas de bancos de dados, infra-estrutura de rede e modelos de segurança. Você pode entrar em contato com ele em bhynes@microsoft.com.
© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..