Compartir a través de

Configuración de Microsoft Entra ID para aprovisionar usuarios en un directorio LDAP para la autenticación de Linux

  • Artículo

La siguiente documentación es un tutorial que muestra cómo controlar el acceso a un sistema Linux. Microsoft Entra aprovisiona a los usuarios en un directorio LDAP local de confianza para ese sistema Linux. Esto permite a los usuarios iniciar sesión en un sistema Linux que se basa en ese directorio LDAP para la autenticación de usuario. Cuando un usuario se quita de Microsoft Entra ID, ya no puede iniciar sesión en un sistema Linux.

Nota

El escenario descrito en este artículo solo es aplicable a los sistemas Linux existentes que ya se basan en un conmutador de servicios de nombres (NSS) o en los módulos de autenticación conectables (PAM) LDAP para la identificación y autenticación de usuarios. Las máquinas virtuales Linux en Azure o que están habilitadas para Azure Arc deben integrarse en su lugar con la autenticación de Microsoft Entra. Ahora puede usar Microsoft Entra ID como plataforma de autenticación principal y como una autoridad de certificación para acceder por SSH a una máquina virtual Linux mediante Microsoft Entra ID y la autenticación basada en certificados OpenSSH, tal como se describe en Iniciar sesión en una máquina virtual Linux en Azure mediante Microsoft Entra ID y OpenSSH.

Para ver otros escenarios que implican el aprovisionamiento de usuarios en directorios LDAP, que no sean para la autenticación de Linux, consulte configuración de Microsoft Entra ID para aprovisionar usuarios en directorios LDAP.

Requisitos previos para el aprovisionamiento de usuarios en un directorio LDAP para la autenticación de Linux

En este artículo se da por supuesto que el servidor LDAP ya está presente en el entorno local, utilizado por uno o varios sistemas Linux u otros sistemas POSIX para la autenticación de usuarios.

Diagrama que muestra la arquitectura para el aprovisionamiento local de Microsoft Entra ID a un servidor de directorio LDAP.

Requisitos previos locales

  • Un servidor Linux u otro servidor POSIX que responde sobre un servidor de directorios mediante un módulo PAM o NSS.
  • Un servidor de directorio LDAP que admita el esquema POSIX, como OpenLDAP, en el que los usuarios se pueden crear, actualizar y eliminar. Para obtener más información sobre los servidores de directorio admitidos, consulte la referencia del conector LDAP genérico .
  • 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 de Windows Server. También debe tener conectividad con el servidor de directorios de destino y la conectividad saliente con login.microsoftonline.com, 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. .NET Framework 4.7.2 debe instalarse en ese servidor.
  • Opcional: Aunque no es necesario, se recomienda descargar Microsoft Edge para Windows Server y usarlo en lugar de Internet Explorer.

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 licencias de 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.

  • Rol de administrador de identidad híbrida para la configuración del agente de aprovisionamiento.

  • Los roles de Administrador de aplicaciones o Administrador de aplicaciones en la nube para configurar el aprovisionamiento en el portal de Azure o en el centro de administración de Microsoft Entra.

  • El esquema del servidor de directorios requiere atributos específicos para que cada usuario de Microsoft Entra sea aprovisionado en el directorio LDAP, y estos atributos deben estar ya poblados. En concreto, cada usuario debe tener un número único como su número de identificador de usuario. Antes de implementar el agente de aprovisionamiento y asignar usuarios al directorio, debe generar ese número a partir de un atributo existente en el usuario o ampliar el esquema de Microsoft Entra. A continuación, puede rellenar ese atributo en los usuarios que estén bajo el ámbito. Consulte la Extensibilidad de Graph para obtener información sobre cómo crear extensiones de directorio adicionales.

Más recomendaciones y limitaciones

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 locales. Microsoft recomienda usar un agente independiente para la sincronización en la nube y otro para el aprovisionamiento de aplicaciones locales.
  • En el caso de AD LDS actualmente, 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.
  • Para 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 usuarios de LDAP a Microsoft Entra ID.
  • No se admite el aprovisionamiento de pertenencias de grupos y usuarios a un servidor de directorios.

