Active Directory

O Active Directory (AD) é um serviço de diretório desenvolvido pela Microsoft para redes de domínios Windows. Os sistemas operacionais Windows Server o incluem como um conjunto de processos e serviços. Originalmente, apenas o gerenciamento centralizado de domínios utilizava o Active Directory. No entanto, ele acabou se tornando um título genérico para vários serviços relacionados à identidade baseados em diretório.

Um controlador de domínio é um servidor que executa a função de Active Directory Domain Services (AD DS). Ele autentica e autoriza todos os usuários e computadores em uma rede do tipo domínio Windows, atribuindo e aplicando políticas de segurança para todos os computadores e instalando ou atualizando softwares. Por exemplo, quando um usuário faz login em um computador que faz parte de um domínio Windows, o Active Directory verifica o nome de usuário e a senha enviados e determina se o usuário é um administrador de sistema ou um usuário comum. Além disso, permite o gerenciamento e armazenamento de informações, fornece mecanismos de autenticação e autorização e estabelece uma estrutura para implantar outros serviços relacionados: Certificate Services (Serviços de Certificado), Federation Services (Serviços de Federação), Lightweight Directory Services (Serviços de Diretório Leves) e Rights Management Services (Serviços de Gerenciamento de Direitos).

O Active Directory utiliza as versões 2 e 3 do Lightweight Directory Access Protocol (LDAP), a versão da Microsoft do Kerberos, e o DNS.

Robert R. King definiu-o da seguinte forma:

"Um domínio representa um banco de dados. Esse banco de dados contém registros sobre serviços de rede — coisas como computadores, usuários, grupos e outras coisas que usam, dão suporte ou existem em uma rede. O banco de dados do domínio é, na verdade, o Active Directory."

História

Como muitos esforços de tecnologia da informação, o Active Directory originou-se de uma democratização do design utilizando Requests for Comments (RFCs). A Internet Engineering Task Force (IETF) supervisiona o processo de RFC e aceitou inúmeras RFCs iniciadas por participantes de diversos setores. Por exemplo, o LDAP serve de base para o Active Directory. Além disso, os diretórios X.500 e a Unidade Organizacional precederam o conceito do Active Directory que utiliza esses métodos. O conceito do LDAP começou a emergir antes mesmo da fundação da Microsoft em abril de 1975, com RFCs já em 1971. As RFCs que contribuíram para o LDAP incluem a RFC 1823 (sobre a API do LDAP, agosto de 1995), RFC 2307, RFC 3062 e RFC 4533.

A Microsoft apresentou uma prévia do Active Directory em 1999, lançou-o primeiramente com a edição Windows 2000 Server e revisou-o para estender a funcionalidade e melhorar a administração no Windows Server 2003. O suporte ao Active Directory também foi adicionado ao Windows 95, Windows 98 e Windows NT 4.0 por meio de uma correção (patch), com alguns recursos não suportados. Melhorias adicionais vieram com as versões subsequentes do Windows Server. No Windows Server 2008, a Microsoft adicionou outros serviços ao Active Directory, como o Active Directory Federation Services. A parte do diretório encarregada de gerenciar domínios, que era uma parte central do sistema operacional, foi renomeada para Active Directory Domain Services (AD DS) e tornou-se uma função de servidor como as outras. "Active Directory" tornou-se o título genérico de uma gama mais ampla de serviços baseados em diretório. De acordo com Byron Hynes, tudo relacionado à identidade foi trazido sob a marca do Active Directory.

Serviços do Active Directory

Os Serviços do Active Directory consistem em múltiplos serviços de diretório. O mais conhecido é o Active Directory Domain Services, comumente abreviado como AD DS ou simplesmente AD.

Domain Services (Serviços de Domínio)

O Active Directory Domain Services (AD DS) é a base de toda rede de domínio Windows. Ele armazena informações sobre os membros do domínio, incluindo dispositivos e usuários, verifica suas credenciais e define seus direitos de acesso. O servidor que executa esse serviço é chamado de controlador de domínio. Um controlador de domínio é contatado quando um usuário faz login em um dispositivo, acessa outro dispositivo na rede ou executa um aplicativo no estilo Metro de linha de negócios instalado localmente (sideloaded) em uma máquina.

Outros serviços do Active Directory (excluindo o LDS, conforme descrito abaixo) e a maioria das tecnologias de servidor da Microsoft dependem ou usam os Serviços de Domínio; os exemplos incluem Políticas de Grupo (Group Policy), Encrypting File System, BitLocker, Serviços de Nome de Domínio, Serviços de Área de Trabalho Remota, Exchange Server e SharePoint Server.

O Active Directory DS autogerenciado deve ser distinguido do Azure AD DS gerenciado, um produto em nuvem.

Lightweight Directory Services (Serviços de Diretório Leves)

O Active Directory Lightweight Directory Services (AD LDS), anteriormente chamado de Active Directory Application Mode (ADAM), implementa o protocolo LDAP para o AD DS. Ele funciona como um serviço no Windows Server e oferece a mesma funcionalidade que o AD DS, incluindo uma API idêntica. No entanto, o AD LDS não exige a criação de domínios ou controladores de domínio. Ele fornece um Repositório de Dados para armazenar dados de diretório e um Serviço de Diretório com uma Interface de Serviço de Diretório LDAP. Ao contrário do AD DS, múltiplas instâncias do AD LDS podem operar no mesmo servidor.

Certificate Services (Serviços de Certificado)

O Active Directory Certificate Services (AD CS) estabelece uma infraestrutura de chaves públicas local. Ele pode criar, validar, revogar e realizar outras ações semelhantes em certificados de chave pública para usos internos de uma organização. Esses certificados podem ser usados para criptografar arquivos (quando usados com o Encrypting File System), e-mails (conforme o padrão S/MIME) e tráfego de rede (quando usados por redes privadas virtuais, protocolo Transport Layer Security ou protocolo IPSec).

