Share via

Procedimientos recomendados para proteger los Servicios de federación de Active Directory

  • Artículo

En este documento se proporcionan los procedimientos recomendados para planear e implementar de forma segura los Servicios de federación de Active Directory (AD FS) y Proxy de aplicación web (WAP). Contiene recomendaciones para configuraciones de seguridad adicionales, casos de uso específicos y requisitos de seguridad.

Este documento se aplica a AD FS y WAP en Windows Server 2012 R2, 2016 y 2019. Estas recomendaciones se pueden usar para una red local o en un entorno hospedado en la nube, como Microsoft Azure.

Topología de implementación estándar

Para la implementación en entornos locales, se recomienda una topología de implementación estándar que consta de:

  • Uno o varios servidores de AD FS en la red corporativa interna.
  • Uno o varios servidores Proxy de aplicación web (WAP) en una red perimetral o extranet.

En cada capa, AD FS y WAP, se coloca un equilibrador de carga de hardware o software delante de la granja de servidores y se controla el enrutamiento del tráfico. Los firewalls se colocan delante de la dirección IP externa del equilibrador de carga, según sea necesario.

A diagram depicting a standard A D F S topology.

Nota:

AD FS requiere el funcionamiento de un controlador de dominio de plena escritura en lugar de un controlador de dominio de solo lectura. Si una topología planeada incluye un controlador de dominio de solo lectura, ese controlador se puede usar para la autenticación, pero el procesamiento de notificaciones LDAP requerirá una conexión con el controlador de dominio de escritura.

Protección de los servidores de AD FS

A continuación se muestra una lista de sugerencias y procedimientos recomendados para reforzar y proteger la implementación de AD FS:

  • Asegúrese de que solo los administradores de Active Directory y los administradores de AD FS tengan derechos de administrador para el sistema de AD FS.
  • Reduzca la pertenencia a grupos de administradores locales en todos los servidores de AD FS.
  • Requiera que todos los administradores de la nube usen la autenticación multifactor (MFA).
  • Funcionalidad de administración mínima a través de los agentes.
  • Limite el acceso en la red a través del firewall de host.
  • Asegúrese de que los administradores de AD FS usen estaciones de trabajo de administración para proteger sus credenciales.
  • Coloque los objetos de equipo de servidor de AD FS en una unidad organizativa de nivel superior que no hospede otros servidores.
  • Todos los GPO que se apliquen a los servidores de AD FS deben aplicarse solo a ellos y no a otros servidores. Esto limita la posible elevación de privilegios mediante la modificación del GPO.
  • Asegúrese de que los certificados instalados estén protegidos frente a robos (no los almacene en un recurso compartido de la red) y establezca un aviso de calendario para asegurarse de que se renueven antes de expirar (un certificado expirado interrumpe la autenticación de federación). Asimismo, se recomienda proteger las claves o certificados de firma en un módulo de seguridad de hardware (HSM) asociado a AD FS.
  • Establezca el registro en el nivel más alto y envíe los registros de AD FS (y de seguridad) a una instancia de SIEM para correlacionarlos con la autenticación de AD, así como con AzureAD (o similar).
  • Quite las características de Windows y los protocolos innecesarios.
  • Use una contraseña compleja larga (>25 caracteres) para la cuenta de servicio de AD FS. Se recomienda usar una cuenta de servicio administrada de grupo (gMSA) como cuenta de servicio, ya que elimina la necesidad de administrar la contraseña de la cuenta de servicio a lo largo del tiempo mediante su administración automática.
  • Actualice a la última versión de AD FS para obtener mejoras de seguridad y registro (como siempre, pruebe primero).

Puertos necesarios

En el diagrama siguiente se muestran los puertos de firewall que deben habilitarse entre los componentes de la implementación de AD FS y WAP. Si la implementación no incluye Microsoft Entra ID ni Office 365, pueden omitirse los requisitos de sincronización.

Nota:

El puerto 49443 solo es necesario si se usa la autenticación de certificados de usuario, que es opcional para Microsoft Entra ID y Office 365.

A diagram showing the required ports and protocols for an A D F S deployment.

Nota:

