Gérer des utilisateurs existants d’une application – Microsoft PowerShell

Article
01/03/2024

Il existe trois scénarios courants dans lesquels il est nécessaire de compléter Microsoft Entra ID avec les utilisateurs existants d’une application avant d’utiliser l’application avec une fonctionnalité de Microsoft Entra ID Governance comme les révisions d’accès.

Conditions de licence :

L’utilisation de cette fonctionnalité nécessite des licences Gouvernance Microsoft Entra ID ou Suite Microsoft Entra. Pour trouver la licence adaptée à vos besoins, consultez Notions de base sur les licences Gouvernances des ID Microsoft Entra.

Application migrée vers Microsoft Entra ID après avoir utilisé son propre fournisseur d’identité

Dans le premier scénario, l’application existe déjà dans l’environnement. L’application utilisait précédemment son propre fournisseur d’identité ou son propre magasin de données pour suivre les utilisateurs pouvant y accéder.

Quand vous modifiez l’application pour qu’elle utilise Microsoft Entra ID, seuls les utilisateurs qui se trouvent dans Microsoft Entra ID et qui ont une autorisation d’accès à cette application peuvent y accéder. Dans le cadre de ce changement de configuration, vous pouvez choisir d’importer les utilisateurs existants dans Microsoft Entra ID à partir du magasin de données de cette application. Ces utilisateurs conservent ainsi l’accès par le biais de Microsoft Entra ID.

Le fait que les utilisateurs associés à l’application soient représentés dans Microsoft Entra ID permettra à Microsoft Entra ID de suivre les utilisateurs ayant accès à l’application, même si leur relation avec l’application a une autre origine. Par exemple, la relation peut avoir pour origine la base de données ou l’annuaire d’une application.

Quand Microsoft Entra ID a connaissance de l’attribution d’un utilisateur, il peut envoyer des mises à jour au magasin de données de l’application. Ces mises à jour incluent la date de modification des attributs de cet utilisateur ou la date de sortie de l’utilisateur de l’étendue de l’application.

Application qui n’utilise pas Microsoft Entra ID comme unique fournisseur d’identité

Dans le deuxième scénario, une application n’utilise pas uniquement Microsoft Entra ID comme fournisseur d’identité.

Dans certains cas, une application peut s’appuyer sur des groupes AD. Ce scénario est décrit comme le Modèle B dans Préparer une révision d’accès de l’accès d’un utilisateur à une application. Vous n’avez pas besoin de configurer l’approvisionnement pour cette application comme décrit dans cet article. Suivez plutôt les instructions du modèle B de cet article sur la façon de vérifier l’appartenance aux groupes AD.

Dans d’autres cas, une application peut prendre en charge plusieurs fournisseurs d’identité ou disposer de son propre stockage d’informations d’identification intégré. Ce scénario est décrit comme le Modèle C dans Préparer une révision d’accès de l’accès d’un utilisateur à une application.

Il n’est peut-être pas possible de supprimer les autres fournisseurs d’identité ou l’authentification des informations d’identification locales de l’application. Dans ce cas, si vous voulez utiliser Microsoft Entra ID pour vérifier qui a accès à cette application ou supprimer l’accès d’une personne à cette application, vous devez créer des attributions dans Microsoft Entra ID, représentant les utilisateurs de l’application qui ne dépendent pas de Microsoft Entra ID pour l'authentification.

Ces attributions sont nécessaires si vous envisagez de passer en revue tous les utilisateurs ayant accès à l’application dans le cadre d’une révision d’accès.

Par exemple, supposons qu’un utilisateur figure dans le magasin de données de l’application. Microsoft Entra ID est configuré pour exiger des attributions de rôles à l’application. Toutefois, l’utilisateur n’a pas d’attribution de rôle d’application dans Microsoft Entra ID.

Si l’utilisateur est mis à jour dans Microsoft Entra ID, aucune modification ne sera envoyée à l’application. Et si les attributions de rôles de l’application sont passées en revue, l’utilisateur ne sera pas inclus dans cette révision. Pour que tous les utilisateurs de l’application soient inclus dans la révision, ils doivent tous disposer d’attributions de rôles d’application.

L’application n’utilise pas Microsoft Entra ID comme fournisseur d’identité et ne prend pas en charge l’approvisionnement

Pour certaines applications héritées, il peut ne pas être possible de supprimer d’autres fournisseurs d’identité ou l’authentification par informations d’identification locales de l’application, ou d’activer la prise en charge des protocoles d’approvisionnement pour ces applications.

Ce scénario d’une application qui ne prend pas en charge les protocoles d’approvisionnement est abordé dans un article distinct, Régir les utilisateurs existants d’une application qui ne prend pas en charge l’approvisionnement.

Terminologie

Cet article illustre le processus de gestion des attributions de rôles d’application à l’aide des cmdlets Microsoft Graph PowerShell. Il utilise la terminologie Microsoft Graph suivante.

Diagramme illustrant la terminologie Microsoft Graph.

Dans Microsoft Entra ID, un principal de service (ServicePrincipal) représente une application dans l’annuaire d’une organisation particulière. ServicePrincipal possède une propriété nommée AppRoles qui liste les rôles pris en charge par une application, par exemple Marketing specialist. AppRoleAssignment établit un lien entre un utilisateur et un principal de service et indique le rôle que possède l’utilisateur dans cette application. Une application peut avoir plusieurs principaux de service si l’authentification unique pour l’application et l’approvisionnement de l’application sont gérés séparément.

Vous pouvez aussi utiliser des packages d’accès de gestion des droits d’utilisation Microsoft Entra pour accorder aux utilisateurs un accès limité dans le temps à l’application. Dans la gestion des droits d’utilisation, AccessPackage contient un ou plusieurs rôles de ressource, provenant éventuellement de plusieurs principaux de service. AccessPackage possède également des attributions (Assignment) pour les utilisateurs du package d’accès.

