Compartir a través de

Gobernanza de los usuarios existentes de una aplicación: Microsoft PowerShell

  • Artículo

Hay tres escenarios comunes en los que es necesario rellenar Microsoft Entra ID con los usuarios actuales de una aplicación antes de usar la aplicación con la característica Microsoft Entra ID Governance, como las revisiones de acceso.

Requisitos de licencia

El uso de esta característica requiere licencias de Gobierno de Microsoft Entra ID o Microsoft Entra Suite. Para encontrar la licencia adecuada para sus requisitos, consulte Aspectos básicos de las licencias gubernamentales de id. de Microsoft Entra.

Aplicación migrada a Microsoft Entra ID después de usar su propio proveedor de identidades

En el primer escenario, la aplicación ya existe en el entorno. Antes, la aplicación utilizaba su propio proveedor de identidades o almacén de datos para realizar un seguimiento de los usuarios que tenían acceso.

Al cambiar la aplicación para que use Microsoft Entra ID, solo los usuarios que están en Microsoft Entra ID y tienen permitido el acceso a esa aplicación pueden acceder a ella. Dentro de este cambio de configuración, puede incorporar a Microsoft Entra ID los usuarios actuales del almacén de datos de la aplicación. Después, esos usuarios siguen teniendo acceso a través de Microsoft Entra ID.

Tener los usuarios que están asociados a la aplicación representados en Microsoft Entra ID permite que Microsoft Entra ID haga un seguimiento de los usuarios con acceso a la aplicación, aunque la relación de los usuarios con la aplicación se haya originado en otro lugar. Por ejemplo, la relación podría haberse originado en la base de datos o directorio de una aplicación.

Una vez que Microsoft Entra ID conoce la asignación de un usuario, puede enviar actualizaciones al almacén de datos de la aplicación. Entre las actualizaciones, se incluye cuando cambian los atributos de ese usuario o cuando el usuario sale del ámbito de la aplicación.

Aplicación que no usa Microsoft Entra ID como único proveedor de identidades

En el segundo escenario, una aplicación no tiene Microsoft Entra ID como único proveedor de identidades.

En algunos casos, una aplicación podría depender de grupos de AD. Este escenario se describe en el patrón B en Preparación de una revisión del acceso de los usuarios a una aplicación. No es necesario configurar el aprovisionamiento para esa aplicación tal como se describe en ese artículo; en su lugar, siga las instrucciones del patrón B en ese artículo sobre cómo revisar la pertenencia de grupos de AD.

En otros casos, una aplicación puede admitir varios proveedores de identidades o tener su propio almacenamiento de credenciales integrado. Este escenario se describe como patrón C en Preparación de una revisión del acceso de los usuarios a una aplicación.

Es posible que no sea factible quitar otros proveedores de identidades o la autenticación de credenciales locales de la aplicación. En este caso, si desea usar Microsoft Entra ID para revisar quién tiene acceso a esa aplicación o quitarle el acceso a alguien a esa aplicación, debe crear asignaciones en Microsoft Entra ID que representen a los usuarios de la aplicación que no dependen de Microsoft Entra ID para la autenticación.

Es necesario tener estas asignaciones si planea revisar todos los usuarios con acceso a la aplicación como parte de una revisión de acceso.

Por ejemplo, supongamos que un usuario está en el almacén de datos de la aplicación. Microsoft Entra ID está configurado para requerir asignaciones de roles a la aplicación. Sin embargo, el usuario no tiene una asignación de rol de aplicación en Microsoft Entra ID.

Si se actualiza el usuario en Microsoft Entra ID, no se envía ningún cambio a la aplicación. Y si se revisan las asignaciones de roles de la aplicación, el usuario no se incluirá en la revisión. Para que se incluyan todos los usuarios en la revisión, es necesario tener asignaciones de roles de aplicación para todos los usuarios de la aplicación.

La aplicación no usa Microsoft Entra ID como proveedor de identidades ni admite aprovisionamiento

En el caso de algunas aplicaciones heredadas, puede que no sea factible quitar otros proveedores de identidades o la autenticación de credenciales locales de la aplicación, o habilitar la compatibilidad con protocolos de aprovisionamiento para esas aplicaciones.

Ese escenario de una aplicación que no admite protocolos de aprovisionamiento se trata en un artículo distinto, Gobernanza de los usuarios existentes de una aplicación que no admite el aprovisionamiento.

Terminología

