Procedimientos recomendados para proteger los Servicios de federación de Active Directory
En este documento se proporcionan procedimientos recomendados para la planeación e implementación seguras de Servicios de federación de Active Directory (AD FS) (AD FS) y Application Proxy web. 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 de Application Proxy web (WAP) en una red perimetral o extranet.
En cada capa, AD FS y WAP, un equilibrador de carga de hardware o software se coloca delante de la granja de servidores y 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.
Nota
AD FS requiere que un controlador de dominio grabable completo funcione en lugar de un controlador de dominio Read-Only. Si una topología planeada incluye un controlador de dominio de Read-Only, el controlador de dominio Read-Only se puede usar para la autenticación, pero el procesamiento de notificaciones LDAP requerirá una conexión con el controlador de dominio grabable.
Protección de los servidores de AD FS
A continuación se muestra una lista de procedimientos recomendados y recomendaciones para proteger y proteger la implementación de AD FS.
- Asegúrese de que solo los administradores de Active Directory y los administradores de AD FS tienen derechos de administrador para el sistema de AD FS.
- Reduzca la pertenencia a grupos de administradores locales en todos los servidores de AD FS.
- Requerir que todos los administradores de la nube usen Multi-Factor Authentication (MFA).
- Funcionalidad de administración mínima a través de agentes.
- Limite el acceso en la red a través del firewall de host.
- Asegúrese de que los administradores de AD FS usan estaciones de trabajo de Administración para proteger sus credenciales.
- Coloque 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 aplican a los servidores de AD FS solo deben aplicarse a ellos y no a otros servidores. Esto limita la posible elevación de privilegios a través de la modificación del GPO.
- Asegúrese de que los certificados instalados están protegidos contra el robo (no los almacenes en un recurso compartido de la red) y establezca un aviso de calendario para asegurarse de que se renuevan antes de expirar (el certificado expirado interrumpe la autenticación de federación). Además, se recomienda proteger las claves o certificados de firma en un módulo de seguridad de hardware (HSM) conectado a AD FS.
- Establezca el registro en el nivel más alto y envíe los registros de AD FS (& seguridad) a un SIEM para correlacionar con la autenticación de AD, así como AzureAD (o similar).
- Eliminación de protocolos innecesarios & Windows características
- Use una contraseña larga (>25 caracteres) compleja 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 versión más reciente de AD FS para mejorar la seguridad y el registro (como siempre, pruebe primero).
Puertos necesarios
En el diagrama siguiente se muestran los puertos de firewall que se deben habilitar entre y entre los componentes de la implementación de AD FS y WAP. Si la implementación no incluye Azure AD o Office 365, se pueden omitir los requisitos de sincronización.
Tenga en cuenta que el puerto 49443 solo es necesario si se usa la autenticación de certificados de usuario, que es opcional para Azure AD y Office 365.
Nota
El puerto 808 (Windows Server 2012R2) o el puerto 1501 (Windows Server 2016+) es el puerto net.TCP que usa AD FS para el punto de conexión WCF local para transferir los datos de configuración al proceso de servicio y PowerShell. Este puerto se puede ver ejecutando Get-AdfsProperties | Seleccione NetTcpPort. Se trata de un puerto local que no tendrá que abrirse 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 de servidores y los servidores web de Application Proxy (WAP) a través del puerto HTTP 80 para la sincronización de configuración. Asegúrese de que solo estos servidores pueden comunicarse entre sí y ningún otro es una medida de defensa en profundidad.
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 de servidores y los servidores WAP. Tenga en cuenta que algunos equilibradores de carga de red (NLB) usan el puerto HTTP 80 para sondear el estado en servidores de federación individuales. Asegúrese de incluir las direcciones IP de NLB en las reglas de firewall configuradas.
Azure AD Conectar y servidores de federación/WAP
En esta tabla se describen los puertos y protocolos que son necesarios para la comunicación entre el servidor de Azure AD Connect y servidores de federación/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 Azure AD. |
| WinRM | 5985 | Agente de escucha de WinRM |
Servidores wap y federación
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. |
WAP y usuarios
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 protocolos necesarios para las implementaciones híbridas, consulte el documento aquí.
Para obtener información sobre los puertos y protocolos necesarios para una implementación de Azure AD y Office 365, consulte el documento aquí.
Puntos de conexión habilitados
Cuando se instala 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 más comunes necesarios y usados y no es necesario cambiarlos.
[Opcional] Conjunto mínimo de puntos de conexión proxy habilitado para Azure AD o Office 365
Las organizaciones que implementan AD FS y WAP solo para Azure AD y escenarios de 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 de ataque más mínima. 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 explorador y las versiones actuales de Microsoft Office usan este punto de conexión para Azure AD y la autenticación Office 365 |
| /adfs/services/trust/2005/usernamemixed | Se usa para Exchange Online con clientes de Office anteriores a Office actualización de mayo de 2015 de mayo de 2015. Los clientes posteriores usan el punto de conexión pasivo \adfs\ls. |
| /adfs/services/trust/13/usernamemixed | Se usa para Exchange Online con clientes de Office anteriores a Office actualización de mayo de 2015 de mayo de 2015. 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 Azure AD). |
| /adfs/services/trust/mex | Se usa para Exchange Online con clientes de Office anteriores a Office actualización de mayo de 2015. Los clientes posteriores usan el punto de conexión pasivo \adfs\ls. |
| /adfs/ls/federationmetadata/2007-06/federationmetadata.xml | Requisito de cualquier flujo pasivo; y lo usan Office 365 o Azure AD para comprobar los certificados de AD FS. |
Los puntos de conexión de AD FS se pueden deshabilitar en el proxy mediante el siguiente cmdlet de PowerShell:
Set-AdfsEndpoint -TargetAddressPath <address path> -Proxy $false
Por ejemplo:
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 hombre en el medio (MITM) y está habilitado de forma predeterminada con AD FS.
Para comprobar la configuración, puede hacer lo siguiente:
La configuración se puede comprobar mediante el siguiente cmdlet de PowerShell.
Get-ADFSProperties
La propiedad es ExtendedProtectionTokenCheck. La configuración predeterminada es Permitir, de modo que se puedan lograr las ventajas de seguridad sin los problemas de compatibilidad con los exploradores que no admiten la funcionalidad.
Control de congestión para proteger el servicio de federación
El proxy del servicio de federación (parte de WAP) proporciona control de congestión para proteger el servicio de AD FS frente a una inundación de solicitudes. El Application Proxy web rechazará las solicitudes de autenticación de cliente externo si el servidor de federación está sobrecargado según lo detectado por la latencia entre el Application Proxy 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:
- En el equipo del proxy de aplicación web, inicia una ventana de comando con privilegios elevados.
- Vaya al directorio de AD FS, en %WINDIR%\adfs\config.
- Cambie la configuración del control de congestión de sus valores predeterminados a
<congestionControl latencyThresholdInMSec="8000" minCongestionWindowSize="64" enabled="true" />. - Guarde y cierre el archivo.
- Para reiniciar el servicio de AD FS, ejecuta
net stop adfssrvy luegonet start adfssrv. Para su referencia, puede encontrar instrucciones sobre esta funcionalidad aquí.
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 sospecha de riesgo de servidores dmz, AD FS puede "revocar la confianza de proxy" para que ya no confíe en las solicitudes entrantes de servidores proxy potencialmente comprometidos. Al revocar la confianza de proxy, se revoca el certificado propio de cada proxy para que no se pueda autenticar correctamente para cualquier propósito en el servidor de AD FS.
- FS-P finaliza todas las conexiones y crea una nueva conexión HTTP al servicio AD FS en la red interna. Esto proporciona un búfer de nivel de sesión entre dispositivos externos y el servicio AD FS. El dispositivo externo nunca se conecta directamente al servicio AD FS.
- FS-P realiza la validación de solicitudes HTTP que filtra específicamente los encabezados HTTP que no son necesarios para el servicio AD FS.
Configuraciones de seguridad recomendadas
Asegúrese de que todos los servidores de AD FS y WAP reciben las actualizaciones más recientes. La recomendación de seguridad más importante para la infraestructura de AD FS es asegurarse de que tiene un medio para mantener actualizados los servidores 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 Azure AD supervisen y mantengan actualizada su infraestructura se realiza a través de Azure AD Conectar Health para AD FS, una característica de Azure AD Premium. Azure AD Conectar Health incluye monitores y alertas que se desencadenan si falta una máquina de AD FS o WAP una de las actualizaciones importantes específicamente para AD FS y WAP.
Puede encontrar información sobre cómo instalar Azure AD Conectar Health para AD FS aquí.
Procedimiento recomendado para proteger y supervisar la confianza de AD FS con Azure AD
Al federar AD FS con Azure AD, es fundamental que la configuración de la federación (relación de confianza configurada entre AD FS y Azure AD) 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 la federación.
Configuraciones de seguridad adicionales
Se pueden configurar las siguientes funcionalidades adicionales para proporcionar más protección.
Protección de bloqueo de extranet "soft" 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 observation windowperíodo de tiempo (ExtranetObservationWindow). Cuando se alcanza este número máximo (ExtranetLockoutThreshold) de las 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 esta cuenta de un bloqueo de cuenta de AD, es decir, protege esta cuenta de la pérdida de acceso a los recursos corporativos que dependen de AD FS para la autenticación del usuario. Esta configuración se aplica a todos los dominios que el servicio AD FS puede autenticar.
Puede usar el siguiente comando Windows PowerShell para establecer el bloqueo de extranet de AD FS (ejemplo):
Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow ( new-timespan -Minutes 30 )
Como referencia, la documentación pública de esta característica está aquí.
Deshabilitar WS-Trust Windows puntos de conexión en el proxy, es decir, desde extranet
WS-Trust Windows puntos de conexión (/adfs/services/trust/2005/windowstransport y /adfs/services/trust/13/windowstransport) solo están diseñados para ser puntos de conexión accesibles desde la intranet que usan el enlace WIA en HTTPS. Exponerlos a 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, deshabilitado desde extranet) para proteger el bloqueo de la cuenta de AD mediante los siguientes comandos de PowerShell. No hay ningún impacto conocido del usuario final al deshabilitar estos puntos de conexión en el proxy.
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 servidores de AD FS se ejecuta en Windows bases de datos internas (WID) y tiene un servidor de AD FS secundario, después de deshabilitar los puntos de conexión en el servidor principal, espere a que se produzca la sincronización en los nodos secundarios antes de reiniciar el servicio 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 para el acceso de intranet y 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 las solicitudes que proceden de Internet a través del proxy. Esta diferenciación se puede realizar por aplicación o globalmente. Para aplicaciones o aplicaciones de alto valor empresarial con información confidencial o de identificación personal, considere la posibilidad de requerir 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 se puede configurar para requerir autenticación segura (como la autenticación multifactor) específicamente para las solicitudes que entran a través del proxy, para aplicaciones individuales y para el acceso condicional tanto a Azure AD como a Office 365 y a recursos locales. Los métodos admitidos de MFA incluyen tanto Microsoft Azure MF como proveedores de terceros. Se pide al usuario que proporcione la información adicional (por ejemplo, un texto de SMS que contiene un código de una sola vez) 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 esta página, así como HDI Global.
Habilitación de la protección para evitar el paso de Azure AD Multi-Factor Authentication en la nube cuando se federa con Azure AD
Habilite la protección para evitar el paso de Azure AD Multi-Factor Authentication en la nube cuando se federa con Azure AD y usa Azure AD Multi-Factor Authentication como autenticación multifactor para los usuarios federados.
Habilitar la protección de un dominio federado en el inquilino de Azure AD garantizará que Azure AD Multi-Factor Authentication siempre se realice cuando un usuario federado acceda a una aplicación que se rige por una directiva de acceso condicional que requiera MFA. Esto incluye realizar Azure AD Multi-Factor Authentication incluso cuando el proveedor de identidades federados ha indicado (a través de notificaciones de token federado) que se ha realizado MFA local. La aplicación de Azure AD Multi-Factor Authentication cada vez garantiza que una cuenta local en peligro no puede omitir Azure AD Multi-Factor Authentication imitando que el proveedor de identidades ya ha realizado una autenticación multifactor y se recomienda encarecidamente a menos que realice MFA para los usuarios federados mediante 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 los cmdlets de MS Graph API o MS Graph PowerShell de federación interna. La federatedIdpMfaBehavior configuración determina si Azure AD 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 siguientes valores:
Los administradores pueden elegir uno de los siguientes valores:
| Propiedad | Descripción |
|---|---|
| acceptIfMfaDoneByFederatedIdp | Azure AD acepta MFA si lo realiza el proveedor de identidades. Si no es así, realiza Azure AD Multi-Factor Authentication. |
| enforceMfaByFederatedIdp | Azure AD acepta MFA si lo realiza el proveedor de identidades. Si no es así, redirige la solicitud al proveedor de identidades para realizar MFA. |
| rejectMfaByFederatedIdp | Azure AD siempre realiza Azure AD Multi-Factor Authentication y rechaza MFA si lo realiza el proveedor de identidades. |
Puede habilitar la protección estableciendo 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"
PowerShell
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)
En su configuración predeterminada, las claves que AD FS usa para firmar tokens nunca dejan los servidores de federación en la intranet. Nunca están presentes en la red perimetral o en las máquinas proxy. Opcionalmente, para proporcionar más protección, se recomienda proteger estas claves en un módulo de seguridad de hardware (HSM) conectado a AD FS. Microsoft no produce un producto HSM, pero hay varios en el mercado que admiten AD FS. Para implementar esta recomendación, siga las instrucciones del proveedor para crear los certificados X509 para la firma y el cifrado y, a continuación, use los commandlets de PowerShell de instalación de AD FS, especificando los certificados personalizados de la siguiente manera:
Install-AdfsFarm -CertificateThumbprint <String> -DecryptionCertificateThumbprint <String> -FederationServiceName <String> -ServiceAccountCredential <PSCredential> -SigningCertificateThumbprint <String>
donde:
CertificateThumbprintes el certificado SSL.SigningCertificateThumbprintes el certificado de firma (con clave protegida HSM)DecryptionCertificateThumbprintes el certificado de cifrado (con clave protegida con HSM)