Novedades de Servicios de federación de Active Directory (AD FS)

  • Artículo

Novedades en los Servicios de federación de Active Directory (AD FS) para Windows Server 2019

Este artículo describe los nuevos cambios realizados en Servicios de federación de Active Directory (AD FS).

Inicios de sesiones protegidos

Los siguientes puntos son un breve resumen de las actualizaciones de los inicios de sesión protegidos disponibles en los Servicios de federación de Active Directory (AD FS) 2019:

  • Proveedores de autenticación externos como principales. Los clientes ahora pueden usar productos con autenticación de terceros como primer factor sin exponer contraseñas como el primer factor. En los casos en los que un proveedor de autenticación externo puede comprobar dos factores, puede reclamar a la MFA.
  • Autenticación por contraseña como autenticación adicional. Los clientes disponen de una opción totalmente compatible para utilizar contraseñas sólo como factor adicional después de utilizar una opción sin contraseña como primer factor. Esta opción mejora la experiencia del cliente en comparación con AD FS 2016, donde los clientes debían instalar un adaptador de GitHub admitido como tal.
  • Módulo de evaluación de riesgos acoplable. Los clientes ahora pueden crear sus propios módulos acoplables para bloquear determinados tipos de solicitudes durante la fase de autenticación previa. Esta función facilita a los clientes el uso de la inteligencia en la nube (como Identity Protection) para bloquear los inicios de sesión para usuarios o transacciones de riesgo. Para obtener más información, consulte Creación de complementos con el modelo de evaluación de riesgos de AD FS 2019.
  • Mejoras ESL. Mejora la ingeniería de corrección rápida (QFE) de ESL en 2016 añadiendo las siguientes capacidades:
    • Permite que los clientes puedan estar en modo auditoría mientras conservan la funcionalidad de bloqueo de extranet "clásico" disponible desde AD FS 2012 R2. Actualmente, los clientes de la versión 2016 no tienen protección mientras están en modo auditoría.
    • Habilita el umbral de bloqueo independiente para las ubicaciones conocidas. Esta función permite que varias instancias de aplicaciones que se ejecutan con una cuenta de servicio común sustituyan las contraseñas con el menor impacto posible.

Otras mejoras de seguridad

Las siguientes mejoras de seguridad están disponibles en AD FS 2019:

  • PowerShell remoto utilizando el inicio de sesión de tarjeta inteligente. Los clientes ahora pueden usar tarjetas inteligentes para conectarse de forma remota a AD FS a través de PowerShell, y usarlas para administrar todas las funciones de PowerShell, incluidos los cmdlets de varios nodos.
  • Personalización del encabezado HTTP. Los clientes ahora pueden personalizar las cabeceras HTTP emitidas durante las respuestas de AD FS, incluyendo las siguientes cabeceras:
    • HSTS: este encabezado transmite que los puntos de conexión de AD FS solo se pueden utilizar en puntos de conexión HTTPS para que un navegador compatible los aplique.
    • x-frame-options: permite a los administradores de AD FS permitir a partes confiantes específicas incrustar iFrames para páginas de inicio de sesión interactivas de AD FS. Este encabezado debe usarse con cuidado y únicamente en hosts HTTPS.
    • Encabezado futuro: otros encabezados futuros también pueden ser configurados.

Para obtener más información, consulte Personalizar encabezados de respuesta de seguridad HTTP con AD FS 2019.

Funcionalidades de autenticación o directiva

