For the complete documentation index, see llms.txt. This page is also available as Markdown.

AD Bridge para Linux

AD Bridge do DataDike PAM — integração de servidores Linux ao Active Directory/LDAP para autenticação, provisionamento automático e controle centralizado de identidades, com auditoria unificada.

O AD Bridge é o recurso de compatibilidade do DataDike PAM que habilita a autenticação e o controle centralizado de identidades de servidores Linux contra o Active Directory (AD) e diretórios LDAP corporativos. Por meio dele, hosts Linux passam a reconhecer usuários e grupos do diretório como contas nativas do sistema operacional, eliminando a necessidade de bases de identidade locais paralelas e de credenciais avulsas em cada máquina.

Diferentemente de abordagens que duplicam contas ou exigem sincronização manual, o AD Bridge mantém a mesma nomenclatura de usuários e grupos do diretório e realiza o provisionamento automático e transparente das identidades autorizadas no momento do primeiro acesso, sob políticas administradas de forma central a partir do PAM.

O AD Bridge é parte do plano de controle do DataDike PAM. Toda decisão de quem pode autenticar, em quais hosts e sob quais políticas é avaliada pelo PAM antes de ser aplicada ao sistema operacional Linux — o diretório permanece como fonte autoritativa de identidade, e o PAM como ponto de decisão e auditoria.

Visão geral

Em ambientes heterogêneos, é comum que estações e servidores Windows já estejam integrados ao domínio, enquanto a frota Linux opera com contas locais dispersas, chaves SSH não gerenciadas e políticas inconsistentes entre máquinas. Esse modelo amplia a superfície de ataque, dificulta a revogação tempestiva de acessos e fragmenta a trilha de auditoria.

O AD Bridge unifica esse cenário ao estender a identidade do diretório para os hosts Linux:

  • Identidade única: o mesmo sAMAccountName/userPrincipalName do AD é o login no Linux, sem aliases locais.

  • Grupos como autorização: a pertinência a grupos do diretório governa quem acessa quais hosts e com qual perfil.

  • Provisionamento sob demanda: contas e grupos são materializados no host apenas quando autorizados, de forma transparente para o usuário.

  • Políticas centralizadas: regras de acesso, sudo, shell e diretório-base são definidas no PAM e propagadas aos hosts.

  • Auditoria integrada: cada autenticação, provisionamento e ação privilegiada é registrada na trilha unificada do PAM.

Componentes da arquitetura

A integração envolve três planos que se comunicam por canais autenticados e cifrados:

Plano de diretório

O Active Directory/LDAP corporativo permanece como fonte autoritativa de identidade. Ele detém os objetos de usuário e grupo, suas filiações, atributos e o estado de habilitação/bloqueio das contas. O AD Bridge não altera o esquema do diretório como condição de funcionamento; quando atributos POSIX (uidNumber, gidNumber, loginShell, unixHomeDirectory) estão presentes, eles são respeitados, e quando ausentes, o PAM gera mapeamento determinístico e estável (ver Mapeamento de identidade unificada).

Plano de controle (DataDike PAM)

O PAM concentra a política. Ele mantém o catálogo de hosts Linux ingressados, os conjuntos de grupos autorizados por host ou por grupo de hosts, as regras de elevação (sudo), os parâmetros de provisionamento e a configuração de auditoria. É no plano de controle que se decide se um usuário do diretório pode autenticar em determinado host e como sua conta será materializada.

Plano de host (agente AD Bridge no Linux)

Em cada servidor Linux executa o agente AD Bridge, responsável por:

  • Realizar o ingresso (join) do host ao domínio e renovar a confiança da conta de máquina.

  • Resolver identidades e grupos do diretório para o sistema operacional (camada de name service e de autenticação do SO).

  • Aplicar localmente as políticas recebidas do PAM (acesso, sudo, shell, home).

  • Reportar eventos de autenticação e provisionamento ao plano de controle.

Pré-requisitos

