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.

También deben quedar definidos el routing y la ruta de origen desde la firewall hasta el domain controller. LDAPS requiere TCP 636 y STARTTLS TCP 389; la resolución DNS interna y una cadena de certificados completa y válida deben funcionar desde la ruta que realmente use la firewall. Antes del cambio, se crea y descarga una copia cifrada de la configuración en Backup and firmware > Backup and restore, y se guarda su contraseña de forma segura.

⚠️ 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 empleada para consultar AD. Sophos usa el nombre corto administrator en su ejemplo. Para producción, Avanet recomienda una cuenta de servicio dedicada con permisos para buscar, leer y consultar la pertenencia a grupos, no una cuenta Domain Admin. Sophos no confirma de forma general que el nombre corto, DOMAIN\user y el UPN sean equivalentes en todas las configuraciones; por tanto, se utiliza y documenta el formato probado en el propio entorno AD.
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. Plaintext no cifra y solo debería usarse para pruebas.
9. Display name attribute: Atributo AD que se usa como nombre mostrado en la firewall. El valor debe corresponder al esquema del directorio y validarse con un usuario de prueba; la guía general de Sophos no presenta valores estándar universalmente intercambiables. Para Microsoft Entra Domain Services, Sophos indica expresamente DisplayName.
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 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=ad,DC=example,DC=com o, de forma más precisa, OU=Users,OU=Company,DC=ad,DC=example,DC=com. Una OU específica limita los usuarios visibles y mantiene clara la importación.

Solo los usuarios incluidos por al menos una Search query pueden aparecer para este servidor AD en Current activities > Live users. Si falta un usuario esperado aunque Test connection sea correcto, primero se comprueba que el Base DN y el ámbito de la OU incluyan su objeto real del directorio. La search base no se amplía preventivamente a todo el dominio.

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í.

Automatización AD al pasar de SFOS 22 a SFOS 23: La documentación de la API para añadir y editar un servidor AD utiliza en SFOS 23 denominaciones más específicas en las tablas que en SFOS 22: ServerIpDomain/ServerAddress pasa a ser ServerAddress, ServerName/NetBIOSDomain pasa a ser NetBIOSDomain y ADSUsername/Administrator/Username pasa a ser ADSUsername/Administrator. En cambio, el ejemplo XML sigue utilizando en ambas versiones, sin cambios, los elementos ServerAddress, NetBIOSDomain y ADSUsername. Esto demuestra un cambio en las denominaciones de la documentación, no que la firewall rechace los alias antiguos ni que se hayan renombrado los campos de WebAdmin explicados anteriormente. El ejemplo, que presenta inconsistencias internas, no es una plantilla de API verificada que pueda ejecutarse directamente.

Las denominaciones de la seguridad de conexión también se mantienen separadas: Plaintext es la denominación de WebAdmin; la documentación de la API indica los valores Simple, SSL y StartTLS para ConnectionSecurity. Las denominaciones de la GUI no se utilizan como valores de la API sin verificarlas previamente.

Entre SFOS 22 y SFOS 23 también difieren las tablas de estados y mensajes documentadas para Add y Edit. Estas tablas por sí solas no garantizan los códigos de respuesta reales ni los textos de los mensajes devueltos, ni tampoco los estados de transporte HTTP o que sea seguro reintentar las solicitudes. Por ello, al migrar la automatización AD, se comprueba la interpretación de las respuestas a partir de la documentación de la API de la versión utilizada y de respuestas realmente capturadas, en lugar de reutilizar sin cambios las antiguas correspondencias de errores. A continuación, se comprueban la configuración AD guardada y el inicio de sesión de un usuario de prueba normal en el servicio previsto.