El puerto 808 (Windows Server 2012 R2) o el puerto 1501 (Windows Server 2016 y versiones posteriores) es Net. Puerto TCP que AD FS usa para el punto de conexión WCF local para transferir los datos de configuración al proceso de servicio y PowerShell. Para ver este puerto, ejecute Get-AdfsProperties y seleccione NetTcpPort. Se trata de un puerto local que no es necesario abrir en el firewall, pero que se mostrará en un examen de puertos.

Comunicación entre servidores de federación

Los servidores de federación de una granja de AD FS se comunican con otros servidores de la granja y con los servidores Proxy de aplicación web (WAP) a través del puerto HTTP 80 para la sincronización de la configuración. Asegurarse de que solo estos servidores puedan comunicarse entre sí y ningún otro pueda hacerlo es una medida de defensa a fondo.

Las organizaciones pueden lograr este estado mediante la configuración de reglas de firewall en cada servidor. Las reglas solo deben permitir la comunicación entrante desde las direcciones IP de los servidores de la granja y los servidores WAP. Algunos equilibradores de carga de red (NLB) usan el puerto HTTP 80 para sondear el estado de los servidores de federación individuales. Asegúrese de incluir las direcciones IP de NLB en las reglas de firewall configuradas.

Microsoft Entra Connect y Servidores de federación AD FS/WAP

En esta tabla se describen los puertos y protocolos que son necesarios para la comunicación entre el servidor de Microsoft Entra Connect y servidores de federación AD FS/WAP.

Protocolo Puertos Descripción
HTTP 80 (TCP/UDP) Se usa para descargar CRL (listas de revocación de certificados) para comprobar certificados SSL.
HTTPS 443 (TCP/UDP) Se usa para sincronizar con Microsoft Entra ID.
WinRM 5985 Agente de escucha de WinRM.

Servidores de federación y WAP

En esta tabla se describen los puertos y protocolos que son necesarios para la comunicación entre los servidores de federación y los servidores WAP.

Protocolo Puertos Descripción
HTTPS 443 (TCP/UDP) Se usa para autenticación.

Usuarios y WAP

En esta tabla se describen los puertos y protocolos que son necesarios para la comunicación entre los usuarios y los servidores WAP.

Protocolo Puertos Descripción
HTTPS 443 (TCP/UDP) Se usa para la autenticación de dispositivos.
TCP 49443 (TCP) Se usa para la autenticación de certificados.

Para obtener información sobre los puertos y los protocolos requeridos en las implementaciones híbridas, consulte Puertos de conexión de referencia híbrida.

Para obtener información sobre los puertos y los protocolos requeridos para una implementación de Microsoft Entra ID y Office 365, consulte el documento Intervalos de direcciones IP y direcciones URL de Office 365.

Puntos de conexión habilitados

Al instalar AD FS y WAP, se habilita un conjunto predeterminado de puntos de conexión de AD FS en el servicio de federación y en el proxy. Estos valores predeterminados se eligieron en función de los escenarios requeridos y usados con más asiduidad y no es necesario cambiarlos.

Conjunto mínimo de puntos de conexión habilitados en el proxy para Microsoft Entra ID u Office 365 (opcional)

Las organizaciones que implementan AD FS y WAP solo para escenarios de Microsoft Entra ID y Office 365 pueden limitar aún más el número de puntos de conexión de AD FS habilitados en el proxy para lograr una superficie expuesta a ataques mucho menor. A continuación se muestra la lista de puntos de conexión que deben habilitarse en el proxy en estos escenarios:

Punto de conexión Propósito
/adfs/ls/ Los flujos de autenticación basados en el explorador y las versiones actuales de Microsoft Office usan este punto de conexión para la autenticación de Microsoft Entra ID y Office 365
/adfs/services/trust/2005/usernamemixed Se usa para clientes de Exchange Online con Office anteriores a la actualización de mayo de 2015 para Office 2013. Los clientes posteriores usan el punto de conexión pasivo \adfs\ls.
/adfs/services/trust/13/usernamemixed Se usa para clientes de Exchange Online con Office anteriores a la actualización de mayo de 2015 para Office 2013. Los clientes posteriores usan el punto de conexión pasivo \adfs\ls.
/adfs/oauth2/ Se usa para cualquier aplicación moderna (local o en la nube) que haya configurado para autenticarse directamente en AD FS (es decir, no a través de Microsoft Entra ID).
/adfs/services/trust/mex Se usa para clientes de Exchange Online con Office anteriores a la actualización de mayo de 2015 para Office 2013. Los clientes posteriores usan el punto de conexión pasivo \adfs\ls.
/federationmetadata/2007-06/federationmetadata.xml Requisito para cualquier flujo pasivo; lo usan Office 365 o Microsoft Entra ID para comprobar los certificados de AD FS.