En este artículo, se muestra el proceso de administración de las asignaciones de roles de aplicación mediante cmdlets de PowerShell de Microsoft Graph. Se usa la siguiente terminología de Microsoft Graph.

Diagrama que muestra la terminología de Microsoft Graph.

En Microsoft Entra ID, una entidad de servicio (ServicePrincipal) representa una aplicación del directorio de una organización determinada. El elemento ServicePrincipal tiene una propiedad llamada AppRoles, que enumera los roles que admite una aplicación, como Marketing specialist. Un elemento AppRoleAssignment vincula un usuario a una entidad de servicio y especifica qué rol tiene el usuario en esa aplicación. Una aplicación puede tener más de una entidad de servicio, si el inicio de sesión único en la aplicación y el aprovisionamiento de la aplicación se controlan por separado.

También puede usar los paquetes de acceso de la administración de derechos de Microsoft Entra para conceder a los usuarios acceso limitado en el tiempo a la aplicación. En la administración de derechos, un elemento AccessPackage contiene uno o varios roles de recursos, potencialmente de varias entidades de servicio. El elemento AccessPackage también tiene asignaciones (Assignment) para los usuarios al paquete de acceso.

Al crear una asignación para un usuario a un paquete de acceso, la administración de derechos de Microsoft Entra crea automáticamente las instancias de AppRoleAssignment necesarias para el usuario para la entidad de servicio de cada aplicación en el paquete de acceso. Para obtener más información, vea el tutorial Administrar el acceso a recursos en la administración de derechos de Microsoft Entra sobre cómo crear paquetes de acceso a través de PowerShell.

Antes de empezar

  • Debe tener una de las siguientes licencias en el inquilino:

    • Microsoft Entra ID P2 o Microsoft Entra ID Governance
    • Licencia de Enterprise Mobility + Security E5

  • Debe tener un rol administrativo adecuado. Si es la primera vez que realiza estos pasos, necesitará el rol Administrador global para autorizar el uso de PowerShell de Microsoft Graph en el inquilino.

  • La aplicación necesita al menos una entidad de servicio en el inquilino:

Recopilación de los usuarios existentes de una aplicación

El primer paso para garantizar que todos los usuarios se hayan registrado en Microsoft Entra ID es recopilar la lista de usuarios existentes que tienen acceso a la aplicación.

Algunas aplicaciones pueden tener un comando integrado para exportar una lista de los usuarios actuales del almacén de datos. En otros casos, la aplicación puede depender de un directorio o base de datos externos.

En algunos entornos, es posible que la aplicación se encuentre en un segmento de red o un sistema que no sea adecuado para administrar el acceso a Microsoft Entra ID. Por tanto, es posible que tenga que extraer la lista de usuarios de ese directorio o base de datos y transferirla como un archivo a otro sistema que se pueda usar para las interacciones de Microsoft Entra.

En esta sección, se explican cuatro enfoques de cómo obtener una lista de usuarios en un archivo de valores separados por comas (CSV):

  • Desde un directorio LDAP
  • Desde una base de datos de SQL Server
  • Desde otra base de datos basada en SQL
  • Desde SAP Cloud Identity Services

Recopilación de los usuarios existentes de una aplicación que usa un directorio LDAP

Esta sección trata sobre las aplicaciones que usan un directorio LDAP como almacén de datos subyacente para los usuarios que no se autentican en Microsoft Entra ID. Muchos directorios LDAP, como Active Directory, incluyen un comando que genera una lista de usuarios.

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

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

    Por ejemplo, este comando produciría un archivo .csv en el directorio del sistema de archivos actual con el atributo userPrincipalName de cada persona del directorio LDAP:

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

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

  4. Continúe leyendo en la sección Confirmación de que Microsoft Entra ID tiene usuarios que coinciden con los usuarios de la aplicación más adelante en este artículo.

Recopilación de los usuarios existentes de la tabla de base de datos de una aplicación mediante un asistente de SQL Server

Esta sección se aplica a las aplicaciones que usan SQL Server como almacén de datos subyacente.

