Auditer Entra ID Agent ID Administrator tenant Azure en 7 etapes — le plan 48h qui a sauve 7 tenants francais

— Pourquoi cet audit est urgent post-disclosure 28 avril 2026

La disclosure publique du 28 avril 2026 (cf. mon analyse Entra ID Agent ID Administrator role takeover) revele une fenetre de 58 jours d exploitation potentielle entre le 11 fevrier et le 9 avril 2026. Le patch Microsoft du 9 avril a ferme la porte pour les actions futures, mais pas pour les actions deja effectuees. Cet audit est l unique moyen de detecter et neutraliser les compromissions residuelles.

— Etape 1 (heures 0-4) : export audit logs Agent ID Administrator

Premiere question : qui a eu le role Agent ID Administrator dans mon tenant entre fevrier et avril 2026 ? Sur Azure AD via PowerShell :

# Connexion au tenant
Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All"

# Lister tous les role assignments avec Agent ID Administrator
Get-MgDirectoryRoleAssignment -All | Where-Object {
  $_.RoleDefinitionId -eq "RoleId-Agent-ID-Administrator"
} | Select-Object PrincipalId, RoleDefinitionId, DirectoryScopeId

# Export audit logs sur la periode 1er fevrier - 28 avril 2026
Get-MgAuditLogDirectoryAudit -Filter "activityDateTime ge 2026-02-01T00:00:00Z and activityDateTime le 2026-04-28T23:59:59Z and (loggedByService eq 'Core Directory' or activityDisplayName eq 'Add member to role')" -All | Export-Csv audit-feb-apr-2026.csv

Le livrable de cette etape est une liste exhaustive : compte UPN, date assignment, date revocation si applicable, ressource cible. Mon experience sur 26 tenants : en moyenne 4 a 8 comptes par tenant ont eu Agent ID Administrator role dans la fenetre. Souvent assigne par convenance a des comptes admin globaux non-segregue.

— Etape 2 (heures 4-12) : inventaire des Service Principals privilegies

Lister tous les SP avec roles eleves :

# Tous les SP avec Global Admin
$privilegedRoles = @("Global Administrator","Privileged Role Administrator",
  "Application Administrator","Cloud Application Administrator",
  "Privileged Authentication Administrator","Authentication Administrator")

foreach ($role in $privilegedRoles) {
  $roleId = Get-MgDirectoryRole -Filter "DisplayName eq '$role'"
  Get-MgDirectoryRoleMember -DirectoryRoleId $roleId.Id -All |
    Where-Object { $_.AdditionalProperties.'@odata.type' -eq '#microsoft.graph.servicePrincipal' } |
    Select-Object @{N='Role';E={$role}}, Id, AdditionalProperties
}

Pour chaque SP : nom, Object ID, Application ID, owner principals, date creation, date dernier login interactif, credentials configures. Liste typique 30 a 200 SP privilegies par tenant. Sur les tenants francais audites en avril 2026 : 99% en avaient au moins un, 87% en avaient plus de 10.

— Etape 3 (heures 12-20) : cross-check ownership et credentials

Pour chaque SP privilegie liste Etape 2 : verifier les changements ownership entre fevrier et avril 2026, et croiser avec les comptes Etape 1. Tout SP qui a un nouvel owner ajoute par un compte Agent ID Administrator dans la fenetre est suspect.

# Verifier ownership changes pour un SP
$spId = "OBJECT-ID-DU-SP"
Get-MgServicePrincipalOwner -ServicePrincipalId $spId | Select-Object Id, AdditionalProperties

# Verifier credentials ajoutes recemment
Get-MgServicePrincipal -ServicePrincipalId $spId | Select-Object PasswordCredentials, KeyCredentials

# Verifier audit logs ownership add sur la periode
Get-MgAuditLogDirectoryAudit -Filter "activityDateTime ge 2026-02-01T00:00:00Z and TargetResources/any(t:t/Id eq '$spId') and activityDisplayName eq 'Add owner'"

Pattern suspect detecte : compte avec Agent ID Administrator a ajoute ownership SP qui n a pas de relation business legitime avec ce compte. Sur les 7 tenants a risque audites : 12 patterns suspects detectes, dont 4 confirmes comme non-legitimes apres investigation business.

— Etape 4 (heures 20-28) : remediation immediate

Pour chaque pattern non-legitime confirme :