Determinar cómo interactuará el conector LDAP de Microsoft Entra con el servidor de directorios

Antes de implementar el conector en un servidor de directorios existente, debe analizar con el operador de servidor de directorios de su organización cómo integrarse con su servidor de directorios. La información que se va a recopilar incluye:

  • Información de red de cómo conectarse al servidor de directorios.
  • Cómo debe autenticarse el conector en el servidor de directorios.
  • Esquema que el servidor de directorios ha seleccionado para modelar usuarios.
  • Reglas de jerarquía de directorios y nombres distintivos base del contexto de nomenclatura.
  • Cómo asociar usuarios en el servidor de directorios a los usuarios de Microsoft Entra ID.
  • Qué debe ocurrir cuando un usuario sale del alcance 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 su proveedor del servidor de directorios o 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 OpenLDAP.

Parámetro de configuración Donde 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 a través de 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 cn=admin,dc=contoso,dc=lab
contraseña para que el conector se autentique en el servidor de directorios Página Conectividad del Asistente para configuración
clase de objeto estructural para un usuario en el servidor de directorios Página Tipos de objeto del Asistente para configuración inetOrgPerson
clases de objetos auxiliares para un usuario en el servidor de directorios Asignaciones de atributos de la página Aprovisionamiento de Azure Portal posixAccount yshadowAccount
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 cn, gidNumber, homeDirectory, mail, objectClass, sn, uid, uidNumberuserPassword
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 DC=Contoso,DC=lab
atributos para correlacionar usuarios entre el identificador de Microsoft Entra y el servidor de directorios Asignaciones de atributos de la página Aprovisionamiento de Azure Portal mail
comportamiento del desaprovisionamiento cuando un usuario sale del ámbito en Microsoft Entra ID Página Desaprovisionamiento del Asistente para configuración Eliminación del 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 donde el servidor de directorios se encuentra junto con el conector en la misma instancia de Windows Server o usa la seguridad de nivel de red, las conexiones de red desde el conector a un servidor de directorio deben protegerse 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 a través de TLS.

Debe 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 una contraseña asociada 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 dentro del modelo de control de acceso del directorio. El conector debe tener permisos de escritura para poder exportar y permisos de de lectura para poder importar. La configuración de permisos se realiza dentro de las experiencias de administración del propio directorio de destino.

Un esquema de directorio especifica las clases y atributos de objeto que representan una entidad real en el directorio. El conector admite que un usuario se represente con una clase de objeto estructural, como inetOrgPersony, 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.

Es probable que también configure asignaciones a algunos de los atributos opcionales de estas clases. Un servidor de directorios OpenLDAP con el esquema POSIX para admitir la autenticación de Linux podría requerir un objeto para que un nuevo usuario tenga atributos como en el 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 directorios implementadas por un servidor de directorio describen cómo los objetos de cada usuario se relacionan 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 su 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 para el contexto de nomenclatura de un servidor de directorios es dc=contoso,dc=com, un nuevo usuario tendría un nombre distintivo como 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 como cn=alice,ou=London,dc=contoso,dc=com. Dado que el conector no crea objetos intermedios para 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 en el identificador de Microsoft Entra. Por otro lado, una organización puede tener un atributo diferente, como mail o employeeId, en su esquema de servidor de directorios que también está asociado a sus usuarios en 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 tiene un valor específico de ese atributo y solo crear un nuevo usuario en el servidor de directorios si no existe uno.

Si su escenario implica la creación de nuevos usuarios en el directorio LDAP, no solo actualizando o eliminando usuarios existentes, deberá determinar también cómo administran la autenticación los sistemas Linux que usan ese servidor de directorios. Algunos sistemas pueden consultar la clave pública o el certificado SSH de un usuario desde el directorio, que puede ser adecuado para los usuarios que ya contienen 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, debe establecer una contraseña específica de la aplicación al crear un nuevo usuario en el directorio, ya que el id. de Microsoft Entra 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 se configura el conector y Microsoft Entra ID ha vinculado a un usuario de Microsoft Entra ID con un usuario del directorio, ya sea para un usuario que ya está en el directorio o un nuevo usuario, entonces Microsoft Entra ID puede provisionar los cambios de atributos del usuario de Microsoft Entra en el directorio.

