¿Tu servidor Windows Server 2016 con IIS FTP acepta inicios de sesión por horas y, sin tocar nada, todos los usuarios empiezan a fallar con “User cannot log in, home directory inaccessible”? Aquí tienes un método probado para diagnosticar y corregir el problema, evitando reinicios completos.
Resumen del escenario y del error
Entorno típico: IIS FTP en Windows Server 2016 Datacenter, autenticación contra Active Directory, acceso restringido a un grupo de AD y aislamiento de usuarios basado en atributos de AD. El servicio funciona un tiempo y, de forma intermitente, todos los usuarios dejan de autenticarse con el error 530: “User cannot log in, home directory inaccessible”. Reiniciar IIS/FTP no ayuda; solo reiniciar el servidor recupera temporalmente el acceso.
Por qué sucede: patrones de ruptura más comunes
En la mayoría de incidentes con este patrón “funciona → 24 h → deja de funcionar”, hay un elemento que expira, rota o pierde su canal seguro. Los sospechosos habituales son:
Cuenta de servicio o credenciales (AD y/o UNC)
- El aislamiento por Active Directory utiliza una cuenta de lectura para consultar atributos como
msIIS-FTPDirymsIIS-FTPRoot. Si la contraseña caduca, la cuenta se bloquea o pierde el derecho de lectura, el FTP no puede resolver la ruta home. - Si las home están en UNC/DFS (por ejemplo,
\\filesrv\home\usuario) y el sitio usa Pass-through o Conectar como… mal configurado, las sesiones SMB expiran, la delegación Kerberos falla (doble salto) o el FTP pierde acceso intermitente al recurso.
Replicación o selección de Controlador de Dominio (DC)
El servidor puede alternar a un DC con replicación incompleta o con permisos inconsistentes. Resultado: la consulta de atributos msIIS-FTPDir/msIIS-FTPRoot devuelve vacío o rutas incorrectas, bloqueando el login.
Permisos NTFS/Share o rutas no disponibles
Herencias cambiadas, destinos DFS desincronizados o fuera de línea, o permisos Share más restrictivos que NTFS provocan denegaciones que desembocan en “home directory inaccessible”.
Hora/Kerberos y canal seguro Netlogon
Un desfase horario rompe Kerberos. Un canal seguro (Secure Channel) deteriorado entre el servidor y el dominio causa fallos de autenticación o lectura de AD que, de forma engañosa, “se curan” tras reiniciar la máquina.
Cómo confirmarlo rápido: señales en logs
| Indicio | Probable causa | Qué verificar |
|---|---|---|
| FTP 530 con home directory inaccessible | Atributos AD no legibles o ruta UNC sin acceso | Lectura de msIIS-FTPDir/msIIS-FTPRoot y permisos NTFS/Share |
| Eventos 4768/4771 en Seguridad (Kerberos) | Desfase horario, SPN o delegación | NTP correcto, SPN CIFS del file server, KCD si hay “doble salto” |
| Eventos de Netlogon o Secure Channel | Canal seguro roto | nltest /sc_verify, reinicio de Netlogon |
| Errores SMB en el servidor de archivos | Share o NTFS insuficiente | Open Files/SMB Server, auditoría, denegaciones |
Solución recomendada paso a paso (evita reiniciar el servidor)
Estabiliza las cuentas de servicio
- Crea una cuenta dedicada de solo lectura en AD para el modo “Active Directory user isolation”. Concédele lectura a los atributos
msIIS-FTPDirymsIIS-FTPRoot. Marca Password never expires. - Si la raíz/home está en UNC, en el sitio FTP (o en la raíz/VD correspondiente) usa “Conectar como…” con una cuenta de servicio que tenga permisos NTFS/Share mínimos en el recurso. Evita Pass-through si no tienes configurada la delegación Kerberos (KCD).
# Ejemplo: configurar aislamiento AD con appcmd
%windir%\system32\inetsrv\appcmd.exe set config "FTPSitio" ^
/section:system.ftpServer/userIsolation ^
/mode:"ActiveDirectory" /adUserName:"DOM\svcftpad" /adPassword:""
Establecer credenciales para acceder a \\filesrv\home desde la raíz del sitio
IIS Manager → Sitio FTP → Configuración básica → Conectar como… (DOM\svcftpdata)
Si usas UNC/DFS para los directorios home
- Opción preferida: “Conectar como…” con la cuenta de servicio mencionada. Esto elimina el doble salto y estabiliza SMB.
- Si debes usar Pass-through: configura Delegación Kerberos (KCD) en la cuenta del servidor FTP (o en la identidad que use) hacia el servicio CIFS del servidor de archivos. Asegúrate de que los SPN del file server (
cifs/filesrv,cifs/filesrv.dominio.local) están correctos.
# Comprobar SPN del servidor de archivos
setspn -L FILESRV
(Si usas identidad de dominio para el servicio FTP) validar SPN de la identidad frontal
setspn -L DOM\svcftpfront
Delegación: en AD Users & Computers → Cuenta del FTP server/servicio →
"Trust this computer/account for delegation to specified services only" →
Añadir CIFS del FILESRV
Valida atributos y permisos en Active Directory
- Verifica que todos los usuarios que deben iniciar sesión tienen poblados
msIIS-FTPDir(ymsIIS-FTPRootsi aplica) apuntando a una ruta válida (local o UNC). - Confirma que la cuenta de consulta puede leer esos atributos en todos los DCs.
# Revisar atributos de un usuario (desde un equipo con RSAT)
Get-ADUser usuario1 -Properties msIIS-FTPDir,msIIS-FTPRoot |
Select-Object SamAccountName, msIIS-FTPDir, msIIS-FTPRoot
Comprobar que el valor es una ruta válida (p.ej. \\filesrv\home\usuario1)
Comprueba salud de AD, replicación y hora
# Resumen de replicación
repadmin /replsummary
Ver el DC preferido/actual y su disponibilidad
nltest /dsgetdc\:DOMINIO.LOCAL
dcdiag /test\:Advertising
Validar canal seguro (Secure Channel)
nltest /sc\_verify\:DOMINIO.LOCAL
Test-ComputerSecureChannel -Verbose
NTP
w32tm /query /status
w32tm /query /source
w32tm /resync Registra, traza y aísla la causa
- Activa el log Microsoft-Windows-IIS-FTP Service/Operational (Visor de eventos → Registros de aplicaciones y servicios → Microsoft → Windows → IIS-FTP Service → Operational).
- Habilita Failed Request Tracing (FREB) en el sitio y filtra por estado 530. Verás el detalle del fallo y, a menudo, el motivo home directory inaccessible con código Win32.
- En el servidor de archivos, revisa Open Files/SMB y auditoría de denegaciones.
- En Seguridad, observa 4625 (NTLM fallido), 4768/4771 (Kerberos TGT/PA fallidos), 4769 (TGS).
Prueba A/B para acotar origen
Temporalmente cambia el aislamiento a “User name directory” con ruta local (p.ej., D:\FTP\%UserName%).
- Si el fallo desaparece, el problema está en AD/UNC/Delegación.
- Si persiste, investiga permisos locales, antivirus o la propia configuración del sitio FTP.
Acciones de mitigación sin reinicio completo
Si el incidente se reproduce, prueba estas acciones controladas. Suelen recuperar el servicio cuando la causa es Netlogon/SMB/Kerberos:
# 1) Renovar credenciales y sesiones de red del proceso
klist purge
nltest /sc_verify:DOMINIO.LOCAL
2) Reiniciar Netlogon (reestablece el canal seguro)
net stop netlogon && net start netlogon
3) Reiniciar el cliente SMB del servidor FTP
net stop lanmanworkstation && net start lanmanworkstation
net use \* /delete /y
4) Reiniciar únicamente el servicio FTP
Restart-Service -Name ftpsvc -Force Importante: estas acciones son menos disruptivas que un reinicio completo y, bien coordinadas, apenas cortan sesiones activas durante unos segundos.
Tabla de mapeo de errores frecuentes
| FTP/Estado | Win32 (logs FTP) | Interpretación práctica | Acción sugerida |
|---|---|---|---|
| 530 Not logged in | 5 (Access is denied) | Permiso NTFS/Share insuficiente | Revisar ACL NTFS/Share y “Conectar como…” |
| 530 Not logged in | 53 (Network path not found) | Ruta UNC inválida o DNS/DFS | Validar existencia/DFS y resolución de nombres |
| 530 Not logged in | 64 (Network name deleted) | Sesión SMB caída, recurso intermitente | Reiniciar Workstation, revisar SMB/DFS |
| 530 Not logged in | 1326 (Logon failure) | Credenciales erróneas/expiradas | Actualizar cuenta de servicio/AD query |
| 530 Not logged in | 86 (Wrong password) | Contraseña de “Conectar como…” cambiada | Actualizar secreto almacenado en IIS |
Checklist de corrección definitiva
- La cuenta de consulta a AD existe, no caduca, no está bloqueada y puede leer
msIIS-FTPDir/msIIS-FTPRoot. - Si la raíz/home es UNC, el sitio usa “Conectar como…” con cuenta de servicio (o KCD correctamente configurado para Pass-through).
- Permisos NTFS/Share coherentes en todas las rutas (y destinos DFS con la misma ACL).
- Los atributos de AD están poblados y replicados en todos los DCs.
- Hora NTP correcta en FTP server y DCs; canal seguro Netlogon verificado.
- FTP Operational log y FREB activados con filtro 530, confirmando causa raíz.
Guía práctica de permisos mínimos
| Objeto | Permisos mínimos | Notas |
|---|---|---|
| Carpeta raíz del sitio (local) | Lectura para el proceso FTP | Evita escribir si no es necesario |
| Compartido \\filesrv\home | Share: “Change” o “Read” según necesidad | ACL de Share no más restrictiva que NTFS |
| Carpeta de cada usuario | NTFS: Usuario (Modify/Read), Servicio (Read) | Habilita “Traverse folder/execute file” |
Verificaciones de línea de comandos útiles
# Probar acceso a la ruta UNC con la cuenta de servicio (desde un CMD elevado)
runas /user:DOM\svcftpdata cmd
dir \\filesrv\home\usuario1
Limpiar y reestablecer sesión SMB (solo en el FTP server)
net use \* /delete /y
dir \filesrv\home & rem Fuerza reconexión
Confirmar que el sitio FTP está usando el modo de aislamiento AD esperado
%windir%\system32\inetsrv\appcmd.exe list config "FTPSitio" /section\:system.ftpServer/userIsolation Buenas prácticas para producción
- Estándar de cuentas de servicio: evita cuentas personales; usa cuentas dedicadas con contraseña controlada por TI. Documenta quién, dónde y para qué.
- Rotación segura de secretos: cuando cambies la contraseña de Conectar como… o de la cuenta AD de consulta, actualiza inmediatamente IIS para evitar tokens caducados.
- Topología DFS simple: intenta que las homes tengan un único target por site o alinea permisos en todos los targets para evitar sorpresas al conmutar.
- Supervisión proactiva: alerta en eventos 530 del FTP, 4768/4771 de Seguridad, y en indisponibilidad de \\filesrv.
- FTPS obligatorio: habilita TLS para proteger credenciales y datos (recomendación de seguridad).
Preguntas frecuentes
¿Por qué tras reiniciar el servidor “se arregla” por unas horas?
El reinicio renueva credenciales, sesiones SMB y el canal seguro. Si la causa raíz es expiración de tickets, bloqueo de cuenta o canal Netlogon roto, el problema reaparece cuando vuelven a caducar/romperse esos elementos. Por eso conviene reiniciar servicios específicos (Netlogon/Workstation) o corregir la raíz (credenciales/permiso/tiempo).
¿Puedo usar Pass-through sin KCD?
Funcionar, puede, pero en cuanto el servicio necesite acceder a \\UNC con las credenciales del usuario, sin delegación Kerberos caerás en el problema del doble salto. Lo más estable es “Conectar como…” con una cuenta de servicio dedicada; si debes Pass-through, configura KCD.
¿Qué valores debería tener msIIS-FTPDir?
Una ruta válida local o UNC accesible por el FTP y por el usuario, por ejemplo \\filesrv\home\%UserName%. Evita rutas con letras de unidad asignadas por usuario (no existen en el contexto del servicio), y verifica que la cuenta de consulta puede leer el atributo en todos los DCs.
¿Por qué los usuarios ven “home directory inaccessible” si su contraseña es correcta?
Porque la autenticación puede superarse pero fallar la resolución/entrada a la home: permisos NTFS/Share, ruta DFS no disponible, atributo AD vacío o ilegible, o el FTP no puede hacer double-hop hasta \\UNC.
Plan de prueba y validación final
- Confirma que la cuenta de consulta de AD está operativa y con Password never expires.
- En el FTP, configura “Conectar como…” para el acceso UNC y valida con
dir \\filesrv\home. - Activa FREB filtrado 530, reproduce el fallo con un usuario de prueba.
- Si falla, revisa el código Win32 y cruza con la tabla de mapeo.
- Si apunta a autenticación, verifica hora/NTP,
nltest /sc_verify,klist, y SPN/Delegación. - Si apunta a permisos, ajusta Share/NTFS y herencias en todos los targets DFS.
Conclusión
El error intermitente “User cannot log in, home directory inaccessible” en IIS FTP suele tener causas repetibles: credenciales caducadas o bloqueadas, delegación Kerberos ausente/defectuosa para \\UNC, atributos de AD inconsistentes, o problemas de hora y canal seguro. Con una cuenta de servicio estable, acceso a UNC mediante “Conectar como…” (o KCD bien definido), permisos coherentes y verificación de AD/SMB/NTP, se elimina la necesidad de reiniciar la máquina y se obtiene un servicio FTP predecible y mantenible.
Lista de verificación rápida
- Cuenta de consulta a AD: existente, sin caducidad ni bloqueos, con lectura de
msIIS-FTPDir/msIIS-FTPRoot.- Si hay \\UNC: usar “Conectar como…” con cuenta de servicio o, alternativamente, KCD configurado para Pass-through.
- Permisos NTFS/Share correctos (y destinos DFS coherentes).
- Atributos AD presentes y replicados en todos los DCs.
- Hora NTP alineada; canal Netlogon verificado.
- FREB/Operational log activos para confirmar causa.
Nota de seguridad: habilita FTPS (TLS) para proteger credenciales y datos en tránsito.