Compartir vía

Configuración de Microsoft Entra ID para aprovisionar usuarios en directorios LDAP

  • Artículo

La siguiente documentación proporciona información de configuración y tutoriales que demuestran cómo aprovisionar usuarios desde Microsoft Entra ID a un directorio LDAP.

En este documento se describen los pasos que hay que realizar para aprovisionar y desaprovisionar automáticamente usuarios de Microsoft Entra ID en un directorio LDAP. El documento ilustra cómo puede aprovisionar usuarios en AD LDS como un directorio LDAP de ejemplo, pero se pueden aprovisionar en cualquiera de los servidores de directorios LDAP admitidos que se mencionan en las siguientes secciones. No se admite el aprovisionamiento de usuarios en Active Directory Domain Services a través de esta solución.

Para obtener detalles importantes sobre lo que hace este servicio, cómo funciona y las preguntas más frecuentes, consulte Automatizar el aprovisionamiento y desaprovisionamiento de usuarios a aplicaciones SaaS con Microsoft Entra ID y la arquitectura de aprovisionamiento de aplicaciones locales. El siguiente vídeo proporciona información general sobre el aprovisionamiento local.

Requisitos previos para aprovisionar usuarios en un directorio LDAP

Requisitos previos locales

  • Una aplicación que usa un servidor de directorios para consultar a los usuarios.
  • Un directorio de destino, distinto de Active Directory Domain Services, donde se pueden crear, actualizar y eliminar usuarios. Por ejemplo, Active Directory Lightweight Services (AD LDS). Esta instancia de directorio no debe ser un directorio que también se utilice para aprovisionar usuarios en Microsoft Entra ID, porque tener ambos escenarios puede crear un bucle con Microsoft Entra Connect.
  • Un equipo con al menos 3 GB de RAM para hospedar un agente de aprovisionamiento. El equipo debe tener Windows Server 2016 o una versión posterior, con conectividad al sistema de directorio de destino y con conectividad saliente a login.microsoftonline.com y otros dominios de Microsoft Online Services y Azure. Un ejemplo es una máquina virtual de Windows Server 2016 hospedada en IaaS de Azure o detrás de un proxy.
  • Tiene que tener instalado .NET Framework 4.7.2.
  • Opcional: aunque no es necesario, se recomienda descargar Microsoft Edge para Windows Server y usarlo en lugar de Internet Explorer.

Servidores de directorios LDAP compatibles

El conector se basa en diversas técnicas para detectar e identificar el servidor LDAP. El conector utiliza el DSE de raíz, el nombre y la versión del proveedor, e inspecciona el esquema para buscar objetos únicos y atributos que se sabe que existen en determinados servidores LDAP.

  • OpenLDAP
  • Microsoft Active Directory Lightweight Directory Services
  • 389 Directory Server
  • Apache Directory Server
  • IBM Tivoli DS
  • Isode Directory
  • NetIQ eDirectory
  • Novell eDirectory
  • Open DJ
  • Open DS
  • Oracle (anteriormente, Sun ONE) Directory Server Enterprise Edition
  • RadiantOne Virtual Directory Server (VDS)

Para obtener más información, consulte la Referencia del conector LDAP genérico.

Requisitos de la nube

  • Un inquilino de Microsoft Entra con Microsoft Entra ID P1 o Premium P2 (o EMS E3 o E5).

    El uso de esta característica requiere una licencia Microsoft Entra ID P1. Para encontrar la licencia que más se ajuste a sus requisitos, consulte la Comparación de las características de disponibilidad general de Microsoft Entra ID.

  • El rol Administrador de identidad híbrida para configurar el agente de aprovisionamiento y los roles Administrador de aplicaciones o Administrador de aplicaciones en la nube para configurar el aprovisionamiento en Azure Portal.

  • Los usuarios de Microsoft Entra que se aprovisionarán en el directorio LDAP ya deben contar con los atributos que necesitará el esquema del servidor de directorios y que son específicos de cada usuario. Por ejemplo, si el servidor de directorios requiere que cada usuario tenga un número único entre 10000 y 30000 como su número de id. de usuario para admitir una carga de trabajo POSIX, deberá generar ese número de un atributo existente en el usuario, o bien, ampliar el esquema de Microsoft Entra y rellenar ese atributo en los usuarios en el ámbito de la aplicación basada en LDAP. Consulte la Extensibilidad de Graph para obtener información sobre cómo crear extensiones de directorio adicionales.

Más limitaciones y recomendaciones

Los siguientes puntos de viñeta son más recomendaciones y limitaciones.

  • No se recomienda usar el mismo agente para la sincronización en la nube y el aprovisionamiento de aplicaciones local. Microsoft recomienda usar un agente independiente para la sincronización en la nube y otro para el aprovisionamiento de aplicaciones local.
  • Actualmente, para AD LDS, los usuarios no se pueden aprovisionar con contraseñas. Por lo tanto, deberá deshabilitar la directiva de contraseñas para AD LDS o aprovisionar los usuarios en un estado deshabilitado.
  • En el caso de otros servidores de directorios, se puede establecer una contraseña aleatoria inicial, pero no es posible aprovisionar la contraseña de un usuario de Microsoft Entra en un servidor de directorios.
  • No se admite el aprovisionamiento de Microsoft Entra ID a Active Directory Domain Services.
  • No se admite el aprovisionamiento de usuarios de LDAP a Microsoft Entra ID.
  • No se admite el aprovisionamiento de pertenencias de grupos y usuarios a un servidor de directorios.

Selección de perfiles de ejecución

Al crear la configuración para que el conector interactúe con un servidor de directorios, primero deberá configurar la lectura del esquema del directorio por parte del conector, asignar ese esquema al esquema de Microsoft Entra ID y, a continuación, configurar el enfoque que el conector debe usar de forma continua con perfiles de ejecución. Cada perfil de ejecución que configure especificará cómo generará el conector solicitudes LDAP para importar o exportar datos desde el servidor de directorios. Antes de implementar el conector en un servidor de directorios existente, tendrá que analizar con el operador del servidor de directorios de la organización el patrón de las operaciones que se realizarán con el servidor de directorios.

  • Después de la configuración, cuando se inicie el servicio de aprovisionamiento, realizará automáticamente las interacciones configuradas en el perfil de ejecución Full Import (Importación completa). En este perfil de ejecución, el conector leerá todos los registros de los usuarios del directorio mediante una operación de búsqueda de LDAP. Este perfil de ejecución es necesario para que, más adelante, si Microsoft Entra ID necesita realizar un cambio para un usuario, actualice un objeto existente de ese usuario en el directorio, en lugar de crear un objeto nuevo para el usuario.

  • Cada vez que se realizan cambios en Microsoft Entra ID, como asignar un nuevo usuario a la aplicación o actualizar un usuario existente, el servicio de aprovisionamiento realizará las interacciones de LDAP del perfil de ejecución Exportación. En el perfil de ejecución Exportación, Microsoft Entra ID emitirá solicitudes LDAP a objetos Add, Modify, Remove o Rename del directorio para sincronizar el contenido del directorio con Microsoft Entra ID.

  • Si el directorio lo admite, también puede configurar un perfil de ejecución Importación diferencial. En este perfil de ejecución, Microsoft Entra ID leerá los cambios realizados en el directorio, distintos de los realizados por Microsoft Entra ID, desde la última importación completa o diferencial. Este perfil de ejecución es opcional, ya que es posible que el directorio no se haya configurado para admitir una importación diferencial. Por ejemplo, si su organización usa OpenLDAP, OpenLDAP debe haberse implementado con la característica de superposición de registros de acceso habilitada.

Determinación de cómo va a interactuar el conector LDAP de Microsoft Entra con el servidor de directorios

Antes de implementar el conector en un servidor de directorios existente, deberá analizar con el operador del servidor de directorios de la organización cómo integrarlo con el servidor de directorios. La información que va a recopilar incluye la información de red de cómo conectarse al servidor de directorios, cómo se debe autenticar el propio conector en el servidor de directorios, qué esquema ha seleccionado el servidor de directorios para modelar usuarios, las reglas de la jerarquía de directorios y nombres distintivos base del contexto de nomenclatura, cómo asociar los usuarios del servidor de directorios a usuarios de Microsoft Entra ID, y qué debe ocurrir cuando un usuario sale del ámbito en Microsoft Entra ID. La implementación de este conector puede requerir cambios en la configuración del servidor de directorios, así como cambios de configuración en Microsoft Entra ID. En el caso de las implementaciones que implican la integración de Microsoft Entra ID con un servidor de directorios de terceros en un entorno de producción, se recomienda que los clientes trabajen con el proveedor del servidor de directorios o con un asociado de implementación para obtener ayuda, instrucciones y soporte técnico para esta integración. En este artículo se usan los siguientes valores de ejemplo para dos directorios, para AD LDS y para OpenLDAP.