En primer lugar, obtenga una lista de los usuarios desde las tablas. La mayoría de las bases de datos proporcionan una manera de exportar el contenido de las tablas a un formato de archivo estándar, como a un archivo .csv. Si la aplicación usa una base de datos de SQL Server, puede usar el Asistente para importación y exportación de SQL Server para exportar partes de una base de datos. Si no tiene una utilidad para la base de datos, puede usar el controlador ODBC con PowerShell, como se describe en la sección siguiente.

  1. Inicie sesión en el sistema donde está instalado SQL Server.
  2. Abra Importación y exportación de SQL Server 2019 (64 bits) o el equivalente para su base de datos.
  3. Seleccione la base de datos existente como origen.
  4. Como Destino, seleccione Destino de archivo plano. Proporcione un nombre de archivo y cambie el valor de Página de códigos a 65001 (UTF-8).
  5. Complete el asistente y seleccione la opción para ejecutarlo inmediatamente.
  6. Espere a que finalice la ejecución.
  7. 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.
  8. Continúe leyendo en la sección Confirmación de que Microsoft Entra ID tiene usuarios que coinciden con los usuarios de la aplicación más adelante en este artículo.

Recopilación de los usuarios existentes de la tabla de base de datos de una aplicación mediante PowerShell

Esta sección se aplica a las aplicaciones que usan otra base de datos SQL como almacén de datos subyacente, en la que se usa el host del conector ECMA para aprovisionar usuarios en esa aplicación. Si aún no ha configurado el agente de aprovisionamiento, use esa guía para crear el archivo de conexión DSN que usará en esta sección.

  1. Inicie sesión en el sistema donde está o se instalará el agente de aprovisionamiento.

  2. Abra PowerShell.

  3. Construya una cadena de conexión para conectarse al sistema de base de datos.

    Los componentes de una cadena de conexión dependen de los requisitos de la base de datos. Si usa SQL Server, consulte la lista de Atributos y palabras clave de cadena de conexión y DSN.

    Si usa otra base de datos, debe incluir las palabras clave obligatorias para conectarse a esa base de datos. Por ejemplo, si la base de datos usa el nombre de ruta de acceso completo del archivo DSN, un identificador de usuario y una contraseña, construya la cadena de conexión mediante los siguientes comandos:

    $filedsn = "c:\users\administrator\documents\db.dsn"
$db_cs = "filedsn=" + $filedsn + ";uid=p;pwd=secret"

  4. Abra una conexión a la base de datos y proporcione la cadena de conexión mediante los siguientes comandos:

    $db_conn = New-Object data.odbc.OdbcConnection
$db_conn.ConnectionString = $db_cs
$db_conn.Open()

  5. Construya una consulta SQL para recuperar los usuarios de la tabla de base de datos. Asegúrese de incluir las columnas que se usarán para buscar coincidencias entre los usuarios de la base de datos de la aplicación y los usuarios de Microsoft Entra ID. Las columnas pueden incluir el identificador de empleado, el nombre de la cuenta o la dirección de correo electrónico.

    Por ejemplo, si los usuarios se mantienen en una tabla de base de datos llamada USERS que tiene las columnas name y email, escriba el siguiente comando:

    $db_query = "SELECT name,email from USERS"

  6. Envíe la consulta a la base de datos mediante la conexión:

    $result = (new-object data.odbc.OdbcCommand($db_query,$db_conn)).ExecuteReader()
$table = new-object System.Data.DataTable
$table.Load($result)

    El resultado es la lista de filas que representan a los usuarios recuperados de la consulta.

  7. Escriba el resultado en un archivo .csv:

    $out_filename = ".\users.csv"
$table.Rows | Export-Csv -Path $out_filename -NoTypeInformation -Encoding UTF8

  8. Si este sistema no tiene instalados los cmdlets de PowerShell de Microsoft Graph o no tiene conectividad con Microsoft Entra ID, transfiera el archivo .csv que contiene la lista de usuarios a un sistema que tenga instalados los cmdlets de PowerShell de Microsoft Graph.

Recopilación de usuarios existentes desde SAP Cloud Identity Services

Esta sección se aplica a las aplicaciones de SAP que usan SAP Cloud Identity Services como servicio subyacente para el aprovisionamiento de usuarios.

  1. Inicie sesión en la consola de administración de SAP Cloud Identity Services, https://<tenantID>.accounts.ondemand.com/admin o https://<tenantID>.trial-accounts.ondemand.com/admin, si se trata de una prueba.
  2. Vaya a Usuarios y autorizaciones > Exportar usuarios.
  3. Seleccione todos los atributos necesarios para hacer coincidir los usuarios de Microsoft Entra con los de SAP. Esto incluye los atributos SCIM ID, userName, emails, y otros que pueda estar usando en sus sistemas SAP.
  4. Seleccione Exportar y espere a que el explorador descargue el archivo CSV.
  5. Si este sistema no tiene instalados los cmdlets de PowerShell de Microsoft Graph o no tiene conectividad con Microsoft Entra ID, transfiera el archivo .csv que contiene la lista de usuarios a un sistema que tenga instalados los cmdlets de PowerShell de Microsoft Graph.

