> 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/es/pam/administration/integrations/ad-bridge.md).

# AD Bridge para hosts Linux

Una hosts Linux a Active Directory para que los usuarios y grupos del directorio se conviertan en cuentas del sistema operativo, con mapeo de UID, política de sudo y gestión de keytab administrados de

AD Bridge une **servidores Linux** a Active Directory o a un directorio LDAP corporativo, de modo que los usuarios y grupos del directorio sean reconocidos por el host como cuentas nativas del sistema operativo. La flota deja de arrastrar entradas de cuentas locales, claves SSH no gestionadas y credenciales sueltas por máquina.

{% hint style="warning" %}
**Esto no es lo mismo que el inicio de sesión en la consola contra el directorio.** Autenticar a los *usuarios de la consola* contra un directorio se configura en [LDAP y Active Directory](/es/pam/administration/identities/ldap-and-ad.md) y no instala nada en ninguna parte. AD Bridge es una propiedad del *host de destino*: un agente se ejecuta en el servidor Linux y convierte las identidades del directorio en cuentas locales en él. Las dos funcionalidades se configuran por separado y pueden usarse de forma independiente.
{% endhint %}

## Qué es esto y cuándo usarlo

En un parque mixto, las máquinas Windows suelen estar ya en el dominio mientras que la flota Linux funciona sobre cuentas locales dispersas, con una política inconsistente de máquina a máquina. Eso amplía la superficie de ataque, dificulta la revocación a tiempo y fragmenta el registro de auditoría.

AD Bridge extiende la identidad del directorio hasta el host:

| Propiedad                          | Efecto                                                                                                            |
| ---------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| **Una identidad**                  | El `sAMAccountName` / `userPrincipalName` del directorio *es* el inicio de sesión de Linux. Sin alias locales     |
| **Grupos como autorización**       | La pertenencia a grupos del directorio decide quién alcanza qué hosts, y con qué perfil                           |
| **Aprovisionamiento bajo demanda** | La cuenta y sus grupos se materializan en el host solo cuando un usuario autorizado inicia sesión por primera vez |
| **Política central**               | Las reglas de acceso, sudo, shell y directorio personal se definen una vez y se envían a los hosts                |
| **Un solo registro de auditoría**  | Autenticación, aprovisionamiento y acciones privilegiadas caen en el mismo registro que los demás eventos         |

Como la autorización deriva de los grupos del directorio, conceder o revocar acceso en toda una flota Linux es una operación en el directorio, no un cambio en cada máquina.

{% hint style="info" %}
El directorio sigue siendo la fuente autoritativa de identidad. La solución es el punto de decisión y el punto de auditoría: toda pregunta sobre quién puede autenticarse, en qué host y bajo qué política se evalúa de forma centralizada antes de aplicarse al sistema operativo.
{% endhint %}

## Cómo encajan las piezas

Tres planos, que se comunican por canales autenticados y cifrados:

| Plano                | Qué contiene                                                                                                                                                                              |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Directorio**       | Active Directory o LDAP: objetos de usuario y de grupo, pertenencias, atributos, y si una cuenta está habilitada o bloqueada                                                              |
| **Plano de control** | El catálogo de hosts Linux unidos, los conjuntos de grupos autorizados por host o grupo de hosts, las reglas de sudo, los parámetros de aprovisionamiento y la configuración de auditoría |
| **Host**             | El agente de AD Bridge: realiza la unión, resuelve las identidades del directorio para el sistema operativo, aplica la política que recibe e informa de los eventos                       |

El agente se encarga de la unión y de la renovación de la confianza de la cuenta de máquina, resuelve usuarios y grupos en la pila de servicio de nombres y de autenticación del host, aplica localmente la política recibida e informa hacia arriba de los eventos de autenticación y aprovisionamiento.

{% hint style="warning" %}
El agente no almacena **ninguna credencial de usuario en texto claro** en el host. Las contraseñas se validan contra el directorio por Kerberos o LDAP. La caché sin conexión, cuando está habilitada, solo conserva verificadores protegidos, con un tiempo de vida fijado por política.
{% endhint %}

## Antes de empezar

