Configurando e entendendo as “Operações Mestres” (FSMO) do Active Directory

Introdução

Sem dúvida, o surgimento do Windows 2000 foi uma grande revolução na maneira de se administrar e organizar uma rede corporativa. E grande crédito disto se deve à introdução do conceito de Diretório Ativo (Active Directory). Isto porque novos conceitos foram introduzidos neste modelo. O Windows 2003 continua trabalhando sobre esta mesma base, e estes conceitos ainda são muito úteis.

Um destes conceitos está relacionado ao modo como as informações deste diretório ativo são disponibilizadas. No modelo antigo, usado no Windows NT 4.0, havia um único servidor no domínio responsável por processar e disponibilizar informações vitais, como criação e alteração de usuários e grupos, gerenciamento de senhas, etc. Este servidor era conhecido como PDC (Primary Domain Controller), o coração do domínio. Havia logicamente modelos de redundância, os chamados BDC (Backup Domain Controllers), porém estes possuíam uma cópia "Somente-Leitura" dos dados. A maior parte das tarefas era processada única e exclusivamente pelo PDC. Este modelo era conhecido como "Single-Master".

Com o Active Directory, o conceito PDC-BDC foi modificado. Todos os "Controladores de Domínio" passaram a armazenar uma cópia do diretório ativo que poderia ser modificada. Assim, a redundância das informações e a distribuição de carga poderia ser melhor aproveitada, pois todos os controladores poderiam processar alterações eles mesmos, sem a necessidade de repassar para um servidor Mestre. Este modelo é conhecido como "Multi-Master".

Porém, este modelo necessita possuir alguns tipos de controles especiais. É necessário tratar os "conflitos" que podem existir. Por exemplo, em um SERVIDOR1, um operador pode estar alterando a senha de um USUÁRIO-A, e, ao mesmo tempo, no SERVIDOR2, um segundo operador pode estar excluindo o USUÁRIO-A. É para casos como estes que ainda é necessário que apenas um servidor no domínio controle ou previna tais tipos de conflitos. E isto é feito utilizando-se algumas regras, conhecidas como "Flexible Single-Master Operation", ou FSMO, que, se configuradas de maneira incorretas, podem prejudicar e afetar o bom funcionamento de uma rede.

Nossa intenção é descrever cada uma destas regras e como devem ser configuradas da melhor maneira possível.

Definindo cada FSMO

Inicialmente, vale mencionar que apenas servidores do tipo "Domain Controllers" (DC) podem ser configurados para hospedar uma das FSMO, já que estes servidores possuem uma cópia do tipo "Escrita" do Active Directory. As FSMO são divididas em 2 grupos:

• Floresta: são regras que afetam toda uma floresta Windows 2000 ou 2003 e podem ser hospedadas por qualquer DC dentro da floresta.

• Domínio: são regras que afetam apenas um domínio Windows 2000 ou 2003, e podem ser hospedadas por DCs dentro do domínio.

Ao todo, temos cinco FSMO, duas que afetam a floresta como um todo e outras três que afetam um domínio, conforme explicação abaixo:

• Floresta

  • Schema Master: O Schema é o coração do Active Directory. Ele é composto de objetos e atributos, que modelam o Active Directory. É através do Schema que dizemos, por exemplo, que o objeto do tipo "USUÁRIO" terá os atributos "NOME", "ENDEREÇO", "TELEFONE", etc. Como o esquema pode ser customizado e deve ser o mesmo em toda a floresta Windows, a regra "Schema Master" se encarrega de evitar conflitos entre os DCs.

  • Domain Naming Master: Se você adiciona um novo domínio em uma floresta (por exemplo, se você adiciona um domínio filho), o nome deste domínio deve ser único na floresta. É esta regra responsável por assegurar isto e evitar conflitos entre outros domínios.