Los puntos de conexión de AD FS pueden deshabilitarse en el proxy mediante el cmdlet de PowerShell siguiente:

Set-AdfsEndpoint -TargetAddressPath <address path> -Proxy $false

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/certificatemixed -Proxy $false

Protección ampliada para la autenticación

La protección ampliada para la autenticación es una característica que mitiga los ataques de intermediario (MITM) y se habilita de forma predeterminada con AD FS. La configuración puede comprobarse mediante el cmdlet de PowerShell siguiente:

Get-ADFSProperties

La propiedad es ExtendedProtectionTokenCheck. La configuración predeterminada es Permitir, de modo que puedan obtenerse las ventajas de seguridad sin problemas de compatibilidad con exploradores que no admitan la funcionalidad.

Control de la congestión para proteger el servicio de federación

El proxy de servicio de federación (parte del WAP) proporciona control de congestión para proteger el servicio de AD FS frente a desbordamientos de solicitudes. El proxy de aplicación web rechazará las solicitudes de autenticación de clientes externos si el servidor de federación está sobrecargado, al detectarse por la latencia entre el proxy de aplicación web y el servidor de federación. Esta característica se configura de forma predeterminada con un nivel de umbral de latencia recomendado. Para comprobar la configuración, puede hacer lo siguiente:

  1. En el equipo del proxy de aplicación web, inicia una ventana de comando con privilegios elevados.
  2. Vaya al directorio de AD FS, en %WINDIR%\adfs\config.
  3. Cambie la configuración de control de congestión de los valores predeterminados a <congestionControl latencyThresholdInMSec="8000" minCongestionWindowSize="64" enabled="true" />.
  4. Guarde y cierre el archivo.
  5. Para reiniciar el servicio de AD FS, ejecuta net stop adfssrv y luego net start adfssrv.

Para obtener instrucciones sobre esta funcionalidad, consulte Configurar acceso a extranet para AD FS en Windows Server 2012 R2.

Comprobaciones de solicitudes HTTP estándar en el proxy

El proxy también realiza las siguientes comprobaciones estándar en todo el tráfico:

  • El propio FS-P se autentica en AD FS a través de un certificado de corta duración. En un escenario de riesgo potencial de los servidores de red perimetral, AD FS puede "revocar la confianza del proxy" para que deje de confiar en las solicitudes entrantes de servidores proxy potencialmente en riesgo. Al revocar la confianza del proxy, se revoca el certificado propio de cada proxy a fin de que no se pueda autenticar correctamente para ningún fin en el servidor de AD FS.
  • FS-P finaliza todas las conexiones y crea una nueva conexión HTTP con el servicio de AD FS en la red interna. Esto proporciona un búfer de nivel de sesión entre los dispositivos externos y el servicio AD FS. El dispositivo externo nunca se conecta directamente con el servicio de AD FS.
  • FS-P realiza una validación de solicitudes HTTP que filtra específicamente los encabezados HTTP que no requiere el servicio de AD FS.

Asegúrese de que todos los servidores de AD FS y WAP reciban las actualizaciones más recientes. La recomendación de seguridad más importante en relación con la infraestructura de AD FS es que se asegure de contar con los medios para mantener al día los servidores de AD FS y WAP con todas las actualizaciones de seguridad, así como las actualizaciones opcionales especificadas como importantes para AD FS en esta página.

La manera recomendada para que los clientes de Microsoft Entra supervisen y mantengan actualizada su infraestructura es a través de Microsoft Entra Connect Health para AD FS, una característica de Microsoft Entra ID P1 o P2. Microsoft Entra Connect Health incluye monitores y alertas que se desencadenan si a una máquina de AD FS o WAP le falta alguna de las actualizaciones importantes específicas para AD FS y WAP.

Para más información sobre el seguimiento de estado de AD FS, consulte Instalar los agentes de Microsoft Entra Connect Health.

Procedimiento recomendado para proteger y supervisar la confianza de AD FS con Microsoft Entra ID