* **DNS.** El host Linux debe resolver los registros SRV del dominio (`_ldap._tcp`, `_kerberos._tcp`) y los nombres de los controladores de dominio. Un DNS inconsistente es, con diferencia, la causa más frecuente de una unión fallida.
* **Hora.** Kerberos exige poca desviación de reloj, normalmente por debajo de cinco minutos, entre el host, el controlador de dominio y la solución. Ejecute NTP o chrony en todas partes.
* **Red.** Los servicios de directorio (LDAP/LDAPS, Kerberos) deben ser alcanzables desde el host, además del canal autenticado del agente hacia la solución.
* **Una cuenta de unión.** Una cuenta de servicio del directorio con permiso delegado para crear y gestionar cuentas de máquina en la OU de destino. Manténgala con el mínimo privilegio, acotada a la OU que contiene los servidores Linux y a nada más.
* **Una distribución soportada**, con la pila de autenticación del sistema operativo disponible.
* **La credencial de unión en la bóveda.** Se custodia en la [bóveda de credenciales](/es/pam/administration/accounts/vault.md), nunca en un archivo del host.

## Pasos

1. **Registre el host.** El servidor Linux se añade al [Inventario](/es/pam/administration/assets/inventory.md), a mano o mediante descubrimiento, y recibe su propia identidad y el agente de AD Bridge.
2. **Decida el modelo de autorización** antes de unir nada: qué *grupos* del directorio pueden autenticarse en qué hosts o grupos de hosts. Modele por grupo, no por usuario individual: eso es lo que hace que conceder y revocar escalen.
3. **Una el host.** El agente solicita la credencial de unión; se libera de la bóveda justo a tiempo, acotada y limitada en el tiempo a la operación de unión únicamente. El agente localiza entonces un controlador de dominio mediante los registros SRV del DNS, se autentica por Kerberos y crea o actualiza la **cuenta de máquina** en la OU designada.
4. **Se establece la confianza.** Se genera un keytab para la cuenta de máquina y se almacena protegido en el host, de modo que la autenticación Kerberos deja de depender de una contraseña estática.
5. **Se envía la configuración de identidad.** El dominio y los realms, el esquema de mapeo UID/GID, la plantilla de directorio personal y el shell por defecto se envían al host.
6. **Confirme y audite.** El agente confirma la unión, y el evento se escribe en el registro de auditoría con el host, la OU, la cuenta de máquina, el operador responsable y la marca de tiempo.

{% hint style="info" %}
La credencial de unión nunca queda fijada en el host. Tras la unión, la confianza descansa sobre el keytab de la cuenta de máquina, cuya contraseña se rota automáticamente según la política del dominio y la de la solución.
{% endhint %}

### Salir del dominio

La retirada sigue el mismo camino auditado a la inversa: se revoca la política, el agente elimina la confianza local, y la cuenta de máquina se deshabilita o se borra en la OU, con todo el evento registrado. Eso es lo que mantiene el desmantelamiento libre de cuentas huérfanas.

## Aprovisionamiento en el host

Los usuarios y grupos autorizados del directorio se materializan sin tocar el host a mano:

* **Disparado por el primer inicio de sesión.** Cuando un usuario del directorio que pertenece a un grupo autorizado se autentica por primera vez en un host unido, la cuenta se crea de forma transparente.
* **Directorio personal a partir de una plantilla.** El directorio personal se construye a partir de un modelo definido por política (estructura, skel, permisos), respetando los atributos POSIX del directorio allí donde existan.
* **Grupos reflejados.** Los grupos relevantes del directorio se reflejan en el host **con los mismos nombres**, y allí gobiernan la pertenencia y el privilegio.
* **Desaprovisionamiento por política.** Perder la pertenencia a un grupo autorizado, o que se revoque el acceso de forma centralizada, termina el acceso. Las cuentas inactivas pueden archivarse o eliminarse según la retención que usted fije.

## Mapeo de UID y GID

La identidad debe ser la misma en todos los hosts, y coherente con el directorio:

| Situación                                       | Qué ocurre                                                                                                                                  |
| ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| El directorio publica `uidNumber` / `gidNumber` | Esos valores se adoptan directamente                                                                                                        |
| No hay atributos POSIX presentes                | Un algoritmo determinista deriva el UID y el GID del identificador inmutable del objeto (SID o GUID)                                        |
| Varios dominios o bosques                       | Los realms y las relaciones de confianza se gestionan para que las identidades de dominios distintos no colisionen en el espacio de UID/GID |

{% hint style="warning" %}
La derivación determinista significa que **el mismo usuario obtiene el mismo UID en todos los hosts**, que es lo que hace que los sistemas de archivos compartidos como NFS se comporten correctamente. Si más adelante añade atributos POSIX al directorio para usuarios ya aprovisionados a partir de valores derivados, los dos esquemas discrepan y la propiedad de los archivos en el almacenamiento compartido deja de coincidir. Decida qué esquema va a usar antes de desplegar la flota, y prefiera los atributos POSIX en el directorio siempre que los hosts compartan archivos.
{% endhint %}

## Política aplicada de forma centralizada

