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.

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

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.

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.

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.

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.

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, nunca en un archivo del host.

Pasos

1. Registre el host. El servidor Linux se añade al Inventario, 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.

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.

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

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.

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.

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.

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

Qué queda auditado

Todo lo mediado por AD Bridge alimenta el registro de auditoría:

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

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: la otra integración con directorio, que autentica a los usuarios de la consola sin instalar nada

• Descubrimiento de cuentas: tratar las cuentas del directorio como credenciales gestionadas

• La bóveda de credenciales: dónde viven la credencial de unión y los keytabs

• Registro de auditoría: dónde caen los eventos de autenticación, aprovisionamiento y sudo

• Usuarios y grupos: cómo la pertenencia a grupos determina la autorización