Conectar un servidor LDAP genérico a Sophos Firewall

Sophos Firewall puede autenticar usuarios mediante el tipo de servidor LDAP server según los atributos del directorio y la pertenencia a grupos. En la práctica, son necesarios cuatro pasos: preparar un grupo local, conectar el servidor LDAP, seleccionarlo en Authentication > Services para el servicio deseado y verificar el inicio de sesión y la autorización con cuentas de prueba reales.

OpenLDAP, 389 Directory Server o FreeIPA son candidatos típicos para una conexión LDAP genérica, pero no son productos intercambiables. Los atributos, los valores de grupo devueltos y el vencimiento de la cuenta difieren según el esquema. Por lo tanto, esta guía proporciona un ejemplo transferible; los valores deben verificarse en el objeto de usuario real. Google Secure LDAP se describe a continuación como una variante específica documentada por Sophos.

Para Windows Active Directory con LDAPS, importación de grupos o AD SSO, Conectar Active Directory a Sophos Firewall es una mejor opción. RADIUS mediante Microsoft NPS o una puerta de enlace MFA se trata en Configurar el servidor RADIUS de Sophos Firewall. Si necesita reemplazar el tipo de servidor nativo de eDirectory antes de SFOS 23, puede encontrar el proceso de migración completo en Migrar eDirectory antes de SFOS 23.

Preparar los valores y el procedimiento de reversión

Se necesita:

acceso WebAdmin a Sophos Firewall;
conectividad con el servidor LDAP desde el firewall a través del puerto configurado en el servidor;
una cuenta de enlace con permisos de lectura en el área del directorio requerida;
Bind DN y Base DN, por ejemplo cn=svc-sophos,ou=service,dc=example,dc=net y ou=people,dc=example,dc=net;
los atributos de inicio de sesión, nombre para mostrar, dirección de correo electrónico, grupo y, si corresponde, de vencimiento de la cuenta;
para verificar el certificado, un nombre de servidor que se pueda resolver y la cadena de confianza de CA adecuada.

Los valores iniciales habituales son el puerto 389 para STARTTLS y 636 para SSL/TLS. No son valores predeterminados fijos de SFOS: un directorio puede usar un puerto diferente, que debe coincidir con Connection security y la configuración del servidor.

⚠️ La cuenta de enlace no requiere permisos administrativos de escritura. Limite sus permisos de lectura al subárbol y los atributos que el firewall necesita para las solicitudes de los usuarios.

Antes de realizar el cambio, documente en Authentication > Services los servidores seleccionados, su orden y las opciones de herencia para cada método afectado. En Firewall authentication methods, registre también el Default group anterior. Esto le permite deshacer el cambio sin eliminar apresuradamente nuevos objetos. Durante los cambios, mantenga disponible un acceso de administrador local previamente probado para la recuperación.

Distinguir Bind DN, Base DN y atributos

Un DN va desde el objeto específico hasta la raíz del directorio. cn=svc-sophos,ou=service,dc=example,dc=net identifica la cuenta de enlace en el ejemplo. El DN base, por otro lado, especifica el punto de partida de la búsqueda de usuarios, como ou=people,dc=example,dc=net.

Un DN base demasiado estrecho no encontrará todos los usuarios que necesita. Una base de búsqueda innecesariamente amplia puede ralentizar las búsquedas e incluir objetos no deseados. Append base DN agrega el DN base a un DN de enlace incompleto al realizar el enlace; si el DN ya está completo, normalmente la opción se deja desactivada. El comportamiento exacto depende del servidor LDAP utilizado.

Los atributos también provienen del esquema del directorio. uid, cn, mail y memberOf son ejemplos, no especificaciones universales. Sophos recomienda memberOf como Group name attribute, pero utiliza GID en su propio ejemplo de configuración general. Por lo tanto, el valor de retorno, la asignación de grupos locales y la pertenencia a varios grupos deben verificarse con usuarios de prueba reales.