Al federar AD FS con Microsoft Entra ID, es fundamental que la configuración de la federación (relación de confianza configurada entre AD FS y Microsoft Entra ID) se supervise de forma estrecha y que se capture cualquier actividad inusual o sospechosa. Para ello, se recomienda configurar alertas y recibir notificaciones cada vez que se realicen cambios en la configuración de la federación. Para aprender a configurar alertas, consulte Supervisión de cambios en la configuración de federación.

Configuraciones de seguridad adicionales

Para ofrecer más protección, se pueden configurar las funcionalidades adicionales siguientes.

Protección de bloqueo de extranet "temporal" para cuentas

Con la característica de bloqueo de extranet en Windows Server 2012 R2, un administrador de AD FS puede establecer un número máximo permitido de solicitudes de autenticación erróneas (ExtranetLockoutThreshold) y un período de tiempo de observation window (ExtranetObservationWindow). Cuando se alcanza este número máximo (ExtranetLockoutThreshold) de solicitudes de autenticación, AD FS deja de intentar autenticar las credenciales de cuenta proporcionadas en AD FS durante el período de tiempo establecido (ExtranetObservationWindow). Esta acción protege a esta cuenta frente a un bloqueo de cuenta de AD, es decir, protege la cuenta para que no pierda acceso a los recursos corporativos que se basan en AD FS para la autenticación del usuario. Esta configuración se aplica a todos los dominios que el servicio de AD FS puede autenticar.

Puede usar el comando de Windows PowerShell siguiente para establecer el bloqueo de extranet de AD FS (ejemplo):

Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow ( new-timespan -Minutes 30 )

Como referencia, consulte Configuración del bloqueo de extranet de AD FS para obtener más información sobre esta característica.

Deshabilitar los puntos de conexión de Windows WS-Trust del proxy de la extranet

Los puntos de conexión de Windows WS-Trust (/adfs/services/trust/2005/windowstransport y /adfs/services/trust/13/windowstransport) solo están diseñados como puntos de conexión accesibles desde la intranet que usan el enlace WIA en HTTPS. Exponerlos a la extranet podría permitir que las solicitudes en estos puntos de conexión omitan las protecciones de bloqueo. Estos puntos de conexión deben deshabilitarse en el proxy (es decir, deshabilitados de la extranet) a fin de proteger el bloqueo de la cuenta de AD mediante el uso de los comandos de PowerShell siguientes. Deshabilitar estos puntos de conexión en el proxy no tiene ningún efecto conocido en el usuario final.

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/2005/windowstransport -Proxy $false

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/windowstransport -Proxy $false

Nota

Si la granja de AD FS se ejecuta en bases de datos internas de Windows (WID) y tiene un servidor secundario de AD FS, después de deshabilitar los puntos de conexión en el servidor primario, espere a que se realice la operación SYNC en los nodos secundarios antes de reiniciar el servicio de AD FS en ellos. Use el comando de PowerShell Get-AdfsSyncProperties en el nodo secundario para realizar el seguimiento del último proceso SYNC.

Diferenciar las directivas de acceso a la intranet y a la extranet

AD FS tiene la capacidad de diferenciar las directivas de acceso para las solicitudes que se originan en la red corporativa local frente a aquellas que proceden de Internet a través del proxy. Esta diferenciación se puede realizar por aplicación o de forma global. Para aplicaciones de alto valor empresarial o aplicaciones con información confidencial, considere la posibilidad de solicitar la autenticación multifactor. La autenticación multifactor se puede configurar mediante el complemento de administración de AD FS.

Requerir autenticación multifactor (MFA)

AD FS puede configurarse de forma que requiera una autenticación sólida (como la autenticación multifactor) específicamente para las solicitudes que entren a través del proxy, para aplicaciones individuales y para el acceso condicional a Microsoft Entra ID u Office 365 y recursos locales. Entre los métodos admitidos de MFA se incluyen Microsoft Azure MF y proveedores de terceros. Se solicita al usuario que proporcione información adicional (por ejemplo, un texto SMS que contiene un código de un solo uso) y AD FS funciona con el complemento específico del proveedor para permitir el acceso.

Los proveedores de MFA externos admitidos incluyen los enumerados en la página Configurar métodos de autenticación adicionales para AD FS.

Habilitar la protección para evitar la derivación de la autenticación multifactor de Microsoft Entra en la nube cuando se federa con Microsoft Entra ID.

