Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

Accorder un consentement pour une application au nom d’un utilisateur unique avec PowerShell

À quoi cela sert ?

Dans certaines organisations, il est parfois nécessaire d’accorder à une application des permissions pour accéder à une API uniquement au nom d’un utilisateur précis, sans étendre ce consentement à l’ensemble du tenant. Cette approche est particulièrement utile pour des scénarios de test, des comptes dédiés, ou des usages restreints nécessitant un contrôle fin des accès. Microsoft Entra ID permet cela grâce à Microsoft Graph PowerShell, en créant une délégation ciblée de permissions associée à un utilisateur unique.

Script proposé par Microsoft

Microsoft fournit un script PowerShell destiné à appliquer, pour une application, un ensemble de permissions déléguées au nom d’un utilisateur précis.

Prérequis

  • Un compte avec un rôle suffisant : Application Administrator, Cloud Application Administrator ou Privileged Role Administrator.
  • L’ID de l’application cliente, l’ID de l’API et l’UPN ou ID de l’utilisateur ciblé.
  • Le module Microsoft Graph PowerShell installé.

Script

# The app for which consent is being granted.
$clientAppId = "de8bc8b5-d9f9-48b1-a8ad-b748da725064" # Microsoft Graph Explorer

# The API to which access will be granted. Microsoft Graph Explorer makes API 
# requests to the Microsoft Graph API, so we'll use that here.
$resourceAppId = "00000003-0000-0000-c000-000000000000" # Microsoft Graph API

# The permissions to grant. Here we're including "openid", "profile", "User.Read"
# and "offline_access" (for basic sign-in), as well as "User.ReadBasic.All" (for 
# reading other users' basic profile).
$permissions = @("openid", "profile", "offline_access", "User.Read", "User.ReadBasic.All")

# The user on behalf of whom access will be granted. The app will be able to access 
# the API on behalf of this user.
$userUpnOrId = "user@example.com"

# Step 0. Connect to Microsoft Graph PowerShell. We need User.ReadBasic.All to get
#    users' IDs, Application.ReadWrite.All to list and create service principals, 
#    DelegatedPermissionGrant.ReadWrite.All to create delegated permission grants, 
#    and AppRoleAssignment.ReadWrite.All to assign an app role.
#    WARNING: These are high-privilege permissions!
Connect-MgGraph -Scopes ("User.ReadBasic.All Application.ReadWrite.All " + "DelegatedPermissionGrant.ReadWrite.All " + "AppRoleAssignment.ReadWrite.All")

# Step 1. Check if a service principal exists for the client application. 
#     If one doesn't exist, create it.
$clientSp = Get-MgServicePrincipal -Filter "appId eq '$($clientAppId)'"
if (-not $clientSp) {
   $clientSp = New-MgServicePrincipal -AppId $clientAppId
}

# Step 2. Create a delegated permission that grants the client app access to the
#     API, on behalf of the user. (This example assumes that an existing delegated 
#     permission grant does not already exist, in which case it would be necessary 
#     to update the existing grant, rather than create a new one.)
$user = Get-MgUser -UserId $userUpnOrId
$resourceSp = Get-MgServicePrincipal -Filter "appId eq '$($resourceAppId)'"
$scopeToGrant = $permissions -join " "
$grant = New-MgOauth2PermissionGrant -ResourceId $resourceSp.Id -Scope $scopeToGrant -ClientId $clientSp.Id -ConsentType "Principal" -PrincipalId $user.Id

# Step 3. Assign the app to the user. This ensures that the user can sign in if assignment
#     is required, and ensures that the app shows up under the user's My Apps portal.
if ($clientSp.AppRoles | ? { $_.AllowedMemberTypes -contains "User" }) {
    Write-Warning ("A default app role assignment cannot be created because the " + "client application exposes user-assignable app roles. You must " + "assign the user a specific app role for the app to be listed " + "in the user's My Apps portal.")
} else {
    # The app role ID 00000000-0000-0000-0000-000000000000 is the default app role
    # indicating that the app is assigned to the user, but not for any specific 
    # app role.
    $assignment = New-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $clientSp.Id -ResourceId $clientSp.Id -PrincipalId $user.Id -AppRoleId "00000000-0000-0000-0000-000000000000"
}

Conclusion

Bien que ce mécanisme soit efficace pour des besoins très ciblés, il doit être utilisé de manière prudente. Le consentement est appliqué immédiatement, sans validation de l’utilisateur, ce qui peut amplifier les risques en cas de permissions sensibles. Cette méthode n’est pas adaptée pour remplacer un consentement administrateur global dès que l’application s’adresse à un ensemble étendu d’utilisateur.

[Le saviez vous ?] – Modification du groupe « Schema Admins » quels évènements surveiller ?

Lorsqu’une modification du groupe à privilèges ‘Schema Admins‘ est réalisée dans l’Active Directory, un Event Id est déclenché dans le journal d’évènement « Security » du contrôleur de domaine.

Voilà pourquoi il est important d’activer les journaux d’audit et d’ajouter ces évènements dans votre système de monitoring (Siem, Scripts Powershell, Scom, Zabbix….).

L’ajout de membre

Lorsqu’un compte est ajouté aux membres du Groupe ‘Schema Admins‘, l’évènement 4756 apparait dans les journaux de sécurité du contrôleur de domaine, malheureusement cet Event Id ne remonte pas que les modifications du groupe ‘Schema Admins’, il vous faudra donc ajouter un peu de filtrage en parcourant le Message de l’évènement.

La suppression de membre

Lorsqu’un compte est retiré des membres du Groupe ‘Schema Admins‘, l’évènement 4757 apparait dans les journaux de sécurité du contrôleur de domaine, tout comme pour l’ajout, il vous faudra donc ajouter un peu de filtrage en parcourant le Message de l’évènement.

Attention

Les groupes « Schema Admins » et « Enterprise Admins » partagent le même Id pour l’ajout et la suppression de membres (4756 et 4757), faites donc attention à la configuration de vos filtres et alertes.

[Le saviez vous ?] – Modification du groupe « DNS Admins » quels évènements surveiller ?

Lorsqu’une modification du groupe à privilèges ‘DNS Admins‘ est réalisée dans l’Active Directory, un Event Id est déclenché dans le journal d’évènement « Security » du contrôleur de domaine.

Voilà pourquoi il est important d’activer les journaux d’audit et d’ajouter ces évènements dans votre système de monitoring (Siem, Scripts Powershell, Scom, Zabbix….).

L’ajout de membre

Lorsqu’un compte est ajouté aux membres du Groupe ‘DNS Admins‘, l’évènement 4732 apparait dans les journaux de sécurité du contrôleur de domaine, malheureusement cet Event Id ne remonte pas que les modifications du groupe ‘DNS Admins’, il vous faudra donc ajouter un peu de filtrage en parcourant le Message de l’évènement.

La suppression de membre

Lorsqu’un compte est retiré des membres du Groupe ‘DNS Admins‘, l’évènement 4733 apparait dans les journaux de sécurité du contrôleur de domaine, tout comme pour l’ajout, il vous faudra donc ajouter un peu de filtrage en parcourant le Message de l’évènement.