Opción de configuración Dónde se establece el valor Valor de ejemplo
nombre de host del servidor de directorios Página Conectividad del Asistente para configuración APP3
número de puerto del servidor de directorios Página Conectividad del Asistente para configuración 636. Para LDAP sobre SSL o TLS (LDAPS), use el puerto 636. Para Start TLS, use el puerto 389.
cuenta para que el conector se identifique a sí mismo en el servidor de directorios Página Conectividad del Asistente para configuración Para AD LDS, CN=svcAccountLDAP,CN=ServiceAccounts,CN=App,DC=contoso,DC=lab y para OpenLDAP, cn=admin,dc=contoso,dc=lab
contraseña para que el conector se autentique a sí mismo en el servidor de directorios Página Conectividad del Asistente para configuración
clase de objeto estructural de un usuario en el servidor de directorios Página Tipos de objeto del Asistente para configuración Para AD LDS User y para OpenLDAP inetOrgPerson
clases de objetos auxiliares de un usuario en el servidor de directorios Asignaciones de atributos de la página Aprovisionamiento de Azure Portal Para OpenLDAP con el esquema POSIX, posixAccount y shadowAccount
atributos que se van a rellenar en un nuevo usuario Página Seleccionar Atributos del Asistente para configuración y asignaciones de atributos de la página Aprovisionamiento de Azure Portal Para AD LDS msDS-UserAccountDisabled, userPrincipalName y displayName, y para OpenLDAP cn, gidNumber, homeDirectory, mail, objectClass, sn, uid, uidNumber, userPassword
jerarquía de nomenclatura requerida por el servidor de directorios Asignaciones de atributos de la página Aprovisionamiento de Azure Portal Establezca el DN de un usuario recién creado para que esté inmediatamente debajo de CN=CloudUsers,CN=App,DC=Contoso,DC=lab para AD LDS y de DC=Contoso,DC=lab para OpenLDAP
atributos para correlacionar los usuarios entre Microsoft Entra ID y el servidor de directorios Asignaciones de atributos de la página Aprovisionamiento de Azure Portal Para AD LDS, que no está configurado, ya que este ejemplo es para un directorio inicialmente vacío para OpenLDAP, mail
comportamiento del desaprovisionamiento cuando un usuario sale del ámbito en Microsoft Entra ID Página Desaprovisionamiento del Asistente para configuración Eliminar el usuario del servidor de directorios

La dirección de red de un servidor de directorios es un nombre de host y un número de puerto TCP, normalmente el puerto 389 o 636. Excepto en los casos en los que el servidor de directorios está ubicado conjuntamente con el conector en el mismo servidor de Windows Server o en los que usa la seguridad de nivel de red, las conexiones de red del conector a un servidor de directorios se deben proteger mediante SSL o TLS. El conector admite la conexión a un servidor de directorios en el puerto 389 y el uso de Start TLS para habilitar TLS dentro de la sesión. El conector también admite la conexión a un servidor de directorios en el puerto 636 para LDAPS: LDAP sobre TLS.

Deberá tener ya configurada en el servidor de directorios una cuenta identificada para que el conector se autentique en el servidor de directorios. Esta cuenta se identifica normalmente con un nombre distintivo y tiene asociada una contraseña o un certificado de cliente. Para realizar operaciones de importación y exportación en los objetos del directorio conectado, la cuenta del conector debe tener permisos suficientes en el modelo de control de acceso del directorio. El conector necesita tener permisos de escritura para poder exportar y permisos de lectura para poder importar. La configuración de permiso se realiza dentro de las experiencias de administración del propio directorio de destino.

Un esquema de directorio especifica las clases de objeto y los atributos que representan una entidad real en el directorio. El conector admite que un usuario se represente con una clase de objeto estructural, como inetOrgPerson, y, opcionalmente, clases de objetos auxiliares adicionales. Para que el conector pueda aprovisionar usuarios en el servidor de directorios, durante la configuración en Azure Portal definirá asignaciones del esquema de Microsoft Entra a todos los atributos obligatorios. Esto incluye los atributos obligatorios de la clase de objeto estructural, las superclases de esa clase de objeto estructural y los atributos obligatorios de cualquier clase de objeto auxiliar. Además, es probable que también configure asignaciones a algunos de los atributos opcionales de estas clases. Por ejemplo, un servidor de directorios OpenLDAP podría requerir un objeto para que un nuevo usuario tenga atributos como los del ejemplo siguiente.

dn: cn=bsimon,dc=Contoso,dc=lab
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
cn: bsimon
gidNumber: 10000
homeDirectory: /home/bsimon
sn: simon
uid: bsimon
uidNumber: 10011
mail: bsimon@contoso.com
userPassword: initial-password

Las reglas de jerarquía de directorio implementadas por un servidor de directorios describen cómo se relacionan los objetos de cada usuario entre sí y con los objetos existentes en el directorio. En la mayoría de las implementaciones, la organización eligió tener una jerarquía plana en el servidor de directorios, en la que cada objeto de un usuario se encuentra inmediatamente debajo de un objeto base común. Por ejemplo, si el nombre distintivo base del contexto de nomenclatura en un servidor de directorios es dc=contoso,dc=com, un nuevo usuario tendría un nombre distintivo similar a cn=alice,dc=contoso,dc=com. Sin embargo, algunas organizaciones pueden tener una jerarquía de directorios más compleja, en cuyo caso deberá implementar las reglas al especificar la asignación de nombres distintivos para el conector. Por ejemplo, un servidor de directorios puede esperar que los usuarios estén en unidades organizativas por departamento, por lo que un nuevo usuario tendría un nombre distintivo similar a cn=alice,ou=London,dc=contoso,dc=com. Dado que el conector no crea objetos intermedios para las unidades organizativas, los objetos intermedios que espera la jerarquía de reglas del servidor de directorios ya deben existir en el servidor de directorios.

A continuación, deberá definir las reglas de cómo debe determinar el conector si ya hay un usuario en el servidor de directorios correspondiente a un usuario de Microsoft Entra. Cada directorio LDAP tiene un nombre distintivo que es único para cada objeto del servidor de directorios, pero ese nombre distintivo a menudo no está presente para los usuarios de Microsoft Entra ID. En su lugar, una organización puede tener otro atributo, como mail o employeeId, en su esquema de servidor de directorios que también esté presente en los usuarios de Microsoft Entra ID. A continuación, cuando el conector está aprovisionando un nuevo usuario en un servidor de directorios, el conector puede buscar si ya hay un usuario en ese directorio que tenga un valor específico de ese atributo y crear un nuevo usuario en el servidor de directorios solo si no hay uno presente.

Si el escenario implica crear nuevos usuarios en el directorio LDAP, no solo actualizar o eliminar los usuarios existentes, deberá determinar también cómo controlarán la autenticación las aplicaciones que usan ese servidor de directorios. El enfoque recomendado es que las aplicaciones usen un protocolo de federación o SSO, como SAML, OAuth o OpenID Connect para autenticarse en Microsoft Entra ID y basarse solo en el servidor de directorios para los atributos. Tradicionalmente, las aplicaciones podían usar directorios LDAP para autenticar a los usuarios comprobando una contraseña, pero este caso de uso no es posible para la autenticación multifactor o cuando el usuario ya se ha autenticado. Algunas aplicaciones pueden consultar una clave pública o certificado SSH de un usuario desde el directorio, lo cual puede ser adecuado para los usuarios que ya tienen credenciales de esos formularios. Sin embargo, si la aplicación que se basa en el servidor de directorios no admite protocolos de autenticación modernos ni credenciales más seguras, deberá establecer una contraseña específica de la aplicación al crear un nuevo usuario en el directorio, ya que Microsoft Entra ID no admite el aprovisionamiento de la contraseña de Microsoft Entra de un usuario.

Por último, deberá llegara a un acuerdo sobre el comportamiento del desaprovisionamiento. Cuando el conector está configurado y Microsoft Entra ID ha establecido un vínculo entre un usuario de Microsoft Entra ID y un usuario del directorio, ya sea para un usuario que ya se encuentra el directorio o uno nuevo, Microsoft Entra ID puede aprovisionar los cambios de atributo del usuario de Microsoft Entra en el directorio. Si un usuario asignado a la aplicación se elimina en Microsoft Entra ID, entonces Microsoft Entra ID enviará una operación de eliminación al servidor de directorios. También es posible que quiera que Microsoft Entra ID actualice el objeto en el servidor de directorios cuando un usuario sale del ámbito de poder usar la aplicación. Este comportamiento depende de la aplicación que va a usar el servidor de directorios, ya que muchos directorios, como OpenLDAP, puede que no tengan una manera predeterminada de indicar que la cuenta de un usuario está inactiva.

Preparación del directorio LDAP

