Visão geral:
- Usando o novo Gerenciador de Servidores com o ADDS
- Executando serviços de domínio no Server Core
- Controladores de domínio somente leitura
- Alterações em senhas, fazendo backup e auditando
Com o Windows 2000, a Microsoft apresentou ao mundo o Active Directory. A próxima versão principal, o Windows Server 2003, trouxe aprimoramentos consideráveis no Active Directory, mas nenhuma
alteração muito surpreendente. Atualmente, o Active Directory® é um serviço de diretório robusto e muito amadurecido. Mesmo assim, a equipe do Active Directory contribuiu com avanços substanciais na versão mais recente para aumentar a segurança e a gerenciabilidade desse serviço de rede básico.
Em torno da virada do século, o Active Directory era aquilo que autenticava um usuário no logon, aplicava diretivas de grupo ao usuário e seu computador e o ajudava a localizar a impressa que ele estava procurando. Alguns anos mais tarde, a Microsoft lançou uma variante autônoma chamada ADAM (Modo de Aplicativo do Active Directory).
Em 2006, tudo isso mudou. O Active Directory não era mais uma tecnologia específica. Passou a ser o nome da marca que identifica uma coleção de serviços para controle de acesso e identidades do Windows® prontos para usar. A Figura 1 apresenta um rápido resumo do que constitui a marca Active Directory.
Figure 1 Componentes do Active Directory
Tecnologia atual do Active Directory
Anteriormente chamado
Descrição
Serviços de Domínio Active Directory (ADDS)
Active Directory
O que costumávamos chamar de Active Directory. Fornece autenticação Kerberos e baseada em NTLM para usuários e computadores do domínio e gerencia unidades organizacionais, grupos, diretivas de grupo e muito mais.
Active Directory Lightweight Directory Services (ADLDS)
Modo de Aplicativo do Active Directory (ADAM)
Um servidor LDAP de alto desempenho baseado no mesmo código-fonte usado pelo ADDS.
Serviços de Certificados do Active Directory (ADCS)
Serviços de Certificados
Fornece autenticação forte usando certificados X.509.
Active Directory Rights Management Services (ADRMS)
Rights Management Services
Protege ativos digitais (como documentos e emails) contra uso não autorizado criando contêineres e arquivos protegidos por direitos.
Serviços de Federação do Active Directory (ADFS)
Serviços de Federação do Active Directory
Fornece logon único na Web e federação de identidade para serviços Web compatíveis com WS-*.
Assim, para usar a terminologia correta, este artigo é sobre os Serviços de Domínio. Para ser honesto, porém, ainda é o mesmo Active Directory que você aprendeu a amar desde 2000.
Gerenciador de Servidores no Windows Server 2008
Os dois primeiros aprimoramentos do Active Directory que discutirei aqui não são realmente alterações no ADDS (Serviços de Domínio Active Directory). São alterações no Windows que modificarão o modo como você gerencia o Active Directory. O primeiro – o novo Gerenciador de Servidores – pode ser notado logo na primeira inicialização do servidor Windows Server® 2008. O segundo é a instalação do Server Core, que comentarei daqui a pouco.
É provável que o Gerenciador de Servidores lhe pareça familiar por causa do Assistente para Configurar o Servidor no Windows Server 2003, que surge por padrão depois que você instala o Windows Server 2003. Essa versão, contudo, não é muito útil para a administração do dia-a-dia, e todo o mundo que eu conheço marca a caixa "Não exibir esta página ao fazer logon".
O Gerenciador de Servidores no Windows Server 2008, por outro lado, é bem útil (consulte o artigo de Byron Hynes nesta edição da TechNet Magazine para obter uma visão geral desse recurso). Em primeiro lugar, como você pode ver na Figura 2, o Gerenciador de Servidores agora é um snap-in do MMC (Console de Gerenciamento Microsoft®), e não mais um Aplicativo HTML (HTA). Isso significa que ele tem uma interface do usuário cheia de recursos, familiar e fácil de personalizar. Pronto para ser usado, o Gerenciador de Servidores permite gerenciar a instalação de funções de servidor (serviços essenciais como DNS, ADDS e IIS) e recursos (componentes de software, como o Microsoft .NET Framework, a criptografia de unidade de disco BitLockerTM e o Windows PowerShellTM). Além da capacidade de adicionar e remover software, o Gerenciador de Servidores também oferece um ponto de contato único para executar ferramentas de diagnóstico (como Visualizar Eventos e PerfMon) e utilitários de configuração do sistema (como o Gerenciador de Dispositivos e o snap-in Firewall do Windows). Se você adicionar os snap-ins do MMC para Active Directory (por exemplo, Usuários e Computadores, Domínios e Relações de Confiança, e Sites e Serviços), terá uma interface bem bonita para executar o gerenciamento diário do seu controlador de domínio do Windows Server 2008.
Figura 2 Gerenciador de Servidores no Windows Server 2008 (Clique na imagem para aumentar a exibição)
Windows Server 2008 Server Core
O Windows Server Core é uma nova opção de instalação do Windows que fornece uma versão reduzida do Windows contendo apenas os componentes necessários para executar certas funções de servidor importantes, como os Serviços de Domínio Active Directory. A Figura 3 lista as funções com suporte no Server Core. Embora uma instalação Server Core possua uma interface gráfica do usuário, ela não executa o shell de desktop do Windows, e quase todas as ferramentas gráficas para gerenciar e configurar o Windows estão ausentes (consulte a Figura 4). Em lugar delas, você recebe uma janela de comando e fica com a sensação de que não sabe o que fazer a seguir. Como faço para alterar o nome do computador? Como configuro um endereço IP estático?
Figura 4 Não há muito a ver na interface do usuário do Server Core (Clique na imagem para aumentar a exibição)
Os primeiros minutos na frente de uma instalação Server Core podem ser perturbadores. Mas depois de algum tempo familiarizando-se novamente com WMIC, NETSH e NETDOM, você estará apto a realizar todas as tarefas de instalação e configuração, sem dificuldade. E ainda tem o Regedit e o Bloco de Notas para satisfazer suas necessidades de ferramenta gráfica.
A principal vantagem do Server Core é que é removida uma boa parte do código obtido com a instalação típica do Windows, que talvez não seja necessária para as principais funções de servidor. Isso reduz a possível superfície de ataque de malware (o que é bom) e diminui a quantidade de aplicação de patch e de reinicialização que você terá de executar em seus controladores de domínio (o que é melhor ainda). Você tem também menos requisitos de disco rígido e uma capacidade de disco muito menor, o que normalmente não é grande coisa, mas pode ser útil em ambientes de servidor virtualizados.
A ausência de utilitários gráficos dificulta o gerenciamento do ADDS? De forma alguma. É possível realizar quase todas as tarefas de gerenciamento remotamente por meio da execução dos utilitários na estação de trabalho e da conexão ao controlador de domínio pela rede. Minha expectativa é que a grande maioria de controladores de domínio virá a ser executada em instalações Server Core.
Alterações no DCPROMO
A primeira alteração que você observará no ADDS em si é o novo DCPROMO. Ele funciona exatamente como o DCPROMO no Windows Server 2003, mas foi completamente reescrito para facilitar o uso. Por exemplo, você não precisa inserir suas credenciais de administrador de domínio; o DCPROMO pode usar as credenciais do seu login atual para promover o servidor. Também não é necessário digitar DCPROMO /ADV para obter as opções do DCPROMO no modo avançado. Agora existe uma caixa de seleção na primeira caixa de diálogo do DCPROMO para habilitar essas opções. O modo avançado também permite selecionar o controlador de domínio a partir do qual será feita a replicação. Isso significa que é possível manter a carga de replicação do DCPROMO fora dos controladores de domínio de produção.
Quando você promove um controlador de domínio em um novo domínio ou floresta, o DCPROMO lhe dá a opção de definir o nível funcional do domínio ou da floresta, para que você não precise fazê-lo mais tarde. Você também pode especificar o site do Active Directory no qual deseja colocar o controlador de domínio durante o processo de promoção, o que é muito útil no cenário de DCPROMO autônomo. O DCPROMO até sugerirá o melhor site para o controlador de domínio com base no respectivo endereço IP.
O novo DCPROMO também reúne todas as opções de configuração em uma única página, fornecendo um lugar em que você poderá decidir se o novo controlador de domínio será um catálogo global (GC), um servidor DNS ou um controlador de domínio somente leitura. Não é preciso ir para um local obscuro no snap-in Sites e Serviços do Active Directory para marcar o controlador de domínio como GC.
Mas talvez o recurso mais interessante no novo DCPROMO seja a capacidade de salvar todas as configurações em um arquivo de resposta um pouco antes do processo de promoção ter início. Isso é muito mais simples – e menos sujeito a erros – do que emendar o arquivo de resposta à mão. Você poderá então usá-lo para executar DCPROMOs autônomos em outros servidores. E, para os fanáticos por script, agora todas as opções do DCPROMOs podem ser acessadas a partir da linha de comando.
Controladores de domínio somente leitura
Nos primórdios do Active Directory, as empresas costumavam implantar controladores de domínio em cada site no qual os usuários pudessem fazer login. Isso era comum nos bancos, por exemplo, onde cada agência tinha um controlador de domínio. A lógica era que os usuários na agência poderiam fazer logon e acessar recursos de rede locais mesmo se a WAN falhasse.
Na época, a necessidade de segurança física dos controladores de domínio não era bem compreendida. Já vi controladores de domínio enfiados debaixo de mesas, onde poderiam facilmente ser acessados pelas pessoas que passavam. Só alguns anos mais tarde é que os arquitetos do Active Directory tiveram compreensão total do risco à segurança que era um controlador de domínio e as organizações de TI começaram a consolidar seus controladores de domínio em data centers mais centralizados. Os usuários das filiais passaram fazer a autenticação pela WAN, mas a segurança adicional compensava.
O Active Directory no Windows Server 2008 muda a equação no tocante à implantação de filiais introduzindo controladores de domínio somente leitura (RODCs), que representam a maior alteração nos Serviços de Domínio do Windows Server 2008.
O foco da equipe do Active Directory quando desenvolveu o RODC eram os requisitos do cenário de filiais, por isso adotou a meta de "o que acontece na filial, fica na filial". A questão é que, se você implanta um controlador de domínio em uma filial fisicamente insegura, não há nada que possa fazer para impedir que ele (e os computadores que confiam nele) seja comprometido, mas pode evitar que esse comprometimento se espalhe da filial para o resto do domínio.
Observe que, mesmo que constituam uma enorme alteração na infra-estrutura do ADDS, os RODCs são bem simples de implementar. É preciso que o seu domínio esteja no nível funcional de floresta do Windows Server 2003 e deve haver pelo menos um controlador de domínio do Windows Server 2008 no domínio. Mais do que ser simplesmente uma solução para filiais, os RODCs fazem sentido em ambientes voltados para a Internet e em situações nas quais o controlador de domínio é colocado no perímetro da rede.
Controlador de domínio ausente sem permissão
Existem várias classes de ameaças a considerar em uma filial. A primeira é o cenário "controlador de domínio roubado", em que alguém some com o controlador de domínio ou seu respectivo disco. Mais do que a interrupção do serviço local, o risco é que o invasor acabe obtendo acesso a todos os nomes de usuário e senhas no domínio e, a partir daí, eleve seus privilégios para obter acesso a recursos protegidos ou provocar uma negação de serviço. Para resolver essa ameaça, os RODCs, por padrão, não armazenam os hashes de senha na DIT (árvore de informações de diretórios) do RODC. Assim, para autenticar um usuário no domínio, quando ele se autentica pela primeira vez em um determinado RODC, este passa a solicitação para um controlador de domínio completo (FDC) no domínio. O FDC processa a solicitação e, se bem-sucedida, o RODC emite uma solicitação de replicação para o hash de senha.
Um RODC comprometido poderia solicitar hashes de senha para contas confidenciais. Para impedir isso, o administrador de domínio pode configurar uma diretiva de replicação de senha para cada RODC. Essa diretiva é formada por dois atributos no objeto de computador do RODC. O atributo msDS-RevealOnDemandGroup contém os nomes distintos de contas de grupos, usuários ou computadores cujas senhas podem ser armazenadas em cache no RODC (normalmente, são usuários e computadores do mesmo site que o RODC). O msDS-NeverRevealGroup contém os nomes distintos de contas de grupos, usuários ou computadores cujas senhas não podem ser armazenadas em cache no RODC (por exemplo, a conta do administrador de domínio nunca deve ter seus hashes de senha armazenados em cache em um RODC). Quando o RODC solicita o hash de senha de uma determinada conta, o FDC avalia a solicitação em relação à diretiva de replicação de senha para determinar se o hash de senha deve ser replicado para o RODC. Quando um controlador de domínio é roubado, isso limita a vulnerabilidade àquelas senhas que tinham sido armazenadas em cache no RODC roubado na época em que ele foi removido da rede, o que elimina a possibilidade de uma senha importante ser comprometida.
O objeto de computador do RODC contém dois outros atributos para ajudá-lo a determinar exatamente quais contas devem ter suas senhas armazenadas em cache. O atributo msDS-AuthenticatedAtDC lista as contas que foram autenticadas no RODC, enquanto o atributo msDS-RevealedList nomeia as contas cujas senhas estão armazenadas atualmente no RODC.
Os hashes de senha de usuários e computadores não são os únicos segredos armazenados em um controlador de domínio. A conta KrbTGT contém as chaves para o serviço Centro de Distribuição de Chaves Kerberos (KDC) executado em cada controlador de domínio. Em um cenário típico, cada KDC no domínio compartilha a mesma conta KrbTGT e é possível que um invasor possa recuperar essas chaves de um controlador de domínio roubado a fim de usá-las para atacar o resto do domínio. No entanto, cada RODC tem suas próprias chaves e conta KrbTGT, eliminando essa possibilidade.
Também não é incomum os aplicativos armazenarem senhas ou outros segredos na DIT. Se um invasor fosse roubar um controlador de domínio, possivelmente roubaria essas senhas de aplicativo e as usaria para obter acesso aos aplicativos. Para diminuir esse risco, os Serviços de Domínio do Windows Server 2008 permitem que os administradores definam o conjunto de atributos filtrados para o RODC (RO-FAS). Os atributos que fazem parte do RO-FAS nunca são replicados para RODCs e, portanto, não podem ser recuperados de um controlador de domínio comprometido. Você designa atributos ao RO-FAS definindo o bit 9 (0×0200) do atributo searchFlags do objeto attributeSchema correspondente no esquema.
Bárbaros no recinto
Outra classe de ameaça a controladores de domínio de filiais é o caso de um administrador de servidor local que eleva seu privilégio aproveitando os privilégios do controlador de domínio para obter acesso a outros recursos do domínio ou engendrar um ataque de negação de serviço. Mais uma vez, se o administrador local tiver acesso físico ao controlador de domínio, pouco poderá ser feito para impedir o comprometimento. Mas é possível impedir o invasor de usar o controlador de domínio de filiais para comprometer outros no domínio.
Os controladores de domínio completo no domínio não confiam nos RODCs como controladores de domínio. Do ponto de vista de relações de confiança, os FDCs tratam os RODCs como servidores membros no domínio. Um RODC não é membro dos grupos Controladores de Domínio de Empresa ou Controladores de Domínio. A conta do RODC tem capacidade muito limitada para atualizar algo no diretório. Por isso, mesmo que um invasor a comprometa, não obterá praticamente nenhum privilégio.
Os RODCs nem mesmo aparecem na topologia de replicação normal do controlador de domínio. Como os RODCs parecem servidores membros normais e não controladores de domínio, o KCC (Knowledge Consistency Checker), que é o processo em cada controlador de domínio responsável por calcular a topologia de replicação do controlador de domínio, não criará objetos de conexão a partir dos RODCs. Nenhum controlador de domínio ou RODC tentará replicar de um RODC. Por outro lado, o RODC criará um objeto de conexão representando um acordo de replicação de entrada a partir de um controlador de domínio completo, mas esse objeto de conexão só existe na réplica do RODC; nenhum outro controlador de domínio tem uma cópia desse objeto de conexão. Do ponto de vista de replicação, os RODCs são como motéis cheios de baratas para os objetos de diretório. Os objetos se replicam internamente, mas não externamente.
Separação de funções administrativas nos RODCs
É muito comum o controlador de domínio de uma filial ser gerenciado por um administrador de servidor local que faz tudo, desde executar backups no controlador de domínio até limpar teclados. Mas é um risco à segurança conceder a um administrador de site remoto os direitos necessários para fazer manutenção geral em um controlador de domínio, pois ele pode elevar seus privilégios no domínio. Os RODCs fornecem dois tipos de separação de funções administrativas para minimizar essa ameaça.
Com a primeira forma de separação de funções, o administrador de domínio pode promover o RODC normalmente usando o DCPROMO ou pode utilizar um processo em duas etapas no qual o processo de promoção real é delegado de modo seguro ao administrador de site da filial, sem conceder direitos de administração de domínio. O administrador de domínio cria previamente a conta de computador do RODC no domínio usando o snap-in do MMC Usuários e Computadores do Active Directory, como mostra a Figura 5.
Figura 5 Criando previamente a conta de computador do RODC (Clique na imagem para aumentar a exibição)
Se você selecionar "Pré-criar conta do Controlador de Domínio Somente Leitura", será executada uma versão abreviada do DCPROMO que realiza todas as tarefas que requerem acesso administrativo ao domínio. Por exemplo, criação da conta de computador, atribuição do RODC a um site, especificação das funções do controlador de domínio, especificação da diretiva de replicação de senha e definição do usuário ou grupo que precisará dos direitos para concluir a operação do DCPROMO no RODC. O grupo ou administrador delegado é armazenado no atributo managedBy do objeto de computador do RODC.
O administrador delegado pode então executar o DCPROMO no próprio servidor. O DCPROMO detectará a conta pré-criada e transformará o servidor em um RODC. A execução do DCPROMO dessa maneira não requer credenciais de administrador de domínio.
A segunda forma de os RODCs fornecerem separação de funções administrativas é criando funções administrativas locais no próprio RODC. Essas funções parecem grupos locais de computador (são armazenadas no Registro do RODC) e só podem ser avaliadas no RODC. Mas, em vez de usar o snap-in do MMC Gerenciamento do Computador para gerenciá-las, o administrador gerencia as funções locais do RODC usando o NTDSUTIL. A Figura 6 lista as funções administrativas locais em um RODC. Essas funções correspondem uma a uma aos grupos internos no Windows.
Figure 6 Funções administrativas do RODC local
Operadores de Conta
Administradores
Operadores de Backup
Acesso DCOM de Serviços de Certificados
Operadores Criptográficos
Distributed COM – Usuários
Leitores de Log de Eventos
Convidados
IIS_IUSRS
Construtores de Confiança de Floresta de Entrada
Operadores de Configuração de Rede
Usuários do Log de Desempenho
Usuários do Monitor de Desempenho
Acesso Compatível com Versões Anteriores ao Windows 2000
Operadores de Impressão
Usuários da Área de Trabalho Remota
Replicadores
Operadores de Servidor
Usuários de Licença do Terminal Server
Usuários
Grupo de Acesso de Autorização do Windows
Singularidades do RODC
Os RODCs podem exibir alguns comportamentos inesperados, já que são somente leitura e nenhum outro controlador de domínio se replicará a partir deles. Por exemplo, objetos persistentes – ou seja, aqueles que tenham sido excluídos de todos os locais exceto de um determinado controlador de domínio porque este não podia ser replicado por mais tempo do que o tempo de vida de desativação da floresta – normalmente são detectados pelos parceiros de replicação externos do controlador de domínio. Mas como os RODCs não têm nenhum parceiro de replicação interno, não há detecção de objetos persistentes para eles.
Os RODCs não atenderão a operações de atualização do LDAP (adição, modificação, exclusão e movimentação). Em vez disso, eles retornam um erro com uma referência LDAP para um controlador de domínio gravável que possa atender à operação. Se o aplicativo que emitiu a atualização do LDAP não processar corretamente a operação de referência, poderá falhar.
Finalmente, se um usuário de outro domínio na floresta tentar autenticar em um RODC, este deverá ser capaz de acessar um FDC em seu próprio domínio a fim de obter a senha de confiança para passar corretamente a solicitação de autenticação para o controlador de domínio no domínio do usuário. Se a conexão de rede entre o RODC e o FDC em seu domínio estiver indisponível, ocorrerá falha na autenticação.
Diretivas de senha refinadas
A capacidade de definir mais de uma diretiva de senha no domínio era provavelmente o recurso mais solicitado para o ADDS do Windows Server 2008. Como você já deve saber, no Active Directory do Windows 2000 e do Windows Server 2003, cada domínio oferece suporte a apenas uma única diretiva de senha, que é aplicada a todas as entidades de segurança no domínio. Se você precisa de uma diretiva de senha separada para um grupo específico de usuários, tem de criar um domínio separado. Mas agora um novo recurso no ADDS do Windows Server 2008, chamado Diretivas Refinadas de Senha, permite definir várias diretivas de senha em um domínio.
A nova estratégia usa grupos para aplicar diretivas de senha refinadas a usuários. Primeiro você define a diretiva de senha refinada criando um novo objeto msDS-PasswordSettings no contêiner CN=Password Settings Container, CN=System, DC=<domínio>. O objeto msDS-PasswordSettings (PSO l, para abreviar) contém atributos que correspondem à configuração de diretiva de senha na Diretiva de Grupo (consulte a Figura 7).
Figure 7 Atributos no objeto mSDS-PasswordSettings
Atributo
Descrição
mSDS-PasswordReversibleEncryptionEnabled
Booleano indicando se as senhas são criptografadas com o uso de criptografia reversível.
mSDS-PasswordHistoryLength
Número de entradas mantidas no histórico de senhas.
mSDS-PasswordComplexityEnabled
Booleano indicando se as restrições de complexidade de senha estão habilitadas.
mSDS-MinimumPasswordLength
Inteiro definindo o comprimento mínimo de senha.
mSDS-MinimumPasswordAge
INTEGER8 indicando o tempo de vida mínimo da senha antes de poder ser alterada.
mSDS-MaximumPasswordAge
INTEGER8 indicando o tempo de vida máximo da senha antes de precisar ser alterada.
mSDS-LockoutThreshold
Inteiro indicando o número de logons com falha antes do bloqueio.
mSDS-LockoutObservationWindow
INTEGER8 indicando o número de nanossegundos dentro dos quais foi preciso que logons com falha consecutivos ocorressem para disparar o bloqueio.
mSDS-LockoutDuration
INTEGER8 indicando o número de nanossegundos em que a conta foi bloqueada.
Você atribui então a diretiva de senha a usuários ou grupos adicionando seus nomes ao atributo do PSO com valores múltiplos chamado mDS-PSOAppliesTo. Depois que você aceita a idéia de não aplicar diretivas de senha a unidades organizacionais, é bem simples. Mas há uma complexidade a mais.
Normalmente, os usuários são membros de muitos grupos. O que acontece se houver várias diretivas de senha conflitantes associadas a um usuário por causa dessas associações de grupo? Nesse caso, o ADDS usa a avaliação de precedência para determinar qual diretiva de senha deverá ser aplicada. Funciona assim:
- Se a diretiva de senha estiver vinculada diretamente a um objeto de usuário (e não através de uma associação de grupo), será aplicada.
- Caso haja várias diretivas de senha vinculadas diretamente ao usuário, a diretiva com o menor valor de precedência (conforme determinado pelo valor do atributo do PSO msDS-PasswordSettingsPrecendence) será aplicada.
- Se houver vários PSOs com a mesma precedência, aquele com o menor valor objectGUID será aplicado.
- Caso nenhum PSO esteja vinculado ao usuário, o ADDS avaliará os PSOs vinculados aos grupos do usuário. Se houver mais de um PSO, o PSO com o menor valor no atributo msDS-PasswordSettingsPrecedence será aplicado.
- Caso haja mais de um PSO com o mesmo valor de precedência, aquele com o menor valor objectGUID será aplicado.
- Se nenhum PSO estiver associado ao usuário, a diretiva de senha de domínio será usada.
Os objetos de usuário têm um novo atributo chamado msDS-ResultantPSO para ajudar a classificar exatamente qual PSO se aplica a um usuário. Esse atributo contém o nome distinto do PSO que governa a senha desse usuário.
As diretivas de senha refinadas dão mais flexibilidade do que o necessário, mas você deve gerenciar essas diretivas com cuidado e mantê-las simples. Não existe nenhum utilitário pronto para usar que defina diretivas de senha refinadas; você precisará usar ADSIEdit ou localizar um utilitário de terceiros.
Serviço Active Directory reinicializável
Sempre que você desativa o controlador de domínio para fazer manutenção da DIT, provoca alguma interrupção nos níveis de serviço de rede. Os controladores de domínio do Windows Server 2008 têm um novo recurso que permite parar o serviço de diretório sem desligar completamente o controlador de domínio.
O comando NET STOP NTDS pára o ADDS em um controlador de domínio do Windows Server 2008. Quando você faz isso, o processo do serviço LSASS no controlador de domínio continua em execução, mas descarrega todas as DLLs relacionadas ao ADDS e o serviço de diretório fica indisponível. O LSASS então se comporta basicamente como faria em um servidor membro, encaminhando as solicitações de autenticação de domínio para um controlador de domínio. Como as DLLs que processam o ADDS estão descarregadas, você pode aplicar patches relacionados ao ADDS ou executar uma desfragmentação offline da DIT. Iniciar o ADDS é tão simples como NET START NTDS. No entanto, a restauração da DIT a partir de um backup de estado do sistema ainda exige que você reinicialize no modo de reparo do serviço de diretório.
É importante compreender que o serviço de diretório não é um serviço do Windows real. Ele continua sendo um componente integrante do LSASS, que não pode ser parado sem que o computador seja desligado. Mas a capacidade de iniciar e parar o diretório de serviço no Windows Server 2008 é uma opção conveniente.
Backup e recuperação
O mecanismo inteiro de backup e restauração foi remodelado no Windows Server 2008. Não entrarei em detalhes aqui, mas o novo Backup do Windows Server tem alguma alterações que afetam o ADDS.
O Backup do Windows Server é uma solução de backup baseada em volume, o que significa que faz backup de volumes de disco inteiros de cada vez. Porém, ele só faz backup em dispositivos de disco (ou semelhantes), ou seja, não aceita backup em fita.
Existe uma opção de backup de estado do sistema para o utilitário de backup da linha de comando WBADMIN. Usando o comando WBADMIN START SYSTEMSTATEBACKUP, agora você pode criar uma imagem de backup que contém todos os arquivos do sistema necessários para restaurar o Active Directory em um controlador de domínio. No entanto, embora haja um potencial para até cinco volumes no conjunto de backup, os volumes nesse conjunto conterão apenas os arquivos necessários para uma restauração de estado do sistema. Por mais incômodo que isso seja, desde a versão RC0 do Windows Server 2008, não é possível executar um backup de estado do sistema em um compartilhamento de rede. É preciso ter um volume de disco local disponível para armazenar imagens do backup de estado do sistema e esse volume não deve fazer parte do conjunto de volumes desse backup. Talvez seja necessário adicionar um novo volume de disco a cada controlador de domínio em que você executar backups de estado do sistema.
Executar uma restauração de estado do sistema é simples. Basta inicializar o controlador de domínio no Modo de Restauração dos Serviços de Diretório e executar o comando WBADMIN START SYSTEMSTATERECOVERY. O resultado é uma DIT restaurada de forma não autoritativa, na qual é possível restaurar objetos específicos de modo autoritativo usando NTDSUTIL, exatamente como você fez no Windows Server 2003.
Um aspecto do Backup do Windows Server merece ser mencionado: ele armazena imagens de backup no formato VHD (Virtual Hard Disk). Esse é o mesmo formato que o Microsoft Virtual Server 2005 usa para armazenar suas imagens de disco virtual. Isso significa que você pode pegar uma imagem de backup criada com o Backup do Windows Server e montá-la como unidade de disco em uma máquina virtual que esteja executando o Microsoft Virtual Server. Depois é só navegar até o conteúdo do backup como se fosse uma unidade de disco normal!
Outra alteração em relação ao backup do ADDS é a capacidade de usar o Serviço de Cópias de Sombra de Volume para criar instantâneos pontuais do Active Directory. Quando você cria um instantâneo usando NTDSUTIL, o Serviço de Cópias de Sombra de Volume salva a imagem anterior de cada bloco de disco da DIT antes que ela seja substituída por uma operação de atualização. Combinando as imagens anteriores salvas com a versão atual da DIT, o Serviço de Cópias de Sombra de Volume pode construir um instantâneo completo da DIT com muito pouca sobrecarga. Um instantâneo típico leva apenas alguns segundos para ser criado, seja qual for o tamanho da DIT.
Por si só, essa é uma capacidade interessante, mas não tão útil assim. Entretanto, no Windows Server 2008, o ADDS inclui um utilitário de linha de comando chamado DSAMAIN que monta a imagem do instantâneo no modo somente leitura. Isso fornece um servidor LDAP autônomo, muito parecido com uma instância do ADLDS que inclui o conteúdo do seu diretório na época do instantâneo. Você pode procurar o diretório usando o utilitário LDP ou outras ferramentas LDAP e recuperar versões de objetos de diretório a partir de um ponto anterior no tempo.
Replicação do SYSVOL com DFS-R
O Windows Server 2003 R2 apresentou um DFS (serviço de arquivos distribuído) remodelado que incorporou um mecanismo de replicação de arquivos novo em folha chamado DFS-R. Ele usa compactação diferencial remota, o que reduz consideravelmente o tráfego de replicação de arquivos determinando quais blocos de um arquivo de destino precisam ser replicados para colocá-lo em sincronia com o arquivo de origem. No entanto, o Windows Server 2003 R2 ainda usa o Serviço de Replicação de Arquivos (e não o DFS-R) para replicar o SYSVOL entre controladores de domínio. Por causa disso, a replicação do SYSVOL continuou a ser uma fonte de problemas para os administradores do Active Directory.
Durante a execução em seu nível funcional de domínio, o Windows Server 2008 pode replicar o SYSVOL com o uso do DFS-R, aumentando a velocidade e a robustez da replicação do SYSVOL. E isso torna razoável colocar arquivos grandes no SYSVOL para disponibilizá-los em todos os controladores de domínio. Para usar o DFS-R para o SYSVOL, você deve primeiro migrar os dados antigos do SYSVOL para o DFS-R usando o utilitário DFSRMIG. Esse processo consiste em quatro etapas:
- Criar objetos do Active Directory necessários para o DFS-R.
- Criar a nova estrutura de arquivos do SYSVOL em cada controlador de domínio.
- Alternar todos os controladores de domínio para usar o novo SYSVOL.
- Remover o SYSVOL antigo.
Dependendo do tamanho do SYSVOL e do número de controladores de domínio que você tem, esse processo pode demorar um pouco, mas o desempenho e a confiabilidade aprimorados fazem o esforço valer a pena.
Aprimoramentos de auditoria
O sistema de auditoria no Active Directory para Windows Server 2003 é, ao mesmo tempo, uma benção e uma maldição. Por um lado, ele fornece uma solução bem abrangente, flexível e segura para rastrear alterações no diretório. Mas alguns podem argumentar que ele possui diversos problemas de usabilidade significativos.
A habilitação da auditoria de alterações de diretório em um controlador de domínio do Windows Server 2003 é uma questão de tudo ou nada. E o volume do tráfego de auditoria em um controlador de domínio de empresa ocupado pode tornar a auditoria impraticável. A configuração do sistema de auditoria para produzir as mensagens realmente necessárias perdendo tempo com descritores de segurança individuais é monótona e sujeita a erros. As próprias mensagens de auditoria geralmente são cifradas e, em muitos casos, não contêm as informações de que você precisa, como os valores antes e depois de atributos alterados. Além disso, coletar, correlacionar e arquivar as mensagens de vários controladores de domínio não é viável com o uso de ferramentas nativas do Windows.
O sistema de auditoria dos serviços de diretório no Windows Server 2008 resolve alguns desses problemas. Primeiro, existem quatro novas subcategorias de auditoria para auditar serviços de diretório: Acesso DS, Alterações DS, Replicação DS e Replicação Detalhada DS. Assim, se você quer apenas auditar alterações no diretório, não precisa examinar todos os eventos de replicação e leitura. Porém, se você deseja incluir exclusões de objeto em seu log de auditoria, deve habilitar Acesso DS. Isso gera mensagens para todos os acessos de objeto DS, basicamente fazendo com que você volte a gerar mensagens em excesso. E ainda depende de você configurar ou não os descritores de segurança para gerar as mensagens de auditoria que deseja para os objetos com os quais se importa.
As mensagens de auditoria foram substancialmente limpas para que fiquem legíveis e contenham os dados necessários. Em especial, as alterações no diretório geram entradas de log de auditoria que contêm os valores novos e antigos de atributos alterados. Esse é um aprimoramento enorme. A única desvantagem aqui é que os valores novos e antigos aparecem em entradas separadas do log de auditoria, por isso você tem de correlacioná-las para compreender realmente a alteração que foi feita. Muitos dos produtos da coleção complementar de logs de auditoria, como os Serviços de Coleta de Auditoria da Microsoft, oferecem suporte a esse tipo de correlação.
Aprimoramentos na interface do usuário
Os snap-ins do MMC Usuários e Computadores do Active Directory, Domínios e Relações de Confiança, e Sites e Serviços sempre foram adequados para gerenciar o Active Directory. No Windows Server 2008, foram removidas as ferramentas administrativas básicas e introduzidos alguns recursos novos interessantes. Se você habilitar Recursos Avançados, a caixa de diálogo Propriedades referente a cada objeto exibirá uma guia adicional intitulada Editor de Atributos. Essa é mesma guia usada pelo ADSIEdit, que permite inspecionar e editar todos os atributos do objeto. A guia em si agora oferece melhor decodificação de atributos codificados, como o userAccountControl. A Figura 8 mostra o quão integrado está o editor de atributos.
Figura 8 Editor de atributos em Usuários e Computadores do Active Directory (Clique na imagem para aumentar a exibição)
Conclusão
Além dos pontos principais que discutimos neste artigo, existem muitos outros aprimoramentos que você encontrará no ADDS do Windows Server 2008. Por exemplo, o KDC usa a criptografia AES de 256 bits (AES-256) se o domínio está no nível funcional de domínio do Windows Server 2008. Você pode habilitar a Prevenção Contra Exclusão Acidental de objetos marcando a caixa apropriada na guia Objeto referente a qualquer objeto DS. O Mecanismo de Armazenamento Extensível que fornece o serviço de gerenciamento de dados foi aperfeiçoado para usar correção de erro de bit único, reduzindo a probabilidade de um erro de hardware ou software no subsistema de disco corromper a DIT. O serviço DNS começa a processar solicitações antes de carregar completamente o banco de dados DNS. O módulo do localizador de controladores de domínio foi aprimorado para que, caso não consiga localizar um controlador de domínio no site desejado, tente localizá-lo no próximo site mais próximo em vez de simplesmente usar qualquer controlador de domínio que puder encontrar no domínio. E agora NTDSUTIL dá suporte a RODCs e a instantâneos do Serviço de Cópias de Sombra de Volume.
Sem dúvida, o Windows Server 2008 oferece um número substancial de aprimoramentos nos Serviços de Domínio Active Directory. Juntas, essas alterações melhoram consideravelmente a segurança e a gerenciabilidade do ADDS. O melhor, porém, é que a integração do Windows Server 2008 ao ambiente do Active Directory não envolve uma migração massiva; é um processo fácil e incremental.
Fonte: revista technet windows 2008