Quand vous créez une attribution pour un utilisateur de package d’accès, la gestion des droits d’utilisation Microsoft Entra crée automatiquement les instances AppRoleAssignment nécessaires à l’utilisateur pour le principal de service de chaque application dans le package d’accès. Pour plus d’informations, consultez le Gérer l’accès aux ressources dans la gestion des droits d’utilisation Microsoft Entra tutoriel pour savoir comment créer des packages d’accès via PowerShell.

Avant de commencer

Vous devez disposer d’une des licences suivantes dans votre locataire :
- Microsoft Entra ID P2 ou gouvernance de Microsoft Entra ID
- Licence Enterprise Mobility + Security E5
Vous devez disposer d’un rôle administrateur approprié. Si vous effectuez ces étapes pour la première fois, vous avez besoin du rôle d’administrateur général pour autoriser l’utilisation de Microsoft Graph PowerShell dans votre locataire.
Votre application a besoin d’au moins un principal de service dans votre locataire :
- Si l’application utilise un annuaire LDAP, suivez le guide de configuration de Microsoft Entra ID pour provisionner des utilisateurs dans des annuaires LDAP dans la section Télécharger, installer et configurer le package de l’agent de provisionnement Microsoft Entra Connect.
- Si l’application utilise une base de données SQL, suivez le guide de configuration de Microsoft Entra ID pour provisionner des utilisateurs dans des applications SQL dans la section Télécharger, installer et configurer le package de l’agent de provisionnement Microsoft Entra Connect.
- Si l’application utilise SAP Cloud Identity Services ou est une application cloud qui prend en charge le protocole SCIM et que l’application n’est pas déjà configurée dans votre locataire ; plus tard dans ce guide, vous inscrirez l’application à partir de la galerie d’applications.
- Si l’application est locale et prend en charge le protocole SCIM, suivez le guide de configuration de Microsoft Entra ID pour provisionner des utilisateurs dans des applications SCIM locales.

Collecter les utilisateurs existants d’une application

Pour vérifier que tous les utilisateurs sont enregistrés dans Microsoft Entra ID, la première étape consiste à collecter la liste des utilisateurs existants qui ont accès à l’application.

Certaines applications peuvent intégrer une commande permettant d’exporter la liste des utilisateurs actifs à partir du magasin de données. Dans d’autres cas, l’application peut avoir recours à un annuaire ou une base de données externe.

Dans certains environnements, l’application peut se trouver sur un système ou un segment réseau qui ne convient pas à la gestion de l’accès à Microsoft Entra ID. Vous aurez alors peut-être besoin d’extraire la liste des utilisateurs de cet annuaire ou cette base de données, puis de la transférer sous forme de fichier vers un autre système pouvant être utilisé pour les interactions Microsoft Entra.

Cette section décrit quatre approches d’obtention d’une liste des utilisateurs dans un fichier de valeurs séparées par des virgules (CSV) :

À partir d’un annuaire LDAP
À partir d’une base de données SQL Server
À partir d’une autre base de données SQL
À partir de SAP Cloud Identity Services

Collecter les utilisateurs existants à partir d’une application qui utilise un annuaire LDAP

Cette section concerne les applications qui utilisent un annuaire LDAP comme magasin de données sous-jacent pour les utilisateurs qui ne s’authentifient pas auprès de Microsoft Entra ID. La plupart des annuaires LDAP, comme Active Directory, comprennent une commande qui génère une liste d’utilisateurs.

Identifiez les utilisateurs de l’annuaire qui se trouvent dans l’étendue des utilisateurs de l’application. Ce choix dépend de la configuration de votre application. Pour certaines applications, tout utilisateur qui existe dans un annuaire LDAP est un utilisateur valide. D’autres applications peuvent exiger de l’utilisateur qu’il possède un attribut particulier ou qu’il soit membre d’un groupe de cet annuaire.
Exécutez la commande qui récupère ce sous-ensemble d’utilisateurs à partir de votre annuaire. Vérifiez que la sortie comprend les attributs d’utilisateurs qui seront utilisés pour la mise en correspondance avec Microsoft Entra ID. par exemple, l’ID d’employé, le nom du compte et l’adresse e-mail.

Par exemple, cette commande produit un fichier CSV dans l’annuaire actuel du système de fichiers avec l’attribut userPrincipalName de chaque personne de l’annuaire LDAPS :
```
$out_filename = ".\users.csv"
csvde -f $out_filename -l userPrincipalName,cn -r "(objectclass=person)"
```
Si nécessaire, transférez le fichier CSV contenant la liste des utilisateurs vers un système avec les cmdlets Microsoft Graph PowerShell installées.
Poursuivez la lecture à la section Vérifier que Microsoft Entra ID a des utilisateurs correspondant à ceux de l’application plus loin dans cet article.

Collecter les utilisateurs existants à partir d’une table de base de données d’application à l’aide d’un Assistant SQL Server

Cette section concerne les applications qui utilisent SQL Server comme magasin de données sous-jacent.

Tout d’abord, obtenez la liste des utilisateurs dans les tables. La plupart des bases de données offrent un moyen d’exporter le contenu des tables dans un format de fichier standard, tel qu’un fichier CSV. Si l’application utilise une base de données SQL Server, vous pouvez utiliser l’Assistant Importation et exportation SQL Server pour exporter des parties d’une base de données. Si vous n’avez pas d’utilitaire pour votre base de données, vous pouvez utiliser le pilote ODBC avec PowerShell comme décrit dans la section suivante.

