Conectar Active Directory con Sophos Firewall

Active Directory sigue siendo en muchos entornos Sophos Firewall la fuente central para usuarios, grupos y autenticación. La firewall utiliza la integración AD, por ejemplo, para reglas basadas en usuarios, Remote Access VPN, Captive Portal, User Portal, reporting o escenarios de Single Sign-On.

Este artículo explica cómo añadir un servidor Active Directory en Sophos Firewall, qué campos son realmente importantes y cómo validar después la conexión. En diseños nuevos de Remote Access también conviene decidir si encaja mejor AD clásico, RADIUS o Microsoft Entra ID SSO para Sophos Connect y VPN Portal.

Si Active Directory es el destino de un entorno eDirectory existente, conviene planificar primero la migración controlada de eDirectory, incluida la validación de grupos, el cutover por servicio y la vía de reversión.

El siguiente vídeo de Sophos Techvids muestra el proceso básico como complemento visual. Se creó con SFOS v21; la lógica sigue siendo útil, aunque algunas pantallas pueden verse ligeramente distintas en SFOS 22.

El flujo práctico consta de cuatro partes. Una prueba de conexión correcta es solo el principio; VPN, portal, reglas de usuario y SSO deben validarse por separado.

1. Añadir servidor: Introducir correctamente domain controller, NetBIOS domain, search base y cuenta de servicio.
2. Proteger la conexión: Planificar conscientemente LDAPS, validación de certificados y resolución DNS interna.
3. Importar grupos: Importar solo los grupos AD necesarios y entender la Main Group.
4. Probar el uso: Comprobar login, MFA, VPN, User Portal, Captive Portal, SSO y Log Viewer.

Contexto

Sophos Firewall puede usar varias fuentes de autenticación. Active Directory tiene sentido cuando usuarios y grupos ya se gestionan localmente en un dominio Windows y la firewall debe utilizar estas identidades directamente.

Casos de uso típicos:

• sincronización de usuarios y grupos desde Active Directory local
• reglas de firewall con referencia a usuarios o grupos
• Remote Access VPN con usuarios AD
• User Portal o Captive Portal con cuentas de dominio
• reporting por usuario en lugar de solo por IP
• Active Directory SSO con NTLM o Kerberos

Pero integrar AD no resuelve automáticamente todas las preguntas de autenticación. Hay que distinguir si la firewall solo consulta usuarios por LDAP/LDAPS, si se importan grupos, si se usa SSO o si Remote Access requiere además MFA. Para los fundamentos de MFA, véase Activar MFA para Sophos Firewall WebAdmin, VPN Portal y Remote Access.

Decisiones importantes antes de configurar

Antes de añadir el servidor, conviene aclarar estos puntos:

• Conexión: Usar LDAPS con SSL/TLS en el puerto 636 siempre que sea posible.
• Cuenta de servicio: Usar una cuenta AD dedicada con permisos de lectura en lugar de Domain Admin.
• Search base: Buscar solo las OUs necesarias, no todo el dominio sin criterio.
• Atributo de visualización: Elegir conscientemente sAMAccountName, userPrincipalName o displayName.
• Grupos: Importar solo los grupos necesarios para firewall, VPN o portales.
• MFA: Proteger Remote Access y portales adicionalmente con MFA.
• Orden de servidores: Definir de forma consciente el orden de consulta si hay varios servidores AD.
• Operación: Revisar regularmente auth logs, importación de grupos, certificados y expiración de contraseña.

⚠️ La conexión entre firewall y servidor de autenticación debería estar cifrada. LDAP sin cifrar en el puerto 389 puede funcionar en laboratorios, pero no es una buena solución permanente para producción.

Para la integración AD también se soportan versiones antiguas de Windows Server, pero en entornos actuales son especialmente relevantes Windows Server 2016, 2019, 2022 y 2025. Desde SFOS 21.5 MR1, Active Directory SSO con Windows Server 2025 es posible para NTLM y Kerberos. SFOS 22 contiene componentes Samba actualizados para autenticación Kerberos y NTLM y elimina métodos de cifrado antiguos. Por eso, tras upgrades de firewall o de domain controllers, se deben probar AD SSO, importación de grupos y Remote Access de forma específica.