Retirar de servicio el antiguo servidor AD de forma segura: La operación de API documentada Delete Active Directory server identifica la entrada del servidor de autenticación guardada en la firewall mediante su ServerName exacto, no mediante la dirección IP del controlador de dominio ni mediante un usuario AD. En cambio, Purge AD users depura las entradas de usuarios AD en la firewall y no sustituye la eliminación del servidor. Que la tabla de Delete indique que ServerName es opcional no demuestra que sea seguro eliminar sin especificar un destino ni que se admita una eliminación masiva. Por tanto, si el destino falta o no está claro, no se genera ni se ejecuta ninguna solicitud de eliminación; la documentación no proporciona una estructura completa de solicitud verificada y ejecutable ni especifica el comportamiento cuando se omite el destino. Como precaución operativa conservadora, antes de una retirada de servicio autorizada se documentan el nombre exacto del objeto y sus ajustes, se aseguran un acceso de administrador local utilizable y una copia de seguridad de la configuración, y se revisan los servicios afectados y el orden de servidores previsto en Authentication > Services. Primero se valida la vía de inicio de sesión de sustitución con un usuario normal y sus permisos de grupo; no se debe confiar en un fallback automático cuando se rechazan las credenciales. Después se vuelve a consultar la lista de servidores guardada y se comprueban el inicio de sesión y la autorización por grupos en cada servicio afectado. Ante una respuesta ambigua, primero se determina el estado real, sin repetir a ciegas la eliminación. La tabla de Delete sigue indicando 200 y 500 en SFOS 22 y 23, pero los identificadores de mensajes JavaScript cambian entre versiones. Estos valores de la documentación no son estados HTTP ni demuestran el efecto de la operación; las referencias JavaScript sin resolver no permiten deducir los textos de los mensajes devueltos ni las características de comportamiento en tiempo de ejecución. Esta es una recomendación operativa limitada a lo que permite afirmar la documentación, no una prueba de eliminación o restauración realizada aquí.

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. El certificado de servidor del domain controller se carga en Certificates > Certificates > Add > Upload certificate. Un certificado solo de CA se importa, en cambio, en Certificates > Certificate authorities; no deben confundirse ambas listas.
2. Tal como indica Sophos, en Server IP/domain se introduce el CNAME; este nombre DNS debe figurar en el Subject Alternative Name del certificado de servidor.
3. La firewall puede resolver internamente el CNAME.
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 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 de servidor adecuado. Si Validate server certificate está activo, se sigue el procedimiento de Sophos descrito anteriormente para importar el certificado de servidor; cualquier certificado de CA que también sea necesario se importa por separado como Certificate Authority.

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
• el certificado de servidor y, si procede, la CA emisora están importados en sus respectivas listas de certificados
• fecha y hora coinciden en firewall y domain controller

Sigue existiendo un límite importante del producto: SFOS 22 no admite actualmente la aplicación estricta de LDAP Channel Binding y LDAP Signing. LDAPS con validación de certificados protege la conexión, pero no demuestra el cumplimiento de una política de seguridad AD que exija channel binding o signing. Si la organización requiere esta aplicación, la integración se valida con la política AD concreta antes del despliegue y no se aprueba basándose únicamente en un Test connection correcto.

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.

Conectar Microsoft Entra Domain Services

Un dominio administrado de Microsoft Entra Domain Services puede conectarse como un servidor Active Directory. Sophos enumera WebAdmin, Captive Portal, User Portal, Client Authentication Agent y Remote Access SSL VPN para esta integración. No es una conexión SSO directa con Entra ID; en particular, esta documentación no deduce de ello compatibilidad con VPN Portal.

Para producción se activa Secure LDAP y se permite el puerto 636 desde la ruta elegida de la firewall hasta el dominio administrado. El certificado de servidor necesita la Extended Key Usage Server Authentication. Siempre que sea posible, en lugar de publicar LDAPS se utiliza una conexión privada mediante redes Azure o IPsec y se limita el acceso en la Network Security Group a la dirección de origen necesaria.

La configuración de ejemplo oficial de Sophos utiliza la IP pública de Secure LDAP, SSL/TLS, el puerto 636, DisplayName y mail, y desactiva Validate server certificate. La conexión privada mediante redes Azure o IPsec es una recomendación de seguridad adicional de Sophos. En cambio, validar el certificado con un nombre coincidente y una cadena de confianza correcta es una propuesta de refuerzo de Avanet que debe probarse en el entorno propio antes de producción; no se presenta como parte del ejemplo oficial. Los usuarios de Entra deben iniciar sesión y cambiar antes su contraseña para que se generen y sincronicen los hashes Kerberos/NTLM; la cuenta de bind debe pertenecer al grupo de administradores de Entra Domain Services configurado.