Connectez-vous au système sur lequel SQL Server est installé.
Ouvrez Importation et exportation SQL Server 2019 (64 bits) ou l’équivalent pour votre base de données.
Sélectionnez la base de données existante comme source.
Sélectionnez Destination de fichier plat comme destination. Indiquez un nom de fichier et faites passer la valeur Page de codes à 65001 (UTF-8).
Terminez l’Assistant, puis sélectionnez l’option d’exécution immédiate.
Attendez que l’exécution se termine.
Si nécessaire, transférez le fichier CSV contenant la liste des utilisateurs vers un système avec les cmdlets Microsoft Graph PowerShell installées.
Poursuivez la lecture à la section Vérifier que Microsoft Entra ID a des utilisateurs correspondant à ceux de l’application plus loin dans cet article.

Collecter les utilisateurs existants à partir d’une table de base de données d’application à l’aide de PowerShell

Cette section concerne les applications qui utilisent une autre base de données SQL comme magasin de données sous-jacent, dans le cas où vous utilisez l’hôte connecteur ECMA pour provisionner les utilisateurs dans cette application. Si vous n’avez pas encore configuré l’agent de provisionnement, utilisez ce guide pour créer le fichier de connexion DSN que vous utiliserez dans cette section.

Connectez-vous au système sur lequel l’agent de provisionnement est ou doit être installé.
Ouvrez PowerShell.
Construisez une chaîne de connexion pour vous connecter à votre système de base de données.

Les composants d’une chaîne de connexion dépendent des exigences de votre base de données. Si vous utilisez SQL Server, consultez la liste des mots clés et des attributs de chaîne de connexion et de nom de source de données (DSN).

Si vous utilisez une base de données différente, vous devez inclure les mots clés obligatoires permettant de se connecter à cette base de données. Par exemple, si votre base de données utilise le nom de chemin complet du fichier DSN, un ID utilisateur et un mot de passe, construisez la chaîne de connexion à l’aide des commandes suivantes :
```
$filedsn = "c:\users\administrator\documents\db.dsn"
$db_cs = "filedsn=" + $filedsn + ";uid=p;pwd=secret"
```
Ouvrez une connexion à votre base de données et fournissez la chaîne de connexion à l’aide des commandes suivantes :
```
$db_conn = New-Object data.odbc.OdbcConnection
$db_conn.ConnectionString = $db_cs
$db_conn.Open()
```
Construisez une requête SQL pour récupérer les utilisateurs dans la table de base de données. Veillez à inclure les colonnes qui serviront à mettre en correspondance les utilisateurs de la base de données de l’application avec les utilisateurs dans Microsoft Entra ID. par exemple, l’ID d’employé, le nom de compte ou l’adresse e-mail.

Par exemple, si vos utilisateurs sont stockés dans une table de base de données nommée USERS et contenant les colonnes name et email, entrez la commande suivante :
```
$db_query = "SELECT name,email from USERS"
```
Envoyez la requête à la base de données avec la connexion :
```
$result = (new-object data.odbc.OdbcCommand($db_query,$db_conn)).ExecuteReader()
$table = new-object System.Data.DataTable
$table.Load($result)
```
Le résultat est la liste des lignes, représentant les utilisateurs qui ont été récupérés à partir de la requête.

Écrivez le résultat dans un fichier CSV :

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

Si les cmdlets Microsoft Graph PowerShell ne sont pas installées sur ce système ou si celui-ci n’est pas connecté à Microsoft Entra ID, transférez le fichier CSV contenant la liste des utilisateurs vers un système sur lequel les cmdlets Microsoft Graph PowerShell sont installées.

Collecter des utilisateurs existants à partir de SAP Cloud Identity Services

Cette section s’applique aux applications SAP qui utilisent SAP Cloud Identity Services comme service sous-jacent pour l’approvisionnement d’utilisateurs.

Connectez-vous à votre console d’administration de SAP Cloud Identity Services, https://<tenantID>.accounts.ondemand.com/admin ou https://<tenantID>.trial-accounts.ondemand.com/admin en cas d’essai gratuit.
Accédez à Utilisateurs et autorisations > Exporter des utilisateurs.
Sélectionnez tous les attributs requis pour la mise en correspondance des utilisateurs Microsoft Entra avec ceux de SAP. Cela inclut les attributs SCIM ID, userName et emails d’autres attributs que vous utilisez peut-être dans vos Systèmes SAP.
Sélectionnez Exporter et attendre que le navigateur télécharge le fichier CSV.
Si les cmdlets Microsoft Graph PowerShell ne sont pas installées sur ce système ou si celui-ci n’est pas connecté à Microsoft Entra ID, transférez le fichier CSV contenant la liste des utilisateurs vers un système sur lequel les cmdlets Microsoft Graph PowerShell sont installées.

Vérifier que Microsoft Entra ID a des utilisateurs correspondant à ceux de l’application

Maintenant que vous avez obtenu la liste de tous les utilisateurs de l’application, vous devez mettre en correspondance ces utilisateurs du magasin de données de l’application avec les utilisateurs de Microsoft Entra ID.

Avant de continuer, consultez les informations sur la correspondance des utilisateurs dans les systèmes source et cible. Vous configurerez le provisionnement Microsoft Entra avec des mappages équivalents par la suite. Cette étape permettra au provisionnement Microsoft Entra d’interroger le magasin de données de l’application avec les mêmes règles de correspondance.

Récupérer les ID des utilisateurs dans Microsoft Entra ID

Cette section montre comment interagir avec Microsoft Entra ID à l’aide de cmdlets Microsoft Graph PowerShell.

La première fois que votre organisation utilise ces cmdlets pour ce scénario, vous devez avoir un rôle d’administrateur général pour autoriser l’utilisation de Microsoft Graph PowerShell dans votre locataire. Les interactions suivantes peuvent utiliser un rôle avec des privilèges inférieurs, par exemple :

Administrateur d’utilisateurs si vous prévoyez de créer des utilisateurs
Administrateur d’application ou Administrateur de gouvernance des identités si vous gérez simplement des attributions de rôles d’application