Confirmar que Microsoft Entra ID tiene usuarios que coinciden con los usuarios de la aplicación

Ahora que ha obtenido de la aplicación una lista de todos los usuarios, hará coincidir los usuarios del almacén de datos de la aplicación con los usuarios en Microsoft Entra ID.

Antes de continuar, revise la información sobre los usuarios coincidentes en los sistemas de origen y de destino. Después, configurará el aprovisionamiento de Microsoft Entra con asignaciones equivalentes. Ese paso permitirá el aprovisionamiento de Microsoft Entra para consultar el almacén de datos de la aplicación con las mismas reglas de coincidencia.

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

Registro de la aplicación

Si la aplicación ya está registrada en Microsoft Entra ID, continúe con el paso siguiente.

Comprobar los usuarios que aún no están asignados a la aplicación

Los pasos anteriores han confirmado que todos los usuarios del almacén de datos de la aplicación existen como usuarios en Microsoft Entra ID. Sin embargo, es posible que actualmente no se hayan asignado todos a los roles de la aplicación en Microsoft Entra ID. Por lo tanto, los pasos siguientes consisten en ver qué usuarios no tienen asignaciones a roles de aplicación.

  1. Busque el identificador de la entidad de servicio de la aplicación. Si creó recientemente una entidad de servicio para una aplicación que usa un directorio LDAP o una base de datos SQL, use el nombre de esa entidad de servicio.

    Por ejemplo, si la aplicación empresarial se llama CORPDB1, escriba los siguientes comandos:

    $azuread_app_name = "CORPDB1"
$azuread_sp_filter = "displayName eq '" + ($azuread_app_name -replace "'","''") + "'"
$azuread_sp = Get-MgServicePrincipal -Filter $azuread_sp_filter -All

  2. Recupere los usuarios que tienen actualmente asignaciones a la aplicación en Microsoft Entra ID.

    Esto se basa en la variable $azuread_sp establecida en el comando anterior.

    $azuread_existing_assignments = @(Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $azuread_sp.Id -All)

  3. Compare la lista de identificadores de usuario de la sección anterior con los usuarios asignados actualmente a la aplicación:

    $azuread_not_in_role_list = @()
foreach ($id in $azuread_match_id_list) {
   $found = $false
   foreach ($existing in $azuread_existing_assignments) {
      if ($existing.principalId -eq $id) {
         $found = $true; break;
      }
   }
   if ($found -eq $false) { $azuread_not_in_role_list += $id }
}
$azuread_not_in_role_count = $azuread_not_in_role_list.Count
Write-Output "$azuread_not_in_role_count users in the application's data store are not assigned to the application roles."

    Si 0 usuarios no están asignados a roles de aplicación, lo que indica que todos los usuarios están asignados a roles de aplicación, no tiene que hacer más cambios antes de realizar una revisión de acceso.

    Sin embargo, si uno o varios usuarios no están asignados actualmente a los roles de la aplicación, deberá seguir el procedimiento y agregarlos a uno de los roles de la aplicación.

  4. Seleccione el rol de la aplicación al que va a asignar los usuarios restantes.

    Una aplicación puede tener más de un rol y una entidad de servicio puede tener roles adicionales. Use este comando para ver los roles disponibles de una entidad de servicio:

    $azuread_sp.AppRoles | where-object {$_.AllowedMemberTypes -contains "User"} | ft DisplayName,Id

    Seleccione el rol adecuado en la lista y obtenga su identificador de rol. Por ejemplo, si el nombre del rol es Admin, proporcione ese valor en los siguientes comandos de PowerShell:

    $azuread_app_role_name = "Admin"
$azuread_app_role_id = ($azuread_sp.AppRoles | where-object {$_.AllowedMemberTypes -contains "User" -and $_.DisplayName -eq $azuread_app_role_name}).Id
if ($null -eq $azuread_app_role_id) { write-error "role $azuread_app_role_name not located in application manifest"}

Configuración del aprovisionamiento de la aplicación