Las siguientes funcionalidades de autenticación y directivas forman parte de AD FS 2019:

  • Especifique el método de autenticación para otra autenticación para RP (parte confiante). Los clientes ya pueden usar reglas de notificaciones para decidir qué proveedor de autenticación adicional debe aplicarse para la autenticación adicional. Esta función resulta útil en dos casos:
    • Los clientes están pasando de un proveedor de autenticación a otro. De esta forma, a medida que los usuarios se incorporan a un nuevo proveedor de autenticación, pueden utilizar grupos para controlar a qué proveedor de autenticación adicional se llama.
    • Los clientes necesitan un proveedor de autenticación adicional específico (por ejemplo, un certificado) para determinadas aplicaciones.
  • Restringir la autenticación de dispositivos basada en la seguridad de la capa de transporte (TLS) sólo a las aplicaciones que lo requieran. Ahora, los clientes pueden restringir las autenticaciones de dispositivos basadas en TLS del cliente únicamente a las aplicaciones que realizan acceso condicional basado en dispositivos. Esta opción impide que se generen mensajes no deseados para la autenticación de dispositivos (o errores si la aplicación cliente no puede controlarla) para las aplicaciones que no requieren de la autenticación de dispositivo basada en TLS.
  • Compatibilidad con la actualización de autenticación multifactor (MFA). AD FS ahora admite la capacidad de rehacer la credencial de segundo factor basándose en la frescura de la credencial de segundo factor. Esta función permite a los clientes realizar una transacción inicial con dos fases y solicitar el segundo factor únicamente de forma periódica. Esta función está solo disponible para las aplicaciones que pueden proporcionar un parámetro adicional en la solicitud y no es un valor configurable en AD FS. Azure AD admite este parámetro al configurar "Recordar mi MFA durante X días" y establecer la marca "supportsMFA" en TRUE en la configuración de confianza de dominio federado de Azure AD.

Mejoras en el inicio de sesión único

En AD FS 2019 se han realizado las siguientes mejoras de SSO de inicio de sesión único:

  • UX paginada con tema centrado. AD FS se ha cambiado ahora a un flujo de experiencia de usuario paginada que permite a AD FS validar y proporcionar una experiencia de inicio de sesión más fluida. AD FS ahora usa una interfaz de usuario centrada (en lugar del lado derecho de la pantalla). Es posible que necesite un logotipo y unas imágenes de fondo más recientes para adaptarse a esta experiencia. Este cambio también refleja la funcionalidad ofrecida en Azure AD.
  • Corrección de errores: estado de SSO persistente para dispositivos con Windows 10 cuando se realiza la autenticación de token de actualización principal (PRT). Este cambio resuelve un problema por el que el estado de MFA no persistía al utilizar la autenticación PRT para dispositivos con Windows 10. Como resultado, a los usuarios finales se les solicitaban las credenciales de segunda fase (MFA) con frecuencia. La corrección también hace que la experiencia sea coherente cuando la autenticación de dispositivo se realiza correctamente a través de TLS cliente y a través del mecanismo de PRT.

Compatibilidad para crear aplicaciones de línea de negocio modernas

Se ha añadido a AD FS 2019 la siguiente compatibilidad con la creación de aplicaciones LOB de línea de negocio modernas:

  • Oauth Flujo/perfil del dispositivo. AD FS ahora admite el perfil de flujo de dispositivo de OAuth para realizar inicios de sesión en dispositivos que no tienen un área expuesta de interfaz de usuario para admitir experiencias de inicio de sesión enriquecidas. Esta función permite al usuario completar la experiencia de inicio de sesión en un dispositivo diferente. Esta funcionalidad es necesaria para la experiencia de CLI de Azure en Azure Stack y puede utilizarse en otros casos.
  • Eliminación del parámetro "Recurso". AD FS ahora ha retirado el requisito de especificar un parámetro de recurso, que coincide con las especificaciones actuales de Oauth. Ahora los clientes pueden proporcionar el identificador de relación de confianza de usuario de confianza como parámetro de ámbito, además de los permisos solicitados.
  • Encabezados de uso compartido de recursos entre orígenes (CORS) en las respuestas de AD FS. Ahora los clientes pueden crear aplicaciones de una sola página que permitan a las bibliotecas JavaScript del lado del cliente validar la firma del id_token mediante la consulta de las claves de firma del documento de detección de OpenID Connect (OIDC) en AD FS.
  • Compatibilidad con la clave de prueba para intercambio de código (PKCE). AD FS agrega compatibilidad con PKCE para proporcionar un flujo de código de autenticación seguro en OAuth. Esta función agrega una capa adicional de seguridad a este flujo para evitar que se secuestre el código y se reproduzca desde un cliente diferente.
  • Corrección de errores: enviar notificación x5t y kid. Este cambio es una corrección menor de errores. AD FS ahora envía también la notificación "kid" para indicar la sugerencia de identificador de clave para comprobar la firma. Anteriormente, AD FS sólo enviaba la notificación "x5t".

Mejoras de compatibilidad