Ouvrez PowerShell.
Si les modules Microsoft Graph PowerShell ne sont pas déjà installés, installez le module Microsoft.Graph.Users et les autres à l’aide de cette commande :
```
Install-Module Microsoft.Graph
```
Si les modules sont déjà installés, vérifiez que vous utilisez une version récente :
```
Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications
```

Connectez-vous à Microsoft Entra ID :

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

Si c’est la première fois que vous utilisez cette commande, vous devrez peut-être consentir à ce que les outils en ligne de commande Microsoft Graph disposent de ces autorisations.
Lisez la liste des utilisateurs obtenue à partir du magasin de données de l’application dans la session PowerShell. Si la liste des utilisateurs était stockée dans un fichier CSV, vous pouvez utiliser la cmdlet PowerShell Import-Csv et fournir le nom du fichier de la section précédente comme argument.

Par exemple, si le fichier obtenu depuis SAP Cloud Identity Services se nomme Users-exported-from-sap.csv et se trouve dans le répertoire actif, entrez cette commande.
```
$filename = ".\Users-exported-from-sap.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8
```
Dans le cas où vous utilisez une base de données ou un répertoire, si le fichier est nommé users.csv et se trouve dans le répertoire actif, entrez cette commande :
```
$filename = ".\users.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8
```
Choisissez la colonne du fichier users.csv qui correspond à un attribut d’un utilisateur dans Microsoft Entra ID.

Si vous utilisez SAP Cloud Identity Services, l’attribut SAP SCIM userName et l’attribut Microsoft Entra ID userPrincipalName sont mappés par défaut :
```
$db_match_column_name = "userName"
$azuread_match_attr_name = "userPrincipalName"
```
Dans le cas où vous utilisez une base de données ou un répertoire, vous pouvez avoir dans la base de données des utilisateurs dont la valeur dans la colonne nommée EMail est identique à celle contenue dans l’attribut Microsoft Entra userPrincipalName :
```
$db_match_column_name = "EMail"
$azuread_match_attr_name = "userPrincipalName"
```

Récupérez les ID de ces utilisateurs dans Microsoft Entra ID.

Le script PowerShell suivant utilise les valeurs $dbusers, $db_match_column_nameet $azuread_match_attr_name spécifiées précédemment. Le système interroge Microsoft Entra ID pour localiser un utilisateur ayant un attribut avec une valeur correspondante pour chaque enregistrement du fichier source. Si de nombreux utilisateurs existent dans le fichier obtenu depuis la source SAP Cloud Identity Services, la base de données ou le répertoire, ce script peut prendre plusieurs minutes. Si aucun attribut dans Microsoft Entra ID n’a cette valeur et que vous devez utiliser une expression contains ou une autre expression de filtre, vous devez personnaliser ce script et celui de l’étape 11 plus bas.

$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 }
}

Examinez les résultats des requêtes précédentes. Vérifiez si l’un des utilisateurs de SAP Cloud Identity Services, de la base de données ou du répertoire n’a pas pu être localisé dans Microsoft Entra ID en raison d’erreurs ou de correspondances manquantes.

Le script PowerShell suivant affiche le nombre d’enregistrements qui n’ont pas été localisés :

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

Quand le script est terminé, il indique une erreur si des enregistrements de la source de données n’ont pas été localisés dans Microsoft Entra ID. Si certains enregistrements d’utilisateurs du magasin de données de l’application n’ont pas pu être localisés comme utilisateurs dans Microsoft Entra ID, vous devez investiguer les enregistrements qui n’ont pas eu de correspondance et pourquoi.

Par exemple, l’adresse e-mail et le userPrincipalName d’une personne ont sans doute été modifiés dans Microsoft Entra ID sans que sa propriété mail correspondante ait été mise à jour dans la source de données de l’application. Ou encore, l’utilisateur peut avoir déjà quitté l’organisation et figurer encore dans la source de données de l’application. Autre possibilité : la source de données de l’application contient un compte fournisseur ou de super administrateur qui ne correspond à aucune personne précise dans Microsoft Entra ID.
Si certains utilisateurs n’ont pas pu être localisés dans Microsoft Entra ID ou n’étaient pas actifs et en mesure de se connecter, mais que vous souhaitez que leur accès soit révisé ou que leurs attributs soient mis à jour dans SAP Cloud Identity Services, la base de données ou le répertoire, vous devez mettre à jour l’application, la règle de correspondance, ou mettre à jour ou créer des utilisateurs Microsoft Entra pour eux. Pour plus d’informations sur les modifications à apporter, consultez Gérer les mappages et les comptes d’utilisateur dans les applications qui ne correspondent pas à des utilisateurs dans Microsoft Entra ID.

Si vous choisissez de créer des utilisateurs dans Microsoft Entra ID, vous pouvez le faire en bloc en utilisant l’une des options suivantes :
- Fichier CSV comme décrit dans Créer des utilisateurs en bloc dans le centre d’administration Microsoft Entra
- Avec la cmdlet New-MgUser
Veillez à ce que ces nouveaux utilisateurs soient renseignés avec les attributs nécessaires à Microsoft Entra ID pour les mettre en correspondance par la suite avec les utilisateurs existants de l’application et avec les attributs nécessaires à Microsoft Entra ID, y compris userPrincipalName, mailNickname et displayName. Le userPrincipalName doit être unique parmi tous les utilisateurs de l’annuaire.