Preparar dominio administrado y certificado

Antes de cambiar producción, confirmar con el responsable Azure tenant, nombre DNS administrado, VNet/ruta privada, grupo administrador, ámbito de sincronización y permisos. Usar un equipo Windows, macOS o Linux protegido con OpenSSL; el ejemplo shell es Linux/macOS, no la consola SFOS. Guardar certificado, LDAP, NSG y orden de servicios actuales; mantener disponible un administrador local probado.

⚠️ Ejemplo mínimo HISTÓRICO, NO apto para cargar el certificado: La secuencia de comandos conservada a continuación explica la CA, la clave/CSR LDAP, serverAuth y PKCS#12. Solo establece el uso extendido de clave, pero no el uso de clave requerido ni un nombre DNS comodín. Su resultado no debe cargarse directamente en el siguiente paso de Azure. Primero se debe obtener un certificado adecuado de la PKI aprobada o planificar un caso de prueba autofirmado expresamente autorizado y comprobar todos los criterios siguientes. Un ejemplo autofirmado no constituye una aprobación para producción.

Para Secure LDAP, el certificado debe tener las siguientes propiedades:

• Nombre de dominio: Un comodín para el dominio DNS administrado real en el sujeto o en el nombre alternativo del sujeto (SAN) de tipo DNS, por ejemplo *.ad.example.com para ad.example.com. Sustituir el nombre de dominio de ejemplo completo; un único nombre de host LDAP no basta, porque Microsoft opera los controladores de dominio administrados con nombres cambiantes. Para la posterior validación en la firewall, el nombre del endpoint utilizado también debe coincidir con el certificado.
• Uso de clave: digitalSignature y keyEncipherment; además, el uso extendido de clave serverAuth para Server Authentication. La EKU por sí sola no sustituye estos dos requisitos de uso de clave.
• Validez y confianza: El certificado debe ser válido en el momento de su uso y cubrir, como mínimo, los próximos 3 a 6 meses. Planificar su renovación con antelación. Los sistemas que accedan deben confiar en el emisor y en la cadena necesaria; si se utiliza una CA propia o un certificado de prueba autofirmado, distribuir de forma selectiva los certificados públicos de confianza, nunca la clave privada del servidor ni de la CA.
• Paquete para cargar: Una .pfx protegida por contraseña con la clave privada LDAP correspondiente al certificado de servidor y los certificados públicos necesarios de la cadena, pero sin la clave privada de la CA. El formato de exportación PFX también debe cumplir los requisitos de importación descritos más adelante.

Para el ejemplo histórico, trabajar en un directorio nuevo al que solo tenga acceso su propietario, no sobrescribir nada y establecer umask 077. Crear entra-eku.conf en un editor de texto:

[client_server_ssl]
extendedKeyUsage = serverAuth

Ejecutar allí los siguientes comandos únicamente para comprender el ejemplo mínimo histórico; responder a las solicitudes de datos del certificado según el plan de nombres aprobado, sin copiar identidades de clientes de ejemplo. Incluso si se responde correctamente a esas solicitudes, esta secuencia de comandos no añade automáticamente las extensiones de certificado que faltan:

umask 077
openssl genrsa -out entra-ca.key 4096
openssl req -x509 -new -key entra-ca.key -days 365 -out entra-ca.pem
openssl genrsa -out entra-ldap.key 4096
openssl req -new -key entra-ldap.key -out entra-ldap.csr
openssl x509 -req -extensions client_server_ssl -extfile entra-eku.conf -in entra-ldap.csr -CA entra-ca.pem -CAkey entra-ca.key -CAcreateserial -out entra-ldap.crt -days 365
openssl pkcs12 -export -out entra-ldap.pfx -inkey entra-ldap.key -in entra-ldap.crt -certfile entra-ca.pem
openssl x509 -in entra-ldap.crt -noout -text
openssl pkcs12 -in entra-ldap.pfx -info -noout

