Introdução resumida ao Active Directory (AD)
Nuno Alexandre Magalhães Pereira; Novembro de 2005.
O Active Directory (AD) é, com toda a certeza, o componente mais importante do Windows 2000/2003 (W2K/2K3). É também um dos componentes mais complexos e dos mais omnipresentes: Uma boa parte das funcionalidades mais relevantes do W2K/2K3 requerem o AD.
Afinal o que é o AD? E, já agora: “Active Directory”... isso não é um nome um pouco estranho?
O nome “Directory” advém da utilização, na língua inglesa, da designação de “office directories” ou “phone
directories” para referir listas com informação pessoal. Quanto ao “Active”, apenas pode ser atribuído ao marketing…
O AD é, na sua essência, uma base de dados onde é guardada informação sobre utilizadores, grupos, máquinas, etc. No seu âmago encontra-se um motor de base de dados, chamado ESE (Extensible Storage Engine), que é uma variante do motor do Access (chamado JET Joint Engine Technology).
Adicionalmente, este tipo de base de dados (de utilizadores, grupos, máquinas, …) tende a ser mais lida que escritas e isto permite introduzir algumas optimizações no motor da base de dados, para aproveitar esse facto. Isto não esclarece muito sobre o nome encontrado para esta tecnologia, mas acontece que, os especialistas de bases de dados, costumam dar o nome de “directory” a este tipo de bases de dados.
Os diversos recursos armazenados no AD recebem o nome de objectos. Estes objectos podem ser máquinas, utilizadores, informação sobre estes, impressoras, políticas de segurança, etc. Cada objecto contém um conjunto de atributos que o caracterizam. Por exemplo, os atributos de uma conta de utilizador podem incluir o primeiro e último nome do utilizador, departamento, endereço de correio electrónico, etc.
Figura 1. Objectos e atributos no AD
Um facto importante sobre o AD é a interface que disponibiliza.
Antes, poderia acontecer que, para cada serviço da rede, o utilizador se tivesse de autenticar perante esse serviço (BD, NetWare, Mail, ...). O ideal seria poder entrar no sistema operativo e depois este trataria de autenticar o utilizador junto de outros serviços. O problema era: Como os fabricantes de software iriam fazer os seus produtos perguntar ao SO se um utilizador particular pode utilizar o seu serviço? E como podiam confiar que a Microsoft não iria mudar essa interface, caso existisse, numa futura versão? Bom, com o W2K a Microsoft tentou responder a esta
questão: Baseou a interface do AD numa norma chamada LDAP (Lightweight Directory Access Protocol), que faz parte da norma X.500. Desta forma “abriu” o AD para outros fabricantes de software.
Resumindo algumas das propriedades mais relevantes do AD:
- Dispõe de uma interface normalizada: LDAP (Lightweight Directory Access Protocol); - Contas de utilizadores e máquinas centralizadas;
- Servidores que funcionam como servidores de autenticação: Controladores de domínio; - Funciona como um índice dos recursos na rede;
- Domínios muito maiores (comparado com versões anteriores de servidores Windows); - Subdivisão de domínios em unidades lógicas;
- Delegação de tarefas administrativas;
- Melhoria dos processos de replicação. Através da criação de sites; - Facilita o processo de construir e manter múltiplos domínios; - Unificação do sistema de nomes: Baseado em DNS;
- Implementação de políticas de utilização do sistema (Group Policies). Nas secções seguintes, iremos abordar alguns conceitos básicos sobre o AD.
1. Componentes básicos do AD
Os objectos que podem ser armazenados no AD estão definidos no AD Schema. Este define não só os tipos de objectos como os tipos dos atributos de cada objecto. As definições em si são também elas próprias objectos, de forma a poderem ser geridas da mesma forma que os restantes objectos.
O AD contém componentes que permitem representar as estruturas lógicas da organização: Domínios, Unidades Organizacionais (organizational units - OUs), Árvores e Florestas.
O Global Catalog contém um resumo dos objectos guardados no AD.
Adicionalmente, existem componentes que permitem representar a estrutura física: Sites e Controladores de Domínio. Vamos agora ver cada um destes componentes.
Domínios
Esta é a unidade básica da estrutura lógica do AD. De uma forma simples, um Domínio é uma unidade de segurança, que define os direitos administrativos sobre um grupo de recursos. De salientar, no entanto, que o AD permite que estes direitos possam ser delegados a sub-divisões do domínio, chamadas Unidades Organizacionais (Organizational Units - OUs).
Figura 2. Recursos organizados hierarquicamente em estruturas lógicas.
O AD permite a criação de domínios com milhões de objectos, tornando possível desenvolver domínios a uma escala muito alargada: É perfeitamente aceitável o cenário de uma empresa de dimensão mundial, com apenas um domínio.
Em versões anteriores (NT4), este era um cenário impossível, principalmente porque os domínios eram muito mais limitados na quantidade de utilizadores que suportavam, não permitiam a criação de divisões do domínio com diferentes poderes de administração, e também porque os Controladores de Domínio não possuíam forma de saber como estavam conectados entre si, assim iriam efectuar as tarefas de cópia de informação respeitante ao domínio da mesma forma, quer estivessem na mesma rede local, ou ligados através de uma conexão de área alargada com muito menor capacidade.
Existem, no entanto, algumas razões para criar domínios diferentes no W2K, estas podem ser razões políticas ou razões técnicas. Não nos iremos abordar as razões políticas. Quanto às razões técnicas, estas podem incluir:
problemas de cópia da informação respeitante ao AD, devido a uma largura de banda muito reduzida ou conexões pouco fiáveis. Embora o W2K possua mecanismos para lidar com este aspecto (criação de Sites), podem existir casos em que as conexões impedem a replicação normal entre os Controladores de Domínio;
políticas de contas de utilizadores diferentes. O W2K apenas permite a definição de políticas como “quantas vezes um utilizador pode falhar a introdução da sua palavra-chave” ou “quando deve um utilizador ser obrigado a trocar de palavra-chave” a um nível de domínio; Ou por
razões de segurança: Como cada Controlador de Domínio contém uma cópia do AD para toda a organização. Se alguém mal intencionado conseguir obter o AD (por exemplo, simplesmente roubando o disco de um controlador numa delegação distante onde são mais descuidados em termos de segurança física dos servidores) poderá eventualmente conseguir decifrar a informação aí contida e conseguir as palavras-chave de todo o domínio.
Unidades Organizacionais (Organizational Units - OUs)
Como referido, os domínios podem ser divididos em OUs. Estas são utilizadas como contentores, para organizar objectos dentro de um domínio em grupos administrativos lógicos que reflectem de alguma forma a estrutura organizacional ou estrutura de negócio da organização.
Utilizando OUs é possível delegar direitos administrativos sobre grupos de recursos. Na figura 3, foram criadas três OUs: US, ORDERS e DISP, estas podem reflectir conjuntos de direitos administrativos diferentes. Por exemplo poderia ser desejado que os administradores de ORDERS tenham capacidade para adicionar/remover utilizadores, e permitir acesso aos ficheiros e impressoras afectos a essas OUs. Mas, aos administradores da DISP, não se desejava dar a permissão para criar modificar os utilizadores.
Figura 3. Recursos organizados hierarquicamente em estruturas lógicas.
Por omissão, as permissões das OUs são “herdadas” dos seus superiores. Portanto (observando a Figura 3), se ORDERS e DISP fossem “filhos” de US seria possível atribuir uma gama mais alargada de permissões a US e restringir, através das propriedades da herança, as permissões específicas para cada uma das OUs.
Árvores e Florestas
Árvores e Florestas são estruturas que permitem poupar o administrador da tarefa de construir relações de confiança entre os domínios que administra.
As árvores são grupos de domínios. Entre os domínios de uma árvore são criadas relações de confiança bidireccionais (domínio A confia no domínio B e B confia em A) e transitivas (por exemplo, na figura 4, se sls.uk.microsoft.com possuí uma relação de confiança com uk.microsoft.com, então também possuí uma relação de confiança com microsoft.com).
Figura 5. Uma árvore de domínios
As florestas não são mais do que grupos de árvores (como seria de esperar…). Entre as árvores de uma floresta são também criadas relações de confiança bidireccionais e transitivas.
Mas porque necessitamos de florestas afinal? Não poderíamos passar apenas com árvores? Os grupos de domínios criados pelas árvores têm um problema: Os nomes têm de estar dentro de uma hierarquia. Ou seja, os sub-domínios têm de incluir os nomes dos domínios superiores. Pode acontecer que este “arranjo” não seja possível para uma determinada organização. E é para isso que existem as florestas.
Figura 6. Uma floresta de árvores
Escondido nesta admirável noção de juntar domínios em árvores e árvores em florestas existe um problema: Não é possível juntar domínios já existentes a uma árvore ou juntar árvores já existentes a uma floresta. A única forma de adicionar um domínio a uma árvore ou uma árvore a uma floresta é construindo o domínio de raiz dentro de uma árvore ou floresta já existente.
Acontece também que não é possível criar relações de confiança bidireccionais e transitivas manualmente. Apenas relações num só sentido e não transitivas.
A solução para o problema de inserir um domínio já existente a uma árvore ou floresta seria criar um novo domínio vazio e depois copiar toda a informação deste para o novo domínio.
O W2K3 veio colmatar de alguma forma este problema, pois é possível criar relações de confiança bidireccionais e transitivas entre florestas. No entanto, para tal será necessário ter todos os controladores de domínio da floresta com W2K3.
Grupos
Os grupos permitem juntar conjuntos de utilizadores, sobre os quais serão aplicadas as mesmas permissões. Na sua essência, grupos são um tipo especial de conta, que podem incluir não só utilizadores como também máquinas. É
necessário chamar à atenção para o facto de, apesar do seu nome, as políticas de grupo1 não são aplicadas a grupos, mas sim a OUs.
Agora iremos rever brevemente cada um dos diferentes tipos de grupos existentes: • Machine local groups; Domain local groups
o Grupos locais; Para atribuição de privilégios locais e acesso a recursos locais. Deve-se tentar colocar outros grupos dentro dos grupos locais e tentar manter o número de membros pequeno. • Domain global groups
o Grupos globais; Para reunir utilizadores e outros grupos globais no mesmo domínio que necessitam dos mesmos privilégios ou acesso aos mesmos recursos. Colocar estes grupos dentro de grupos locais que possuem os privilégios pretendidos.
• Universal groups
o Grupos Universais; Apenas podem ser utilizados quando estamos em modo nativo (modo nativo do W2K refere-se ao modo de funcionamento do domínio, por razões de compatibilidade com versões anteriores. Os grupos universais são uma das principais razões para a existência de diferentes modos de funcionamento, pois este tipo de grupos não é compatível com NT42). Deve-se manter o número de membros pequeno. A melhor forma para utilizar estes grupos é colocar grupos globais dentro destes, evitando colocar utilizadores ou máquinas directamente dentro de grupos universais (na secção seguinte, respeitante ao Global Catalog, explica-se porquê).
Deve-se evitar fazer muitos níveis imbricados de grupos, pois tal terá impacto sobre o desempenho do sistema. A imagem seguinte mostra a forma como os grupos podem ser colocados dentro de outros grupos.
Figura 7. Que grupos vão para dentro de outros grupos
Global Catalog (GC)
O GC é uma versão abreviada da informação sobre cada um dos domínios na floresta, servindo como elo de ligação entre os domínios. Contém uma relação dos UPNs (User Principal Name, que será discutido mais adiante) dos utilizadores e dos domínios a que pertencem, informação sobre os grupos globais e também sobre os grupos universais.
No caso dos grupos universais, o GC também guarda cada um dos seus membros. Por esta razão, não é recomendada a utilização de muitos grupos universais.
1 Políticas de Grupo (Group Policies), são o substituto (W2K/2K3) das políticas de sistema (system policies) do NT4, basicamente permitem manipular atributos do registry, de forma a implementar políticas de utilização do sistema. Exemplos: Ajustar os direitos dos utilizadores; Restringir as aplicações que os utilizadores podem utilizar; Configuração do ambiente de trabalho dos utilizadores; etc
2 Neste aspecto, o W2K3 introduziu ainda mais complexidade. Enquanto no W2K existiam apenas dois modos de funcionamento, (nativo - native e combinado - mixed), no W2K3, os modos de funcionamento passam a denominar-se functional levels. Existem (quatro) ao nível do domínio (domain functional levels) e (dois) ao nível da floresta (forest functional levels).
Figura 8. Global Catalog
O GC foi concebido para melhorar o desempenho das consultas sobre objectos do AD e, adicionalmente, reduzir o tráfego gerado para o fazer. Porque contém informação sobre todos os domínios da floresta, permite que as consultas não necessitem de percorrer vários domínios até encontrar a resposta.
Para motivar a importância do GC, podemos dizer que este é uma peça fundamental para o login de utilizadores em estruturas múltiplo domínio W2K. Sem um servidor do GC disponível, um utilizador apenas conseguirá fazer login localmente. Vamos ver porquê. (Já agora, como é que uma máquina encontra o servidor do GC, para fazer a sua consulta? – Resposta: Através do DNS.)
Com o W2K, qualquer utilizador de um domínio pode (a menos que existam políticas de segurança que digam o contrário) entrar em qualquer máquina pertencente à floresta, sendo identificado pelo seu UPN (User Principal
Name). O UPN é uma simplificação na forma como os utilizadores se identificam perante o sistema. Um UPN tem
um formato semelhante a um endereço de correio electrónico (por exemplo, zé@dei-isep.pt), o utilizador pode entrar no sistema introduzindo o seu nome (zé) e o domínio a que pertence (dei-isep.pt), ou pode simplesmente indicar o seu UPN. Adicionalmente, o sufixo UPN (neste caso: dei-isep.pt) não necessita de ter nada a ver com o nosso domínio, por exemplo podíamos atribuir o UPN zé@asi1.pt, mas o nosso utilizador ser, na realidade, um utilizador do domínio dei-isep.pt. Para isso teríamos apenas de definir o sufixo asi1.pt como um sufixo UPN válido (na ferramenta “Active Directory Domains and Trusts”). Esta simplificação para os utilizadores, adiciona complexidade ao processo de autenticação do utilizador, pois quando um utilizador se identifica desta forma é depois necessário descobrir a que domínio o utilizador pertence na realidade. Esta é uma das funções do GC.
Num domínio com apenas um controlador (que, deve-se dizer, é uma situação pouco recomendável), o GC encontra-se no próprio Controlador de Domínio. No caso de existirem múltiplos Controladores de Domínio, é possível designar quais terão também o papel de serem servidores do GC (Global Catalog Servers).
Sites
Os Sites existem para reflectirem as interligações físicas entre as máquinas de um domínio. Desta forma, os Controladores de Domínio ficam a saber se estão a comunicar via uma conexão de alta velocidade ou se, por outro lado, a conexão é lenta e devem aplicar maior parcimónia na utilização da conexão.
Tipicamente os Sites são definidos pelas redes de área local da organização. Todas as máquinas de uma determinada rede local estarão, à partida, no mesmo Site.
Controladores de Domínio
Os Controladores de Domínio são máquinas com o W2K Server que guardam uma cópia do AD. Em W2K, um domínio pode ter vários Controladores de Domínio e estes encarregam-se de manter cada uma das suas cópias do AD consistentes entre si, através de um processo de replicação explicado adiante.
É necessário ter em conta que, a replicação junto de um determinado Controlador de Domínio por todos os outros controladores, pode demorar algum tempo. Por isso, as alterações submetidas a um determinado Controlador de Domínio (por exemplo, alteração de palavras-chave, adição de utilizadores) podem demorar algum tempo a se propagar pelos outros controladores.
1.1.1. Replicação
O processo de transferência de informação do AD, entre Controladores de Domínio de uma floresta, de modo a manter a homogeneidade é denominado de replicação.
A replicação ocorre de uma forma periódica. A informação sobre os Sites (como vimos, são estruturas que definem as interligações entre as máquinas de um domínio) definidos é utilizada para gerir a forma como a replicação acontece. A replicação entre controladores do mesmo Site acontece de forma mais frequente que entre controladores em Sites diferentes.
Entre Controladores de Domínio que se encontram dentro do mesmo Site, um programa denominado KCC (Knowledge Consistency Checker) executa periodicamente e elabora uma topologia para a replicação da informação de uma eficiente.
Figura 9. Topologia de Replicação
Quando temos os nossos Controladores de Domínio a operar em modo nativo, estes não irão efectuar replicação com os controladores de versões anteriores ao W2K.
A replicação entre controladores de Sites diferentes dá-se de uma forma semelhante, no entanto existe um cuidado especial na utilização das ligações entre os Sites e a informação das actualizações é comprimida.
