Requisitos de AD FS para Windows Server
A continuación se muestran los distintos requisitos que debe cumplir al implementar AD FS:
Requisitos de certificados
Los certificados desempeñan una función crucial a la hora de proteger las comunicaciones entre los servidores de federación, los servidores Proxy de aplicación web, las aplicaciones para notificaciones y los clientes web. Los requisitos de los certificados varían en función de si se configura un equipo de servidor de federación o proxy, tal y como se describe en esta sección.
Certificados del servidor de federación
| Tipo de certificado | Requisitos, soporte y aspectos que deben conocerse |
|---|---|
| Certificado de Capa de sockets seguros (SSL): se trata de un certificado SLL estándar utilizado para proteger las comunicaciones entre los servidores de federación y los clientes. | - Este certificado debe ser un certificado de confianza pública* X509 v3. - Todos los clientes que acceden a cualquier punto de conexión de AD FS deben confiar en este certificado. Se recomienda encarecidamente usar certificados emitidos por una entidad de certificación pública (de terceros). Puede usar un certificado SSL autofirmado correctamente en servidores de federación en un entorno de laboratorio de pruebas. Sin embargo, para un entorno de producción, se recomienda obtener el certificado de una CA pública. - Se admite cualquier tamaño de clave compatible con Windows Server 2012 R2 para los certificados SSL. - No se admiten certificados que utilizan claves CNG. - Cuando se usa junto con Workplace Join o el Servicio de registro de dispositivos, el nombre alternativo del firmante del certificado SSL para el servicio AD FS debe contener el valor enterpriseregistration seguido del sufijo del nombre principal de usuario (UPN) de su organización, por ejemplo, enterpriseregistration.contoso.com. - Se admiten certificados comodín. Al crear la granja de AD FS, se le pedirá que proporcione el nombre del servicio para el servicio de AD FS (por ejemplo, adfs.contoso.com. - Se recomienda encarecidamente usar el mismo certificado SSL para el Proxy de aplicación web. Sin embargo, es necesario que sea el mismo cuando se admiten puntos de conexión de autenticación integrada de Windows a través del Proxy de aplicación web y cuando la autenticación de protección ampliada está activada (configuración predeterminada). - El nombre del firmante de este certificado se usa para representar el nombre del servicio de federación para cada instancia de AD FS que implemente. Por esta razón, tal vez te interese elegir un nombre de firmante en los certificados nuevos emitidos por CA que a los asociados les resulte más representativo del nombre de tu empresa u organización. La identidad del certificado debe coincidir con el nombre del servicio de federación (por ejemplo, fs.contoso.com). La identidad es una extensión de nombre alternativo del firmante de tipo dNSName o, si no hay entradas de nombre alternativo del firmante, el nombre del firmante especificado como nombre común. Puede haber varias entradas de nombre alternativo del firmante en el certificado, siempre que una de ellas coincida con el nombre de servicio de federación. - Importante: Se recomienda encarecidamente utilizar el mismo certificado SSL en todos los nodos de la granja de AD FS, así como todos los servidores Proxy de aplicación web de la granja de AD FS. |
| Certificado de comunicación de servicios: este certificado habilita la seguridad de mensajes WCF para proteger las comunicaciones entre los servidores de federación. | De manera predeterminada, se utiliza el certificado SSL como certificado de comunicaciones de servicio. Pero también tiene la opción de configurar otro certificado como certificado de comunicación de servicio. - Importante: Si usa el certificado SSL como certificado de comunicación de servicio, cuando expire el certificado SSL, asegúrese de configurar el certificado SSL renovado como certificado de comunicación de servicio. Esto no ocurre automáticamente. - Este certificado debe ser de confianza para los clientes de AD FS que usan la seguridad de mensajes WCF. - Se recomienda usar un certificado de autenticación de servidor emitido por una entidad de certificación pública (de terceros). - El certificado de comunicación de servicio no puede ser un certificado que use claves CNG. - Este certificado puede administrarse a través de la consola de administración de AD FS. |
| Certificado de firma de tokens: se trata de un certificado X509 estándar que se utiliza para firmar de manera segura todos los tokens que emite el servidor de federación. | - De forma predeterminada, AD FS crea un certificado autofirmado con claves de 2048 bits. - Los certificados emitidos por la entidad de certificación también se admiten y se pueden cambiar mediante el complemento de administración de AD FS. - Los certificados emitidos por la entidad de certificación deben almacenarse y, para acceder a ellos, se debe recurrir a un proveedor de cifrado CSP. - El certificado de firma de tokens no puede ser un certificado que use claves CNG. - AD FS no requiere certificados inscritos externamente para la firma de tokens. AD FS renueva automáticamente estos certificados autofirmados antes de que expiren, configurando primero los nuevos certificados como certificados secundarios para permitir que los asociados los consuman, y luego pasándolos a primarios en un proceso denominado renovación automática de certificados. Se recomienda usar los certificados predeterminados generados automáticamente para la firma de tokens. Si su organización tiene directivas que requieren que se configuren certificados diferentes para la firma de tokens, puede especificar los certificados en el momento de la instalación mediante PowerShell (use el parámetro –SigningCertificateThumbprint del cmdlet Install-AdfsFarm). Después de la instalación, puede ver y administrar certificados de firma de tokens mediante la consola de administración de AD FS o los cmdlets de PowerShell Set-AdfsCertificate y Get-AdfsCertificate. Cuando se usan certificados inscritos externamente para la firma de tokens, AD FS no realiza la renovación ni sustitución automática de certificados. Un administrador debe ocuparse de este proceso. Para permitir la sustitución de certificados cuando un certificado está a punto de caducar, se puede configurar un certificado de firma de tokens secundario en AD FS. De forma predeterminada, todos los certificados de firma de tokens están publicados en metadatos de federación, pero AD FS solo usa el certificado principal de firma de tokens para firmar los tokens. |
| Certificado de cifrado o descifrado de tokens: se trata de un certificado X509 estándar que se usa para descifrar o cifrar los tokens entrantes. También se publica en los metadatos de federación. | - De forma predeterminada, AD FS crea un certificado autofirmado con claves de 2048 bits. - Los certificados emitidos por la entidad de certificación también se admiten y se pueden cambiar mediante el complemento de administración de AD FS. - Los certificados emitidos por la entidad de certificación deben almacenarse y, para acceder a ellos, se debe recurrir a un proveedor de cifrado CSP. - El certificado de cifrado o descifrado de tokens no puede ser un certificado que use claves de CNG. - De forma predeterminada, AD FS genera y usa sus propios certificados autofirmados y generados internamente para el descifrado de tokens. AD FS no requiere certificados inscritos externamente para este fin. Además, AD FS renueva automáticamente estos certificados autofirmados antes de que expiren. Se recomienda usar los certificados predeterminados generados automáticamente para el descifrado de tokens. Si su organización tiene directivas que requieren que se configuren certificados diferentes para el descifrado de tokens, puede especificar los certificados en el momento de la instalación mediante PowerShell (use el parámetro –DecryptionCertificateThumbprint del cmdlet Install-AdfsFarm). Después de la instalación, puede ver y administrar certificados de descifrado de tokens mediante la consola de administración de AD FS o los cmdlets de PowerShell Set-AdfsCertificate y Get-AdfsCertificate. Cuando se usan certificados inscritos externamente para el descifrado de tokens, AD FS no realiza la renovación automática de certificados. Un administrador debe ocuparse de este proceso. - La cuenta de servicio de AD FS debe tener acceso a la clave privada del certificado de firma de tokens en el almacén personal del equipo local. De esto se encarga el programa de instalación. También puede usar el complemento de administración de AD FS para garantizar este acceso si después cambia el certificado de firma de tokens. |
Precaución
Los certificados que se usan para la firma de tokens y el cifrado/descifrado de tokens son cruciales para la estabilidad del servicio de federación. Los clientes que administran sus propios certificados de firma de tokens y de descifrado y cifrado de tokens deben asegurarse de que estos certificados tengan una copia de seguridad y estén disponibles de forma independiente durante un evento de recuperación.
Nota:
En AD FS, puede cambiar el nivel del Algoritmo hash seguro (SHA) que se usa para las firmas digitales a SHA-1 o a SHA-256 (más seguro). AD FS no es compatible con el uso de certificados con otros métodos hash, como MD5 (el algoritmo hash predeterminado utilizado con la herramienta de línea de comandos Makecert.exe). Para tu seguridad, te recomendamos que utilices SHA-256 (establecido de manera predeterminada) para todas las firmas. Se aconseja el uso de SHA-1 solo en los casos en que se debe interoperar con un producto no compatible con las comunicaciones que usan SHA-256, como un producto que no sea de Microsoft o versiones heredadas de AD FS.
Nota
Después de recibir un certificado de una CA, asegúrate de que todos los certificados se importen al almacén de certificados personales del equipo local. Puedes importar certificados al almacén personal con el complemento Certificados de MMC.
Requisitos de hardware
Los siguientes requisitos mínimos y recomendados de hardware se aplican a los servidores de federación de AD FS en Windows Server 2012 R2:
| Requisito de hardware | Requisito mínimo | Requisito recomendado |
|---|---|---|
| Velocidad de CPU | Procesador de 64 bits a 1,4 GHz | Cuatro núcleos, 2 GHz |
| RAM | 512 MB | 4 GB |
| Espacio en disco | 32 GB | 100 GB |
Requisitos de software
Los siguientes requisitos de AD FS son para la funcionalidad del servidor integrada en el sistema operativo Windows Server® 2012 R2:
Para el acceso desde una extranet, debe implementar el servicio de rol del Proxy de aplicación web, que forma parte del rol de servidor de Acceso remoto de Windows Server® 2012 R2. Las versiones anteriores de un proxy de servidor de federación no se admiten con AD FS en Windows Server® 2012 R2.
No se puede instalar un servidor de federación y el servicio de rol de Proxy de aplicación web en el mismo equipo.
Requisitos de AD DS
Requisitos del controlador de dominio
Los controladores de dominio de todos los dominios de usuario y el dominio al que se unen los servidores de AD FS deben ejecutar Windows Server 2008 o posterior.
Nota
Todo el soporte para entornos con controladores de dominio Windows Server 2003 finalizará después de la fecha de finalización del soporte extendido para Windows Server 2003. Se recomienda encarecidamente a los clientes actualizar sus controladores de dominio lo antes posible. Visite esta página para obtener información adicional sobre el ciclo de vida del soporte técnico de Microsoft. Para los problemas detectados que sean específicos de los entornos de controlador de dominio de Windows Server 2003, solo se emitirán correcciones para los problemas de seguridad y si se puede emitir una corrección antes de que expire el soporte extendido para Windows Server 2003.
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.
Requisitos de nivel funcional del dominio
Todos los dominios de cuentas de usuario y el dominio al cual se unen los servidores de AD FS deben funcionar en el nivel funcional de dominio de Windows Server 2003 o posterior.
La mayoría de las características de AD FS no requieren modificaciones de niveles funcionales de AD DS para funcionar correctamente. Sin embargo, se requiere un nivel funcional de dominio de Windows Server 2008 o superior para que la autenticación del certificado de cliente funcione correctamente, si dicho certificado está asignado explícitamente a una cuenta de usuario en AD DS.
Requisitos de esquemas
AD FS no requiere ningún cambio de esquema ni modificaciones en el nivel funcional de AD DS.
Para usar la funcionalidad Workplace Join, el esquema del bosque al que están unidos los servidores de AD FS debe establecerse en Windows Server 2012 R2.
Requisitos de cuentas de servicio
Se puede usar cualquier cuenta de servicio estándar como cuenta de servicio para AD FS. También se admiten cuentas de servicio administradas de grupo. Esto requiere al menos un controlador de dominio (se recomienda implementar dos o más) que ejecute Windows Server 2012 o superior.
Para que la autenticación Kerberos funcione entre clientes unidos a un dominio y AD FS, "HOST/<adfs_service_name>" debe estar registrado como SPN en la cuenta de servicio. De forma predeterminada, AD FS lo configurará al crear una nueva granja de AD FS si tiene permisos suficientes para realizar esta operación.
La cuenta de servicio de AD FS debe ser de confianza en todos los dominios de usuario que contengan usuarios que se autentiquen en el servicio de AD FS.
Requisitos de dominio
Todos los servidores de AD FS deben estar unidos a un dominio AD DS.
Todos los servidores de AD FS de una granja deben implementarse en un único dominio.
El dominio al que se unan los servidores de AD FS debe confiar en cada dominio de cuenta de usuario que contenga usuarios que se autentiquen en el servicio AD FS.
Requisitos de varios bosques
El dominio al que se unan los servidores de AD FS debe confiar en cada dominio de cuenta de usuario o bosque que contenga usuarios que se autentiquen en el servicio AD FS.
La cuenta de servicio de AD FS debe ser de confianza en todos los dominios de usuario que contengan usuarios que se autentiquen en el servicio de AD FS.
Requisitos de bases de datos de configuración
A continuación se muestran los requisitos y restricciones que se aplican en función del tipo de almacén de configuración:
WID
Una granja de servidores WID tiene un límite de 30 servidores de federación si tiene 100 o menos relaciones de confianza para usuario autenticado.
El perfil de resolución de artefactos de SAML 2.0 no se admite en la base de datos de configuración de WID. La detección de reproducción de tokens no se admite en la base de datos de configuración de WID. Esta funcionalidad solo se usa en escenarios donde AD FS funciona como proveedor de federación y consume tokens de seguridad de proveedores de notificaciones externos.
La implementación de servidores de AD FS en distintos centros de datos para la conmutación por error o el equilibrio de carga geográfica se admite siempre que el número de servidores no supere los 30.
En la siguiente tabla se proporciona un resumen del uso de una granja de WID. Úselo para planear la implementación.
| 1-100 relaciones de confianza para usuario autenticado | Más de 100 relaciones de confianza para usuario autenticado |
|---|---|
| 1-30 nodos de AD FS: Compatible con WID | 1-30 nodos de AD FS: No compatible con WID, se requiere SQL |
| Más de 30 nodos de AD FS: No compatible con WID, se requiere SQL | Más de 30 nodos de AD FS: No compatible con WID, se requiere SQL |
SQL Server
Para AD FS en Windows Server 2012 R2, puede usar SQL Server 2008 y versiones posteriores.
Requisitos del explorador
Cuando la autenticación de AD FS se hace a través de un explorador o un control de explorador, el explorador tiene que cumplir los siguientes requisitos:
JavaScript debe estar habilitado.
Las cookies deben estar activadas.
Se debe admitirla indicación de nombre de servidor (SNI).
Para la autenticación de certificados de usuario y certificados de dispositivo (funcionalidad Workplace Join), el explorador tiene que admitir la autenticación de certificados de cliente SSL.
Varios exploradores y plataformas clave se han sometido a una validación de representación y funcionalidad cuyos detalles se enumeran a continuación. Los exploradores y dispositivos que no se tratan en esta tabla siguen siendo compatibles si cumplen los requisitos enumerados anteriormente:
| Exploradores | Plataformas |
|---|---|
| IE=10.0 | Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 |
| IE=11.0 | Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 |
| Agente de autenticación web de Windows | Windows 8.1 |
| Firefox [v21] | Windows 7, Windows 8.1 |
| Safari [v7] | iOS 6, Mac OS-X 10.7 |
| Chrome [v27] | Windows 7, Windows 8.1, Windows Server 2012, Windows Server 2012 R2, Mac OS-X 10.7 |
Importante
Problema conocido: Firefox: la funcionalidad Workplace Join que identifica el dispositivo mediante el certificado de dispositivo no es funcional en plataformas Windows. Firefox no admite actualmente la realización de la autenticación de certificados de cliente SSL mediante certificados aprovisionados en el almacén de certificados de usuario en clientes Windows.
Cookies
AD FS crea cookies persistentes y basadas en sesión que deben almacenarse en equipos cliente para proporcionar funcionalidades de inicio de sesión, cierre de sesión, inicio de sesión único (SSO) y demás. Por lo tanto, el explorador cliente debe estar configurado para aceptar cookies. Las cookies usadas para la autenticación son siempre cookies de sesión de protocolo seguro de transferencia de hipertexto (HTTPS) escritas para el servidor de origen. Si el explorador cliente no está configurado para permitir estas cookies, AD FS no funcionará correctamente. Las cookies persistentes se usan para conservar la selección del usuario del proveedor de notificaciones. Puedes deshabilitarlas a través de una opción del archivo de configuración para las páginas de inicio de sesión de AD FS. Es necesaria la compatibilidad con TLS/SSL por motivos de seguridad.
Requisitos de extranet
Para proporcionar acceso de extranet al servicio AD FS, debe implementar el servicio de rol del Proxy de aplicación web como rol orientado a la extranet que represente las solicitudes de autenticación de forma segura en el servicio AD FS. Esto proporciona el aislamiento de los puntos de conexión del servicio de AD FS, así como el aislamiento de todas las claves de seguridad (como los certificados de firma de tokens) de las solicitudes que se originan en Internet. Además, las características como el bloqueo parcial de la cuenta de extranet requieren el uso del Proxy de aplicación web. Para obtener información general sobre el Proxy de aplicación web, consulte Proxy de aplicación web. `
Requisitos de red
Configurar de manera apropiada los siguientes servicios de red es fundamental para una correcta implementación de AD FS en su organización.
Configuración del firewall corporativo
Tanto el firewall que se encuentra entre el Proxy de aplicación web y la granja de servidores de federación como el firewall entre los clientes y el Proxy de aplicación web deben tener el puerto 443 TCP habilitado para la entrada.
Además, si se requiere la autenticación de certificados de usuario de cliente (autenticación de clientTLS mediante certificados de usuario X509) AD FS en Windows Server 2012 R2 requiere que el puerto 49443 TCP esté habilitado en el firewall entre los clientes y el Proxy de aplicación web. Esto no es necesario en el firewall entre el Proxy de aplicación web y los servidores de federación.
Nota
Asegúrese también de que el puerto 49443 no lo use ningún otro servicio en el servidor de AD FS y el Proxy de aplicación web.
Configuring DNS (Configuración de DNS)
Para el acceso desde una intranet, todos los clientes que accedan al servicio de AD FS dentro de la red corporativa interna (intranet) deben poder resolver el nombre del servicio de AD FS (nombre proporcionado por el certificado SSL) en el equilibrador de carga para los servidores de AD FS.
Para el acceso desde una extranet, todos los clientes que accedan al servicio de AD FS desde fuera de la red corporativa (extranet/Intranet) deben poder resolver el nombre del servicio de AD FS (nombre proporcionado por el certificado SSL) en el equilibrador de carga para los servidores del Proxy de aplicación web.
Para que el acceso de la extranet funciona correctamente, cada servidor del Proxy de aplicación web de DMZ debe poder resolver el nombre del servicio de AD FS (nombre proporcionado por el certificado SSL) en el equilibrador de carga para los servidores de AD FS. Esto puede lograrse mediante un servidor DNS alternativo en la red perimetral o cambiando la resolución del servidor local mediante el archivo HOSTS.
Para que la autenticación integrada de Windows funcione dentro y fuera de la red para un subconjunto de puntos de conexión expuestos a través del Proxy de aplicación web, debe usar un registro A (no CNAME) para apuntar a los equilibradores de carga.
Para obtener información sobre cómo configurar el DNS corporativo para el servicio de federación y el Servicio de registro de dispositivos, consulte Configurar el DNS corporativo para los servicios de federación y DRS.
Para obtener información sobre cómo configurar el DNS corporativo para servidores Proxy de aplicación web, consulte la sección "Configurar DNS" en Paso 1: Configurar la infraestructura del Proxy de aplicación web.
Para obtener información sobre cómo configurar una dirección IP de clúster o un FQDN de clúster con NLB, consulte Especificación de los parámetros de clúster en http://go.microsoft.com/fwlink/?LinkId=75282.
Requisitos de almacenes de atributos
AD FS necesita que se use por lo menos un almacén de atributos para autenticar a los usuarios y extraer notificaciones de seguridad para ellos. Para ver una lista de los almacenes de atributos compatibles con AD FS, vea El papel de los almacenes de atributos.
Nota
AD FS crea automáticamente un almacén de atributos de Active Directory de manera predeterminada. Los requisitos de los almacenes de atributos dependen de si la organización actúa como asociado de cuenta (hospeda a los usuarios federados) o como asociado de recurso (hospeda la aplicación federada).
Almacenes de atributos de LDAP
Cuando trabajes con otros almacenes de atributos basados en el Protocolo ligero de acceso a directorios (LDAP), debes conectarte a un servidor LDAP que sea compatible con la autenticación integrada de Windows. Además, la cadena de conexión de LDAP debe estar escrita con el formato de una dirección URL de LDAP, tal y como se describe en RFC 2255.
También es necesario que la cuenta de servicio del servicio de AD FS tenga derecho a recuperar información de usuario en el almacén de atributos de LDAP.
Almacenes de atributos de SQL Server
Para que AD FS en Windows Server 2012 R2 funcione correctamente, los equipos que hospedan el almacén de atributos de SQL Server deben ejecutar Microsoft SQL Server 2008 o superior. Si trabajas con almacenes de atributos basados en SQL, también debes configurar una cadena de conexión.
Almacenes de atributos personalizados
Puedes desarrollar almacenes de atributos personalizados para habilitar escenarios avanzados.
El lenguaje de directiva integrado en AD FS puede hacer referencia a almacenes de atributos personalizados, con el fin de permitir una mejora en los siguientes escenarios:
Crear notificaciones para un usuario autenticado localmente
Complementar notificaciones para un usuario autenticado externamente
Autorizar a un usuario a obtener un token
Autorizar a un servicio a obtener un token del comportamiento de un usuario
Emitir datos adicionales en tokens de seguridad emitidos por AD FS a los usuarios de confianza.
Todos los almacenes de atributos personalizados deben compilarse sobre .NET 4.0 o superior.
Si trabaja con un almacén de atributos personalizado, también podría tener que configurar una cadena de conexión. En ese caso, puede escribir un código personalizado de su elección que permita una conexión al almacén de atributos personalizado. La cadena de conexión en esta situación es un conjunto de pares nombre-valor interpretados como implementados por el desarrollador del almacén de atributos personalizados. Para obtener más información sobre el desarrollo y el uso de almacenes de atributos personalizados, vea Información general sobre el almacén de atributos.
Requisitos de las aplicaciones
AD FS admite aplicaciones para notificaciones que usan los protocolos siguientes:
WS-Federation
WS-Trust
Protocolo SAML 2.0 mediante perfiles IDPLite, SPLite y eGov1.5.
Perfil de concesión de autorización de OAuth 2.0
AD FS también admite la autenticación y autorización para las aplicaciones que no son para notificaciones que admite el Proxy de aplicación web.
Requisitos de autenticación
Autenticación de AD DS (autenticación principal)
Para el acceso a la intranet, se admiten los siguientes mecanismos de autenticación estándar para AD DS:
Autenticación integrada de Windows utilizando Negotiate para Kerberos y NTLM
Autenticación de formularios mediante nombres de usuario y contraseñas
Autenticación de certificados mediante certificados asignados a cuentas de usuario en AD DS
Para el acceso de extranet, se admiten los siguientes mecanismos de autenticación:
Autenticación de formularios mediante nombres de usuario y contraseñas
Autenticación de certificados mediante certificados asignados a cuentas de usuario en AD DS
Autenticación integrada de Windows mediante Negotiate (solo NTLM) para puntos de conexión de WS-Trust que aceptan la autenticación integrada de Windows.
Para la autenticación de certificados:
Se extiende a las tarjetas inteligentes que pueden protegerse con PIN.
AD FS no proporciona la GUI para que el usuario escriba su PIN y es necesario que forme parte del sistema operativo cliente que se muestra al usar la TLS de cliente.
El lector y el proveedor de servicios de cifrado (CSP) de la tarjeta inteligente deben funcionar en el equipo donde está ubicado el explorador.
El certificado de la tarjeta inteligente debe encadenarse a una raíz de confianza en todos los servidores AD FS y servidores de Proxy de aplicación web.
El certificado debe asignarse a la cuenta de usuario de AD DS mediante uno de los siguientes métodos:
El nombre del firmante del certificado se corresponde con el nombre distintivo de LDAP de una cuenta de usuario en AD DS.
La extensión NombreAlt del firmante del certificado tiene el nombre principal de usuario (UPN) de una cuenta de usuario en AD DS.
Para una autenticación integrada de Windows sin fisuras mediante Kerberos en la intranet:
Es necesario que el nombre del servicio forme parte de los sitios de confianza o de los sitios de la intranet local.
Además, el SPN HOST/<adfs_service_name> debe establecerse en la cuenta de servicio en la que se ejecuta la granja de AD FS.
Multi-Factor Authentication
AD FS admite autenticación adicional (más allá de la autenticación principal admitida por AD DS) mediante un modelo de proveedor en el que los proveedores o clientes pueden crear su propio adaptador de autenticación multifactor que un administrador puede registrar y usar durante el inicio de sesión.
Cada adaptador de MFA debe compilarse sobre .NET 4.5.
Para obtener más información sobre MFA, consulte Administración de riesgos con la autenticación multifactor adicional para aplicaciones confidenciales.
Autenticación de dispositivos
AD FS admite la autenticación de dispositivos mediante certificados aprovisionados por el Servicio de registro de dispositivos durante el acto de unión al área de trabajo que un usuario final realiza con su dispositivo.
Requisitos de unión al área de trabajo
Los usuarios finales pueden incorporar sus dispositivos a una organización con AD FS mediante la opción de unirse al área de trabajo. Esto es compatible con el Servicio de registro de dispositivos en AD FS. Como resultado, los usuarios finales obtienen la ventaja adicional del inicio de sesión único en las aplicaciones compatibles con AD FS. Además, los administradores pueden administrar el riesgo limitando el acceso a las aplicaciones solo a los dispositivos que se han incorporado a la organización mediante la opción de unirse al área de trabajo. A continuación se muestran los siguientes requisitos para habilitar este escenario.
AD FS admite la unión al área de trabajo para dispositivos Windows 8.1 e iOS 5+.
Para usar la funcionalidad Workplace Join, el esquema del bosque al que están unidos los servidores de AD FS debe establecerse en Windows Server 2012 R2.
El nombre alternativo del firmante del certificado SSL para el servicio AD FS debe contener el valor enterpriseregistration seguido del sufijo de nombre principal de usuario (UPN) de su organización, por ejemplo, enterpriseregistration.corp.contoso.com.
Requisitos de criptografía
En la tabla siguiente se proporciona información adicional sobre la compatibilidad con criptografía para la funcionalidad de firma de tokens de AD FS, cifrado/descifrado de tokens:
| Algoritmo | Longitudes de clave | Protocolos/aplicaciones/comentarios |
|---|---|---|
| TripleDES: valor predeterminado 192 (compatible con 192 – 256) - http://www.w3.org/2001/04/xmlenc#tripledes-cbc | >= 192 | Algoritmo admitido para descifrar el token de seguridad. No se admite el cifrado del token de seguridad con este algoritmo. |
| AES128 - http://www.w3.org/2001/04/xmlenc#aes128-cbc | 128 | Algoritmo admitido para descifrar el token de seguridad. No se admite el cifrado del token de seguridad con este algoritmo. |
| AES192 - http://www.w3.org/2001/04/xmlenc#aes192-cbc | 192 | Algoritmo admitido para descifrar el token de seguridad. No se admite el cifrado del token de seguridad con este algoritmo. |
| AES256 - http://www.w3.org/2001/04/xmlenc#aes256-cbc | 256 | Default. Algoritmo admitido para cifrar el token de seguridad. |
| TripleDESKeyWrap - http://www.w3.org/2001/04/xmlenc#kw-tripledes | Todos los tamaños de clave admitidos por .NET 4.0+. | Algoritmo admitido para cifrar la clave simétrica que cifra un token de seguridad. |
| AES128KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes128 | 128 | Algoritmo admitido para cifrar la clave simétrica que cifra el token de seguridad. |
| AES192KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes192 | 192 | Algoritmo admitido para cifrar la clave simétrica que cifra el token de seguridad. |
| AES256KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes256 | 256 | Algoritmo admitido para cifrar la clave simétrica que cifra el token de seguridad. |
| RsaV15KeyWrap - http://www.w3.org/2001/04/xmlenc#rsa-1_5 | 1024 | Algoritmo admitido para cifrar la clave simétrica que cifra el token de seguridad. |
| RsaOaepKeyWrap - http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p | 1024 | Predeterminada. Algoritmo admitido para cifrar la clave simétrica que cifra el token de seguridad. |
| SHA1-http://www.w3.org/PICS/DSig/SHA1_1_0.html | N/D | Usado por el servidor de AD FS en la generación SourceId del artefacto: en este escenario, STS usa SHA1 (según la recomendación del estándar SAML 2.0) para crear un valor corto de 160 bits para el SourceId del artefacto. También lo utiliza el agente web de AD FS (componente heredado del marco período de tiempo de WS2003) para identificar los cambios en un valor temporal de "última actualización", de forma que sepa cuándo debe actualizar la información del STS. |
| SHA1withRSA- | N/D | Se utiliza en los casos en los que el servidor de AD FS valida la firma de SAML AuthenticationRequest, firma la solicitud o respuesta de resolución de artefactos o crea un certificado de firma de tokens. En estos casos, SHA256 es el valor predeterminado y SHA1 solo se usa si el asociado (usuario de confianza) no puede admitir SHA256 y debe usar SHA1. |
Requisitos de permisos
El administrador que realiza la instalación y la configuración inicial de AD FS debe tener permisos de administrador de dominio en el dominio local (es decir, el dominio al que está unido el servidor de federación).