Las políticas se definen una vez y se propagan a los hosts unidos:

* **Acceso, por host y por grupo de hosts.** Qué grupos del directorio pueden autenticarse en qué servidores, opcionalmente acotado por franja horaria y otras restricciones contextuales.
* **Elevación de privilegio (sudo).** Las reglas de `sudo` por grupo y por host se administran de forma centralizada, en lugar de archivos `sudoers` editados máquina por máquina.
* **GPO donde aplica.** Allí donde el entorno publica una política de grupo con semántica que significa algo en Linux (parámetros de inicio de sesión, mensajes, restricciones compatibles), AD Bridge la interpreta y la aplica localmente.
* **Shell y directorio personal.** El shell por defecto, el skel y la política de creación del directorio personal se uniformizan mediante la configuración distribuida.

{% hint style="warning" %}
**Dos reglas que discrepan se resuelven por especificidad, no por orden.** Una regla escrita para un solo host gana sobre una regla escrita para un grupo de hosts, y el conflicto queda registrado para revisión administrativa. Busque esos registros antes de concluir que un host "ignora" una política.
{% endhint %}

{% hint style="info" %}
Una directiva de política de grupo **sin equivalente en Linux se ignora de forma segura y se registra**. No se aplica a medias y no produce efectos secundarios. Si esperaba que un ajuste exclusivo de Windows surtiera efecto en un host Linux, es en el registro donde descubrirá que se omitió.
{% endhint %}

## Qué queda auditado

Todo lo mediado por AD Bridge alimenta el [registro de auditoría](/es/pam/administration/audit/audit-trail.md):

| Familia                 | Eventos                                                                                                                         |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| **Autenticación**       | Inicio de sesión correcto y fallido, origen, host, identidad del directorio y método (Kerberos, contraseña, caché sin conexión) |
| **Aprovisionamiento**   | Creación, actualización y eliminación de cuentas y grupos, con el operador o la política responsable                            |
| **Acción privilegiada** | `sudo` y elevaciones, correlacionados con la identidad real del directorio en lugar de enmascarados tras una cuenta genérica    |
| **Confianza**           | Unión y salida del dominio, rotación de keytab y cambios en la confianza                                                        |

Los registros son inmutables, con marca de tiempo y correlacionables con el resto del registro, de modo que "quién accedió a qué, cuándo, desde dónde y bajo qué autorización" puede reconstruirse de extremo a extremo.

## Cómo encaja con el resto de la solución

* **Bóveda.** Las credenciales de unión y los keytabs los custodia y rota la [bóveda](/es/pam/administration/accounts/vault.md), se entregan justo a tiempo y nunca quedan en archivos de configuración.
* **Grabación de sesión.** Las sesiones interactivas de SSH y de consola abiertas por identidades del directorio en estos hosts pueden mediarse y grabarse, indexadas por comando y por usuario.
* **RBAC.** Los [roles](/es/pam/administration/identities/roles.md) deciden quién administra la integración, quién aprueba el acceso privilegiado y quién puede leer la auditoría, manteniendo separados operador, aprobador y auditor.
* **Aprobación y acceso limitado en el tiempo.** El acceso elevado en hosts Linux puede exigir aprobación y caducar, conforme a las políticas de [acceso just-in-time](/es/pam/administration/access/just-in-time.md).

## Cómo verificar que funcionó

No se detenga en "la unión informó de éxito". Compruebe las cosas que de verdad se rompen después:

1. **La unión está en el registro.** Confirme el evento de unión, con el host, la OU, la cuenta de máquina y el operador. Después confirme en el directorio que la cuenta de máquina existe en la OU que pretendía, y no en el contenedor de equipos por defecto.
2. **Una identidad autorizada se aprovisiona en el primer inicio de sesión.** Inicie sesión en el host con un usuario del directorio que pertenezca a un grupo autorizado. La cuenta debe crearse, el directorio personal debe existir a partir de la plantilla, e `id <user>` debe devolver los grupos del directorio.
3. **El UID es el mismo en todas partes.** Ejecute `id <user>` en un **segundo** host unido y compare. UIDs distintos en dos hosts significan que ambos no están usando el mismo esquema de mapeo, y el almacenamiento compartido mostrará propietarios equivocados.
4. **El `sudo` se atribuye a la persona real.** Ejecute un comando privilegiado y confirme que el registro de auditoría nombra la identidad del directorio, y no una cuenta genérica. Ese es todo el sentido de la integración.
5. **La revocación revoca de verdad.** Quite al usuario de prueba del grupo autorizado en el directorio y confirme que el siguiente inicio de sesión se rechaza.
6. **Tras una salida del dominio**, confirme que la cuenta de máquina está deshabilitada o borrada en la OU y que no quedan cuentas huérfanas en el host.