Si se elimina un usuario que se asigna a la aplicación en microsoft Entra ID, Microsoft Entra ID envía una operación de eliminación al servidor de directorios. También puede que desee que el identificador de Entra de Microsoft 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, como muchos directorios, como OpenLDAP, puede que no tenga una manera predeterminada de indicar que la cuenta de un usuario está inactiva.

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

  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 la selección de Automático.

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

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

  1. Deje el portal y ejecute el instalador del agente de aprovisionamiento, acepte los términos del servicio y seleccione Instalar.
  2. Espere al Asistente para configuración del agente de aprovisionamiento de Microsoft Entra y seleccione Siguiente.
  3. En el paso Seleccione la extensión, seleccione Aprovisionamiento de aplicaciones locales y Siguiente.
  4. El agente de aprovisionamiento usa el explorador web del sistema operativo para mostrar una ventana emergente para que se autentique en Microsoft Entra ID y, posiblemente, también con el proveedor de identidad de la 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 credenciales para un administrador de Microsoft Entra cuando se le pida que autorice. El usuario debe tener al menos el rol 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 que muestra cómo seleccionar y asignar un agente.

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

Configuración del certificado host del conector ECMA de Microsoft Entra

  1. En Windows Server donde está instalado el agente de aprovisionamiento, seleccione con el botón derecho el Asistente para configuración de Microsoft ECMA2Host en el menú Inicio y ejecute como administrador. La ejecución como administrador de Windows es necesaria para que el asistente cree los registros de eventos de Windows necesarios.
  2. Una vez iniciada la configuración del host del conector ECMA, si es la primera vez que ha ejecutado el asistente, se le pide que cree un certificado. Deje el puerto predeterminado 8585 y seleccione Generar certificado para generar un certificado. El certificado generado automáticamente se firma automáticamente como parte de la raíz de confianza. SAN coincide con el nombre de host. Captura de pantalla que muestra cómo configurar tus ajustes.
  3. Seleccione Guardar.

Nota

Si ha elegido generar un nuevo certificado, registre la fecha de expiración del certificado para asegurarse de que programa para volver al Asistente para configuración y volver a generar el certificado antes de que expire.

