Compartir a través de


Arquitectura de aprovisionamiento de identidades de aplicaciones locales de Microsoft Entra

Información general

En el diagrama siguiente se muestra información general de cómo funciona el aprovisionamiento de aplicaciones locales.

Diagrama en el que se muestra la arquitectura para el aprovisionamiento de aplicaciones locales.

Existen tres componentes principales para el aprovisionamiento de usuarios en una aplicación local:

  • El agente de aprovisionamiento proporciona conectividad entre Microsoft Entra ID y el entorno local.
  • El host del conector extensible connectivity(ECMA) convierte las solicitudes de aprovisionamiento de Microsoft Entra ID en las solicitudes realizadas a la aplicación de destino. Actúa como puerta de enlace entre Microsoft Entra ID y la aplicación. Se puede usar para importar los conectores ECMA2 existentes que se utilizan con Microsoft Identity Manager. El host ECMA no es necesario si ha creado una aplicación SCIM o una puerta de enlace SCIM.
  • El servicio de aprovisionamiento de Microsoft Entra actúa como motor de sincronización.

Nota:

La sincronización de Microsoft Identity Manager no es necesaria. Pero puedes usarla para crear y probar el conector ECMA2 antes de importarlo en el host ECMA. El conector ECMA2 es específico de MIM, donde el host ECMA es específico para su uso con el agente de aprovisionamiento.

Requisitos de firewall

No es necesario abrir conexiones de entrada a la red corporativa. Los agentes de aprovisionamiento solo usan conexiones salientes al servicio de aprovisionamiento, lo que significa que no es necesario abrir los puertos de firewall para las conexiones entrantes. Tampoco necesitas una red perimetral (DMZ), porque todas las conexiones son salientes y se realizan por medio de un canal seguro.

Los puntos de conexión de salida necesarios para los agentes de aprovisionamiento se detallan aquí.

Arquitectura del host del conector de ECMA

El host del conector de ECMA tiene varias áreas que usa para el aprovisionamiento local. El diagrama siguiente es un dibujo conceptual que presenta estas áreas individuales. En la tabla siguiente se describen con más detalle.

Host del conector de ECMA

Área Descripción
Puntos de conexión Responsable de la comunicación y la transferencia de datos con el servicio de aprovisionamiento de Microsoft Entra
Caché en memoria Se usa para almacenar los datos importados desde el origen de datos local.
Sincronización automática Proporciona sincronización asincrónica de datos entre el host del conector de ECMA y el origen de datos local.
Lógica de negocios Se usa para coordinar todas las actividades del host del conector de ECMA. La hora de la sincronización automática se puede configurar en el host de ECMA. Está en la página de propiedades.

Acerca de los atributos delimitadores y los nombres distintivos

La siguiente información se proporciona para explicar mejor los atributos delimitadores y los nombres distintivos, que el conector de genericSQL usa especialmente.

El atributo delimitador es un atributo único de un tipo de objeto que no cambia y representa ese objeto en la memoria caché en memoria del host del conector de ECMA.

El nombre distintivo (DN) es un nombre que identifica de forma única un objeto indicando su ubicación actual en la jerarquía del directorio. O con SQL, en la partición. Para formar el nombre se concatena el atributo delimitador en la raíz de la partición de directorio.

Cuando se piensa en nombres distintivos tradicionales en formato tradicional, por ejemplo, de Active Directory o LDAP, se piensa en algo similar a:

CN=Lola Jacobson,CN=Users,DC=contoso,DC=com

Sin embargo, para un origen de datos como SQL, que es plano y no jerárquico, el nombre distintivo debe estar ya presente en una de las tablas, o bien crearse a partir de la información que proporcionamos al host del conector de ECMA.

Esto se consigue al marcar Autogenerated en la casilla al configurar el conector de genericSQL. Al elegir el DN generado automáticamente, el host ECMA generará uno en formato LDAP: CN=<anchorvalue>,OBJECT=<type>. También se presupondrá que la opción DN es delimitador se dejó sin activar en la página Conectividad.

Opción DN is Anchor (DN es delimitador) sin marcar