Introducir una contraseña de exportación única de forma interactiva y guardarla en el almacén de secretos autorizado, nunca en un comando, ticket o registro. La .pfx contiene la clave privada LDAP, no la clave privada de la CA. Las claves generadas anteriormente se almacenan sin cifrar en el disco de trabajo; umask 077 limita los permisos de los archivos, pero no sustituye el cifrado. Utilizar un disco protegido y cifrado, proteger las claves y el paquete, transferir de forma segura solo el paquete aprobado y eliminar las copias de trabajo conforme a la política de claves. Los dos últimos comandos son comprobaciones que no muestran claves privadas, no una aprobación para cargar el paquete. Aquí no se han probado los comandos ni la carga en Azure en ningún tenant o dispositivo.

Comprobar las propiedades del certificado antes de exportarlo

Comprobar el certificado de servidor que realmente se vaya a utilizar con openssl x509 -in entra-ldap.crt -noout -text; para ello, sustituir el nombre de archivo por el del certificado aprobado por la PKI, sin utilizar el resultado del ejemplo mínimo sin verificarlo previamente. En el resultado, el nombre de dominio administrado con comodín, Digital Signature, Key Encipherment, TLS Web Server Authentication, el emisor, Not Before y Not After deben cumplir los requisitos. Solicitar también la comprobación de la cadena de confianza correspondiente y de la coincidencia con la clave privada prevista. Esta visualización de texto por sí sola no demuestra que la cadena sea de confianza en el endpoint de la firewall ni que Azure haya aceptado el paquete. Si falta alguna propiedad o no se ha aclarado la cadena de confianza, detener el procedimiento y obtener un certificado adecuado con el responsable de PKI/Azure; no cargar el ejemplo mínimo.

Exportar el PFX con un formato compatible y protegido

El comando conservado anteriormente, openssl pkcs12 -export, no selecciona expresamente un formato de exportación compatible. OpenSSL 3 utiliza de forma predeterminada AES-256-CBC/PBKDF2 y un MAC SHA256; Microsoft exige TripleDES-SHA1 para esta importación en Entra. Por tanto, el archivo histórico entra-ldap.pfx no es un paquete aprobado para cargar. Cambiar el nombre del paquete o introducir una contraseña correcta no resuelve este conflicto de formato. La codificación de compatibilidad afecta exclusivamente al contenedor PFX; no es una recomendación para utilizar algoritmos débiles de TLS, de firma de certificados o de claves.

Una vía alternativa documentada es la exportación de certificados de Windows en un sistema Windows protegido que ofrezca TripleDES-SHA1; en Windows Server, esta opción está disponible a partir de Windows Server 2016. El certificado de servidor, previamente revisado y aprobado por separado, debe estar en el almacén personal de certificados de ese sistema junto con su clave privada correspondiente y exportable. No importar claves privadas únicamente para distribuir la confianza a los clientes.

1. Como administrador autorizado, abrir mmc y seleccionar File > Add/Remove Snap-in > Certificates > Computer account > Local computer. En Certificates (Local Computer) > Personal > Certificates, identificar el certificado aprobado por su nombre y huella digital, no seleccionar un certificado cualquiera con el mismo nombre.
2. Seleccionar All Tasks > Export, después Yes, export the private key y Personal Information Exchange - PKCS #12 (.PFX). Activar Include all certificates in the certification path if possible. Los certificados de CA son componentes públicos de la cadena; la clave privada de la CA no se exporta.
3. En la página de seguridad, seleccionar Password, establecer TripleDES-SHA1 como cifrado e introducir y confirmar una contraseña única en el cuadro de diálogo. Guardar el paquete en una ubicación protegida con un nombre nuevo, por ejemplo entra-ldap-upload.pfx; no sobrescribir el archivo de ejemplo histórico. Si la opción no está disponible o la clave privada no es exportable, detener el procedimiento y solicitar al responsable de PKI una exportación compatible, sin continuar con los valores predeterminados.
4. Comprobar el paquete final en un sistema protegido con openssl pkcs12 -in entra-ldap-upload.pfx -info -noout; introducir la contraseña solo de forma interactiva. Se esperan un MAC SHA1 y TripleDES/3DES para los componentes cifrados de claves y certificados, que en la salida de OpenSSL suelen aparecer como pbeWithSHA1And3-KeyTripleDES-CBC. AES/PBKDF2 o un MAC SHA256 no cumplen este perfil de exportación. Si la versión instalada de OpenSSL o la política de proveedores impide la comprobación, no desactivar indiscriminadamente los mecanismos de protección; solicitar al responsable de PKI que compruebe el paquete con una herramienta de verificación aprobada. -noout impide que se muestren certificados y claves privadas; las contraseñas, los archivos PFX y las claves privadas no deben incluirse en los registros de comprobación.