Las siguientes mejoras en la compatibilidad ya forman parte de AD FS 2019:

  • Enviar los detalles del error a los administradores de AD FS. Los administradores pueden configurar a los usuarios finales para que envíen registros de depuración relacionados con un error en la autenticación del usuario final que se almacenará como archivo comprimido para facilitar su consumo. Los administradores también pueden configurar una conexión SMTP (protocolo simple de transferencia de correo) para enviar automáticamente el archivo comprimido a una cuenta de correo electrónico de triaje o para crear automáticamente un ticket basado en el correo electrónico.

Actualizaciones de implementación

Las siguientes actualizaciones de implementación ahora están incluidas en AD FS 2019:

  • Nivel de comportamiento de la granja de servidores 2019. Al igual que con AD FS 2016, se requiere una nueva versión de nivel de comportamiento de granja para habilitar la nueva funcionalidad descrita posteriormente en el artículo. Esta actualización permite pasar de:
    • AD FS en Windows Server 2012 R2 a AD FS en Windows Server 2016.
    • AD FS en Windows Server 2016 a AD FS en Windows Server 2019.

Actualizaciones de SAML

La siguiente actualización del lenguaje de marcado de aserción de seguridad (SAML) está en AD FS 2019:

  • Corrección de errores: corregir errores en la federación agregada. Se han producido numerosas correcciones de errores en torno a la compatibilidad con la federación agregada (por ejemplo, InCommon). Se han corregido las siguientes áreas:
    • Escalado mejorado para un gran número de entidades en el documento de metadatos de federación agregada. Anteriormente, el escalado fallaba con un error "ADMIN0017".
    • Consulta utilizando el parámetro "ScopeGroupID" mediante el cmdlet Get-AdfsRelyingPartyTrustsGroup de PowerShell.
    • Tratamiento de condiciones de error en torno a entityID duplicados.

Especificación de recursos de estilo Azure AD en el parámetro de ámbito

Anteriormente, AD FS necesitaba que el recurso y el ámbito deseados se incluyeran en parámetros independientes en cualquier solicitud de autenticación. Por ejemplo, la siguiente solicitud OAuth podría parecerse a la que enviaría normalmente:

https://fs.contoso.com/adfs/oauth2/authorize?response_type=code&client_id=claimsxrayclient&resource=urn:microsoft:adfs:claimsxray&scope=oauth&redirect_uri=https://adfshelp.microsoft.com/
ClaimsXray/TokenResponse&prompt=login

Con AD FS en Server 2019, ahora puedes pasar el valor de recurso insertado en el parámetro de ámbito. Este cambio es coherente con el modo en que también se puede realizar la autenticación en Azure AD.

Ahora, el parámetro de ámbito se puede organizar como una lista separada por espacios donde cada entrada está estructurada como recurso/ámbito.

Nota

Solo se puede especificar un recurso en la solicitud de autenticación. Si se incluye más de un recurso en la solicitud, AD FS devuelve un error y la autenticación no se realiza correctamente.

Compatibilidad con la clave de prueba para intercambio de código (PKCE) de OAuth

Los clientes públicos de OAuth que usan la concesión de código de autorización son susceptibles de sufrir ataques de interceptación de código de autorización. El ataque se describe correctamente en RFC 7636. Para mitigar este ataque, AD FS en Server 2019 admite la clave de prueba para intercambio de código (PKCE) para el flujo de concesión de código de autorización de OAuth.

Para utilizar la compatibilidad con PKCE, esta especificación añade más parámetros a las solicitudes de autorización y token de acceso de OAuth 2.0.

Diagram of the PKCE relationship between the client and AD FS 2019.

A. El cliente crea y registra un secreto denominado "code_verifier" y deriva una versión transformada "t(code_verifier)" (a la que se hace referencia como "code_challenge"). El secreto se envía en la solicitud de autorización OAuth 2.0 junto con el método de transformación "t_m".

B. El punto de conexión de autorización responde como de costumbre pero registra "t(code_verifier)" y el método de transformación.

C. Después, el cliente envía el código de autorización en la solicitud de token de acceso como de costumbre, pero incluye el secreto "code_verifier" generado en (A).

D. AD FS transforma el secreto "code_verifier" y lo compara con "t(code_verifier)" de (B). Se deniega el acceso si no son iguales.

Cómo elegir proveedores de autenticación adicional en 2019