Par exemple, vous pouvez avoir des utilisateurs dans la base de données où la valeur dans la colonne nommée EMail est celle que vous voulez utiliser comme nom d’utilisateur principal Microsoft Entra, où la valeur dans la colonne Alias contient le pseudonyme de messagerie Microsoft Entra ID et où la valeur dans la colonne Full name contient le nom complet de l’utilisateur :
```
$db_display_name_column_name = "Full name"
$db_user_principal_name_column_name = "Email"
$db_mail_nickname_column_name = "Alias"
```
Vous pouvez ensuite utiliser ce script pour créer des utilisateurs Microsoft Entra pour ceux présents dans SAP Cloud Identity Services, la base de données ou le répertoire et qui ne correspondaient pas à des utilisateurs dans Microsoft Entra ID. Notez qu’il peut être nécessaire de modifier ce script pour ajouter des attributs Microsoft Entra supplémentaires nécessaires dans votre organisation, ou si le $azuread_match_attr_name n’est ni mailNickname ni userPrincipalName, pour fournir cet attribut 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
   }
}
```

Après avoir ajouté les éventuels utilisateurs manquants à Microsoft Entra ID, réexécutez le script de l’étape 7. Exécutez ensuite le script de l’étape 8. Vérifiez qu’aucune erreur n’est signalée.

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

Enregistrement de l’application

Si l’application est déjà inscrite dans Microsoft Entra ID, passez à l’étape suivante.

Si l’application utilise un annuaire LDAP, suivez le guide de configuration de Microsoft Entra ID pour provisionner des utilisateurs dans des annuaires LDAP afin de créer une inscription pour une application ECMA locale dans Microsoft Entra ID.
Si l’application utilise une base de données SQL, suivez le guide de configuration de Microsoft Entra ID afin de provisionner des utilisateurs dans des applications SQL afin de créer une inscription pour une application ECMA locale dans Microsoft Entra ID.
Si vous utilisez SAP Cloud Identity Services, suivez le guide de configuration de Microsoft Entra ID pour approvisionner des utilisateurs dans SAP Cloud Identity Services.
Si c’est une application cloud qui prend en charge le protocole SCIM, vous pouvez ajouter l’application à partir de la galerie d’applications.
Si l’application est locale et prend en charge le protocole SCIM, suivez le guide de configuration de Microsoft Entra ID pour provisionner des utilisateurs dans des applications SCIM locales.

Rechercher les utilisateurs qui ne sont pas déjà affectés à l’application

Les étapes précédentes ont permis de vérifier que tous les utilisateurs du magasin de données de l’application existaient en tant qu’utilisateurs dans Microsoft Entra ID. Cependant, il se peut que certains d’entre eux ne soient pas actuellement attribués aux rôles de l’application dans Microsoft Entra ID. Les étapes suivantes visent donc à identifier les utilisateurs qui ne sont pas affectés aux rôles d’application.

Recherchez l’ID de principal de service pour le principal de service de l’application. Si vous avez récemment créé un principal de service pour une application qui utilise un annuaire LDAP ou une base de données SQL, utilisez le nom de ce principal de service.

Par exemple, si l’application d’entreprise s’appelle CORPDB1, entrez les commandes suivantes :
```
$azuread_app_name = "CORPDB1"
$azuread_sp_filter = "displayName eq '" + ($azuread_app_name -replace "'","''") + "'"
$azuread_sp = Get-MgServicePrincipal -Filter $azuread_sp_filter -All
```
Récupérez les utilisateurs qui sont actuellement affectés à l’application dans Microsoft Entra ID.

Cela s’appuie sur l’ensemble de variables $azuread_sp de la commande précédente.
```
$azuread_existing_assignments = @(Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $azuread_sp.Id -All)
```
Comparez la liste des ID utilisateur de la section précédente aux utilisateurs actuellement attribués à l’application :
```
$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 aucun utilisateur n’est dépourvu d’une attribution de rôle d’application, ce qui indique que tous les utilisateurs sont attribués à des rôles d’application, vous n’avez pas besoin d’apporter d’autres modifications avant la révision d’accès.

En revanche, si un ou plusieurs utilisateurs sont dépourvus d’une attribution de rôle d’application, vous devez poursuivre la procédure et les ajouter à l’un des rôles de l’application.
Sélectionnez le rôle de l’application à affecter aux utilisateurs restants.

Une application peut avoir plusieurs rôles et un principal de service peut avoir des rôles supplémentaires. Utilisez cette commande pour répertorier les rôles disponibles d’un principal de service :
```
$azuread_sp.AppRoles | where-object {$_.AllowedMemberTypes -contains "User"} | ft DisplayName,Id
```
Sélectionnez le rôle approprié dans la liste et obtenez son ID de rôle. Par exemple, si le nom du rôle est Admin, indiquez cette valeur dans les commandes PowerShell suivantes :
```
$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"}
```

Configurer le provisionnement de l’application

Si votre application utilise un annuaire LDAP, une base de données SQL, SAP Cloud Identity Services ou prend en charge SCIM, avant de créer de nouvelles affectations, configurez l’approvisionnement des utilisateurs Microsoft Entra dans l’application. La configuration du provisionnement avant de créer des affectations permettra à Microsoft Entra ID de mettre en correspondance les utilisateurs dans Microsoft Entra ID dotés des attributions de rôles d’application avec les utilisateurs déjà présents dans le magasin de données de l’application. Si votre application dispose d’une base de données ou d’un répertoire local à approvisionner et prend également en charge l’authentification unique fédérée, vous devrez peut-être avoir besoin de deux principaux de service pour représenter l’application dans votre répertoire : l’un pour l’approvisionnement et l’autre pour l’authentification unique. Si votre application ne prend pas en charge l’approvisionnement, poursuivez la lecture dans la section suivante.