Configuración del 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. Use la siguiente información para guiarle en la configuración.

  1. Genere un token secreto que se usará para autenticar el identificador de Microsoft Entra en el conector. Debe tener 12 caracteres como mínimo y ú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 cómo elegir 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 introducción de propiedades.

    Propiedad Value
    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 el token secreto aquí. Debe tener 12 caracteres como mínimo.
    DLL de extensión En el conector LDAP genérico, seleccione Microsoft.IAM.Connector.GenericLdap.dll.

  5. En la página de conectividad , configurará cómo el Host del Conector ECMA se comunica 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 consulta el servidor de directorios para su configuración. Captura de pantalla que muestra la página Conectividad.

    Propiedad Descripción
    Anfitrión Nombre de host donde se encuentra el servidor LDAP. En este ejemplo se usa APP3 como nombre de host de ejemplo.
    Puerto 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 autentica el conector en el servidor de directorios. Con la configuración de Basic o con la configuración de SSL o TLS y ningún certificado de cliente configurado, el conector envía un enlace LDAP simple para autenticarse con un nombre distintivo y una contraseña. Con la configuración SSL o TLS y un certificado de cliente especificado, el conector envía una vinculación LDAP SASL EXTERNAL para autenticarse con dicho certificado.
    Nombre de usuario Cómo el conector ECMA se autentica en el servidor de directorios. En este ejemplo, cn=admin,dc=contoso,dc=lab
    Contraseña La contraseña del usuario que el conector ECMA utiliza para autenticarse en el servidor de directorios.
    Reino/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 de esquemas y el conector necesita ayuda para identificar esos atributos. Por ejemplo, si el servidor de directorios no publica userCertificate;binary y desea aprovisionar ese atributo, la siguiente cadena debe escribirse 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.
    Incluir atributos operativos Active la casilla Include operational attributes in schema para incluir también atributos creados por el servidor de directorios. Estos incluyen atributos como cuando se creó el objeto y la hora de la última actualización.
    Incluir atributos extensibles Active la casilla Include extensible attributes in schema si se usan objetos extensibles (RFC4512/4.3) en el servidor de directorios. La habilitación de esta opción permite que todos los atributos se usen en todos los objetos. Al seleccionar esta opción, el esquema es muy grande, por lo que, a menos que el directorio conectado use esta característica, la recomendación es mantener la opción sin seleccionar.
    Permitir selección manual de anclaje Deje la opción desactivada.

    Nota

    Si experimenta un problema al intentar conectarse y no puede continuar con la página Global, asegúrese de que la cuenta de servicio del servidor de directorios esté habilitada.

  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 previamente 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 compatibles En la sección superior se muestra 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 muestra 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 raíz. Si estos controles no aparecen en la lista, se presenta una advertencia. Algunos directorios LDAP no enumeran todas las características del DSE raíz y es posible que el conector funcione sin problemas incluso si existe 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. Este valor debe especificarse para habilitar la importación delta. Si no necesita implementar la importación delta, este campo puede estar en blanco.
    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 no detectados automáticamente. Por ejemplo, esta configuración se puede usar si varios servidores componen un clúster lógico, que debe importarse al mismo tiempo. Al igual que Active Directory puede tener varios dominios en un bosque, pero todos los dominios comparten un esquema, lo mismo se puede simular 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. A continuación, seleccione Siguiente. Captura de pantalla que muestra la página Perfiles de ejecución.

    Propiedad Descripción
    Exportar Perfil de ejecución que exporta datos al servidor de directorio LDAP. Este perfil de ejecución es necesario.
    Importación completa Perfil de ejecución que importa todos los datos de orígenes LDAP especificados anteriormente. Este perfil de ejecución es necesario.
    Importación diferencial Ejecute un perfil que importe 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 de exportación , deje los valores predeterminados sin cambios y seleccione Siguiente.

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

  11. En la página Importación diferencial, si existe, deje los valores predeterminados y seleccione 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 directorio LDAP. Use inetOrgPersony 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 en Azure Portal.
    Ancla Los valores de este atributo deben ser únicos para cada objeto del directorio de destino. El servicio de aprovisionamiento de Microsoft Entra consulta el host del conector ECMA mediante este atributo después del ciclo inicial. Normalmente, use el nombre distintivo, que se puede seleccionar como -dn-. Los atributos con varios valores, como el atributo uid en el esquema OpenLDAP, no se pueden usar como anclajes.
    Atributo de consulta Este atributo debe ser el mismo que Anchor.
    DN El valor distinguishedName del objeto de destino. Conserve -dn-.
    Generado automáticamente Desactivado

  13. El host ECMA detecta los atributos admitidos por el directorio de destino. Puede elegir cuál de esos atributos desea exponer al identificador de Entra de Microsoft. 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, uno por uno, que son necesarios como atributos obligatorios o que desea provisionar desde Microsoft Entra ID. Captura de pantalla que muestra la página Seleccionar Atributos.
    La lista desplegable de atributos muestra cualquier atributo detectado en el directorio de destino y no elegido en el uso anterior del asistente para configuración de la página Seleccionar Atributos .

    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.

    Configure la visibilidad de los atributos siguientes.

    Atributo Tratar como valor único
    _distinguishedName
    -dn-
    exportar_contraseña
    cn Y
    gidNumber
    homeDirectory
    correo Y
    objectClass
    sn Y
    uid Y
    uidNumber
    userPassword Y

    Una vez agregados 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 Eliminary, en Eliminar flujo, seleccione Eliminar. Si se elige Set attribute value, los atributos seleccionados en la página anterior no estarán disponibles para seleccionar en la página Desaprovisionamiento.

Nota