Seleccionar cifrado y certificados

Plaintext envía credenciales de usuario sin cifrar y no es una buena configuración de producción. SSL/TLS cifra la conexión desde el principio; STARTTLS convierte una conexión LDAP inicialmente no cifrada en una conexión cifrada mediante TLS.

Para Validate server certificate, el nombre especificado en el certificado del servidor y que el firewall puede resolver debe estar en Server IP/domain. Sophos se refiere a él como CNAME en la ayuda de SFOS 22, mientras que la misma descripción de campo en otros lugares solo menciona la IP del servidor. Por lo tanto, el nombre del certificado es la opción segura para una implementación controlada de TLS. Si el firewall no puede resolverlo, se puede crear una entrada en Network > DNS > DNS host entry. En Configurar entradas de host DNS en Sophos Firewall se explican el TTL, la búsqueda inversa y la prueba del resolvedor DNS.

Validate server certificate comprueba el certificado del servidor LDAP remoto. El Client certificate opcional especifica un certificado que utiliza el firewall para establecer una conexión segura al servicio LDAP; Google Secure LDAP requiere explícitamente el certificado generado por Google. Para errores de TLS, corrija primero el nombre, el DNS, la hora, la validez y la cadena de confianza en lugar de desactivar la verificación del certificado del servidor como primer paso.

Configurar grupo y servidor LDAP

Preparar grupo local

Abra Authentication > Groups y seleccione Add.
Ingrese un Group name único, por ejemplo LDAP-Benutzer.
Seleccione el Group type correspondiente al método de inicio de sesión previsto. Normal requiere que el usuario inicie sesión; Clientless controla el acceso en función de una dirección IP.
Configure las políticas de usuario, acceso remoto e inicio de sesión requeridas y guárdelas con Save.

En Surfing quota y Access time, seleccione deliberadamente los límites necesarios. Sophos utiliza Unlimited internet access y Allowed all the time en el ejemplo de aprendizaje; son políticas de ejemplo, no un requisito para LDAP. Para un acceso piloto restringido, resultan más adecuados la duración de uso realmente necesaria y el intervalo de tiempo autorizado. Mantenga los demás campos en sus valores predeterminados solo si estos se ajustan a su propia política de acceso.

El grupo se utilizará posteriormente como Default group. Por sí solo no concede ni bloquea el tráfico; son sus políticas y las reglas del servicio correspondiente las que deciden. En las políticas de usuario y las VPN de acceso remoto, salvo SSL VPN, la configuración específica del usuario tiene prioridad sobre las políticas de grupo. Esta regla de prioridad no se aplica a las VPN SSL de acceso remoto: un usuario puede acceder a los recursos de todas las políticas de túnel completo y dividido aplicables a él o a sus grupos. Por tanto, una política de usuario más restrictiva no anula automáticamente los permisos más amplios de los grupos de SSL VPN. Esto no garantiza que todos los esquemas LDAP representen del mismo modo la pertenencia a varios grupos; la asignación de grupos y los recursos realmente accesibles deben comprobarse durante la prueba piloto. La lógica de grupo completa, con la prueba piloto, las excepciones específicas de cada usuario y el grupo principal, está disponible en Gestionar de forma segura los grupos de usuarios de Sophos Firewall.

Crear la conexión y configurar el enlace

Abra Authentication > Servers y seleccione Add.
En Server type, seleccione LDAP server.
Asigne un Server name único, por ejemplo LDAP-Firma.
Ingrese la IP del servidor o el nombre de dominio en Server IP/domain. Para Validate server certificate, utilice el nombre del certificado del servidor que se pueda resolver.
Seleccione la Version 2 o 3 admitida por el servidor. Google Secure LDAP requiere la versión 3.
Configure Connection security y Port conjuntamente. Para el funcionamiento en producción, utilice SSL/TLS o STARTTLS.
Desactive Anonymous login e ingrese Bind DN y Password de la cuenta de lectura.
Solo active Append base DN si el firewall debe agregar el DN base a un DN de enlace incompleto al realizar el enlace.
Si la conexión es segura, decida expresamente si se debe activar Validate server certificate. Para servidores LDAP normales, la verificación es la opción segura en producción una vez preparados correctamente el nombre, el DNS y la cadena de confianza. Google Secure LDAP sigue el caso especial que se describe a continuación. Si se necesita un Client certificate, selecciónelo de la lista.