• Domínio

  • PDC Emulator: Como o nome já diz, uma das funções desta regra é "emular" um PDC NT 4.0 para manter a compatibilidade com servidores legados (por exemplo, BDCs NT 4.0) e clientes mais antigos. Mesmo que você migre todo seu ambiente para Windows 2000 ou 2003, esta regra ainda é importante, pois é responsável por tratar alterações de contas de usuários, "lockouts" de contas, relações de confianças com outros domínios e pelo sincronismo do relógio no domínio.

  • RID Master. Qualquer DC pode criar novos objetos (usuários, grupos, contas de computadores). Cada objeto deve possuir um identificador único, conhecido como SID. O SID do objeto é construído usando o SID do domínio, mais um ID relativo (RID). Porém, após criar 512 objetos, um DC precisa contatar o RID Master para conseguir mais 512 RIDs (atualmente, um DC contata o RID Master quando ele possui menos de 100 RIDs disponíveis). Isto evita que dois objetos diferentes tenham o mesmo RID em todo o domínio.

  • Infrastructure Master. Esta regra é muitas vezes conhecida apenas como "cosmética", já que sua função é se assegurar que o "Display Name" de usuários pertencentes a um grupo sejam atualizados caso este atributo seja alterado. Ele é mais importante em ambientes que possuem vários domínios, pois vai assegurar que todos os grupos que um determinado usuário pertença irá refletir o "Display Name" correto.

Assim, se você possui uma floresta com um único domínio, você terá cinco FSMO (duas das florestas, mais três do seu único domínio). Já uma floresta com dois domínios, você terá oito FSMO (duas da floresta, mais três por cada domínio).

Existem inúmeros métodos de se verificar quais DCs hospedam as FSMO dentro da floresta ou domínio. Uma delas é simplesmente instalar o "Support Tools" a partir do diretório \Support\Tools do CD de instalação do Windows 2000 / 2003 e digitar o comando "netdom query fsmo" em um prompt de comando:

Problemas com FSMO

Se uma das FSMO falhar, com certeza você terá problemas em seu ambiente. A tabela abaixo ajuda a identificar possíveis problemas que possam ocorrer:

Regras para configurações das FSMO

DCs irão hospedá-las. Por padrão, quando você instala o primeiro DC da sua floresta (que neste caso é também o domínio raiz ou root), este DC irá hospedar as cinco FSMO. Quando você instala o primeiro DC de qualquer outro domínio dentro de sua floresta, ele irá hospedar as três FSMO do domínio. Porém, dependendo da complexidade do seu ambiente, este comportamento padrão pode não ser o mais apropriado e você deve transferir algumas regras para máquinas diferentes para um melhor desempenho. Os artigos KB 223787 e KB 255504 descrevem como este procedimento deve ser efetuado.

As regras a seguir podem ser usadas na definição das FSMO:

1 - PDC Emulator e RID Master devem estar na mesma máquina porque o PDC Emulator é um grande consumidor de RID´s

Dica: Como o PDC Emulator é a regra mais utilizada num ambiente Windows, se a máquina que hospeda estas duas regras está com um alto nível de utilização, é necessário mover estas regras para um outro DC (de preferência que não seja um Global Catalog (GC), já que este também possui alta utilização) ou realizar um upgrade de hardware.

2 - Infrastructure Master não deve estar em um DC que também é GC (Global Catalog)

Dica: Certifique-se que o Infrastructure Master e o GC estejam em um mesmo site físico e que estes dois DCs sejam configurados como "Replication Partner", usando o "Active Directory Sites and Services".

Exceção 1: se você possui apenas um domínio (Single Domain), você pode ter na mesma máquina o Infrastructure Master e o GC
Exceção 2: se todos os DCs em sua floresta são também GC, você pode ter o Infrastructure Master junto com o GC.

3 - Para um gerenciamento facilitado, Schema Master e Domain Naming Master podem estar na mesma máquina, que deve ser também um Global Catalog (GC).

4 - De tempos em tempos, verifique se todas as FSMO estão disponíveis e funcionando corretamente.

Conclusão

Sem dúvida, o assunto Active Directory exige muita dedicação e estudo por parte do profissional que deseja dominá-lo. As FSMO desempenham um papel importante neste ambiente e seu bom entendimento e configuração, sem dúvida, irá trazer inúmeros benefícios para o ambiente administrado.

Danilo Bordini é MCSE e MCSA em Windows 2000 / 2003 e trabalha atualmente coordenando e implementando projetos de infra-estrutura de redes Microsoft e segurança da informação. Trabalha na área de informática desde 1996, nos últimos anos se especializando em ambientes de alta disponibilidade e soluções para Internet, participando de vários projetos de implementações e migrações de redes para o ambiente Microsoft. Danilo é MVP em Windows Server - Directory Services.