Importante: Sophos Firewall no soporta actualmente la imposición estricta de LDAP Channel Binding y LDAP Signing. Si los domain controllers aplican políticas LDAP muy estrictas, la integración AD debería probarse en una ventana de mantenimiento antes de un cambio productivo.

Añadir servidor Active Directory

La configuración se realiza en el WebAdmin de Sophos Firewall:

Authentication > Servers

Allí se crea un nuevo servidor de autenticación con Add y se selecciona Active Directory como Server Type.

Campos de la configuración Active Directory

La numeración del screenshot está elegida intencionadamente: los campos importantes se explican de arriba abajo. Según la versión de SFOS, el orden puede variar ligeramente. En versiones recientes también aparece Validate server certificate si se quiere activar la validación del certificado para LDAPS.

1. Server type: Para un dominio Windows clásico se usa Active Directory. Otros tipos como RADIUS, LDAP o Microsoft Entra ID son integraciones distintas y no deben mezclarse sin planificación.
2. Server name: Nombre interno mostrado en la firewall. No afecta a DNS ni a AD, pero debe ser claro, por ejemplo AD-ZH-DC01 o AD-HQ-LDAPS. Con varios domain controllers ayuda después en Log Viewer y troubleshooting.
3. Server IP/domain: IP o nombre DNS del domain controller. Un nombre DNS es más limpio si certificado, resolución interna y failover encajan. Una IP es más fácil de depurar, pero ata la firewall a un domain controller concreto.
4. Port: Puerto de la conexión LDAP. Para producción se prefiere 636 con SSL/TLS. 389 se usa para LDAP sin cifrar o STARTTLS, pero no debería ser la solución permanente si la autenticación se usa en producción.
5. NetBIOS domain: Nombre corto NetBIOS del dominio AD, por ejemplo AVANET. No es el nombre DNS del dominio. Valores incorrectos provocan a menudo que los usuarios existan, pero no se encuentren o asignen correctamente.
6. ADS user name: Usuario de la cuenta de servicio con la que la firewall consulta AD. Debe usarse una cuenta dedicada con permisos de lectura, no un Domain Admin. Según el entorno puede funcionar el logon name corto, DOMAIN\user o un UPN como svc-firewall-ldap@example.local.
7. Password: Contraseña de la cuenta de servicio. Si expira o se cambia, las consultas de usuarios, importación de grupos, logins VPN o portales dejan de funcionar. Por eso la cuenta debe documentarse y monitorizarse.
8. Connection security: Define si la conexión está protegida y cómo. Para LDAPS se usa SSL/TLS con puerto 636. STARTTLS normalmente usa puerto 389, pero exige que el domain controller lo ofrezca correctamente. Simple no cifra y solo debería usarse para pruebas.
9. Display name attribute: Atributo AD que la firewall usa como nombre mostrado. Valores frecuentes son sAMAccountName, userPrincipalName, displayName o name. Para operación y troubleshooting es más importante un atributo único que uno bonito.
10. Email address attribute: Atributo de la dirección de correo. Normalmente es mail. Solo resulta útil si las direcciones de correo están realmente mantenidas en AD. De lo contrario aparecen datos de usuario vacíos o incoherentes.
11. Domain name: Nombre DNS del dominio AD, por ejemplo example.local o ad.example.com. No es el nombre NetBIOS. Debe coincidir con el dominio, la search base y el domain controller usado.
12. Search queries: Search base para consultas de usuarios y grupos. Aquí se introducen Distinguished Names como DC=example,DC=local o, de forma más precisa, OU=Users,OU=Company,DC=example,DC=local. Cuanto más concreta sea la search base, más clara y eficiente será la importación.

Si hay varios domain controllers, se debe decidir conscientemente si la firewall apunta a un DC concreto o si un nombre DNS interno estable representa una infraestructura AD adecuada. DNS, certificado, routing y reglas de firewall deben encajar entre sí.

Validate server certificate

En versiones actuales de SFOS se puede activar además Validate server certificate. Esto es útil para LDAPS, porque la firewall no solo cifra la conexión, sino que también comprueba si confía en el certificado del domain controller.

Para ello deben cumplirse estos puntos:

1. La CA emisora del certificado del domain controller está disponible en la firewall bajo Certificates > Certificates.
2. El valor de Server IP/domain coincide con el nombre del certificado o con un Subject Alternative Name.
3. Si se usa un CNAME, la firewall puede resolverlo internamente.
4. Fecha y hora coinciden en firewall y domain controller.