O AD CS antecede o Windows Server 2008, mas seu nome era simplesmente Certificate Services.

O AD CS requer uma infraestrutura de AD DS.

Federation Services (Serviços de Federação)

O Active Directory Federation Services (AD FS) é um serviço de logon único (single sign-on). Com uma infraestrutura de AD FS instalada, os usuários podem usar vários serviços baseados na web (por exemplo, fórum de internet, blog, compras online, webmail) ou recursos de rede usando apenas um conjunto de credenciais armazenadas em um local central, em vez de ter que receber um conjunto dedicado de credenciais para cada serviço. O AD FS usa muitos padrões abertos populares para passar credenciais de token, como SAML, OAuth ou OpenID Connect. O AD FS suporta criptografia e assinatura de asserções SAML. O objetivo do AD FS é uma extensão do AD DS: este último permite que os usuários se autentiquem e usem os dispositivos que fazem parte da mesma rede, usando um conjunto de credenciais; o primeiro permite que eles usem o mesmo conjunto de credenciais em uma rede diferente.

Como o nome sugere, o AD FS funciona com base no conceito de identidade federada.

O AD FS requer uma infraestrutura de AD DS, embora seu parceiro de federação possa não exigir.

Rights Management Services (Serviços de Gerenciamento de Direitos)

O Active Directory Rights Management Services (AD RMS), anteriormente conhecido como Rights Management Services ou RMS antes do Windows Server 2008, é um software de servidor incluído no Windows Server que permite o gerenciamento de direitos de informação. Ele usa criptografia e negação seletiva para restringir o acesso a vários documentos, como e-mails corporativos, documentos do Microsoft Word e páginas da web. Também limita as operações que os usuários autorizados podem realizar neles, como visualizar, editar, copiar, salvar ou imprimir. Os administradores de TI podem criar modelos predefinidos para os usuários finais por conveniência, mas os usuários finais ainda podem definir quem pode acessar o conteúdo e quais ações podem tomar.

Estrutura lógica

O Active Directory é um serviço composto por um banco de dados e código executável. É responsável por gerenciar solicitações e manter o banco de dados. O Directory System Agent (Agente do Sistema de Diretório) é a parte executável, um conjunto de serviços do Windows e processos que rodam no Windows 2000 e posterior. O acesso aos objetos nos bancos de dados do Active Directory é possível através de várias interfaces, como LDAP, ADSI, API de mensagens e serviços do Security Accounts Manager.

Objetos utilizados

Um exemplo simplificado da rede interna de uma editora. A empresa possui quatro grupos com permissões variadas para as três pastas compartilhadas na rede.

As estruturas do Active Directory consistem em informações sobre objetos classificados em duas categorias: recursos (como impressoras) e entidades de segurança (que incluem contas de usuários ou computadores e grupos). Cada principal de segurança recebe um identificador de segurança (SID) exclusivo. Um objeto representa uma única entidade, como um usuário, computador, impressora ou grupo, junto com seus atributos. Alguns objetos podem até conter outros objetos dentro deles. Cada objeto possui um nome exclusivo e sua definição é um conjunto de características e informações por um esquema, que determina o armazenamento no Active Directory.

Os administradores podem estender ou modificar o esquema usando o objeto de esquema quando necessário. No entanto, como cada objeto de esquema é parte integrante da definição dos objetos do Active Directory, desativá-los ou alterá-los pode alterar fundamentalmente ou interromper uma implantação. A modificação do esquema afeta todo o sistema automaticamente e os novos objetos não podem ser excluídos, apenas desativados. A alteração do esquema geralmente requer planejamento.

Florestas, árvores e domínios

Em uma rede Active Directory, a estrutura que contém os objetos possui diferentes níveis: a floresta, a árvore e o domínio. Os domínios dentro de uma implantação contêm objetos armazenados em um único banco de dados replicável, e a estrutura de nomes do DNS identifica seus domínios, o espaço de nomes. Um domínio é um grupo lógico de objetos de rede, como computadores, usuários e dispositivos, que compartilham o mesmo banco de dados do Active Directory.

Por outro lado, uma árvore é uma coleção de domínios e árvores de domínios em um espaço de nomes contíguo, vinculados em uma hierarquia de confiança transitiva. A floresta está no topo da estrutura, sendo uma coleção de árvores com um catálogo global padrão, esquema de diretório, estrutura lógica e configuração de diretório. A floresta é um limite seguro que limita o acesso a usuários, computadores, grupos e outros objetos.

  Domínio-Boston
  Domínio-Nova Iorque
  Domínio-Philly
 Árvore-Sul
  Domínio-Atlanta
  Domínio-Dallas
Domínio-Dallas
 OU-Marketing
  Hewitt
  Aon
  Steve
 OU-Vendas
  Bill
  Ralph
Exemplo de organização geográfica de zonas de interesse dentro de árvores e domínios

Unidades organizacionais

Os objetos mantidos em um domínio podem ser agrupados em unidades organizacionais (OUs). As OUs podem fornecer hierarquia a um domínio, facilitar sua administração e podem se assemelhar à estrutura da organização em termos gerenciais ou geográficos. As OUs podem conter outras OUs — os domínios são contêineres nesse sentido. A Microsoft recomenda o uso de OUs em vez de domínios para estruturação e para simplificar a implementação de políticas e administração. A OU é o nível recomendado no qual aplicar políticas de grupo, que são objetos do Active Directory formalmente chamados de objetos de política de grupo (GPOs), embora as políticas também possam ser aplicadas a domínios ou sites (veja abaixo). A OU é o nível no qual os poderes administrativos são comumente delegados, mas a delegação também pode ser realizada em objetos ou atributos individuais.