Solo cuando se hayan comprobado y documentado los criterios del certificado, la clave privada correspondiente, la cadena, el perfil de exportación y la transferencia segura, podrá utilizarse la entra-ldap-upload.pfx aprobada en el siguiente paso. Se trata de una preparación respaldada por documentación, no de una prueba de tenant o dispositivo realizada aquí; tampoco se ha realizado aquí ninguna prueba en Windows.

Configurar Secure LDAP y descubrir el endpoint

1. El responsable Azure provisiona el dominio con DNS/VNet/admin acordados; esperar Microsoft Entra Domain Services > Running. En Synchronization, elegir deliberadamente All o Scoped y Save synchronization scope. Incluir usuarios previstos y completar sincronización de hashes explicada arriba.
2. Solo después de superar las comprobaciones del certificado y del PFX, abrir Secure LDAP del dominio, activarlo y cargar exclusivamente el paquete aprobado, no el archivo de ejemplo histórico, en .PFX file with secure LDAP certificate. Introducir la contraseña de exportación en Password to decrypt .PFX file y seleccionar Save. El ejemplo público original también activa Allow secure LDAP access over the internet; esto no es obligatorio para una ruta privada. Activarlo solo para un acceso público expresamente autorizado, con una regla NSG para TCP 636 que permita exclusivamente la IP pública de origen real de la firewall.
3. En Properties, registrar IP addresses, Secure LDAP external IP addresses, Admin group. En Microsoft Entra ID > Users, verificar pertenencia del bind account al grupo. Para routing privado comprobar endpoint administrado, DNS y origen; una IP del tenant no sustituye al controlador de dominio.

Mapear el servidor y validar servicios

En Authentication > Servers > Add: Server type: Active Directory, Server name único, Server IP/domain del endpoint LDAP elegido, Connection security: SSL/TLS, Port: 636, NetBIOS domain administrado. ADS user name es el miembro Admin group verificado; introducir contraseña de forma segura. Display name attribute: DisplayName, Email address attribute: mail, Domain name DNS administrado y Search queries con DN LDAP solo de objetos sincronizados necesarios. Sigue vigente la cualificación anterior: desactivar Validate server certificate es el ejemplo fuente, no el estándar de endurecimiento Avanet.

Test connection, después Save. Importar grupos necesarios en Authentication > Servers > Import, verificar Authentication > Groups y seleccionar servidor para servicios soportados previstos en Authentication > Services, sin alterar silenciosamente otros órdenes. Probar login y autorización de grupos de usuario sincronizado normal por servicio. Ante fallo, revisar Running, sincronización/hashes, endpoint/ruta, NSG TCP 636, contraseña/caducidad/EKU PFX, grupo bind y DN. No abrir LDAP ampliamente ni desactivar validación permanentemente. Si falla aceptación, restaurar certificado/LDAP/NSG/servicios registrados durante mantenimiento y probar ruta anterior; no borrar el dominio. Asignar responsable de renovación y reversión.

Atributo de visualización y atributo de correo

El atributo de visualización determina cómo se muestran los usuarios en Sophos Firewall. Entre los atributos del directorio que pueden encontrarse y que deben comprobarse en el entorno propio antes de utilizarlos están:

• sAMAccountName
• userPrincipalName
• displayName
• name

Estos valores no son intercambiables de forma general. Lo determinante es el esquema del directorio, la unicidad y el resultado con un usuario de prueba. Para Entra Domain Services, Sophos documenta DisplayName; esto no implica una regla general para AD local.

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=ad,DC=example,DC=com

Para una OU concreta, la ruta puede ser:

OU=Users,OU=Company,DC=ad,DC=example,DC=com

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. Configurar L2TP Remote Access en Sophos Firewall explica la asignación expresa de miembros, el límite del grupo principal y la validación.

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.