Si usa el valor Establecer atributo tenga en cuenta que solo se permiten valores booleanos.

  1. Seleccione Finalizar.

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

Siga estos pasos para confirmar que el host del conector se ha iniciado y ha identificado los usuarios existentes desde el servidor de directorios.

  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 Services, asegúrese de que Microsoft ECMA2Host esté presente y en ejecución. Si no se está ejecutando, seleccione Iniciar. Captura de pantalla que muestra la ejecución del servicio.
  4. Si ha iniciado recientemente el servicio y tiene muchos objetos de usuario en el servidor de directorios, espere varios minutos para que el conector establezca una conexión con el servidor de directorios.
  5. En el servidor que ejecuta el host del conector ECMA de Microsoft Entra, inicie PowerShell.
  6. Cambie a la carpeta donde se instaló el host ECMA, como C:\Program Files\Microsoft ECMA2Host.
  7. Cambie al subdirectorio Troubleshooting.
  8. Ejecute el script TestECMA2HostConnection.ps1 en ese directorio como se muestra y proporcione 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 el nombre del conector y el token secreto coinciden 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, se espera este comportamiento 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 mostró 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 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 aplicaciones 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. Seleccione 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 administrador, 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 Value
    Dirección URL del inquilino https://localhost:8585/ecma2host_connectorName/scim

  3. Escriba el valor del token secreto que usted definió 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 funcionará hasta que se complete el registro. Forzar el registro del agente para completarse al reiniciar el agente de aprovisionamiento en su servidor puede acelerar el proceso de registro. Vaya a su servidor, busque servicios en la barra de búsqueda de Windows, identifique el servicio Microsoft Entra Connect Provisioning Agent, seleccione el servicio con el botón derecho y reinicie.

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

  5. Una vez que la prueba de conexión se haya realizado correctamente e indique que las credenciales proporcionadas están autorizadas para habilitar el aprovisionamiento, seleccione Guardar.
    Captura de pantalla que muestra la prueba de un agente.

Ampliar el esquema de Microsoft Entra

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 para proporcionar valores de esos atributos desde una constante, desde una expresión transformada desde otros atributos de Microsoft Entra o ampliando 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, debe generar ese atributo a partir de otros atributos del usuario a través de una expresión , o use 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 la sincronización en la nube de Microsoft Entra Connect. Esto configurará el atributo para que se sincronice desde Active Directory Domain Services a microsoft Entra ID, lo que hace que esté disponible para el aprovisionamiento en otros sistemas.

Si sus usuarios se originan en Microsoft Entra ID, necesitará definir una extensión de directorio para cada nuevo atributo a almacenar en un usuario. 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éis la asignación entre los atributos del usuario de Microsoft Entra y los atributos que seleccionasteis anteriormente en el Asistente de configuración de ECMA Host. Más adelante, cuando el conector crea un objeto en un servidor de directorios, los atributos de usuario de Microsoft Entra se envían 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 configura las asignaciones de atributos para esta aplicación, solo hay una asignación presente como 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 para que el esquema se actualice, luego seleccione Asignación de atributos en la línea de navegación y, a continuación, seleccione Editar lista de atributos para ScimOnPremises nuevamente para recargar 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. Utilice los siguientes valores para crear la asignación, cambiando 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: 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 suministren varios valores de clase de objeto estructural o valores de clase de objeto auxiliares en el atributo objectClass, entonces agregue un mapeo a ese atributo. Para agregar una asignación para objectClass, seleccione Agregar nueva asignación. Use los siguientes valores para crear la asignación, cambiando los nombres de las clases de objetos en la expresión para que coincidan con los del esquema del directorio de destino.

    • Tipo de asignación: expresión
    • 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. Para cada una de las asignaciones de la tabla siguiente para el servidor de directorios, seleccione Agregar nueva asignacióny especifique los atributos de origen y 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 OpenLDAP con el esquema POSIX, también deberá proporcionar los atributos gidNumber, homeDirectory, uid y uidNumber. Cada usuario requiere un uid único y un uidNumberúnico. Normalmente, el homeDirectory se establece mediante una expresión derivada del identificador de usuario del usuario. Por ejemplo, si la uid de un usuario se genera mediante una expresión derivada de su nombre principal de usuario, el valor del directorio principal de ese usuario podría generarse mediante una expresión similar también 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 mapeo Atributo de origen Atributo objetivo
    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
    Expresión 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
    Expresión 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

  8. 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.

  9. seleccione Guardar.

