Créer un package d’accès dans la gestion des droits d’utilisation pour une application avec un rôle unique à l’aide de PowerShell

Article
08/25/2024

Dans la gestion des droits d’utilisation Microsoft Entra, un package d’accès englobe les stratégies spécifiant comment les utilisateurs peuvent se voir attribuer un ou plusieurs rôles de ressources. Les ressources peuvent inclure des groupes, des applications et des sites SharePoint Online.

Cet article explique comment créer un package d’accès pour une application unique avec un rôle unique, à l’aide de Microsoft Graph PowerShell. Ce scénario s’applique principalement aux environnements qui utilisent la gestion des droits d’utilisation pour automatiser l’accès continu pour une application métier ou intergiciel spécifique. Une organisation disposant de plusieurs ressources ou de ressources avec plusieurs rôles peut également modéliser ses stratégies d’accès avec des packages d’accès :

Si l’organisation dispose déjà d’un modèle de rôle organisationnel pour ses rôles d’entreprise, elle peut migrer ce modèle vers Gouvernance Microsoft Entra ID et régir l’accès avec un modèle de rôle organisationnel.
Si l’organisation a des applications avec plusieurs rôles, elle peut déployer des stratégies organisationnelles pour régir l’accès aux applications intégrées à Microsoft Entra ID.
Pour plus d’informations sur la création de packages d’accès pour d’autres scénarios, consultez Tutoriel : Gérer l’accès aux ressources dans la gestion des droits d’utilisation et comment créer un package d’accès dans la gestion des droits d’utilisation.

Prérequis

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.

Avant de commencer à créer le package d’accès, vous devez intégrer l’application à Microsoft Entra ID. Si votre application n’est pas encore présente dans votre locataire Microsoft Entra ID, suivez les instructions de cet article pour créer une application et un principal de service pour l’objet. Vérifiez également que votre locataire Microsoft Entra ID satisfait les prérequis avant de configurer Microsoft Entra ID pour la gouvernance des identités.

Pour créer le package d’accès et ses stratégies et affectations associées, vous devez disposer des informations suivantes :

Cas d’usage	Paramètre de configuration	Variable PowerShell
Tous	Nom de l’application dans votre locataire Microsoft Entra ID	`$servicePrincipalName`
Tous	Nom du rôle de l’application	`$servicePrincipalRoleName`
Tous	Nom du catalogue contenant le package d’accès	`$catalogName`
Tous	Nom à donner au package d’accès	`$accessPackageName`
Tous	Description à donner au package d’accès	`$accessPackageDescription`
Séparation des tâches requise avec un package d’accès incompatible	ID du package d’accès incompatible	`$incompatibleAccessPackageId` (si nécessaire)
Utilisateurs qui n’ont pas encore d’affectation et qui ne seraient pas automatiquement affectés	Liste d’utilisateurs	`$inputpath` (si nécessaire)
Les utilisateurs ayant des attributs spécifiques ont automatiquement des affectations	Expression de requête pour les utilisateurs dans l’étendue	`$autoAssignmentPolicyFilter` (si nécessaire)
Autoriser les utilisateurs qui n’ont pas d’affectation à demander une affectation	Étendue des utilisateurs qui peuvent demander, approbateurs, et période de révision d’accès	Dépend des exigences
Automatiser la création ou la suppression d’affectations selon que l’utilisateur rejoint ou quitte un workflow dans les workflows de cycle de vie	Noms des workflows qui accordent et retirent l’accès	Dépend des exigences

S’authentifier auprès de Microsoft Entra ID

Cette section montre comment interagir avec Gouvernance 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 Identity Governance.

Ouvrez PowerShell.
Si les modules Microsoft Graph PowerShell ne sont pas déjà installés, installez le module Microsoft.Graph.Identity.Governance 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.

Créer un catalogue dans la gestion des droits d’utilisation Microsoft Entra

Par défaut, lorsqu’un administrateur interagit pour la première fois avec la gestion des droits d’utilisation, un catalogue par défaut est créé automatiquement. Toutefois, les packages d’accès pour les applications régies doivent se trouver dans un catalogue désigné.

