Gouverner les utilisateurs d’une application qui ne prend pas en charge l’approvisionnement - Microsoft PowerShell

Article
10/25/2023

Il existe trois scénarios courants dans lesquels il est nécessaire de remplir 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.

Application migrée vers Microsoft Entra ID après avoir utilisé son propre fournisseur d’identité
Application qui n’utilise pas Microsoft Entra ID comme unique fournisseur d’identité
L’application n’utilise pas Microsoft Entra ID comme fournisseur d’identité et ne prend pas en charge l’approvisionnement

Pour plus d’informations sur les deux premiers scénarios, où l’application prend en charge l’approvisionnement ou utilise un annuaire LDAP, une base de données SQL, une API SOAP ou REST, ou s’appuie sur Microsoft Entra ID comme fournisseur d’identité, consultez l’article Régir les utilisateurs existants d’une application. Cet article explique comment utiliser les fonctionnalités de gouvernance des identités pour les utilisateurs existants de ces catégories d’applications

Cet article aborde le troisième scénario. 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 Pour ces applications, 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 Cet article traite du scénario d’une application qui n’utilise pas Microsoft Entra ID comme fournisseur d’identité et ne prend pas en charge l’approvisionnement.

Conditions de licence

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

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.

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 chaque application. Pour plus d’informations, consultez le tutoriel Gérer l’accès aux ressources dans la gestion des droits d’utilisation Microsoft Entra 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’un principal de service dans votre locataire. Si un principal de service n’existe pas encore, vous pouvez inscrire une application pour la représenter dans Microsoft Entra ID.

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 cette application, 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.

Si votre application dispose d’un annuaire LDAP ou d’une base de données SQL, consultez Collecter des utilisateurs existants à partir d’une application pour obtenir des recommandations sur la façon d’extraire la collection d’utilisateurs.

Sinon, si l’application n’a pas de répertoire ou de base de données, vous devez contacter le propriétaire de l’application et lui faire fournir une liste d’utilisateurs. Il peut s’agir d’un format comme un fichier CSV, avec une ligne par utilisateur. Assurez-vous qu’un champ de chaque utilisateur dans le fichier contient un identificateur unique, comme une adresse e-mail, qui est également présent sur les utilisateurs dans Microsoft Entra ID.

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.

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.

Le compte que vous utilisez doit avoir l’autorisation de gérer les applications dans Microsoft Entra ID. Les rôles Microsoft Entra suivants incluent les autorisations nécessaires :

Créez l’application et le principal de service.

Par exemple, si l’application d’entreprise s’appelle CORPDB1, entrez les commandes suivantes :

$azuread_app_name = "CORPDB1"
$azuread_app = New-MgApplication -DisplayName $azuread_app_name
$azuread_sp = New-MgServicePrincipal -DisplayName $azuread_app_name -AppId $azuread_app.AppId

Ajoutez un rôle à l’application et étiquetez l’application comme intégrée à Microsoft Entra ID afin que ses affectations puissent être examinées. Par exemple, si le nom du rôle est General, indiquez cette valeur dans les commandes PowerShell suivantes :

$ar0 = New-Object Microsoft.Graph.PowerShell.Models.MicrosoftGraphAppRole
$ar0.AllowedMemberTypes += "User"
$ar0.Description = "General role"
$ar0.DisplayName = "General"
$ar0.id = New-Guid
$ar0.IsEnabled = $true
$ar0.Value = "General"
$ara = @()
$ara += $ar0

$azuread_app_tags = @()
$azuread_app_tags += "WindowsAzureActiveDirectoryIntegratedApp"

$azuread_app_update = Update-MgApplication -ApplicationId $azuread_app.Id -AppRoles $ara -Tags $azuread_app_tags

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.

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. Utilisez cette commande pour lister les rôles disponibles :

$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 General, indiquez cette valeur dans les commandes PowerShell suivantes :

$azuread_app_role_name = "General"
$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"}

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.

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

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.

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.

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.

Créer la révision des attributions de rôles d’application

Une fois que les utilisateurs sont dans les rôles d’application et que les réviseurs sont identifiés, vous pouvez configurer Microsoft Entra ID pour démarrer une révision.

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.

Récupérer les affectations mises à jour une fois les révisions terminées

Une fois la révision terminée, vous pouvez récupérer la liste mise à jour des utilisateurs avec des attributions de rôle d’application.
```
$res = (Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $azuread_sp.Id -All)
```
Les colonnes PrincipalDisplayName et PrincipalId contiennent les noms complets et les ID d’utilisateur Microsoft Entra de chaque utilisateur qui conserve une attribution de rôle d’application.

Configurer l’intégration de la gestion des droits d’utilisation avec ServiceNow pour la création de tickets (facultatif)

Si vous disposez de ServiceNow, vous pouvez éventuellement configurer la création automatisée de tickets ServiceNow, à l’aide de l’intégration de la gestion des droits d’utilisation via Logic Apps. Dans ce scénario, la gestion des droits d’utilisation peut créer automatiquement des tickets ServiceNow pour l’approvisionnement manuel des utilisateurs qui ont reçu des affectations de package d’accès.

Share via