Establecer base de búsqueda y atributos

En Base DN, ingrese el punto de inicio de la búsqueda de usuarios. Get base DN puede obtener la base de búsqueda que ofrece el servidor.
Configure el atributo con el nombre de inicio de sesión como Authentication attribute, a menudo uid o mail.
Ingrese Display name attribute y Email address attribute para que coincidan con el objeto de usuario, por ejemplo, cn y mail.
En Group name attribute, ingrese el atributo de grupo devuelto en el objeto de usuario. memberOf es la recomendación de Sophos, pero debe coincidir con el esquema y el formato de devolución.
Ingrese el Expiry date attribute que coincida con el esquema. Si no existe tal atributo, verifique antes de la implementación si el formulario acepta un valor vacío y cómo se manejan las cuentas sin vencimiento.
Ejecute Test connection y guarde con Save.

Display name attribute y Email address attribute son campos opcionales en el servidor LDAP genérico. El nombre para mostrar facilita la identificación del objeto de usuario local; el atributo de correo electrónico proporciona la dirección correspondiente. En cambio, el atributo de correo electrónico es obligatorio para la creación de grupos LDAP de Google. Un Expiry date attribute indica el vencimiento de la cuenta, no la duración de una sesión VPN. Sophos indica Date en el ejemplo de aprendizaje general y expiry para Google; el nombre de atributo adecuado depende del esquema correspondiente.

Según Sophos, Test connection comprueba la conexión y las credenciales de enlace. La prueba no demuestra que el DN base incluya a todos los usuarios ni que una autorización de grupo o servicio se aplique correctamente. Para ello se requiere un inicio de sesión real.

Solo para automatización mediante API al pasar de SFOS 22 a SFOS 23: En la referencia de la API LDAP cambian las filas documentadas de Status Message Information: para Add LDAP server, de 200/500/502/503 a 200/400/401/403/409/500; para Edit LDAP server, de 200/500/503 a 200/400/401/403/404/500. 409 aparece solo para Add y 404 solo para Edit. Los símbolos de presentación también cambian de Message.LDAP* a Message.CP*. Estas filas y símbolos de la documentación no garantizan los códigos o mensajes realmente transmitidos ni establecen una correspondencia fija de 502/503 a 409/404. Para automatizar mediante API, revise la referencia de su versión y valide las respuestas reales del firewall de destino antes de adoptar una correspondencia. Esta comprobación de la API es independiente; siguen siendo necesarias la comprobación Test connection en la GUI y un inicio de sesión real.

Antes de cada alta o edición automatizada de LDAP: Las referencias de la API de SFOS 22 y 23 presentan contradicciones respecto a IntegrationType: el ejemplo indica LooseIntegration/TightIntegration y marca DisplayNameAttribute, EmailAddressAttribute, GroupNameAttribute y ExpiryDateAttribute con el comentario Only For Tight Integration; la tabla de parámetros describe ambos modos, pero solo permite el valor 1. No deduzca de ello que se admita alguno de los modos, qué significa 1 ni si se permite omitir atributos condicionales. El ejemplo no es un payload listo para enviar; sus valores textuales para las opciones de activación y desactivación y la seguridad de la conexión tampoco coinciden con las codificaciones de las tablas. Antes de realizar un cambio, revise el esquema o la referencia de la API de la versión de destino y compruebe en modo de solo lectura la configuración real de destino y una respuesta de la API correspondiente. Si la correspondencia sigue sin estar clara, no ejecute ninguna automatización basada en ella; utilice el procedimiento verificado mediante la GUI o aclare los requisitos de la API con Sophos Support. Los pasos de la GUI descritos anteriormente siguen siendo independientes de esta comprobación; siguen siendo necesarios Test connection y las pruebas reales de identidad, grupos, vencimiento de la cuenta cuando corresponda y cada servicio utilizado.

