Sophos Firewall: migrar eDirectory antes de SFOS 23

SFOS 23.0 deja de admitir el servidor de autenticación eDirectory nativo. Si queda una configuración de servidor eDirectory nativa en el firewall, la actualización de firmware a SFOS 23.0 o posterior falla. Por tanto, antes de actualizar debe funcionar un servidor de autenticación compatible y se deben eliminar por completo las configuraciones nativas de servidor eDirectory y SSO.

eDirectory sigue funcionando en SFOS 22.0 MR2. Este tiempo debe aprovecharse para un funcionamiento en paralelo controlado: añadir el nuevo origen, validar usuarios y grupos con cuentas reales, migrar de forma controlada los servicios de autenticación y eliminar eDirectory solo cuando ya no se necesite la vía de reversión. Los servicios de SSO con Entra ID acoplados se tratan conjuntamente. El resumen de MR2 pone en contexto los demás cambios de esta versión.

Proceso resumido

Inventariar todas las dependencias de eDirectory en servidores, grupos, servicios, reglas, VPN y SSO.
Preparar un backup actual, un administrador local y un acceso de consola documentado.
Elegir como destino LDAP genérico, Active Directory, RADIUS o Microsoft Entra ID SSO según el caso de uso.
Añadir en paralelo el nuevo servidor de autenticación y validar la conexión, los usuarios y los grupos.
Asignar deliberadamente los grupos y las políticas al nuevo origen.
Migrar de forma controlada los servicios en Authentication > Services y probarlos con cuentas reales; tratar conjuntamente los servicios de SSO con Entra ID acoplados.
Solo después de la validación completa, eliminar todas las configuraciones nativas de servidor eDirectory y SSO, crear otro backup e iniciar la actualización a SFOS 23.

No se trata de un cambio que se realice con un único interruptor. El firewall utiliza servidores de autenticación por servicio y en un orden definido. Además, los permisos dependen a menudo de grupos que pueden conservar el mismo nombre visible después de la migración, pero no tienen automáticamente la misma asignación ni el mismo efecto.

Qué depende actualmente de eDirectory

Antes del primer cambio debe quedar claro dónde se utiliza realmente eDirectory. El inventario debe incluir al menos estas áreas:

En Authentication > Servers aparecen los servidores eDirectory y, si corresponde, varios destinos de directorio.
En Authentication > Services se define para cada servicio qué servidores se consultan y en qué orden.
En Authentication > Groups, las políticas de grupo, Default Group y el orden de los grupos pueden determinar los permisos efectivos de un usuario. En Active Directory también intervienen Main Group y las pertenencias adicionales.
Las reglas de firewall, las políticas Web y Application, y Traffic Shaping pueden hacer referencia a usuarios o grupos.
VPN Portal, SSL VPN, Remote Access IPsec, User Portal y Captive Portal tienen rutas de inicio de sesión y autorización independientes.
MFA y los inicios de sesión administrativos pueden depender de los grupos y del orden de autenticación.
Los informes basados en usuarios y la identificación transparente de usuarios siguen necesitando una asignación fiable entre el usuario y la conexión.

Una captura de pantalla del orden actual de servidores, servicios y grupos suele ser más útil que una simple lista de nombres. Para cada grupo importante también conviene anotar al menos un usuario de prueba positivo y otro negativo. De este modo se puede comprobar después no solo quién obtiene acceso, sino también quién es rechazado correctamente.

Elegir el método de destino adecuado

No existe un sustituto universal 1:1 para todos los entornos eDirectory. Una organización puede seguir utilizando el directorio existente mediante LDAP, migrar las identidades a otro directorio o combinar varios métodos de autenticación según el servicio.

Mantener eDirectory mediante LDAP genérico

Si eDirectory sigue existiendo, Sophos Firewall puede consultarlo para los inicios de sesión de usuarios mediante el tipo de servidor compatible LDAP server. Este método no modifica automáticamente el árbol del directorio, pero requiere una nueva configuración LDAP con la Base DN y los atributos de inicio de sesión y de grupo adecuados.

La principal limitación es que el SSO nativo de eDirectory deja de estar disponible a partir de SFOS 23. El servidor LDAP genérico verifica la autenticación, pero no proporciona la identificación transparente de usuarios. Por tanto, los usuarios que antes se identificaban automáticamente necesitan un nuevo flujo de SSO o de inicio de sesión. La descripción completa de los campos está disponible en Conectar un servidor LDAP genérico con Sophos Firewall.

Active Directory