Spécifiez le nom du catalogue.
```
$catalogName = "Business applications"
```
Si vous disposez déjà d’un catalogue pour votre scénario de gouvernance d’application, passez à l’étape 4 de cette section.
Si vous n’avez pas encore de catalogue pour votre scénario de gouvernance des applications, créez un catalogue.
```
$catalog = New-MgEntitlementManagementCatalog -DisplayName $catalogName
```

Recherchez l’ID du catalogue.

$catalogFilter = "displayName eq '" + $catalogName + "'"
$catalog = Get-MgEntitlementManagementCatalog -Filter $catalogFilter -All -expandProperty resources,accessPackages
if ($catalog -eq $null) { throw "catalog $catalogName not found" }
$catalogId = $catalog.Id

Ajouter l’application en tant que ressource au catalogue

Une fois le catalogue créé, ajoutez l’application en tant que ressource dans ce catalogue.

Spécifiez le nom de l’application et le nom du rôle d’application. Utilisez le nom de votre application comme valeur de servicePrincipalName.
```
$servicePrincipalName = "SAP Cloud Identity Services"
$servicePrincipalRoleName = "User"
```

Recherchez l’ID du principal de service de l’application.

$servicePrincipalFilter = "displayName eq '" + $applicationName + "'"
$servicePrincipal = Get-MgServicePrincipal -Filter $servicePrincipalFilter -all
if ($servicePrincipal -eq $null) { throw "service principal $servicePrincipalName not found" }
$servicePrincipalId = $servicePrincipal.Id

Vérifiez si l’application est déjà présente dans le catalogue en tant que ressource. Si elle est déjà présente, passez à l’étape 6 de cette section.

$resourceId = $null
foreach ($r in $catalog.Resources) { if ($r.OriginId -eq $servicePrincipalId) { $resourceId = $r.id; break } }
if ($resourceId -ne $null) { write-output "resource already in catalog" } else {write-output "resource not yet in catalog"}

Ajoutez le principal de service de l’application en tant que ressource au catalogue.

$resourceAddParams = @{
  requestType = "adminAdd"
  resource = @{
    originId = $servicePrincipalId
    originSystem = "AadApplication"
  }
  catalog = @{ id = $catalogId }
}

$resourceAdd = New-MgEntitlementManagementResourceRequest -BodyParameter $resourceAddParams
if ($resourceAdd -eq $null) { throw "resource could not be added" }
sleep 5

Récupérez l’ID et l’étendue de la ressource dans ce catalogue.

$resource = $null
$resourceId = $null
$resourceScope = $null
$catalogResources = Get-MgEntitlementManagementCatalogResource -AccessPackageCatalogId $CatalogId -ExpandProperty "scopes" -all

foreach ($r in $catalogResources) { if ($r.OriginId -eq $servicePrincipalId) { $resource = $r; $resourceId = $r.id; $resourceScope = $r.Scopes[0]; break } }
if ($resourceId -eq $null) { throw "resource was not added" }

Récupérez les rôles de l’application.

$resourceRoleFilter = "(originSystem eq 'AadApplication' and resource/id eq '" + $resourceId + "')"
$resourceRoles = @(get-mgentitlementmanagementcatalogresourcerole  -AccessPackageCatalogId $catalogId -Filter $resourceRoleFilter -All -ExpandProperty "resource")
if ($resourceRoles -eq $null -or $resourceRoles.count -eq 0) { throw "no roles available" }

Sélectionnez le rôle qui sera inclus dans le package d’accès.

$resourceRole = $null
foreach ($r in $resourceRoles) { if ($r.DisplayName -eq $servicePrincipalRoleName) { $resourceRole = $r; break; } }
if ($resourceRole -eq $null) { throw "role $servicePrincipalRoleName not located" }

Créer le package d’accès pour l’application

Ensuite, vous allez utiliser PowerShell pour créer un package d’accès dans un catalogue qui inclut le rôle de l’application.

Spécifiez le nom et la description du package d’accès.

$accessPackageName = "SAP Cloud Identity Services"
$accessPackageDescription = "A user of SAP Cloud Identity Services"
$accessPackageHidden = $true

Vérifiez que le package d’accès n’existe pas déjà.

foreach ($a in $catalog.AccessPackages) { if ($a.DisplayName -eq $accessPackageName) { throw "access package $accessPackageName already exists" } }