Si aún no tiene un servidor de directorios y quiere probar esta característica, Preparación de Active Directory Lightweight Directory Services para el aprovisionamiento desde Microsoft Entra ID muestra cómo crear un entorno de prueba de AD LDS. Si ya tiene otro servidor de directorios implementado, puede omitir ese artículo y continuar con la instalación y configuración del host del conector ECMA.

Instalación y configuración del agente de aprovisionamiento de Microsoft Entra Connect

Si ya ha descargado el agente de aprovisionamiento y lo ha configurado para otra aplicación local, continúe la lectura en la sección siguiente.

  1. Inicie sesión en Azure Portal.
  2. Vaya a Aplicaciones empresariales y seleccione Nueva aplicación.
  3. Busque la aplicación ECMA local, asigne un nombre a la aplicación y seleccione Crear para agregarla al inquilino.
  4. En el menú, vaya a la página de aprovisionamiento de la aplicación.
  5. Seleccione Comenzar.
  6. En la página Aprovisionamiento, cambie el modo a Automático.

Captura de pantalla de cómo seleccionar Automático.

  1. En Conectividad local, seleccione Descargar e instalar y seleccione Aceptar términos descargar.

Captura de pantalla de la ubicación de descarga del agente.

  1. Salga del portal y abra el instalador del agente de aprovisionamiento, acepte los términos de servicio y seleccione Instalar.
  2. Espere al Asistente para configuración del agente de aprovisionamiento de Microsoft Entra y, después, seleccione Siguiente.
  3. En el paso Seleccione la extensión, seleccione Aprovisionamiento de aplicaciones locales y Siguiente.
  4. El agente de aprovisionamiento usa el navegador web del sistema operativo para mostrar una ventana emergente para que el usuario se autentique en Microsoft Entra ID y, potencialmente, también en el proveedor de identidades de su organización. Si usa Internet Explorer como explorador en Windows Server, es posible que tenga que agregar sitios web de Microsoft a la lista de sitios de confianza del explorador para permitir que JavaScript se ejecute correctamente.
  5. Proporcione las credenciales de un administrador de Microsoft Entra cuando se le solicite para la autorización. El usuario debe tener al menos el rol de Administrador de identidades híbridas.
  6. Seleccione Confirmar para confirmar la configuración. Una vez que la instalación se haya realizado correctamente, puede seleccionar Salir y cerrar también el instalador de paquete del agente de aprovisionamiento.

Configuración de la aplicación ECMA local

  1. Vuelva al portal y, en la sección Conectividad local, seleccione el agente que ha implementado y seleccione Asignar agentes.

    Captura de pantalla en la que se muestra cómo seleccionar y asignar un agente.

  2. Mantenga abierta esta ventana del explorador, ya que completará el siguiente paso de configuración con el Asistente para configuración.

Configurar el certificado de host del conector ECMA de Microsoft Entra

  1. En la instancia de Windows Server donde está instalado el agente de aprovisionamiento, haga clic con el botón derecho en el Asistente para configuración de Microsoft ECMA2Host desde el menú Inicio y ejecútelo como administrador. Debe ejecutarlo como administrador de Windows para que el asistente cree los registros de eventos de Windows necesarios.
  2. Una vez que se inicie la configuración del host del conector ECMA, si es la primera vez que se ha ejecutado el asistente, se le pedirá que cree un certificado. Deje el puerto predeterminado 8585 y seleccione Generar certificado para generar un certificado. El certificado autogenerado se firma automáticamente como parte de la raíz de confianza. SAN coincide con el nombre de host. Captura de pantalla que muestra la configuración de los valores.
  3. Seleccione Guardar.

Nota:

Si ha elegido generar un nuevo certificado, registre la fecha de expiración del certificado para asegurarse de que establece una programación a fin de regresar al asistente de configuración y volver a generar el certificado antes de que expire.

Configuración de un conector LDAP genérico