Si la aplicación usa un directorio LDAP, una base de datos SQL, SAP Cloud Identity Services o admite SCIM, antes de crear asignaciones, configure el aprovisionamiento de usuarios de Microsoft Entra en la aplicación. La configuración del aprovisionamiento antes de crear asignaciones permite que Microsoft Entra ID establezca la coincidencia entre los usuarios de Microsoft Entra ID y las asignaciones de roles de la aplicación a los usuarios que ya están en el almacén de datos de la aplicación. Si la aplicación tiene un directorio local o una base de datos que se va a aprovisionar y también admite el inicio de sesión único federado, es posible que necesite dos entidades de servicio para representar la aplicación en el directorio: una para el aprovisionamiento y otra para el inicio de sesión único. Si la aplicación no admite el aprovisionamiento, siga leyendo la sección siguiente.

  1. Asegúrese de que la aplicación esté configurada para requerir que los usuarios tengan asignaciones de roles de aplicación, de modo que solo se aprovisionarán los usuarios seleccionados en la aplicación.

  2. Si no se ha configurado el aprovisionamiento para la aplicación, configúrelo ahora (pero no inicie el aprovisionamiento):

  3. Revise la pestaña Propiedades de la aplicación. Verifique que la opción ¿Asignación de usuario obligatoria? esté establecida en Sí. Si se establece en No, todos los usuarios del directorio, incluidas las identidades externas, pueden acceder a la aplicación y no puede revisar el acceso a la aplicación.

  4. Compruebe las asignaciones de atributos para el aprovisionamiento en esa aplicación. Asegúrese de que la opción Hacer coincidir objetos con este atributo esté establecida para el atributo y la columna de Microsoft Entra que usó en las secciones anteriores para buscar coincidencias.

    Si estas reglas no usan los mismos atributos que usó antes, es posible que, cuando se creen las asignaciones de roles de la aplicación, Microsoft Entra ID no pueda encontrar los usuarios actuales en el almacén de datos de la aplicación. En este caso, Microsoft Entra ID podría crear usuarios duplicados accidentalmente.

  5. Compruebe que haya una asignación de atributos para isSoftDeleted para un atributo de la aplicación.

    Cuando un usuario se desasigna de la aplicación, se elimina temporalmente en Microsoft Entra ID o se bloquea para que no pueda iniciar sesión, el aprovisionamiento de Microsoft Entra ID actualiza el atributo asignado a isSoftDeleted. Si no se ha asignado ningún atributo, los usuarios que más adelante no tengan asignado el rol de aplicación seguirán existiendo en el almacén de datos de la aplicación.

  6. Si ya se ha habilitado el aprovisionamiento para la aplicación, compruebe que el aprovisionamiento de la aplicación no esté en cuarentena. Resuelva los problemas que causan la cuarentena antes de continuar.

Creación de asignaciones de roles de aplicación en Microsoft Entra ID

Para que Microsoft Entra ID haga coincidir a los usuarios de la aplicación con los usuarios de Microsoft Entra ID, debe crear asignaciones de roles de aplicación en Microsoft Entra ID. Cada asignación de roles de aplicación asocia un usuario a un rol de aplicación de una entidad de servicio.

Cuando se crea una asignación de un rol de aplicación en Microsoft Entra ID para un usuario y la aplicación admite el aprovisionamiento:

  • Microsoft Entra ID consulta la aplicación a través de SCIM, o su directorio o base de datos, para determinar si el usuario ya existe.
  • Cuando se realicen actualizaciones posteriores a los atributos del usuario en Microsoft Entra ID, Microsoft Entra ID enviará esas actualizaciones a la aplicación.
  • El usuario permanecerá en la aplicación indefinidamente, a menos que se actualice fuera de Microsoft Entra ID o hasta que se quite la asignación en Microsoft Entra ID.
  • En la siguiente revisión de acceso de las asignaciones de roles de esa aplicación, se incluirá al usuario en la revisión de acceso.
  • Si se deniega al usuario en una revisión de acceso, se quitará su asignación de roles de aplicación. Microsoft Entra ID notifica a la aplicación que el usuario tiene bloqueado el inicio de sesión.