Créez le package d’accès.

$accessPackageParams = @{
    displayName = $accessPackageName
    description = $accessPackageDescription
    isHidden = $accessPackageHidden
    catalog = @{
        id = $catalog.id
    }
}
$accessPackage = New-MgEntitlementManagementAccessPackage -BodyParameter $accessPackageParams
$accessPackageId = $accessPackage.Id

Ajouter le rôle d’application au package d’accès

Une fois que vous avez créé un package d’accès, vous liez le rôle de la ressource dans le catalogue au package d’accès.

$rrsParams = @{
 role = @{
     id =  $resourceRole.Id
     displayName =  $resourceRole.DisplayName
     description =  $resourceRole.Description
     originSystem =  $resourceRole.OriginSystem
     originId =  $resourceRole.OriginId
     resource = @{
         id = $resource.Id
         originId = $resource.OriginId
         originSystem = $resource.OriginSystem
     }
 }
 scope = @{
     id = $resourceScope.Id
     originId = $resourceScope.OriginId
     originSystem = $resourceScope.OriginSystem
 }
}

$roleAddRes = New-MgEntitlementManagementAccessPackageResourceRoleScope -AccessPackageId $accessPackageId -BodyParameter $rrsParams

Créer des stratégies d’affectation de package d’accès pour l’affectation directe

Dans cette section, vous allez créer la première stratégie d’affectation de package d’accès dans le package d’accès, une stratégie d’affectation de package d’accès pour l’affectation directe, qui peut être utilisée pour le suivi des utilisateurs qui ont déjà accès à l’application. Dans l’exemple de stratégie créé dans cette section, seuls les administrateurs ou les gestionnaires d’affectation de package d’accès peuvent attribuer l’accès, les utilisateurs conservent indéfiniment l’accès, et il n’y a pas d’approbations ni de révisions d’accès.

Créez une stratégie.

$policy1Name = "Direct assignment policy"
$policy1Description = "policy for administrative assignment"

$policy1params = @{
 displayName = $policy1Name
 description = $policy1Description
 allowedTargetScope = "notSpecified"
 specificAllowedTargets = @(
 )
 expiration = @{
     endDateTime = $null
     duration = $null
     type = "noExpiration"
 }
 requestorSettings = @{
     enableTargetsToSelfAddAccess = $true
     enableTargetsToSelfUpdateAccess = $false
     enableTargetsToSelfRemoveAccess = $true
     allowCustomAssignmentSchedule = $true
     enableOnBehalfRequestorsToAddAccess = $false
     enableOnBehalfRequestorsToUpdateAccess = $false
     enableOnBehalfRequestorsToRemoveAccess = $false
     onBehalfRequestors = @(
     )
 }
 requestApprovalSettings = @{
     isApprovalRequiredForAdd = $false
     isApprovalRequiredForUpdate = $false
     stages = @(
     )
 }
 accessPackage = @{
     id = $accessPackageId
 }
}

$policy1Res = New-MgEntitlementManagementAssignmentPolicy -BodyParameter $policy1params
$directAssignmentPolicyId = $policy1Res.Id

Configurer les contraintes de séparation des tâches

La gestion des droits d’utilisation Microsoft Entra peut appliquer des vérifications de séparation des tâches pour empêcher un utilisateur qui a déjà une affectation existante à un autre package d’accès désigné, ou qui est membre d’un groupe désigné, de demander un package d’accès.

Si vous n’avez pas d’exigences en matière de séparation des tâches pour cette application, passez à la section suivante.

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.

Pour chaque package d’accès qui doit être marqué comme incompatible avec un autre, vous pouvez utiliser PowerShell afin de configurer des packages d’accès comme incompatibles.

Spécifiez l’autre package d’accès incompatible avec celui-ci. Remplacez la valeur de incompatibleAccessPackageId par l’ID d’un autre package d’accès dans la gestion des droits d’utilisation Microsoft Entra.
```
$incompatibleAccessPackageId = "67cc7175-7a3d-4cb2-860f-4d9217ba96ca"
```

Créez la référence incompatible sur ce package d’accès.