Antes de ingressar hosts Linux ao domínio via AD Bridge, verifique:

  • Resolução de nomes (DNS): os hosts Linux devem resolver os registros SRV do domínio (_ldap._tcp, _kerberos._tcp) e os nomes dos controladores de domínio. DNS inconsistente é a causa mais comum de falha de join.

  • Sincronização de tempo (NTP/chrony): a autenticação Kerberos exige skew de relógio reduzido (tipicamente até cinco minutos) entre host, controlador de domínio e PAM.

  • Conectividade de rede: liberação dos serviços de diretório (LDAP/LDAPS, Kerberos), além do canal autenticado entre o agente e o PAM.

  • Conta de ingresso: uma conta de serviço do AD com permissão delegada para criar/gerenciar a conta de máquina na unidade organizacional (OU) de destino. Recomenda-se o menor privilégio, restrito à OU dos servidores Linux.

  • Distribuição suportada: sistema Linux dentro da matriz de compatibilidade do agente AD Bridge, com pilha de autenticação do SO disponível.

  • Cofre de credenciais do PAM: a credencial da conta de ingresso deve estar custodiada no cofre do DataDike PAM, não em arquivos no host.

Fluxo de ingresso (join) do host Linux ao domínio

O ingresso é orquestrado pelo PAM e executado pelo agente no host. O fluxo típico:

  1. Registro do host no PAM. O servidor Linux é cadastrado no inventário do PAM (manualmente ou por descoberta), recebendo identidade própria e o agente AD Bridge.

  2. Recuperação segura da credencial de ingresso. O agente solicita ao PAM a credencial da conta de join; o PAM a entrega a partir do cofre, com escopo e validade restritos à operação de ingresso (acesso just-in-time).

  3. Negociação com o diretório. O agente localiza o controlador de domínio via DNS/SRV, autentica via Kerberos e cria/atualiza a conta de máquina na OU designada.

  4. Estabelecimento da confiança. É gerada a keytab da conta de máquina, armazenada de forma protegida no host, permitindo autenticação Kerberos sem senha estática.

  5. Aplicação de configuração de identidade. O PAM envia ao host o domínio, os realms, o esquema de mapeamento de UID/GID, o template de diretório-base e o shell padrão.

  6. Confirmação e auditoria. O agente confirma o join, e o PAM registra o evento (host, OU, conta de máquina, operador responsável, data/hora) na trilha unificada.

Saída do domínio (unjoin)

A remoção de um host segue caminho equivalente e auditado: o PAM revoga as políticas, o agente remove a confiança local e a conta de máquina é desativada/excluída na OU, com registro completo do evento. Isso garante descomissionamento limpo, sem contas órfãs.

Provisionamento automático e transparente

O provisionamento de usuários e grupos do AD autorizados ocorre sem intervenção manual no host:

  • Acionamento por primeiro acesso. Quando um usuário do diretório, pertencente a um grupo autorizado, autentica pela primeira vez em um host ingressado, sua conta é materializada no SO de forma transparente.

  • Diretório-base sob template. O home é criado a partir de um modelo definido por política (estrutura, skel, permissões), respeitando atributos POSIX do diretório quando existirem.

  • Grupos espelhados. Os grupos do diretório relevantes são refletidos no host, preservando a mesma nomenclatura e governando associações e privilégios.

  • Desprovisionamento por política. A perda de filiação a um grupo autorizado, ou a revogação no PAM, encerra o acesso; contas inativas podem ser arquivadas ou removidas conforme retenção definida.

Como a autorização deriva de grupos do diretório, conceder ou revogar acesso a uma frota inteira de servidores Linux passa a ser uma operação única no AD/PAM, sem tocar máquina a máquina.

Mapeamento de identidade unificada

