O que são os Serviços de Domínio Active Directory e como funcionam?

O que é o Active Directory?

O Active Directory Domain Services é o Directory Server da Microsoft. Ele fornece mecanismos de autenticação e autorização, bem como uma estrutura na qual outros serviços relacionados podem ser implantados (Serviços de Certificado do AD, Serviços Federados do AD, etc.). É um banco de dados compatível com LDAP que contém objetos. Os objetos mais usados ​​são usuários, computadores e grupos. Esses objetos podem ser organizados em unidades organizacionais (OUs) por qualquer número de necessidades lógicas ou de negócios. Objetos de Diretiva de Grupo (GPOs) podem ser vinculados a UOs para centralizar as configurações de vários usuários ou computadores em uma organização.

Quando as pessoas dizem "Active Directory", elas normalmente estão se referindo a "Serviços de Domínio Active Directory". É importante observar que existem outras funções/produtos do Active Directory, como Serviços de Certificados, Serviços de Federação, Serviços de Diretório Leves, Serviços de Gerenciamento de Direitos etc. Esta resposta se refere especificamente aos Serviços de Domínio Active Directory.

O que é um domínio e o que é uma floresta?

Uma floresta é um limite de segurança. Objetos em florestas separadas não podem interagir entre si, a menos que os administradores de cada floresta separada criem uma relação de confiança entre eles. Por exemplo, uma conta de administrador corporativo para domain1.com, que normalmente é a conta mais privilegiada de uma floresta, não terá nenhuma permissão em uma segunda floresta chamada domain2.com, mesmo se essas florestas existirem na mesma LAN, a menos que haja uma relação de confiança no local .

Se você tiver várias unidades de negócios separadas ou precisar de limites de segurança separados, precisará de várias florestas.

Um domínio é um limite de gerenciamento. Os domínios fazem parte de uma floresta. O primeiro domínio em uma floresta é conhecido como domínio raiz da floresta. Em muitas organizações pequenas e médias (e até mesmo algumas grandes), você encontrará apenas um único domínio em uma única floresta. O domínio raiz da floresta define o namespace padrão para a floresta. Por exemplo, se o primeiro domínio em uma nova floresta for denominado domain1.com, esse será o domínio raiz da floresta. Se você tiver uma necessidade comercial de um domínio filho, por exemplo - uma filial em Chicago, você pode nomear o domínio filho chi. O FQDN do domínio filho seriachi.domain1.com. Você pode ver que o nome do domínio filho foi anexado ao nome do domínio raiz da floresta. Normalmente é assim que funciona. Você pode ter namespaces separados na mesma floresta, mas isso é uma lata de worms totalmente separada para um momento diferente.

Na maioria dos casos, você vai querer fazer todo o possível para ter um único domínio do AD. Ele simplifica o gerenciamento e as versões modernas do AD facilitam muito a delegação de controle com base na UO, o que diminui a necessidade de domínios filho.

Eu posso nomear meu domínio como eu quiser, certo?

Na verdade, não. dcpromo.exe, a ferramenta que trata da promoção de um servidor a um DC não é à prova de idiotas. Ele permite que você tome decisões erradas com sua nomenclatura, portanto, preste atenção a esta seção se não tiver certeza. (Edit: dcpromo está obsoleto no Server 2012. Use o Install-ADDSForestcmdlet do PowerShell ou instale o AD DS do Gerenciador do Servidor.)

Em primeiro lugar, não use TLDs inventados como .local, .lan, .corp ou qualquer outra porcaria. Esses TLDs não são reservados. A ICANN está vendendo TLDs agora, então o mycompany.corpque você está usando hoje pode pertencer a alguém amanhã. Se você possui mycompany.com, a coisa inteligente a fazer é usar algo como internal.mycompany.comou ad.mycompany.compara seu nome interno do AD. Se você usar mycompany.comcomo um site que pode ser resolvido externamente, evite usá-lo também como seu nome de AD interno, pois você acabará com um DNS de cérebro dividido.

Controladores de domínio e catálogos globais

Um servidor que responde a solicitações de autenticação ou autorização é um controlador de domínio (DC). Na maioria dos casos, um Controlador de Domínio manterá uma cópia do Catálogo Global . Um Catálogo Global (GC) é um conjunto parcial de objetos em todos os domínios de uma floresta. É diretamente pesquisável, o que significa que as consultas entre domínios geralmente podem ser executadas em um GC sem a necessidade de uma referência a um DC no domínio de destino. Se um DC for consultado na porta 3268 (3269 se estiver usando SSL), o GC estará sendo consultado. Se a porta 389 (636 se estiver usando SSL) for consultada, uma consulta LDAP padrão está sendo usada e objetos existentes em outros domínios podem exigir uma referência .