$incompatible1params = @{
 "@odata.id" = "https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/accessPackages/" + $incompatibleAccessPackageId
}
New-MgEntitlementManagementAccessPackageIncompatibleAccessPackageByRef -AccessPackageId $accessPackageId -BodyParameter $incompatible1params

Créez la référence incompatible sur l’autre package d’accès.

$incompatible2params = @{
 "@odata.id" = "https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/accessPackages/" + $accessPackageId
}
New-MgEntitlementManagementAccessPackageIncompatibleAccessPackageByRef -AccessPackageId $incompatibleAccessPackageId -BodyParameter $incompatible2params

Répétez l’opération pour tous les autres packages 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.

Ajoutez les affectations d’utilisateurs existants qui ont déjà accès à l’application.

Ajoutez les affectations d’utilisateurs existants, qui ont déjà accès à l’application, au package d’accès et à sa stratégie d’affectation directe. Vous pouvez affecter directement chaque utilisateur à un package d’accès.

Récupérez les attributions de rôles d’application existantes.

$existingAppRoleAssignments = @(Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $servicePrincipalId -All)

Pour éviter de créer des attributions en double, récupérez les attributions existantes dans le package d’accès.

$existingAssignments1filter = "accessPackage/id eq '" + $accessPackageId + "' and state eq 'Delivered'"
$existingassignments1 = @(Get-MgEntitlementManagementAssignment -Filter $existingAssignments1filter -ExpandProperty target -All -ErrorAction Stop)
$existingusers1 = @()
foreach ($a in $existingassignments1) { $existingusers1 += $a.Target.ObjectId}

Créez de nouvelles affectations.

foreach ($ar in $existingAppRoleAssignments) {
 if ($ar.principalType -ne "User") {
   write-warning "non-user assigned to application role"
 }
 $arpid = $ar.principalId
 if ($existingusers1.contains($arpId)) { continue }

 $params = @{
   requestType = "adminAdd"
   assignment = @{
      targetId = $arpId
      assignmentPolicyId = $directAssignmentPolicyId
      accessPackageId = $accessPackageId
   }
 }
 try {
   New-MgEntitlementManagementAssignmentRequest -BodyParameter $params
 } catch {
   write-error "cannot create request for user $upn"
 }
}

Ajoutez des affectations à tous les utilisateurs supplémentaires qui doivent avoir accès à l’application.

Ce script illustre l’utilisation des cmdlets PowerShell Microsoft Graph pour ajouter des utilisateurs supplémentaires afin qu’ils aient accès à l’application. Si vous n’avez pas d’utilisateurs qui ont besoin d’un accès et qui ne le recevraient pas automatiquement, passez à la section suivante.

Ce script part du principe que vous disposez d’un fichier CSV d’entrée contenant une colonne, UserPrincipalName, pour affecter ces utilisateurs au package d’accès via sa stratégie d’affectation directe.

Spécifiez le nom du fichier d’entrée.
```
$inputpath = "users.csv"
```

Pour éviter de créer des attributions en double, récupérez les attributions existantes dans le package d’accès.

$existingAssignments2filter = "accessPackage/id eq '" + $accessPackageId + "' and state eq 'Delivered'"
$existingassignments2 = @(Get-MgEntitlementManagementAssignment -Filter $existingAssignments2filter -ExpandProperty target -All -ErrorAction Stop)
$existingusers2 = @()
foreach ($a in $existingassignments2) { $existingusers2 += $a.Target.ObjectId}

Créez de nouvelles affectations.

$users = import-csv -Path $inputpath
foreach ($userrecord in $users) {
   $upn = $userrecord.UserPrincipalName
   if ($null -eq $upn) {throw "no UserPrincipalName" }
   $u = $null
   try {
      $u = Get-MgUser -UserId $upn
   } catch {
      write-error "no user $upn"
   }
   if ($u -eq $null) { continue }
   if ($existingusers2.contains($u.Id)) { continue }

   $params = @{
      requestType = "adminAdd"
      assignment = @{
         targetId = $u.Id
         assignmentPolicyId = $directAssignmentPolicyId
         accessPackageId = $accessPackageId
      }
   }
   try {
      New-MgEntitlementManagementAssignmentRequest -BodyParameter $params
   } catch {
      write-error "cannot create request for user $upn"
   }
}