Vérifiez que l’application est configurée pour exiger des utilisateurs qu’ils disposent d’attributions de rôle d’application. Ainsi, seuls les utilisateurs sélectionnés seront provisionnés dans l’application.
Si le provisionnement n’a pas été configuré pour l’application, configurez-le maintenant (mais ne commencez pas le provisionnement) :
- Si l’application utilise un annuaire LDAP, suivez le guide de configuration de Microsoft Entra ID pour provisionner des utilisateurs dans des annuaires LDAP.
- Si l’application utilise une base de données SQL, suivez le guide de configuration de Microsoft Entra ID pour provisionner des utilisateurs dans des applications SQL.
- Si l’application utilise SAP Cloud Identity Services, suivez le guide de configuration de Microsoft Entra ID pour approvisionner des utilisateurs dans SAP Cloud Identity Services.
- Pour les autres applications, suivez les étapes 1-3 pour configurer l’approvisionnement via les API Graph.
Cliquez sur l'onglet Propriétés de l’application. Vérifiez que l’option Affectation d’utilisateurs requise ? est définie sur Oui. Si elle est définie sur Non, tous les utilisateurs de votre répertoire, y compris les identités externes, peuvent accéder à l’application et vous ne pouvez pas réviser l’accès à l’application.
Vérifiez les mappages d’attributs pour le provisionnement de cette application. Vérifiez que les objets Match utilisant cet attribut sont définis pour l’attribut et la colonne Microsoft Entra que vous avez utilisés dans les sections précédentes pour la mise en correspondance.

Si ces règles n’utilisent pas les attributs que vous avez utilisés précédemment, au moment de créer les attributions de rôles d’application, Microsoft Entra ID ne pourra peut-être pas localiser les utilisateurs existants dans le magasin de données de l’application. Microsoft Entra ID peut alors créer accidentellement des utilisateurs en double.
Vérifiez qu’il existe un mappage d’attribut pour isSoftDeleted à un attribut de l’application.

Quand un utilisateur fait l’objet d’une annulation d’attribution dans l’application, qu’il est supprimé de manière réversible dans Microsoft Entra ID ou qu’il est empêché de se connecter, le provisionnement Microsoft Entra met à jour l’attribut mappé à isSoftDeleted. Si aucun attribut n’est mappé, les utilisateurs qui font par la suite l’objet d’une annulation d’attribution de rôle de l’application continuent d’exister dans le magasin de données de l’application.
Si le provisionnement a déjà été activé pour l’application, vérifiez que le provisionnement de l’application n’est pas en quarantaine. Résolvez les problèmes éventuels provoquant la mise en quarantaine avant de continuer.

Créer des attributions de rôles d’application dans Microsoft Entra ID

Pour permettre à Microsoft Entra ID de mettre en correspondance les utilisateurs de l’application avec ceux de Microsoft Entra ID, vous devez créer des attributions de rôle d’application dans Microsoft Entra ID. Chaque attribution de rôle d’application associe un utilisateur à un rôle d’application d’un principal de service.

Quand une attribution de rôle d’application est créée dans Microsoft Entra ID pour un utilisateur d’une application, et que l’application prend en charge l’approvisionnement, alors :

Microsoft Entra ID interroge l’application via SCIM, ou son répertoire ou sa base de données, pour déterminer si l’utilisateur existe déjà.
Lorsque des mises à jour ultérieures sont apportées aux attributs de l’utilisateur dans Microsoft Entra ID, le service envoie ces mises à jour à l’application.
L’utilisateur reste indéfiniment dans l’application, à moins qu’il fasse l’objet d’une mise à jour en dehors de Microsoft Entra ID ou que son attribution soit supprimée de Microsoft Entra ID.
À la prochaine révision d’accès des attributions de rôles de cette application, l’utilisateur sera inclus dans la révision d’accès.
Si l’utilisateur est refusé dans le cadre d’une révision d’accès, son attribution de rôle d’application est supprimée. Microsoft Entra ID indique à l’application que la connexion de l’utilisateur est bloquée.

Si l’application ne prend pas en charge l’approvisionnement, alors

L’utilisateur reste indéfiniment dans l’application, à moins qu’il fasse l’objet d’une mise à jour en dehors de Microsoft Entra ID ou que son attribution soit supprimée de Microsoft Entra ID.
À la prochaine révision des attributions de rôles de cette application, l’utilisateur sera inclus dans la révision.
Si l’utilisateur est refusé dans le cadre d’une révision d’accès, son attribution de rôle d’application est supprimée. L’utilisateur ne pourra plus se connecter à l’application à partir de Microsoft Entra ID.

Créez des attributions de rôle d’application pour les utilisateurs qui n’ont pas actuellement d’attributions de rôle :

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 
}

Patientez une minute, le temps que les modifications se propagent dans Microsoft Entra ID.

Vérifier que le provisionnement Microsoft Entra a mis en correspondance les utilisateurs existants

Interrogez Microsoft Entra ID pour obtenir la liste mise à jour des attributions de rôle :

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

Comparez la liste des ID utilisateur de la section précédente aux utilisateurs maintenant attribués à l’application :

$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 certains utilisateurs n’ont pas d’attribution de rôle d’application, vérifiez s’il existe dans le journal d’audit Microsoft Entra une erreur liée à une étape précédente.

Si le principal du service d’application est configuré pour l’approvisionnement et que l’État d’approvisionnement du principal de service est Désactivé, activez-le. Vous pouvez également démarrer l’approvisionnement à l’aide des API Graph.
Sur la base des indications concernant la durée de provisionnement des utilisateurs, attendez que le provisionnement Microsoft Entra mette en correspondance les utilisateurs existants de l’application avec ceux qui viennent d’être affectés.
Surveillez l’état d’approvisionnement via les API Portail ou Graph pour vous assurer que tous les utilisateurs ont été mis en correspondance avec succès.

