| Campo | Valor |
|---|---|
| Autor | Mario Sánchez |
| Rol | Administrador de Sistemas / DevOps |
| Versión | 1.1 |
| Fecha | 2026-05-26 |
| Tipo de documento | Runbook de Operaciones — Entorno de Lab / Despliegue |
| Documento relacionado | Arquitecuta — Documento de Arquitectura Corporativa |
Alcance: Procedimientos paso a paso para desplegar y operar la federación de identidades AD + FreeIPA desde cero, incluyendo diagnóstico, rollback y monitorización. Cubre el entorno de laboratorio (Vagrant/VirtualBox + UTM sobre macOS).
| Componente | IP | Dominio | Hipervisor |
|---|---|---|---|
| Servidor AD (Windows Server) | 172.16.50.239 |
nanobytes2.local · NetBIOS NANOBYTES2 |
UTM |
| Servidor FreeIPA (Linux) | 192.168.56.10 (Host-Only) · 172.16.50.x (Bridged) |
nanobytes.local · NetBIOS NANOBYTES |
VirtualBox + Vagrant |
| Cliente Linux | 192.168.56.11 (Host-Only) |
Unido a FreeIPA | VirtualBox + Vagrant |
| Cliente Windows 11 | Segmento puente común | Unido a AD | UTM |
Hipervisores: Oracle VirtualBox (con Vagrant) sobre macOS + UTM (Apple Hypervisor Framework).
server-IPA: servidor FreeIPA (192.168.56.10)client: cliente Linux unido a IPA (192.168.56.11)Los siguientes puertos deben estar abiertos en el firewall de cada sistema. En entornos con firewalld o iptables activo, verificar con firewall-cmd --list-all (Linux) o el Panel de Firewall de Windows.
| Puerto | Protocolo | Origen → Destino | Servicio | Obligatorio para |
|---|---|---|---|---|
| 88 | TCP/UDP | FreeIPA ↔ AD | Kerberos KDC | Cross-realm trust, autenticación SSH |
| 389 | TCP | FreeIPA ↔ AD | LDAP | Búsqueda de usuarios y grupos |
| 636 | TCP | FreeIPA ↔ AD | LDAPS | LDAP sobre TLS (recomendado en producción) |
| 464 | TCP/UDP | FreeIPA ↔ AD | Kerberos kpasswd | Cambio de contraseñas Kerberos |
| 53 | TCP/UDP | FreeIPA ↔ AD | DNS | Resolución de nombres bidireccional |
| 135 | TCP | FreeIPA → AD | RPC endpoint mapper | Establecimiento del trust (ipa trust-add) |
| 445 | TCP | FreeIPA → AD | SMB/CIFS (Samba) | Establecimiento del trust (ipa trust-add) |
| 22 | TCP | Clientes → servidor Linux | SSH | Acceso interactivo federado |
| 80/443 | TCP | Administradores → FreeIPA | IPA Web UI | Gestión web de FreeIPA |
En el entorno de lab con Vagrant, el firewall de las VMs Linux está deshabilitado por defecto. En producción, añadir las reglas con
firewall-cmd --permanent --add-service=<servicio>.
Verificación rápida de puertos desde FreeIPA:
# Comprobar Kerberos en AD
nc -zv 172.16.50.239 88
# Comprobar LDAP en AD
nc -zv 172.16.50.239 389
# Comprobar SMB/CIFS (necesario para ipa trust-add)
nc -zv 172.16.50.239 445
Esta fase es específica de entornos Vagrant/VirtualBox con
private_network. Si todas las VMs están ya en modo Bridged, puedes saltarla e ir directamente a la Fase 1.
Un entorno Vagrant típico con private_network tiene dos adaptadores:
┌─────────────────────────────────────────────────────────┐
│ VM (guest) │
│ │
│ enp0s8 · 10.0.2.15/24 enp0s9 · 192.168.56.10 │
└──────────┬──────────────────────────────┬───────────────┘
│ Adaptador NAT │ Adaptador Host-Only
▼ ▼
┌─────────────┐ ┌──────────────────┐
│ Motor NAT │ │ Red privada │
│ VirtualBox │ │ 192.168.56.0/24 │
│ 10.0.2.2 │ │ (host ↔ VMs) │
└──────┬──────┘ └──────────────────┘
│
▼
Internet
Regla nemotécnica: NAT = internet · Host-Only = red interna
Síntoma:
ping 8.8.8.8
# PING 8.8.8.8 … connect: Network is unreachable
Tabla problemática:
default via 192.168.56.1 dev enp0s9 proto static metric 102 ← MAL
10.0.2.0/24 dev enp0s8 proto kernel scope link src 10.0.2.15 metric 101
192.168.56.0/24 dev enp0s9 proto kernel scope link src 192.168.56.10 metric 102
Vagrant, al provisionar private_network, a veces registra un gateway para enp0s9 en NetworkManager. NM lo convierte en ruta default estática, enviando todo el tráfico de internet por la interfaz Host-Only, que no tiene salida al exterior.
# Paso 1 — ¿Hay ruta default?
ip route | grep default
# Paso 2 — ¿Apunta a la interfaz correcta?
# CORRECTO: default via 10.0.2.2 dev enp0s8
# INCORRECTO: default via 192.168.56.1 dev enp0s9
# Paso 3 — ¿El gateway NAT es alcanzable?
ping -c 3 10.0.2.2
# Paso 4 — ¿Hay internet tras corregir?
ping -c 3 8.8.8.8
# 1. Eliminar la ruta default incorrecta
sudo ip route del default via 192.168.56.1 dev enp0s9
# 2. Añadir la ruta default correcta
sudo ip route add default via 10.0.2.2 dev enp0s8
# 3. Verificar
ip route
ping -c 3 8.8.8.8
ip routees volátil. Los cambios se pierden al reiniciar. Persistir con NetworkManager.
# Evitar que host-only se declare como default gateway
sudo nmcli connection modify enp0s9 ipv4.never-default yes
# Asegurar que NAT tiene el gateway correcto
sudo nmcli connection modify enp0s8 ipv4.gateway "10.0.2.2"
sudo nmcli connection modify enp0s8 ipv4.never-default no
# Aplicar sin reiniciar
sudo nmcli connection up enp0s9
sudo nmcli connection up enp0s8
# El parámetro run: "always" ejecuta el script en cada vagrant up
server.vm.provision "shell", path: "provision/fix_routing.sh", run: "always"
server.vm.provision "shell", path: "provision/install_server.sh"
fix_routing.shdebe ir antes queinstall_server.shpara que el provisionador tenga internet al instalar paquetes.
Problema: Las VMs fragmentadas entre NAT y Host-Only generan aislamiento unidireccional. Kerberos descarta tickets al detectar SNAT (enmascaramiento de IP), ya que el ticket contiene la IP de origen y el NAT la modifica en tránsito.
Solución: Migrar todas las VMs a modo Adaptador Puente (Bridged), de modo que el router físico asigne IPs del mismo rango (172.16.50.x) a todas las máquinas.
En VirtualBox:
Configuración de VM → Red → Adaptador 1 → Conectado a: Adaptador Puente
En UTM:
Configuración de VM → Red → Modo: Bridged
# Desde FreeIPA hacia AD
ping -c 4 172.16.50.239
# Desde AD hacia FreeIPA (PowerShell)
Test-NetConnection -ComputerName <IP_FREEIPA> -Port 389
Resultado esperado: Respuesta ICMP en ambas direcciones sin pérdida de paquetes, y el puerto 389 (LDAP) accesible.
La autenticación Kerberos exige red plana en Capa 2. El SNAT invalida los tickets al modificar la IP de origen del paquete Kerberos.
Problema: El cliente resuelve DNS vía IPv6 Link-Local, ignorando el Controlador de Dominio. El sufijo .local activa mDNS en lugar de DNS corporativo, haciendo que ping funcione (responde por multicast) pero nslookup falle (no encuentra los registros SRV de Kerberos).
[Cliente] → (mDNS Multicast) → [Windows Server] → Responde PING ← engaño
[Cliente] → (DNS vía IPv6 errónea) → [Router] → TIMEOUT ← fallo real
Deshabilitar IPv6 en el adaptador de red:
Panel de Control → Centro de redes → Propiedades del adaptador
→ Desmarcar "Protocolo de Internet versión 6 (TCP/IPv6)"
Configurar DNS estático apuntando al DC:
DNS preferido: 172.16.50.239
DNS alternativo: (dejar vacío)
Purgar caché DNS y NetBIOS:
ipconfig /flushdns
nbtstat -RR
Unir al dominio usando FQDN explícito:
Sistema → Unirse a dominio → nanobytes2.local
Usuario: nanobytes2.local\Administrador
En Windows Server en español, la cuenta integrada es
Administrador, noAdministrator. El comando de unión al dominio fallará con "nombre de usuario o contraseña incorrectos" si se usa el nombre en inglés.
nslookup nanobytes2.local 172.16.50.239
Debe devolver la IP 172.16.50.239 consultando directamente al DC, sin timeouts.
Problema: Para establecer la relación de confianza, ambos servidores deben resolver mutuamente sus registros SRV. FreeIPA devuelve SERVFAIL al reenviar consultas hacia AD: el motor Bind9 tiene DNSSEC activo y descarta las respuestas de AD al carecer de firmas criptográficas, interpretándolas como un ataque de envenenamiento DNS.
En Windows Server, abrir DNS Manager:
DNS Manager → <servidor> → Reenviadores condicionales → Nuevo reenviador
Dominio DNS: NANOBYTES.LOCAL
IP del servidor DNS: <IP_FREEIPA>
ipa dnsforwardzone-add nanobytes2.local \
--forwarder=172.16.50.239 \
--forward-policy=only
FreeIPA tiene una arquitectura modular con sentencias include. La directiva dnssec-validation reside en el archivo específico de la aplicación, no en /etc/named.conf. Editarlo en el lugar incorrecto duplica la variable y provoca la caída del demonio named.
Auditar primero la configuración:
sudo named-checkconf
# Si aparece: 'dnssec-validation' redefined near 'dnssec-validation'
# → el parámetro está duplicado; eliminar el duplicado manual de /etc/named.conf
Editar el archivo correcto:
sudo nano /etc/named/ipa-options-ext.conf
Localizar la línea y modificarla:
dnssec-validation no;
Reiniciar y purgar caché:
sudo systemctl restart named
sudo rndc flush
Verificación:
# Desde FreeIPA — debe devolver NOERROR
dig nanobytes2.local
# Desde FreeIPA, consultar directamente al DC (baseline)
dig @172.16.50.239 nanobytes2.local
# Desde AD — debe resolver el dominio de FreeIPA (PowerShell)
Resolve-DnsName ipa.nanobytes.local
Nunca reiniciar un servicio crítico como
namedsin ejecutarnamed-checkconfantes. Los entornos empresariales modernos rara vez son monolíticos; la configuración modular conincludees la norma.
Problema: ipa trust-add falla con:
ipa: ERROR: CIFS server communication error: code "3221225525",
message "The object name already exists."
El error NT_STATUS_OBJECT_NAME_COLLISION indica que un intento previo fallido dejó un objeto trustedDomain incompleto en la base de datos LDAP de AD. La interfaz gráfica domain.msc no lo muestra, pero bloquea el espacio de nombres.
Causa del intento fallido previo: ejecutar ipa trust-add con sudo destruye el contexto del ticket Kerberos. El ticket TGT reside en la caché del usuario de sesión (vagrant); al invocar sudo, el comando se ejecuta como root local, que carece de credenciales de red para AD. El subsistema CIFS intenta autenticarse sin TGT, corrompe la negociación inicial y crea el objeto a medias.
Abrir ADSI Edit: Win + R → adsiedit.msc
Conectar al contexto predeterminado:
Acción → Conectar a...
Punto de conexión: Seleccionar contexto de nomenclatura conocido → DC predeterminado
Navegar hasta:
CN=System,DC=nanobytes2,DC=local
Localizar el objeto CN=NANOBYTES.LOCAL de tipo trustedDomain → clic derecho → Eliminar.
Get-ADObject -Filter {ObjectClass -eq "trustedDomain"} `
-SearchBase "CN=System,DC=nanobytes2,DC=local"
El comando no debe devolver ningún objeto relacionado con NANOBYTES.LOCAL.
Las herramientas gráficas ocultan ciertos objetos del sistema para proteger al usuario no técnico. Un administrador de sistemas audita la base de datos en bruto cuando las GUIs no muestran el problema.
Requisito crítico: Los siguientes comandos deben ejecutarse como usuario admin con ticket Kerberos activo, sin sudo. El usuario root local no tiene contexto de red en Active Directory y la negociación fallará.
kinit admin
# Introducir contraseña del admin de FreeIPA
# Verificar que el ticket está activo
klist
ipa trust-add --type=ad nanobytes2.local \
--admin Administrador \
--password
Salida esperada:
Added Active Directory trust for realm "nanobytes2.local"
Realm name: nanobytes2.local
Domain NetBIOS name: NANOBYTES2
Domain Security Identifier: S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX
Trust direction: Trusting forest
Trust type: Active Directory domain
Trust status: Established and verified
SSSD intercepta las llamadas del sistema y traduce las identidades de Windows a estructuras POSIX nativas de Linux:
id Administrador@nanobytes2.local
Salida esperada:
uid=1916000500(administrador@nanobytes2.local) \
gid=1916000500(administrador@nanobytes2.local) \
groups=1916000500(administrador@nanobytes2.local),\
1916000512(domain admins@nanobytes2.local),\
1916000513(domain users@nanobytes2.local)
SSSD contactó al LDAP de Windows Server vía Kerberos, leyó los objetos de seguridad y asignó dinámicamente uid/gid POSIX con los grupos corporativos. La federación está operativa.
ipa trust-show nanobytes2.local
Escenario: Iniciar sesión SSH en el cliente Linux (unido a FreeIPA) usando un usuario del dominio AD (admin02@nanobytes2.local), sin que el cliente esté unido directamente a AD.
El flujo de autenticación atraviesa cuatro capas, cada una independiente:
ssh admin02@NANOBYTES2.LOCAL@<IP_CLIENTE>
│
└─► sshd → PAM
├─► pam_sss → SSSD → FreeIPA LDAP (búsqueda de usuario: uid, gid, home)
│
└─► pam_sss → SSSD → KDC AD :88 (autenticación: ticket Kerberos)
│
└─► PAM monta sesión
└─► pam_oddjob_mkhomedir → oddjobd
└─► crea /home/nanobytes2.local/usuario
└─► Shell
La búsqueda LDAP (FreeIPA) y la autenticación Kerberos (AD) son operaciones separadas. Por eso
id usuario@nanobytes2.localpuede funcionar aunque el login SSH falle: el problema está en la capa de autenticación, no en la de directorio.
Esta fase acumula tres problemas independientes que se manifiestan en orden: primero la sesión se cierra sola, luego cuelga indefinidamente, luego falla la autenticación Kerberos.
Síntoma: La sesión SSH se cierra de forma abrupta tras autenticación correcta. PAM aborta la sesión porque /home/nanobytes2.local/<usuario> no existe en disco.
Diagnóstico:
# En el cliente Linux
sudo tail -f /var/log/secure
# Conexión con depuración máxima
ssh -vvv admin02@nanobytes2.local@<IP_CLIENTE>
Solución:
sudo authselect enable-feature with-mkhomedir
sudo systemctl restart sssd
sudo systemctl enable --now oddjobd
Verificación:
ssh admin02@nanobytes2.local@<IP_CLIENTE>
ls -la /home/nanobytes2.local/
with-mkhomedirdelega la creación del home al demoniooddjobdmediantepam_oddjob_mkhomedir. Sioddjobdestá parado, el login cuelga indefinidamente esperando respuesta. Verificar siempre consystemctl status oddjobd.
Síntoma: SSH o kinit cuelgan, o devuelven kinit: Cannot find KDC. El comando id usuario@nanobytes2.local funciona, pero la autenticación Kerberos falla.
Causa raíz: El cliente Linux usa systemd-resolved con su stub resolver (127.0.0.53). Este stub trata el dominio .local como mDNS (Multicast DNS) en lugar de DNS corporativo, rechazando las queries SRV que Kerberos necesita para localizar el KDC de AD.
El trazado de Kerberos lo confirma:
KRB5_TRACE=/dev/stderr kinit admin02@NANOBYTES2.LOCAL 2>&1 | head -20
# Sending DNS SRV query for _kerberos._tcp.NANOBYTES2.LOCAL.
# No SRV records found
# kinit: Cannot find KDC for realm "NANOBYTES2.LOCAL"
Diagnóstico:
# ¿Qué DNS usa el cliente?
cat /etc/resolv.conf
# ¿Resuelve los SRV de Kerberos?
dig SRV _kerberos._tcp.nanobytes2.local
Solución — Crear /etc/resolv.conf estático:
# Desvincular el symlink de systemd-resolved
sudo unlink /etc/resolv.conf
# Apuntar directamente al DNS de FreeIPA
sudo tee /etc/resolv.conf << 'EOF'
nameserver 192.168.56.10
search nanobytes.local nanobytes2.local
EOF
Verificación:
# Debe resolver los SRV del KDC de AD
dig SRV _kerberos._tcp.nanobytes2.local
# Debe autenticar correctamente (realm en MAYÚSCULAS)
kinit admin02@NANOBYTES2.LOCAL
klist
El realm Kerberos debe escribirse siempre en MAYÚSCULAS (
NANOBYTES2.LOCAL). Kerberos es sensible a mayúsculas en el nombre del realm. El comandoidfunciona en minúsculas porque SSSD normaliza internamente para la búsqueda LDAP, pero la autenticación Kerberos requiere el realm exacto.
Síntoma: Después de corregir el DNS, sssctl domain-status nanobytes2.local devuelve Offline.
Causa raíz: SSSD arrancó cuando el DNS estaba mal configurado. Al no poder contactar AD durante el inicio, marcó el backend como offline. Este estado persiste aunque el DNS se corrija después.
Diagnóstico:
sudo sssctl domain-status nanobytes2.local
# Online status: Offline
Solución:
sudo sss_cache -E
sudo systemctl restart sssd
sleep 3
sudo sssctl domain-status nanobytes2.local
# Online status: Online
Verificación final del flujo completo:
# 1. SSSD resuelve el usuario
id admin02@nanobytes2.local
# 2. Kerberos autentica
kinit admin02@NANOBYTES2.LOCAL && klist
# 3. SSH funciona
ssh admin02@nanobytes2.local@<IP_CLIENTE>
# 4. Directorio home creado automáticamente
ls -la /home/nanobytes2.local/
Restringir qué usuarios de AD pueden hacer SSH a qué servidores Linux:
# Deshabilitar la regla permisiva por defecto
ipa hbacrule-disable allow_all
# Crear grupo de usuarios AD con acceso SSH
ipa group-add --desc="Linux admins from AD" LinuxAdmins_AD
# Crear regla HBAC
ipa hbacrule-add ssh_ad_admins --desc="SSH access for AD Linux admins"
ipa hbacrule-add-service ssh_ad_admins --hbacsvcs=sshd
ipa hbacrule-add-user ssh_ad_admins --groups=LinuxAdmins_AD
ipa hbacrule-add-host ssh_ad_admins --hostgroups=<hostgroup_objetivo>
# Simular acceso antes de activar (evita lockouts)
ipa hbactest \
--user=admin02@nanobytes2.local \
--host=<fqdn_servidor> \
--service=sshd
Mapear grupos de AD a políticas sudo gestionadas desde FreeIPA:
# Crear regla sudo para el grupo AD
ipa sudorule-add ad_admins_sudo --desc="Sudo for AD Linux admins"
ipa sudorule-add-user ad_admins_sudo --groups=LinuxAdmins_AD
ipa sudorule-add-runasuser ad_admins_sudo --users=root
ipa sudorule-add-command ad_admins_sudo --sudocmds=ALL
# Verificar
ipa sudorule-show ad_admins_sudo
Usar
ipa hbactestantes de deshabilitarallow_all. Un error en las reglas HBAC puede dejar fuera del sistema a todos los usuarios, incluyendo al administrador.
Ejecutar periódicamente para verificar que la federación sigue operativa tras reinicios, actualizaciones de paquetes o cambios de red.
# Estado del trust (desde el servidor FreeIPA)
ipa trust-show nanobytes2.local
# Estado de los dominios en SSSD
sudo sssctl domain-status nanobytes.local
sudo sssctl domain-status nanobytes2.local
# Estado de los servicios críticos de FreeIPA
sudo ipactl status
# Kerberos KDC
sudo systemctl status krb5kdc
# Servidor LDAP de FreeIPA (389-ds)
sudo systemctl status dirsrv@NANOBYTES-LOCAL
# DNS (named)
sudo systemctl status named
# SSSD
sudo systemctl status sssd
# oddjobd (creación dinámica de homes)
sudo systemctl status oddjobd
# 1. Resolución DNS bidireccional
dig nanobytes2.local
dig ipa.nanobytes.local @172.16.50.239
# 2. Autenticación Kerberos
kinit admin && klist && kdestroy
# 3. Resolución de usuario AD desde Linux
id Administrador@nanobytes2.local
# 4. Validez del ticket de confianza
ipa trust-show nanobytes2.local | grep "Trust status"
| Señal | Acción inmediata |
|---|---|
ipa trust-show → Trust status: Established but not verified |
Renovar el trust: ipa trust-fetch-domains nanobytes2.local |
sssctl domain-status → Offline |
sss_cache -E && systemctl restart sssd |
id usuario@nanobytes2.local → no such user |
Verificar DNS + estado de SSSD |
systemctl status named → failed |
named-checkconf antes de reiniciar |
kinit → Cannot find KDC |
Verificar DNS y registros SRV: dig SRV _kerberos._tcp.NANOBYTES2.LOCAL |
Si el trust provoca problemas o es necesario reestablecerlo desde cero:
En FreeIPA:
# Eliminar el trust de FreeIPA
ipa trust-del nanobytes2.local
# Verificar que no queda ningún trust
ipa trust-find
En Windows Server (PowerShell):
# Eliminar la relación de confianza desde AD
netdom trust nanobytes2.local /domain:nanobytes.local /remove /force
Si persiste el objeto zombi, limpiar con ADSI Edit (ver Fase 4).
# Eliminar la zona de reenvío
ipa dnsforwardzone-del nanobytes2.local
# Revertir DNSSEC (si se necesita restaurar la validación)
sudo nano /etc/named/ipa-options-ext.conf
# Cambiar: dnssec-validation yes;
sudo named-checkconf && sudo systemctl restart named
# Restaurar resolv.conf gestionado por systemd-resolved
sudo rm /etc/resolv.conf
sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
# Desactivar mkhomedir si causa problemas
sudo authselect disable-feature with-mkhomedir
sudo systemctl restart sssd
# Desactivar oddjobd
sudo systemctl disable --now oddjobd
# Eliminar la ruta añadida manualmente
sudo ip route del default via 10.0.2.2 dev enp0s8
# Revertir configuración de NetworkManager
sudo nmcli connection modify enp0s9 ipv4.never-default no
sudo nmcli connection up enp0s9
| Capa | Síntoma | Causa Raíz | Resolución |
|---|---|---|---|
| L3 — Routing VirtualBox | Sin internet en la VM tras vagrant up |
private_network sobreescribe la ruta default al adaptador Host-Only |
ip route del default via 192.168.56.1 dev enp0s9 + ip route add default via 10.0.2.2 dev enp0s8 + persistir con nmcli |
| L3 — Red entre hipervisores | VMs sin comunicación bidireccional; Kerberos rechaza tickets | NAT/SNAT modifica la IP de origen e invalida los tickets Kerberos | Migrar todas las VMs a modo Bridged en VirtualBox y UTM |
| L7 — DNS Windows 11 | nslookup falla; ping funciona pero join al dominio falla con "contraseña incorrecta" |
IPv6 Link-Local + mDNS intercepta .local antes que el DNS corporativo |
Deshabilitar IPv6, fijar DNS estático a 172.16.50.239, ipconfig /flushdns |
| L7 — DNS FreeIPA | SERVFAIL al resolver el dominio AD desde FreeIPA |
DNSSEC activo en Bind9 rechaza respuestas de AD sin firmar | dnssec-validation no; en /etc/named/ipa-options-ext.conf (no en named.conf) |
| Named | Servicio DNS cae al reiniciar tras editar configuración | Directiva dnssec-validation duplicada por ignorar arquitectura modular con include |
named-checkconf + eliminar el duplicado en /etc/named.conf |
| LDAP — AD | ipa trust-add → NT_STATUS_OBJECT_NAME_COLLISION |
Objeto trustedDomain zombi en CN=System invisible en la GUI |
Eliminar manualmente con ADSI Edit navegando a CN=NANOBYTES.LOCAL en CN=System |
| Kerberos | ipa trust-add falla con error de credenciales CIFS |
sudo ejecuta el comando como root local, destruyendo el TGT Kerberos del usuario de red |
Ejecutar kinit admin + ipa trust-add sin sudo |
| PAM — sesión | SSH autentica pero cierra sesión inmediatamente | Directorio /home/nanobytes2.local/<usuario> no existe en disco |
authselect enable-feature with-mkhomedir + systemctl enable --now oddjobd |
| PAM — oddjobd | Login cuelga indefinidamente tras activar mkhomedir | oddjobd parado; pam_oddjob_mkhomedir espera respuesta sin timeout |
systemctl enable --now oddjobd |
| DNS — cliente Linux | kinit: Cannot find KDC / SSH cuelga en autenticación |
systemd-resolved trata .local como mDNS; el stub 127.0.0.53 rechaza los SRV de Kerberos |
unlink /etc/resolv.conf + crear estático apuntando a 192.168.56.10 |
| SSSD — cliente Linux | sssctl domain-status → Offline aunque la red funcione |
SSSD arrancó con DNS roto y marcó el backend AD como offline en caché | sss_cache -E + systemctl restart sssd |
| Acción | Comando |
|---|---|
| Ver tabla de rutas | ip route |
| Ver IPs de interfaces | ip -4 addr show |
| Eliminar ruta default | sudo ip route del default via <gw> dev <iface> |
| Añadir ruta default | sudo ip route add default via <gw> dev <iface> |
| Marcar iface como no-default (NM) | sudo nmcli connection modify <iface> ipv4.never-default yes |
| Aplicar cambios NM | sudo nmcli connection up <iface> |
| Verificar configuración NM | nmcli connection show <iface> \| grep -i gateway |
| Elemento | IP |
|---|---|
| Gateway NAT (siempre) | 10.0.2.2 |
| IP del guest en NAT (DHCP) | 10.0.2.15 |
| IP del host en Host-Only | 192.168.56.1 |
| Servidor FreeIPA | 192.168.56.10 |
| Cliente Linux | 192.168.56.11 |
# Estado del trust
ipa trust-show nanobytes2.local
# Estado de SSSD por dominio
sudo sssctl domain-status nanobytes2.local
# Resolver usuario de AD desde Linux
id Administrador@nanobytes2.local
# Verificar ticket Kerberos activo
klist
# Trazar problema de KDC
KRB5_TRACE=/dev/stderr kinit admin02@NANOBYTES2.LOCAL 2>&1 | head -30
# Verificar objetos trustedDomain en AD (PowerShell)
Get-ADObject -Filter {ObjectClass -eq "trustedDomain"} -SearchBase "CN=System,DC=nanobytes2,DC=local"
# Verificar registros SRV de Kerberos
dig SRV _kerberos._tcp.nanobytes2.local
dig SRV _ldap._tcp.nanobytes2.local
¿Sin internet en la VM?
│
├─ ip route | grep default → vacío
│ └─ Añadir: sudo ip route add default via 10.0.2.2 dev enp0s8
│
└─ ip route | grep default → apunta a enp0s9 (192.168.56.x)
├─ Borrar: sudo ip route del default via 192.168.56.1 dev enp0s9
├─ Añadir: sudo ip route add default via 10.0.2.2 dev enp0s8
└─ Persistir: sudo nmcli connection modify enp0s9 ipv4.never-default yes
sudo nmcli connection up enp0s9
sudo nmcli connection up enp0s8