Habilitar LDAP para los servicios requeridos

Abra Authentication > Services.
En Firewall authentication methods, mueva el servidor LDAP a Selected authentication servers. Si debe responder en primer lugar, colóquelo en la primera posición.
Como Default group, seleccione el grupo preparado LDAP-Benutzer y haga clic en Apply.
Seleccione el servidor por separado para todos los métodos realmente utilizados: User portal authentication methods, VPN portal authentication methods, VPN (IPsec/dial-in/L2TP/PPTP) authentication methods, Administrator authentication methods y SSL VPN authentication methods.
Utilice opciones de herencia como Set authentication methods same as firewall, Same as firewall o Same as VPN solo si la lista de servidores resultante es la deseada.

Se puede seleccionar un máximo de 20 servidores por método de autenticación. Si hay varios servidores, el firewall los consultará en el orden que se muestra. El método de administrador no se aplica al superadministrador. Para L2TP y PPTP, Sophos sólo documenta PAP para LDAP; esta combinación no debe introducirse de nuevo sin una evaluación previa, tanto por PAP como por el carácter obsoleto de esos métodos VPN.

Además, para los inicios de sesión de administradores: Un usuario autenticado externamente mediante LDAP se crea inicialmente como usuario estándar al iniciar sesión por primera vez, aunque tenga una función de administrador en el directorio. Primero, inicie sesión con la cuenta prevista en un servicio habilitado, como el portal de usuario o de VPN. Después, con el acceso de administrador local existente, edite el usuario creado en Authentication > Users, establezca User type en Administrator, seleccione un Profile limitado a los permisos necesarios y guarde con Save. Seleccionar el servidor en Administrator authentication methods no es suficiente. A continuación, compruebe con esta cuenta el inicio de sesión en WebAdmin y las acciones de administración permitidas y no permitidas; siga conservando el acceso local de recuperación probado.

Configurar Google Secure LDAP

Antes de la configuración del firewall, se crea un cliente LDAP en la Consola de administración de Google en Apps > LDAP. Se limitan sus Access permissions, se descargan el certificado y su clave privada y se generan credenciales de acceso independientes. La contraseña ya no es visible después de cerrar el cuadro de diálogo. Si el nombre de usuario o la contraseña son incorrectos o ya no están disponibles, genere nuevas credenciales de acceso en la Consola de administración de Google y actualice después Bind DN y Password en la configuración del servidor LDAP del firewall.

Google puede cambiar la interfaz y los pasos de la Consola de administración. Por lo tanto, antes de la configuración, consulte la documentación actual de Google sobre cómo crear clientes LDAP, descargar el certificado y generar credenciales de acceso. Google Secure LDAP explica si el servicio está disponible para su edición de Google; los permisos de acceso deben ajustarse al ámbito de usuarios y grupos previsto.

El procedimiento documentado por Sophos en la Consola de administración de Google puede seguirse de este modo:

En Apps > LDAP, comience con ADD CLIENT, ingrese un nombre de cliente LDAP y una Description y seleccione CONTINUE. Un nombre único como Sophos-Firewall-Pilot facilita la identificación posterior.
Limite los Access permissions al ámbito de usuarios y grupos necesario y confirme con ADD LDAP CLIENT.
Seleccione Download certificate. El ZIP contiene el archivo de certificado .cer y la clave privada .key. Extraiga ambos archivos en una carpeta de trabajo protegida y registre la ubicación para la importación posterior. La clave privada no debe incluirse en tickets ni en recursos compartidos sin protección.
Continúe con CONTINUE TO CLIENT DETAILS, abra la tarjeta Authentication y seleccione GENERATE NEW CREDENTIALS. Registre de forma segura Username y Password antes de seleccionar CLOSE; estos valores se utilizarán posteriormente como Bind DN y Password, no las credenciales de un administrador de Google.