Asegúrese de que los usuarios que se aprovisionen en el directorio dispongan de los atributos necesarios.

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

Si planea crear nuevos usuarios en el directorio LDAP, debe asegurarse de que las representaciones de Microsoft Entra de esos usuarios tienen los atributos de origen requeridos por el esquema de usuario del directorio de destino. Cada usuario requiere un uid único y un uidNumberúnico.

Si sus usuarios se originan en Active Directory Domain Services y tienen el atributo en ese directorio, puede usar Microsoft Entra Connect o la sincronización en la nube de Microsoft Entra Connect para configurar la sincronización del atributo desde Active Directory Domain Services a Microsoft Entra ID, de modo que esté disponible para el aprovisionamiento en otros sistemas.

Si los usuarios se originan en Microsoft Entra ID, entonces para cada nuevo atributo que necesite almacenar en un usuario, 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.

Confirmación de usuarios a través de PowerShell

Una vez actualizados los usuarios en Microsoft Entra ID, puede utilizar los cmdletsMicrosoft Graph PowerShell para automatizar la comprobación de que los usuarios tienen todos los atributos necesarios.

Por ejemplo, supongamos que el aprovisionamiento requiere que los usuarios tengan tres atributos DisplayName,surname y extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty. Este tercer atributo se usa para contener el uidNumber. Puede usar el cmdlet Get-MgUser para recuperar cada usuario y comprobar si los atributos necesarios están presentes. Tenga en cuenta que el cmdlet graph v1.0 Get-MgUser, de forma predeterminada, no devuelve 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.

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

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 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. Conectarse a Microsoft Entra ID:

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

  4. Construya la lista de usuarios y los atributos que se van a comprobar.

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

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

  5. Consulte el directorio para cada uno de los usuarios.

    $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

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

  2. Ejecute un comando que recupere ese subconjunto de usuarios del directorio LDAP en un archivo CSV. Asegúrese de que la salida incluye los atributos de los usuarios que se usan para buscar coincidencias con el identificador de Microsoft Entra. Algunos ejemplos de estos atributos son id. de empleado, nombre de cuenta o uidy dirección de correo electrónico.

  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 instalado.

  4. Ahora que tiene una lista de todos los usuarios obtenidos del directorio, los comparará con los usuarios de 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 usando cmdlets de Microsoft Graph PowerShell.

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 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. Conectarse 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 obtenidos 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 de PowerShell Import-Csv 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

    Para 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 coincidirá con un atributo de un usuario en microsoft Entra ID.

    Si está utilizando SAP Cloud Identity Services, entonces la configuración predeterminada de mapeo es el atributo SCIM de SAP userName con el atributo Microsoft Entra ID userPrincipalName:

    $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_namey $azuread_match_attr_name especificados anteriormente. Consultará el identificador de Entra de Microsoft para buscar un usuario que tenga un atributo con un valor coincidente para cada registro del archivo de origen. Si hay muchos usuarios en el archivo obtenido del origen 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 con el valor deseado y necesita usar una expresión de filtro contains u otra, entonces deberá personalizar este script y el del paso 11 a continuación para emplear una expresión de filtro diferente.

    $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. Vea los resultados de las consultas anteriores. Verifique 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 faltantes.

    El siguiente script de PowerShell mostrará los recuentos de 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, indicará un error si no se encontraron registros del origen de datos en microsoft Entra ID. Si no todos los registros de los usuarios del almacén de datos de la aplicación podrían ubicarse como usuarios en el identificador de Entra de Microsoft, deberá investigar qué registros no coincidieron y por qué.

    Por ejemplo, la dirección de correo electrónico de alguien y su nombre principal de usuario podrían haber cambiado en Microsoft Entra ID sin que su propiedad mail correspondiente se actualice en el origen de datos de la aplicación. O bien, es posible que el usuario ya haya dejado la organización, pero todavía está en el origen de datos de la aplicación. O puede haber una cuenta de proveedor o superadministrador en el origen de datos de la aplicación que no se corresponda con ninguna persona específica de Microsoft Entra ID.

  10. Si había usuarios que no podían estar ubicados en el id. de Microsoft Entra, 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 para que el identificador de Microsoft Entra coincida más adelante con los usuarios existentes de la aplicación y los atributos requeridos por el identificador de Entra de Microsoft, incluidos userPrincipalName, mailNickname y displayName. El userPrincipalName debe ser único entre todos los usuarios del directorio.

    Por ejemplo, puede tener usuarios en una base de datos en la que el valor de la columna denominada EMail es el valor que desea usar como nombre principal de usuario de Microsoft Entra, el valor de la columna Alias contiene el alias de correo de Id. de Entra de Microsoft y el valor de la columna Full name contiene 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 identificador de Microsoft Entra. Tenga en cuenta que es posible que tenga que modificar este script para agregar atributos adicionales de Microsoft Entra necesarios en su organización o si el $azuread_match_attr_name no es mailNickname ni userPrincipalName, para proporcionar ese atributo 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 notifica 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."