Quando um usuário tenta fazer logon em um computador que está associado ao AD usando suas credenciais do AD, a combinação de nome de usuário e senha com sal e hash é enviada ao DC para a conta de usuário e a conta de computador que está fazendo logon. computador faz login também. Isso é importante, porque se algo acontecer com a conta do computador no AD, como alguém redefinir a conta ou excluí-la, você poderá receber um erro informando que não existe uma relação de confiança entre o computador e o domínio. Mesmo que suas credenciais de rede estejam corretas, o computador não é mais confiável para fazer login no domínio.

Preocupações com a disponibilidade do controlador de domínio

Ouço "Tenho um controlador de domínio primário (PDC) e quero instalar um controlador de domínio de backup (BDC)" com muito mais frequência do que gostaria de acreditar. O conceito de PDCs e BDCs morreu com o Windows NT4. O último bastião para PDCs estava em um AD de modo misto de transição do Windows 2000 quando você ainda tinha DCs NT4 por perto. Basicamente, a menos que você esteja suportando uma instalação com mais de 15 anos que nunca foi atualizada, você realmente não tem um PDC ou um BDC, você só tem dois controladores de domínio.

Vários DCs são capazes de responder a solicitações de autenticação de diferentes usuários e computadores simultaneamente. Se um falhar, os outros continuarão a oferecer serviços de autenticação sem ter que fazer um "primário" como você teria que fazer nos dias do NT4. É uma prática recomendada ter pelo menos dois DCs por domínio. Esses DCs devem conter uma cópia do GC e devem ser servidores DNS que também mantêm uma cópia das zonas DNS integradas do Active Directory para seu domínio.

Funções do FSMO

"Então, se não há PDCs, por que há uma função PDC que apenas um único DC pode ter?"

Eu ouço muito isso. Há uma função de emulador PDC . É diferente de ser um PDC. Na verdade, existem 5 funções de operações mestre únicas flexíveis (FSMO) . Essas também são chamadas de funções de Mestre de Operações. Os dois termos são intercambiáveis. O que são e o que fazem? Boa pergunta! Os 5 papéis e suas funções são:

Mestre de nomenclatura de domínio - há apenas um mestre de nomenclatura de domínio por floresta. O mestre de nomenclatura de domínio garante que, quando um novo domínio for adicionado a uma floresta, ele seja exclusivo. Se o servidor que mantém essa função estiver offline, você não poderá fazer alterações no namespace do AD, o que inclui coisas como adicionar novos domínios filho.

Mestre de Esquema - Existe apenas um Mestre de Operações de Esquema em uma floresta. Ele é responsável por atualizar o Esquema do Active Directory. As tarefas que exigem isso, como preparar o AD para uma nova versão do Windows Server funcionando como um DC ou a instalação do Exchange, exigem modificações de esquema. Essas modificações devem ser feitas a partir do Schema Master.

Mestre de Infraestrutura - Há um Mestre de Infraestrutura por domínio. Se você tiver apenas um único domínio em sua floresta, não precisará se preocupar com isso. Se você tiver várias florestas, certifique-se de que essa função não seja mantida por um servidor que também seja um detentor de GC, a menos que cada DC na floresta seja um GC . O mestre de infraestrutura é responsável por garantir que as referências entre domínios sejam tratadas corretamente. Se um usuário em um domínio for adicionado a um grupo em outro domínio, o mestre de infraestrutura dos domínios em questão se certificará de que ele seja tratado corretamente. Essa função não funcionará corretamente se estiver em um catálogo global.

RID Master - O Relative ID Master (RID Master) é responsável por emitir pools RID para DCs. Há um mestre RID por domínio. Qualquer objeto em um domínio do AD tem um identificador de segurança (SID) exclusivo. Este é composto por uma combinação do identificador de domínio e um identificador relativo. Cada objeto em um determinado domínio tem o mesmo identificador de domínio, então o identificador relativo é o que torna os objetos únicos. Cada DC tem um pool de IDs relativos para usar, portanto, quando esse DC cria um novo objeto, ele acrescenta um RID que ainda não foi usado. Como os DCs são emitidos em pools não sobrepostos, cada RID deve permanecer exclusivo durante a vida útil do domínio. Quando um DC chega a ~100 RIDs restantes em seu pool, ele solicita um novo pool do RID master. Se o mestre RID estiver offline por um longo período de tempo, a criação do objeto poderá falhar.

Emulador de PDC - Finalmente, chegamos ao papel mais incompreendido de todos, o papel de emulador de PDC. Há um emulador de PDC por domínio. Se houver uma tentativa de autenticação com falha, ela será encaminhada ao emulador PDC. O emulador PDC funciona como o "desempate" se uma senha foi atualizada em um DC e ainda não foi replicada para os outros. O emulador PDC também é o servidor que controla a sincronização de tempo no domínio. Todos os outros DCs sincronizam seu tempo do emulador PDC. Todos os clientes sincronizam seu horário do DC ao qual efetuaram login. É importante que tudo permaneça dentro de 5 minutos um do outro, caso contrário o Kerberos quebra e quando isso acontece, todos choram.