Si la aplicación no admite el aprovisionamiento,

  • El usuario permanecerá en la aplicación indefinidamente, a menos que se actualice fuera de Microsoft Entra ID o hasta que se quite la asignación en Microsoft Entra ID.
  • En la siguiente revisión de las asignaciones de roles de esa aplicación, se incluirá al usuario en la revisión.
  • Si se deniega al usuario en una revisión de acceso, se quitará su asignación de roles de aplicación. El usuario ya no puede iniciar sesión en la aplicación desde Microsoft Entra ID.

  1. Cree asignaciones de roles de aplicación para los usuarios que no tienen actualmente asignaciones de roles:

    foreach ($u in $azuread_not_in_role_list) {
   $res = New-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $azuread_sp.Id -AppRoleId $azuread_app_role_id -PrincipalId $u -ResourceId $azuread_sp.Id 
}

  2. Espere un minuto para que los cambios se propaguen en Microsoft Entra ID.

Comprobación de que el aprovisionamiento de Microsoft Entra ha establecido la coincidencia de los usuarios actuales

  1. Consulte en Microsoft Entra ID para obtener la lista actualizada de asignaciones de roles:

    $azuread_existing_assignments = @(Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $azuread_sp.Id -All)

  2. Compare la lista de identificadores de usuario de la sección anterior con los usuarios asignados actualmente a la aplicación:

    $azuread_still_not_in_role_list = @()
foreach ($id in $azuread_match_id_list) {
   $found = $false
   foreach ($existing in $azuread_existing_assignments) {
      if ($existing.principalId -eq $id) {
         $found = $true; break;
      }
   }
   if ($found -eq $false) { $azuread_still_not_in_role_list += $id }
}
$azuread_still_not_in_role_count = $azuread_still_not_in_role_list.Count
if ($azuread_still_not_in_role_count -gt 0) {
   Write-Output "$azuread_still_not_in_role_count users in the application's data store are not assigned to the application roles."
}

    Si algún usuario no se ha asignado a roles de aplicación, compruebe el registro de auditoría de Microsoft Entra para ver si hay algún error en un paso anterior.

  3. Si la entidad de servicio de aplicación está configurada para el aprovisionamiento y el estado del aprovisionamiento de la entidad de servicio es Desactivado, colóquelo en Activado. También puede empezar a aprovisionar mediante Graph API.

  4. En función de las indicaciones sobre cuánto tiempo se tarda en aprovisionar usuarios, espere a que el aprovisionamiento de Microsoft Entra establezca la coincidencia entre los usuarios actuales de la aplicación y los usuarios recién asignados.

  5. Supervise el estado de aprovisionamiento a través del portal o las Graph API para asegurarse de que todos los usuarios coincidan correctamente.

    Si no ve que se aprovisionen usuarios, consulte la guía de solución de problemas No se está aprovisionando ningún usuario. Si ve un error en el estado de aprovisionamiento y está aprovisionando en una aplicación local, consulte la guía sobre solución de problemas de aprovisionamiento de aplicaciones locales.

  6. Compruebe el registro de aprovisionamiento a través del Centro de administración de Microsoft Entra o Graph API. Filtre el registro por el estado Failure (Error). Si hay errores con el código DuplicateTargetEntries, indica ambigüedad en las reglas de coincidencia del aprovisionamiento y tendrá que actualizar los usuarios de Microsoft Entra o las asignaciones que se usan para establecer la coincidencia, con el fin de asegurarse de que cada usuario de Microsoft Entra coincida con un usuario de la aplicación. A continuación, filtre el registro por la acción Create (Crear) y el estado Skipped (Omitido). Si se han omitido usuarios con el código NotEffectivelyEntitled para SkipReason, puede indicar que no se estableció la coincidencia de las cuentas de usuario de Microsoft Entra ID porque el estado de las cuentas de usuario era Deshabilitado.

Una vez que el servicio de aprovisionamiento de Microsoft Entra ha establecido la coincidencia de los usuarios en función de las asignaciones de roles de la aplicación que ha creado, se envían a la aplicación los cambios posteriores que se realicen en esos usuarios.

Selección de revisores adecuados

Al crear las revisiones de acceso, los administradores pueden elegir uno o más revisores. Todos los revisores pueden llevar a cabo una revisión; y elegir los usuarios que seguirán teniendo acceso a un recurso, o bien eliminarlos.

Normalmente, un propietario de recursos es responsable de realizar una revisión. Si va a crear una revisión de un grupo, como parte de la revisión del acceso de una aplicación integrada en el patrón B, puede seleccionar los propietarios del grupo como revisores. Como las aplicaciones de Microsoft Entra ID no tienen necesariamente un propietario, la opción para seleccionar el propietario de la aplicación como revisor no es posible. En su lugar, al crear la revisión, puede proporcionar los nombres de los propietarios de la aplicación para que sean los revisores.