Si la resolución DNS interna no resuelve correctamente un CNAME o el nombre del domain controller, puede ayudar un DNS Host Entry en Network > DNS > DNS host entry.

NetBIOS domain y Domain name

Sophos Firewall necesita tanto la NetBIOS domain como el Domain name. Ambos valores deben coincidir exactamente con el dominio AD.

La NetBIOS domain puede verse, por ejemplo, en Active Directory Users and Computers en las propiedades del dominio.

El Domain name es el nombre DNS del dominio, por ejemplo example.local o ad.example.com.

Errores típicos en este punto:

• se confunden NetBIOS name y DNS domain name
• el domain controller introducido pertenece a otro dominio
• la firewall no puede resolver el DNS name del domain controller
• una firewall de red o Windows Firewall bloquea la conexión entre firewall y domain controller

Cuenta de servicio y contraseña

Para acceder a Active Directory se debería usar una cuenta de servicio dedicada. Una cuenta Domain Admin no es necesaria para consultas LDAP normales y aumenta el riesgo de forma innecesaria.

Recomendaciones:

• cuenta propia para la firewall, por ejemplo svc-sophos-fw-ldap
• solo permisos de lectura necesarios
• owner documentado para cambios de contraseña
• contraseña larga y única
• sin inicio de sesión interactivo si las políticas AD lo permiten limpiamente
• monitoring o recordatorio antes de la expiración

Si la contraseña de la cuenta de servicio expira o cambia, la firewall ya no puede consultar usuarios ni grupos. Más tarde esto suele verse como problema de VPN, portal o regla de usuario, aunque la causa real esté en la integración AD.

Seguridad de conexión y LDAPS

En producción se debería preferir LDAPS. Para ello el domain controller necesita un certificado adecuado y la firewall debe confiar en la CA emisora.

Comprobar:

• el puerto 636 es accesible desde la interfaz de la firewall al domain controller
• el certificado del domain controller es válido
• el nombre del certificado coincide con el nombre DNS usado
• la CA emisora es conocida por la firewall si se exige validación
• fecha y hora coinciden en firewall y domain controller

En temas de certificados también importa la distribución de CA. Para distribuir la CA de Sophos Firewall a clientes, véase Distribuir el certificado CA de Sophos Firewall para HTTPS Scanning. Para LDAPS, en cambio, lo relevante es principalmente la CA del domain controller o de la PKI interna.

Atributo de visualización y atributo de correo

El atributo de visualización determina cómo se muestran los usuarios en Sophos Firewall. Valores típicos:

• sAMAccountName
• userPrincipalName
• displayName
• name

sAMAccountName suele ser robusto y corto en entornos AD clásicos. userPrincipalName se acerca más a nombres de login modernos e identidades cloud. displayName es legible para personas, pero no siempre suficientemente único para operación y troubleshooting.

Los atributos pueden comprobarse en Active Directory Users and Computers si Advanced Features está activado.

El atributo de correo suele ser mail. Es especialmente relevante si la firewall debe asociar información de correo a usuarios.

Search base y grupos

La search base define qué parte de Active Directory busca la firewall. Para un dominio completo, un ejemplo sería:

DC=example,DC=local

Para una OU concreta, la ruta puede ser:

OU=Users,OU=Company,DC=example,DC=local

El Distinguished Name de una OU se encuentra en Active Directory Users and Computers, en los atributos de la OU.

Una search base demasiado amplia suele funcionar, pero hace la configuración menos clara. En producción es mejor:

• OU dedicada o search base clara para usuarios relevantes
• grupos AD separados para VPN, portales o reglas de firewall
• no reutilizar al azar grandes grupos departamentales
• probar la importación de grupos tras cambios
• eliminar grupos antiguos o vacíos periódicamente

Importar grupos demasiado amplios puede cargar a largo plazo la gestión interna de usuarios de la firewall. Si con el tiempo hay muchos usuarios o grupos antiguos y las descargas del VPN Portal fallan de forma inesperada, ayuda revisar el límite de User-ID de Sophos Firewall.

Importante para Remote Access: En SFOS 21.5 MR1 se cambió que L2TP y PPTP ya no se activan automáticamente al importar grupos desde Active Directory y Microsoft Entra ID. Esto reduce superficie de ataque no deseada, pero debe revisarse tras upgrades si procesos antiguos de Remote Access dependían de ello.