El conector de genericSQL espera que el nombre distintivo se rellene en formato LDAP. El conector de genericSQL usa el estilo de LDAP con el nombre de componente "OBJECT=". Esto le permite usar particiones (cada tipo de objeto es una partición).

Como el host del conector de ECMA actualmente solo admite el tipo de objeto USER, OBJECT=<type> será OBJECT=USER. Por lo tanto, el nombre distintivo de un usuario con un valor delimitador ljacobson sería:

CN=ljacobson,OBJECT=USER

Flujo de trabajo de creación de usuarios

  1. El servicio de aprovisionamiento de Microsoft Entra consulta el host del conector de ECMA para ver si el usuario existe. Usa como filtro el atributo coincidente. Este atributo se define en Azure Portal, en Aplicaciones empresariales -> Aprovisionamiento local -> Aprovisionamiento -> Coincidencia de atributos. Se indica en 1 para la precedencia coincidente. Puede definir uno o varios atributos coincidentes y priorizarlos. Si desea cambiar el atributo coincidente, también puede hacerlo. Atributo coincidente

  2. El host del conector de ECMA recibe la solicitud GET y consulta su caché interna para ver si el usuario existe y se ha importado. Esto se hace con los atributos coincidentes anteriores. Si defines varios atributos coincidentes, el servicio de aprovisionamiento de Microsoft Entra enviará una solicitud GET para cada atributo y el host ECMA comprobará si hay una coincidencia en la memoria caché hasta que se encuentre una.

  3. Si el usuario no existe, Microsoft Entra ID realizará una solicitud POST para crear el usuario. El host del conector de ECMA responderá a Microsoft Entra ID con HTTP 201 y proporcionará un identificador de usuario. Este identificador se deriva del valor delimitador definido en la página de tipos de objeto. Este delimitador lo usará Microsoft Entra ID para consultar el host del conector de ECMA en solicitudes futuras.

  4. Si se produce un cambio en el usuario de Microsoft Entra ID, Microsoft Entra ID realizará una solicitud GET para recuperar el usuario mediante el delimitador del paso anterior, en lugar del atributo coincidente del paso 1. Esto permite, por ejemplo, que el nombre principal de usuario cambie sin romper el vínculo entre el usuario de Microsoft Entra ID y la aplicación.

Procedimientos recomendados del agente

  • Actualmente no se admite el uso del mismo agente para la función de aprovisionamiento local junto con la sincronización en la nube de Workday / SuccessFactors / Microsoft Entra Connect. Estamos trabajando activamente para conseguir que se admita el uso de la característica de aprovisionamiento local en el mismo agente que se usa para los demás escenarios de aprovisionamiento.
    • Evita todo tipo de inspección insertada en las comunicaciones TLS salientes entre los agentes y Azure. Este tipo de inspección insertada provoca la degradación en el flujo de la comunicación.
  • El agente tiene que comunicarse con Azure y la aplicación; por eso la ubicación del agente afecta a la latencia de esas dos conexiones. Puedes probar a minimizar la latencia del tráfico de extremo a extremo optimizando cada conexión de red. Cada conexión se puede optimizar mediante uno de estos modos:
  • Reducir la distancia entre los dos extremos del salto.
  • Elegir la red adecuada por la que pasar. Por ejemplo, puede ser más rápido pasar por una red privada que por la red pública de Internet debido a los vínculos dedicados.
  • El agente y el host ECMA dependen de un certificado para la comunicación. El certificado autofirmado generado por el host ECMA solo debe usarse para realizar pruebas. El certificado autofirmado expira en dos años de forma predeterminada y no se puede revocar. Microsoft recomienda usar un certificado de una entidad de certificación de confianza para los casos de uso de producción.

Alta disponibilidad

La siguiente información se proporciona para escenarios de alta disponibilidad o conmutación por error.

Para las aplicaciones locales que usan el conector ECMA: la recomendación es tener 1 agente activo y 1 agente pasivo (configurado, pero detenido, no asignado a la aplicación empresarial en Entra) por centro de datos.