Si AD debe ser el método de autenticación principal de este procedimiento, ir a Authentication > Services, seleccionar el servidor AD configurado en Firewall authentication methods, moverlo a la primera posición de la lista de servidores seleccionados y hacer clic en Apply. Después, comprobar los grupos importados en Authentication > Groups y pedir a un usuario de prueba que vuelva a iniciar sesión para actualizar la asignación de grupos. Esta primera posición corresponde al procedimiento con AD como método principal, no a cualquier orden de servidores existente.

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 ninguno de los grupos AD de un usuario existe en la firewall, este recibe la Default group configurada en Authentication > Services. El valor predeterminado del producto es Open group. Aun así, antes del despliegue se comprueba el valor efectivo, porque puede haberse modificado y determina directamente los ajustes heredados.

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. Para los Firewall authentication methods se aplica una semántica importante: la firewall solo pasa al servidor siguiente si el anterior no está disponible; el rechazo de credenciales no provoca un fallback normal. Por tanto, este orden no es balanceo de carga ni sustituye un diseño AD correctamente planificado.

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.

Para varios dominios UPN en el mismo servidor de dominio, Sophos describe esta configuración específica: crear un registro DNS para cada dominio que apunte a la dirección IP de ese servidor y una configuración de servidor AD independiente en la firewall para cada dominio. Utilizar el dominio AD correspondiente como Search query en formato DN de LDAP, por ejemplo DC=ad,DC=example,DC=com para ad.example.com. Sustituir los valores por los dominios propios y comprobar el inicio de sesión y la asignación de grupos para cada dominio UPN. No es un procedimiento de balanceo de carga ni de failover entre varios controladores de dominio; con LDAPS, el nombre de servidor utilizado debe seguir siendo compatible con la validación del certificado.

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. Comprobar que se encuentre el grupo y que un usuario de prueba definido aparezca como miembro.
• 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.

Sophos sitúa NTLM, iniciado por el navegador, detrás de General Authentication Client, Clientless single sign-on y Client-based single sign-on. NTLM solo actúa como fallback cuando esas asignaciones no se aplican; si NTLM también falla, aparece Captive Portal. Si un usuario aparece con un método inesperado en Current activities > Live users, primero se comprueban el Client type mostrado y las fuentes de identidad ya activas antes de cambiar el SPN o Web Authentication.

La opción Kerberos & NTLM ofrece ambos métodos al navegador, y el cliente decide cuál utiliza. No existe un modo exclusivo de Kerberos porque la especificación HTTP no lo admite. Para el tráfico web transparente, la firewall redirige la autenticación al puerto TCP 8091.

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:

Sophos describe el registro de la firewall en el dominio Windows como la creación de un objeto para la firewall en el controlador de dominio principal. Este contexto corresponde a la unión al dominio para AD SSO; las consultas LDAP/LDAPS al directorio por sí solas no requieren automáticamente esa unión. Los permisos necesarios para la unión y los permisos de lectura de la cuenta de enlace LDAP se mantienen separados.

1. Definir un hostname o FQDN en Administration > Admin and user settings. Para Kerberos se utiliza un FQDN en minúsculas, con una parte host de 15 caracteres como máximo, para que NetBIOS name, objeto de equipo AD y SPN no diverjan.

   Ejemplo: la firewall está configurada como fw01.edge.example.com y el dominio AD se llama corp.example.com. Durante el Domain Join, SFOS utiliza el hostname NetBIOS fw01 con el dominio AD. Por tanto, el nombre conocido en AD es fw01.corp.example.com, no automáticamente el FQDN configurado en la firewall. El nombre de redirección para Kerberos transparente debe coincidir con el SPN HTTP registrado en AD y resolverse en DNS.

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. Una cuenta con acceso de lectura a AD puede ejecutar esta consulta dirigida y de solo lectura en un sistema Windows:

   setspn -Q HTTP/fw01.corp.example.com
   

   El FQDN de redirección propio sustituye al valor de ejemplo. La salida debe mostrar exactamente el SPN y el objeto de equipo esperados; si no hay resultado o aparece otro objeto, debe aclararse con el responsable de AD antes del despliegue.

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 solo pasa al servidor siguiente si el anterior no está disponible, no cuando se rechazan las credenciales.

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.

