Domain Admin en el FortiGate: el atajo que convierte tu perímetro en un compromiso de dominio

Hay una cuenta de servicio corriendo ahora mismo en su red que, según la documentación —si es que existe—, «solo hace single sign-on». Nadie recuerda quién la creó, en qué grupo quedó, ni qué ocurriría si alguien la extrajera del equipo donde vive. Y el equipo donde vive es el firewall Fortigate que da la cara a Internet. Y lo más preocupante: esa cuenta resulta ser un Domain Admin en el Directorio Activo.

Ese detalle debería quitarle el sueño a cualquier CISO, por una razón simple de aritmética de riesgo: el firewall perimetral es, por definición, uno de los activos más expuestos de la organización —recibe tráfico de Internet, publica portales VPN. Poner una credencial de Domain Admin dentro del activo más expuesto significa que un solo fallo de perímetro deja de ser «comprometieron el firewall» y pasa a ser «comprometieron el dominio completo». No hay movimiento lateral que ganar: el atacante ya está en la cima.

El riesgo real: por qué existe el atajo

La documentación de Fortinet es honesta al respecto. En su artículo «Technical Tip: Restricting a Fortinet Single Sign On Agent Service (FSSO) service account» (community.fortinet.com, artículo 99528 / KB FD36039), Fortinet afirma que el método más simple es ejecutar el agente FSSO con una cuenta de Domain Admin, porque así —sin importar el modo o la función que se active— el servicio siempre tendrá permisos suficientes. Es el camino que funciona en cualquier escenario.

Pero el mismo documento agrega, textualmente, que esa configuración no es deseable en entornos que aplican medidas de seguridad rigurosas, y dedica el resto del artículo a explicar cómo restringirla. Traducción: Fortinet ofrece el atajo por comodidad, documenta que es prescindible, y deja la decisión en manos del administrador. En la práctica, esa decisión rara vez se toma de forma consciente, y el firewall termina convertido en un activo Tier 0 sin que nadie lo haya aprobado.

Para desarmar el atajo hay que entender que estamos hablando de dos funciones distintas que la gente confunde bajo el paraguas de «integración con AD».

Las dos funciones que se confunden

1. Autenticación de VPN vía LDAP / LDAPS. Cuando un usuario se conecta a la VPN, el FortiGate hace un bind contra el Directorio Activo para validar credenciales y resolver a qué grupos pertenece. Esto es lectura pura. El firewall no escribe nada en el directorio; no existe «sincronización» en ningún sentido. La membresía de grupos se resuelve por consulta en cada inicio de sesión. Para esto basta una cuenta miembro de Domain Users, que por defecto ya tiene permiso de lectura sobre la membresía de grupos —así lo confirma la propia documentación de Fortinet, que señala que el permiso «Read Group membership» está permitido por defecto para cualquier miembro de Domain Users.

2. FSSO para políticas de navegación por grupo. Aquí el FortiGate (o el Collector Agent) necesita detectar los inicios de sesión de los usuarios para aplicarles políticas web según su grupo de AD. El mecanismo es leer los registros de seguridad de los controladores de dominio. Según Fortinet (mismo artículo 99528), el privilegio mínimo para leer esos logs es pertenecer al grupo Event Log Readers; y para resolver a qué grupos pertenece cada usuario detectado, se apoya en LDAP con permisos de Domain Users. Si la cuenta no está en Event Log Readers, el log del Collector devuelve el error 1314 y simplemente no ve logins.

Ninguna de las dos funciones necesita Domain Admin.

Receta de mínimo privilegio

La configuración correcta usa dos cuentas de servicio dedicadas y separadas, nunca la misma cuenta reutilizada para todo, y nunca una cuenta administrativa:

• svc-vpn-ldap — miembro de Domain Users. Solo hace el bind LDAP/LDAPS para autenticación VPN.
• svc-fsso — miembro de Event Log Readers (más Domain Users). Solo lee los logs de seguridad para FSSO.

