Ir al contenido
Avanet

Conectar Microsoft AD FS con Sophos Central

Microsoft AD FS puede autenticar en Sophos Central identidades existentes de Active Directory. El proceso se inicia desde el SP: Sophos Central proporciona Entity ID y Callback URL, y AD FS procesa el inicio de sesión como Claims-Aware Relying Party Trust.

AD FS aumenta la carga de gestión propia en comparación con Entra ID o un servicio OIDC administrado. Los certificados, los metadatos, la accesibilidad externa, la alta disponibilidad y el estado de los parches del Federation Service siguen siendo responsabilidad de la organización.

Requisitos

Se necesitan derechos de Super Admin en Central, un servicio AD FS operativo, la autorización del responsable de AD y un dominio verificado. Los administradores y usuarios de Central deben existir en el bosque de AD utilizado; sus direcciones de correo electrónico deben coincidir con las guardadas en Central.

Antes de activar Federated credentials only como opción de inicio de sesión, cada administrador y usuario afectado debe estar asociado a un dominio verificado y a un Identity Provider operativo. De lo contrario, la conversión bloquea esas cuentas. Por ello, una cuenta independiente de Sophos para emergencias y un piloto correcto forman parte de los requisitos, y no son meras medidas posteriores para solucionar problemas.

Antes del cambio en Central se comprueban la URL de metadatos de AD FS, los certificados de Federation Service y la resolución externa de nombres. Sophos muestra https://login.microsoftonline.com/<TenantDomainName>/FederationMetadata/2007-06/FederationMetadata.xml como formato de metadatos; sin embargo, para un servicio clásico propio de AD FS se utiliza la URL de FederationMetadata que publica realmente el servicio propio. Un ejemplo de Microsoft Online no se aplica sin más a AD FS local.

Preparar el dominio y el proveedor en Central

En Global Settings > Access Control > Sign-in and Identity > Sophos sign-in > Verify domains, primero se utiliza Add domain para guardar el dominio y su descripción. Central muestra entonces el registro TXT en Verify domain ownership. Se añade exactamente a la zona DNS pública. Tras la propagación, se vuelve a Verify domains y se selecciona Verify domain ownership > Verify. La propagación puede tardar hasta 24 horas; una verificación correcta es válida durante un año y puede renovarse antes.

A continuación:

  1. Abrir Federated identity providers y crear un proveedor nuevo.
  2. Introducir un nombre sin caracteres especiales problemáticos y una descripción.
  3. Seleccionar Type: Microsoft AD FS y el Vendor adecuado.
  4. Introducir la AD FS metadata URL comprobada.
  5. Seleccionar el dominio verificado.
  6. Definir si AD FS obliga a utilizar MFA o si Central exige su propia MFA después de iniciar sesión correctamente en AD FS.
  7. Guardar y copiar del proveedor la Entity ID y la Callback URL generadas por Central.

El proveedor todavía no se activa en todo el tenant como única vía de inicio de sesión.

Crear Relying Party Trust en AD FS

En el servidor de AD FS se inicia el asistente Add Relying Party Trust mediante Server Manager > Tools > AD FS Management:

  1. Seleccionar Claims Aware.
  2. Utilizar Enter data about the relying party manually.
  3. Introducir un Display Name inequívoco.
  4. Seleccionar AD FS profile; continuar en el paso del certificado si no existen requisitos de cifrado adicionales.
  5. En Configure URL, activar Enable support for the WS-Federation Passive protocol.
  6. Introducir la Callback URL copiada de Central como WS-Federation Passive Protocol URL.
  7. En Configure Identifiers, añadir la Entity ID copiada de Central como Relying Party Trust Identifier.
  8. Configurar MFA de acuerdo con el diseño propio de AD FS y Conditional Access.
  9. Para el piloto, autorizar solo a los usuarios necesarios. Sophos muestra Permit all users to access this relying party como vía predeterminada; un grupo piloto controlado resulta más seguro.
  10. Finalizar el Trust y abrir directamente el diálogo Edit Claim Rules.