Importar grupos y entender usuarios

Después de añadir el servidor AD, los grupos AD no están automáticamente completos en la firewall. Los grupos se importan mediante el asistente:

Authentication > Servers > Import

El proceso:

1. Seleccionar el servidor AD e iniciar Import.
2. Seleccionar Base DN para la búsqueda de grupos.
3. Seleccionar los grupos AD necesarios.
4. Revisar políticas comunes de grupo.
5. Comprobar selección y finalizar importación.
6. Bajo Authentication > Groups, revisar que los grupos existen correctamente.

Los usuarios aparecen bajo Authentication > Users solo cuando se autentican en un servicio, por ejemplo User Portal, VPN Portal, Captive Portal o Remote Access VPN. En cada login la firewall vuelve a comprobar qué grupos importados corresponden al usuario y actualiza la asignación.

Si un usuario no se encuentra en ningún grupo AD importado, queda en la Default Group. Esta Default Group se ve en Authentication > Services dentro de Firewall Authentication Methods. Por defecto suele ser Open group.

En entornos HA se importan los grupos AD en el dispositivo Primary. Lo mismo aplica al limpiar usuarios AD antiguos con Purge AD users.

El procedimiento completo para operar y probar las políticas de grupo, el Default Group, el grupo principal, las excepciones de usuario y el comportamiento de grupos múltiples según la función se explica en Gestionar correctamente los grupos de usuarios y el grupo principal en Sophos Firewall.

Main Group, orden de grupos y grupos anidados

Un usuario AD puede pertenecer a varios grupos. Sophos Firewall distingue:

• Group: Primer grupo coincidente en la lista de grupos de la firewall. Es la Main Group del usuario.
• Other group memberships: Otros grupos importados en los que el usuario también es miembro.
• Group order: Orden bajo Authentication > Groups. Decide qué grupo se convierte en Main Group cuando hay varios matches.

Esto es importante porque no todas las funciones evalúan múltiples grupos. Algunas usan solo la Main Group. Si un usuario está en varios grupos AD, puede aplicarse una policy distinta de la esperada.

El orden de grupos se cambia aquí:

Authentication > Groups > Reorder

Los grupos AD anidados no están soportados. Si una firewall policy debe aplicarse a un subgrupo, ese subgrupo debe importarse por sí mismo. No basta con importar solo el grupo AD superior.

El grupo AD primario de un usuario tampoco se transfiere como una membresía normal. Esto afecta especialmente al grupo AD estándar Domain Users. Para firewall policies se deben usar grupos de seguridad explícitos e incluir a los usuarios directamente.

Qué funciones soportan múltiples grupos

Para la operación, esta distinción es especialmente importante.

Se pueden tener en cuenta varios grupos AD en:

• Firewall rules: Sigue siendo decisivo el orden de las reglas de firewall.
• SSL/TLS inspection rules: Se aplica la primera Inspection rule coincidente.
• Web policies: Primero coincide la regla de firewall, después la regla Web Policy adecuada.
• IPS policies: Se aplica la policy de la regla coincidente.
• Application control policies: La evaluación se realiza mediante la regla de firewall correspondiente.
• SD-WAN routes: Los criterios de usuarios o grupos pueden considerar varios grupos.
• Policy test: Útil para comprobar matching de grupos y policies.
• Remote access SSL VPN: Se consideran permisos de Full y Split Tunnel policies coincidentes. En Full Tunnel, Full Tunnel tiene prioridad.
• Clientless SSL VPN: Se combinan permisos de los grupos coincidentes.

Solo se tienen en cuenta la Main Group o usuarios explícitos en:

• WAF rules
• Remote access IPsec VPN
• L2TP y PPTP
• Hotspots
• MFA, cuando MFA se aplica específicamente a grupos
• Surfing quota, Access time, Network traffic y Traffic shaping
• Quarantine digest, MAC binding y Sign-in restriction

Access Time de Sophos Firewall para usuarios y grupos muestra cómo comprobar el grupo principal para un acceso de usuario dependiente de la hora y cómo delimitar las excepciones de usuario.

La misma limitación de Main Group se aplica a los créditos de tiempo y datos basados en el consumo. Surfing Quota y Network Traffic Quota en Sophos Firewall muestra el procedimiento completo.