AD FS ya admite la activación de la autenticación adicional basada en las directivas de reglas de notificación. Esas directivas se pueden configurar en un RP específico o en el nivel global. Se puede establecer una directiva de autenticación adicional para una RP específico mediante el cmdlet Set-AdfsRelyingPartyTrust (AD FS) | Microsoft Docs pasando el parámetro AdditionalAuthenticationRules o AdditionalAuthenticationRulesFile. Para establecer la directiva en el nivel global, el administrador puede usar el cmdlet Set-AdfsAdditionalAuthenticationRule (AD FS) | Microsoft Docs.

Por ejemplo, de 2012 R2 en adelante el administrador ya puede escribir la siguiente regla para pedir una autenticación adicional si la solicitud procede de la extranet.

Set-AdfsAdditionalAuthenticationRule -AdditionalAuthenticationRules 'c:[type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = "https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = "https://schemas.microsoft.com/claims/multipleauthn" );'

En 2019, los clientes ya pueden usar reglas de notificaciones para decidir qué proveedor de autenticación adicional debe invocarse para la autenticación adicional. Esta característica es útil para dos escenarios:

Los clientes están pasando de un proveedor de autenticación a otro. De esta forma, a medida que los usuarios se incorporan a un nuevo proveedor de autenticación, pueden utilizar grupos para controlar a qué proveedor de autenticación adicional se llama.

Los clientes necesitan un proveedor de autenticación adicional específico (por ejemplo, un certificado) para determinadas aplicaciones, pero un método diferente (Azure AD Multi-factor Authentication) para otras aplicaciones.

Para obtener este resultado, se puede emitir la notificación https://schemas.microsoft.com/claims/authnmethodsproviders de otras directivas de autenticación. El valor de esta notificación debe ser el nombre del proveedor de autenticación.

En 2019 ya se puede modificar la regla de notificación anterior para elegir proveedores de autenticación en función del escenario.

Transición de otro proveedor de autenticación a otro: puede modificar la regla mencionada anteriormente para elegir Azure AD Multi-factor Authentication para los usuarios que están en el grupo SID S-1-5-21-608905689-872870963-3921916988-12345. Por ejemplo, podría usar esta modificación en un grupo que administra por la empresa, que realiza un seguimiento de los usuarios registrados en Azure AD Multi-Factor Authentication. Esta modificación también funciona para el resto de los usuarios que un administrador quiere que usen la autenticación del certificado.

'c:[type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "https://schemas.microsoft.com/claims/multipleauthn" ); 

 c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-608905689-872870963-3921916988-12345"] => issue(Type = "`https://schemas.microsoft.com/claims/authnmethodsproviders`", Value = "AzureMfaAuthentication"); 

not exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value=="S-1-5-21-608905689-872870963-3921916988-12345"]) => issue(Type = "`https://schemas.microsoft.com/claims/authnmethodsproviders`", Value = "CertificateAuthentication");’

En este ejemplo se muestra cómo establecer dos proveedores de autenticación diferentes para dos aplicaciones diferentes:

Establezca la aplicación A para usar Azure AD Multi-Factor Authentication como proveedor de autenticación adicional:

Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules 'c:[type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "https://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication");'

Establezca la aplicación B para que use un certificado como proveedor de autenticación adicional:

Set-AdfsRelyingPartyTrust -TargetName AppB -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");'

Los administradores también pueden hacer reglas para permitir más de un proveedor de autenticación adicional. En este caso, AD FS muestra los proveedores de métodos de autenticación emitidos y un usuario puede elegir cualquiera de ellos. Para permitir varios proveedores de autenticación adicionales, deben emitir varias notificaciones https://schemas.microsoft.com/claims/authnmethodsproviders.

Si la evaluación de notificaciones no devuelve ninguno de los proveedores de autenticación, AD FS vuelve a mostrar todos los proveedores de autenticación adicionales configurados por el administrador en AD FS. A continuación, el usuario debe seleccionar el proveedor de autenticación adecuado.