Las credenciales de acceso de Google no sustituyen el certificado de cliente. Para esta variante, Sophos Firewall necesita tanto el certificado con su clave privada como las credenciales de enlace generadas.

A continuación, active el cliente en Service status con ON for everyone y guárdelo con SAVE. Este estado de servicio activa el cliente, pero no sustituye los Access permissions configurados previamente.

Antes de importar el certificado, verifique en Administration > Time si el firewall obtiene la hora correcta a través de NTP. Según Sophos, una hora configurada manualmente de forma incorrecta puede provocar que falle la importación de certificados. Luego, en Certificates > Certificates > Add, seleccione el formato CER (.cer) e importe tanto Certificate como Private key desde la descarga de Google. El certificado puede aparecer como no confiable porque el propio Google lo firma; Sophos confirma que Google LDAP sigue funcionando. Esta indicación se refiere al certificado del cliente y no a la verificación del certificado del servidor LDAP.

Asigne un nombre de certificado único durante la importación. Mediante Choose File, seleccione el archivo .cer extraído para Certificate y el archivo .key correspondiente para Private key, confirme cada selección con Open y, por último, seleccione Save. Solo después de guardarlo podrá seleccionar este certificado en Client certificate en el servidor LDAP.

Los siguientes valores se aplican al servidor LDAP:

Server IP/domain: ldap.google.com
Version: 3
Connection security: SSL/TLS
Port: 636
Anonymous login: desactivado
Bind DN y Password: las credenciales LDAP de Google generadas
Append base DN: desactivado
Client certificate: el certificado de Google importado
Base DN: ingresar o recuperar con Get base DN
Authentication attribute: UID
Display name attribute: CN
Email address attribute: mail
Group name attribute: memberOf
Expiry date attribute: expiry

mail es obligatorio para la creación de grupos LDAP de Google. La guía de Sophos para Google Secure LDAP no establece explícitamente Validate server certificate en su lista de valores. De ello no puede deducirse que sea obligatorio activarlo ni desactivarlo; la opción se decide según el procedimiento general de TLS y su propia cadena de confianza. La indicación de que un certificado de cliente de Google no es confiable no es motivo para desactivar la verificación del certificado del servidor remoto.

Compruebe la conexión de Google con Test connection y guarde el servidor con Save. Después, prepare un grupo LDAP local como se describe arriba y seleccione el servidor de Google en Authentication > Services para los servicios necesarios. También en el caso de Google, crear únicamente el objeto de servidor no habilita ningún servicio; el inicio de sesión piloto comprueba posteriormente la identidad, el grupo y la autorización.

Comprobar el inicio de sesión y la asignación de grupos

Una prueba de aceptación abarca la conexión, la identidad y la autorización:

Test connection debe confirmar la conexión y las credenciales de enlace.
En Authentication > Services, verifique la lista de servidores, el orden y la herencia de cada método utilizado. El Default group pertenece a Firewall authentication methods.
Inicie sesión en el servicio deseado con un usuario piloto. Cuando inicia sesión por primera vez, el firewall crea localmente el usuario autenticado externamente.
En Authentication > Users, verifique que el usuario y el grupo aparezcan como se esperaba.
Realice una prueba positiva para cada grupo de directorio relevante. Además, verifique con un usuario sin una asignación de grupo local adecuada si se aplica el Default group esperado.
Revise no solo el inicio de sesión, sino también la política o regla de prueba prevista. En SSL VPN, pruebe los recursos permitidos y bloqueados teniendo en cuenta las políticas de usuario y de grupo aplicables; no deduzca los permisos efectivos únicamente a partir de una política de usuario restrictiva. Luego utilice una contraseña incorrecta como prueba negativa.
Para el inicio de sesión, la autorización y la contabilización del usuario, verifique access_server.log; para problemas del portal VPN, verifique además vpnportal.log.
Si se utiliza un atributo de vencimiento, incluya una cuenta de prueba con un estado de vencimiento conocido.

