Comprensión de las reglas de notificaciones de AD FS junto con Azure AD

Azure AD Connect ayuda a los administradores a crear su propia granja de AD FS y conectarla a Azure AD. Pero si usa Azure AD Connect junto con AD FS para autenticar usuarios o administradores en Azure AD, le resultará muy difícil comprender las reglas de notificación establecidas por Azure AD Connect. Para los "novatos" de AD FS, las reglas de notificaciones son generalmente difíciles de entender. Y para los principiantes, quizás no haya nada más complicado que el llamado reglas de reclamación personalizadas. Profundicemos en las reglas de notificación generadas automáticamente para que pueda obtener una descripción general de la arquitectura de AD FS. En este tutorial, aprenderá cómo funcionan las reglas de notificación y qué hacen cuando un ID se autentica en Azure AD.

Índice

Arquitectura

Observe la siguiente arquitectura:

Esta arquitectura le muestra el flujo de trabajo de autenticación y sincronización, así como los componentes involucrados que se configurarán en la configuración de Azure AD Connect (consulte el rectángulo "En Enterprise"). Describe las diferentes partes de Azure que están involucradas o pueden estar involucradas, como las aplicaciones web. En este ejemplo, consideramos un bosque de dominios que tiene el mismo dominio DNS registrado en Azure.

flujo de trabajo

El dominio DNS registrado de Azure está federado y, por lo tanto, el proveedor de notificaciones o identificación es el Active Directory local, no Azure AD. Esto significa que tan pronto como un usuario inicie sesión en Azure Portal o en una aplicación web alojada en Azure que esté configurada para la autenticación de Azure AD, será redirigido a la granja de AD FS. Cuando un usuario ingresa un nombre de usuario en un cuadro de texto especial y deja un cuadro de texto de contraseña, el llamado Descubrimiento del reino de origen sucede como se puede ver a continuación:

Descubrimiento de dominio de inicio de Microsoft Azure, paso 1Descubrimiento del dominio de inicio de Microsoft Azure, paso 2

Microsoft Azure Home Realm Discovery, paso 3: distribuir AD FS

Azure busca el proveedor de ID adecuado mediante el sufijo de dominio "propassig.com" y accede a la granja de AD FS. Si desea obtener más información sobre las diferentes arquitecturas relacionadas con la identidad, puede encontrar recursos adicionales en Microsoft TechNet.

¡Comencemos a construir y revivir esta arquitectura!

Granja de AD FS

Con el instalador de Azure AD Connect, es fácil crear una granja AD FS simple, como se muestra a continuación. Sobre Canal 9 usted puede encontrar un muy buen tutorial presentado @ArturoLucatero sobre la configuración de una granja de AD FS con Azure AD Connect.

Después de completar el tutorial, tendrá más o menos la misma configuración que se muestra en el diagrama de arquitectura. La configuración crea automáticamente un Confía en la fiesta de confianza a Azure AD y también define reglas de reclamación esta parte de confianza en AD FS.

Es bueno conocer los términos de AD FS:

  • A Espero que la fiesta es casi nada más que una aplicación (en nuestro caso, Azure AD) que desea enviar notificaciones para autenticar a los usuarios o administradores.
  • A proveedor de reclamaciones suele ser Active Directory, que almacena los atributos necesarios para la autenticación. En algunos casos, también puede ser otro proveedor de ID, como el proveedor de ID SAML 2.0, que envía la respuesta SAML a AD FS.
  • A reclamar sin embargo, es un atributo que puede identificar a una persona. Por ejemplo, el atributo Nombre principal de usuario (UPN) de Active Directory.

Revisión de las reglas de reclamación

Las reglas de notificaciones dentro de AD FS se aplican al proveedor de notificaciones y del lado de la parte dependiente.

Lado del proveedor de reclamacionesEspera el lado del partido

En total, hay cinco tipos de reglas de reclamación:

  • Enviar atributos LDAP como reclamos: tales reglas simplemente emiten atributos LDAP, p. UPN o correo. Se agregarán a la respuesta a la demanda enviada al síndico.
  • Enviar la pertenencia a un grupo como notificación: casi lo mismo que el primer tipo de regla, pero emite la pertenencia a un grupo de AD en respuesta enviada por el administrador.
  • Conversión de reclamos entrantes: esta regla transforma reclamos preespecificados. Por ejemplo, en respuesta a un reclamo de un proveedor de reclamos (AD), hay un reclamo Dirección de correo electrónico emitido, pero la parte de confianza espera que el reclamo sea el precio Nombre del identificador. Entonces puedo usar esta regla para transferir valores de un reclamo a otro.
  • Omitir o filtrar reclamos entrantes: esta regla le permite omitir reclamos enviados por el proveedor de reclamos o filtrar/editar valores, como cambiar el sufijo de dominio.
  • Reglas de notificación personalizadas: las reglas más complejas son las reglas personalizadas porque pueden combinar todas las reglas anteriores y trabajar con expresiones regulares.