Ejemplo práctico: un usuario está en VPN-Users y Firewall-Admins. Para SSL VPN puede funcionar la múltiple membresía. Para IPsec Remote Access o asignación de MFA por grupo, en cambio, puede contar solo la Main Group. Por eso, en Remote Access y accesos administrativos se debe probar conscientemente qué grupo aparece como Group en el objeto de usuario.

Varios servidores Active Directory

Se pueden configurar varios servidores AD. La firewall valida usuarios en el orden configurado en WebAdmin. Esto no sustituye un diseño AD limpio.

Recomendaciones:

• Definir conscientemente el orden de servidores bajo Authentication > Services.
• Documentar search base y dominio por servidor.
• No usar grupos contradictorios con el mismo nombre en fuentes distintas.
• En varios UPNs o dominios, planificar DNS y AD de forma limpia.
• Probar failover no solo con Test connection, sino con un login real.
• Si falla un servidor AD, el mensaje para el usuario puede parecer una contraseña incorrecta.

Si varios UPNs pertenecen a la misma infraestructura de dominio, los registros DNS y la configuración de AD server deben corresponder al dominio correspondiente. Search base, Domain Name y resolución del servidor tienen que pertenecer juntos.

Probar la conexión

Después de guardar, la conexión debe probarse directamente. El test comprueba si la firewall alcanza el servidor y si los datos básicos son correctos.

Un test correcto no significa automáticamente que las reglas de usuario, SSO o VPN ya funcionen. Después deberían comprobarse al menos estos puntos:

1. Usuarios o grupos AD se encuentran correctamente.
2. Un usuario de prueba puede iniciar sesión en el lugar previsto.
3. La membresía de grupo coincide con el permiso de firewall o VPN deseado.
4. Log Viewer muestra eventos de autenticación comprensibles.
5. Remote Access VPN, User Portal o Captive Portal funcionan con un usuario de prueba normal.
6. MFA se solicita si está previsto para el caso de uso.
7. El servidor AD está en Authentication > Services en el lugar deseado de Firewall Authentication Methods.

Si después sigue sin estar claro si falla la selección del servicio, la identidad del usuario, la Main Group, la cuota o solo la posterior regla de firewall, Solucionar sistemáticamente los errores de autenticación en Sophos Firewall separa estas capas mediante un caso de prueba reproducible.

Para Remote Access con Sophos Connect, el siguiente paso es Configurar Sophos Connect Client en Sophos Firewall.

Validación por caso de uso

Después de la integración AD no debería documentarse solo un test de conexión. Distintas funciones usan la integración AD de formas distintas. Por eso conviene hacer una prueba propia para cada caso de uso previsto.

• Importación de grupos: Buscar e importar el grupo AD relevante en la firewall. Si algo no encaja, el grupo no se encuentra o contiene usuarios inesperados.
• User Portal: Probar el login con un usuario AD normal. Un síntoma típico es que el login falle aunque el server test fuera correcto.
• Remote Access VPN: Probar VPN login, permiso de grupo, MFA y acceso a destinos internos. En caso de error, el usuario quizá se autentica, pero no recibe la policy correcta o no tiene acceso.
• Regla de firewall basada en usuario: Generar tráfico de prueba y revisar usuario, grupo y Rule ID en Log Viewer. Si la asignación no funciona, el tráfico aparece solo con IP o coincide con otra regla.
• Captive Portal: Probar login en navegador y tráfico posterior. Los errores suelen verse cuando el login funciona, pero el usuario no se asigna correctamente después.
• AD SSO o STAS: Revisar Live Users y Log Viewer tras el login de Windows. Si hay problemas, el usuario queda desconocido o se asigna a una IP incorrecta.

Esta separación ahorra tiempo en operación. Un LDAP test correcto solo demuestra que servidor, puerto, bind account y search base son accesibles. No demuestra que los grupos VPN estén correctamente asignados, que MFA se aplique o que el tráfico de usuario se evalúe con identidad en reglas de firewall.

Para reglas basadas en usuarios, siempre se debe generar tráfico real y comprobar en Log Viewer si username, group, Firewall Rule ID y acción coinciden con lo esperado. Si solo se ve la dirección IP, la causa suele estar en SSO, STAS, Captive Portal o en el orden de las reglas de firewall. Para entornos STAS, Configurar STAS en Sophos Firewall es el artículo de continuación.