As unidades organizacionais não possuem, cada uma, um espaço de nomes separado. Como consequência, para compatibilidade com implementações NetBios herdadas, contas de usuário com um SamAccountName idêntico não são permitidas no mesmo domínio, mesmo que os objetos das contas estejam em OUs separadas. Isso ocorre porque o SamAccountName, um atributo de objeto de usuário, deve ser exclusivo dentro do domínio. No entanto, dois usuários em OUs diferentes podem ter o mesmo nome comum (CN), o nome sob o qual estão armazenados no próprio diretório, como "fred.staff-ou.domain" e "fred.student-ou.domain", onde "staff-ou" e "student-ou" são as OUs.

Em geral, a razão para essa falta de permissão para nomes duplicados por meio do posicionamento em diretórios hierárquicos é que a Microsoft depende principalmente dos princípios do NetBIOS, que é um método de espaço de nomes plano de gerenciamento de objetos de rede que, para os softwares da Microsoft, remonta ao Windows NT 3.1 e ao MS-DOS LAN Manager. Permitir a duplicação de nomes de objetos no diretório, ou remover completamente o uso de nomes NetBIOS, impediria a compatibilidade com versões anteriores de softwares e equipamentos herdados. No entanto, proibir nomes de objetos duplicados dessa forma é uma violação das RFCs do LDAP nas quais o Active Directory supostamente se baseia.

À medida que o número de usuários em um domínio aumenta, convenções como "primeira inicial, inicial do meio, sobrenome" (ordem ocidental) ou o inverso (ordem oriental) falham para sobrenomes comuns como Li (李), Smith ou Garcia. As soluções alternativas incluem adicionar um dígito ao final do nome de usuário. Outras alternativas incluem a criação de um sistema de IDs separado com números de identificação de funcionário/estudante exclusivos para usar como nomes de conta no lugar dos nomes reais dos usuários e permitir que os usuários escolham sua sequência de palavras preferida dentro de uma política de uso aceitável.

Como não podem existir nomes de usuário duplicados em um domínio, a geração de nomes de conta representa um desafio significativo para grandes organizações que não podem ser facilmente subdivididas em domínios separados, como estudantes em um sistema de escolas públicas ou universidades que devem ser capazes de usar qualquer computador na rede.

Grupos de sombra (Shadow groups)

No Active Directory da Microsoft, as OUs não conferem permissões de acesso e os objetos colocados dentro delas não recebem privilégios de acesso automaticamente com base na OU que os contém. Isso representa uma limitação de design específica do Active Directory; outros diretórios concorrentes, como o Novell NDS, podem definir privilégios de acesso por meio do posicionamento do objeto dentro de uma OU.

O Active Directory exige uma etapa separada para que um administrador atribua um objeto em uma OU como membro de um grupo também dentro dessa OU. Usar apenas a localização da OU para determinar as permissões de acesso não é confiável, pois a entidade pode ainda não ter sido atribuída ao objeto de grupo daquela OU.

Uma solução comum para um administrador do Active Directory é escrever um script personalizado em PowerShell ou Visual Basic para criar e manter automaticamente um grupo de usuários para cada OU em seu diretório. Os scripts são executados periodicamente para atualizar o grupo de modo que corresponda aos membros da conta da OU. No entanto, eles não podem atualizar instantaneamente os grupos de segurança sempre que o diretório muda, como ocorre em diretórios concorrentes, pois a segurança é implementada diretamente no diretório. Esses grupos são conhecidos como grupos de sombra (shadow groups). Depois de criados, esses grupos de sombra são selecionáveis no lugar da OU nas ferramentas administrativas. A documentação de referência do Server 2008 da Microsoft menciona os grupos de sombra, mas não fornece instruções sobre como criá-los. Além disso, não há métodos de servidor ou snap-ins de console disponíveis para gerenciar esses grupos.

Uma organização deve determinar a estrutura de sua infraestrutura de informações dividindo-a em um ou mais domínios e OUs de nível superior. Essa decisão é crítica e pode se basear em vários modelos, como unidades de negócios, localizações geográficas, serviços de TI, tipo de objeto ou uma combinação desses modelos. O objetivo imediato da organização das OUs é simplificar a delegação administrativa e, secundariamente, aplicar políticas de grupo. Embora as OUs sirvam como um limite administrativo, a floresta em si é o único limite de segurança. Todos os outros domínios devem confiar em qualquer administrador da floresta para manter a segurança.

Partições

O banco de dados do Active Directory é organizado em partições, cada uma contendo tipos específicos de objetos e seguindo um padrão de replicação específico. A Microsoft costuma se referir a essas partições como "contextos de nomenclatura" (naming contexts). A partição "Schema" (Esquema) define classes de objetos e atributos dentro da floresta. A partição "Configuration" (Configuração) contém informações sobre a estrutura física e a configuração da floresta (como a topologia do site). Ambas se replicam para todos os domínios da floresta. A partição "Domain" (Domínio) contém todos os objetos criados naquele domínio e se replica apenas dentro dele.

Algumas partições de diretório armazenam informações de configuração de toda a floresta e informações de esquema; outras partições de diretório armazenam informações específicas de domínios individuais, como usuários, grupos e unidades organizacionais.

Por padrão, o Active Directory Domain Services contém os seguintes contextos de nomenclatura:

  • Schema NC: armazena informações de esquema que são replicadas para controladores de domínio em todos os domínios da floresta.
  • Configuration NC: armazena a topologia e outras informações de dados de configuração que são replicadas para controladores de domínio em todos os domínios da floresta.
  • Domain NC: armazena informações do domínio, como usuários e computadores, que são replicadas apenas para os controladores de domínio daquele domínio específico.