Active Directory es adecuado si los usuarios ya existen en un dominio Windows o se migran deliberadamente a él. En ese caso hay que importar los grupos, volver a revisar Main Group y las políticas, y preparar por separado cualquier identificación transparente de usuarios que se necesite. Conectar Active Directory con Sophos Firewall explica LDAPS, la importación de grupos y las pruebas de los servicios.

STAS comunica de forma transparente los inicios de sesión de dominio Windows al firewall, pero no convierte la configuración de SSO de eDirectory existente. Si se necesita esta vía de identidad, debe planificarse como una migración independiente mediante STAS para Sophos Firewall.

RADIUS

RADIUS es adecuado cuando ya existe un servicio de autenticación central o una pasarela MFA. El servidor RADIUS debe proporcionar al firewall la información necesaria para cada servicio; el modelo de grupos de un directorio no se transfiere automáticamente. El método MFA debe ser compatible con el servicio: por ejemplo, VPN Portal no admite MFA RADIUS basado en challenge. Shared Secret, el atributo de grupo, los timeouts y otras limitaciones se tratan en Configurar un servidor RADIUS en Sophos Firewall.

Microsoft Entra ID SSO

Microsoft Entra ID SSO puede ser útil para los escenarios documentados de portales, administradores y Remote Access. Sin embargo, no sustituye de forma general todas las consultas de usuario y contraseña ni proporciona identificación transparente de usuarios en la LAN. En Remote Access deben coordinarse los servicios relacionados: VPN Portal y SSL VPN utilizan el mismo servidor Entra; con un archivo de aprovisionamiento, esto también se aplica a IPsec. Redirect URIs, los grupos, Conditional Access y los servicios compatibles se describen en Microsoft Entra ID SSO para Sophos Connect y VPN Portal.

La arquitectura de destino puede ser mixta. Por ejemplo, LDAP puede autenticar inicialmente a los usuarios del eDirectory existente, mientras que Remote Access se migra más adelante de forma específica a RADIUS o Entra ID SSO. Lo importante es que cada servicio utilizado disponga de una ruta de destino probada antes de eliminar eDirectory.

Proteger el entorno antes del primer cambio

Antes del cutover deben estar preparados los siguientes elementos:

Un backup de Sophos Firewall actual y cifrado.
Un administrador local cuyo inicio de sesión no dependa de eDirectory ni del nuevo origen externo. En Authentication > Services, Local debe seguir seleccionado en Administrator authentication methods.
Un acceso de consola documentado u otro método de acceso de emergencia al firewall.
Capturas de pantalla o un inventario escrito del orden de servidores, servicios y grupos.
Al menos una cuenta de prueba por cada grupo importante, además de una cuenta que no deba obtener acceso.
Una ventana de mantenimiento, una persona responsable de la decisión y un criterio claro de reversión.

El acceso a WebAdmin se migra en último lugar. Antes hay que comprobar que Local sigue seleccionado y que el inicio de sesión local funciona en una ventana privada del navegador. Así se conserva un acceso independiente si la nueva autenticación externa o su resolución de grupos no funcionan como se esperaba.

Preparar el servidor de destino en paralelo

Primero se añade el nuevo servidor. Durante la configuración inicial se mantiene sin cambios la selección de eDirectory existente; solo al comenzar la prueba piloto se modifica exactamente un método de autenticación que sea fácil de controlar.

Ejemplo: conectar eDirectory como servidor LDAP genérico

En Authentication > Servers > Add, una configuración piloto podría tener este aspecto:

Server type: LDAP server
Server name: EDIR-LDAP-PILOT
Server IP/domain: edir01.example.net
Version: 3
Connection security: SSL/TLS
Port: 636
Bind DN: cn=sfos-bind,ou=service,o=Example
Base DN: ou=users,o=Example
Authentication attribute: por ejemplo, uid, después de comprobar el objeto de usuario
Group name attribute: por ejemplo, groupMembership, después de comprobar el objeto de usuario
Validate server certificate: activado después de establecer la CA emisora como fiable en el firewall

edir01.example.net, Bind DN y Base DN son valores de ejemplo y deben adaptarse al árbol de directorio propio. Con la validación de certificados activada, el FQDN configurado debe coincidir con el certificado del servidor y el firewall debe poder resolverlo. La cuenta de bind solo necesita permisos de lectura sobre el ámbito de directorio necesario.

El objeto de usuario real determina qué atributos de inicio de sesión y de grupo son adecuados. En un entorno eDirectory, por ejemplo, cn o uid pueden ser relevantes para el inicio de sesión y groupMembership para los grupos. Son candidatos que deben comprobarse, no valores universales.