O importante a lembrar é que os servidores em que essas funções são executadas não são imutáveis. Geralmente é trivial mover essas funções, portanto, embora alguns DCs façam um pouco mais do que outros, se ficarem inativos por curtos períodos de tempo, tudo funcionará normalmente. Se eles estiverem inativos por muito tempo, é fácil transferir as funções de forma transparente. É muito melhor do que os dias do NT4 PDC/BDC, então, por favor, pare de chamar seus DCs por esses nomes antigos. :)

Então, hum... como os DCs compartilham informações se eles podem funcionar independentemente um do outro?

Replicação, é claro . Por padrão, os DCs pertencentes ao mesmo domínio no mesmo site replicarão seus dados entre si em intervalos de 15 segundos. Isso garante que tudo esteja relativamente atualizado.

Existem alguns eventos "urgentes" que acionam a replicação imediata. Esses eventos são: Uma conta é bloqueada por muitos logons com falha, uma alteração é feita na senha do domínio ou nas políticas de bloqueio, o segredo LSA é alterado, a senha é alterada em uma conta de computador do DC ou a função RID Master é transferida para um novo DC. Qualquer um desses eventos acionará um evento de replicação imediato.

As alterações de senha estão em algum lugar entre urgentes e não urgentes e são tratadas de forma exclusiva. Se a senha de um usuário for alterada DC01e um usuário tentar fazer login em um computador que está se autenticando DC02antes da replicação ocorrer, você esperaria que isso falhasse, certo? Felizmente isso não acontece. Suponha que haja também um terceiro DC aqui chamado DC03que detém a função de emulador de PDC. Quando DC01é atualizado com a nova senha do usuário, essa alteração é imediatamente replicada DC03também. Quando a tentativa de autenticação DC02falha, DC02encaminha essa tentativa de autenticação para DC03, que verifica se ela é, de fato, boa e o logon é permitido.

Vamos falar sobre DNS

O DNS é fundamental para um AD funcionando corretamente. A linha oficial da Microsoft é que qualquer servidor DNS pode ser usado se estiver configurado corretamente. Se você tentar usar o BIND para hospedar suas zonas AD, você está chapado. Seriamente. Fique com o uso de zonas DNS integradas ao AD e use encaminhadores condicionais ou globais para outras zonas, se necessário. Todos os seus clientes devem estar configurados para usar seus servidores DNS do AD, portanto, é importante ter redundância aqui. Se você tiver dois DCs, faça com que ambos executem o DNS e configure seus clientes para usar os dois para resolução de nomes.

Além disso, você deve certificar-se de que, se tiver mais de um DC, eles não se listem primeiro para resolução de DNS. Isso pode levar a uma situação em que eles estão em uma "ilha de replicação" onde estão desconectados do restante da topologia de replicação do AD e não podem se recuperar. Se você tiver dois servidores DC01 - 10.1.1.1e DC02 - 10.1.1.2, a lista de servidores DNS deles deve ser configurada assim:

Servidor: DC01 (10.1.1.1)
DNS primário - 10.1.1.2
DNS secundário - 127.0.0.1

Servidor: DC02 (10.1.1.2)
DNS primário - 10.1.1.1
DNS secundário - 127.0.0.1

Tudo bem, isso parece complicado. Por que eu quero usar o AD?

Porque uma vez que você sabe o que está fazendo, sua vida se torna infinitamente melhor. O AD permite a centralização do gerenciamento de usuários e computadores, bem como a centralização do acesso e uso de recursos. Imagine uma situação em que você tem 50 usuários em um escritório. Se você quisesse que cada usuário tivesse seu próprio login em cada computador, você teria que configurar 50 contas de usuário local em cada PC. Com o AD, você só precisa fazer a conta de usuário uma vez e pode fazer login em qualquer PC do domínio por padrão. Se você quisesse fortalecer a segurança, teria que fazer isso 50 vezes. Uma espécie de pesadelo, certo? Imagine também que você tem um compartilhamento de arquivos ao qual deseja que apenas metade dessas pessoas acessem. Se você não estiver usando o AD, precisará replicar o nome de usuário e as senhas manualmente no servidor para fornecer acesso sem sentido, ou você ' d tem que fazer uma conta compartilhada e dar a cada usuário o nome de usuário e senha. Uma maneira significa que você sabe (e precisa atualizar constantemente) as senhas dos usuários. A outra maneira significa que você não tem trilha de auditoria. Não é bom, certo?