También puede elegir, al crear una revisión de un grupo o una aplicación, realizar una revisión en varias fases. Por ejemplo, puede seleccionar que el administrador de cada usuario asignado realice la primera fase de la revisión y el propietario del recurso la segunda. De este modo, el propietario del recurso puede centrarse en los usuarios que su administrador ya ha aprobado.

Antes de crear las revisiones, compruebe que tenga suficientes puestos de SKU de Gobierno de id. de Microsoft Entra o Microsoft Entra ID P2 en el inquilino. Además, compruebe que todos los revisores son usuarios activos con direcciones de correo electrónico. Cuando se inician las revisiones de acceso, cada una revisa un correo electrónico desde Microsoft Entra ID. Si el revisor no tiene un buzón, no recibirá el correo electrónico cuando se inicie la revisión ni un recordatorio por correo electrónico. Y, si están bloqueados para poder iniciar sesión en Microsoft Entra ID, no podrán realizar la revisión.

Configuración de revisiones de acceso o administración de derechos

Una vez que los usuarios están en los roles de aplicación, y usted tiene los revisores identificados, entonces usted puede gobernar esos usuarios y cualquier usuario adicional que necesitará acceso, usando revisiones de acceso o administración de derechos.

Revisión y eliminación de accesos existentes mediante una revisión de accesos de asignaciones de roles de la aplicación

Si la aplicación tiene múltiples roles de aplicación, está representada por múltiples principales de servicio, o desea tener un proceso para que los usuarios soliciten o se les asigne acceso a la aplicación, entonces continúe en la siguiente sección de este artículo para regular el acceso mediante la administración de derechos.

Ahora que los usuarios existentes tienen asignaciones a un rol de aplicación, puede configurar Microsoft Entra ID para iniciar una revisión de esas asignaciones.

  1. Para este paso, deberá estar en el rol Administrador global o Administrador de gobernanza de identidades.

  2. Siga las instrucciones de la guía para crear una revisión de acceso de grupos o aplicaciones para crear la revisión de las asignaciones de rol de la aplicación. Configure la revisión para que se apliquen los resultados cuando termine. Puede crear la revisión de acceso en PowerShell con el cmdlet New-MgIdentityGovernanceAccessReviewDefinition de los cmdlets de PowerShell de Microsoft Graph para el módulo Identity Governance. Para obtener más información, vea los ejemplos.

    Nota:

    Si habilita los ayudantes de decisión de revisión al crear la revisión de acceso, entonces las recomendaciones del ayudante de decisión se basan en el periodo de intervalo de 30 días en función de la última vez que el usuario inició sesión en la aplicación utilizando Microsoft Entra ID.

  3. Cuando se inicie la revisión de acceso, pida a los revisores que proporcionen una entrada. De manera predeterminada, cada uno de ellos recibe un correo electrónico de Microsoft Entra ID con un enlace al panel de acceso, donde revisan el acceso a la aplicación.

  4. Una vez iniciadas las revisiones, puede supervisar su progreso y actualizar los aprobadores si es necesario, hasta que finalice la revisión de acceso. A continuación, puede confirmar que se está quitando, para los usuarios cuyo acceso han denegado los revisores, el acceso de la aplicación.

  5. Si no se seleccionó la aplicación automática cuando se creó la revisión, deberá aplicar los resultados de la revisión cuando se complete.

  6. Espere a que el estado de la revisión cambie a Resultado aplicado. En unos minutos se eliminarán las asignaciones de roles de aplicación de los usuarios denegados, si los hubiera.

  7. Una vez aplicados los resultados, Microsoft Entra ID comenzará a desaprovisionar a los usuarios denegados de la aplicación. De acuerdo con la orientación sobre cuánto tiempo se tardará en aprovisionar a los usuarios, espere a que el aprovisionamiento de Microsoft Entra comience a desaprovisionar a los usuarios denegados. Supervise el estado de aprovisionamiento a través de las API de Portal o Graph para asegurarse de que todos los usuarios denegados se eliminaron correctamente.

    Si no ve que se desaprovisionan usuarios, consulte la guía de solución de problemas para ver si no se aprovisionan usuarios. Si ve un error en el estado de aprovisionamiento y está aprovisionando en una aplicación local, consulte la guía sobre solución de problemas de aprovisionamiento de aplicaciones locales.

