> 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/integracoes/windows/ad-bridge-linux.md).

# AD Bridge para Linux

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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://wiki.datadike.com/integracoes/windows/ad-bridge-linux.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.