## Errores frecuentes

| Síntoma                                                                         | Causa                                                                                                                           | Solución                                                                                                                  |
| ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| La unión falla al localizar el dominio                                          | El host no puede resolver los registros SRV del dominio                                                                         | Arregle el DNS en el host y verifique que `_ldap._tcp` y `_kerberos._tcp` resuelven antes de reintentar                   |
| La unión alcanza el controlador y después falla en Kerberos                     | Desviación de reloj por encima de la ventana permitida                                                                          | Habilite NTP o chrony en el host, el controlador y la solución, y reintente                                               |
| La unión falla al crear la cuenta de máquina                                    | La cuenta de unión carece de derechos delegados en la OU de destino                                                             | Delegue la creación de cuentas de máquina en esa OU a la cuenta de unión, manteniendo el mínimo privilegio                |
| Un usuario del directorio no puede iniciar sesión en un host unido              | El usuario no está en ningún grupo autorizado para ese host                                                                     | Añada el grupo a la autorización del host, no al usuario individual                                                       |
| El mismo usuario tiene UIDs distintos en dos hosts                              | Un host lee los atributos POSIX del directorio y el otro los derivó, o los atributos se añadieron después del aprovisionamiento | Fije un único esquema; donde los hosts comparten archivos, publique atributos POSIX en el directorio                      |
| Un ajuste de política de grupo no surte efecto en Linux                         | La directiva no tiene equivalente en Linux y se ignoró de forma segura                                                          | Consulte el registro de la directiva omitida; aplique el equivalente mediante la política Linux central                   |
| Un host se comporta de forma distinta al resto de su grupo                      | Una regla específica de ese host prevalece sobre la del grupo de hosts                                                          | Lea el conflicto registrado y después elimine o corrija la regla más específica                                           |
| La autenticación sigue funcionando con el directorio caído, o deja de funcionar | La caché sin conexión está habilitada o deshabilitada, con un tiempo de vida fijado por política                                | Decida el comportamiento sin conexión por política, en lugar de descubrirlo durante una caída                             |
| Un host desmantelado todavía tiene cuenta en el directorio                      | El host se borró en lugar de sacarlo del dominio                                                                                | Sáquelo del dominio a través de la solución, para que la cuenta de máquina y la política se eliminen y queden registradas |

## Referencia de campos

### Atributos POSIX respetados desde el directorio

| Atributo            | Se usa para                                       |
| ------------------- | ------------------------------------------------- |
| `uidNumber`         | El ID numérico de usuario de la cuenta en el host |
| `gidNumber`         | El ID numérico del grupo primario de la cuenta    |
| `loginShell`        | El shell de inicio de sesión                      |
| `unixHomeDirectory` | La ruta del directorio personal                   |

Publicarlos no es condición de la integración. Allí donde falten, el UID y el GID se derivan de forma determinista del SID o GUID del objeto.

### Prácticas que conviene adoptar

| Práctica                                                         | Por qué                                                                         |
| ---------------------------------------------------------------- | ------------------------------------------------------------------------------- |
| Dedique una OU a los servidores Linux y delegue solo sobre ella  | Mantiene la cuenta de unión con el mínimo privilegio                            |
| Estandarice NTP y DNS antes de unir la flota                     | Las dos causas de casi toda unión fallida                                       |
| Publique atributos POSIX donde los hosts compartan archivos      | Elimina cualquier dependencia de UIDs derivados a través de NFS                 |
| Autorice por grupo, nunca por usuario                            | Conceder y revocar siguen siendo una sola operación para toda la flota          |
| Fije la retención de grabación y de auditoría desde el principio | Una pregunta formulada fuera de la ventana de retención ya no puede responderse |

## Páginas relacionadas

* [LDAP y Active Directory](/es/pam/administration/identities/ldap-and-ad.md): la otra integración con directorio, que autentica a los *usuarios de la consola* sin instalar nada
* [Descubrimiento de cuentas](/es/pam/administration/accounts/discovery-of-accounts.md): tratar las cuentas del directorio como credenciales gestionadas
* [La bóveda de credenciales](/es/pam/administration/accounts/vault.md): dónde viven la credencial de unión y los keytabs
* [Registro de auditoría](/es/pam/administration/audit/audit-trail.md): dónde caen los eventos de autenticación, aprovisionamiento y `sudo`
* [Usuarios y grupos](/es/pam/administration/identities/users-and-groups.md): cómo la pertenencia a grupos determina la autorización