Habilite la protección para evitar la omisión de la autenticación multifactor de Microsoft Entra en la nube cuando se federe con Microsoft Entra ID y use la autenticación multifactor de Microsoft Entra como su autenticación multifactor para sus usuarios federados.

Habilitar la protección para un dominio federado en su inquilino de Microsoft Entra garantizará que la autenticación multifactor de Microsoft Entra se realice siempre que un usuario federado acceda a una aplicación que se rige por una directiva de acceso condicional que requiere MFA. Esto incluye la realización de la autenticación multifactor Microsoft Entra incluso cuando el proveedor de identidad federada ha indicado (a través de reclamaciones de token federado) que se ha realizado MFA en los locales. La aplicación de la autenticación multifactor de Microsoft Entra asegura que una cuenta comprometida en las instalaciones no pueda eludir la autenticación multifactor de Microsoft Entra imitando que una autenticación multifactor ya ha sido realizada por el proveedor de identidad, y es muy recomendable a menos que usted realice MFA para sus usuarios federados utilizando un proveedor de MFA de terceros.

La protección se puede habilitar mediante una nueva configuración de seguridad, federatedIdpMfaBehavior, que se expone como parte de la MS Graph API de federación interna o los cmdlets de PowerShell de MS Graph. La configuración federatedIdpMfaBehavior determina si Microsoft Entra ID acepta la MFA realizada por el proveedor de identidades federado cuando un usuario federado accede a una aplicación que se rige por una directiva de acceso condicional que requiere MFA.

Los administradores pueden elegir uno de los valores siguientes:

Propiedad Descripción
acceptIfMfaDoneByFederatedIdp Microsoft Entra ID acepta MFA si lo realiza el proveedor de identidad. Si no, realiza la autenticación multifactor Microsoft Entra.
enforceMfaByFederatedIdp Microsoft Entra ID acepta MFA si lo realiza el proveedor de identidad. En caso contrario, redirige la solicitud al proveedor de identidades para realizar MFA.
rejectMfaByFederatedIdp Microsoft Entra ID siempre realiza la autenticación multifactor de Microsoft Entra y rechaza la MFA si la realiza el proveedor de identidad.

Para habilitar la protección, establezca federatedIdpMfaBehavior en rejectMfaByFederatedIdp mediante el comando siguiente.

MS GRAPH API

 PATCH /domains/{domainsId}/federationConfiguration/{internalDomainFederationId} 

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp" 

}

Ejemplo:

PATCH /domains/contoso.com/federationConfiguration/2a8ce608-bb34-473f-9e0f-f373ee4cbc5a 

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"

Ejemplo:

Update-MgDomainFederationConfiguration -DomainId <domainsId> -InternalDomainFederationId <internalDomainFederationId> federatedIdpMfaBehavior "rejectMfaByFederatedIdp"

Ejemplo:

Update-MgDomainFederationConfiguration -DomainId “contoso.com” -InternalDomainFederationId “2a8ce608-bb34-473f-9e0f-f373ee4cbc5a” federatedIdpMfaBehavior "rejectMfaByFederatedIdp"

Módulo de seguridad de hardware (HSM)

Con la configuración predeterminada, las claves que AD FS usa para firmar tokens nunca salen de los servidores de federación en la intranet. Nunca están presentes en la red perimetral ni en las máquinas proxy. Opcionalmente, para ofrecer más protección, se recomienda proteger estas claves en un módulo de seguridad de hardware (HSM) asociado a AD FS. Microsoft no cuenta con ningún producto HSM propio, pero hay varios en el mercado compatibles con AD FS. Para implementar esta recomendación, siga las instrucciones del proveedor destinadas a crear certificados X509 para la firma y el cifrado y, a continuación, use los commandlets de PowerShell de la instalación de AD FS y especifique los certificados personalizados de la siguiente forma:

Install-AdfsFarm -CertificateThumbprint <String> -DecryptionCertificateThumbprint <String> -FederationServiceName <String> -ServiceAccountCredential <PSCredential> -SigningCertificateThumbprint <String>

donde:

  • CertificateThumbprint es su certificado SSL
  • SigningCertificateThumbprint es su certificado de firma (con clave HSM protegida)
  • DecryptionCertificateThumbprint es su certificado de cifrado (con clave HSM protegida)