Estrutura física

Sites (ou locais) são agrupamentos físicos (em vez de lógicos) definidos por uma ou mais sub-redes IP. O AD também define conexões, distinguindo links de baixa velocidade (por exemplo, WAN, VPN) de links de alta velocidade (por exemplo, LAN). As definições de site são independentes da estrutura de domínios e OUs e são compartilhadas por toda a floresta. Os sites desempenham um papel crucial no gerenciamento do tráfego de rede gerado pela replicação e no direcionamento dos clientes para os controladores de domínio (DCs) mais próximos. O Microsoft Exchange Server 2007 utiliza a topologia de sites para o roteamento de e-mails. Os administradores também podem definir políticas no nível do site.

As informações do Active Directory são mantidas fisicamente em um ou mais controladores de domínio pares, substituindo o modelo NT de PDC/BDC (Controlador de domínio primário/de backup). Cada DC possui uma cópia do Active Directory. Os servidores membros que ingressam no Active Directory, mas não são controladores de domínio, são chamados de Servidores Membros. Na partição de domínio, um grupo de objetos atua como cópias dos controladores de domínio configurados como catálogos globais. Esses servidores de catálogo global oferecem uma lista abrangente de todos os objetos na floresta.

Os servidores de Catálogo Global replicam todos os objetos de todos os domínios para si mesmos, fornecendo uma listagem internacional de entidades na floresta. No entanto, para minimizar o tráfego de replicação e manter o banco de dados do GC pequeno, apenas atributos selecionados de cada objeto são replicados, o que é chamado de conjunto parcial de atributos (PAS - partial attribute set). O PAS pode ser modificado alterando o esquema e marcando os recursos para replicação no GC. As versões anteriores do Windows usavam o NetBIOS para se comunicar. O Active Directory é totalmente integrado ao DNS e requer TCP/IP—DNS. Para operar totalmente, o servidor DNS deve suportar registros de recursos SRV, também conhecidos como registros de serviço.

Replicação

O Active Directory utiliza a replicação multimestre para sincronizar as alterações, o que significa que as réplicas buscam (pull) as alterações do servidor onde a alteração ocorreu, em vez de as alterações serem empurradas (push) para elas. O Verificador de Consistência de Conhecimento (KCC - Knowledge Consistency Checker) utiliza os sites definidos para gerenciar o tráfego e criar uma topologia de replicação de links de sites. A replicação intra-site ocorre de forma frequente e automática devido às notificações de alteração, que induzem os pares a iniciar um ciclo de replicação por busca. Os intervalos de replicação entre sites diferentes costumam ser menos consistentes e geralmente não utilizam notificações de alteração. No entanto, é possível configurá-la para ser igual à replicação entre locais na mesma rede, se necessário.

Cada link DS3, T1 e ISDN pode ter um custo atribuído, e o KCC altera a topologia de links de site de acordo com isso. A replicação pode ocorrer de forma transitiva através de vários links de site em pontes de links de site (site link bridges) do mesmo protocolo se o custo for baixo. No entanto, o KCC define automaticamente o custo de um link direto de site a site como inferior ao de conexões transitivas. Um servidor bridgehead (ponta de ponte) em cada zona pode enviar atualizações para outros DCs na mesma localidade para replicar alterações entre sites. Para configurar a replicação para zonas do Active Directory, ative o DNS no domínio com base no site.

Para replicar o Active Directory, são utilizadas Chamadas de Procedimento Remoto (RPC) sobre IP (RPC/IP). O SMTP é usado para replicar entre sites, mas apenas para modificações no Esquema, Configuração ou Conjunto Parcial de Atributos (Catálogo Global) GCs. Ele não é adequado para reproduzir a partição padrão de Domínio.

Atraso de credencial

Atraso de credencial (em inglês, credential lag) é o período temporário após a alteração ou redefinição de uma credencial durante o qual um ou mais sistemas continuam a aceitar ou exigir credenciais previamente armazenadas em cache. Em ambientes de Active Directory (AD) e de identidade híbrida, esse atraso geralmente resulta de:

  • Latência de replicação de controladores de domínio: O tempo necessário para que os atributos atualizados da conta sejam replicados entre controladores de domínio distribuídos geograficamente.
  • Cache de tokens e sessões: Protocolos modernos de autenticação (como OAuth 2.0 ou OpenID Connect) e mecanismos como os Primary Refresh Tokens (PRT) do Microsoft Entra ID podem permitir que tokens de acesso existentes permaneçam válidos até a expiração programada, mesmo após a redefinição de uma senha.
  • Sincronização agendada de identidade: Aplicações de terceiros, serviços em nuvem ou agentes de provisionamento (como SCIM ou Microsoft Entra Connect) que sincronizam dados de autenticação periodicamente, em vez de consultar o Active Directory em tempo real.

Por exemplo, se um usuário altera uma senha expirada do domínio Windows, o Active Directory é atualizado imediatamente. No entanto, se uma aplicação de intranet interna sincroniza seu banco de dados de credenciais local apenas a cada 15 minutos, o usuário não conseguirá se autenticar nessa aplicação usando a nova senha até que o próximo ciclo de sincronização seja concluído.

Implantação

Geralmente, uma rede que utiliza o Active Directory possui mais de um computador servidor Windows licenciado. O backup e a restauração do Active Directory são possíveis em uma rede com um único controlador de domínio. No entanto, a Microsoft recomenda mais de um controlador de domínio para fornecer proteção automática contra falhas (failover) do diretório. Idealmente, os controladores de domínio devem ser de propósito único apenas para operações de diretório e não devem executar nenhum outro software ou função.