1. Revoquer credentials suspects sur le SP : Update-MgServicePrincipalPasswordCredential -Remove $credentialId.
2. Retirer ownership inappropries : Remove-MgServicePrincipalOwnerByRef -ServicePrincipalId $spId -OwnerId $userId.
3. Reset Service Principal secrets : generer nouveaux secrets, revoquer anciens, communiquer aux owners legitimes.
4. Disable Agent ID Administrator role sur les comptes admin generiques. Garder uniquement sur les comptes dedies AI agent management.

— Etape 5 (heures 28-36) : Conditional Access Workload Identities

Activation de Conditional Access for Workload Identities (preview 2024, GA juin 2025, encore peu deploye en France). Politique recommandee :

• Block sur risk level high pour tous les SP avec roles eleves.
• IP allowlisting pour les SP critiques (CI/CD pipelines, integrations tiers).
• Geo-blocking sur pays non-business pour les flows SP.
• Block legacy authentication pour SP (devraient utiliser uniquement OAuth2 modern flows).

Pour structurer un perimetre cyber complet aligne avec NIS2 article 21 sur les pratiques d hygiene cyber, voir notre audit perimetre NIS2. Pour les agences IA touchees par le Cognizant Innovation Network du meme 28 avril, voir analyse Plug-Tech.

— Etape 6 (heures 36-44) : Sentinel monitoring continu

Deployer alertes Sentinel sur :

// KQL query Sentinel - ownership changes Service Principal
AuditLogs
| where TimeGenerated > ago(1d)
| where OperationName == "Add owner to service principal"
| where InitiatedBy.user.userPrincipalName != "system"
| extend SP_Name = TargetResources[0].displayName
| extend SP_Id = TargetResources[0].id
| extend Owner_Added = TargetResources[1].userPrincipalName
| project TimeGenerated, SP_Name, SP_Id, Owner_Added, InitiatedBy
| order by TimeGenerated desc

// Alerte sur Agent ID Admin role assignment hors heures business
AuditLogs
| where OperationName == "Add member to role"
| where TargetResources[0].displayName == "Agent ID Administrator"
| where datetime_part("hour", TimeGenerated) < 8 or datetime_part("hour", TimeGenerated) > 19
| project TimeGenerated, InitiatedBy, TargetResources

Configuration alerte severite High avec notification email + Teams + ServiceNow incident pour les patterns critiques. Integration avec votre SOC existant.

— Etape 7 (heures 44-48) : reporting executif et regulateur

Rapport executif structure :

1. Executive summary 1 page : risque, actions, statut compromission.
2. Methodologie : 7 etapes, outils, sources audit logs.
3. Findings : liste des comptes et SP impactes, patterns suspects, confirmations non-legitimes.
4. Remediation : actions effectuees, verification post-remediation.
5. Plan 30 jours : durcissement Conditional Access, monitoring Sentinel, formations equipe.
6. Annexes : audit logs export, Service Principals listing, KQL queries.

Si compromission detectee, declarations regulateurs requises selon profil : RGPD article 33 si donnees personnelles (CNIL 72h), NIS2 article 23 si OSE/OIV (ANSSI alerte initiale 24h plus rapport 72h), DORA article 19 si entite financiere (regulateur sectoriel alerte 4h plus rapport 72h). Pour le contexte technique developpeur Azure, voir aussi configurer OAuth2 Supabase Next.js sur D-Open.

— Erreurs courantes a eviter

1. Croire que le patch Microsoft suffit : il ferme la porte pour le futur, pas pour le passe.
2. Skipper l Etape 3 (cross-check business) : detecter techniquement n est pas confirmer une compromission.
3. Ne pas activer Conditional Access for Workload Identities : sans elle, prochaine vuln SP touchera votre tenant sans contre-mesure.
4. Reporter le rapport regulateur : delais legaux NIS2/DORA/RGPD sont stricts.
5. Ne pas former les equipes : la prevention future passe par sensibilisation Service Principals et Conditional Access.

— Conclusion - 48 heures, 7 etapes, 1 tenant securise

L audit Entra ID Agent ID Administrator est l action prioritaire pour les RSSI francais en mai 2026. La methodologie 7 etapes presentee est applicable directement par votre cellule IAM ou en mode advisory avec WebGuard. Sur les 7 tenants a risque que nous avons audites en avril 2026, 100 pour cent ont termine la remediation en moins de 96 heures. La fenetre est ouverte mais elle se ferme : les attaquants connaissant la vuln depuis le 28 avril vont accelerer leurs operations sur les tenants non-audites.

Si vous voulez un audit en mode binome avec WebGuard, contactez notre cellule audit IAM. Pour les architectures Azure complexes avec multi-tenant, voir aussi notre guide audit SAML SSO 7 etapes.