Managed Identity UAMI : authentification Graph PowerShell

Introduction : SAMI vs UAMI dans Azure Automation

Lorsqu'on automatise des tâches Microsoft 365 via Azure Automation, la question de l'authentification est centrale. La méthode la plus courante repose sur les System Assigned Managed Identities (SAMI) : simples à configurer, elles sont créées et gérées automatiquement par Azure en lien direct avec un compte d'automatisation. Cependant, cette liaison exclusive constitue aussi leur principale limite.

Dans les environnements complexes — plusieurs comptes d'automatisation, plusieurs abonnements Azure, ou encore des ressources telles que des Logic Apps, des Function Apps ou des machines virtuelles — la User Assigned Managed Identity (UAMI) s'impose comme une alternative plus flexible et plus robuste. Contrairement à une SAMI, une UAMI est un objet Azure indépendant, réutilisable sur plusieurs ressources et dont le cycle de vie n'est pas lié à un compte d'automatisation spécifique.

Cet article détaille pas à pas la configuration d'une UAMI, l'attribution des permissions Microsoft Graph et son intégration dans un runbook PowerShell.

Comparaison SAMI et UAMI

Avant de se lancer dans la configuration, il est utile de comprendre les différences structurelles entre les deux types d'identités managées.

Création d'une User Assigned Managed Identity

La création d'une UAMI s'effectue directement depuis le portail Azure.

Attribution des permissions Microsoft Graph à la UAMI

Comme toute identité managée, une UAMI dispose d'un service principal visible dans les applications d'entreprise du centre d'administration Entra. L'attribution des App Roles (permissions applicatives) de l'API Microsoft Graph ne peut pas être réalisée via l'interface graphique d'Entra : elle doit obligatoirement être effectuée via PowerShell avec le module Microsoft Graph PowerShell SDK.

Script PowerShell d'attribution des permissions Graph

Le script suivant illustre l'attribution des permissions AuditLog.Read.All, User.Read.All et GroupMember.Read.All à une UAMI nommée UAMI2.

Étape 1 — Récupérer les service principals

1# Récupération du service principal de la UAMI
2$TargetSP = Get-MgServicePrincipal -Filter "displayName eq 'UAMI2'"
3 
4# Récupération du service principal de Microsoft Graph
5$GraphApp = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'"

Étape 2 — Définir les permissions à attribuer

1$GraphPermissions = @(
2    "AuditLog.Read.All",
3    "User.Read.All",
4    "GroupMember.Read.All"
5)

Étape 3 — Attribuer les App Roles via New-MgServicePrincipalAppRoleAssignment

1ForEach ($GraphPermission in $GraphPermissions) {
2 
3    $AppRole = $GraphApp.AppRoles | Where-Object {
4        $_.Value -eq $GraphPermission -and
5        $_.AllowedMemberTypes -contains "Application"
6    }
7 
8    If ($AppRole) {
9        Try {
10            $Assignment = @{
11                PrincipalId = $TargetSP.Id
12                ResourceId  = $GraphApp.Id
13                AppRoleId   = $AppRole.Id
14            }
15 
16            $Status = New-MgServicePrincipalAppRoleAssignment `
17                -ServicePrincipalId $TargetSP.Id `
18                -BodyParameter $Assignment `
19                -ErrorAction Stop
20 
21            Write-Host ("Permission '{0}' attribuée à '{1}' avec succès." -f $AppRole.DisplayName, $TargetSP.DisplayName)
22        }
23        Catch {
24            Write-Host "Échec de l'attribution de la permission : $GraphPermission"
25        }
26    } Else {
27        Write-Host "Permission introuvable dans le service principal Graph : $GraphPermission"
28    }
29}

Liaison de la UAMI à un compte Azure Automation

À la différence d'une SAMI, une UAMI n'est pas automatiquement associée à un compte d'automatisation. Cette étape de liaison est indispensable et souvent oubliée lors d'une première configuration.

Authentification dans un runbook avec une UAMI

Différence de syntaxe avec une SAMI

L'authentification via une SAMI se résume à une seule commande :

1# Authentification avec une SAMI
2Connect-MgGraph -Identity

Pour une UAMI, il est nécessaire de préciser le Client ID afin qu'Azure identifie quelle identité utiliser :

1# Authentification avec une UAMI
2Connect-MgGraph -Identity -ClientId "<client-id-de-la-uami>"

Exemple de runbook complet avec récupération dynamique du Client ID

L'approche recommandée consiste à stocker le Client ID dans une variable Azure Automation et à le récupérer dynamiquement via Get-AutomationVariable. Cela évite tout codage en dur dans le script.

1# Récupération du Client ID depuis une variable Azure Automation
2$UamiAppId = Get-AutomationVariable -Name "UAMIAppId"
3 
4# Connexion à Azure Resource Manager (optionnel selon les besoins du runbook)
5Connect-AzAccount -Identity -AccountId $UamiAppId
6Get-AzContext
7 
8# Connexion à Microsoft Graph via la UAMI
9Connect-MgGraph -Identity -ClientId $UamiAppId -NoWelcome
10 
11Write-Host "Connexion à Microsoft Graph établie avec la UAMI : $UamiAppId"
12 
13# Exemple d'utilisation : récupération des utilisateurs
14Get-MgUser | Select-Object DisplayName

Compatibilité des modules PowerShell avec les Managed Identities

La majorité des modules PowerShell Microsoft 365 supportent l'authentification via les identités managées. Voici un récapitulatif :

• ✅ Microsoft Graph PowerShell SDK — support complet
• ✅ Az PowerShell — support complet
• ✅ Exchange Online Management Module — support via rôle Entra
• ✅ Microsoft Teams PowerShell — support complet
• ⚠️ SharePoint Online PnP PowerShell — support partiel, à tester
• ❌ SharePoint Online Management Shell — non supporté nativement

Quand choisir une UAMI plutôt qu'une SAMI ?

Le choix entre SAMI et UAMI dépend principalement de l'architecture de votre tenant Azure. Voici les critères à prendre en compte :

Optez pour une SAMI si :

• Votre tenant utilise un nombre limité de comptes d'automatisation
• La simplicité de configuration est prioritaire
• L'identité n'a pas vocation à être partagée entre plusieurs ressources

Optez pour une UAMI si :

• Plusieurs comptes d'automatisation doivent partager la même identité
• Vous utilisez des ressources Azure variées (Logic Apps, Function Apps, VMs)
• Vous souhaitez découpler le cycle de vie des identités de celui des ressources
• La gestion des coûts est répartie entre plusieurs unités opérationnelles avec des abonnements distincts

Références et ressources complémentaires

• Vue d'ensemble des Managed Identities — Microsoft Learn
• New-MgServicePrincipalAppRoleAssignment — Documentation cmdlet
• Authentification Azure Automation avec Managed Identity
• Microsoft Graph PowerShell SDK — Authentification
• Référence des permissions Microsoft Graph