Como certos produtos da Microsoft, como o SQL Server e o Exchange, podem interferir na operação de um controlador de domínio, aconselha-se o isolamento desses produtos em servidores Windows adicionais. Combiná-los pode tornar mais complexa a configuração e a solução de problemas do controlador de domínio ou dos outros softwares instalados. Se estiver planejando implementar o Active Directory, uma empresa deve adquirir várias licenças do Windows Server para ter pelo menos dois controladores de domínio separados. Os administradores devem considerar controladores de domínio adicionais para desempenho ou redundância, e servidores individuais para tarefas como armazenamento de arquivos, Exchange e SQL Server, pois isso garantirá que todas as funções de servidor sejam adequadamente suportadas.

Uma maneira de reduzir os custos de hardware físico é usando a virtualização. No entanto, para uma proteção adequada contra falhas, a Microsoft recomenda não executar múltiplos controladores de domínio virtualizados no mesmo hardware físico.

Banco de dados

O banco de dados do Active Directory, o repositório de diretório, no Windows 2000 Server utiliza o Extensible Storage Engine (ESE98) baseado no Microsoft JET Blue. O banco de dados de cada controlador de domínio é limitado a 16 terabytes e 2 bilhões de objetos (mas apenas 1 bilhão de entidades de segurança). A Microsoft já criou bancos de dados NTDS com mais de 2 bilhões de objetos. O Gerenciador de Contas de Segurança do NT4 podia suportar até 40.000 objetos. Ele possui duas tabelas principais: a tabela de dados (data table) e a tabela de links (link table). O Windows Server 2003 adicionou uma terceira tabela principal para a instância única de descritores de segurança.

Os programas podem acessar os recursos do Active Directory por meio das interfaces COM fornecidas pelas Interfaces de Serviço do Active Directory (ADSI - Active Directory Service Interfaces).

Relações de confiança (Trusting)

Para permitir que os usuários de um domínio acessem recursos em outro, o Active Directory utiliza relações de confiança (trusts).

As relações de confiança dentro de uma floresta são criadas automaticamente quando os domínios são criados. A floresta estabelece os limites padrão de confiança, e a confiança implícita e transitiva é automática para todos os domínios dentro de uma floresta.

Terminologia

Confiança unidirecional (One-way trust)
Um domínio permite o acesso a usuários de outro domínio, mas o outro domínio não permite o acesso a usuários do primeiro domínio.
Confiança bidirecional (Two-way trust)
Ambos os domínios permitem o acesso a usuários de ambos os lados.
Domínio confiável (Trusted domain)
O domínio em que se confia; cujos usuários têm acesso ao domínio que confia.
Confiança transitiva (Transitive trust)
Uma relação de confiança que pode se estender além de dois domínios para outros domínios confiáveis na floresta.
Confiança intransitiva (Intransitive trust)
Uma confiança unidirecional que não se estende além de dois domínios.
Confiança explícita (Explicit trust)
Uma relação de confiança criada por um administrador. Ela não é transitiva e é apenas unidirecional.
Confiança de link cruzado (Cross-link trust)
Uma confiança explícita entre domínios em árvores diferentes ou na mesma árvore quando não existe uma relação de descendente/ancestral (filho/pai) entre os dois domínios.
Atalho (Shortcut)
Une dois domínios em árvores diferentes; é transitiva, unidirecional ou bidirecional.
Confiança de floresta (Forest trust)
Aplica-se a toda a floresta. Transitiva, unidirecional ou bidirecional.
Território (Realm)
Pode ser transitiva ou não transitiva (intransitiva), unidirecional ou bidirecional.
Externa (External)
Conecta-se a outras florestas ou domínios que não pertencem ao Active Directory. Não transitiva, unidirecional ou bidirecional.
Confiança PAM (PAM trust)
Uma confiança unidirecional usada pelo Microsoft Identity Manager de uma floresta de produção (possivelmente de nível inferior) para uma floresta "bastião" (nível de funcionalidade do Windows Server 2016), que emite associações a grupos com limite de tempo.

Ferramentas de gerenciamento

As ferramentas de gerenciamento do Microsoft Active Directory incluem:

Essas ferramentas de gerenciamento podem não fornecer funcionalidade suficiente para um fluxo de trabalho eficiente em ambientes grandes. Algumas ferramentas de terceiros estendem os recursos de administração e gerenciamento. Elas oferecem recursos essenciais para um processo de administração mais conveniente, como automação, relatórios, integração com outros serviços, etc.

Integração com Unix

Variados níveis de interoperabilidade com o Active Directory podem ser alcançados na maioria dos sistemas operacionais baseados em Unix (incluindo Unix, Linux, Mac OS X ou programas baseados em Java e Unix) por meio de clientes LDAP em conformidade com os padrões, mas esses sistemas geralmente não interpretam muitos atributos associados aos componentes do Windows, como as Políticas de Grupo e o suporte para confianças unidirecionais.

Empresas terceiras oferecem integração do Active Directory para plataformas baseadas em Unix, incluindo:

As adições de esquema incluídas no Windows Server 2003 R2 contêm atributos que se mapeiam de forma próxima o suficiente à RFC 2307 para serem geralmente utilizáveis. A implementação de referência da RFC 2307, nss_ldap e pam_ldap fornecida pela PADL.com, suporta esses atributos diretamente. O esquema padrão para associação a grupos está em conformidade com a RFC 2307bis (proposta). O Windows Server 2003 R2 inclui um snap-in do Microsoft Management Console que cria e edita esses atributos.

