VPN FortiGate: cómo saber por qué falla la autenticación
¿Un usuario no puede conectarse a la VPN del FortiGate? Aprende a usar el debug de fnbamd y los códigos de error LDAP para saber si es contraseña, bloqueo o grupo.
"No me puedo conectar a la VPN." Es una de las incidencias más comunes para cualquier administrador de redes. Cuando la VPN del FortiGate autentica contra Active Directory, la causa puede ser muy variada: una contraseña mal escrita, una cuenta bloqueada, una contraseña caducada, un usuario que no pertenece al grupo correcto o incluso un fallo en la conexión del FortiGate con el controlador de dominio.
El problema es que el log del FortiGate suele decir solo que la autenticación falló, sin explicar el motivo. En esta guía verás cómo obtener la causa exacta con el debug de fnbamd y los códigos de error de LDAP, cómo probar credenciales sin molestar al usuario y cómo distinguir un problema de contraseña de uno de configuración.
Primero: ¿falla la autenticación o antes?
No todos los fallos de VPN son de usuario y contraseña. En una VPN IPsec, el FortiGate y FortiClient primero negocian el túnel (fase 1) y solo después piden las credenciales del usuario. Si falla la negociación, por ejemplo por una clave precompartida distinta o por parámetros de cifrado que no coinciden, el usuario ni siquiera llega a autenticarse.
Por eso conviene distinguir:
- Falla la negociación: afecta normalmente a todos los usuarios o a un equipo concreto con una configuración de FortiClient distinta. Se ve en el debug de
ike. - Falla la autenticación: afecta a un usuario concreto, mientras los demás se conectan sin problema. Se ve en el debug de
fnbamd, que es el proceso del FortiGate encargado de autenticar contra LDAP, RADIUS y otros servidores.
Si solo falla un usuario, casi siempre es lo segundo.
1. Revisar los logs de la GUI
El primer paso rápido es mirar los eventos:
Log & Report → System Events → VPN Events, y también User Events.
Filtra por el nombre del usuario y busca los intentos fallidos. En una VPN IPsec con autenticación de usuario verás mensajes de autenticación fallida; en SSL VPN, eventos con la acción ssl-login-fail.
Estos logs confirman que el usuario llegó a intentarlo y que la autenticación falló, pero no suelen decir por qué. Para eso necesitas el debug.
2. Ver la causa real con el debug de fnbamd
Conéctate por SSH o por la consola de la GUI y ejecuta:
diagnose debug reset
diagnose debug application fnbamd -1
diagnose debug application ike -1
diagnose debug console timestamp enable
diagnose debug enable
Pide al usuario que intente conectarse. Cuando tengas el intento capturado, desactiva el debug:
diagnose debug disable
diagnose debug reset
No dejes el debug activado más tiempo del necesario: genera mucha salida y consume recursos.
Si el FortiGate autentica contra Active Directory por LDAP, cuando la contraseña o la cuenta tienen algún problema verás una línea parecida a esta:
Error 49(80090308: LdapErr: DSID-0C09044E, comment: AcceptSecurityContext error, data 52e, v4563)
El Error 49 indica que Active Directory rechazó las credenciales. Lo importante es el código que aparece después de data: es Active Directory diciéndote exactamente por qué.
3. Interpretar los códigos de error de Active Directory
Código data |
Significado | Qué hacer |
|---|---|---|
| 52e | Contraseña incorrecta | El usuario está escribiendo mal la contraseña o FortiClient tiene guardada una antigua. |
| 525 | El usuario no existe | Revisa cómo escribe el usuario (con o sin dominio) y el atributo de búsqueda configurado en el servidor LDAP. |
| 775 | Cuenta bloqueada | Demasiados intentos fallidos. Desbloquéala y averigua el origen de los intentos. |
| 532 | Contraseña caducada | El usuario debe cambiarla desde un equipo del dominio o por el método de autoservicio que tengan. |
| 773 | Debe cambiar la contraseña en el próximo inicio de sesión | Típico de cuentas nuevas o contraseñas restablecidas por soporte. |
| 533 | Cuenta deshabilitada | Comprueba si es una baja o un error. |
| 701 | Cuenta caducada | La cuenta tiene fecha de expiración y ya pasó. Habitual en contratos temporales. |
| 530 | Inicio de sesión no permitido en este horario | Revisa las restricciones de horario de la cuenta. |
| 531 | Inicio de sesión no permitido desde este equipo | Revisa las restricciones de equipos de la cuenta. |
Un detalle útil: el código 775 (cuenta bloqueada) suele venir precedido de varios 52e. Si ves que la cuenta se bloquea una y otra vez aunque el usuario asegura que no ha intentado conectarse, busca un dispositivo con la contraseña antigua guardada: un móvil, otro equipo o el propio FortiClient reconectando solo.
4. Probar las credenciales desde el FortiGate
Para comprobar las credenciales de un usuario sin que tenga que intentarlo él mismo, el FortiGate permite lanzar una prueba contra el servidor LDAP:
diagnose test authserver ldap <nombre-servidor-ldap> <usuario> <contraseña>
- Si responde que la autenticación fue correcta (
succeeded), la contraseña está bien y el problema está en otra parte: grupo, política o configuración del cliente. - Si responde
failed, combínalo con el debug defnbamdpara ver el código exacto.
Úsalo con criterio: la contraseña se escribe en claro en la consola. Lo ideal es hacer la prueba con el usuario presente o con una cuenta de prueba.
Si autenticas contra RADIUS (por ejemplo, un servidor NPS de Windows), la prueba es parecida, pero hay que indicar el método de autenticación:
diagnose test authserver radius <nombre-servidor-radius> <metodo> <usuario> <contraseña>
El método puede ser pap, chap, mschap o mschap2, según lo que acepte tu servidor. En NPS, el motivo exacto del rechazo aparece en el Visor de eventos de Windows (evento 6273, con su código de motivo).
5. Si la contraseña es correcta: revisa el grupo
Un caso muy común: el debug de fnbamd muestra que la autenticación contra LDAP fue correcta, pero el usuario sigue sin poder conectarse. En ese caso el problema no es la contraseña, sino la pertenencia a grupos.
El FortiGate no solo comprueba que el usuario exista y tenga la contraseña correcta: también comprueba que pertenezca al grupo de usuarios configurado en la VPN o en la política de firewall. Revisa:
- Que el usuario sea miembro del grupo de Active Directory que usa el FortiGate.
- Que el grupo de usuarios del FortiGate apunte a ese grupo de AD con el nombre completo correcto (distinguished name).
- Que la política de firewall o la configuración de la VPN usen ese grupo.
En el debug de fnbamd verás los grupos que el FortiGate lee del usuario y si coinciden o no con el configurado.
6. Si fallan todos los usuarios: revisa la conexión con LDAP
Si de repente nadie puede conectarse, el problema suele estar en la conexión entre el FortiGate y el controlador de dominio, no en los usuarios. Las causas más habituales:
- La cuenta de servicio que usa el FortiGate para consultar LDAP (la cuenta de bind) tiene la contraseña caducada, se ha bloqueado o se ha deshabilitado. Es un fallo clásico: nadie se acuerda de esa cuenta hasta que deja de funcionar. Configúrala para que la contraseña no caduque y documenta su existencia.
- El controlador de dominio no es accesible desde el FortiGate.
- Un certificado caducado, si usas LDAPS.
En User & Authentication → LDAP Servers, el botón para probar la conectividad del servidor te confirma rápidamente si el FortiGate llega al controlador de dominio y si la cuenta de bind funciona.
7. Confirmarlo desde Active Directory
Desde un equipo con el módulo de Active Directory para PowerShell, puedes comprobar el estado de la cuenta:
Get-ADUser usuario -Properties Enabled, LockedOut, badPwdCount, PasswordExpired, AccountExpirationDate |
Select-Object SamAccountName, Enabled, LockedOut, badPwdCount, PasswordExpired, AccountExpirationDateY si está bloqueada:
Unlock-ADAccount -Identity usuarioPara listar todas las cuentas bloqueadas del dominio:
Search-ADAccount -LockedOut | Select-Object Name, SamAccountName, LastLogonDateResumen del procedimiento
- ¿Falla solo un usuario o todos? Si fallan todos, revisa la conexión con LDAP y la cuenta de bind.
- Revisa los logs de la GUI para confirmar el intento fallido.
- Activa el debug de
fnbamdy localiza el códigodatadel error 49. - Si la contraseña es correcta, revisa la pertenencia a grupos.
- Confirma el estado de la cuenta en Active Directory y corrige.
Preguntas frecuentes
¿Qué significa el error LDAP 49 con data 52e? Que Active Directory rechazó el inicio de sesión porque la contraseña es incorrecta para un usuario que sí existe.
¿Cómo sé si un usuario de la VPN tiene la cuenta bloqueada?
En el debug de fnbamd aparecerá el código data 775, o puedes comprobarlo en Active Directory con Get-ADUser usuario -Properties LockedOut.
¿Puedo probar la contraseña de un usuario desde el FortiGate?
Sí, con diagnose test authserver ldap <servidor> <usuario> <contraseña>. Ten en cuenta que la contraseña queda visible en la consola.
¿Por qué la autenticación es correcta pero el usuario no conecta? Normalmente porque no pertenece al grupo de usuarios configurado en la VPN o en la política de firewall.
Conclusión
Diagnosticar una VPN que no conecta deja de ser una adivinanza cuando se sabe dónde mirar. Los logs confirman que el intento falló, pero es el debug de fnbamd y el código data de Active Directory lo que dice exactamente por qué: contraseña incorrecta, cuenta bloqueada, contraseña caducada o cuenta deshabilitada. Con esa información, una incidencia que podía llevar media hora de pruebas se resuelve en unos minutos.