Emitir correctamente los Claims

En Issuance Transform Rules > Add rule se selecciona Send LDAP Attributes as Claims. Se utiliza Active Directory como Attribute Store. La asignación es la siguiente:

LDAP AttributeOutgoing Claim Type
E-mail-AddressesName ID
Given-NameGiven Name
SurnameSurname
E-mail-AddressesE-mail Address

El valor de correo electrónico es la asociación decisiva con Central. Las direcciones vacías, duplicadas o diferentes se corrigen antes del despliegue. Incluso si el inicio de sesión en AD FS se completa correctamente, sin un Claim de correo electrónico coincidente no se accede de forma fiable a la cuenta correcta de Central.

Activar y probar el proveedor

Después de crear el Trust de AD FS, el proveedor se activa en Central mediante Turn on. En Sophos sign-in se mantiene inicialmente la posibilidad de elegir entre credenciales de Sophos e inicio de sesión federado. Mediante Add custom rule, se añade el administrador de emergencia independiente a Selected Users, se selecciona Sophos Central Admin email and password como método de acceso y se guarda la regla. A continuación, se prueba en una sesión privada separada del navegador. Sophos también añade automáticamente a una regla personalizada de este tipo al administrador que cambia los ajustes de inicio de sesión. Esta protección automática no sustituye a una cuenta de emergencia elegida y documentada deliberadamente.

La prueba comienza en la página de inicio de sesión de Sophos e incluye lo siguiente:

  • un administrador normal,
  • un Super Admin,
  • MFA de AD FS o MFA de Central,
  • un usuario sin autorización para el Trust,
  • cierre de sesión y nuevo inicio de sesión,
  • fecha de caducidad, responsable y prueba de sustitución prevista del certificado de firma de AD FS,
  • una cuenta de emergencia independiente con inicio de sesión de Sophos.

La prueba es correcta cuando cada usuario autorizado llega, después de AD FS y MFA, a la cuenta de Central esperada con la función prevista, el usuario no autorizado es rechazado y el acceso de emergencia sigue funcionando.

Solo entonces se activa Federated credentials only. En ese momento, todas las cuentas afectadas deben estar asociadas a un dominio verificado y al proveedor activado. Después de guardar, se vuelven a probar el inicio de sesión federado y la regla personalizada en sesiones privadas; una sesión de administrador ya abierta no es por sí sola una prueba contra el bloqueo.

Solución de problemas

  • No se puede acceder a Metadata URL: comprobar DNS, certificado, TLS, Web Application Proxy y Federation Service.
  • Relying Party Identifier no es válido: copiar Entity ID exactamente desde Central y comprobar que no haya espacios invisibles.
  • Error de Callback: comparar la WS-Federation Passive URL con la Callback URL actual de Central.
  • AD FS acepta al usuario, pero Central no: comprobar los Claims de correo electrónico y Name ID, así como la dirección de correo electrónico de Central.
  • Falta MFA o se solicita dos veces: comprobar conjuntamente las reglas de AD FS y la selección IdP enforced MFA.
  • El proveedor falla después de cambiar el certificado: actualizar los metadatos, el certificado de firma y la confianza de Central y volver a realizar un piloto.

El proceso general para Sign-in Rules, la recuperación de MFA y el cambio controlado a Federated credentials only se describe en Proteger el inicio de sesión de Sophos Central con MFA, Passkeys e IdP.

Preguntas frecuentes

¿Puede utilizarse el mismo Trust de AD FS sin Claims?

No. Central necesita en particular una identidad de correo electrónico coherente. El Trust se configura como Claims-Aware y emite Name ID, nombre, apellido y dirección de correo electrónico tal como se documenta.

¿Debe utilizarse Permit all users?

Para un primer despliegue seguro es mejor un grupo piloto limitado. La autorización solo se amplía al grupo de usuarios deseado cuando funcionan los Claims, MFA y la vía alternativa.