Compartir a través de

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

  • Artículo

La siguiente documentación es un tutorial que demuestra cómo gobernar el acceso a un sistema Linux. Esto se implementa mediante el aprovisionamiento de usuarios de Microsoft Entra en un directorio LDAP local de confianza para ese sistema Linux, de modo que esos usuarios puedan iniciar sesión posteriormente en un sistema Linux que se base en ese directorio LDAP para la autenticación de usuario. Y cuando se elimina a un usuario de Microsoft Entra ID, ya no puede iniciar sesión en un sistema Linux.

Nota:

El escenario descrito en este artículo solo se aplica a sistemas Linux existentes que ya dependen de un módulo LDAP de conmutación de servicios de nombres (NSS) o módulos de autenticación acoplables (PAM) 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 una plataforma de autenticación central y una autoridad de certificados para SSH en una VM Linux usando Microsoft Entra ID y autenticación basada en certificados OpenSSH, como se describe en Iniciar sesión en una máquina virtual Linux en Azure usando Microsoft Entra ID y OpenSSH.

Para 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 considera que el servidor LDAP ya está presente en el entorno local, utilizado por uno o más 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 POSIX que responda a un servidor de directorio que use un módulo PAM o NSS.
  • Un servidor de directorio LDAP compatible con el esquema POSIX, como OpenLDAP, en el que se puedan crear, actualizar y eliminar usuarios. Para más información sobre los servidores de directorio compatibles, 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, con conectividad al servidor de directorios de destino y con conectividad saliente a login.microsoftonline.com, otros Microsoft Online Services y dominios de Azure. Un ejemplo es una máquina virtual de Windows Server 2016 hospedada en IaaS de Azure o detrás de un proxy. Se necesita instalar .NET Framework 4.7.2 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 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 de administrador de identidad híbrida para configurar el agente de aprovisionamiento.

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

  • 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. En especial, se requiere que cada usuario tenga un número único como su número de identificación de usuario. Antes de implementar el agente de aprovisionamiento y la asignación de usuarios al directorio, usted tendría que generar ese número de un atributo existente en el usuario, o ampliar el esquema de Microsoft Entra y rellenar ese atributo en los usuarios en el ámbito. 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 usuarios de LDAP a Microsoft Entra ID.
  • No se admite el aprovisionamiento de pertenencias de grupos y usuarios a un servidor de directorios.

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 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 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 inetOrgPerson
clases de objetos auxiliares de un usuario en el servidor de directorios Asignaciones de atributos de la página Aprovisionamiento de Azure Portal 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 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 Establecer el DN de un usuario recién creado para que esté inmediatamente debajo de DC=Contoso,DC=lab
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 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. Un servidor de directorio OpenLDAP con el esquema POSIX para admitir la autenticación Linux quizás necesite que un objeto para un nuevo usuario tenga atributos como los del siguiente ejemplo.

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 su escenario involucra la creación de nuevos usuarios en el directorio LDAP, no solo la actualización o eliminación de usuarios existentes, entonces necesitará también determinar cómo los sistemas Linux que usan ese servidor de directorio manejarán la autenticación. Algunos sistemas pueden consultar la clave pública SSH de un usuario o un certificado del directorio, lo que puede ser apropiado si los usuarios ya tienen credenciales de esas formas. 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.

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

Configurar el 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 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: 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 se produce un problema al intentar conectarse y no puede pasar a la página Global, asegúrese de que la cuenta de servicio en el servidor de directorio 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 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. Si no necesita implementar la importación diferencial, 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 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. Use inetOrgPerson, y 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. Por lo general, se usa el nombre completo, que puede seleccionarse como -dn-. Los atributos multivalor, como el atributo uid del esquema OpenLDAP, no se pueden usar como delimitadores.
    Atributo de consulta Este atributo suele ser el mismo que el delimitador.
    DN El valor distinguishedName del objeto de destino. Conserve -dn-.
    Generado automáticamente Desactivado

  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.

    Configure la visibilidad de los siguientes atributos.

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

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 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. Ejecute el script TestECMA2HostConnection.ps1 en ese directorio como se muestra a continuación y proporcione como argumentos el nombre del conector y el valor cache de ObjectTypePath. 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 la ventana agotó el tiempo de espera, tendrá que 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

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. Use los valores siguientes 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 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 agregar una asignación para objectClass, seleccione Agregar nueva asignación. Use los valores siguientes para crear la asignación, cambiando 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 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, 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 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
    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
    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

  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 van a aprovisionar en el directorio tienen los atributos requeridos

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. Cada usuario requiere un valor único uid y un uidNumber único.

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.

Confirmación de usuarios a través de PowerShell

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

Por ejemplo, supongamos que el aprovisionamiento requiere que los usuarios tengan tres atributos, DisplayName, surname y extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty. Este tercer atributo se utilizará para contener el uidNumber. 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.

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.Read.All,Application.ReadWrite.All,AppRoleAssignment.ReadWrite.All,EntitlementManagement.ReadWrite.All"

  4. Cree la lista de usuarios y los atributos que debe comprobar.

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

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

  5. Consultar 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 cuales de los usuarios en ese directorio están en el ámbito para ser usuarios con autenticación Linux. Esta elección dependerá de la configuración de su 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 particular o sea miembro de un grupo en ese directorio.

  2. Ejecute un comando que recupere ese subconjunto de usuarios de su directorio LDAP en un archivo CSV. 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 ID de empleado, nombre de cuenta o uid y 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 instalados.

  4. Ahora que tiene una lista de todos los usuarios obtenidos del directorio, va a hacer coincidir esos usuarios del directorio 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."

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

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

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

  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.

Las siguientes instrucciones ilustran cómo consultar 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 incluya a los usuarios aprovisionados desde Microsoft Entra ID.

Pasos siguientes