Domain Admin se usa únicamente de forma temporal durante la instalación o actualización del Collector Agent, y se degrada a nivel Domain Users apenas termina. Fortinet documenta que tras la instalación los permisos pueden reducirse, dejando a la cuenta solo control sobre ciertas claves de registro y carpetas locales del propio agente.

Aquí viene el gotcha que casi nadie discute, y que verifiqué contra la documentación oficial: no todos los modos de «polling» son iguales en cuanto a privilegios.

• El modo DC Agent instala un DLL (dcagent.dll) enganchado a lsass.exe en cada controlador de dominio, y exige reiniciar el DC en cada instalación o upgrade. Meter código de un tercero dentro de LSASS de todos tus DCs es exactamente lo que uno no quiere en un activo Tier 0. Evítalo.
• El modo NetAPI Polling parece liviano, pero Fortinet advierte en el artículo 99528 que, para funcionar correctamente con Windows Server 2019 y superiores, la cuenta de servicio debe ser miembro de Server Operators. Y ese es el punto crítico: Server Operators es un grupo Tier 0. Sus miembros pueden manipular servicios en el controlador de dominio, y modificar el binario de un servicio equivale a ejecución de código como SYSTEM en el DC —un camino de escalada a Domain Admin bien documentado por Microsoft en su Appendix B: Privileged Accounts and Groups in Active Directory. En otras palabras: si eliges NetAPI polling en un DC moderno, tu «cuenta de mínimo privilegio» es en realidad una escalada a dominio esperando ser explotada.

La recomendación, entonces, es usar polling agentless desde el FortiGate (el firewall consulta directamente el log de seguridad del DC por SMB, puerto TCP 445, sin instalar nada) o el Collector Agent en modo WinSec/Event Log, ambos con la cuenta en Event Log Readers —no en Server Operators—. El modo agentless tiene limitaciones que conviene conocer (según Fortinet solo procesa eventos Kerberos 4768/4769, no soporta NTLM, no hace workstation checks y puede fallar con grupos anidados), pero a cambio evita tanto el DLL en los DCs como el requisito de Server Operators.

Un matiz adicional para no repetir un error común: el acceso DCOM/WMI y de administrador local no lo exige la lectura básica de logs, sino el workstation check de FSSO y el modo de polling por WMI. Es una razón más para preferir WinSec/agentless y desactivar el workstation check si no se necesita.

Y sobre el endurecimiento de las cuentas, cuatro controles que Fortinet y Microsoft respaldan:

• Deny Logon Locally sobre ambas cuentas de servicio: no son para uso interactivo.
• Incluir la cuenta FSSO en la Ignore User List del Collector.
• LDAPS obligatorio, nunca LDAP en texto claro —máxime cuando Microsoft empuja el channel binding and signing de LDAP (aviso ADV190023).
• Group Filters para que solo se sincronicen los grupos realmente usados en políticas, reduciendo la superficie de datos que viaja al firewall.

El matiz: necesario, pero no suficiente

Aquí es donde la mayoría de los artículos se detienen y celebran. Nosotros no.

Quitar Domain Admin corta el movimiento lateral y la escalada directa. Pero no elimina el valor de reconocimiento de la cuenta. Aunque svc-vpn-ldap sea de solo lectura, si un atacante compromete el firewall y extrae esa credencial, obtiene un bind autenticado al Directorio Activo. Con eso puede enumerar, sin tocar nada, prácticamente todo el dominio: usuarios, grupos, ACLs, delegaciones, cuentas de servicio con SPN (materia prima para Kerberoasting) y cuentas privilegiadas. Es exactamente el insumo que herramientas como BloodHound/SharpHound necesitan para dibujar el grafo de rutas de ataque —y SharpHound se conforma con un simple usuario de dominio.

Dicho de otro modo: reducir el privilegio te protege de que el firewall sea la llave del dominio, pero no de que sea el mapa que le dice al atacante dónde está la llave. La corrección de privilegios es necesaria; no es el final del trabajo.