En función de las opciones que seleccione, es posible que algunas de las pantallas del asistente no estén disponibles y que la información sea ligeramente diferente. Para los fines de esta configuración de ejemplo, se muestra el aprovisionamiento de usuarios con la clase de objeto User para AD LDS y la clase de objeto inetOrgPerson para OpenLDAP. Use la siguiente información como orientación para la configuración.

  1. Genere un token secreto que se usará para autenticar Microsoft Entra ID en el conector. Debe tener un mínimo de 12 caracteres y un valor único para cada aplicación. Si aún no tiene un generador de secretos, puede usar un comando de PowerShell como el siguiente para generar una cadena aleatoria de ejemplo.

    -join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})

  2. Si aún no lo ha hecho, inicie el Asistente para configuración de Microsoft ECMA2Host desde el menú Inicio.

  3. Seleccione Nuevo conector. Captura de pantalla que muestra que se ha seleccionado Nuevo conector.

  4. En la página Propiedades, rellene los cuadros con los valores especificados en la tabla que sigue a la imagen y seleccione Siguiente. Captura de pantalla que muestra la especificación de propiedades.

    Propiedad. Valor
    Nombre El nombre que eligió para el conector, que debe ser único en todos los conectores del entorno. Por ejemplo, LDAP.
    Temporizador de sincronización automática (minutos) 120
    Token secreto Escriba aquí el token secreto. Debe tener un mínimo de 12 caracteres.
    DLL de extensión Para un conector LDAP genérico, seleccione Microsoft.IAM.Connector.GenericLdap.dll.

  5. En la página Conectividad, configurará cómo se comunicará el host del conector ECMA con el servidor de directorios y establecerá algunas de las opciones de configuración. Rellene los cuadros con los valores especificados en la tabla que sigue a la imagen y seleccione Siguiente. Al seleccionar Siguiente, el conector consultará el servidor de directorios para su configuración. Captura de pantalla que muestra la página Conectividad

    Propiedad. Descripción
    Host Nombre del host donde se encuentra el servidor LDAP. En este ejemplo se usa APP3 como nombre de host de ejemplo.
    Port Número de puerto TCP. Si el servidor de directorios está configurado para LDAP a través de SSL, use el puerto 636. Para Start TLS, o si usa la seguridad de nivel de red, use el puerto 389.
    Tiempo de espera de la conexión 180
    Enlace Esta propiedad especifica cómo se autenticará el conector en el servidor de directorios. Con la opción Basic, o con la opción SSL o TLS y ningún certificado de cliente configurado, el conector enviará un enlace simple de LDAP para autenticarse con un nombre distintivo y una contraseña. Con la opción SSL o TLS y un cliente de certificado especificado, el conector enviará un enlace EXTERNAL SASL LDAP para autenticarse con un certificado de cliente.
    Nombre de usuario Cómo se autenticará el conector de ECMA en el servidor de directorios. En este ejemplo de AD LDS, el nombre de usuario de ejemplo es CN=svcAccount,CN=ServiceAccounts,CN=App,DC=contoso,DC=lab y para OpenLDAP, cn=admin,dc=contoso,dc=lab
    Contraseña La contraseña del usuario que el conector ECMA se autenticará en el servidor de directorios.
    Dominio kerberos o dominio Esta configuración solo es necesaria si ha seleccionado Kerberos como opción de enlace para proporcionar el dominio kerberos o dominio del usuario.
    Certificado La configuración de esta sección solo se usa si ha seleccionado SSL o TLS como opción de enlace.
    Alias de atributo El cuadro de texto Alias de atributo se utiliza para los atributos definidos en el esquema con la sintaxis RFC4522. Estos atributos no se pueden detectar durante la detección del esquema y el conector necesita ayuda para identificarlos. Por ejemplo, si el servidor de directorios no publica userCertificate;binary y quiere aprovisionar ese atributo, se debe escribir la siguiente cadena en el cuadro alias de atributo para identificar correctamente el atributo userCertificate como atributo binario: userCertificate;binary. Si no necesita ningún atributo especial que no esté en el esquema, puede dejar esto en blanco.
    Inclusión de atributos operativos Seleccione la casilla Include operational attributes in schema para incluir también los atributos que ha creado el servidor de directorios. Estos incluyen atributos como la fecha y la hora de creación del objeto y la de la última actualización.
    Inclusión de atributos extensibles Seleccione la casilla Include extensible attributes in schema si se usan objetos extensibles (RFC4512/4.3) en el servidor de directorios. Habilitar esta opción permite que todos los atributos se usen en todos los objetos. Seleccionar esta opción hace que el esquema sea muy grande por lo que, a menos que el directorio conectado utilice esta característica, le recomendamos que mantenga la opción desactivada.
    Permitir la selección manual del delimitador Deje la opción desactivada.

    Nota

    Si experimenta un problema al intentar conectarse, y no puede continuar a la página Global, asegúrese de que la cuenta de servicio de AD LDS o su otro servidor de directorios estén habilitados.

  6. En la página Global, configurará el nombre distintivo del registro de cambios diferenciales, si es necesario, así como características LDAP adicionales. La página se rellena automáticamente con la información proporcionada por el servidor LDAP. Revise los valores que se muestran y, a continuación, seleccione Siguiente.

    Propiedad Descripción
    Mecanismos SASL admitidos En la sección superior se muestra la información proporcionada por el propio servidor, incluida la lista de mecanismos SASL.
    Detalles del certificado de servidor Si se especificó SSL o TLS, el asistente mostrará el certificado devuelto por el servidor de directorios. Confirme que el emisor, el asunto y la huella digital son para el servidor de directorios correcto.
    Características obligatorias encontradas El conector también comprueba que los controles obligatorios estén presentes en el DSE de raíz. Si no se muestran, aparece una advertencia. Algunos directorios LDAP no muestran todas las características en el DSE de raíz y es posible que el conector funcione sin problemas incluso si aparece una advertencia.
    Controles compatibles Las casillas de controles compatibles controlan el comportamiento de ciertas operaciones.
    Importación delta El DN del registro de cambios es el contexto de nomenclatura utilizado por el registro de cambios diferencial, por ejemplo, cn = changelog. Se debe especificar este valor para poder hacer la importación diferencial.
    Atributo de contraseña Si el servidor de directorios admite un atributo de contraseña diferente o hash de contraseña, puede especificar el destino de los cambios de contraseña.
    Nombres de partición En la lista de particiones adicionales es posible agregar espacios de nombres adicionales que no se detectan automáticamente. Por ejemplo, esta configuración puede utilizarse si varios servidores forman un clúster lógico y deben importarse al mismo tiempo. Igual que Active Directory puede tener varios dominios en un bosque, pero todos los dominios comparten un esquema, se puede simular lo mismo escribiendo los espacios de nombres adicionales en este cuadro. Cada espacio de nombres puede importarse desde distintos servidores y se puede configurar aún más en la página Configurar particiones y jerarquías.

  7. En la página Particiones, mantenga el valor predeterminado y seleccione Siguiente.

  8. En la página Perfiles de ejecución, asegúrese de que la casilla Exportación y la casilla Importación completa estén seleccionadas. Luego, seleccione Siguiente. Captura de pantalla que muestra la página Perfiles de ejecución.

    Propiedad. Descripción
    Exportación Perfil de ejecución que exportará datos al servidor de directorios LDAP. Este perfil de ejecución es obligatorio.
    Importación completa Perfil de ejecución que importará todos los datos de orígenes SQL especificados anteriormente. Este perfil de ejecución es obligatorio.
    Importación diferencial Perfil de ejecución que importará solo los cambios de LDAP desde la última importación completa o diferencial. Habilite este perfil de ejecución solo si ha confirmado que el servidor de directorios cumple los requisitos necesarios. Para obtener más información, consulte la Referencia del conector LDAP genérico.

  9. En la página Exportación, deje los valores predeterminados y haga clic en Siguiente.

  10. En la página Importación completa, deje los valores predeterminados y haga clic en Siguiente.

  11. En la página Importación diferencial, si existe, deje los valores predeterminados y haga clic en Siguiente.

  12. En la página Tipos de objeto, rellene los cuadros y seleccione Siguiente.

    Propiedad Descripción
    Objeto de destino Este valor es la clase de objeto estructural de un usuario en el servidor de directorios LDAP. Por ejemplo, inetOrgPerson para OpenLDAP o User para AD LDS. No especifique una clase de objeto auxiliar en este campo. Si el servidor de directorios requiere clases de objetos auxiliares, se configurarán con las asignaciones de atributos de Azure Portal.
    Delimitador Los valores de este atributo deben ser únicos para cada objeto del directorio de destino. El servicio de aprovisionamiento de Microsoft Entra consulta al host ECMA usando este atributo después del ciclo inicial. Para AD LDS, usa ObjectGUID, y para otros servidores de directorios, consulta la tabla siguiente. Tenga en cuenta que el nombre distintivo (DN) se puede seleccionar como -dn-. Los atributos multivalor, como el atributo uid del esquema OpenLDAP, no se pueden usar como delimitadores.
    Atributo de consulta Este atributo debe ser el mismo que el delimitador, como objectGUID si AD LDS es el servidor de directorios o _distinguishedName si es OpenLDAP.
    DN El valor distinguishedName del objeto de destino. Conserve -dn-.
    Generado automáticamente unchecked

    En la tabla siguiente se enumeran los servidores LDAP y el delimitador que se usa:

    Directorio Delimitador
    AD LDS y AD GC de Microsoft objectGUID. Para que ObjectGUID funcione como delimitador, debe usar la versión del agente 1.1.846.0 u otra superior.
    389 Directory Server dn
    Apache Directory dn
    IBM Tivoli DS dn
    Isode Directory dn
    Novell / NetIQ eDirectory GUID
    Open DJ/DS dn
    Open LDAP dn
    Oracle ODSEE dn
    RadiantOne VDS dn
    Sun One Directory Server dn

  13. El host ECMA detecta los atributos que admite el directorio de destino. Puede elegir cuál de esos atributos desea exponer a Microsoft Entra ID. A continuación, estos atributos se pueden configurar en Azure Portal para el aprovisionamiento. En la página Seleccionar atributos, agregue todos los atributos de la lista desplegable, de uno en uno, necesarios como atributos obligatorios o que quiera aprovisionar desde Microsoft Entra ID. Captura de pantalla en la que se muestra la página Seleccionar atributos.
    En la lista desplegable Atributo se muestra cualquier atributo que se haya detectado en el directorio de destino y que no se haya elegido al usar anteriormente la página Seleccionar atributos del asistente para configuración.

    Asegúrese de que la casilla Treat as single value esté desactivada para el atributo objectClass y, si userPassword se está estableciendo, que la casilla no se pueda seleccionar o que esté seleccionada para el atributo userPassword.

    Si usa OpenLDAP con el esquema inetOrgPerson, configure la visibilidad de los siguientes atributos.

    Atributo Tratar como valor único
    cn esté
    mail esté
    objectClass
    sn esté
    userPassword Y

    Si usa OpenLDAP con el esquema POSIX, configure la visibilidad de los siguientes atributos.

    Atributo Tratar como valor único
    _distinguishedName
    -dn-
    export_password
    cn esté
    gidNumber
    homeDirectory
    mail esté
    objectClass
    sn esté
    uid esté
    uidNumber
    userPassword Y

    Una vez que haya agregado todos los atributos pertinentes, seleccione Siguiente.

  14. En la página Desaprovisionamiento, puede especificar si desea que Microsoft Entra ID elimine usuarios del directorio cuando salgan del ámbito de la aplicación. Si es así, en Deshabilitar flujo, seleccione Eliminar y, en Eliminar flujo, seleccione Eliminar. Si se elige Set attribute value, los atributos seleccionados en la página anterior no estarán disponibles para seleccionarlos en la página Desaprovisionamiento.

Nota

Si usa la opción Establecer valor de atributo, tenga en cuenta que solo se permiten valores booleanos.

  1. Seleccione Finalizar.

Asegúrese de que el servicio ECMA2Host se está ejecutando y puede leer desde el servidor de directorios.

Sigue estos pasos para confirmar que el host del conector se ha iniciado y ha leído los usuarios existentes desde el servidor de directorios en el host del conector.

  1. En el servidor en el que se ejecuta el host del conector ECMA de Microsoft Entra, seleccione Iniciar.
  2. Seleccione Ejecutar si es necesario y escriba services.msc en el cuadro.
  3. En la lista Servicios, asegúrese de que Microsoft ECMA2Host esté presente y en ejecución. Si no se está ejecutando, seleccione Iniciar. Captura de pantalla que muestra que el servicio se está ejecutando.
  4. Si recientemente ha iniciado el servicio y tiene muchos objetos de usuario en el servidor de directorios, espere unos minutos hasta que el conector establezca una conexión con el servidor de directorios.
  5. En el servidor en el que se ejecuta el host del conector ECMA de Microsoft Entra, inicie PowerShell.
  6. Cambie a la carpeta en la que se instaló el host ECMA, como C:\Program Files\Microsoft ECMA2Host.
  7. Cambie al subdirectorio Troubleshooting.
  8. Ejecuta el script TestECMA2HostConnection.ps1 en ese directorio como se muestra en el siguiente ejemplo y proporciona como argumentos el nombre del conector y el valor de ObjectTypePathcache. Si el host del conector no escucha en el puerto TCP 8585, es posible que también tenga que proporcionar el argumento -Port. Cuando se le solicite, escriba el token secreto configurado para ese conector. 
    PS C:\Program Files\Microsoft ECMA2Host\Troubleshooting> $cout = .\TestECMA2HostConnection.ps1 -ConnectorName LDAP -ObjectTypePath cache; $cout.length -gt 9