Al realizar una conmutación por error, se recomienda hacer lo siguiente:

  1. Detener el agente activo (A).
  2. Quitar la asignación del agente A de la aplicación empresarial.
  3. Reiniciar el agente pasivo (B).
  4. Asignar el agente B a la aplicación empresarial.

Diagrama de alta disponibilidad con el conector ECMA.

Para las aplicaciones locales que usan el conector SCIM, la recomendación es tener 2 agentes activos por aplicación.

Diagrama de alta disponibilidad con el conector SCIM.

Preguntas sobre el agente de aprovisionamiento

Aquí se responden algunas preguntas comunes.

¿Cómo puedo saber la versión del agente de aprovisionamiento?

  1. Inicia sesión en el servidor de Windows en el que está instalado el agente de aprovisionamiento.
  2. Ve a Panel de control>Desinstalar o cambiar un programa.
  3. Busca la versión correspondiente a la entrada agente de aprovisionamiento de Microsoft Entra Connect.

¿Puedo instalar el agente de aprovisionamiento en el mismo servidor que ejecuta Microsoft Entra Connect o Microsoft Identity Manager?

Sí. Puedes instalar el agente de aprovisionamiento en el mismo servidor que ejecuta Microsoft Entra Connect o Microsoft Identity Manager, pero no son necesarios.

¿Cómo se puede configurar el agente de aprovisionamiento para usar un servidor proxy para la comunicación HTTP saliente?

El agente de aprovisionamiento admite el uso de un proxy de salida. Puedes configurarlo si modificas el archivo de configuración del agente C:\Archivos de programa\Microsoft Azure AD Connect Provisioning Agent\AADConnectProvisioningAgent.exe.config. Agrega las líneas siguientes hacia el final del archivo, justo antes de la etiqueta </configuration> de cierre. Reemplaza las variables [proxy-server] y [proxy-port] con los valores del puerto y el nombre del servidor proxy.

 <system.net>
  <defaultProxy enabled="true" useDefaultCredentials="true">
    <proxy
     usesystemdefault="true"
     proxyaddress="http://[proxy-server]:[proxy-port]"
     bypassonlocal="true"
    />
   </defaultProxy>
 </system.net>

¿Cómo se garantiza que el agente de aprovisionamiento se pueda comunicar con el inquilino de Microsoft Entra y que ningún firewall bloquee los puertos que necesita el agente?

También puedes comprobar si todos los puertos necesarios están abiertos.

¿Cómo puedo desinstalar el agente de aprovisionamiento?

  1. Inicia sesión en el servidor de Windows en el que está instalado el agente de aprovisionamiento.
  2. Ve a Panel de control>Desinstalar o cambiar un programa.
  3. Desinstala los programas siguientes:
  • Agente de aprovisionamiento de Microsoft Entra Connect
  • Actualizador del agente de Microsoft Entra Connect
  • Paquete del agente de aprovisionamiento de Microsoft Entra Connect

Historial del agente de aprovisionamiento

En este artículo se enumeran las versiones y características del agente de aprovisionamiento de Microsoft Entra Connect que se han publicado. El equipo de Microsoft Entra actualiza periódicamente el agente de aprovisionamiento con nuevas características y funciones. Asegúrate de que no se usa el mismo agente para el aprovisionamiento local y el aprovisionamiento basado en la sincronización de la nube o que se realiza a través de RR. HH.

Microsoft proporciona soporte técnico directo para la versión más reciente del agente y una versión anterior.

El aprovisionamiento de aplicaciones locales se ha inscrito en el agente de aprovisionamiento y está disponible en el portal. Consulta el contenido Instalación del agente de aprovisionamiento.

1.1.892.0

20 de mayo de 2022: publicado para descarga

Problemas corregidos

  • Se ha agregado compatibilidad con la exportación de cambios a atributos enteros, lo que beneficia a los clientes que usan el conector LDAP genérico.

1.1.846.0

11 de abril de 2022: publicado para descarga

Problemas corregidos

  • Se ha agregado compatibilidad con ObjectGUID como anclaje para el conector LDAP genérico al aprovisionar usuarios en AD LDS.

Pasos siguientes