Ahora que tiene una línea de base que garantiza que el acceso existente ha sido revisado, puede continuar en la siguiente sección para configurar la gestión de derechos, para permitir nuevas solicitudes de acceso.

Controlar el acceso mediante la administración de derechos

En otras situaciones, por ejemplo, si quiere tener revisores diferentes para cada rol de la aplicación, la aplicación se representa con varias entidades de servicio; o bien, si quiere tener un proceso para que los usuarios soliciten o se les asigne acceso a la aplicación, puede configurar Microsoft Entra ID con un paquete de acceso para cada rol de aplicación. Cada paquete de acceso puede tener una directiva para revisar periódicamente las asignaciones realizadas a ese paquete de acceso. Una vez creados los paquetes de acceso y las directivas, puede asignar los usuarios que tengan asignadas roles de aplicación a los paquetes de acceso, de modo que sus asignaciones puedan revisarse a través del paquete de acceso.

En esta sección, configurará la administración de derechos de Microsoft Entra para una revisión de las asignaciones de paquetes de acceso que contienen las asignaciones de roles de la aplicación y también configurará directivas adicionales para que los usuarios puedan solicitar acceso a los roles de su aplicación.

  1. Para este paso, necesitará tener el rol de Administrador global o Administrador de gobernanza de identidades, o estar delegado como creador de catálogos y ser el propietario de la aplicación.
  2. Si aún no tiene un catálogo para el escenario de gobernanza de aplicaciones, cree un catálogo en la administración de derechos de Microsoft Entra. Puede usar un script de PowerShell para crear cada catálogo.
  3. Rellene el catálogo con los recursos necesarios, agregando la aplicación y los grupos de Microsoft Entra en los que se basa la aplicación, como recursos de ese catálogo. Puede usar un script de PowerShell para agregar cada recurso a un catálogo.
  4. Para cada una de las aplicaciones, y para cada uno de sus roles o grupos de aplicación, cree un paquete de acceso que incluya ese rol o grupo como su recurso. En esta fase de configuración de estos paquetes de acceso, configure la primera directiva de asignación de paquetes de acceso en cada paquete de acceso como una directiva para la asignación directa, de modo que solo los administradores puedan crear asignaciones en esa directiva y establezca los requisitos de revisión de acceso para los usuarios existentes, si los hubiera, para que no mantengan el acceso indefinidamente. Si tiene muchos paquetes de acceso, puede utilizar un script de PowerShell para crear cada paquete de acceso en un catálogo.
  5. Para cada paquete de acceso, asigne los usuarios existentes de la aplicación en ese rol correspondiente, o los miembros de ese grupo, al paquete de acceso y a su directiva de asignación directa. Puede asignar directamente un usuario a un paquete de acceso a través del Centro de administración Microsoft Entra o de forma masiva a través de Graph o PowerShell.
  6. Si ha configurado revisiones de acceso en las directivas de asignación de paquetes de acceso, cuando se inicie la revisión de acceso, pida a los revisores que proporcionen información. De manera predeterminada, cada uno de ellos recibe un correo electrónico de Microsoft Entra ID con un enlace al panel de acceso, donde revisarán las asignaciones de paquetes de acceso. Cuando finalice la revisión, en unos minutos se eliminarán las asignaciones de roles de aplicación de los usuarios denegados, si los hubiera. A continuación, Microsoft Entra ID comenzará a desaprovisionar a los usuarios denegados de la aplicación. De acuerdo con la orientación sobre cuánto tiempo se tardará en aprovisionar a los usuarios, espere a que el aprovisionamiento de Microsoft Entra comience a desaprovisionar a los usuarios denegados. Supervise el estado de aprovisionamiento a través de las API de Portal o Graph para asegurarse de que todos los usuarios denegados se eliminaron correctamente.
  7. Si tiene requisitos de separación de tareas, configure los paquetes de acceso no compatibles o los grupos existentes para el paquete de acceso. Si su escenario requiere la capacidad de invalidar una separación de la comprobación de tareas, también puede configurar paquetes de acceso adicionales para esos escenarios de invalidación.
  8. Si desea permitir que los usuarios que aún no tienen acceso soliciten acceso, en cada paquete de acceso, cree directivas de asignación de paquetes de acceso adicionales para que los usuarios soliciten acceso. Configure los requisitos de aprobación y de revisión de acceso periódica en esa directiva.

Pasos siguientes