| Campo | Valor |
|---|---|
| Título | Federación de Identidades — Active Directory + FreeIPA |
| Autor | Mario Sánchez |
| Rol | Administrador de Sistemas / DevOps |
| Versión | 1.0 |
| Fecha | 2026-05-26 |
| Estado | Borrador para revisión |
| Tipo de documento | Documento de Arquitectura Técnica |
| Documento relacionado | Implantación — Procedimientos de despliegue detallados |
| Versión | Fecha | Autor | Descripción del cambio |
|---|---|---|---|
| 1.0 | 2026-05-26 | Mario Sánchez | Versión inicial |
Este documento describe la arquitectura técnica para unificar la gestión de identidades de un entorno mixto compuesto por un bosque Microsoft Active Directory (AD) y una infraestructura de identidades Linux basada en FreeIPA.
Objetivo: Permitir que los usuarios del dominio Windows (nanobytes2.local) se autentiquen de forma transparente en los servidores Linux gestionados por FreeIPA (nanobytes.local), utilizando una única identidad corporativa. Esto elimina la necesidad de mantener cuentas locales duplicadas en los sistemas Linux y centraliza la política de acceso.
Beneficios principales:
Este documento cubre:
No cubre los procedimientos de instalación paso a paso (ver runbook-operaciones.md) ni la administración diaria de Active Directory o FreeIPA.
| Rol | Uso de este documento |
|---|---|
| Director / CTO | Resumen ejecutivo y beneficios (sección 1) |
| Arquitecto de Sistemas | Secciones 3, 5, 6, 7 y 10 |
| Administrador de Sistemas | Todas las secciones + runbook-operaciones.md |
| Responsable de Seguridad | Secciones 6, 7 y 9 |
| Equipo de Red | Sección 6 |
┌─────────────────────────────────────────────────────────────┐
│ RED CORPORATIVA │
│ │
│ ┌───────────────────────┐ ┌───────────────────────┐ │
│ │ DOMINIO WINDOWS │ │ DOMINIO LINUX │ │
│ │ nanobytes2.local │ │ nanobytes.local │ │
│ │ │ │ │ │
│ │ Windows Server │◄─────►│ FreeIPA │ │
│ │ AD DS + DNS │ Kerb. │ LDAP · KDC · DNS │ │
│ │ 172.16.50.239 │ Trust │ 192.168.56.10 │ │
│ │ │ │ │ │
│ │ Cliente Win 11 │ │ Servidor Linux │ │
│ │ (dominio AD) │──────►│ (cliente FreeIPA) │ │
│ │ │ SSH │ │ │
│ └───────────────────────┘ └───────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
La federación se basa en una relación de confianza de bosque cruzado (Cross-Realm Trust) mediante el protocolo Kerberos v5. Esto implica:
| Componente | Tecnología | Función | Responsable |
|---|---|---|---|
| Controlador de Dominio | Windows Server 2019/2022 · AD DS | Autoridad de identidad para usuarios Windows; KDC del dominio AD | Administrador Windows |
| Servidor DNS de AD | Windows DNS Server | Resolución de nombres del dominio nanobytes2.local; reenvío de consultas a FreeIPA |
Administrador Windows |
| Servidor FreeIPA | RHEL/Rocky Linux · FreeIPA | Autoridad de identidad para usuarios Linux; KDC del dominio IPA; DNS; CA interna | Administrador Linux |
| SSSD | System Security Services Daemon | Intermediario en los clientes Linux: búsqueda LDAP + autenticación Kerberos + caché offline | Administrador Linux |
| PAM + oddjobd | Pluggable Authentication Modules | Integración con el sistema de login de Linux; creación automática de directorios home | Administrador Linux |
| Samba (en FreeIPA) | Samba · CIFS | Establecimiento y mantenimiento del trust con AD; traducción de SIDs a UIDs POSIX | Gestionado por FreeIPA |
┌─────────────┐ ┌────────────────┐ ┌─────────┐ ┌────────────┐
│ Usuario AD │ │ Servidor Linux │ │ FreeIPA │ │ AD (KDC) │
└──────┬──────┘ └────────┬───────┘ └────┬────┘ └─────┬──────┘
│ │ │ │
│ 1. ssh usuario@IP │ │ │
├────────────────────►│ │ │
│ │ │ │
│ │ 2. Buscar usuario │ │
│ ├──────────────────►│ │
│ │ │ │
│ │ 3. Datos LDAP │ │
│ │ (uid/gid/home) │ │
│ │◄──────────────────┤ │
│ │ │ │
│ 4. Solicitar pwd │ │ │
│◄────────────────────┤ │ │
│ │ │ │
│ 5. Contraseña │ │ │
├────────────────────►│ │ │
│ │ 6. Validar Kerberos (TGS) │
│ ├───────────────────────────────► │
│ │ │ │
│ │ 7. Ticket OK │ │
│ │◄───────────────────────────────┤ │
│ │ │ │
│ │ 8. [oddjobd] Crear /home/usuario │
│ │ │ │
│ 9. Sesión abierta │ │ │
│◄────────────────────┤ │ │
│ │ │ │
Puntos críticos:
krb5 localice el KDC de AD. El sufijo .local puede interferir con mDNS si no se configura correctamente.NANOBYTES2.LOCAL).| Puerto | Protocolo | Flujo | Servicio | Fase |
|---|---|---|---|---|
| 88 | TCP + UDP | FreeIPA ↔ AD | Kerberos KDC | Trust + Autenticación |
| 389 | TCP | FreeIPA ↔ AD | LDAP | Búsqueda de usuarios y grupos |
| 636 | TCP | FreeIPA ↔ AD | LDAPS (TLS) | LDAP seguro (recomendado) |
| 464 | TCP + UDP | FreeIPA ↔ AD | Kerberos kpasswd | Cambio de contraseñas |
| 53 | TCP + UDP | FreeIPA ↔ AD | DNS | Resolución bidireccional |
| 135 | TCP | FreeIPA → AD | RPC endpoint | Establecimiento del trust |
| 445 | TCP | FreeIPA → AD | SMB/CIFS | Establecimiento del trust |
| 22 | TCP | Clientes → servidores Linux | SSH | Acceso interactivo |
| 80 / 443 | TCP | Administradores → FreeIPA | IPA Web UI | Administración web |
nanobytes.local → IP de FreeIPAnanobytes2.local → IP del DC de ADdnssec-validation no; en /etc/named/ipa-options-ext.conf.systemd-resolved, para que las queries SRV de Kerberos se resuelvan correctamente.Trusting forest): FreeIPA confía en los usuarios de AD, pero AD no gestiona recursos Linux. Esto limita el radio de impacto si el dominio Linux se ve comprometido.sudo porque éste cambia el contexto de ejecución al usuario root local, que no tiene contexto de red en AD.krb5_renewable_lifetime y krb5_renew_interval en /etc/sssd/sssd.conf para renovación automática.allow_all que permite el acceso SSH a todos los usuarios de todos los dominios. En producción, esta regla debe deshabilitarse y reemplazarse por reglas HBAC específicas antes de exponer el sistema.ALL en producción salvo para cuentas de administración explícitamente auditadas./var/log/secure (o journald) en los clientes Linux.IPA Server → Audit.Security → Audit Logon Events.| Área | Recomendación |
|---|---|
| Transporte LDAP | Usar LDAPS (puerto 636) en lugar de LDAP sin cifrar (389) |
| DNS | Mantener DNSSEC activo para el dominio propio de FreeIPA; deshabilitarlo solo para la zona de reenvío hacia AD |
| Acceso SSH | Deshabilitar autenticación por contraseña en sshd_config; requerir Kerberos o clave pública |
| Tickets Kerberos | Configurar tiempo de vida máximo acorde a la política de seguridad corporativa |
| HBAC | Deshabilitar allow_all antes del despliegue en producción |
| Cuentas de servicio | No usar la cuenta admin de FreeIPA para operaciones rutinarias; crear cuentas de servicio con privilegios mínimos |
| Fase | Descripción | Dependencias | Criterio de aceptación |
|---|---|---|---|
| F1 — Red | Unificar todas las VMs en una red común con visibilidad Capa 2 bidireccional | Infraestructura de red física/virtual disponible | ping bidireccional sin pérdida; Test-NetConnection al puerto 389 desde Windows |
| F2 — DNS bidireccional | Configurar reenviadores condicionales en AD y FreeIPA | F1 completada | dig nanobytes2.local desde FreeIPA devuelve NOERROR; Resolve-DnsName desde AD resuelve nanobytes.local |
| F3 — Unión de clientes Windows al dominio AD | Incorporar los equipos Windows al dominio nanobytes2.local |
F2 completada | nslookup nanobytes2.local devuelve la IP del DC sin timeout |
| F4 — Cross-Realm Trust | Establecer la relación de confianza entre FreeIPA y AD | F1 + F2 completadas; AD sin objetos trustedDomain residuales |
ipa trust-show nanobytes2.local → Trust status: Established and verified |
| F5 — Validación SSSD | Verificar que SSSD resuelve y mapea usuarios de AD en clientes Linux | F4 completada | id Administrador@nanobytes2.local devuelve uid/gid válidos |
| F6 — SSH federado | Autenticación SSH completa con creación dinámica de home | F5 completada; DNS del cliente Linux configurado correctamente | ssh usuario@nanobytes2.local@<IP> abre sesión; home creado en /home/nanobytes2.local/ |
| F7 — HBAC y Sudoers | Definir políticas de acceso y privilegios | F6 completada | ipa hbactest valida el acceso según las reglas definidas |
| Frecuencia | Comprobación | Comando |
|---|---|---|
| Diaria | Estado del trust | ipa trust-show nanobytes2.local \| grep "Trust status" |
| Diaria | Estado de SSSD | sssctl domain-status nanobytes2.local |
| Diaria | Servicios críticos | ipactl status |
| Semanal | Logs de autenticación | journalctl -u sssd --since "7 days ago" \| grep -i error |
| Mensual | Expiración de certificados IPA | ipa-getcert list |
| Mensual | Revisión de reglas HBAC | ipa hbacrule-find |
freeipa-server puede requerir reiniciar todos los servicios del dominio.ipa trust-fetch-domains nanobytes2.local para renovar las claves de confianza sin romper el trust.La arquitectura actual, con un único servidor FreeIPA y un único Controlador de Dominio, representa un punto único de fallo (SPOF). Para entornos de producción críticos, considerar:
| Componente | Solución de HA | Descripción |
|---|---|---|
| FreeIPA | Réplicas FreeIPA | Desplegar al menos 2 réplicas en zonas distintas. FreeIPA soporta replicación multi-master nativa. |
| Active Directory | DC adicionales | Añadir al menos un DC secundario en el mismo dominio. Los clientes pueden contactar cualquier DC. |
| DNS | DNS redundante | Cada réplica de FreeIPA actúa como servidor DNS. Configurar múltiples entradas nameserver en los clientes. |
| SSSD en clientes | Caché offline | SSSD almacena en caché las credenciales y puede autenticar usuarios previamente logados aunque el servidor esté inaccesible. Configurar cache_credentials = true en sssd.conf. |
Para este proyecto de laboratorio, la arquitectura de un único servidor es suficiente. Las consideraciones de HA son relevantes para el escalado a producción en entornos empresariales.
Esta sección recoge las líneas de evolución técnica identificadas a partir de la arquitectura actual. Cada mejora está clasificada por prioridad y dificultad de implementación.
Problema actual: Los grupos de AD (Domain Admins, LinuxAdmins, etc.) son visibles a través de id usuario@nanobytes2.local, pero FreeIPA no puede referenciarlos directamente en reglas HBAC ni Sudoers. Actualmente hay que recrear los grupos manualmente en FreeIPA.
Solución: FreeIPA soporta grupos externos que actúan como envoltorios de grupos de AD, permitiendo usarlos en cualquier política de FreeIPA sin duplicar la gestión.
# 1. Crear el grupo externo que referencia al grupo de AD
ipa group-add --external LinuxAdmins_ext \
--desc="Wrapper del grupo Domain Admins de AD"
# 2. Mapear el grupo de AD al grupo externo
ipa group-add-member LinuxAdmins_ext \
--external "NANOBYTES2\\Domain Admins"
# 3. Crear un grupo POSIX que contenga al grupo externo
ipa group-add LinuxAdmins \
--desc="Administradores Linux (origen: AD Domain Admins)"
ipa group-add-member LinuxAdmins --groups=LinuxAdmins_ext
# 4. Usar el grupo POSIX en reglas HBAC y Sudoers directamente
ipa hbacrule-add-user ssh_admins --groups=LinuxAdmins
ipa sudorule-add-user sudo_admins --groups=LinuxAdmins
Resultado: Un cambio de pertenencia al grupo Domain Admins en AD se refleja automáticamente en los permisos HBAC y Sudoers de los servidores Linux, sin intervención manual en FreeIPA.
Prioridad: Alta. Dificultad: Baja.
Problema actual: Los UIDs y GIDs de los usuarios de AD son generados dinámicamente por FreeIPA a partir del SID de AD. Esto significa que el mismo usuario puede obtener UIDs distintos en diferentes servidores si el rango de IDs no está correctamente sincronizado, rompiendo los permisos de archivos.
Solución: Usar ID Views de FreeIPA para asignar atributos POSIX fijos (UID, GID, shell, home) a usuarios de AD de forma centralizada.
# 1. Crear un ID View para los usuarios de AD
ipa idview-add AD_users_view \
--desc="Atributos POSIX para usuarios de nanobytes2.local"
# 2. Sobrescribir los atributos de un usuario específico
ipa idoverrideuser-add AD_users_view \
"Administrador@nanobytes2.local" \
--uid=10500 \
--gidnumber=10500 \
--homedir=/home/ad/administrador \
--shell=/bin/bash
# 3. Aplicar el ID View a los hosts que lo necesitan
ipa idview-apply AD_users_view --hosts=servidor-linux.nanobytes.local
Resultado: El usuario Administrador@nanobytes2.local tendrá siempre el mismo UID/GID en todos los servidores donde se aplique el view, independientemente del SID asignado en AD.
Prioridad: Media. Dificultad: Baja.
Problema actual: La arquitectura actual mantiene dos planos de identidad separados: usuarios nativos en FreeIPA y usuarios de AD accedidos vía trust. Esto requiere gestión paralela.
Solución a largo plazo: Configurar el trust con el tipo ipa-ad-trust-posix para que AD controle directamente los atributos POSIX de los usuarios (UID, GID, grupos), usando los atributos almacenados en el esquema POSIX de AD (Active Directory Unix Services / IDMU).
# Establecer el trust con rango POSIX controlado por AD
ipa trust-add --type=ad nanobytes2.local \
--admin Administrador \
--password \
--range-type=ipa-ad-trust-posix
Requisito previo: El esquema POSIX de AD debe estar activo y los objetos de usuario deben tener atributos uidNumber, gidNumber y unixHomeDirectory definidos.
Resultado: Los administradores de AD definen los atributos Linux de los usuarios directamente en Active Directory, eliminando la necesidad de ID Views manuales y centralizando toda la gestión de identidades en un único directorio.
Prioridad: Baja (requiere cambios en AD). Dificultad: Media.
Problema actual: La autenticación se basa únicamente en contraseña. Si una contraseña de AD se compromete, el acceso SSH a los servidores Linux queda expuesto.
Solución: FreeIPA soporta TOTP (Time-based One-Time Password) nativo. Los usuarios pueden añadir un segundo factor que se valida en el KDC de FreeIPA antes de emitir el ticket Kerberos.
# Habilitar OTP para un usuario de FreeIPA
ipa user-mod admin --user-auth-type=otp
# El usuario registra su token con ipa otptoken-add
# o vía la Web UI de FreeIPA
Para usuarios de AD, la MFA se gestiona en el lado de AD (Azure MFA, Duo, etc.) y el trust respeta la política del dominio de origen.
Prioridad: Alta en entornos con datos sensibles. Dificultad: Media.
Problema actual: El acceso SSH usa autenticación por contraseña delegada a Kerberos, lo que implica introducir la contraseña en cada sesión si no hay un ticket activo.
Solución: Configurar SSH para aceptar autenticación GSSAPI. Con un TGT Kerberos activo en el cliente, el login SSH es completamente transparente (sin contraseña).
# En el servidor Linux (/etc/ssh/sshd_config)
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
# En el cliente Linux (~/.ssh/config)
Host *.nanobytes.local
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
Con esta configuración, kinit usuario@NANOBYTES2.LOCAL seguido de ssh servidor.nanobytes.local abre la sesión sin volver a pedir contraseña, usando el ticket Kerberos existente.
Prioridad: Media. Dificultad: Baja.
Problema actual: Los logs de autenticación están dispersos: /var/log/secure en cada servidor, el log de SSSD, el Visor de Eventos de AD y el log de auditoría de FreeIPA.
Solución: Centralizar todos los eventos de autenticación en un SIEM (Splunk, Elastic SIEM, Graylog, etc.) mediante un agente de recolección de logs.
| Fuente | Datos relevantes | Método de envío |
|---|---|---|
| Servidores Linux (SSSD) | Logins, fallos, cambios de sesión | rsyslog / Filebeat |
| FreeIPA (389-ds) | Cambios LDAP, creación de cuentas | Log de 389-ds vía syslog |
| FreeIPA (krb5kdc) | Emisión de tickets, fallos Kerberos | journald forwarding |
| Windows Server (AD) | Logon events (ID 4624, 4625, 4768) | WEC + syslog forwarder |
Regla de correlación de ejemplo: Si un usuario de AD obtiene un ticket Kerberos (evento 4768 en AD) pero no aparece en los logs de SSSD del servidor de destino en los siguientes 5 minutos, puede indicar un intento de movimiento lateral.
Prioridad: Alta en entornos regulados. Dificultad: Alta (requiere infraestructura SIEM).
| Mejora | Prioridad | Dificultad | Impacto |
|---|---|---|---|
| Sincronización de grupos de AD (External Groups) | Alta | Baja | Elimina duplicación de grupos |
| MFA / OTP | Alta | Media | Reduce riesgo de credenciales comprometidas |
| SSH con GSSAPI (sin contraseña) | Media | Baja | Mejora experiencia y seguridad |
| ID Views para UIDs fijos | Media | Baja | Consistencia de permisos en filesystem |
| AD como fuente POSIX única | Baja | Media | Centralización total en AD |
| Auditoría centralizada (SIEM) | Alta* | Alta | Visibilidad y cumplimiento normativo |
*Alta si el entorno está sujeto a regulaciones (ISO 27001, ENS, PCI-DSS, etc.).
| Término | Definición |
|---|---|
| Active Directory (AD) | Servicio de directorio de Microsoft que centraliza la autenticación y autorización en entornos Windows mediante LDAP y Kerberos. |
| FreeIPA | Solución de gestión de identidades open-source para Linux, que integra LDAP (389-ds), Kerberos (MIT KDC), DNS (Bind9) y una CA interna. Equivalente de código abierto a Active Directory para el mundo Linux/Unix. |
| Cross-Realm Trust | Relación de confianza entre dos dominios Kerberos distintos que permite que los usuarios de un dominio se autentiquen en recursos del otro sin duplicar cuentas. |
| Kerberos | Protocolo de autenticación de red basado en tickets criptográficos. Evita el envío de contraseñas en texto claro. Usa un Centro de Distribución de Claves (KDC) como árbitro de confianza. |
| KDC (Key Distribution Center) | Servidor central de Kerberos que emite tickets de autenticación (TGT) y tickets de servicio (TGS). |
| TGT (Ticket Granting Ticket) | Credencial inicial que obtiene el usuario al autenticarse con su contraseña. Se usa para solicitar tickets de servicio sin volver a introducir la contraseña. |
| LDAP | Protocolo estándar para acceder y gestionar directorios de información (usuarios, grupos, equipos). Tanto AD como FreeIPA lo implementan. |
| SSSD | Demonio de servicios de seguridad del sistema. Actúa como intermediario en clientes Linux entre el sistema operativo y los proveedores de identidad remotos (LDAP, Kerberos). Incluye caché offline. |
| PAM | Marco de autenticación enchufable de Linux. Define cómo el sistema operativo autentica usuarios. pam_sss delega la autenticación a SSSD. |
| HBAC | Host-Based Access Control. Mecanismo de FreeIPA para definir qué usuarios pueden acceder a qué servicios en qué servidores. |
| SID | Security Identifier. Identificador único de un objeto de seguridad en AD (usuario, grupo, equipo). FreeIPA mapea los SIDs de AD a UIDs/GIDs POSIX para que Linux los entienda. |
| DNSSEC | Extensión de seguridad de DNS que añade firmas criptográficas a los registros DNS para prevenir ataques de envenenamiento. AD no firma sus registros por defecto, lo que requiere deshabilitar la validación DNSSEC en FreeIPA para las zonas de reenvío hacia AD. |
| mDNS | Multicast DNS. Protocolo de resolución de nombres sin servidor central, usado en redes locales. El sufijo .local activa mDNS en sistemas modernos, lo que puede interferir con la resolución DNS corporativa. |
| oddjobd | Demonio de tareas auxiliares que ejecuta operaciones privilegiadas (como crear directorios home) en nombre de PAM, sin necesitar que PAM tenga privilegios de root. |
| ADSI Edit | Herramienta de bajo nivel de Windows para acceder y modificar directamente la base de datos LDAP de Active Directory, incluyendo objetos no visibles en las interfaces gráficas estándar. |