Uma opção alternativa é usar outro serviço de diretório para a autenticação de clientes não-Windows, enquanto os clientes Windows se autenticam no Active Directory. Os clientes não-Windows incluem o 389 Directory Server (antigo Fedora Directory Server, FDS), o ViewDS v7.2 XML Enabled Directory e o Sun Java System Directory Server da Sun Microsystems. Os dois últimos são capazes de realizar sincronização bidirecional com o Active Directory, fornecendo assim uma integração "indireta".

Outra opção é usar o OpenLDAP com sua sobreposição translucent (translúcida), que pode estender entradas em qualquer servidor LDAP remoto com atributos adicionais armazenados em um banco de dados local. Os clientes apontados para o banco de dados local veem entradas que contêm tanto os atributos remotos quanto os locais, enquanto o banco de dados remoto permanece completamente intocado.[carece de fontes]?

A administração (consulta, modificação e monitoramento) do Active Directory pode ser realizada por meio de várias linguagens de script, incluindo PowerShell, VBScript, JScript/JavaScript, Perl, Python e Ruby. Ferramentas gratuitas e comerciais de administração do Active Directory podem ajudar a simplificar e, possivelmente, automatizar as tarefas de gerenciamento do Active Directory.

Desde outubro de 2017, a Amazon AWS oferece integração com o Microsoft Active Directory.

O Active Directory na era moderna e híbrida

Embora a arquitetura central do Active Directory (como o banco de dados NTDS e a topologia de sites) permaneça consistente para garantir a compatibilidade com sistemas legados, o papel do AD DS (on-premises) mudou drasticamente com a ascensão da computação em nuvem. Nas infraestruturas corporativas modernas, o Active Directory raramente opera de forma isolada, funcionando como a base de sistemas de identidade híbrida.

Integração com o Microsoft Entra ID

A evolução do gerenciamento de identidades levou à criação do Microsoft Entra ID (anteriormente conhecido como Azure Active Directory ou Azure AD). Ao contrário do AD tradicional, o Entra ID é um serviço de identidade baseado em nuvem projetado para aplicativos web e que utiliza protocolos modernos como OAuth 2.0, SAML 2.0 e OpenID Connect, em vez de Kerberos e LDAP.

Para unir esses dois mundos, as organizações utilizam ferramentas de sincronização, como o Microsoft Entra Connect. Esse utilitário replica as contas de usuários, grupos e hashes de senhas do Active Directory local para a nuvem, permitindo que os usuários utilizem as mesmas credenciais para acessar servidores físicos internos e serviços em nuvem, como o Microsoft 365.

Foco contemporâneo em segurança

Com a obsolescência de tecnologias de rede antigas e o aumento da largura de banda global, a administração moderna do Active Directory reduziu o foco no cálculo manual de custos de links físicos (como T1 ou ISDN) e redirecionou os esforços para a segurança de identidade. O AD tornou-se um dos principais alvos de ataques cibernéticos modernos. Os administradores atuais concentram-se em:

  • Mitigação de ataques de identidade: Proteção contra técnicas de movimentação lateral, sequestro de tíquetes Kerberos (como Golden Ticket e Kerberoasting) e ataques de força bruta.
  • Gerenciamento de Acesso Privilegiado (PAM): Implementação de florestas administrativas e conceitos de "privilégio mínimo" para evitar que o comprometimento de uma estação de trabalho resulte no controle total do domínio.
  • Abordagem de Confiança Zero (Zero Trust): Integração da infraestrutura local com políticas de acesso condicional na nuvem, exigindo autenticação multifatorial (MFA) e análise de risco em tempo real para cada tentativa de login.

Ver também

