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.
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.
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:
| Punto | Recomendación |
|---|---|
| Conexión | Usar LDAPS con SSL/TLS en el puerto 636 siempre que sea posible |
| Cuenta de servicio | 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 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
389puede 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.
| # | Campo | Significado y recomendación |
|---|---|---|
| 1 | Server type | Tipo del servidor de autenticación. 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 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 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 ser 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. |
| 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:
- La CA emisora del certificado del domain controller está disponible en la firewall bajo Certificates > Certificates.
- El valor de Server IP/domain coincide con el nombre del certificado o con un Subject Alternative Name.
- Si se usa un CNAME, la firewall puede resolverlo internamente.
- 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
636es 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:
sAMAccountNameuserPrincipalNamedisplayNamename
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:
- Seleccionar el servidor AD e iniciar Import.
- Seleccionar Base DN para la búsqueda de grupos.
- Seleccionar los grupos AD necesarios.
- Revisar políticas comunes de grupo.
- Comprobar selección y finalizar importación.
- 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.
Main Group, orden de grupos y grupos anidados
Un usuario AD puede pertenecer a varios grupos. Sophos Firewall distingue:
| Término | Significado |
|---|---|
| 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 tabla es especialmente importante:
| Función | ¿Se tienen en cuenta varios grupos AD? | Nota |
|---|---|---|
| Firewall rules | Sí | Sigue siendo decisivo el orden de las reglas de firewall. |
| SSL/TLS inspection rules | Sí | Se aplica la primera Inspection rule coincidente. |
| Web policies | Sí | Primero coincide la regla de firewall, después la regla Web Policy adecuada. |
| IPS policies | Sí | Se aplica la policy de la regla coincidente. |
| Application control policies | Sí | Se aplica mediante la regla de firewall correspondiente. |
| SD-WAN routes | Sí | Criterios de usuarios o grupos pueden considerar varios grupos. |
| Policy test | Sí | Útil para comprobar matching de grupos y policies. |
| Remote access SSL VPN | Sí | Se consideran permisos de Full y Split Tunnel policies coincidentes. En Full Tunnel, Full Tunnel tiene prioridad. |
| Clientless SSL VPN | Sí | Se combinan permisos de los grupos coincidentes. |
| WAF rules | No | Usar solo Main Group o usuario explícito. |
| Remote access IPsec VPN | No | Usar solo Main Group o usuario explícito. |
| L2TP y PPTP | No | Funciones legacy; solo se considera Main Group. |
| Hotspots | No | Solo Main Group. |
| MFA | No | MFA para grupos se refiere a la Main Group. Alternativamente, proteger usuarios individuales o todos los usuarios. |
| Surfing quota, Access time, Network traffic, Traffic shaping | No | Solo Main Group o ajuste específico de usuario. |
| Quarantine digest, MAC binding, Sign-in restriction | No | Solo Main Group o ajuste específico de usuario. |
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:
- Usuarios o grupos AD se encuentran correctamente.
- Un usuario de prueba puede iniciar sesión en el lugar previsto.
- La membresía de grupo coincide con el permiso de firewall o VPN deseado.
- Log Viewer muestra eventos de autenticación comprensibles.
- Remote Access VPN, User Portal o Captive Portal funcionan con un usuario de prueba normal.
- MFA se solicita si está previsto para el caso de uso.
- El servidor AD está en Authentication > Services en el lugar deseado de Firewall Authentication Methods.
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.
| Caso de uso | Qué se debe probar | Síntoma típico si falla |
|---|---|---|
| Importación de grupos | Buscar e importar el grupo AD relevante en la firewall | El grupo no se encuentra o contiene usuarios inesperados |
| User Portal | Login con un usuario AD normal | El login falla aunque el server test fuera correcto |
| Remote Access VPN | VPN login, permiso de grupo, MFA y acceso a destinos internos | El usuario 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 | El tráfico aparece solo con IP o coincide con otra regla |
| Captive Portal | Probar login en navegador y tráfico posterior | 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 | 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.
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.
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.
- 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
389o636está accesible? - ¿
SSL/TLScoincide 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.
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.
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.
- 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
¿Se debería usar LDAP o LDAPS con Sophos Firewall?
SSL/TLS. LDAP en el puerto 389 es más sencillo, pero sin medidas adicionales no ofrece una base de seguridad adecuada para una integración AD permanente.