Ajouter une stratégie aux packages d’accès pour l’affectation automatique

Si la stratégie de votre organisation spécifiant qui peut se voir octroyer l’accès à une application inclut une règle basée sur les attributs de l’utilisateur qui, en fonction de ces derniers, régit l’octroi et la suppression automatiques de l’accès, vous pouvez représenter cela en utilisant une stratégie d’affectation automatique. Un package d’accès peut avoir au maximum une stratégie d’affectation automatique. Si vous n’avez pas besoin d’affectation automatique, passez à la section suivante.

Spécifiez l’expression de filtre d’affectation automatique pour que les utilisateurs reçoivent une affectation. Remplacez la valeur de autoAssignmentPolicyFilter par un filtre pour les utilisateurs Microsoft Entra ID qui sont dans l’étendue. La syntaxe et les attributs autorisés sont fournis dans les règles pour les groupes d’appartenance dynamique dans Microsoft Entra ID.
```
$autoAssignmentPolicyFilter = '(user.city -eq "Redmond")'
```

Utilisez PowerShell pour créer une stratégie d’affectation automatique dans le package d’accès.

$policy2Name = "Automatic assignment policy"
$policy2Description = "policy for automatic assignment"

$policy2Params = @{
 DisplayName = $policy2Name
 Description = $policy2Description
 AllowedTargetScope = "specificDirectoryUsers"
 SpecificAllowedTargets = @( @{
     "@odata.type" = "#microsoft.graph.attributeRuleMembers"
     description = $policy2Description
     membershipRule = $autoAssignmentPolicyFilter
 } )
 AutomaticRequestSettings = @{
     RequestAccessForAllowedTargets = $true
 }
 AccessPackage = @{
   Id = $accessPackageId
 }
}
New-MgEntitlementManagementAssignmentPolicy -BodyParameter $policy2Params

Créer des stratégies supplémentaires pour permettre aux utilisateurs de demander l’accès

Si vous souhaitez que les utilisateurs qui n’ont pas encore d’accès puissent demander à être affectés à l’application, vous pouvez également configurer une stratégie d’affectation de package d’accès pour permettre aux utilisateurs de demander un package d’accès. Vous pouvez ajouter des stratégies à un package d’accès et, dans chaque stratégie, spécifier quels utilisateurs peuvent formuler une demande et qui doit accorder l’approbation. Si vous souhaitez que l’accès puisse être octroyé aux utilisateurs uniquement automatiquement ou par un administrateur, passez à la section suivante.

Pour obtenir plus d’exemples, consultez Créer une stratégie d’affectation via PowerShell, accessPackageAssignmentPolicy et Créer un objet assignmentPolicy.

Spécifiez le nom, la description de la stratégie et l’ID d’un utilisateur Microsoft Entra qui sera l’approbateur.

$policy3Name = "example policy"
$policy3Description = "example of a policy for users to request assignment"
$policy3ApproverSingleUserId = "1aaaaaa1-2bb2-3cc3-4dd4-5eeeeeeeeee5"

Créez la stratégie.

$policy3Params = @{
 displayName = $policy3Name
 description = $policy3Description
 allowedTargetScope = "allMemberUsers"
 expiration = @{
     type = "noExpiration"
 }
 requestorSettings = @{
     enableTargetsToSelfAddAccess = "true"
     enableTargetsToSelfUpdateAccess = "true"
     enableTargetsToSelfRemoveAccess = "true"
 }
 requestApprovalSettings = @{
     isApprovalRequiredForAdd = "true"
     isApprovalRequiredForUpdate = "true"
     stages = @(
         @{
             durationBeforeAutomaticDenial = "P7D"
             isApproverJustificationRequired = "false"
             isEscalationEnabled = "false"
             fallbackPrimaryApprovers = @(
             )
             escalationApprovers = @(
             )
             fallbackEscalationApprovers = @(
             )
             primaryApprovers = @(
                 @{
                     "@odata.type" = "#microsoft.graph.singleUser"
                     userId = $policy3ApproverSingleUserId
                 }
             )
         }
     )
 }
 accessPackage = @{
     id = $accessPackageId
 }
}