Arquitectura recomendada para «incidentes donde hackean el firewall»

Cuando el modelo de amenaza contempla el compromiso del propio FortiGate —y en un activo perimetral debería contemplarlo siempre—, la respuesta correcta es que el firewall no almacene credenciales de AD:

• FortiAuthenticator (FAC) como intermediario. El FAC actúa como colector de FSSO y como proxy RADIUS/LDAP hacia el Directorio Activo. El FortiGate confía en el FAC, no en AD; las credenciales del directorio viven en el FAC, un activo mucho menos expuesto y endurecible por separado.
• Sin FAC: apuntar el bind LDAP a un RODC. Un controlador de dominio de solo lectura mantiene una réplica filtrada y, mediante la Password Replication Policy, evita almacenar los secretos de cuentas sensibles. Seamos honestos con el alcance: el RODC reduce el robo de credenciales, pero el grafo de objetos sigue siendo enumerable desde él —otra vez, necesario pero no suficiente—.
• Segmentar el acceso firewall → DC por puerto (445 para polling, 636 para LDAPS) y por IP de origen, de modo que el firewall solo hable con los DCs que necesita, y solo por lo que necesita.
• Alertar. Configurar el SIEM para dos señales de alto valor: (1) que cualquiera de las cuentas de servicio aparezca en un logon interactivo (Evento 4624, tipos 2 o 10) —jamás debería—, y (2) consultas LDAP anómalas o masivas originadas desde la IP del firewall, síntoma de una enumeración tipo BloodHound.

Tabla de referencia rápida

Cuenta	Grupo / permiso requerido	Función
svc-vpn-ldap	Domain Users (lectura)	Bind LDAP/LDAPS para autenticación VPN y resolución de grupos
svc-fsso	Event Log Readers (+ Domain Users)	Lectura de logs de seguridad del DC para FSSO (WinSec / agentless)
(instalación)	Domain Admin temporal	Solo durante instalación/upgrade del Collector Agent; degradar a Domain Users al terminar
⚠️ NetAPI Polling en WS2019+	Server Operators (Tier 0 — evitar)	Fortinet lo exige para este modo; usar WinSec/agentless en su lugar

Cierre accionable

Tres cosas para hacer esta semana, sin esperar al próximo pentest:

1. Averigüe en qué grupo está su cuenta de FSSO y su cuenta de bind LDAP. Un net user <cuenta> /domain toma treinta segundos. Si ve «Domain Admins» —o «Server Operators»— tiene un hallazgo crítico abierto.
2. Separe las funciones y degrade los privilegios según la tabla de arriba. Domain Admin, solo temporal y solo para instalar.
3. Asuma que el firewall puede caer y diseñe para que, cuando caiga, no se lleve el dominio consigo: FortiAuthenticator o RODC, segmentación y alertas.

En GreenFence Security evaluamos exactamente este tipo de configuraciones en nuestra Evaluación de Configuración de Firewall Fortigate contra el CIS Benchmark, donde estas desviaciones de mínimo privilegio son de los primeros hallazgos que salen a la luz. Si quiere saber qué privilegios tienen hoy las cuentas de servicio conectadas a su FortiGate, hablemos.

---

Fuentes técnicas: Fortinet, «Technical Tip: Restricting a Fortinet Single Sign On Agent Service (FSSO) service account» (community.fortinet.com, artículo 99528 / KB FD36039, consultado en 2026); Fortinet, «Comparison between DC-Agent mode and polling mode» y «How to troubleshoot FSSO agentless polling mode issues» (community.fortinet.com); Microsoft, «Appendix B: Privileged Accounts and Groups in Active Directory» y aviso ADV190023 sobre LDAP channel binding and signing. Verifique siempre los nombres de grupo y permisos contra la versión de FortiOS y de Windows Server en producción antes de aplicar cambios.