Si vous constatez que les utilisateurs ne sont pas provisionnés, consultez le guide de résolution du problème Aucun utilisateur n’est provisionné. Si vous voyez une erreur dans l’état du provisionnement et que le provisionnement porte sur une application locale, consultez le guide de résolution du problème de provisionnement d’application locale.
Consultez le journal de provisionnement via le centre d’administration Microsoft Entra ou les API Graph. Filtrez le journal sur l’état Échec. Les échecs avec le code d’erreur (ErrorCode) DuplicateTargetEntries indiquent une ambiguïté dans vos règles de correspondance de provisionnement. Vous devez alors mettre à jour les utilisateurs Microsoft Entra ou les mappages utilisés pour la correspondance afin de garantir que chaque utilisateur Microsoft Entra correspond à un utilisateur de l’application. Filtrez ensuite le journal sur l’action Créer et l’état Ignoré. Si des utilisateurs ont été ignorés avec le code SkipReason NotEffectivelyEntitled, cela peut indiquer que les comptes d’utilisateur dans Microsoft Entra ID n’ont pas été mis en correspondance, car l’état du compte d’utilisateur était Désactivé.

Quand le service de provisionnement Microsoft Entra a mis en correspondance les utilisateurs selon les attributions de rôle d’application que vous avez créées, les modifications ultérieures à ces utilisateurs seront envoyées à l’application.

Sélectionner les réviseurs appropriés

Lors de la création d’une révision d’accès, les administrateurs peuvent choisir un ou plusieurs réviseurs. Tous les réviseurs peuvent démarrer et effectuer une révision, en choisissant des utilisateurs pour un accès continu à une ressource ou en les supprimant.

En règle générale, le propriétaire de la ressource est responsable de l’exécution d’une révision. Si vous créez une révision d’un groupe, dans le cadre de la révision de l’accès à une application intégrée au modèle B, vous pouvez sélectionner les propriétaires de groupe en tant que réviseurs. Les applications dans Microsoft Entra ID n'ont pas nécessairement de propriétaire. Par conséquent, vous ne pouvez pas sélectionner propriétaire de l’application en tant que réviseur. Au lieu de cela, lors de la création de la révision, vous pouvez fournir les noms des propriétaires d’application pour qu’ils soient les réviseurs.

Vous pouvez également choisir lors de la création d’une révision d’un groupe ou d’une application d’avoir une révision en plusieurs étapes. Par exemple, vous pouvez choisir de faire en sorte que le responsable de chaque utilisateur affecté effectue la première étape de la révision et le propriétaire de la ressource la deuxième étape. Ainsi, le propriétaire de la ressource peut se concentrer sur les utilisateurs qui ont déjà été approuvés par leur responsable.

Avant de créer les révisions, vérifiez que vous disposez de suffisamment de sièges Microsoft Entra ID P2 ou Microsoft Entra ID Governance SKU dans votre locataire. Vérifiez également que tous les réviseurs sont des utilisateurs actifs avec des adresses e-mail. Lorsque les révisions d’accès démarrent, elles passent chacune en revue un e-mail tiré de Microsoft Entra ID. Si le réviseur n’a pas de boîte aux lettres, il ne reçoit pas l’e-mail au démarrage de la révision ou ni le rappel par e-mail. En outre, si le réviseur ne peut pas se connecter à Microsoft Entra ID, il ne pourra pas effectuer l’évaluation.

Configurer les révisions d’accès ou la gestion des droits d’utilisation

Une fois que les utilisateurs sont dans les rôles d’application et que vous avez identifié les réviseurs, vous pouvez régir ces utilisateurs et tous les utilisateurs supplémentaires qui auront besoin d’un accès en vous servant de la révision d’accès ou de la gestion des droits d'utilisation.

Si l’application n’a qu’un seul rôle d’application, qu’elle est représentée par un seul principal de service dans votre annuaire et qu’aucun utilisateur supplémentaire n’a besoin d’accéder à l’application, passez à la section suivante pour réviser et supprimer l’accès existant au moyen d’une révision d’accès.
Sinon, poursuivez dans la section de cet article pour régir l’accès à l’aide de la gestion des droits d’utilisation.

Vérifier et supprimer l’accès existant au moyen d’une révision d’accès des attributions de rôles d’application

Si l’application a plusieurs rôles d’application, est représentée par plusieurs principaux de service, ou si vous souhaitez que les utilisateurs demandent ou reçoivent l’accès à l’application, continuez à la section suivante de cet article pour régir l’accès à l’aide de la gestion des droits d’utilisation.

Maintenant que les utilisateurs existants ont des attributions à un rôle d’application, vous pouvez configurer Microsoft Entra ID pour démarrer une révision de ces affectations.

Pour cette étape, vous devez disposer du rôle Administrateur général ou Administrateur de la gouvernance des identités.
Suivez les instructions du guide pour créer une révision d’accès de groupes ou d’applications pour créer la révision des attributions de rôles de l’application. Configurez la révision pour appliquer les résultats une fois qu’elle se termine. Vous pouvez créer la révision d’accès dans PowerShell avec le cmdlet New-MgIdentityGovernanceAccessReviewDefinition issu des cmdlets Microsoft Graph PowerShell pour le module de gouvernance des identités. Pour plus d’informations, voir les exemples.

Remarque