New-MgEntitlementManagementAssignmentPolicy -BodyParameter $policy3Params

Configurer des tâches de workflows de cycle de vie

Si vous utilisez des workflows de cycle de vie Microsoft Entra pour les événements de recrutement, de mutation ou de fin de contrat des employés, vous pouvez également ajouter des tâches à ces workflows afin d’ajouter ou de supprimer des affectations de ce package d’accès. Si vous n’utilisez pas de workflows de cycle de vie, passez à la section suivante.

Cet exemple montre comment apporter une modification aux workflows d’événements de recrutement et de fin de contrat.

Récupérez le workflow de catégorie joiner et ses tâches à l’aide de la commande Get-MgIdentityGovernanceLifecycleWorkflow.

Ajoutez une tâche à la liste des tâches de ce workflow.

Nom d’affichage de la tâche	taskDefinitionId	arguments
Demander une attribution de package d’accès pour un utilisateur	`c1ec1e76-f374-4375-aaa6-0bb6bd4c60be`	nom : `assignmentPolicyId` valeur : ID de stratégie d’affectation, tel que la valeur de `$directAssignmentPolicyId` si aucune approbation n’est requise, pour le package d’accès que vous souhaitez affecter à l’utilisateur. nom : `accessPackageId` valeur : ID du package d’accès, `$accessPackageId`, pour le package d’accès que vous souhaitez affecter à l’utilisateur.

Créez une nouvelle version du workflow, incluant la nouvelle tâche, à l’aide de la commande New-MgIdentityGovernanceLifecycleWorkflowNewVersion.
Récupérez le workflow de catégorie leaver et ses tâches à l’aide de la commande Get-MgIdentityGovernanceLifecycleWorkflow.

Ajoutez une tâche à la liste des tâches de ce workflow.

Nom d’affichage de la tâche	taskDefinitionId	arguments
Supprimer l’attribution de package d’accès pour l’utilisateur	`4a0b64f2-c7ec-46ba-b117-18f262946c50`	nom : `accessPackageId` valeur : ID de package d’accès valide, `accessPackageId` pour le package d’accès que vous souhaitez désaffecter de l’utilisateur.

Créez une nouvelle version du workflow, incluant la nouvelle tâche, à l’aide de la commande New-MgIdentityGovernanceLifecycleWorkflowNewVersion.

Gérer les affectations

Une fois que les packages d’accès, les stratégies et les affectations initiales ont été créés, les utilisateurs disposent de l’accès au rôle de l’application.

Plus tard, vous pouvez superviser les modifications apportées aux affectations, ou ajouter ou supprimer des affectations par programmation.

Récupérer des affectations existantes

Ce script illustre l’utilisation d’un filtre pour récupérer les affectations au package d’accès qui sont à l’état Delivered. Le script génère un fichier CSV assignments.csv contenant une liste d’utilisateurs qui ont des affectations, avec une ligne par affectation.

$assignmentFilter = "accessPackage/id eq '" + $accessPackageId + "' and state eq 'Delivered'"
$assignments = @(Get-MgEntitlementManagementAssignment -Filter $assignmentFilter -ExpandProperty target -All -ErrorAction Stop)
$sp = $assignments | select-object -Property Id,{$_.Target.id},{$_.Target.ObjectId},{$_.Target.DisplayName},{$_.Target.PrincipalName}
$sp | Export-Csv -Encoding UTF8 -NoTypeInformation -Path ".\assignments.csv"

Supprimer une affectation

Vous pouvez supprimer l’affectation d’un utilisateur avec la cmdlet New-MgEntitlementManagementAssignmentRequest.

$userId = "00aa00aa-bb11-cc22-dd33-44ee44ee44ee"
$filter = "accessPackage/Id eq '" + $accessPackageId + "' and state eq 'Delivered' and target/objectId eq '" + $userId + "'"
$assignment = Get-MgEntitlementManagementAssignment -Filter $filter -ExpandProperty target -all -ErrorAction stop
if ($assignment -ne $null) {
   $params = @{
      requestType = "adminRemove"
      assignment = @{ id = $assignment.id }
   }
   New-MgEntitlementManagementAssignmentRequest -BodyParameter $params
}

Partager via