Supply values for the following parameters:
SecretToken: ************
  9. Si el script muestra un mensaje de error o advertencia, compruebe que el servicio se esté ejecutando y que el nombre del conector y el token secreto coincidan con los valores configurados en el asistente para configuración.
  10. Si el script muestra la salida False, el conector no ha visto ninguna entrada en el servidor de directorios de origen para los usuarios existentes. Si se trata de una nueva instalación del servidor de directorios, este comportamiento es previsible y puede continuar en la sección siguiente.
  11. Sin embargo, si el servidor de directorios ya contiene uno o varios usuarios, pero el script mostrado es False, este estado indica que el conector no pudo leer desde el servidor de directorios. Si intenta aprovisionar, es posible que Microsoft Entra ID no coincida correctamente con los usuarios de ese directorio de origen con los usuarios en Microsoft Entra ID. Espere varios minutos para que el host del conector termine de leer objetos del servidor de directorios existente y, a continuación, vuelva a ejecutar el script. Si la salida sigue siendo False, compruebe la configuración del conector y si los permisos del servidor de directorios permiten que el conector lea los usuarios existentes.

Prueba de la conexión de Microsoft Entra ID al host del conector

  1. Vuelva a la ventana del explorador web donde configuró el aprovisionamiento de la aplicación en el portal.

    Nota:

    Si se agotó el tiempo de espera de la ventana, deberá volver a seleccionar el agente.

    1. Inicie sesión en Azure Portal.
    2. Vaya a Aplicaciones empresariales y seleccione la aplicación ECMA local.
    3. Haga clic en Aprovisionamiento.
    4. Si aparece Comenzar, cambie el modo a Automático. En la sección Conectividad local, seleccione el agente que acaba de implementar, seleccione Asignar agentes y espere 10 minutos. De lo contrario, vaya a Editar aprovisionamiento.

  2. En la sección Credenciales de administración, escriba la siguiente dirección URL. Reemplace la parte connectorName por el nombre del conector en el host ECMA, como LDAP. Si proporcionó un certificado de la entidad de certificación para el host ECMA, reemplace localhost por el nombre de host del servidor donde está instalado el host ECMA.

    Propiedad Valor
    URL de inquilino https://localhost:8585/ecma2host_connectorName/scim

  3. Escriba el valor de Token secreto que ha definido al crear el conector.

    Nota

    Si acaba de asignar el agente a la aplicación, espere 10 minutos para que se complete el registro. La prueba de conectividad no funciona hasta que se completa el registro. Forzar que el registro del agente se complete reiniciando el agente de aprovisionamiento en el servidor puede acelerar el proceso de registro. Vaya al servidor, busque servicios en la barra de búsqueda de Windows, identifique el servicio Agente de aprovisionamiento de Microsoft Entra Connect, haga clic con el botón derecho en el servicio y reinicie.

  4. Seleccione Probar conexión y espere un minuto.

  5. Una vez que la prueba de conexión funcione correctamente e indique que las credenciales suministradas están autorizadas a habilitar el aprovisionamiento, seleccione Guardar.
    Captura de pantalla de las pruebas de un agente.

Ampliar el esquema de Microsoft Entra (opcional)

Si el servidor de directorios requiere atributos adicionales que no forman parte del esquema predeterminado de Microsoft Entra para los usuarios, al aprovisionar puede configurar que se proporcionen los valores de esos atributos desde una constante, desde una expresión transformada desde otros atributos de Microsoft Entra o al ampliar el esquema de Microsoft Entra.

Si el servidor de directorios requiere que los usuarios tengan un atributo, como uidNumber para el esquema POSIX de OpenLDAP, y ese atributo aún no forma parte del esquema de Microsoft Entra para un usuario y debe ser único para cada usuario, deberá generar ese atributo de otros atributos del usuario mediante una expresión o usar la característica de extensión de directorio para agregar ese atributo como una extensión.

Si los usuarios se originan en Active Directory Domain Services y tienen el atributo en ese directorio, puede usar Microsoft Entra Connect o Microsoft Entra Connect Cloud Sync para configurar que el atributo se deba sincronizar desde Active Directory Domain Services para Microsoft Entra ID, de modo que esté disponible para el aprovisionamiento en otros sistemas.

Si los usuarios se originan en Microsoft Entra ID, para cada nuevo atributo tendrá que almacenar en un usuario, deberá definir una extensión de directorio. A continuación, actualice los usuarios de Microsoft Entra que tiene previsto aprovisionar para proporcionar a cada usuario un valor de esos atributos.

Configuración de la asignación de atributos

En esta sección, configurará la asignación entre los atributos del usuario de Microsoft Entra y los atributos que seleccionó anteriormente en el Asistente para configuración del host ECMA. Más adelante, cuando el conector cree un objeto en un servidor de directorios, los atributos de un usuario de Microsoft Entra se enviarán a través del conector al servidor de directorios para formar parte de ese nuevo objeto.

  1. En el Centro de administración de Microsoft Entra, en Aplicaciones empresariales, seleccione la aplicación ECMA local aplicación y, a continuación, seleccione la página Aprovisionamiento.

  2. Seleccione Editar aprovisionamiento.

  3. Expanda Asignaciones y seleccione Aprovisionar usuarios de Microsoft Entra. Si esta es la primera vez que ha configurado las asignaciones de atributos para esta aplicación, solo habrá una asignación presente para un marcador de posición.

  4. Para confirmar que el esquema del servidor de directorios está disponible en, Microsoft Entra ID active la casilla Mostrar opciones avanzadas y seleccione Editar lista de atributos para ScimOnPremises. Asegúrese de que se muestran todos los atributos seleccionados en el Asistente para configuración. Si no es así, espere varios minutos hasta que se actualice el esquema, seleccione Asignación de atributos en la línea de navegación y, a continuación, seleccione Editar lista de atributos para ScimOnPremises de nuevo para volver a cargar la página. Una vez que vea los atributos enumerados, seleccione Cancelar en esta página para volver a la lista de asignaciones.

  5. Cada usuario de un directorio debe tener un nombre distintivo único. Puede especificar cómo debe construir el conector un nombre distintivo mediante una asignación de atributos. Seleccione Agregar nueva asignación. Usa los valores siguientes del siguiente ejemplo para crear la asignación al cambiar los nombres distintivos de la expresión para que coincidan con los de la unidad organizativa u otro contenedor del directorio de destino.

    • Tipo de asignación: expresión
    • Expresión, si se aprovisiona en AD LDS: Join("", "CN=", Word([userPrincipalName], 1, "@"), ",CN=CloudUsers,CN=App,DC=Contoso,DC=lab")
    • Expresión, si se aprovisiona en OpenLDAP: Join("", "CN=", Word([userPrincipalName], 1, "@"), ",DC=Contoso,DC=lab")
    • Atributo de destino: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:-dn-
    • Aplicar esta asignación: solo durante la creación de objetos

  6. Si el servidor de directorios requiere que se proporcionen varios valores de clase de objeto estructural o valores de clase de objeto auxiliares en el atributo objectClass, agregue una asignación a ese atributo. Para este ejemplo de aprovisionamiento en AD LDS, la asignación de objectClass no es necesaria, pero puede ser necesaria para otros servidores de directorios u otros esquemas. Para agregar una asignación para objectClass, seleccione Agregar nueva asignación. Usa los valores del siguiente ejemplo para crear la asignación al cambiar los nombres de clase de objeto de la expresión para que coincidan con los del esquema de directorio de destino.

    • Tipo de asignación: expresión
    • Expresión, si se aprovisiona el esquema inetOrgPerson: Split("inetOrgPerson",",")
    • Expresión, si se aprovisiona el esquema de POSIX: Split("inetOrgPerson,posixAccount,shadowAccount",",")
    • Atributo de destino: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:objectClass
    • Aplicar esta asignación: solo durante la creación de objetos

  7. Si va a aprovisionar en AD LDS y hay una asignación de userPrincipalName a PLACEHOLDER, haga clic en esa asignación y edítela. Use los valores siguientes para actualizar la asignación.

    • Tipo de asignación: directa
    • Atributo de origen: userPrincipalName
    • Atributo de destino: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPrincipalName
    • Precedencia de coincidencia: 1
    • Aplicar esta asignación: solo durante la creación de objetos

  8. Si va a aprovisionar en AD LDS, agregue una asignación para isSoftDeleted. Seleccione Agregar nueva asignación. Use los valores siguientes para crear la asignación.

    • Tipo de asignación: directa
    • Atributo de origen: isSoftDeleted
    • Atributo de destino: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:msDS-UserAccountDisabled

  9. Para cada una de las asignaciones de la tabla siguiente, seleccione Agregar nueva asignación y especifique los atributos de origen y de destino. Si va a aprovisionar en un directorio existente con usuarios existentes, deberá editar la asignación del atributo que está en común para establecer la opción Hacer coincidir objetos con este atributo de ese atributo. Obtenga más información sobre la asignación de atributos aquí.

    Para AD LDS:

    Tipo de asignación Atributo de origen Atributo de destino
    Directo displayName urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:displayName

    Para OpenLDAP:

    Tipo de asignación Atributo de origen Atributo de destino
    Directo displayName urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:cn
    Directo surname urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:sn
    Directo userPrincipalName urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:mail

    Para OpenLDAP con el esquema de POSIX, también deberá proporcionar los atributos gidNumber, homeDirectory, uid y uidNumber. Cada usuario requiere un valor único uid y un uidNumber único. Normalmente, homeDirectory se establece mediante una expresión derivada del userID del usuario. Por ejemplo, si una expresión derivada del nombre principal de usuario genera el uid de un usuario, el valor del directorio principal del usuario podría generarse mediante una expresión similar derivada de su nombre principal de usuario. Y dependiendo de su caso de uso, es posible que desee que todos los usuarios estén en el mismo grupo, por lo que asignaría el gidNumber de una constante.

    Tipo de asignación Atributo de origen Atributo de destino
    Expression ToLower(Word([userPrincipalName], 1, "@"), ) urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:uid
    Directo (atributo específico del directorio) urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:uidNumber
    Expression Join("/", "/home", ToLower(Word([userPrincipalName], 1, "@"), )) urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:homeDirectory
    Constante 10000 urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:gidNumber

  10. Si está aprovisionando en un directorio distinto de AD LDS, agregue una asignación a urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPassword que establezca una contraseña aleatoria inicial para el usuario. Para AD LDS, no hay ninguna asignación para userPassword.

  11. Seleccione Guardar.

