Implementando Confiança Bidirecional 'Forest-to-Forest' com Microsoft Active Directory do Zero
Descubra como a equipe da MULTIDIRECTOR construiu uma solução de confiança bidirecional 'forest-to-forest' do zero, integrando seu diretório MULTIDIRECTORY com o Active Directory da Microsoft. O artigo detalha os desafios técnicos, os protocolos envolvidos e a estratégia para uma migração suave.
MundiX News·21 de maio de 2026·12 min de leitura·👁 3 views
Em projetos de substituição de produtos de TI estrangeiros, um desafio recorrente é a impossibilidade de simplesmente desativar soluções existentes. Isso é particularmente verdadeiro para serviços de diretório e autenticação. Na MULTIDIRECTOR, desenvolvemos nosso próprio serviço de diretório, MULTIDIRECTORY (MD), uma implementação completa que inclui LDAP, ACL, RBAC, lógica de negócios e subsistema de auditoria desenvolvidos do zero. Utilizamos uma versão modificada do MIT Kerberos, PowerDNS para DNS e Kea DHCP para DHCP, com gerenciamento de políticas de grupo via Salt Stack. Nosso serviço foi projetado desde o início para compatibilidade com o ecossistema Microsoft, garantindo que serviços compatíveis com Active Directory (AD) também funcionem com MD.
O MD suporta ambientes híbridos Linux+Windows. No entanto, como muitos clientes possuem ambientes Active Directory completos, a substituição completa em uma única etapa é inviável tanto técnica quanto organizacionalmente. Isso cria a necessidade de garantir uma migração suave, permitindo que ambos os sistemas operem em paralelo por um período prolongado. Sem uma relação de confiança configurada entre o MD e o AD, teríamos dois mundos isolados, onde usuários, serviços e políticas não se cruzariam, e a administração se tornaria exponencialmente mais complexa. A solução é estabelecer uma relação de confiança entre os diretórios, permitindo autenticação e autorização transparentes. Um usuário de um domínio pode acessar recursos do outro sem perceber a distinção.
Existem três tipos principais de relações de confiança com domínios externos: Realm Trust, que é um acordo entre dois realms Kerberos para transferência de tickets e autenticação, mas não abrange LDAP, grupos ou lógica de autorização. External Trust é usado para confiança entre domínios individuais fora da mesma floresta, útil para integração pontual, mas com limitações. Forest Trust, por outro lado, é projetado especificamente para o ecossistema Active Directory, abrangendo não apenas Kerberos, mas também todos os mecanismos de autorização associados, como usuários, grupos, SIDs e protocolos Windows. Isso faz com que os dois diretórios sejam percebidos como um sistema unificado, tornando o acesso a recursos transparente.
Inicialmente, a equipe da MULTIDIRECTOR optou pelo Realm Trust para cobrir cenários básicos, como autenticação de usuários e transferência de tickets Kerberos. No entanto, rapidamente ficou claro que isso era insuficiente para infraestruturas complexas, especialmente no que diz respeito à autorização. Embora o Kerberos confirme a identidade do usuário e possa transmitir informações de grupo via PAC (Privilege Attribute Certificate), ele não fornece uma visão completa das permissões, exigindo manipulação manual do administrador para mapeamento de direitos. Para mitigar isso parcialmente, implementaram o LDAP Forward, que redireciona requisições LDAP para o domínio confiável, simplificando alguns cenários, principalmente para sistemas Linux baseados em LDAP. Contudo, o Realm Trust é inerentemente limitado e não atende às reais necessidades de infraestruturas corporativas.
Fora do ecossistema Microsoft, a implementação de confiança 'forest-to-forest' geralmente depende da Samba, que reproduziu os protocolos e o código-fonte da Microsoft. Soluções como FreeIPA utilizam componentes Samba como camada de comunicação RPC. Embora conveniente, essa abordagem apresenta desvantagens significativas: dependência de código C de terceiros, difícil controle e adaptação, e sensibilidade a atualizações do Windows que podem desestabilizar os protocolos de confiança. A equipe da MULTIDIRECTOR enfrentou casos em que atualizações do Windows quebraram a confiança, exigindo rollbacks e meses para correções na Samba, tornando soluções baseadas em Samba e FreeIPA reféns da equipe Samba. Essa dependência é inaceitável para um produto de infraestrutura.
Diante disso, a MULTIDIRECTOR decidiu implementar a confiança 'forest-to-forest' do zero, sem depender do código Samba. A escolha do Python, apesar da complexidade, foi deliberada. A principal dificuldade não foi o Kerberos em si, mas sim o complexo conjunto de mecanismos interconectados que a Microsoft utiliza, incluindo Kerberos v5, NTLM v2, EPM (RPC Mapper), Netlogon, DRSUAPI, SAMR, LSARPC (LSAD e LSAT), e SMB v2/v3. Esses mecanismos podem usar diferentes transportes, como SMB ou RPC direto. É importante notar que o NTLM v2 é considerado obsoleto e inseguro, com a Microsoft recomendando sua descontinuação. Portanto, a implementação da MULTIDIRECTOR focou no Kerberos como o único mecanismo de autenticação principal. A documentação, embora detalhada em métodos e interfaces, carecia de informações sobre os formatos de dados reais, exigindo análise de tráfego de rede e comparação com a implementação Samba. Após meses de imersão e análise, a equipe conseguiu entender os protocolos, reconstruir sequências de chamadas e descrever os métodos utilizados, avançando para uma fase de desenvolvimento mais previsível.
Embora a solução utilize o MIT Kerberos como base, ele não é compatível com o modelo Active Directory "out-of-the-box". Uma diferença crucial é a ausência do PAC (Privilege Attribute Certificate), que no AD contém informações essenciais para autorização, como grupos do usuário e SIDs. A implementação do suporte ao PAC foi necessária para garantir a compatibilidade com o Windows e o Forest Trust. Outro ponto importante é a identificação do usuário. No AD, um usuário pode ser identificado por samAccountName (domain\user) e UPN (user@domain.ru). O MIT Kerberos, por padrão, opera apenas com principals no formato username@REALM e é sensível a maiúsculas e minúsculas. Isso exigiu modificações no servidor TGS para processar corretamente as diferentes variantes. A confiança bidirecional opera em duas planos: gerenciamento e uso. O gerenciamento envolve a criação e manutenção da relação de confiança, utilizando protocolos como LSARPC e Netlogon para operações como criação, exclusão, modificação e verificação de confiança. O Netlogon é fundamental para construir o Secure Channel entre controladores de domínio, envolvendo um processo de autenticação com desafios e respostas para estabelecer uma conexão segura. Após o estabelecimento do Secure Channel, protocolos como LogonGetCapabilities e GetForestTrustInformation são usados para negociar capacidades e trocar informações sobre a floresta confiada. A atualização de senhas de confiança, que ocorre a cada 30 dias no AD, é crucial e realizada via NetrServerPasswordSet2, exigindo a atualização do Trusted Domain Object (TDO) e do principal krbtgt para manter a funcionalidade do Kerberos.
Os protocolos LSAD e LSAT desempenham papéis importantes no uso da confiança. O LSAD gerencia políticas de segurança e objetos de confiança, sendo usado para abrir handles de política, verificar a existência de domínios confiados e obter informações sobre a confiança. O LSAT é responsável pela conversão entre identificadores legíveis por humanos e SIDs, utilizando métodos como LsarLookupNames4 (samAccountName para SID) e LsarLookupSids3 (SID para samAccountName), permitindo que o AD trabalhe corretamente com usuários e grupos de outras florestas. O funcionamento do Forest Trust envolve a interação entre esses protocolos. Por exemplo, ao adicionar um usuário de MULTIDIRECTORY a um grupo do Active Directory, o AD utiliza LSAT para converter o samAccountName do usuário em um SID e, em seguida, o DRSUAPI confirma a existência do objeto e seus atributos. O processo de rede envolve o AD obtendo um TGS do KDC do MD, acessando o serviço SMB do MD, onde o ticket é descriptografado e a autenticidade confirmada. Em seguida, um Secure Channel é estabelecido usando a senha TDO, seguido por chamadas como NetrLogonSamLogonEx, que pode transmitir hashes NTLM ou o PAC Kerberos, dependendo do método de autenticação. Isso conclui o login do usuário do MULTIDIRECTORY no sistema AD. A equipe da MULTIDIRECTOR adquiriu experiência e competências únicas, resultando em uma implementação de confiança bidirecional que é a única escrita do zero nos últimos 20 anos.
Até o início de 2026, a MULTIDIRECTOR concluiu a implementação completa da confiança bidirecional 'forest-to-forest' com o Active Directory. Isso incluiu o suporte aos protocolos necessários, aprimoramentos no Kerberos, implementação de PAC e Global Catalog, e a reprodução da lógica de interação da Microsoft. O principal benefício não é apenas o mecanismo de confiança em si, mas o controle sobre ele. A empresa não depende de implementações de terceiros, podendo se adaptar rapidamente a mudanças no ecossistema e garantir um comportamento previsível nas infraestruturas dos clientes. Isso resolve um problema prático fundamental: a capacidade de construir infraestruturas híbridas e migrar do Active Directory para um diretório Linux sem interrupção dos negócios. Os planos futuros incluem o uso desses mesmos protocolos para implementar um Windows Domain Join completo. Fique atento às novidades!
Em projetos de substituição de produtos de TI estrangeiros, um desafio recorrente é a impossibilidade de simplesmente desativar soluções existentes. Isso é particularmente verdadeiro para serviços de diretório e autenticação. Na MULTIDIRECTOR, desenvolvemos nosso próprio serviço de diretório, MULTIDIRECTORY (MD), uma implementação completa que inclui LDAP, ACL, RBAC, lógica de negócios e subsistema de auditoria desenvolvidos do zero. Utilizamos uma versão modificada do MIT Kerberos, PowerDNS para DNS e Kea DHCP para DHCP, com gerenciamento de políticas de grupo via Salt Stack. Nosso serviço foi projetado desde o início para compatibilidade com o ecossistema Microsoft, garantindo que serviços compatíveis com Active Directory (AD) também funcionem com MD.
O MD suporta ambientes híbridos Linux+Windows. No entanto, como muitos clientes possuem ambientes Active Directory completos, a substituição completa em uma única etapa é inviável tanto técnica quanto organizacionalmente. Isso cria a necessidade de garantir uma migração suave, permitindo que ambos os sistemas operem em paralelo por um período prolongado. Sem uma relação de confiança configurada entre o MD e o AD, teríamos dois mundos isolados, onde usuários, serviços e políticas não se cruzariam, e a administração se tornaria exponencialmente mais complexa. A solução é estabelecer uma relação de confiança entre os diretórios, permitindo autenticação e autorização transparentes. Um usuário de um domínio pode acessar recursos do outro sem perceber a distinção.
Existem três tipos principais de relações de confiança com domínios externos: Realm Trust, que é um acordo entre dois realms Kerberos para transferência de tickets e autenticação, mas não abrange LDAP, grupos ou lógica de autorização. External Trust é usado para confiança entre domínios individuais fora da mesma floresta, útil para integração pontual, mas com limitações. Forest Trust, por outro lado, é projetado especificamente para o ecossistema Active Directory, abrangendo não apenas Kerberos, mas também todos os mecanismos de autorização associados, como usuários, grupos, SIDs e protocolos Windows. Isso faz com que os dois diretórios sejam percebidos como um sistema unificado, tornando o acesso a recursos transparente.
Inicialmente, a equipe da MULTIDIRECTOR optou pelo Realm Trust para cobrir cenários básicos, como autenticação de usuários e transferência de tickets Kerberos. No entanto, rapidamente ficou claro que isso era insuficiente para infraestruturas complexas, especialmente no que diz respeito à autorização. Embora o Kerberos confirme a identidade do usuário e possa transmitir informações de grupo via PAC (Privilege Attribute Certificate), ele não fornece uma visão completa das permissões, exigindo manipulação manual do administrador para mapeamento de direitos. Para mitigar isso parcialmente, implementaram o LDAP Forward, que redireciona requisições LDAP para o domínio confiável, simplificando alguns cenários, principalmente para sistemas Linux baseados em LDAP. Contudo, o Realm Trust é inerentemente limitado e não atende às reais necessidades de infraestruturas corporativas.
Fora do ecossistema Microsoft, a implementação de confiança 'forest-to-forest' geralmente depende da Samba, que reproduziu os protocolos e o código-fonte da Microsoft. Soluções como FreeIPA utilizam componentes Samba como camada de comunicação RPC. Embora conveniente, essa abordagem apresenta desvantagens significativas: dependência de código C de terceiros, difícil controle e adaptação, e sensibilidade a atualizações do Windows que podem desestabilizar os protocolos de confiança. A equipe da MULTIDIRECTOR enfrentou casos em que atualizações do Windows quebraram a confiança, exigindo rollbacks e meses para correções na Samba, tornando soluções baseadas em Samba e FreeIPA reféns da equipe Samba. Essa dependência é inaceitável para um produto de infraestrutura.
Diante disso, a MULTIDIRECTOR decidiu implementar a confiança 'forest-to-forest' do zero, sem depender do código Samba. A escolha do Python, apesar da complexidade, foi deliberada. A principal dificuldade não foi o Kerberos em si, mas sim o complexo conjunto de mecanismos interconectados que a Microsoft utiliza, incluindo Kerberos v5, NTLM v2, EPM (RPC Mapper), Netlogon, DRSUAPI, SAMR, LSARPC (LSAD e LSAT), e SMB v2/v3. Esses mecanismos podem usar diferentes transportes, como SMB ou RPC direto. É importante notar que o NTLM v2 é considerado obsoleto e inseguro, com a Microsoft recomendando sua descontinuação. Portanto, a implementação da MULTIDIRECTOR focou no Kerberos como o único mecanismo de autenticação principal. A documentação, embora detalhada em métodos e interfaces, carecia de informações sobre os formatos de dados reais, exigindo análise de tráfego de rede e comparação com a implementação Samba. Após meses de imersão e análise, a equipe conseguiu entender os protocolos, reconstruir sequências de chamadas e descrever os métodos utilizados, avançando para uma fase de desenvolvimento mais previsível.
Embora a solução utilize o MIT Kerberos como base, ele não é compatível com o modelo Active Directory "out-of-the-box". Uma diferença crucial é a ausência do PAC (Privilege Attribute Certificate), que no AD contém informações essenciais para autorização, como grupos do usuário e SIDs. A implementação do suporte ao PAC foi necessária para garantir a compatibilidade com o Windows e o Forest Trust. Outro ponto importante é a identificação do usuário. No AD, um usuário pode ser identificado por samAccountName (domain\user) e UPN (user@domain.ru). O MIT Kerberos, por padrão, opera apenas com principals no formato username@REALM e é sensível a maiúsculas e minúsculas. Isso exigiu modificações no servidor TGS para processar corretamente as diferentes variantes. A confiança bidirecional opera em duas planos: gerenciamento e uso. O gerenciamento envolve a criação e manutenção da relação de confiança, utilizando protocolos como LSARPC e Netlogon para operações como criação, exclusão, modificação e verificação de confiança. O Netlogon é fundamental para construir o Secure Channel entre controladores de domínio, envolvendo um processo de autenticação com desafios e respostas para estabelecer uma conexão segura. Após o estabelecimento do Secure Channel, protocolos como LogonGetCapabilities e GetForestTrustInformation são usados para negociar capacidades e trocar informações sobre a floresta confiada. A atualização de senhas de confiança, que ocorre a cada 30 dias no AD, é crucial e realizada via NetrServerPasswordSet2, exigindo a atualização do Trusted Domain Object (TDO) e do principal krbtgt para manter a funcionalidade do Kerberos.
Os protocolos LSAD e LSAT desempenham papéis importantes no uso da confiança. O LSAD gerencia políticas de segurança e objetos de confiança, sendo usado para abrir handles de política, verificar a existência de domínios confiados e obter informações sobre a confiança. O LSAT é responsável pela conversão entre identificadores legíveis por humanos e SIDs, utilizando métodos como LsarLookupNames4 (samAccountName para SID) e LsarLookupSids3 (SID para samAccountName), permitindo que o AD trabalhe corretamente com usuários e grupos de outras florestas. O funcionamento do Forest Trust envolve a interação entre esses protocolos. Por exemplo, ao adicionar um usuário de MULTIDIRECTORY a um grupo do Active Directory, o AD utiliza LSAT para converter o samAccountName do usuário em um SID e, em seguida, o DRSUAPI confirma a existência do objeto e seus atributos. O processo de rede envolve o AD obtendo um TGS do KDC do MD, acessando o serviço SMB do MD, onde o ticket é descriptografado e a autenticidade confirmada. Em seguida, um Secure Channel é estabelecido usando a senha TDO, seguido por chamadas como NetrLogonSamLogonEx, que pode transmitir hashes NTLM ou o PAC Kerberos, dependendo do método de autenticação. Isso conclui o login do usuário do MULTIDIRECTORY no sistema AD. A equipe da MULTIDIRECTOR adquiriu experiência e competências únicas, resultando em uma implementação de confiança bidirecional que é a única escrita do zero nos últimos 20 anos.
Até o início de 2026, a MULTIDIRECTOR concluiu a implementação completa da confiança bidirecional 'forest-to-forest' com o Active Directory. Isso incluiu o suporte aos protocolos necessários, aprimoramentos no Kerberos, implementação de PAC e Global Catalog, e a reprodução da lógica de interação da Microsoft. O principal benefício não é apenas o mecanismo de confiança em si, mas o controle sobre ele. A empresa não depende de implementações de terceiros, podendo se adaptar rapidamente a mudanças no ecossistema e garantir um comportamento previsível nas infraestruturas dos clientes. Isso resolve um problema prático fundamental: a capacidade de construir infraestruturas híbridas e migrar do Active Directory para um diretório Linux sem interrupção dos negócios. Os planos futuros incluem o uso desses mesmos protocolos para implementar um Windows Domain Join completo. Fique atento às novidades!