Você também pode usar a Diretiva de Grupo quando tiver o AD configurado. A Diretiva de Grupo é um conjunto de objetos vinculados a UOs que definem configurações para usuários e/ou computadores nessas UOs. Por exemplo, se você quiser fazer com que "Desligar" não esteja no menu Iniciar de 500 computadores de laboratório, você pode fazer isso em uma configuração na Diretiva de Grupo. Em vez de passar horas ou dias configurando manualmente as entradas de registro adequadas, você cria um Objeto de Diretiva de Grupo uma vez, vincula-o à UO ou UOs corretos e nunca mais precisa pensar nisso novamente. Existem centenas de GPOs que podem ser configurados, e a flexibilidade da Diretiva de Grupo é um dos principais motivos pelos quais a Microsoft é tão dominante no mercado corporativo.

Observação: essa resposta foi mesclada a esta pergunta de uma pergunta diferente que perguntava sobre as diferenças entre florestas, domínios filho, árvores, sites e UOs. Isso não foi originalmente escrito como uma resposta a essa pergunta específica.

Floresta

Você deseja criar uma nova floresta quando precisar de um limite de segurança. Por exemplo, você pode ter uma rede de perímetro (DMZ) que deseja gerenciar com o AD, mas não deseja que seu AD interno esteja disponível na rede de perímetro por motivos de segurança. Nesse caso, você desejaria criar uma nova floresta para essa zona de segurança. Você também pode querer essa separação se tiver várias entidades que não confiam umas nas outras - por exemplo, uma corporação de fachada que engloba empresas individuais que operam de forma independente. Nesse caso, você deseja que cada entidade tenha sua própria floresta.

Domínio filho

Realmente, você não precisa mais disso. Existem alguns bons exemplos de quando você deseja um domínio filho. Um motivo herdado é devido a diferentes requisitos de política de senha, mas isso não é mais válido, pois há políticas de senha refinadas disponíveis desde o Server 2008. Você realmente só precisa de um domínio filho se tiver áreas com conectividade de rede incrível e desejar para reduzir drasticamente o tráfego de replicação - um navio de cruzeiro com conectividade WAN via satélite é um bom exemplo. Nesse caso, cada navio de cruzeiro pode ser seu próprio domínio filho, de modo a ser relativamente autocontido e ainda poder aproveitar os benefícios de estar na mesma floresta que outros domínios da mesma empresa.

Árvore

Esta é uma bola estranha. Novas árvores são usadas quando você deseja manter os benefícios de gerenciamento de uma única floresta, mas tem um domínio em um novo namespace DNS. Por exemplo corp.example.com, pode ser a raiz da floresta, mas você pode ter ad.mdmarra.comna mesma floresta usando uma nova árvore. As mesmas regras e recomendações para domínios filhos se aplicam aqui - use-as com moderação. Eles geralmente não são necessários em anúncios modernos.

Local

Um site deve representar o limite físico ou lógico em sua rede. Por exemplo, filiais. Os sites são usados ​​para selecionar parceiros de replicação de forma inteligente para controladores de domínio em diferentes áreas. Sem definir sites, todos os DCs serão tratados como se estivessem no mesmo local físico e replicados em uma topologia de malha. Na prática, a maioria das organizações é configurada logicamente em um hub-and-spoke, portanto, os sites e serviços devem ser configurados para refletir isso.

Outros aplicativos também usam Sites e Serviços. O DFS o usa para referências de namespace e seleção de parceiro de replicação. O Exchange e o Outlook o usam para localizar o catálogo global "mais próximo" a ser consultado. Seus computadores ingressados ​​no domínio o usam para localizar o(s) DC(s) "mais próximo(s)" para autenticação. Sem isso, seu tráfego de replicação e autenticação é como o Velho Oeste.

Unidade organizacional

Eles devem ser criados de uma forma que reflita a necessidade de sua organização de delegação de permissão e aplicação de política de grupo. Muitas organizações têm uma UO por site, porque aplicam o GPO dessa maneira - isso é bobagem, porque você também pode aplicar o GPO a um site a partir de Sites e Serviços. Outras organizações separam as UOs por departamento ou função. Isso faz sentido para muitas pessoas, mas realmente o design da UO deve atender às suas necessidades e é bastante flexível. Não há "uma maneira" de fazer isso.

Uma empresa multinacional pode ter UOs de nível superior de North America, Europe, Asia, South America, Africapara que possam delegar privilégios administrativos com base no continente. Outras organizações podem ter UOs de nível superior de Human Resources, Accounting, Sales, etc, se isso fizer mais sentido para elas. Outras organizações têm necessidades de políticas mínimas e usam um layout "plano" com apenas Employee Userse Employee Computers. Não há realmente uma resposta certa aqui, é o que atende às necessidades da sua empresa.