Par défaut, toute personne qui exécute Connect-MgGraph s'authentifie via l'application d'entreprise Microsoft Graph Command Line Tools, avec toutes les permissions consenties sur cette app unique. Dans les grandes organisations, ce modèle centralisé pose rapidement un problème de granularité : le service support n'a pas besoin des mêmes droits qu'une équipe conformité ou qu'un administrateur global. Cet article détaille comment créer et exploiter des applications Entra ID dédiées pour segmenter l'accès interactif au SDK Microsoft Graph PowerShell.
Le problème de l'application par défaut et de la dérive des permissions
L'application Microsoft Graph Command Line Tools fonctionne bien pour un usage administratif ponctuel, mais elle concentre au fil du temps un nombre croissant de permissions consenties par différentes équipes. Ce phénomène de dérive des permissions (permission creep) rend les revues de sécurité complexes : impossible de savoir précisément qui a besoin de quoi, puisque tout le monde partage la même surface de permissions.
Une organisation qui veut appliquer le principe du moindre privilège doit segmenter cet accès. Exemple concret : le help desk a besoin de gérer des comptes utilisateurs, des groupes et des appareils, mais ne doit avoir aucun accès aux données de conformité, aux journaux d'audit ou aux paramètres de sécurité tenant-wide.
Le principe
Application d'entreprise par défaut ou application inscrite dédiée
La différence entre les deux approches se joue sur trois axes : la portée des permissions, la capacité à restreindre les attributions, et la facilité de revue périodique.
| Critère | Application d’entreprise par défaut | Application inscrite dédiée |
|---|---|---|
| Application utilisée | Microsoft Graph Command Line Tools | App créée et nommée par le tenant (ex. HelpDeskGraphSDK) |
| Portée des permissions | Large, accumulée au fil des consentements | Limitée aux permissions strictement nécessaires à l’équipe |
| Attribution des utilisateurs | Souvent ouverte à l’ensemble des comptes | Restreinte via un groupe de sécurité dédié |
| Gouvernance et revue | Difficile, permissions mutualisées entre équipes | Revue périodique possible application par application |
| Cas d’usage typique | Administrateurs généralistes ou scripts d’automatisation | Équipes spécialisées : support, sécurité, conformité |
Créer une application inscrite dédiée pour le SDK Graph PowerShell
La création d'une application dédiée se fait intégralement depuis le portail Entra, sans nécessiter de script pour l'inscription elle-même. Voici la séquence complète.
Inscrire l'application dans Entra ID
Dans le centre d'administration Entra, section App Registrations, créez une nouvelle inscription d'application, donnez-lui un nom explicite (ex. HelpDeskGraphSDK) et enregistrez-la. Assignez au moins un propriétaire d'application et configurez une icône pour faciliter son identification ultérieure.
Configurer l'URI de redirection
Ouvrez l'onglet Authentication de l'application. Sous Redirect URI, choisissez Add Redirect URI puis Mobile and desktop applications. Le choix exact de la valeur dépend de la version de PowerShell utilisée par vos équipes (voir la section suivante). N'oubliez pas de cliquer sur Configure pour valider l'ajout.
Ajouter les permissions déléguées et consentir
Ajoutez uniquement les permissions Graph déléguées nécessaires, par exemple Directory.Read.All et User.Read.All pour un help desk, puis accordez le consentement administrateur. L'application ne fonctionne qu'en accès délégué : les utilisateurs restent limités aux données qu'ils sont eux-mêmes autorisés à consulter. Pour manipuler des objets tenant-wide (groupes, rapports, données d'annuaire), les comptes assignés devront aussi disposer des rôles Entra appropriés.
Rendre l'attribution obligatoire
Dans Enterprise applications, retrouvez le principal de service de l'app, ouvrez la page Properties et positionnez Assignment required? sur Yes. Cette bascule impose qu'un utilisateur ou un groupe soit explicitement assigné avant de pouvoir utiliser l'application.
Attribuer les utilisateurs et groupes autorisés
Toujours dans l'application d'entreprise, ouvrez l'onglet Users and groups et ajoutez les comptes ou, de préférence, un groupe de sécurité dédié. Les attributions s'appliquent au principal de service, car c'est lui qui applique le contrôle d'accès dans le tenant.
Se connecter via l'application dédiée
Une fois l'application configurée, les utilisateurs autorisés se connectent en précisant l'identifiant du tenant et l'identifiant de l'application dans Connect-MgGraph :
1Connect-MgGraph -TenantId mytenant.com -AppId a69635f3-3ac8-4949-a82b-f31b396de57bRépétez l'ensemble de la procédure pour chaque équipe nécessitant un accès différencié au SDK Graph PowerShell.
Ne multipliez pas les apps sans discernement
URI de redirection : le piège classique avec WAM et PowerShell 7
Avant l'arrivée du support WAM (Web Account Manager) dans le SDK Microsoft Graph PowerShell, appelé à devenir le comportement par défaut pour toutes les sessions interactives, l'URI de redirection standard était https://login.microsoftonline.com/common/oauth2/nativeclient. Cette valeur reste fonctionnelle avec PowerShell 5.1.
En revanche, sous PowerShell Core (7.x), WAM utilise un flux d'authentification différent, et l'URI nativeclient provoque une erreur AADSTS50011. Selon la documentation Microsoft sur les commandes d'authentification du SDK Graph PowerShell, la configuration correcte associe http://localhost à un URI de redirection broker WAM de la forme ms-appx-web://Microsoft.AAD.BrokerPlugin/.
À vérifier avant tout déploiement
Attribuer et vérifier les accès utilisateurs
La cmdlet Get-MgServicePrincipalAppRoleAssignedTo liste les comptes disposant d'une attribution directe sur une application. L'exemple ci-dessous récupère d'abord l'identifiant du principal de service via Get-MgServicePrincipal, puis interroge les attributions :
1$GraphSDKApp = Get-MgServicePrincipal -filter "displayname eq 'HelpDeskGraphSDK'"2 3$GraphSDKApp | Format-Table DisplayName, Id4 5# DisplayName Id6# -------------- --7# Help Desk Graph SDK 0c593b15-ec27-4481-9e12-31777c9f65038 9$Assignees = Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $GraphSDKApp.Id10 11$Assignees | Format-Table CreatedDateTime, PrincipalDisplayName, AppRoleId12 13# CreatedDateTime PrincipalDisplayName AppRoleId14# --------------- -------------------- ---------15# 07/09/2026 09:04:54 Tenant Administrator 00000000-0000-0000-0000-00000000000016# 07/09/2026 09:03:00 Help Desk Graph SDK Access 00000000-0000-0000-0000-000000000000L'identifiant 00000000-0000-0000-0000-000000000000 correspond au rôle Default Access, suffisant pour utiliser l'application. Vous pouvez aussi ajouter une attribution directe par script avec New-MgUserAppRoleAssignment :
1$SP = Get-MgServicePrincipal -filter "DisplayName eq 'HelpDeskGraphSDK'"2$DefaultRoleId = "00000000-0000-0000-0000-000000000000"3$User = Get-MgUser -UserId Kim.Akers@office365itpros.com4 5New-MgUserAppRoleAssignment -UserId $User.Id -AppRoleId $DefaultRoleId -PrincipalId $User.Id -ResourceId $SP.IdUne fois connecté via une application dédiée sous SDK Microsoft Graph PowerShell V2.39 en PowerShell Core, l'utilisateur ne dispose que des permissions consenties à cette app, par exemple User.ReadBasic.All. Attention : cette permission ne permet pas de filtrer sur la propriété UserType, ce qui bloquera les tentatives de recherche restreinte aux comptes membres.
Pour retirer une attribution devenue inutile, la cmdlet symétrique Remove-MgServicePrincipalAppRoleAssignedTo s'utilise après avoir récupéré l'identifiant exact de l'attribution via Get-MgServicePrincipalAppRoleAssignedTo :
1$AssignmentId = ($Assignees | Where-Object PrincipalDisplayName -eq 'Kim Akers').Id2Remove-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $SP.Id -AppRoleAssignmentId $AssignmentIdMise en œuvre : audit périodique des applications Graph SDK
Plutôt que de vérifier manuellement chaque application, un script d'audit régulier permet de suivre les attributions et les permissions consenties, et de repérer une éventuelle dérive.
Script en lecture seule
1# Prérequis : module Microsoft.Graph (sous-modules Applications et Identity.SignIns)2# Installation : Install-Module Microsoft.Graph -Scope CurrentUser3# Permission minimale requise : Application.Read.All (délégué) + Directory.Read.All4# Sortie : fichier CSV listant, pour chaque application Graph SDK dédiée,5# les comptes/groupes assignés et les permissions déléguées consenties6 7Connect-MgGraph -Scopes "Application.Read.All", "Directory.Read.All" -NoWelcome8 9# Convention de nommage : adaptez ce motif à vos propres applications Graph SDK10$AppNamingPattern = "*GraphSDK*"11 12$CustomApps = Get-MgServicePrincipal -All | Where-Object { $_.DisplayName -like $AppNamingPattern }13 14if (-not $CustomApps) {15 Write-Host "Aucune application correspondant au motif '$AppNamingPattern' n'a été trouvée." -ForegroundColor Yellow16 return17}18 19$Report = foreach ($App in $CustomApps) {20 21 # Comptes et groupes assignés à l'application (onglet Users and groups)22 $Assignees = Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $App.Id -All23 24 # Permissions déléguées consenties pour cette application25 $DelegatedGrants = Get-MgServicePrincipalOauth2PermissionGrant -ServicePrincipalId $App.Id -All26 27 [PSCustomObject]@{28 Application = $App.DisplayName29 AppId = $App.AppId30 AssignmentRequired = $App.AppRoleAssignmentRequired31 NombreAssignations = $Assignees.Count32 Assignes = ($Assignees.PrincipalDisplayName -join "; ")33 PermissionsDeleguees = ($DelegatedGrants.Scope -join " ").Trim()34 }35}36 37# Export du rapport pour revue périodique (recommandé : trimestrielle)38$Report | Export-Csv -Path ".\\Rapport-Apps-GraphSDK.csv" -NoTypeInformation -Encoding UTF839 40$Report | Format-Table -AutoSizeCe script produit un tableau et un fichier CSV recensant, application par application, le nombre de comptes assignés, leur identité, et la liste des permissions déléguées consenties. C'est ce rapport qu'il faut passer en revue lors de l'audit trimestriel évoqué plus haut.
Dépannage des erreurs courantes
- AADSTS50011 (« The reply URL specified in the request does not match ») : l'URI de redirection ne correspond pas au flux WAM utilisé par PowerShell Core. Vérifiez la présence de
http://localhostet de l'URI brokerms-appx-web://Microsoft.AAD.BrokerPlugin/. - AADSTS50105 (« Your administrator has configured the application... to block users unless they are specifically granted access ») : l'utilisateur tente de se connecter à une application dont
Assignment required?est sur Yes sans disposer d'une attribution directe ou via un groupe. - AADSTS65001 (consentement requis) : les permissions déléguées de l'application n'ont pas été consenties par un administrateur. Retournez sur la page API permissions et cliquez sur Grant admin consent.
- Accès refusé lors de
Get-MgServicePrincipalOauth2PermissionGrant: le compte exécutant le script d'audit ne dispose pas de la permissionApplication.Read.All. Vérifiez le scope demandé lors duConnect-MgGraphinitial.
Points clés à retenir
La segmentation de l'accès interactif au SDK Microsoft Graph PowerShell via des applications Entra ID dédiées répond directement au problème de dérive des permissions accumulées sur l'application par défaut. Concrètement :
- Créez une application inscrite par équipe ayant des besoins d'accès distincts, avec
Assignment required?positionné sur Yes. - Configurez l'URI de redirection en fonction de la version de PowerShell utilisée (
nativeclientpour 5.1,localhost+ broker WAM pour PowerShell Core). - Utilisez un groupe de sécurité plutôt que des attributions individuelles pour simplifier la gestion des accès.
- Planifiez une revue périodique des permissions et attributions via un script d'audit, et n'oubliez pas de sécuriser également l'application par défaut Microsoft Graph Command Line Tools.
Si votre organisation gère plusieurs équipes avec des besoins Graph hétérogènes, commencez par une seule application pilote (le help desk, par exemple) avant de généraliser le modèle à l'ensemble des services concernés.