Si Sophos Endpoint ya envía Security Heartbeat, Synchronized User ID Authentication puede transmitir un usuario de dominio Windows 10 al firewall sin un agente de autenticación adicional. El procedimiento sigue necesitando la validación de AD correspondiente y una prueba real de la regla.

Tener en cuenta Active Directory SSO

Active Directory SSO es un área operativa propia. La conexión AD pura es una base, pero SSO requiere además condiciones adecuadas de cliente, navegador, DNS, Kerberos o NTLM.

Para Web Authentication, Sophos Firewall soporta AD SSO clásico con Kerberos y NTLM. Kerberos es más limpio y rápido, pero exige más precisión en FQDN, DNS, SPN y confianza del navegador. NTLM es más tolerante y puede ser el fallback pragmático en entornos antiguos, pero no debería convertirse silenciosamente en el único método que funciona.

Cuando varios usuarios comparten la misma IP RDS o de terminal server, la asignación IP normal no es suficiente. Para el tráfico HTTP y HTTPS enviado exclusivamente a través de un proxy explícito, Per-Connection AD SSO para hosts multiusuario explica el procedimiento específico y su diferencia respecto a SATC.

⚠️ Nota de actualización para SFOS 22: Tras actualizar de SFOS 21.5 o anterior a SFOS 22.0 GA, AD SSO con Kerberos y NTLM puede dejar de funcionar. Las reglas basadas en identidad ya no reconocen a los usuarios de dominio afectados, mientras que el resto del tráfico del firewall continúa. Sophos corrigió el error en SFOS 22.0 MR1 Build 490. AD SSO debe probarse con tráfico de un usuario real antes e inmediatamente después de la actualización. Reparar AD SSO tras una actualización a SFOS 22 explica cómo revisar nasm.log, ejecutar el cleanup específico de NASM y comprobar el resultado con tráfico de usuario real.

El flujo de AD SSO es por tanto más que solo Test connection en el servidor AD:

1. Definir un hostname o FQDN en Administration > Admin and user settings. Para Kerberos debe usarse un FQDN, en minúsculas y con una parte host de 15 caracteres como máximo, para que NetBIOS name, objeto de equipo AD y SPN no se separen.
2. En Administration > Admin and user settings, configurar la Redirection Location para que los clientes puedan resolver el nombre y confiar en el destino. En escenarios Kerberos transparentes, ese nombre debe coincidir con el SPN. En un cliente Windows, setspn -Q HTTP/* ayuda a comprobar los SPN HTTP existentes.
3. Guardar el servidor AD en Authentication > Servers y ejecutar Test connection. Este test verifica conectividad y credenciales, pero todavía no prueba que AD SSO funcione.
4. En Authentication > Services, colocar el servidor AD en la posición deseada dentro de Firewall authentication methods. AD SSO usa los servidores en ese orden y solo pasa al siguiente si el anterior no está disponible.
5. En Administration > Device access, activar AD SSO para las zonas necesarias. Normalmente es LAN o una red interna de clientes bien definida, no todas las zonas.
6. En Authentication > Web authentication, configurar If Active Directory (AD) SSO is configured como Kerberos & NTLM o conscientemente como NTLM only.
7. En las reglas de firewall correspondientes, revisar si Match known users y, para solicitudes web desconocidas, Use web authentication for unknown users encajan con el flujo previsto. Una regla separada y bien nombrada para HTTP y HTTPS suele ser más fácil de operar.

Si Use web authentication for unknown users debe autenticar tráfico HTTPS en modo transparente, la firewall puede descifrar la conexión para el proceso de autenticación. Esto debe encajar con el diseño de TLS Inspection y certificados; si no, AD SSO se parece rápidamente a un problema de navegador, certificado o webfilter.

Para validar, Log Viewer es clave. En Log viewer > Authentication, al iniciar la conexión AD SSO deberían verse mensajes como Kerberos authentication initialized successfully y NTLM authentication channel established successfully. Mensajes como Cannot initialize Kerberos authentication o Cannot establish NTLM authentication channel son problemáticos. La columna Log Comp muestra además si un cliente usa Kerberos o NTLM.

La cuestión de la cuenta es importante. Para consultas LDAP normales suele bastar un Domain User con permisos de lectura. Para AD SSO, sin embargo, la firewall debe unirse al dominio y poder crear un objeto de equipo o un SPN. Para ello se necesita una cuenta Domain Admin o una cuenta con permisos delegados correctamente para domain join. En entornos HA, con varios servidores AD o tras upgrades, la firewall puede necesitar unirse de nuevo al dominio. Por eso no conviene hacer el join una vez con Domain Admin y después cambiar a una cuenta más débil si esa cuenta no puede hacer el rejoin más adelante.

Desde SFOS 21.5 MR1, Windows Server 2025 está soportado para Active Directory SSO con NTLM y Kerberos. SFOS 22 trae además componentes Samba actualizados y elimina métodos de cifrado antiguos. Para admins esto significa:

• Probar AD SSO después de upgrades de domain controllers.
• Revisar autenticación y asignación de usuarios tras upgrades de SFOS.
• Documentar dependencias Kerberos/NTLM en entornos antiguos.
• No planificar cifrado obsoleto como solución permanente.
• Revisar DNS request routes para dominios AD si la firewall no encuentra los service records AD mediante el resolver normal.
• No confundir SSO con Entra ID SSO para Sophos Connect.

Si se planifica Entra ID SSO para VPN o VPN Portal, se debe usar el artículo separado Configurar Microsoft Entra ID SSO para Sophos Connect y VPN Portal. Es un modelo de autenticación distinto al AD local clásico.

Troubleshooting

El test de conexión falla

Primero revisar conectividad, puerto, routing y DNS. Después comprobar connection security, certificado, cuenta de servicio y contraseña.

Checks prácticos:

• ¿La firewall puede alcanzar el domain controller por IP?
• ¿El nombre DNS se resuelve correctamente?
• ¿El puerto 389 o 636 está accesible?
• ¿SSL/TLS coincide realmente con el puerto y el certificado?
• ¿La cuenta de servicio está activa y no bloqueada?
• ¿Hay reglas en Windows Firewall o requisitos de LDAP Signing?

No se encuentra el usuario

Con frecuencia la search base está mal o es demasiado estrecha. Revisar el distinguishedName de la OU y asegurarse de que el usuario está realmente dentro de la search base. También escritura, caracteres especiales y el atributo de visualización elegido pueden dificultar la búsqueda.

El grupo se importa, pero el acceso no funciona

Entonces hay que revisar la cadena de permisos: grupo AD, grupo importado en la firewall, regla VPN/portal/firewall asignada, MFA y posición de la regla. En Remote Access también debe estar vinculada la configuración VPN adecuada con el grupo.

Si el usuario está en varios grupos AD, revisar además la Main Group bajo Authentication > Users. Especialmente MFA, Remote access IPsec VPN, WAF, Hotspots y varias opciones relacionadas con usuarios consideran solo la Main Group.

Los usuarios AD nuevos no pueden iniciar sesión en el VPN Portal

Si un usuario AD existente puede utilizar el VPN Portal, pero un usuario recién creado con permisos comparables no puede hacerlo, primero hay que comparar la asignación de grupos, el método de Remote Access y la versión del firmware. En Authentication > Users, Group muestra la Main Group; los demás grupos importados aparecen en Other group memberships. SSL VPN puede tener en cuenta varias membresías de grupo, mientras que IPsec Remote Access solo considera la Main Group o un usuario seleccionado explícitamente.

Para el diagnóstico:

1. Comparar el nuevo usuario afectado con un usuario existente que funcione.
2. Comprobar la Main Group y Other group memberships.
3. En Authentication > Services, comprobar los VPN portal authentication methods; en Administration > Device access, la zona de origen permitida; y en la policy de Remote Access, el usuario o grupo.
4. Registrar la versión y el build de SFOS.

Sophos corrigió con NC-180824 un error que impedía a los usuarios AD nuevos de una Secondary AD Group iniciar sesión en el VPN Portal. La corrección está incluida en SFOS 22.0 MR2 Build 546, publicado el 14 de julio de 2026. Sophos no indica ni la versión en la que se introdujo el error ni un workaround oficial. Si la configuración y la lógica de grupos son correctas, se debe actualizar una instalación antigua afectada a SFOS 22.0 MR2 o posterior y repetir después la prueba con un usuario AD que inicie sesión en la firewall por primera vez y cuyo permiso VPN se conceda exclusivamente mediante la Secondary Group afectada en una policy de SSL VPN.

⚠️ No reordenar grupos por sospecha, no depurar usuarios prematuramente con Purge AD users ni volver a crear grupos. Sophos no documenta estas medidas como solución para NC-180824 y pueden modificar otros permisos.

Un grupo AD nuevo no aparece automáticamente

Los grupos AD recién creados no se sincronizan automáticamente con la firewall. El grupo debe importarse de nuevo mediante el asistente de importación o crearse manualmente como grupo adecuado. Después un usuario de prueba debería iniciar sesión de nuevo para que la firewall evalúe otra vez las membresías.

Un usuario eliminado en AD sigue visible en la firewall

Los usuarios AD que ya iniciaron sesión pueden seguir visibles en la firewall. Si usuarios se eliminaron en AD, primero deben retirarse en AD y después usar Purge AD users en la firewall. En entornos HA se hace en el dispositivo Primary.

El login funciona, pero la regla de usuario no se aplica

Entonces normalmente LDAP no es el problema, sino la asignación de usuario, SSO, posición de regla o logging. En Log Viewer debe verse si el tráfico se evalúa con identidad de usuario o solo con IP. Para analizar reglas, véase Probar una regla de firewall con Log Viewer, Policy Test y Packet Capture.

AD SSO cae a Captive Portal o NTLM

Si AD SSO no funciona de forma transparente, normalmente intervienen la Redirection URL, el SPN, la resolución DNS o la confianza del navegador. Para Kerberos, el nombre al que redirige la firewall debe pertenecer al HTTP SPN correspondiente y debe poder resolverse desde el cliente. Para NTLM, el navegador debe tratar el nombre de destino como confiable; si no, solicita credenciales o cae al Captive Portal.

En la práctica se revisa primero Administration > Admin and user settings, la resolución DNS del nombre de redirección, setspn -Q HTTP/* en un cliente Windows y Log viewer > Authentication. Si aparece solo NTLM en lugar de Kerberos, a menudo indica un problema de SPN o confianza del navegador, no necesariamente una conexión AD defectuosa.

Tras un upgrade algunos logins dejan de funcionar

Después de upgrades de SFOS o domain controllers, conviene prestar atención a SSO, Kerberos/NTLM, métodos de cifrado antiguos, certificados e importación de grupos. Si solo algunos usuarios están afectados, revisar también caracteres especiales, espacios, UPN, membresías de grupo y estado de contraseña.

Para logs de autenticación y servicios ayuda Sophos Firewall Troubleshooting: Services y Logs.

La conexión no funciona con validación de certificado activada

Si Validate server certificate está activado, certificado, CNAME, resolución DNS y confianza en la CA deben encajar. Causas frecuentes son un certificado con otro nombre, una CA interna no importada en la firewall o un CNAME que la firewall no puede resolver.

Checklist operativa

Antes de configurar:

• Domain controller, puerto y nombre DNS definidos.
• LDAPS y cadena de certificados revisados.
• Cuenta de servicio dedicada creada.
• Search base y grupos relevantes definidos.
• Diseño de MFA y Remote Access aclarado.

Después de configurar:

• Test de conexión correcto.
• Servidor AD añadido como Authentication Method primaria o adecuada.
• Usuario y grupo de prueba revisados.
• Grupos AD importados mediante el asistente.
• Main Group de un usuario de prueba comprobada.
• Con varios grupos: login en el VPN Portal probado con un usuario existente y con un usuario que inicia sesión en la firewall por primera vez, cuyo permiso se concede exclusivamente mediante una Secondary Group en una policy de SSL VPN.
• Remote Access, portal o regla de usuario probados con usuario normal.
• Log Viewer muestra eventos de autenticación esperados.
• Expiración de contraseña de la cuenta de servicio documentada.
• Prueba de upgrade planificada para AD SSO, importación de grupos y procesos VPN.

En operación:

• Eliminar grupos no necesarios.
• Importar activamente nuevos grupos AD; no esperar sincronización automática.
• Revisar la cuenta de servicio regularmente.
• Renovar certificados LDAPS antes de que expiren.
• Controlar el orden de grupos tras cambios AD.
• Usar named admins y MFA para accesos administrativos.
• No tratar errores de autenticación solo como problema de usuario; revisar también AD, red, certificados y reglas de firewall.

FAQ