> For the complete documentation index, see [llms.txt](https://wiki.datadike.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.datadike.com/product-docs/integracoes/windows/ad-bridge-linux.md).

# 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.

{% hint style="info" %}
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.
{% endhint %}

## 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.

{% hint style="warning" %}
O agente AD Bridge não armazena credenciais de usuário em claro no host. A validação de senha ocorre contra o diretório (Kerberos/LDAP), e o cache offline, quando habilitado, guarda apenas verificadores protegidos, com tempo de vida configurável por política.
{% endhint %}

## 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.

{% hint style="success" %}
A credencial de *join* nunca é fixada no host. Após o ingresso, a confiança é mantida pela *keytab* da conta de máquina, cuja senha é rotacionada automaticamente conforme a política do domínio e do PAM.
{% endhint %}

### 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.

{% hint style="info" %}
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.
{% endhint %}

## 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.