En Authentication > Services, HTTP challenge redirect on intranet zone debería permanecer activado. Si un sitio web alojado en Internet inicia un desafío NTLM, la firewall gestiona así el intercambio mediante su IP de interfaz local en la zona de intranet. Si se desactiva la opción, el navegador puede enviar credenciales a través de Internet. No es un ajuste de compatibilidad inofensivo.

Cuando Use web authentication for unknown users autentica tráfico HTTPS en modo transparente, la firewall descifra la conexión para la autenticación independientemente de la configuración de la regla de firewall o de la regla de SSL/TLS Inspection. 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.

Sophos Firewall solo ofrece uno de los dos métodos al navegador cuando Kerberos y NTLM se han inicializado correctamente en la firewall. Por eso, un fallback visible a NTLM no justifica omitir la comprobación de Kerberos. DNS, SPN y hora del sistema deben coincidir; de forma predeterminada, los relojes implicados en Kerberos no pueden diferir más de cinco minutos.

Las funciones de las cuentas deben mantenerse separadas. La cuenta de enlace LDAP solo necesita los permisos de lectura requeridos para las consultas del directorio. La operación de unión al dominio para AD SSO sí requiere una cuenta Domain Admin o una cuenta con permisos delegados para crear el objeto de equipo o el SPN. En entornos HA, con varios servidores AD o tras una actualización, puede ser necesaria una nueva unión; por ello deben estar disponibles credenciales adecuadas para esa operación, sin conceder esos privilegios elevados a la cuenta de enlace LDAP.

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/fw01.corp.example.com 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.

El certificado seleccionado en Admin console and end-user interaction > Certificate debe cubrir el hostname o FQDN de redirección y ser de confianza para los endpoints. El certificado autofirmado preinstalado de la firewall normalmente no cumple ambas condiciones para un nombre recién configurado. No se debe ignorar una advertencia de certificado, sino resolverla con un certificado público o interno que coincida.

Para NTLM, la confianza puede limitarse al nombre interno de redirección. En Windows, Microsoft Edge y Google Chrome heredan la configuración de Internet Options > Security > Local intranet > Sites > Advanced. En Firefox se añade el mismo FQDN a network.automatic-ntlm-auth.trusted-uris bajo about:config. Solo se autoriza el nombre interno realmente utilizado, no un dominio amplio ni sitios web arbitrarios.

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.

Revertir el cambio y continuar de forma segura

Antes de realizar cambios se documentan el orden de los servidores, los servicios utilizados, los grupos y los ajustes de certificados. Si falla la validación, primero se restauran el orden anterior, el método de conexión cifrado original y su puerto. Una prueba con Plaintext en el puerto 389 es exclusivamente un diagnóstico breve y nunca se deja como rollback de producción.

Si debe restaurarse toda la configuración, se utiliza la copia descargada previamente en Backup and firmware > Backup and restore. La restauración sustituye la configuración actual, descarta cambios posteriores y reinicia la firewall, por lo que debe realizarse en una ventana de mantenimiento. Un rollback de firmware inicia la partición anterior con su configuración y también interrumpe las sesiones. El rollback automático del firmware solo se activa si falla la migración de la configuración, no ante un fallo de AD SSO que solo se manifiesta durante la operación.

Después de cada reversión se repiten Test connection, un login normal en un servicio, la comprobación del efecto de los grupos y, para SSO, un acceso de usuario real junto con Log viewer > Authentication. En HA, la importación de grupos y Purge AD users se realizan en el dispositivo Primary; la prueba de fallo del DC secundario previsto solo se ejecuta en una ventana de mantenimiento autorizada, confirmando que el primer servidor no está realmente disponible y que el login funciona mediante el segundo.

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.
• Para AD SSO, se han comprobado los mensajes de Kerberos/NTLM en el Authentication log.
• 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 cuentas de administrador individuales y MFA para los accesos administrativos.
• No tratar errores de autenticación solo como problema de usuario; revisar también AD, red, certificados y reglas de firewall.

FAQ