Asegúrate de que los usuarios que se aprovisionan en la aplicación tengan los atributos necesarios en Microsoft Entra ID

Si hay personas que tienen cuentas de usuario existentes en el directorio LDAP, deberá asegurarse de que la representación del usuario de Microsoft Entra tenga los atributos necesarios para la coincidencia.

Si planea crear nuevos usuarios en el directorio LDAP, deberá asegurarse de que las representaciones de Microsoft Entra de esos usuarios tengan los atributos de origen requeridos por el esquema de usuario del directorio de destino.

Puede usar los cmdlets de PowerShell de Microsoft Graph para automatizar la comprobación de los usuarios para los atributos necesarios.

Por ejemplo, supongamos que el aprovisionamiento requiere que los usuarios tengan tres atributos, DisplayName, surname y extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty. Puede usar el cmdlet Get-MgUser para recuperar cada usuario y comprobar si están presentes los atributos necesarios. Tenga en cuenta que el cmdlet Get-MgUser de Graph v1.0 no devuelve de forma predeterminada ninguno de los atributos de extensión de directorio de un usuario, a menos que los atributos se especifiquen en la solicitud como una de las propiedades que se van a devolver.

$userPrincipalNames = (
 "alice@contoso.com",
 "bob@contoso.com",
 "carol@contoso.com" )

$requiredBaseAttributes = ("DisplayName","surname")
$requiredExtensionAttributes = ("extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty")

$select = "id"
foreach ($a in $requiredExtensionAttributes) { $select += ","; $select += $a;}
foreach ($a in $requiredBaseAttributes) { $select += ","; $select += $a;}

foreach ($un in $userPrincipalNames) {
   $nu = Get-MgUser -UserId $un -Property $select -ErrorAction Stop
   foreach ($a in $requiredBaseAttributes) { if ($nu.$a -eq $null) { write-output "$un missing $a"} }
   foreach ($a in $requiredExtensionAttributes) { if ($nu.AdditionalProperties.ContainsKey($a) -eq $false) { write-output "$un missing $a" } }
}

Recopilación de usuarios existentes del directorio LDAP

Muchos directorios LDAP, como Active Directory, incluyen un comando que genera una lista de usuarios.

  1. Identifique cuáles de los usuarios de ese directorio están en el ámbito de ser usuarios de la aplicación. Esta opción dependerá de la configuración de la aplicación. Para algunas aplicaciones, cualquier usuario que exista en un directorio LDAP es un usuario válido. Otras aplicaciones pueden requerir que el usuario tenga un atributo determinado o sea miembro de un grupo de ese directorio.

  2. Ejecuta el comando que recupera ese subconjunto de usuarios del directorio LDAP. Asegúrese de que la salida incluya los atributos de los usuarios que se usarán para buscar coincidencias con Microsoft Entra ID. Algunos ejemplos de estos atributos son el identificador de empleado, el nombre de cuenta y la dirección de correo electrónico.

    Por ejemplo, este comando en Windows mediante el programa AD LDS csvde produciría un archivo .csv en el directorio del sistema de archivos actual con el atributo userPrincipalName de cada persona del directorio:

    $out_filename = ".\users.csv"
csvde -f $out_filename -l userPrincipalName,cn -r "(objectclass=person)"

  3. Si es necesario, transfiera el archivo .csv que contiene la lista de usuarios a un sistema con los cmdlets de PowerShell de Microsoft Graph instalados.

  4. Ahora que ha obtenido de la aplicación una lista de todos los usuarios, hará coincidir los usuarios del almacén de datos de la aplicación con los usuarios en Microsoft Entra ID. Antes de continuar, revise la información sobre los usuarios coincidentes en los sistemas de origen y de destino.

Recuperar los identificadores de los usuarios en Microsoft Entra ID

En esta sección, se muestra cómo interactuar con Microsoft Entra ID mediante cmdlets de PowerShell de Microsoft Graph.

La primera vez que la organización use estos cmdlets para este escenario, deberá tener un rol de administrador global para permitir el uso de PowerShell de Microsoft Graph en el inquilino. Las interacciones posteriores pueden usar un rol con privilegios inferiores, como:

  • Administrador de usuarios, si prevé crear nuevos usuarios.
  • Administrador de aplicaciones o Administrador de Identity Governance, si solo va a administrar asignaciones de roles de aplicación.

  1. Abra PowerShell.

  2. Si aún no tiene instalados los módulos de PowerShell de Microsoft Graph, instale el módulo Microsoft.Graph.Users y otros mediante este comando:

    Install-Module Microsoft.Graph

    Si ya tiene instalados los módulos, asegúrese de que usa una versión reciente:

    Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications

  3. Conéctese a Microsoft Entra ID:

    $msg = Connect-MgGraph -ContextScope Process -Scopes "User.ReadWrite.All,Application.ReadWrite.All,AppRoleAssignment.ReadWrite.All,EntitlementManagement.ReadWrite.All"

  4. Si es la primera vez que ha usado este comando, es posible que tenga que dar su consentimiento para permitir que las herramientas de la línea de comandos de Microsoft Graph tengan estos permisos.

  5. Lea la lista de usuarios obtenida del almacén de datos de la aplicación en la sesión de PowerShell. Si la lista de usuarios estaba en un archivo .csv, puede usar el cmdlet Import-Csv de PowerShell y proporcionar el nombre del archivo de la sección anterior como argumento.

    Por ejemplo, si el archivo obtenido de SAP Cloud Identity Services se denomina Users-exported-from-sap.csv y se encuentra en el directorio actual, escriba este comando.

    $filename = ".\Users-exported-from-sap.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8

    Por otro ejemplo, si usa una base de datos o un directorio, si el archivo se denomina users.csv y se encuentra en el directorio actual, escriba este comando:

    $filename = ".\users.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8

  6. Elija la columna del archivo users.csv que va a coincidir con un atributo de un usuario en Microsoft Entra ID.

    Si usa SAP Cloud Identity Services, la asignación predeterminada es el atributo userName SCIM de SAPuserName con el atributo Microsoft Entra IDuserPrincipalName:

    $db_match_column_name = "userName"
$azuread_match_attr_name = "userPrincipalName"

    Por otro ejemplo, si usa una base de datos o un directorio, es posible que tenga usuarios en una base de datos donde el valor de la columna denominada EMail sea el mismo valor que en el atributo Microsoft Entra userPrincipalName:

    $db_match_column_name = "EMail"
$azuread_match_attr_name = "userPrincipalName"

  7. Recupere los identificadores de esos usuarios en Microsoft Entra ID.

    El siguiente script de PowerShell usa los valores $dbusers, $db_match_column_name y $azuread_match_attr_name especificados anteriormente. El script consultará a Microsoft Entra ID para encontrar un usuario que tenga un atributo con un valor coincidente para cada registro del archivo de origen. Si hay muchos usuarios en el archivo obtenidos del origen de SAP Cloud Identity Services, la base de datos o el directorio, este script puede tardar varios minutos en finalizar. Si no tiene un atributo en Microsoft Entra ID que tenga el valor y necesita usar una expresión contains u otra expresión de filtro, deberá personalizar este script en el paso 11 a continuación para usar otra expresión de filtro.

    $dbu_not_queried_list = @()
$dbu_not_matched_list = @()
$dbu_match_ambiguous_list = @()
$dbu_query_failed_list = @()
$azuread_match_id_list = @()
$azuread_not_enabled_list = @()
$dbu_values = @()
$dbu_duplicate_list = @()