Para ver todos los proveedores de autenticación adicionales permitidos, el administrador puede usar el cmdlet (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider. El valor de la notificación https://schemas.microsoft.com/claims/authnmethodsproviders debe ser alguno de los nombres de proveedor que devolvió el cmdlet anterior.

No hay soporte para activar un proveedor de autenticación adicional en particular si el RP está utilizando Políticas de control de acceso en AD FS Windows Server 2016 | Microsoft Docs. Cuando mueve una aplicación fuera de la política de control de acceso, AD FS copia la política correspondiente de la política de control de acceso a AdditionalAuthenticationRules y IssuanceAuthorizationRules. Por lo tanto, si un administrador quiere usar un proveedor de autenticación específico, puede dejar de usar la directiva de control de acceso y, a continuación, modificar el valor de AdditionalAuthenticationRules para activar dicho proveedor de autenticación adicional específico.

Preguntas más frecuentes

Cómo resolver el error de registros de eventos de Administración de AD FS "Solicitud de Oauth no válida recibida. El cliente 'NOMBRE' no tiene permiso para acceder al recurso con el ámbito 'ugs'".

Siga estos pasos para corregir el problema:

  1. Inicia la consola de administración de AD FS. Vaya a Servicios > Descripciones de ámbito.
  2. Seleccione más opciones en Descripciones del ámbito y seleccione Agregar descripción del ámbito.
  3. En nombre, introduzca "ugs" y seleccione Aplicar >Aceptar.
  4. Inicie PowerShell como Administrador.
  5. Ejecute el comando Get-AdfsApplicationPermission. Busque el objeto ScopeNames :{openid, aza} que tiene el ClientRoleIdentifier. Anote el ObjectIdentifier.
  6. Ejecute el comando Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs'.
  7. Reinicie el servicio AD FS.
  8. En el cliente, reinicie el cliente. Se le pedirá que configure Windows Hello para empresas (WHFB).
  9. Si la ventana de configuración no aparece, debe recopilar registros de seguimiento y solucionar problemas.

Cómo pasar un valor del recurso como parte del valor de ámbito de la misma forma en que se realizan las solicitudes en Azure AD.

Con AD FS en Server 2019, ahora puedes pasar el valor de recurso insertado en el parámetro de ámbito. Ahora, el parámetro de ámbito se puede organizar como una lista separada por espacios en la que cada entrada está estructurada como recurso/ámbito. Por ejemplo: <create a valid sample request>

¿AD FS admite la extensión PKCE?

AD FS en Server 2019 admite la clave de prueba para intercambio de código (PKCE) para el flujo de concesión de código de autorización de OAuth.

Novedades en Servicios de federación de Active Directory (AD FS) para Windows Server 2016

Si busca información sobre versiones anteriores de AD FS, consulte los siguientes artículos: AD FS en Windows Server 2012 o 2012 R2 y AD FS 2.0.

AD FS proporciona inicio de sesión único y control de acceso en una amplia variedad de aplicaciones, como Office 365, aplicaciones SaaS basadas en la nube, y aplicaciones en la red corporativa.

  • Para la organización de TI, permite proporcionar inicio de sesión y control de acceso a aplicaciones modernas y heredadas en cualquier máquina, basados en el mismo conjunto de credenciales y directivas.
  • Para el usuario, proporciona un inicio de sesión sin problemas con las mismas credenciales de cuenta conocidas.
  • Para el desarrollador, proporciona una manera sencilla de autenticar a los usuarios cuyas identidades se encuentran en el directorio de la organización, de forma que puedas centrar tus esfuerzos en la aplicación, no en la autenticación o la identidad.

Eliminar contraseñas de la extranet

AD FS 2016 habilita tres nuevas opciones para el inicio de sesión sin contraseñas, lo que permite a las organizaciones evitar el riesgo de poner en peligro la red a causa de contraseñas suplantadas, filtradas o robadas.

Iniciar sesión con la autenticación multifactor de Azure Active Directory

AD FS 2016 se basa en las capacidades de autenticación multifactor (MFA) de AD FS en Windows Server 2012 R2. Ahora puede permitir el inicio de sesión con solo un código de Azure AD Multi-Factor Authentication, sin escribir primero un nombre de usuario y una contraseña.

  • Con Azure AD Multi-Factor Authentication como método de autenticación principal, se solicita al usuario su nombre de usuario y el código OTP de la aplicación Azure Authenticator.
  • Con Azure AD Multi-Factor Authentication como método de autenticación secundario o adicional, el usuario proporciona credenciales de autenticación principal. Pueden iniciar sesión con la autenticación integrada de Windows, con su nombre de usuario y contraseña, tarjeta inteligente o un certificado de usuario o dispositivo. A continuación, ven una solicitud de inicio de sesión de Azure AD Multi-Factor Authentication de texto, voz o basada en OTP.
  • Con el nuevo adaptador integrado de Azure AD Multi-Factor Authentication, la configuración deAzure AD Multi-Factor Authentication con AD FS nunca ha sido más sencilla.
  • Las organizaciones pueden aprovechar Azure AD Multi-Factor Authentication sin necesidad de un servidor local de Azure AD Multi-Factor Authentication.
  • Azure AD Multi-Factor Authentication puede configurarse para la intranet o extranet, o como parte de cualquier directiva de control de acceso.

Para más información sobre Azure AD Multi-Factor Authentication con AD FS, consulte Configurar AD FS 2016 y Azure AD Multi-Factor Authentication.

Acceso sin contraseña desde dispositivos compatibles

AD FS 2016 se basa en las funcionalidades de registro de dispositivos anteriores para habilitar el inicio de sesión y el control de acceso en función del estado de cumplimiento del dispositivo. Los usuarios pueden iniciar sesión con las credenciales del dispositivo y el cumplimiento se vuelve a evaluar cuando cambian los atributos del dispositivo, de modo que siempre se garantiza la aplicación de las directivas. Esta característica habilita directivas como:

  • Habilitar el acceso solo desde dispositivos administrados y/o conformes.
  • Habilitar el acceso a extranet solo desde dispositivos administrados y/o conformes.
  • Solicitar la autenticación multifactor para equipos que no están administrados o conformes.

AD FS proporciona el componente local de las directivas de acceso condicional en un escenario híbrido. Al registrar los dispositivos con Azure AD para el acceso condicional a los recursos en la nube, la identidad del dispositivo puede usarse también para las directivas de AD FS.

Diagram of a hybrid solution and the relationships between users and on-premises active directory.

Para más información sobre el uso del acceso condicional basado en dispositivos en la nube, consulte Acceso condicional de Azure Active Directory.

Para obtener más información sobre el uso del acceso condicional basado en dispositivos con AD FS

Inicio de sesión con Windows Hello para empresas

Nota

Actualmente, Google Chrome y los nuevos exploradores del proyecto de código libre de Microsoft Edge basado en Chromium no se admiten para el inicio de sesión único (SSO) basado en explorador con Microsoft Windows Hello para empresas. Usa Internet Explorer o una versión anterior de Microsoft Edge.

Los dispositivos Windows 10 presentan Windows Hello y Windows Hello para empresas, que reemplazan las contraseñas de usuario con credenciales de usuario seguras enlazadas a un dispositivo y protegidas por un gesto de usuario (un PIN, un gesto de biometría como una huella digital, o reconocimiento facial). AD FS 2016 admite estas nuevas funcionalidades de Windows 10 para que los usuarios puedan iniciar sesión en las aplicaciones de AD FS desde la intranet o la extranet sin necesidad de proporcionar una contraseña.

Para obtener más información sobre el uso de Windows Hello para empresas en su organización, consulte Habilitar Windows Hello para empresas en la organización.

Acceso seguro a aplicaciones

Los siguientes cambios afectan al acceso seguro a las aplicaciones de AD FS.

Autenticación moderna

AD FS 2016 admite los protocolos modernos más recientes que proporcionan una mejor experiencia de usuario para Windows 10, así como para los dispositivos y aplicaciones iOS y Android más recientes.

Para obtener más información, consulte Escenarios de AD FS para desarrolladores.

Configuración de directivas de control de acceso sin tener que conocer el lenguaje de las reglas de notificaciones

Anteriormente, los administradores de AD FS tenían que configurar directivas mediante el lenguaje de reglas de notificaciones de AD FS, lo que dificultaba la configuración y mantenimiento de las directivas. Con las directivas de control de acceso, los administradores pueden usar las plantillas integradas para aplicar directivas comunes como las siguientes

  • Permitir solo el acceso de intranet.
  • Permitir todos y requerir MFA de Extranet.
  • Permitir todos y requerir MFA de extranet de un grupo específico.

Las plantillas son fáciles de personalizar mediante un proceso controlado por asistente para agregar excepciones o reglas de directiva adicionales, y se pueden aplicar a una o varias aplicaciones para una aplicación coherente de directivas.

Para más información, consulte Directivas de control de acceso en AD FS.

Habilitación del inicio de sesión con directorios LDAP que no son de AD

Muchas organizaciones tienen una combinación de directorios de Active Directory y terceros. Con la adición de la compatibilidad de AD FS con la autenticación de usuarios almacenados en directorios compatibles con Lightweight Directory Access Protocol (LDAP) v3, AD FS ahora se puede usar para:

  • Usuarios de directorios compatibles con LDAP v3 de terceros.
  • Usuarios de los bosques de Active Directory para los que no está configurada una confianza bidireccional de Active Directory.
  • Usuarios en Active Directory Lightweight Directory Services (AD LDS).

Para obtener más información, consulte Configure AD FS to authenticate users stored in LDAP directories.

Experiencia de inicio de sesión mejorada

Los siguientes cambios mejoran la experiencia de inicio de sesión de AD FS.

Personalización de la experiencia de inicio de sesión para aplicaciones de AD FS

Anteriormente, AD FS en Windows Server 2012 R2 ofrecía una experiencia de inicio de sesión común para todas las aplicaciones de usuarios de confianza, con la capacidad de personalizar un subconjunto de contenidos basados en texto para cada aplicación. Con Windows Server 2016, puedes personalizar no solo los mensajes, sino también las imágenes, el logotipo y el tema web por aplicación. Además, puede crear nuevos temas web personalizados y aplicarlos por usuario de confianza.

Para obtener más información, consulte Personalización del inicio de sesión del usuario de AD FS.

Mejoras operativas y de administración

En la siguiente sección se describen los escenarios operativos mejorados que se incluyen en Servicios de federación de Active Directory (AD FS) en Windows Server 2016.

Auditoría simplificada para facilitar la administración administrativa

En AD FS para Windows Server 2012 R2 se generaban muchos eventos de auditoría para una única solicitud y la información pertinente sobre una actividad de inicio de sesión o de emisión de tokens faltaba o se repartía en varios eventos de auditoría. De forma predeterminada, se desactivan los eventos de auditoría de AD FS debido a su naturaleza detallada. Con el lanzamiento de AD FS 2016, la auditoría se ha vuelto más simplificada y menos detallada.

Para obtener más información, consulte Mejoras de auditorías para AD FS en Windows Server 2016.

Mejora de la interoperabilidad con SAML 2.0 para participar en confederaciones

AD FS 2016 incluye compatibilidad con el protocolo SAML adicional, incluida la compatibilidad para importar relaciones de confianza basadas en metadatos que contienen varias entidades. Esto permite configurar AD FS para participar en confederaciones como InCommon Federation y otras implementaciones que se ajustan al estándar eGov 2.0.

Para obtener más información, consulte Interoperabilidad mejorada con SAML 2.0.

Administración simplificada de contraseñas para usuarios federados de Microsoft 365

Puedes configurar Servicios de federación de Active Directory (AD FS) para enviar notificaciones de expiración de contraseña a las relaciones de confianza para usuario autenticado (aplicaciones) que tienen la protección de AD FS. La forma en que se usan estas notificaciones depende de la aplicación. Por ejemplo, con Office 365 como usuario de confianza, se han implementado actualizaciones en Exchange y Outlook para notificar a los usuarios federados sobre las contraseñas que pronto van a expirar.

Para obtener más información, consulte Configuración de AD FS para enviar notificaciones de expiración de contraseña.

La migración de AD FS en Windows Server 2012 R2 a AD FS en Windows Server 2016 es más fácil

Anteriormente, la migración a una nueva versión de AD FS requería que se exportara la configuración de la granja anterior y se importara a una nueva granja de servidores en paralelo.

Ahora es mucho más fácil pasar de AD FS en Windows Server 2012 R2 a AD FS en Windows Server 2016. Agregue un nuevo servidor de Windows Server 2016 a una granja de Windows Server 2012 R2, y la granja actúa en el nivel de comportamiento de granja de Windows Server 2012 R2. El servidor ahora se ve y se comporta igual que una granja de Windows Server 2012 R2.

A continuación, agrega los nuevos servidores de Windows Server 2016 a la granja, comprueba que funcionen y quita los servidores más antiguos del equilibrador de carga. Una vez que todos los nodos de la granja estén ejecutando Windows Server 2016, estará listo para actualizar el nivel de comportamiento de la granja a 2016 y comenzar a usar las nuevas características.

Para obtener más información, consulta Actualización a AD FS en Windows Server 2016.