Asigna usuarios a la aplicación en Microsoft Entra ID

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 inició 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 identidades híbridas no tiene permisos para asignar usuarios a las aplicaciones.

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

Si aún no desea actualizar los usuarios existentes en el directorio LDAP, seleccione un usuario de prueba de Microsoft Entra ID que tenga los atributos necesarios y se aprovisionará en el servidor de directorios.

  1. Asegúrese de que el usuario que seleccione tenga 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 Aplicación ECMA local.
  4. A la izquierda, en Administrar, seleccione Usuarios y grupos.
  5. Seleccione Agregar usuario/grupo. Captura de pantalla que muestra cómo agregar un usuario.
  6. En Usuarios, seleccione Ninguno seleccionado. Captura de pantalla que muestra la opción Ninguno seleccionado.
  7. Seleccione un usuario de la derecha y seleccione el botón Seleccionar.
    Captura de pantalla que muestra la selección de usuarios.
  8. Ahora seleccione Asignar. Captura de pantalla que muestra la asignación de usuarios.

Prueba del aprovisionamiento

Ahora que tus atributos están mapeados y se ha asignado un usuario inicial, puedes probar el aprovisionamiento a petición con uno de tus 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 de servicios, asegúrese de que el servicio Microsoft Entra Connect Provisioning Agent y el servicio Microsoft ECMA2Host están en ejecución. Si no es así, seleccione Iniciar.

  4. En Azure Portal, seleccione Aplicaciones empresariales.

  5. Seleccione 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 que muestra la prueba del aprovisionamiento a petición.

  9. Después de varios segundos, aparecerá el mensaje Usuario creado correctamente 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 realiza correctamente, agregue los usuarios restantes. Para obtener más información sobre cómo crear asignaciones de funciones de aplicación en bloque utilizando New-MgServicePrincipalAppRoleAssignedTo, consulte Gobernanza de los usuarios existentes de una aplicación en Microsoft Entra ID.

  1. En Azure Portal, seleccione la aplicación.
  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. Una vez completado 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 es Errory seleccione en esa fila.

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

Para obtener más información, cambie a la pestaña Solución de Problemas & Recomendaciones.

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 incluye solo nombres de 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 de aprovisionamiento, puede cambiar el estado de aprovisionamiento a Desactivary seleccionar Guardar. Esta acción impide que el servicio de aprovisionamiento se ejecute en el futuro.

Comprobación de que los usuarios se aprovisionaron correctamente

Después de esperar, compruebe el servidor de directorios para asegurarse de que los usuarios se están aprovisionando. La consulta que realice en el servidor de directorios dependerá de los comandos que proporcione el servidor de directorios.

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

  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 incluye los usuarios aprovisionados desde microsoft Entra ID.

Pasos siguientes