Reglas de notificaciones de proveedores de notificaciones estándar

Veamos las reglas de requisitos predeterminadas para proveedor de reclamaciones:

Reglas de notificaciones para Active Directory

Como puedes ver, es bastante fácil de entender. Cuando inicia sesión en el sitio web de AD FS con sus contraseñas, todas estas notificaciones se emiten con sus credenciales.

Reglas de reclamos de fideicomisario de forma predeterminada

Por otro lado, el conjunto de reglas que se basan en la mano es mucho más complejo:

Reglas de reclamos de fideicomisarios

La regla de las reclamaciones del proveedor de las primeras reclamaciones

Tenga en cuenta que todas las reglas son reglas de usuario. Veamos la primera regla:

La regla de las reclamaciones del proveedor de las primeras reclamaciones

Comencemos desde arriba:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]

Esto es lo que esperamos reclamos de tipo entrantes ventanas de nombre de cuenta que es básicamente el siguiente valor: Nombre de dominio usuario.

Segunda parte:

issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/UPN", "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID")

significa usar el requisito establecido en el primer párrafo (ventanas de nombre de cuenta) queremos emitir dos nuevos reclamosUPN y ID inmutable) utilizando Active Directory como repositorio de atributos. ID inmutable este es un atributo que se seleccionó previamente como enlace predeterminado en la configuración de Azure AD Connect. Este identificador se usa como un identificador único para autenticarse en el arrendatario de Azure AD.

La tercera parte de la regla es la consulta que usamos para ver el AD y encontrar los valores deseados. He identificado dos parámetros que se utilizarán en la consulta:

 , query = "samAccountName={0};userPrincipalName,objectGUID;{1}", param = regexreplace(c.Value, "(?<domain>[^\]+)\(?<user>.+)", "${user}"), param = c.Value);

Creo que esto se explica mejor usando SQL. La misma consulta se vería así en SQL:

ALTER AUTHORIZATION ON Base de datos::'Active Directoy' TO 'DOMAINUsername';
SELECT userPrincipalName,objectGUID FROM 'Active Directoy' WHERE samAccountName='Username';

Los valores obtenidos por nosotros serán preservados en las reclamaciones UPN y ID inmutable.

La regla de notificaciones del segundo proveedor de notificaciones

La siguiente regla es la última que necesitamos para autenticar a los usuarios. Todas las demás reglas definidas en el conjunto se usan para autenticar/identificar los equipos con Windows 10 a los que está conectado Azure AD. Ver Únase a Azure AD en dispositivos con Windows 10 para más información.

La regla de notificaciones del segundo proveedor de notificaciones

En esta regla, simplemente emitimos un reclamo bajo el título identificación del nombre y establecer el valor de este requisito al mismo que el valor almacenado en el archivo ID inmutable reclamar. Además, añadimos otra propiedad a esta afirmación. Esto se hace usando la palabra clave "Propiedades". Esto establece el formato de notificación como "urna: oasis: nombres: tc: SAML: 1.1: formato de ID de nombre: no especificado", que espera a Azure AD.

Por cierto: También puede definir sus propios tipos de requisitos, por ejemplo "http://temp.org/NombreDominio" para mantener los valores/atributos en él!

¡Aquí estamos! Todas las reclamaciones que hemos emitido (UPN, Id. inmutable, Identificador de nombre) se enviará a Azure AD. Azure AD comprueba si la identidad puede ver Azure Portal y autoriza la identidad cuando está configurada. AD FS usa el formato de token SAML para enviar una respuesta a Azure AD, que se puede ver al realizar un seguimiento de una secuencia mediante violinista.

Ahora está listo para trabajar con reglas de notificaciones personalizadas en AD FS junto con Azure AD/Connect.


Artículos de interés

Subir

Si continuas utilizando este sitio aceptas el uso de cookies. Más información