Si vous activez l’assistance décisionnaire lors de la création de la révision d’accès, les recommandations de l’assistance à la décision sont basées sur la période d’intervalle de 30 jours en fonction du moment où l’utilisateur s’est connecté pour la dernière fois à l’application via Microsoft Entra ID.
Lorsque la révision d’accès démarre, demandez aux réviseurs de donner leur avis. Par défaut, ils reçoivent chacun un e-mail de Microsoft Entra ID avec un lien vers le panneau d’accès, où ils examinent l’accès à l’application.
Une fois les révisions démarrées, vous pouvez surveiller leur progression et mettre à jour les approbateurs si nécessaire, jusqu’à ce que la révision d’accès soit terminée. Vous pouvez ensuite confirmer que les utilisateurs, dont l’accès a été refusé par les réviseurs, ont vu leur accès supprimé de l’application.
Si l’application automatique n’a pas été sélectionnée lors de la création de la révision, vous devez appliquer les résultats de la révision une fois qu’elle est terminée.
Attendez que l’état de la révision passe à Résultat appliqué. Les utilisateurs à qui l’accès a été refusé, s’il y en a, verront leurs attributions de rôles d'application supprimées dans quelques minutes.
Une fois les résultats appliqués, Microsoft Entra ID commence à déprovisionner les utilisateurs refusés de l’application. En fonction des instructions relatives à la durée nécessaire à l’approvisionnement des utilisateurs, attendez que le provisionnement de Microsoft Entra commence à déprovisionner les utilisateurs refusés. Surveillez l’état d’approvisionnement via le Portail ou les API Graph pour vous assurer que tous les utilisateurs refusés ont été supprimés avec succès.

Si vous constatez que les utilisateurs ne sont pas provisionnés, consultez le guide de dépannage pour les utilisateurs non provisionnés. Si vous voyez une erreur dans l’état du provisionnement et que le provisionnement porte sur une application locale, consultez le guide de résolution du problème de provisionnement d’application locale.

Maintenant que vous disposez d’une base de référence qui garantit que l’accès existant a été examiné, vous pouvez continuer dans la section suivante pour configurer la gestion des droits d’utilisation afin d’activer les nouvelles demandes d’accès.

Régir l’accès via la gestion des droits d’utilisation

Dans d’autres situations, par exemple si vous souhaitez avoir des réviseurs différents pour chaque rôle d’application, l’application est représentée par plusieurs principaux de service, ou si vous souhaitez avoir un processus pour que les utilisateurs demandent ou se voient attribuer l’accès à l’application, vous pouvez configurer Microsoft Entra ID avec un package d’accès pour chaque rôle d’application. Chaque package d’accès peut avoir une stratégie pour la révision périodique des affectations effectuées à ce package d’accès. Une fois les packages d’accès et les stratégies créés, vous pouvez affecter les utilisateurs qui ont des attributions de rôle d’application existantes aux packages d’accès, afin que leurs affectations puissent être examinées via le package d'accès.

Dans cette section, vous allez configurer la gestion des droits d’utilisation De Microsoft Entra pour examiner les attributions de package d’accès qui contiennent les attributions de rôles d’application, et configurer des stratégies supplémentaires afin que les utilisateurs puissent demander l’accès aux rôles de votre application.

Pour cette étape, vous devez disposer du rôle Administrateur général ou Administrateur de la gouvernance des identités ou être délégué en tant que créateur de catalogue et propriétaire de l’application.
Si vous n’avez pas encore de catalogue pour votre scénario de gouvernance des applications, créez un catalogue dans la gestion des droits d’utilisation Microsoft Entra. Vous pouvez utiliser un script PowerShell pour créer chaque catalogue.
Remplissez le catalogue avec les ressources nécessaires, en ajoutant l’application, ainsi que tous les groupes Microsoft Entra sur lesquels l’application s’appuie, en tant que ressources dans ce catalogue. Vous pouvez utiliser un script PowerShell pour ajouter chaque ressource à un catalogue.
Pour chacune des applications et pour chacun des rôles ou groupes des applications, créez un package d’accès qui inclut ce rôle ou ce groupe comme ressource. À ce stade de la configuration de ces packages d’accès, configurez la première stratégie d’attribution de package d’accès dans chaque package d’accès comme étant une attribution directe, afin que seuls les administrateurs puissent créer des affectations de cette stratégie, définir les exigences de révision d’accès pour les utilisateurs existants, le cas échéant, afin qu’ils ne conservent pas l’accès indéfiniment. Si vous disposez de beaucoup de packages d’accès, vous pouvez utiliser un script PowerShell pour créer chaque package d’accès dans un catalogue.
Pour chaque package d’accès, affectez les utilisateurs existants de l’application ayant ce rôle, ou les membres de ce groupe, au package d’accès et à ses stratégies d’attribution directe. Vous pouvez affecter directement un utilisateur à un package d’accès à l’aide du centre d’administration Microsoft Entra ou en bloc via Graph ou PowerShell.
Si vous avez configuré des révisions d’accès dans les stratégies d’attribution de package d’accès, lorsque la révision d’accès démarre, demandez aux réviseurs d’entrer. Par défaut, ils reçoivent chacun un e-mail de Microsoft Entra ID avec un lien vers le volet d’accès, où ils examineront les attributions des packages d'accès. Une fois la révision terminée, vous devriez vous attendre à voir les utilisateurs refusés, le cas échéant, voir leurs attributions de rôles d’application supprimées en quelques minutes. Par la suite, Microsoft Entra ID commence à déprovisionner les utilisateurs refusés de l’application. En fonction des instructions relatives à la durée nécessaire à l’approvisionnement des utilisateurs, attendez que le provisionnement de Microsoft Entra commence à déprovisionner les utilisateurs refusés. Surveillez l’état d’approvisionnement via le Portail ou les API Graph pour vous assurer que tous les utilisateurs refusés ont été supprimés avec succès.
Si vous avez des exigences de séparation des tâches, configurez les packages d’accès incompatibles ou les groupes existants pour votre package d’accès. Si votre scénario exige la capacité à substituer une vérification de séparation des tâches, vous pouvez également configurer des packages d’accès supplémentaires pour ces scénarios de substitution.
Si vous souhaitez autoriser les utilisateurs qui n’ont pas déjà accès à demander l’accès, dans chaque package d’accès, créez des stratégies d’attribution de package d’accès supplémentaires pour permettre aux utilisateurs de demander l’accès. Configurez les exigences d’approbation et de révision d’accès périodique dans cette stratégie.

Partager via