07 · Workload identities, enterprise applications et app registrations

Version : 1.1 · Date : 2026-10-21 · Domaine 3 de l'examen : Plan and implement workload identities (20 à 25 %)

En une phrase : une charge de travail s'authentifie de préférence sans secret (managed identity dans Azure, federated credential ailleurs) ; chaque application vit en deux objets, l'App registration (le modèle, où l'on déclare redirect URIs, permissions demandées, scopes et app roles) et l'Enterprise application (l'instance dans le tenant, où l'on règle SSO, assignation, provisioning et consentement) ; Application Proxy publie les applications on-premises sans aucun port entrant.

Ce que l'examen demande#

Blocs Plan and implement identities for applications and Azure workloads, Plan, implement, and monitor the integration of enterprise applications et Plan and implement app registrations du guide d'étude SC-300 (compétences du 28 octobre 2026) :

Le quatrième bloc du domaine 3 (Manage and monitor app access by using Microsoft Defender for Cloud Apps) est traité au chapitre 08. Les risques des workload identities (ID Protection) sont au chapitre 06, les access reviews au chapitre 09.

Ce chapitre suppose connues les bases vues en SC-500 : application object et service principal (SC-500 01 § 5.1), types de credentials (§ 5.2), delegated et application permissions (§ 5.3), consentement (§ 6), managed identities et workload identity federation (§ 7). On va ici au niveau administrateur : réglages exacts du portail, PowerShell Microsoft Graph, licences, dépannage.

1. Les bases pour un administrateur#

1.1 Les workload identities dans Microsoft Entra#

Dans Microsoft Entra, les workload identities sont les applications, les service principals et les managed identities. Une managed identity est un type particulier de service principal : elle n'a pas d'application object (pas d'App registration), seulement un service principal, et Azure gère ses credentials. Conséquence pratique : on ne peut pas modifier les réglages d'une managed identity depuis Enterprise applications, la frontière de sécurité est la ressource Azure elle-même.

1.2 Les licences qui reviennent dans ce domaine#

Workload ID Premium : Conditional Access pour workload identities ne couvre que les applications single-tenant et pas les managed identities ; ID Protection couvre les applications single-tenant et multitenant, pas les managed identities ni les applications Microsoft. Une seule licence dans le tenant débloque les fonctions, sans assignation par identité.

2. Choisir l'identité d'une charge de travail#

Un gMSA reste un compte AD DS : il ne sert pas à accéder aux API Entra ou Azure. Pour une application on-premises qui doit appeler Azure, la réponse est un service principal (certificat ou federated credential), voire une managed identity si le serveur est Azure Arc-enabled (endpoint local http://localhost:40342).

3. Créer et assigner une managed identity#

Le choix system-assigned ou user-assigned est détaillé en SC-500 01 § 7.2.

# User-assigned : créer l'identité, puis l'assigner à une VM et à une web app
az identity create --resource-group rg-app-prd --name id-app-prd
az vm identity assign --resource-group rg-app-prd --name vm-app-prd --identities id-app-prd
az webapp identity assign --resource-group rg-app-prd --name app-web-prd \
  --identities /subscriptions/<sub>/resourceGroups/rg-app-prd/providers/Microsoft.ManagedIdentity/userAssignedIdentities/id-app-prd

# System-assigned sur une VM existante
az vm identity assign --resource-group rg-app-prd --name vm-app-prd

4. Accéder à d'autres ressources avec une managed identity#

4.1 Vers une ressource Azure : un rôle RBAC#

La managed identity reçoit un rôle Azure RBAC sur la ressource cible (Key Vault Secrets User, Storage Blob Data Reader…), puis le code obtient un jeton. Sur une VM, le jeton vient de l'Instance Metadata Service (IMDS), joignable seulement depuis la VM :

# Jeton pour Azure Resource Manager ; l'en-tête Metadata: true est obligatoire (protection contre le SSRF)
curl -H Metadata:true \
  "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"
# Avec plusieurs user-assigned identities, préciser client_id, object_id ou msi_res_id

En pratique, le code utilise le SDK (DefaultAzureCredential d'Azure.Identity) qui fait cet appel. Le paramètre resource doit correspondre exactement à ce qu'attend Entra (slash final compris pour Resource Manager).

4.2 Vers Microsoft Graph ou une API maison : un app role#

Une managed identity n'a pas d'App registration : pas de blade API permissions pour lui ajouter User.Read.All. On crée directement l'appRoleAssignment (une application permission) sur le service principal de l'API cible :

Connect-MgGraph -Scopes "Application.Read.All","AppRoleAssignment.ReadWrite.All"
$mi    = Get-MgServicePrincipal -Filter "displayName eq 'id-app-prd' and servicePrincipalType eq 'ManagedIdentity'"
$graph = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'"   # Microsoft Graph
$role  = $graph.AppRoles | Where-Object { $_.Value -eq "User.Read.All" -and $_.AllowedMemberTypes -contains "Application" }

New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $graph.Id `
  -PrincipalId $mi.Id -ResourceId $graph.Id -AppRoleId $role.Id

Points d'examen :

• AppRoleAssignment.ReadWrite.All permet d'élever les privilèges de n'importe quelle application : à réserver à des administrateurs de confiance ;
• consentir à des application permissions Microsoft Graph demande un rôle au-dessus de Cloud Application Administrator : Privileged Role Administrator (Microsoft indique qu'en pratique le Global Administrator est souvent nécessaire) ;
• les jetons d'une managed identity sont mis en cache : un changement de rôle peut mettre du temps à s'appliquer ;
• le même mécanisme sert pour une API interne : on assigne à la managed identity un app role déclaré avec Allowed member types = Applications (section 16).

5. Enterprise applications : réglages de l'application et du tenant#

5.1 Réglages de l'application (Enterprise apps > application > Properties)#

Assignment required ne s'applique qu'aux applications SAML, OpenID Connect, OAuth 2.0, WS-Federation, Application Proxy avec pre-authentication Microsoft Entra, et aux applications pour lesquelles d'autres applications demandent des jetons. Pour certaines applications, l'option n'apparaît pas dans le portail : on règle la propriété appRoleAssignmentRequired par PowerShell.

$sp = Get-MgServicePrincipal -Filter "displayName eq 'Salesforce'"
Update-MgServicePrincipal -ServicePrincipalId $sp.Id -AppRoleAssignmentRequired:$true

5.2 Réglages du tenant#

Les anciens réglages My Apps preview et My Staff ne sont plus utilisés par le service et disparaissent du portail.

6. Les rôles pour gérer les applications#

Élévation de privilège : Application Administrator et Cloud Application Administrator peuvent ajouter des credentials à une application et s'en servir pour agir avec ses droits. Si l'application a des permissions fortes (créer des users…), le rôle devient de fait plus puissant qu'il n'y paraît : à protéger avec PIM (chapitre 09). Les créateurs d'une application ne deviennent pas owners quand ils ont ces rôles.

Le moindre privilège par tâche, selon Microsoft :

7. Microsoft Entra Application Proxy#

7.1 Le principe#

Application Proxy publie une application web on-premises (ou dans un cloud privé) pour des utilisateurs distants, sans VPN ni reverse proxy en DMZ :

1. l'utilisateur ouvre l'External URL (ou My Apps) et s'authentifie dans Microsoft Entra ID (pre-authentication, avec Conditional Access et MFA) ;
2. le service Application Proxy, dans le cloud, reçoit la requête avec le jeton ;
3. le Microsoft Entra private network connector, installé sur un Windows Server du réseau interne, a ouvert des connexions sortantes (ports 80 et 443) vers le service : il récupère la requête ;
4. le connector fait le SSO pour l'utilisateur (Kerberos, en-têtes…) et appelle l'Internal URL ;
5. la réponse revient par le même chemin.

Le connector est le même que celui de Microsoft Entra Private Access (chapitre 06, SC-500 06 § 6) ; il se télécharge dans Global Secure Access > Connect > Connectors.

7.2 Prérequis et composants#

Les applications Application Proxy n'utilisent plus de client secret (CWAP_AuthSecret) : avec la pre-authentication Microsoft Entra, un federated identity credential le remplace (il n'expire pas). Depuis le 30 juin 2026, l'admin consent pour la permission déléguée User.Read n'est plus accordé automatiquement aux nouvelles applications Application Proxy : l'accorder après la création. À la création, Assignment required est mis à Yes par défaut. Ne pas modifier l'App registration d'une application Application Proxy (public client flows, federated credentials, API permissions) et la supprimer depuis Enterprise apps, pas depuis App registrations.

7.3 Publier une application#

Enterprise apps > New application > On-premises application (ou application existante > Application proxy) :

Passthrough : aucune authentification Entra avant d'atteindre l'application, donc pas de Conditional Access, pas de MFA, pas de SSO. Passer de Passthrough à Microsoft Entra ID sécurise aussi l'External URL en HTTPS.

7.4 Les modes de SSO d'une application Application Proxy#

Dépannage KCD : enregistrement DNS de type A (pas CNAME) pour l'application, délégation du connector vers le bon SPN, journaux du connector (Applications and Services Logs > Microsoft > Microsoft Entra private network > Connector > Admin, événements 13019 ou 12027). Un connector configuré en SPNEGO (applications non Windows) doit l'être comme tous les connectors de son groupe.

flowchart TD
    A{"Application on-premises<br/>pour des utilisateurs distants ?"} -- Non --> Z["Accès interne : pas d'Application Proxy<br/>moderniser l'app vers OIDC / SAML"]
    A -- Oui --> B{"Accès web (HTTP/HTTPS)<br/>à une application précise ?"}
    B -- Non --> P["Microsoft Entra Private Access<br/>(TCP/UDP, mêmes connectors)"]
    B -- Oui --> C{"Authentification de l'app"}
    C -- "IWA, Kerberos" --> K["Application Proxy + KCD"]
    C -- "En-têtes HTTP" --> H["Application Proxy + header-based"]
    C -- "SAML" --> S["Application Proxy + SAML"]
    C -- "Formulaire" --> W["Application Proxy + password-based"]

8. Intégrer une application SaaS#

8.1 Gallery, non-gallery et choix du SSO#

Une application de la Microsoft Entra application gallery arrive préconfigurée (SSO, souvent provisioning) ; pour une application absente, on crée une non-gallery application. Microsoft recommande de créer les applications SAML depuis la gallery.

8.2 Configurer le SSO SAML#

Enterprise apps > application > Single sign-on > SAML :

Rotation du certificat : New Certificate (une date entre aujourd'hui et 3 ans, non modifiable ensuite) > Save > télécharger le certificat ou les metadata pour l'éditeur > Make certificate active > retirer l'ancien. Entra envoie une notification 60, 30 et 7 jours avant l'expiration, à cinq adresses au plus (utiliser une liste de distribution). Les jetons OIDC et OAuth, eux, sont signés par une clé globale d'Entra.

Le claim UPN fait partie des SAML restricted claims : sans clé de signature personnalisée, on l'ajoute en optional claim dans l'App registration (Token configuration > Add optional claim > SAML > upn). Les réglages d'Attributes & Claims peuvent écraser les optional claims.

8.3 Le provisioning automatique (SCIM)#

Enterprise apps > application > Provisioning :

9. Users, groups et app roles d'une Enterprise application#

Enterprise apps > application > Users and groups > Add user/group : choisir les users ou groups, puis un app role (par défaut User ou Default Access si l'application n'en déclare pas). Points clés :

• l'assignation par groupe demande P1 ou P2, et les groupes imbriqués ne sont pas pris en compte ;
• quand l'application déclare des app roles pour Users/Groups, chaque assignation doit en choisir un : prévoir un rôle de base sans privilège (par exemple User) à côté des rôles élevés ;
• les app roles assignés arrivent dans le claim roles du jeton ; ajouter un service principal à un groupe puis assigner ce groupe à un app role ne donne pas de claim roles au service principal ;
• « classer » les accès se fait par ces app roles (qui fait quoi dans l'application) et, côté consentement, par les permission classifications (section 10).

$sp   = Get-MgServicePrincipal -Filter "displayName eq 'Contoso Orders'"
$role = $sp.AppRoles | Where-Object Value -eq "Orders.Manager"
$grp  = Get-MgGroup -Filter "displayName eq 'GRP-Orders-Managers'"
New-MgGroupAppRoleAssignment -GroupId $grp.Id -PrincipalId $grp.Id -ResourceId $sp.Id -AppRoleId $role.Id

Pour retirer l'accès : supprimer l'assignation, désactiver la connexion (Enabled for users to sign in = No) ou supprimer l'Enterprise application.

10. User consent et admin consent côté administrateur#

Les principes (user consent, admin consent, réglages, classifications, admin consent workflow) sont en SC-500 01 § 6. Ce qu'ajoute le niveau administrateur :

10.1 Régler le consentement#

Un reviewer peut voir, bloquer ou refuser une demande, mais n'approuve que ce que son rôle lui permet de consentir : seuls les Global Administrators approuvent les demandes d'application permissions Microsoft Graph. Les demandes apparaissent dans Enterprise apps > Admin consent requests > My Pending.

10.2 Accorder un admin consent pour tout le tenant#

Enterprise apps > application > Permissions > Grant admin consent for {tenant}, ou App registrations > application > API permissions > Grant admin consent. Obligatoire pour les application permissions et pour toute application dont Assignment required est à Yes.

10.3 Examiner et révoquer#

Enterprise apps > application > Permissions : onglet Admin consent (révocable depuis le portail) et onglet User consent (révocable seulement par Microsoft Graph ou PowerShell).

# Délégations accordées à l'application (consentType AllPrincipals = admin consent, Principal = un user)
$sp = Get-MgServicePrincipal -Filter "displayName eq 'Appli suspecte'"
Get-MgOauth2PermissionGrant -Filter "clientId eq '$($sp.Id)'" | Format-List ConsentType, PrincipalId, Scope

# Révoquer une délégation, et les application permissions (appRoleAssignments)
Get-MgOauth2PermissionGrant -Filter "clientId eq '$($sp.Id)'" | ForEach-Object { Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId $_.Id }
Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id |
  ForEach-Object { Remove-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id -AppRoleAssignmentId $_.Id }

Révoquer ne coupe pas les access tokens déjà émis (valables jusqu'à leur expiration) et n'empêche pas l'utilisateur de reconsentir : bloquer l'application (Enabled for users to sign in = No), durcir les user consent settings ou retirer la demande de permission dans l'application. La surveillance des applications OAuth à risque se fait aussi avec Defender for Cloud Apps (chapitre 08).

11. Les collections de My Apps#

Par défaut, My Apps affiche toutes les applications d'un utilisateur sur une page (950 applications accessibles au plus). Une collection regroupe des applications (par métier, projet, tâche) dans un onglet à part ; c'est un filtre : l'utilisateur ne voit dans la collection que les applications qui lui sont assignées.

Pour qu'une application y apparaisse : Visible to users = Yes, une assignation et une Homepage URL.

12. Planifier les app registrations#

App management policies (gratuites) : une politique par défaut du tenant (defaultAppManagementPolicy) et des politiques personnalisées assignables à des applications. Elles peuvent bloquer l'ajout de mots de passe, limiter la durée de vie des mots de passe ou des certificats (Block password addition, Block custom passwords, Restrict max password lifetime, Restrict max certificate lifetime, blocage des identifier URIs non sûrs). Portail : Entra ID > Enterprise apps > Application policies ; API policies/defaultAppManagementPolicy (permission Graph Policy.ReadWrite.ApplicationConfiguration). Les politiques personnalisées ne se voient que par Microsoft Graph.

13. Créer une app registration#

Portail : Entra ID > App registrations > New registration > nom, Supported account types, redirect URI facultatif > Register. Le portail crée l'application object et le service principal du tenant ; l'application object ne peut pas être déplacé dans un autre tenant.

# Microsoft Graph PowerShell : application object puis service principal (deux objets distincts par l'API)
Connect-MgGraph -Scopes "Application.ReadWrite.All"
$app = New-MgApplication -DisplayName "app-orders-api" -SignInAudience "AzureADMyOrg"
New-MgServicePrincipal -AppId $app.AppId

# Azure CLI
az ad app create --display-name app-orders-api --sign-in-audience AzureADMyOrg
az ad sp create --id <appId>

14. Configurer l'authentification de l'application#

App registrations > application > Authentication :

Autres réglages :

• Allow public client flows (Advanced settings) : à activer seulement pour les flux de client public qui l'exigent, comme ROPC (identifiants envoyés dans la requête, incompatible avec la MFA) ;
• Implicit grant : à éviter ; Microsoft recommande le flux authorization code avec PKCE pour les SPA ;
• Certificates & secrets : federated credentials (GitHub Actions, Kubernetes, managed identity ; 20 au plus par application ou par user-assigned managed identity, tous types confondus ; le couple issuer + subject doit être unique), certificates, client secrets ;
• Token configuration : optional claims (upn, ipaddr, auth_time, amr…) et groups claim (Security groups, Directory roles, All groups, Groups assigned to the application). Limite : 150 groupes dans une assertion SAML, 200 dans un JWT ; au-delà, choisir Groups assigned to the application ou passer par les app roles. emit_as_roles place les groupes dans le claim roles (les app roles assignés n'y figurent alors plus).

15. Configurer les API permissions et exposer une API#

15.1 Demander des permissions (application cliente)#

App registrations > application > API permissions > Add a permission > Microsoft Graph, APIs my organization uses ou My APIs > Delegated permissions ou Application permissions, puis Grant admin consent si nécessaire.

Les permissions déclarées ici sont demandées ; elles ne sont accordées qu'au consentement, enregistré sur l'Enterprise application (onglet Permissions). Une permission demandée mais jamais consentie n'est pas dans le jeton.

15.2 Exposer une API (application qui protège l'API)#

App registrations > API > Expose an API :

Pour les clients, les scopes de l'API apparaissent comme delegated permissions et les app roles avec Allowed member types = Applications comme application permissions. Les scopes et app roles partagent une limite de 700 définitions de permissions par application.

sequenceDiagram
    participant C as Application web (client)
    participant E as Microsoft Entra ID
    participant A as Web API (Orders)
    C->>E: Authorization code + scope api://orders/Orders.Read
    E-->>C: Access token (aud = API, scp = Orders.Read)
    C->>A: Appel avec le jeton
    A->>A: Vérifie aud, issuer, scp
    Note over C,A: Daemon : client credentials, scope api://orders/.default, claim roles

16. Créer des app roles#

App registrations > application > App roles > Create app role :

Ensuite, Enterprise apps > application > Users and groups pour assigner des users et groups à un rôle (section 9), ou un appRoleAssignment pour une application ou une managed identity (section 4.2).

Points d'examen :

• application qui connecte des utilisateurs : le claim roles arrive dans l'ID token ; application qui appelle une API : dans l'access token, et les rôles se définissent et s'assignent sur l'App registration de l'API ;
• un app role désactivé n'est plus assignable, mais les assignations existantes restent et le rôle continue d'apparaître dans les jetons : retirer les assignations ;
• les app roles évitent le dépassement du nombre de groupes dans les jetons et le mappage d'ID de groupes dans le code.

17. Labs conseillés#

À faire dans un tenant de test (essai Microsoft Entra ID P2 pour Application Proxy et les collections) et un abonnement de test.

Lab 1 · Managed identity vers Microsoft Graph (30 min, coût d'une petite VM pendant le lab)

1. Créer une VM Linux et activer sa system-assigned managed identity.
2. Avec Graph PowerShell, lui assigner l'app role User.Read.All de Microsoft Graph (section 4.2).
3. Depuis la VM, obtenir un jeton IMDS avec resource=https://graph.microsoft.com/ et appeler GET /v1.0/users?$top=1.
4. Résultat attendu : la liste renvoie un user ; le jeton décodé contient roles: ["User.Read.All"]. Supprimer la VM ensuite.

Lab 2 · Enterprise application SAML (30 min, gratuit)

1. Ajouter Microsoft Entra SAML Toolkit depuis la gallery, configurer Identifier et Reply URL.
2. Assigner un user de test, passer Assignment required à Yes, essayer avec un user non assigné.
3. Créer un nouveau certificat avec une date d'expiration plus courte, l'activer, ajouter une adresse de notification.
4. Résultat attendu : le user non assigné reçoit une erreur d'assignation ; le certificat actif change.

Lab 3 · Application Proxy (45 min, une VM Windows Server)

1. Installer le private network connector sur une VM Windows avec IIS (site interne), dans un connector group dédié.
2. Publier le site avec pre-authentication Microsoft Entra ID, accorder l'admin consent User.Read, assigner un user.
3. Ouvrir l'External URL depuis un poste externe, puis passer en Passthrough et constater l'absence de Conditional Access.
4. Résultat attendu : authentification Entra puis site IIS ; aucune règle entrante dans le NSG. Supprimer la VM ensuite.

Lab 4 · API protégée, scope et app role (40 min, gratuit)

1. Inscrire une API : Application ID URI, scope Orders.Read (Admins and users), app role Orders.ReadAll (Applications).
2. Inscrire un client daemon, lui ajouter l'application permission Orders.ReadAll, accorder l'admin consent.
3. Obtenir un jeton client credentials (api://{clientId}/.default) et le décoder.
4. Résultat attendu : claim roles = Orders.ReadAll, pas de scp.

Lab 5 · Consentement et collections (20 min, P1 pour les collections)

1. Régler le user consent sur verified publishers, selected permissions, classer User.Read en Low, activer l'admin consent workflow avec un reviewer.
2. Faire une demande depuis un user pour une application qui demande Mail.Read ; la traiter.
3. Créer une collection Finance avec deux applications et l'assigner à un groupe.
4. Résultat attendu : demande visible dans My Pending ; collection visible dans My Apps pour le groupe.

18. Pièges d'examen#

19. Scénarios corrigés#

1. La Function func-rh doit lire les profils des utilisateurs dans Microsoft Graph sans aucun secret. Que faire ?

Activer une managed identity sur la Function, puis lui assigner l'app role User.Read.All de Microsoft Graph avec New-MgServicePrincipalAppRoleAssignment (une application permission ; consentement réservé à Privileged Role Administrator ou Global Administrator). Pas d'App registration à créer.

2. Un administrateur avec le rôle Cloud Application Administrator doit publier l'intranet SharePoint on-premises pour les commerciaux en déplacement, avec SSO Windows. Que lui manque-t-il et que configurer ?

Le rôle Application Administrator (Cloud Application Administrator ne gère pas Application Proxy) et une licence P1/P2. Installer deux private network connectors dans un connector group, publier l'Internal URL avec pre-authentication Microsoft Entra ID, SSO Integrated Windows authentication avec le SPN HTTP/sharepoint et la délégation KCD des connectors.

3. Les utilisateurs se plaignent : une application SaaS demande sans cesse un consentement depuis que l'équipe a passé Assignment required à Yes. Cause et solution ?

Quand l'assignation est requise, le user consent n'est plus possible : accorder l'admin consent pour tout le tenant à l'application (Permissions > Grant admin consent).

4. Une application OAuth malveillante a obtenu Mail.Read par le consentement de plusieurs utilisateurs. Quelles actions, dans l'ordre ?

Mettre Enabled for users to sign in à No (plus aucun jeton), révoquer les délégations par PowerShell (Remove-MgOauth2PermissionGrant, l'onglet User consent ne permet pas la révocation), puis durcir les user consent settings (éditeurs vérifiés, permissions à faible impact) et activer l'admin consent workflow. Les jetons déjà émis restent valables jusqu'à expiration.

5. Le certificat SAML de l'application de paie expire dans 20 jours. Comment le renouveler sans coupure ?

SAML Certificates > New Certificate (inactif), télécharger les Federation Metadata pour l'éditeur, attendre qu'il ait importé le nouveau certificat, puis Make certificate active et retirer l'ancien. Ajouter une liste de distribution aux adresses de notification.

6. Les nouveaux salariés n'apparaissent pas dans l'application SaaS alors que le provisioning est en mode Automatic. Que vérifier ?

Qu'ils sont assignés à l'application (directement ou par un groupe non imbriqué), le scope Sync only assigned users and groups, les scoping filters, l'état du job (quarantine ?) et les provisioning logs ; tester avec Provision on demand. Les cycles incrémentaux passent environ toutes les 40 minutes.

7. Une API interne doit être appelée par un daemon sans utilisateur, et par une application web au nom des utilisateurs. Comment la déclarer ?

Sur l'App registration de l'API : Expose an API (Application ID URI, scope Orders.Read pour l'application web, claim scp) et un app role Orders.ReadAll avec Allowed member types = Applications pour le daemon (application permission, claim roles, admin consent). Le daemon demande api://{clientId}/.default en client credentials.

8. Le RSSI veut interdire les client secrets sur toutes les nouvelles applications. Solution native ?

Une app management policy (politique par défaut du tenant) qui bloque l'ajout de mots de passe et, au besoin, limite la durée des certificats. Fonction gratuite.

9. L'entreprise veut appliquer une stratégie Conditional Access à un service principal (bloquer hors d'une plage d'IP). Que faut-il ?

Microsoft Entra Workload ID Premium ; la stratégie vise les applications single-tenant (pas les managed identities ni les applications Microsoft).

10. L'équipe Finance veut voir ses quinze applications regroupées dans My Apps. Que configurer et avec quelle licence ?

Une collection (Enterprise apps > App launchers > Collections) avec les applications, assignée au groupe Finance ; licence P1 ou P2 ; les applications doivent être assignées au groupe et visibles.

11. Un service Windows tourne sur trois serveurs IIS joints au domaine et accède à un partage on-premises. Quelle identité ?

Un group managed service account (gMSA) : compte AD DS dont les contrôleurs de domaine gèrent le mot de passe, utilisable sur plusieurs serveurs. Ni managed identity (Azure) ni compte utilisateur.

12. Après avoir désactivé un app role, un administrateur constate que les utilisateurs le reçoivent encore dans leurs jetons. Pourquoi ?

Désactiver un app role empêche seulement les nouvelles assignations ; les assignations existantes restent et le rôle continue d'arriver dans les jetons. Il faut retirer les assignations, puis supprimer le rôle.

20. Pour aller plus loin#

• Conditional Access pour workload identities et ID Protection pour workload identities (risques comme des credentials divulgués) : chapitre 06 et Securing workload identities.
• App Health Recommendations (Workload ID Premium) : repérer les applications inutilisées ou aux credentials expirés.
• Microsoft Entra Agent ID : les agents d'IA ont leur propre type d'identité (agent identity blueprint), créé par défaut par les users tant que Users can create agent blueprints n'est pas à No ; voir SC-500 07.
• Application Proxy avec Azure Front Door pour accélérer l'accès géographiquement, et connectors déployables depuis les marketplaces Azure, AWS et GCP (préversion).
• Infrastructure as Code : App registrations, service principals et federated credentials se gèrent avec le fournisseur Terraform azuread ou Microsoft Graph, ce qui facilite la revue des permissions.

21. Fiche à retenir#

• Workload identities = applications, service principals, managed identities ; une managed identity n'a pas d'App registration.
• Préférence : managed identity > federated credential > certificate > secret ; gMSA pour un service Windows on-premises ; jamais un compte utilisateur.
• User-assigned : Managed Identity Contributor pour créer, Managed Identity Operator pour assigner.
• IMDS 169.254.169.254, en-tête Metadata: true, paramètre resource exact ; Graph pour une MI : New-MgServicePrincipalAppRoleAssignment.
• Enabled for users to sign in = No coupe tous les jetons ; Assignment required limite l'accès et bloque le user consent ; Visible to users ne protège rien.
• Assignation par groupe : P1/P2, pas de groupes imbriqués.
• Application Administrator = tout + Application Proxy ; Cloud Application Administrator = tout sauf Application Proxy ; Application Developer = créer des App registrations ; Graph app permissions = Privileged Role Administrator.
• Application Proxy : P1/P2, connector sortant (80/443), 2 connectors par connector group, même connector que Private Access, Passthrough = pas de Conditional Access, KCD pour IWA, header-based, pas pour les internes.
• SAML : Identifier, Reply URL, NameID = UPN par défaut, certificat SHA-256 3 ans max, notifications 60/30/7 jours, 5 adresses.
• Provisioning SCIM : assignés seulement, mappings et scoping filters, ~40 min, quarantine (4 semaines = désactivé).
• Consentement : user consent settings (Global Administrator), classifications Low, admin consent workflow (reviewer sans droit ajouté) ; révoquer un user consent = Graph/PowerShell.
• Collections My Apps : P1/P2, App launchers > Collections, filtre des applications assignées.
• signInAudience : AzureADMyOrg, AzureADMultipleOrgs, AzureADandPersonalMicrosoftAccount, PersonalMicrosoftAccount.
• Authentication : platforms Web, SPA (PKCE), mobile/desktop ; implicit grant à éviter ; public client flows seulement si nécessaire.
• Expose an API : api://{clientId}, scopes (Who can consent), Authorized client applications ; scopes = delegated, app roles Applications = application permissions.
• App roles : Users/Groups ou Applications, claim roles ; désactiver ne retire pas des jetons ; 700 définitions maximum avec les scopes.
• Groups claim : 150 (SAML), 200 (JWT) ; Groups assigned to the application pour les gros tenants.
• App management policies (gratuites), app instance property lock (activé par défaut depuis juin 2026), Workload ID Premium pour Conditional Access et ID Protection des workload identities.

Références#

Toutes lues le 21/10/2026 sur Microsoft Learn :

• Study guide for Exam SC-300
• What are workload identities?
• Frequently asked questions about Microsoft Entra Workload ID
• Manage group Managed Service Accounts
• Assign an application role to a managed identity using PowerShell
• How to use managed identities for Azure resources on an Azure VM to acquire an access token
• Properties of an enterprise application
• Configure enterprise application properties
• Manage access to an application
• Microsoft Entra built-in roles
• Least privileged roles by task in Microsoft Entra ID
• Delegate app registration permissions in Microsoft Entra ID
• Microsoft Entra application proxy
• Plan a Microsoft Entra application proxy deployment
• Add an on-premises application for remote access through application proxy
• Microsoft Entra application proxy frequently asked questions
• Microsoft Entra private network connectors
• How to configure private network connectors
• Kerberos Constrained Delegation for single sign-on with application proxy
• Header-based single sign-on with application proxy
• Troubleshoot Kerberos constrained delegation
• Plan a single sign-on deployment
• Tutorial: Manage certificates for federated single sign-on
• Application Management certificates frequently asked questions
• Customize SAML token claims
• Plan an automatic user provisioning deployment
• Application provisioning in quarantine status
• Configure how users consent to applications
• Configure the admin consent workflow
• Review permissions granted to enterprise applications
• Grant and revoke API permissions in Microsoft Entra ID (PowerShell)
• Create collections on the My Apps portal
• My Apps portal overview
• Register an application in Microsoft Entra ID
• Modify the accounts supported by an application
• How to configure app instance property lock
• Configure restrictions on how applications can be configured (app management policies)
• How to add a redirect URI to your application
• Configure and manage optional claims
• Configure an application to expose a web API
• Expose scopes in a protected web API
• Add app roles to your application and receive them in the token