foreach ($dbu in $dbusers) { 
   if ($null -ne $dbu.$db_match_column_name -and $dbu.$db_match_column_name.Length -gt 0) { 
      $val = $dbu.$db_match_column_name
      $escval = $val -replace "'","''"
      if ($dbu_values -contains $escval) { $dbu_duplicate_list += $dbu; continue } else { $dbu_values += $escval }
      $filter = $azuread_match_attr_name + " eq '" + $escval + "'"
      try {
         $ul = @(Get-MgUser -Filter $filter -All -Property Id,accountEnabled -ErrorAction Stop)
         if ($ul.length -eq 0) { $dbu_not_matched_list += $dbu; } elseif ($ul.length -gt 1) {$dbu_match_ambiguous_list += $dbu } else {
            $id = $ul[0].id; 
            $azuread_match_id_list += $id;
            if ($ul[0].accountEnabled -eq $false) {$azuread_not_enabled_list += $id }
         } 
      } catch { $dbu_query_failed_list += $dbu } 
    } else { $dbu_not_queried_list += $dbu }
}

  8. Observe los resultados de las consultas anteriores. Vea si alguno de los usuarios de SAP Cloud Identity Services, la base de datos o el directorio no se pudieron encontrar en Microsoft Entra ID, debido a errores o coincidencias que faltan.

    El siguiente script de PowerShell mostrará los recuentos de los registros que no se encontraron:

    $dbu_not_queried_count = $dbu_not_queried_list.Count
if ($dbu_not_queried_count -ne 0) {
  Write-Error "Unable to query for $dbu_not_queried_count records as rows lacked values for $db_match_column_name."
}
$dbu_duplicate_count = $dbu_duplicate_list.Count
if ($dbu_duplicate_count -ne 0) {
  Write-Error "Unable to locate Microsoft Entra ID users for $dbu_duplicate_count rows as multiple rows have the same value"
}
$dbu_not_matched_count = $dbu_not_matched_list.Count
if ($dbu_not_matched_count -ne 0) {
  Write-Error "Unable to locate $dbu_not_matched_count records in Microsoft Entra ID by querying for $db_match_column_name values in $azuread_match_attr_name."
}
$dbu_match_ambiguous_count = $dbu_match_ambiguous_list.Count
if ($dbu_match_ambiguous_count -ne 0) {
  Write-Error "Unable to locate $dbu_match_ambiguous_count records in Microsoft Entra ID as attribute match ambiguous."
}
$dbu_query_failed_count = $dbu_query_failed_list.Count
if ($dbu_query_failed_count -ne 0) {
  Write-Error "Unable to locate $dbu_query_failed_count records in Microsoft Entra ID as queries returned errors."
}
$azuread_not_enabled_count = $azuread_not_enabled_list.Count
if ($azuread_not_enabled_count -ne 0) {
 Write-Error "$azuread_not_enabled_count users in Microsoft Entra ID are blocked from sign-in."
}
if ($dbu_not_queried_count -ne 0 -or $dbu_duplicate_count -ne 0 -or $dbu_not_matched_count -ne 0 -or $dbu_match_ambiguous_count -ne 0 -or $dbu_query_failed_count -ne 0 -or $azuread_not_enabled_count) {
 Write-Output "You will need to resolve those issues before access of all existing users can be reviewed."
}
$azuread_match_count = $azuread_match_id_list.Count
Write-Output "Users corresponding to $azuread_match_count records were located in Microsoft Entra ID."

  9. Cuando finalice el script, se indicará un error si no se encontraron en Microsoft Entra ID algunos registros del origen de datos. Si no se han podido encontrar como usuarios de Microsoft Entra ID todos los registros de los usuarios del almacén de datos de la aplicación, deberá investigar qué registros no coincidieron y por qué.

    Por ejemplo, es posible que la dirección de correo electrónico de algún usuario y el valor de userPrincipalName hayan cambiado en Microsoft Entra ID sin que se haya actualizado su propiedad mail correspondiente en el origen de datos de la aplicación. O bien, es posible que el usuario ya haya dejado la organización, pero siga estando en el origen de datos de la aplicación. O bien, puede haber una cuenta de proveedor o superadministrador en el origen de datos de la aplicación que no corresponda a ninguna persona específica de Microsoft Entra ID.

  10. Si había usuarios que no podían estar ubicados en Microsoft Entra ID, o no estaban activos y podían iniciar sesión, pero quiere tener su acceso revisado o sus atributos actualizados en SAP Cloud Identity Services, la base de datos o el directorio, deberá actualizar la aplicación, la regla de coincidencia o actualizar o crear usuarios de Microsoft Entra para ellos. Para obtener más información sobre qué cambio realizar, vea administrar asignaciones y cuentas de usuario en aplicaciones que no coincidieron con los usuarios de Microsoft Entra ID.

    Si elige la opción de crear usuarios en Microsoft Entra ID, puede crear usuarios de forma masiva mediante:

    Asegúrese de que estos nuevos usuarios se rellenan con los atributos necesarios de Azure AD de forma que coincidan posteriormente con los usuarios existentes en la aplicación, y los atributos requeridos por Microsoft Entra ID, como userPrincipalName, mailNickname y displayName. El valor de userPrincipalName debe ser único entre todos los usuarios del directorio.

    Por ejemplo, es posible que tengas usuarios una la base de datos donde el valor de la columna denominada EMail sea el valor que quieres usar como nombre principal de usuario de Microsoft Entra ID, el valor de la columna Alias contenga el alias de correo de Microsoft Entra ID y el valor de la columna Full name contenga el nombre para mostrar del usuario:

    $db_display_name_column_name = "Full name"
$db_user_principal_name_column_name = "Email"
$db_mail_nickname_column_name = "Alias"

    Después, puede usar este script para crear usuarios de Microsoft Entra para aquellos de SAP Cloud Identity Services, la base de datos o el directorio que no coincidan con los usuarios en el Microsoft Entra ID. Tenga en cuenta que es posible que deba modificar este script para agregar atributos adicionales de Microsoft Entra necesarios en su organización, o si el valor de $azuread_match_attr_name no es mailNickname ni userPrincipalName, para proporcionar ese atributo de Microsoft Entra.

    $dbu_missing_columns_list = @()
$dbu_creation_failed_list = @()
foreach ($dbu in $dbu_not_matched_list) {
   if (($null -ne $dbu.$db_display_name_column_name -and $dbu.$db_display_name_column_name.Length -gt 0) -and
       ($null -ne $dbu.$db_user_principal_name_column_name -and $dbu.$db_user_principal_name_column_name.Length -gt 0) -and
       ($null -ne $dbu.$db_mail_nickname_column_name -and $dbu.$db_mail_nickname_column_name.Length -gt 0)) {
      $params = @{
         accountEnabled = $false
         displayName = $dbu.$db_display_name_column_name
         mailNickname = $dbu.$db_mail_nickname_column_name
         userPrincipalName = $dbu.$db_user_principal_name_column_name
         passwordProfile = @{
           Password = -join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})
         }
      }
      try {
        New-MgUser -BodyParameter $params
      } catch { $dbu_creation_failed_list += $dbu; throw }
   } else {
      $dbu_missing_columns_list += $dbu
   }
}

  11. Después de agregar los usuarios que faltan a Microsoft Entra ID, vuelva a ejecutar el script del paso 7. A continuación, ejecute el script del paso 8. Compruebe que no se notifique ningún error.

    $dbu_not_queried_list = @()
$dbu_not_matched_list = @()
$dbu_match_ambiguous_list = @()
$dbu_query_failed_list = @()
$azuread_match_id_list = @()
$azuread_not_enabled_list = @()
$dbu_values = @()
$dbu_duplicate_list = @()

foreach ($dbu in $dbusers) { 
   if ($null -ne $dbu.$db_match_column_name -and $dbu.$db_match_column_name.Length -gt 0) { 
      $val = $dbu.$db_match_column_name
      $escval = $val -replace "'","''"
      if ($dbu_values -contains $escval) { $dbu_duplicate_list += $dbu; continue } else { $dbu_values += $escval }
      $filter = $azuread_match_attr_name + " eq '" + $escval + "'"
      try {
         $ul = @(Get-MgUser -Filter $filter -All -Property Id,accountEnabled -ErrorAction Stop)
         if ($ul.length -eq 0) { $dbu_not_matched_list += $dbu; } elseif ($ul.length -gt 1) {$dbu_match_ambiguous_list += $dbu } else {
            $id = $ul[0].id; 
            $azuread_match_id_list += $id;
            if ($ul[0].accountEnabled -eq $false) {$azuread_not_enabled_list += $id }
         } 
      } catch { $dbu_query_failed_list += $dbu } 
    } else { $dbu_not_queried_list += $dbu }
}