Referências

  1. 1 2 «Directory System Agent». MSDN Library. Microsoft. Consultado em 23 de abril de 2014
  2. 1 2 Solomon, David A.; Russinovich, Mark (2005). «Chapter 13». Microsoft Windows Internals: Microsoft Windows Server 2003, Windows XP, and Windows 2000 4th ed. Redmond, Washington: Microsoft Press. p. 840. ISBN 0-7356-1917-4
  3. 1 2 3 Hynes, Byron (novembro de 2006). «The Future of Windows: Directory Services in Windows Server "Longhorn"». TechNet Magazine. Microsoft. Consultado em 30 de abril de 2020. Cópia arquivada em 30 de abril de 2020
  4. ↑ «Active Directory on a Windows Server 2003 Network». Active Directory Collection. Microsoft. 13 de março de 2003. Consultado em 25 de dezembro de 2010. Cópia arquivada em 30 de abril de 2020
  5. ↑ Rackspace Support (27 de abril de 2016). «Install Active Directory Domain Services on Windows Server 2008 R2 Enterprise 64-bit.». Rackspace. Rackspace US, Inc. Consultado em 22 de setembro de 2016. Cópia arquivada em 30 de abril de 2020
  6. ↑ «Microsoft Kerberos - Win32 apps». docs.microsoft.com. 7 de janeiro de 2021
  7. ↑ «Domain Name System (DNS)». docs.microsoft.com. 10 de janeiro de 2022
  8. ↑ King, Robert (2003). Mastering Active directory for Windows server 2003 3rd ed. Alameda, Calif.: Sybex. p. 159. ISBN 978-0-7821-5201-2. OCLC 62876800
  9. ↑ Howes, T.; Smith, M. (agosto de 1995). «The LDAP Application Program Interface». The Internet Engineering Task Force (IETF). Consultado em 26 de novembro de 2013. Cópia arquivada em 30 de abril de 2020
  10. ↑ Howard, L. (março de 1998). «An Approach for Using LDAP as a Network Information Service». Internet Engineering Task Force (IETF). Consultado em 26 de novembro de 2013. Cópia arquivada em 30 de abril de 2020
  11. ↑ Zeilenga, K. (fevereiro de 2001). «LDAP Password Modify Extended Operation». The Internet Engineering Task Force (IETF). Consultado em 26 de novembro de 2013. Cópia arquivada em 30 de abril de 2020
  12. ↑ Zeilenga, K.; Choi, J.H. (junho de 2006). «The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation». The Internet Engineering Task Force (IETF). Consultado em 26 de novembro de 2013. Cópia arquivada em 30 de abril de 2020
  13. ↑ Daniel Petri (8 de janeiro de 2009). «Active Directory Client (dsclient) for Win98/NT»
  14. ↑ «Dsclient.exe connects Windows 9x/NT PCs to Active Directory». 5 de junho de 2003
  15. 1 2 Thomas, Guy (29 de novembro de 2000). «Windows Server 2008 - New Features». ComputerPerformance.co.uk. Computer Performance Ltd. Consultado em 30 de abril de 2020. Cópia arquivada em 2 de setembro de 2019
  16. ↑ «What's New in Active Directory in Windows Server». Windows Server 2012 R2 and Windows Server 2012 Tech Center. Microsoft. 31 de agosto de 2016
  17. ↑ «Compare Active Directory-based services in Azure». docs.microsoft.com. 3 de abril de 2023
  18. ↑ «AD LDS». Microsoft. Consultado em 28 de abril de 2009
  19. ↑ «AD LDS versus AD DS». Microsoft. 2 de julho de 2012. Consultado em 25 de fevereiro de 2013
  20. ↑ Zacker, Craig (2003). «11: Creating and Managing Digital Certificates». In: Harding, Kathy; Jean, Trenary; Linda, Zacker. Planning and Maintaining a Microsoft Windows server 2003 Network Infrastructure. Redmond, WA: Microsoft Press. pp. 11–16. ISBN 0-7356-1893-3
  21. ↑ «Active Directory Certificate Services Overview». Microsoft TechNet. Microsoft. Consultado em 24 de novembro de 2015
  22. ↑ «Overview of authentication in Power Apps portals». Microsoft Docs. Microsoft. Consultado em 30 de janeiro de 2022
  23. ↑ «How to Replace the SSL, Service Communications, Token-Signing, and Token-Decrypting Certificates». TechNet. Microsoft. Consultado em 30 de janeiro de 2022
  24. ↑ «Step 1: Preinstallation Tasks». TechNet. Microsoft. Consultado em 21 de outubro de 2021
  25. ↑ «Test Lab Guide: Deploying an AD RMS Cluster». Microsoft Docs. Microsoft. 31 de agosto de 2016. Consultado em 30 de janeiro de 2022
  26. ↑ Windows Server 2003: Active Directory Infrastructure. [S.l.]: Microsoft Press. 2003. pp. 1–8–1–9
  27. ↑ «Organizational Units». Distributed Systems Resource Kit (TechNet). Microsoft. 2011. An organizational unit in Active Directory is analogous to a directory in the file system
  28. ↑ «SamAccountName is always unique in a Windows domain... or is it?». Joeware. 4 de janeiro de 2012. Consultado em 18 de setembro de 2013. examples of how multiple AD objects can be created with the same SamAccountName
  29. ↑ Microsoft Server 2008 Reference, discutindo grupos de sombra usados para políticas de senha refinadas: https://technet.microsoft.com/en-us/library/cc770394%28WS.10%29.aspx
  30. ↑ «Specifying Security and Administrative Boundaries». Microsoft Corporation. 23 de janeiro de 2005. However, service administrators have abilities that cross domain boundaries. For this reason, the forest is the ultimate security boundary, not the domain.
  31. ↑ Andreas Luther (9 de dezembro de 2009). «Active Directory Replication Traffic». Microsoft Corporation. Consultado em 26 de maio de 2010. The Active Directory is made up of one or more naming contexts or partitions.
  32. ↑ «Sites overview». Microsoft Corporation. 21 de janeiro de 2005. A site is a set of well-connected subnets.
  33. ↑ «Planning for domain controllers and member servers». Microsoft Corporation. 21 de janeiro de 2005. [...] member servers, [...] belong to a domain but do not contain a copy of the Active Directory data.
  34. ↑ «What Is the Global Catalog?». Microsoft Corporation. 10 de dezembro de 2009. [...] a domain controller can locate only the objects in its domain. [...] The global catalog provides the ability to locate objects from any domain [...]
  35. ↑ «Global Catalog». Microsoft Corporation
  36. ↑ «Attributes Included in the Global Catalog». Microsoft Corporation. 26 de agosto de 2010. The isMemberOfPartialAttributeSet attribute of an attributeSchema object is set to TRUE if the attribute is replicated to the global catalog. [...] When deciding whether or not to place an attribute in the global catalog remember that you are trading increased replication and increased disk storage on global catalog servers for, potentially, faster query performance.
  37. ↑ «Directory data store». Microsoft Corporation. 21 de janeiro de 2005. Active Directory uses four distinct directory partition types to store [...] data. Directory partitions contain domain, configuration, schema, and application data.
  38. ↑ «What Is the Active Directory Replication Model?». Microsoft Corporation. 28 de março de 2003. Domain controllers request (pull) changes rather than send (push) changes that might not be needed.
  39. ↑ «What Is Active Directory Replication Topology?». Microsoft Corporation. 28 de março de 2003. SMTP can be used to transport nondomain replication [...]
  40. ↑ «Revoke user access in an emergency in Microsoft Entra ID» (em inglês). learn.microsoft.com. Consultado em 23 de julho de 2026. Cópia arquivada em 4 de julho de 2026
  41. ↑ «Microsoft Entra Connect Sync: Scheduler» (em inglês). learn.microsoft.com. Consultado em 23 de julho de 2026. Cópia arquivada em 13 de julho de 2026
  42. ↑ kaushika-msft. «Cached domain logon information - Windows Server» (em inglês). learn.microsoft.com. Consultado em 23 de julho de 2026. Cópia arquivada em 15 de julho de 2026
  43. ↑ «Active Directory Backup and Restore». TechNet. Microsoft. 9 de dezembro de 2009. Consultado em 5 de fevereiro de 2014
  44. ↑ «AD DS: All domains should have at least two functioning domain controllers for redundancy». TechNet. Microsoft. Consultado em 5 de fevereiro de 2014
  45. ↑ Posey, Brien (23 de agosto de 2010). «10 tips for effective Active Directory design». TechRepublic. CBS Interactive. Consultado em 5 de fevereiro de 2014. Whenever possible, your domain controllers should run on dedicated servers (physical or virtual).
  46. ↑ «You may encounter problems when installing SQL Server on a domain controller (Revision 3.0)». Support. Microsoft. 7 de janeiro de 2013. Consultado em 5 de fevereiro de 2014
  47. ↑ Degremont, Michel (30 de junho de 2011). «Can I install SQL Server on a domain controller?». Microsoft SQL Server blog. Consultado em 5 de fevereiro de 2014. For security and performance reasons, we recommend that you do not install a standalone SQL Server on a domain controller.
  48. ↑ «Installing Exchange on a domain controller is not recommended». TechNet. Microsoft. 22 de março de 2013. Consultado em 5 de fevereiro de 2014
  49. ↑ «Security Considerations for a SQL Server Installation». TechNet. Microsoft. Consultado em 5 de fevereiro de 2014. After SQL Server is installed on a computer, you cannot change the computer from a domain controller to a domain member. You must uninstall SQL Server before you change the host computer to a domain member.
  50. ↑ «Exchange Server Analyzer». TechNet. Microsoft. Consultado em 5 de fevereiro de 2014. Running SQL Server on the same computer as a production Exchange mailbox server is not recommended.
  51. ↑ «Running Domain Controllers in Hyper-V». TechNet. Microsoft. Planning to Virtualize Domain Controllers. Consultado em 5 de fevereiro de 2014. You should attempt to avoid creating potential single points of failure when you plan your virtual domain controller deployment.frank
  52. 1 2 efleis (8 de junho de 2006). «Large AD database? Probably not this large». Blogs.technet.com. Consultado em 20 de novembro de 2011. Cópia arquivada em 17 de agosto de 2009
  53. ↑ Berkouwer, Sander. «Active Directory basics». Veeam Software
  54. ↑ Active Directory Service Interfaces, Microsoft
  55. ↑ «Domain and Forest Trusts Technical Reference». Microsoft Corporation. 28 de março de 2003. Trusts enable [...] authentication and [...] sharing resources across domains or forests
  56. ↑ «Domain and Forest Trusts Work». Microsoft Corporation. 11 de dezembro de 2012. Consultado em 29 de janeiro de 2013. Defines several kinds of trusts. (automatic, shortcut, forest, realm, external)
  57. ↑ «Privileged Access Management for Active Directory Domain Services». docs.microsoft.com. 8 de fevereiro de 2023
  58. ↑ «TechNet Wiki». social.technet.microsoft.com. 17 de janeiro de 2024
  59. 1 2 Edge, Charles S. Jr; Smith, Zack; Hunter, Beau (2009). «Chapter 3: Active Directory». Enterprise Mac Administrator's Guide. New York City: Apress. ISBN 978-1-4302-2443-3
  60. ↑ «Samba 4.0.0 Available for Download». SambaPeople. SAMBA Project. Consultado em 9 de agosto de 2016. Cópia arquivada em 15 de novembro de 2010
  61. ↑ «The great DRS success!». SambaPeople. SAMBA Project. 5 de outubro de 2009. Consultado em 2 de novembro de 2009. Cópia arquivada em 13 de outubro de 2009
  62. ↑ «RFC 2307bis». Consultado em 20 de novembro de 2011. Cópia arquivada em 27 de setembro de 2011
  63. ↑ «Active Directory Administration with Windows PowerShell». Microsoft. Consultado em 7 de junho de 2011
  64. ↑ «Using Scripts to Search Active Directory». Microsoft. 26 de maio de 2010. Consultado em 22 de maio de 2012
  65. ↑ «ITAdminTools Perl Scripts Repository». ITAdminTools.com. Consultado em 22 de maio de 2012
  66. ↑ «Win32::OLE». Perl Open-Source Community. Consultado em 22 de maio de 2012
  67. ↑ «Introducing AWS Directory Service for Microsoft Active Directory (Standard Edition)». Amazon Web Services. 24 de outubro de 2017
  68. ↑ «What is hybrid identity with Microsoft Entra?». learn.microsoft.com (em inglês). Consultado em 23 de julho de 2026
  69. ↑ «Compare Active Directory to Microsoft Entra ID». learn.microsoft.com (em inglês). Consultado em 23 de julho de 2026
  70. ↑ «What is Microsoft Entra Connect and Connect Health?». learn.microsoft.com (em inglês). Consultado em 23 de julho de 2026
  71. ↑ «Securing Domain Controllers Against Attacks». learn.microsoft.com (em inglês). Consultado em 23 de julho de 2026
  72. ↑ «Securing devices for privileged access». learn.microsoft.com (em inglês). Consultado em 23 de julho de 2026
  73. ↑ «Zero Trust deployment guide for Microsoft Entra ID». learn.microsoft.com (em inglês). Consultado em 23 de julho de 2026