O AD Bridge garante que a identidade seja a mesma em todos os hosts e consistente com o diretório:

  • Nomenclatura preservada. O login Linux corresponde ao identificador do diretório; não há criação de nomes alternativos por host.

  • Atributos POSIX nativos. Quando o diretório publica uidNumber/gidNumber, eles são adotados diretamente.

  • Mapeamento determinístico. Na ausência de atributos POSIX, o PAM aplica algoritmo determinístico que deriva UID/GID a partir do identificador imutável do objeto (SID/GUID), assegurando que o mesmo usuário receba o mesmo UID em todos os hosts — essencial para sistemas de arquivos compartilhados (NFS) e consistência de permissões.

  • Múltiplos domínios/florestas. Realms e relações de confiança são tratados de forma que identidades de diferentes domínios não colidam no espaço de UID/GID.

Aplicação centralizada de políticas

As políticas são definidas uma vez no PAM e propagadas aos hosts ingressados:

  • Acesso por host e por grupo de hosts. Define quais grupos do diretório podem autenticar em quais servidores, com possibilidade de janelas de tempo e restrições contextuais.

  • Elevação de privilégio (sudo). Regras de sudo por grupo/host são administradas centralmente, substituindo arquivos sudoers editados manualmente em cada máquina.

  • GPO onde aplicável. Onde o ambiente disponibiliza diretivas de grupo (GPO) com semântica aplicável a Linux, o AD Bridge as interpreta e impõe localmente (por exemplo, parâmetros de logon, mensagens e restrições compatíveis). Quando uma diretiva não tem equivalente em Linux, ela é ignorada de forma segura e registrada, sem efeitos colaterais.

  • Shell e diretório-base. Shell padrão, skel e política de criação de home são uniformizados pela configuração distribuída.

A precedência de políticas é resolvida no plano de controle: regras mais específicas (por host) prevalecem sobre regras mais amplas (por grupo de hosts), e conflitos são registrados para revisão administrativa.

Auditoria integrada

Toda a atividade mediada pelo AD Bridge alimenta a trilha de auditoria unificada do DataDike PAM:

  • Eventos de autenticação: sucesso e falha de logon, origem, host, identidade do diretório e método (Kerberos/senha/offline).

  • Eventos de provisionamento: criação/atualização/remoção de contas e grupos, com o operador ou política responsável.

  • Ações privilegiadas: uso de sudo e elevações, correlacionadas à identidade real do diretório (sem mascaramento por contas genéricas).

  • Operações de ingresso/saída: join/unjoin, rotação de keytab e alterações de confiança.

Os registros são imutáveis, carimbados no tempo e correlacionáveis aos demais eventos do PAM, permitindo reconstruir, ponta a ponta, "quem acessou o quê, quando, a partir de onde e com qual autorização".

Integração com o restante do DataDike PAM

O AD Bridge não opera isolado: ele reaproveita os mecanismos centrais do PAM.

  • Cofre de credenciais. Credenciais de ingresso e keytabs são custodiadas e rotacionadas pelo cofre, com entrega just-in-time e sem exposição em arquivos de configuração.

  • Gravação de sessão. Sessões interativas (SSH e console) abertas por identidades do diretório nos hosts Linux podem ser intermediadas e gravadas pelo PAM, com indexação por comando e por usuário.

  • RBAC. O controle de acesso baseado em papéis do PAM determina quem administra a integração, quem aprova acessos privilegiados e quem pode consultar a auditoria, segregando funções entre operadores, aprovadores e auditores.

  • Fluxos de aprovação e acesso temporário. Acessos elevados em hosts Linux podem exigir aprovação e ter duração limitada, alinhados às políticas just-in-time do PAM.

Dessa forma, a identidade vem do diretório, o controle e a evidência vêm do PAM, e o host Linux torna-se um recurso plenamente governado pela plataforma.

Boas práticas

  • Restrinja a conta de join a uma OU dedicada de servidores Linux, com delegação mínima.

  • Padronize NTP e DNS antes de ingressar a frota; valide os registros SRV.

  • Prefira atributos POSIX no diretório quando houver compartilhamento de arquivos entre hosts.

  • Modele autorização por grupos, não por usuários individuais, para escalar concessão e revogação.

  • Defina retenção de gravações de sessão e de logs de auditoria conforme as exigências regulatórias aplicáveis.

Atualizado

Isto foi útil?