$dbu_not_queried_count = $dbu_not_queried_list.Count
if ($dbu_not_queried_count -ne 0) {
  Write-Error "Unable to query for $dbu_not_queried_count records as rows lacked values for $db_match_column_name."
}
$dbu_duplicate_count = $dbu_duplicate_list.Count
if ($dbu_duplicate_count -ne 0) {
  Write-Error "Unable to locate Microsoft Entra ID users for $dbu_duplicate_count rows as multiple rows have the same value"
}
$dbu_not_matched_count = $dbu_not_matched_list.Count
if ($dbu_not_matched_count -ne 0) {
  Write-Error "Unable to locate $dbu_not_matched_count records in Microsoft Entra ID by querying for $db_match_column_name values in $azuread_match_attr_name."
}
$dbu_match_ambiguous_count = $dbu_match_ambiguous_list.Count
if ($dbu_match_ambiguous_count -ne 0) {
  Write-Error "Unable to locate $dbu_match_ambiguous_count records in Microsoft Entra ID as attribute match ambiguous."
}
$dbu_query_failed_count = $dbu_query_failed_list.Count
if ($dbu_query_failed_count -ne 0) {
  Write-Error "Unable to locate $dbu_query_failed_count records in Microsoft Entra ID as queries returned errors."
}
$azuread_not_enabled_count = $azuread_not_enabled_list.Count
if ($azuread_not_enabled_count -ne 0) {
 Write-Warning "$azuread_not_enabled_count users in Microsoft Entra ID are blocked from sign-in."
}
if ($dbu_not_queried_count -ne 0 -or $dbu_duplicate_count -ne 0 -or $dbu_not_matched_count -ne 0 -or $dbu_match_ambiguous_count -ne 0 -or $dbu_query_failed_count -ne 0 -or $azuread_not_enabled_count -ne 0) {
 Write-Output "You will need to resolve those issues before access of all existing users can be reviewed."
}
$azuread_match_count = $azuread_match_id_list.Count
Write-Output "Users corresponding to $azuread_match_count records were located in Microsoft Entra ID."

Asignación de usuarios a una aplicación

Ahora que el host del conector ECMA de Microsoft Entra se comunica con Microsoft Entra ID y se ha configurado la asignación de atributos, puede pasar a configurar quién está dentro del alcance del aprovisionamiento.

Importante

Si ha iniciado sesión con un rol de administrador de identidades híbridas, debe cerrar sesión e iniciar sesión con una cuenta que tenga al menos el rol Administrador de aplicaciones para esta sección. El rol Administrador de identidad híbrida no tiene permisos para asignar usuarios a aplicaciones.

Si existen usuarios en el directorio LDAP, debe crear asignaciones de roles de aplicación para esos usuarios existentes en Microsoft Entra ID. Para obtener más información sobre cómo crear asignaciones de roles de aplicación en bloque mediante New-MgServicePrincipalAppRoleAssignedTo, consulta Gobernanza de los usuarios existentes de una aplicación en Microsoft Entra ID.

De lo contrario, si el directorio LDAP está vacío, seleccione un usuario de prueba de Microsoft Entra ID que tenga los atributos requeridos y se aprovisionará en el servidor de directorios de la aplicación.

  1. Asegúrese de que el usuario seleccionado tiene todas las propiedades que se asignarán a los atributos necesarios del esquema del servidor de directorios.
  2. En Azure Portal, seleccione Aplicaciones empresariales.
  3. Seleccione la aplicación Aplicación ECMA local.
  4. A la izquierda, en Administrar, seleccione Usuarios y grupos.
  5. Seleccione Agregar usuario o grupo. Captura de pantalla que muestra la incorporación de un usuario.
  6. En Usuarios, seleccione Ninguno seleccionado. Captura de pantalla que muestra la opción Ninguno seleccionado.
  7. Seleccione a un usuario de la derecha y luego, haga clic en el botón Seleccionar.
    Captura de pantalla en la que se muestra Seleccionar usuarios.
  8. Ahora seleccione Asignar. Captura de pantalla que muestra la asignación de usuarios.

Prueba del aprovisionamiento

Ahora que el usuario inicial y los atributos están asignados, puede probar el aprovisionamiento a petición con uno de los usuarios.

  1. En el servidor en el que se ejecuta el host del conector ECMA de Microsoft Entra, seleccione Iniciar.

  2. Escriba run y luego services.msc en el cuadro.

  3. En la lista Servicios, asegúrese de que tanto el servicio Agente de aprovisionamiento de Microsoft Entra Connect como el servicio Microsoft ECMA2Host se estén ejecutando. Si no es así, seleccione Iniciar.

  4. En Azure Portal, seleccione Aplicaciones empresariales.

  5. Seleccione la aplicación Aplicación ECMA local.

  6. A la izquierda, seleccione Aprovisionamiento.

  7. Seleccione Aprovisionamiento a petición.

  8. Busque alguno de los usuarios de prueba y seleccione Aprovisionar. Captura de pantalla en la que se muestran las pruebas de aprovisionamiento bajo demanda.

  9. Después de varios segundos, aparecerá el mensaje Se ha creado correctamente el usuario en el sistema de destino, con una lista de los atributos de usuario. Si aparece un error en su lugar, consulte Solución de problemas de errores de aprovisionamiento.

Inicio del aprovisionamiento de usuarios

Una vez que la prueba del aprovisionamiento a petición se realice correctamente, agregue a los usuarios restantes.

  1. Seleccione la aplicación en Azure Portal.
  2. A la izquierda, en Administrar, seleccione Usuarios y grupos.
  3. Asegúrese de que todos los usuarios estén asignados al rol de aplicación.
  4. Vuelva a la página de configuración de aprovisionamiento.
  5. Asegúrese de que el ámbito esté establecido solo en los usuarios y grupos asignados, active el aprovisionamiento y seleccione Guardar.
  6. Espere varios minutos para que se inicie el aprovisionamiento. Puede tardar hasta 40 minutos. Después de completarse el trabajo de aprovisionamiento, como se describe en la sección siguiente,

Solución de errores de aprovisionamiento

Si se muestra un error, seleccione Ver registros de aprovisionamiento. Busque en el registro una fila en la que el Estado sea Error y haga clic en esa fila.

Si el mensaje de error es No se pudo crear el usuario, compare los atributos que se muestran con los requisitos del esquema del directorio.

Para más información, cambie a la pestaña de Recomendaciones y Resolución de problemas.

Si el mensaje de error de solución de problemas incluye que un valor objectClass es invalid per syntax, asegúrese de que la asignación de atributos de aprovisionamiento al atributo objectClass incluya solo nombres de las clases de objeto reconocidas por el servidor de directorios.

Para otros errores, consulte Solución de problemas de aprovisionamiento de aplicaciones locales.

Si desea pausar el aprovisionamiento en esta aplicación, en la página de configuración del aprovisionamiento puede cambiar el estado de aprovisionamiento a Desactivado y seleccionar Guardar. Esta acción evita que el servicio de aprovisionamiento se ejecute en el futuro.

Comprobación de aprovisionamiento correcto de los usuarios

Después de esperar, compruebe el servidor de directorios para asegurarse de que los usuarios se aprovisionan. La consulta que realice al servidor de directorio dependerá de los comandos que proporcione su servidor de directorio.

En las instrucciones siguientes se muestra cómo comprobar AD LDS.

  1. Abra el Administrador del servidor y seleccione AD LDS a la izquierda.
  2. Haga clic con el botón derecho en la instancia de AD LDS y seleccione ldp.exe en el elemento emergente. Captura de pantalla de la ubicación de la herramienta Ldp.
  3. En la parte superior de ldp.exe, seleccione Conexión y Conectar.
  4. Escriba la siguiente información y haga clic en Aceptar.
    • Servidor: APP3
    • Puerto: 636
    • Coloque una marca de verificación en la casilla de SSL Captura de pantalla en la que se muestra la conexión Ldp para verificar usuarios.
  5. En la parte superior, en Conexión seleccione Enlazar.
  6. Deje el valor predeterminado y haga clic en Aceptar.
  7. En la parte superior, seleccione Ver y Árbol
  8. En BaseDN, escriba CN=App,DC=contoso,DC=lab y haga clic en Aceptar.
  9. A la izquierda, expanda el DN y haga clic en CN=CloudUsers,CN=App,DC=contoso,DC=lab. Debería ver los usuarios que se aprovisionaron desde Microsoft Entra ID. Captura de pantalla en la que se muestra el enlace Ldp para los usuarios.

En las instrucciones siguientes se muestra cómo comprobar OpenLDAP.

  1. Abra una ventana de terminal con un shell de comandos en el sistema con OpenLDAP.
  2. Escriba el comando ldapsearch -D "cn=admin,dc=contoso,dc=lab" -W -s sub -b dc=contoso,dc=lab -LLL (objectclass=inetOrgPerson)
  3. Compruebe que el LDIF resultante incluya a los usuarios aprovisionados desde Microsoft Entra ID.

Pasos siguientes