Si los valores del esquema no están claros, un administrador puede consultar el objeto de usuario en modo de solo lectura desde un sistema de administración Linux o directamente desde el servidor LDAP:

ldapsearch -LLL -x -H ldaps://ldap.example.net:636 \
  -D 'cn=svc-sophos,ou=service,dc=example,dc=net' -W \
  -b 'ou=people,dc=example,dc=net' \
  '(uid=max.muster)' '*' '+'

Este procedimiento de diagnóstico opcional no es un comando de SFOS y no debe ejecutarse en la consola avanzada. El ejemplo requiere LDAPS y confianza en la CA del servidor en el sistema que lo ejecuta; STARTTLS requiere una invocación adaptada a ese protocolo. -W solicita la contraseña de enlace de forma interactiva. Adapte el filtro (uid=max.muster) al Authentication attribute configurado. '*' y '+' pueden mostrar numerosos atributos normales y operativos con datos personales. Antes de adjuntar la salida a un ticket o compartirla, hay que anonimizarla.

Aislar errores por síntoma

Sin conexión: Verifique el enrutamiento, el DNS, el puerto y Connection security. Luego verifique el DN de enlace, la contraseña y Anonymous login.
Error de TLS o de certificado: Verifique el nombre del certificado del servidor, la resolución DNS, la hora del firewall, la validez y la cadena de CA. No desactive la verificación del certificado como primer paso.
Test connection funciona, pero no se encuentra el usuario: Compare el DN base, Authentication attribute y el nombre de inicio de sesión ingresado.
El inicio de sesión funciona, pero el grupo es incorrecto: Verifique Group name attribute y su valor de retorno real, la asignación de grupos locales y Default group. memberOf es una recomendación, pero no una asignación garantizada para cada esquema.
El servidor está creado, pero no se utiliza: Verifique la selección, el orden y la herencia del servicio afectado en Authentication > Services.
Google Secure LDAP no establece el enlace: Verifique por separado la versión 3, el puerto 636, Anonymous login desactivado, Append base DN desactivado, el estado del servicio del cliente, las credenciales y el certificado de cliente de Google.
La búsqueda es lenta o devuelve cuentas no deseadas: Limite el DN base al subárbol requerido.
El inicio de sesión funciona, pero la política esperada no: Verifique por separado la configuración específica del usuario, la política de grupo, la asignación de grupos y la regla de firewall o VPN correspondiente. En SSL VPN, incluya todas las políticas de usuario y de grupo aplicables, así como los recursos realmente permitidos; una política de usuario restrictiva no basta por sí sola. El modelo de diagnóstico completo se describe en Solucionar sistemáticamente los errores de autenticación.
El inicio de sesión en el portal funciona, pero en WebAdmin no: En Authentication > Users, verifique la función de administrador asignada manualmente y el Profile. Después, compruebe la selección del servidor en Administrator authentication methods y las reglas de acceso al dispositivo aplicables. No prescinda del acceso local de recuperación antes de haber probado el nuevo método.

Revertir los cambios de forma segura

En caso de una implementación fallida, primero restaure la selección de servidores, el orden y la herencia previamente documentados para cada método afectado. En Firewall authentication methods, también se restaura el Default group anterior. Realice una prueba positiva y otra negativa utilizando el método de autenticación anterior y verifique los registros relevantes.

Elimine el nuevo servidor y grupo LDAP únicamente cuando ya no se utilicen en ningún servicio o política. No limpie los usuarios LDAP creados automáticamente con Purge AD users: la ayuda de SFOS 22 documenta esta función solo para Active Directory. Si es necesario eliminar dichos usuarios, consulte previamente con el soporte de Sophos el procedimiento compatible con su configuración.