Conectar un servidor LDAP genérico con Sophos Firewall

Active Directory es el servidor de autenticación más habitual en Sophos Firewall, pero no el único. Quien opera OpenLDAP, 389 Directory Server, FreeIPA, Google Secure LDAP u otro directorio LDAP puro puede conectar Sophos Firewall igualmente como cliente LDAP. El tipo de servidor se llama deliberadamente LDAP server, no Active Directory, aunque Active Directory sea técnicamente en sí mismo un directorio LDAP.

Este artículo trata específicamente el caso genérico: un servicio de directorio sin los campos específicos de AD, como nombres de dominio o Kerberos. Para entornos Active Directory con LDAPS, importación de grupos y AD SSO encaja mejor conectar Active Directory con Sophos Firewall. Para autenticación basada en RADIUS, por ejemplo mediante Microsoft NPS o una pasarela MFA, el artículo adecuado es configurar un servidor RADIUS en Sophos Firewall.

Cuándo encaja un servidor LDAP genérico

Un servidor LDAP en Sophos Firewall tiene sentido cuando:

• Los usuarios y grupos están en un directorio que no es Active Directory, por ejemplo OpenLDAP, 389 Directory Server o FreeIPA.
• Un directorio basado en la nube ofrece una interfaz LDAP, por ejemplo Google Secure LDAP o un proxy LDAP delante de Entra ID u Okta.
• Varios sistemas ya autentican contra el mismo directorio LDAP y el firewall debe usar la misma fuente.
• No se necesita Kerberos ni NTLM, sino que basta con una autenticación bind simple.

Si en cambio se opera un Windows Server con Active Directory Domain Services, el tipo de servidor AD especializado suele ser la mejor opción, porque representa correctamente campos adicionales como los nombres de dominio. El tipo de servidor LDAP genérico también funciona contra Active Directory, pero cubre menos automatismos específicos de AD.

Requisitos previos

• Acceso al WebAdmin de Sophos Firewall.
• Alcanzabilidad del servidor LDAP desde el firewall, normalmente el puerto 389 (texto plano/StartTLS) o 636 (LDAPS).
• Una cuenta de bind con permisos de lectura sobre el subárbol relevante, especificada como Distinguished Name (DN).
• La Base DN bajo la que se buscan los usuarios, por ejemplo ou=people,dc=firma,dc=local.
• Conocimiento del atributo que sirve como nombre de inicio de sesión, con frecuencia uid, sAMAccountName o mail.
• Con conexión cifrada: el certificado del servidor o la cadena de certificados, si el firewall debe validarlo.

⚠️ Una cuenta de bind solo debería tener permisos de lectura sobre el subárbol necesario. No se usa para cambios administrativos en el directorio, sino únicamente para que el firewall autentique las solicitudes de los usuarios ante el servidor LDAP.

Crear el servidor LDAP

1. Abrir Authentication > Servers.
2. Seleccionar Add y elegir LDAP server como Server type.
3. En Server name, asignar un nombre único, por ejemplo LDAP_Firma_Intern.
4. En Server IP/domain, introducir la dirección IP o el nombre DNS del servidor LDAP.
5. En Version, elegir la versión LDAP soportada por el servidor, normalmente Version 3.
6. En Connection security, elegir entre Plaintext, SSL/TLS o STARTTLS.
7. En Port, definir el puerto correspondiente, si no se usa el puerto estándar.
8. Desactivar Anonymous login si el servidor no permite solicitudes de bind anónimas.
9. En Bind DN, introducir la cuenta técnica como Distinguished Name, por ejemplo cn=svc-sophos,ou=service,dc=firma,dc=local.
10. Introducir el Password correspondiente.
11. En Base DN, introducir el ámbito de búsqueda de usuarios, por ejemplo ou=people,dc=firma,dc=local.
12. En Authentication attribute, introducir el campo que sirve como nombre de inicio de sesión, con frecuencia uid.
13. Opcionalmente definir Display name attribute y Email address attribute, por ejemplo cn y mail.
14. Opcionalmente definir Group name attribute si se deben evaluar las pertenencias a grupos.
15. Ejecutar Test connection y comprobar el resultado.
16. Elegir Save.

Los campos de un vistazo:

Un Test connection exitoso solo demuestra que el servidor, el puerto, la cuenta de bind y la base de búsqueda son en principio alcanzables. Si se encuentran los usuarios correctos y los grupos se asignan correctamente debe comprobarse después con un usuario de prueba real.

Elegir correctamente el cifrado

Para entornos productivos, la conexión entre el firewall y el servidor LDAP debería estar cifrada, ya sea mediante LDAPS en el puerto 636 o mediante STARTTLS en el puerto clásico 389. El LDAP en texto plano envía las contraseñas de bind, y en parte también datos de usuario, sin cifrar, y solo debería usarse en escenarios de prueba internos y estrechamente protegidos.

Con Validate server certificate, el firewall comprueba si el certificado presentado por el servidor LDAP es de confianza. Con certificados autofirmados, como los que se usan por ejemplo en Google Secure LDAP, el certificado puede marcarse como no confiable aunque la conexión funcione. En ese caso hay que decidir conscientemente si se ajusta la comprobación del certificado o si el certificado se importa al firewall.

Ejemplo: Google Secure LDAP

Google Secure LDAP muestra bien cómo se conecta un directorio basado en la nube mediante LDAP genérico:

• Server IP/domain: ldap.google.com
• Port: 636
• Version: 3
• Connection security: SSL/TLS
• Bind DN y Password: credenciales de las LDAP-Client-Credentials generadas en la Google Admin Console.
• Certificado: el certificado de cliente emitido por Google, con clave privada, se guarda en el firewall.
• Atributos: uid para el inicio de sesión, cn para el nombre mostrado, mail para la dirección de correo electrónico, memberOf para los grupos.

Este ejemplo se puede trasladar a otros proveedores LDAP con una estructura similar. Lo decisivo es siempre qué atributo rellena realmente el proveedor para el nombre de inicio de sesión, el nombre mostrado, el correo electrónico y la pertenencia a grupos.

Introducir correctamente Bind DN y Base DN

La fuente de error más frecuente en un nuevo servidor LDAP es una sintaxis DN mal escrita o mal entendida.

Reglas importantes:

• Un DN se escribe de la parte más específica a la más general, por ejemplo cn=svc-sophos,ou=service,dc=firma,dc=local.
• La Base DN para la búsqueda de usuarios debe ser el subárbol en el que realmente se encuentran los objetos de usuario relevantes, no necesariamente la raíz del directorio.
• Si los usuarios se encuentran en varias unidades organizativas, la Base DN debe elegirse lo suficientemente arriba en el árbol como para incluir todos los contenedores relevantes.
• Append base DN decide si la Base DN se añade adicionalmente al Bind DN. Esto depende del servidor y debería probarse específicamente en caso de problemas.

Si la Base DN se elige demasiado estrecha, el firewall puede reportar una prueba de conexión exitosa, pero no encontrar usuarios más adelante. Si la Base DN se elige demasiado amplia, la búsqueda puede tardar innecesariamente o incluir objetos no deseados.

Asignar grupos y atributos

Para las reglas de firewall, las Web Policies o los permisos VPN por grupos, el Group name attribute es decisivo. Determina qué atributo LDAP interpreta el firewall como pertenencia a un grupo.

Patrones típicos:

• Los directorios con el esquema clásico groupOfNames o posixGroup suelen usar un atributo como memberOf o evalúan la pertenencia a grupos mediante referencias inversas.
• Los directorios en la nube con proxy LDAP, por ejemplo Google Secure LDAP, suelen entregar los grupos directamente en el atributo memberOf del objeto de usuario.
• Si el esquema no está claro, ayuda un navegador LDAP o una herramienta de línea de comandos como ldapsearch para ver por completo el objeto de usuario antes de configurar el firewall.

Después de la configuración se debería probar al menos un usuario de cada grupo relevante. Un único inicio de sesión exitoso no demuestra que la asignación de grupos funcione correctamente para todos los grupos.

Activar el servidor LDAP para servicios

Un servidor LDAP creado aún no autentica a nadie por sí mismo. Además debe asignarse al servicio deseado en Authentication > Services, por ejemplo VPN Portal, SSL VPN, Captive Portal o el inicio de sesión de administración.

Procedimiento práctico:

1. Abrir Authentication > Services.
2. Seleccionar el servicio afectado, por ejemplo Firewall authentication methods o VPN.
3. Añadir el servidor LDAP recién creado como fuente de autenticación.
4. Comprobar el orden si se usan varios servidores en paralelo.
5. Comprobar el servicio previsto con un usuario de prueba.

Si hay varios servidores de autenticación activos simultáneamente, por ejemplo LDAP y usuarios locales, el orden debería elegirse conscientemente. El firewall consulta los servidores en el orden en que están registrados.

Probar y validar la conexión

Después de guardar, la configuración debería probarse en varios niveles:

1. Test connection en la pantalla del servidor: confirma la alcanzabilidad, la cuenta de bind y la Base DN.
2. Iniciar sesión con un usuario de prueba en el servicio de destino: confirma que la autenticación realmente funciona.
3. Comprobar la pertenencia a grupos: confirma que el Group name attribute se evalúa correctamente.
4. Probar con un usuario o contraseña incorrectos: confirma que los inicios de sesión fallidos se rechazan correctamente.
5. Revisar el Log Viewer: muestra si las solicitudes de autenticación llegan y se procesan como se espera.

Un usuario de prueba que inicia sesión correctamente pero no está asignado al grupo esperado suele indicar un Group name attribute incorrecto o un esquema de grupos inesperado.

Errores típicos

• Sintaxis DN incorrecta: Bind DN o Base DN están intercambiados, mal escritos o usan separadores incorrectos. Comprobar la sintaxis contra el esquema del directorio.
• Base DN elegida demasiado estrecha: la prueba de conexión es exitosa, pero no se encuentran usuarios reales. Ajustar la Base DN más arriba en el árbol del directorio.
• Puerto o cifrado incorrectos: LDAPS en el puerto 389 o texto plano en el puerto 636 no funciona. El puerto y el Connection security deben coincidir entre sí.
• Certificado no confiable: con certificados autofirmados, el firewall puede clasificar la conexión como no confiable. Importar el certificado conscientemente o ajustar la validación de forma específica.
• Anonymous login activo, aunque el servidor lo rechaza: el bind falla. Desactivar Anonymous login e introducir Bind DN/Password.
• El atributo de grupo no coincide con el esquema: el inicio de sesión funciona, pero las directivas de grupo no se aplican. Comprobar el atributo contra el esquema LDAP real, por ejemplo con ldapsearch.
• Servidor LDAP no asignado en Authentication > Services: el servidor está creado, pero ningún servicio lo usa. Completar la asignación en Authentication > Services.
• Varios servidores de autenticación en el orden equivocado: otro servidor responde primero y produce un comportamiento inesperado. Comprobar el orden en Authentication > Services.

FAQ