Un objeto de usuario puede consultarse en modo read-only desde un sistema de administración Linux:

LDAPTLS_CACERT='/secure/path/edir-ca.pem' \
ldapsearch -LLL -x \
  -H 'ldaps://edir01.example.net:636' \
  -D 'cn=sfos-bind,ou=service,o=Example' -W \
  -b 'ou=users,o=Example' -s sub \
  '(|(cn=max.muster)(uid=max.muster))' \
  dn objectClass cn uid mail groupMembership

Este comando no debe ejecutarse en la Advanced Shell de Sophos Firewall. -W solicita la contraseña de bind de forma interactiva para que no quede guardada en el historial de la shell. La ruta de LDAPTLS_CACERT, el FQDN, las DN, el filtro y los atributos solicitados deben adaptarse al entorno propio. Si el cliente OpenLDAP local ya confía en la CA mediante su Trust Store o ldap.conf, se puede omitir LDAPTLS_CACERT. De lo contrario, la variable apunta a un bundle de CA en formato PEM que pueda leerse.

Una posible salida tendría este aspecto:

dn: cn=Max Muster,ou=users,o=Example
cn: Max Muster
uid: max.muster
mail: max.muster@example.net
groupMembership: cn=VPN-Mitarbeitende,ou=groups,o=Example

Este es un ejemplo de lectura, no un esquema eDirectory garantizado. Si falta groupMembership o el directorio devuelve otros valores, hay que identificar el atributo real y adaptar a él la configuración del firewall. Después se validan por separado Test connection, un inicio de sesión real y el grupo resultante.

Volver a asignar grupos y políticas

Un inicio de sesión correcto no basta si después el usuario termina en el grupo equivocado. Supongamos que el grupo actual VPN-Mitarbeitende puede utilizar SSL VPN y acceder a aplicaciones internas mediante una regla de usuario. Después de la migración deben responderse al menos estas preguntas:

¿Aparece el usuario de prueba en Authentication > Users con el grupo efectivo esperado? En Active Directory, Main Group y las pertenencias adicionales se comprueban por separado.
¿Está presente el nuevo grupo en Authentication > Groups y ocupa la posición correcta?
¿La configuración de SSL VPN o IPsec hace referencia al nuevo grupo efectivo?
¿El usuario sigue coincidiendo con la regla de firewall prevista y no con una regla más general?
¿Sigue aplicándose la política MFA deseada?

Que dos orígenes muestren nombres de grupo iguales no garantiza ni la misma pertenencia ni la misma prioridad efectiva de grupo. En Active Directory, el orden de los grupos y Main Group pueden influir en VPN, MFA y otras políticas. Los fundamentos se explican en Activar MFA para Sophos Firewall.

Migrar servicio por servicio

En Authentication > Services, los servidores de autenticación se seleccionan por servicio. Por eso no se migra todo al mismo tiempo. Sin embargo, los servicios de SSO con Entra ID acoplados se planifican y validan como una ruta conjunta.

Elegir primero un servicio fácil de controlar y un usuario piloto.
Seleccionar el nuevo servidor para ese servicio y establecer deliberadamente su posición en el orden de servidores.
Aplicar el cambio y probar tanto un inicio de sesión correcto como uno deliberadamente incorrecto.
Comprobar el usuario, el grupo, la entrada de log y la política que se ha aplicado realmente.
Solo entonces migrar el siguiente servicio.

Se comienza con un servicio piloto elegido deliberadamente y fácil de controlar. Después se continúa con las áreas que realmente se utilizan, como Firewall authentication methods, User portal authentication methods, VPN portal authentication methods, SSL VPN authentication methods y Remote Access IPsec. Para Entra ID SSO, los servicios de Remote Access acoplados descritos anteriormente se migran de forma coordinada. Debido al riesgo de bloqueo, Administrator authentication methods se migra en último lugar. La vista general de los portales de Sophos Firewall explica qué portales funcionan por separado y deben ser accesibles.

Si el mismo nombre de usuario existe en los servidores antiguo y nuevo, el orden de los servidores puede ocultar una asignación de grupos incorrecta. Para realizar una prueba controlada, se puede seleccionar temporalmente solo el nuevo servidor para el servicio piloto elegido. Después, el inicio de sesión real y Authentication > Users muestran si el nuevo origen proporciona al usuario el grupo esperado.

Validar con conexiones reales

Test connection confirma la accesibilidad y las credenciales del servidor. La validación solo termina cuando funcionan el servicio real y los permisos asociados.

Para cada grupo relevante, la validación debe demostrar al menos lo siguiente:

Un usuario autorizado puede iniciar sesión en el portal o servicio VPN previsto.
Un usuario no autorizado es rechazado o solo recibe la política restringida prevista.
En Authentication > Users, el usuario y el grupo son correctos.
Log Viewer muestra un evento de autenticación trazable.
Las políticas de firewall, Web y VPN coinciden con la regla esperada.
Los destinos internos son accesibles a través de la ruta de tráfico prevista.
MFA y los roles administrativos se comportan según lo planificado.

Firewall Rule Testing y Log Viewer permite comprobar qué Rule ID se aplica a un usuario y su tráfico. La identificación transparente de usuarios o el SSO deben probarse por separado; un inicio de sesión LDAP correcto no confirma esta ruta.

Vía de reversión durante la fase piloto

Mientras el firewall siga utilizando SFOS 22.0 MR2 y eDirectory no se haya eliminado, la configuración anterior permanece disponible como vía de reversión controlada. Si una prueba piloto falla, se revierten todos los valores modificados para ella: la selección y el orden de los servidores en Authentication > Services, Default Group y el orden de los grupos, así como los miembros VPN y las referencias MFA y de políticas afectados. Después se vuelven a comprobar el inicio de sesión, el grupo y la política.

El backup protege la configuración del firewall, pero no es una migración automática de identidades. Los backups y las importaciones de configuración no convierten ni migran la configuración eDirectory que contienen. Por tanto, un backup de este tipo no es una vía de reversión funcional para eDirectory después de la actualización.

Eliminar eDirectory y habilitar la actualización a SFOS 23

eDirectory solo se elimina después de un periodo de observación definido de antemano. Durante ese periodo, todas las rutas de inicio de sesión utilizadas en producción, cada grupo importante, las conexiones VPN en uso y los procesos administrativos deben haber funcionado sin errores al menos una vez mediante el nuevo origen y en condiciones realistas. Cualquier error de autenticación, grupo o política sin resolver impide autorizar la eliminación.

Para completar la migración:

Comprobar que eDirectory ya no está seleccionado en ningún método de autenticación.
Comparar de nuevo con el inventario las dependencias de grupos, VPN, políticas, MFA, administradores y SSO.
Eliminar del firewall todas las configuraciones nativas de servidor eDirectory y SSO de eDirectory. Un LDAP server genérico recién añadido que consulta el mismo directorio permanece configurado.
Comprobar en Authentication > Servers, Authentication > Services y en el inventario que no queda ninguna configuración ni dependencia nativa de eDirectory.
Crear un nuevo backup cifrado de la configuración depurada.
Revisar la guía general Actualización del firmware de Sophos Firewall: preparación y buenas prácticas, así como las notas actuales de versión, actualización y Known Issues de SFOS 23. Solo entonces se inicia la actualización.

Sophos ha confirmado que la actualización falla cuando queda una configuración de servidor eDirectory nativa y que es necesario eliminarla antes de SFOS 23. Antes de la actualización en producción, también deben revisarse las notas finales de versión, actualización y Known Issues de SFOS 23 para conocer otros detalles.

Errores habituales

Test connection se realiza correctamente, pero el usuario termina en el grupo equivocado: Comprobar Base DN, los atributos de inicio de sesión y de grupo en el objeto de usuario real, así como el orden de los grupos.
La prueba piloto parece funcionar, pero podría seguir utilizando eDirectory: Seleccionar temporalmente solo el nuevo servidor para el servicio piloto controlado y comprobar después el usuario, el grupo y la política.
User Portal funciona, pero VPN no: Comprobar por separado el método de autenticación y el grupo de permisos de cada portal y servicio VPN.
El inicio de sesión LDAP funciona, pero la identificación transparente no: El SSO nativo de eDirectory deja de estar disponible a partir de SFOS 23. LDAP genérico verifica el inicio de sesión, pero no proporciona la identificación transparente.
Después de cambiar el grupo se aplica otra regla de firewall: Comparar el grupo efectivo, el orden de grupos y las referencias directas a usuarios o grupos en las políticas. En Active Directory, comprobar además Main Group y las pertenencias adicionales.
El backup se planifica como una vía de reversión posterior para eDirectory: En SFOS 23 no se migra la configuración eDirectory que contiene; la vía de reversión debe funcionar antes de actualizar.