Intune RBAC et scope tags : déléguer sans ouvrir tout le tenant

Position recommandée

Une role assignment associe un rôle built-in/custom, des Admin Groups, des Scope Groups et des Scope Tags. Les permissions de plusieurs assignments sont cumulatives et il n’existe pas de deny pour annuler un droit accordé ailleurs.

Les scope tags filtrent la visibilité d’objets Intune et de devices; ils ne remplacent pas les scope groups. Une assignment sans tag peut ouvrir une visibilité beaucoup plus large.

Je recommande des groupes administrateurs dédiés, rôles custom par persona, scope groups limités et tags par frontière opérationnelle. Chaque persona est testée avec un compte sans rôle Entra privilégié parasite.

Une role assignment associe un rôle built-in/custom, des Admin Groups, des Scope Groups et des Scope Tags. Les permissions de plusieurs assignments sont cumulatives et il n’existe pas de deny pour annuler un droit accordé ailleurs.

Besoin, cas d’usage et périmètre de la recommandation

Les rôles Intune built-in couvrent des personas génériques. Un rôle custom retire les permissions inutiles, notamment remote tasks, managed apps, enrollment ou security baselines.

Admin Groups contiennent les administrateurs. Scope Groups contiennent les users/devices qu’ils peuvent gérer ou cibler. Les groupes All users/devices doivent être utilisés seulement si la délégation le justifie.

Les scope tags sont ajoutés aux policies, apps et devices supportés. Un objet créé par un admin reçoit ses tags selon le comportement documenté; je vérifie ce résultat dans le runbook.

Critères de décision et options possibles

Pour RBAC et scope tags dans Intune, je commence par trois résultats concrets: Lister droits requis par persona, Créer rôle custom minimal et Définir Admin et Scope Groups. Ils doivent être observables avant de comparer les méthodes disponibles.

L’architecture cible suit Role → Admin group → Scope group → Scope tag. Chaque composant a un propriétaire clair, un état vérifiable et une méthode de retour arrière; cette répartition évite qu’une seconde politique masque le résultat de la première.

Le pilote contrôle notamment Lister droits requis par persona, Créer rôle custom minimal et Définir Admin et Scope Groups. La généralisation ne commence qu’après une période stable et après vérification des exceptions propres aux populations visées.

La recommandation devient mesurable lorsqu’elle relie le besoin à une cible vérifiable. Les résultats attendus sont Lister droits requis par persona, Créer rôle custom minimal et Définir Admin et Scope Groups. Les responsabilités se répartissent ainsi: Role: Actions Create/Read/Update/Delete. Admin group: Qui reçoit le rôle. Scope group: Quels users/devices sont gérables. Scope tag: Quels objets sont visibles. Cette répartition permet d’attribuer chaque écart au bon propriétaire et d’éviter qu’un second profil, une ancienne autorité ou une exception silencieuse ne produise un résultat apparemment correct mais impossible à exploiter dans la durée.

Les écarts « Admin voit trop », « Admin ne cible pas groupe », « Exclude refusé » et « Tag disparaît » servent de tests de décision. Pour chacun, la preuve indiquée dans la matrice doit permettre de choisir entre correction, exception temporaire et retour arrière. Le pilote surveille également les points suivants: permissions cumulatives sans deny, rôles Entra ne suivent pas scope tags Intune, assignment sans tag élargit la vue et tester avec comptes dédiés. La valeur cible, le mode de distribution, les contrôles et la sortie de secours sont ainsi évalués ensemble.

Architecture cible et répartition des responsabilités

Les rôles Intune built-in couvrent des personas génériques. Un rôle custom retire les permissions inutiles, notamment remote tasks, managed apps, enrollment ou security baselines.

Admin Groups contiennent les administrateurs. Scope Groups contiennent les users/devices qu’ils peuvent gérer ou cibler. Les groupes All users/devices doivent être utilisés seulement si la délégation le justifie.

Les scope tags sont ajoutés aux policies, apps et devices supportés. Un objet créé par un admin reçoit ses tags selon le comportement documenté; je vérifie ce résultat dans le runbook.

Prérequis, gouvernance et préparation

La préparation de RBAC et scope tags dans Intune couvre personas administratives, inventaire des rôles Entra/Intune, groupes admin dédiés, frontières géographiques/métier, scope groups fiables. Le propriétaire de chaque composant et la population pilote sont définis avant la création de la configuration.

L’état initial est mesuré avec Lister droits requis par persona. Créer rôle custom minimal. Définir Admin et Scope Groups. Créer/assigner Scope Tags. Il servira de point de comparaison pendant le pilote et lors d’un éventuel retour arrière.

• personas administratives
• inventaire des rôles Entra/Intune
• groupes admin dédiés
• frontières géographiques/métier
• scope groups fiables
• nomenclature tags
• comptes de test

Fonctionnement détaillé et frontières de responsabilité

Les rôles Intune built-in couvrent des personas génériques. Un rôle custom retire les permissions inutiles, notamment remote tasks, managed apps, enrollment ou security baselines.

Admin Groups contiennent les administrateurs. Scope Groups contiennent les users/devices qu’ils peuvent gérer ou cibler. Les groupes All users/devices doivent être utilisés seulement si la délégation le justifie.

Les scope tags sont ajoutés aux policies, apps et devices supportés. Un objet créé par un admin reçoit ses tags selon le comportement documenté; je vérifie ce résultat dans le runbook.

• personas administratives
• inventaire des rôles Entra/Intune
• groupes admin dédiés
• frontières géographiques/métier

Mise en œuvre, exploitation et cas limites

Les affectations automatiques de tags aux devices par groupe peuvent écraser les tags manuels. Plusieurs tags automatiques peuvent s’appliquer; leur modèle doit être stable.

Les permissions de plusieurs rôles sont cumulatives. Un rôle Entra comme Intune Administrator peut contourner le périmètre Intune attendu; je teste avec un compte dépourvu de ces rôles.

PIM group-based peut rendre l’élévation temporaire, avec un délai de propagation documenté. J’ajoute access reviews, justification, approbation et audit pour les actions sensibles.

• Tester lecture, création, ciblage et remote actions
• Tester cumul de plusieurs assignments
• Mettre en place revue et PIM

Méthode de validation à l’échelle du parc

Pour rbac et scope tags dans intune, je constitue un échantillon qui couvre au minimum deux modèles matériels, plusieurs profils utilisateur, un site réseau contraint et les exceptions métier connues. Un résultat homogène sur des machines de laboratoire identiques ne démontre pas la robustesse de la configuration.

Les mesures portent sur Lister droits requis par persona. Créer rôle custom minimal. Définir Admin et Scope Groups. Créer/assigner Scope Tags. Elles sont définies avant le pilote de RBAC et scope tags dans Intune afin que les seuils ne soient pas déplacés après l’observation.

Les cas « Admin voit trop », « Admin ne cible pas groupe », « Exclude refusé », « Tag disparaît » servent de scénarios négatifs. Ils vérifient que l’échec reste visible, localisable et associé à une correction précise.

La généralisation de RBAC et scope tags dans Intune tient compte de permissions cumulatives sans deny, rôles Entra ne suivent pas scope tags Intune, assignment sans tag élargit la vue, tester avec comptes dédiés. Chaque vague se ferme après lecture de ces points et validation du retour à l’état connu.

Configuration recommandée et déploiement par étapes

La méthode retenue pour RBAC et scope tags dans Intune se déploie par les étapes « Mesurer l’état initial », « Configurer le pilote », « Observer les indicateurs », « Décider la vague suivante ». Chaque passage produit un résultat vérifiable avant l’ouverture du suivant.

Paramètres, commandes et automatisation

Les commandes et valeurs de cette section servent à vérifier Lister droits requis par persona. Créer rôle custom minimal. Définir Admin et Scope Groups. Créer/assigner Scope Tags. Chaque exemple précise l’état attendu et les éléments à comparer dans le service.

Le contexte d’exécution, les permissions et les effets sur Role, Admin group, Scope group, Scope tag doivent rester explicites lorsque la configuration est automatisée.

# Collecte de diagnostic
$ErrorActionPreference = 'Stop'
try {
 $uri='https://graph.microsoft.com/v1.0/deviceManagement/roleAssignments?$expand=roleDefinition'
 $page=Invoke-MgGraphRequest -Method GET -Uri $uri
 $page.value | Select-Object id,displayName,scopeMembers,resourceScopes,@{n='Role';e={$_.roleDefinition.displayName}}
}
catch { Write-Error "Inventaire RBAC impossible : $($_.Exception.Message)"; exit 1 }

Validation, indicateurs et critères GO / NO-GO

La décision repose sur Lister droits requis par persona, Créer rôle custom minimal, Définir Admin et Scope Groups et Créer/assigner Scope Tags. Ces indicateurs couvrent le résultat technique, l’état du service et l’effet réel sur la population pilote.

• Lister droits requis par persona.
• Créer rôle custom minimal.
• Définir Admin et Scope Groups.
• Créer/assigner Scope Tags.
• Tester lecture, création, ciblage et remote actions
• Tester cumul de plusieurs assignments
• Mettre en place revue et PIM

Exploitation, journaux et contrôle continu

La chronologie de RBAC et scope tags dans Intune relie Role, Admin group, Scope group, Scope tag. Les heures et identifiants communs indiquent si les informations décrivent la même tentative.

Les états sont lus à partir de Lister droits requis par persona. Créer rôle custom minimal. Définir Admin et Scope Groups. Créer/assigner Scope Tags. Cette séquence sépare une absence de configuration d’un traitement en attente ou d’un échec confirmé.

Les causes « Assignment sans tag/rôle Entra », « Scope Group absent », « Groupe hors scope », « Auto assignment écrase manuel » restent des hypothèses jusqu’à ce que la preuve indiquée dans la matrice les confirme.

• Lister droits requis par persona.
• Créer rôle custom minimal.
• Définir Admin et Scope Groups.
• Créer/assigner Scope Tags.
• Tester lecture, création, ciblage et remote actions
• Tester cumul de plusieurs assignments
• Mettre en place revue et PIM

Exceptions, erreurs connues et traitement

Les exceptions à prévoir pour RBAC et scope tags dans Intune apparaissent notamment sous la forme Admin voit trop, Admin ne cible pas groupe, Exclude refusé, Tag disparaît. La preuve associée indique s’il faut corriger la configuration ou conserver une exception documentée.

Coût de maintien des exceptions

Une exception à RBAC et scope tags dans Intune crée une charge récurrente: elle doit être identifiée, surveillée et réévaluée jusqu’à sa suppression. Sans propriétaire ni date de revue, cette charge finit par devenir une configuration parallèle difficile à tester.

Rollback, gestion du changement et points de vigilance

Le rollback de RBAC et scope tags dans Intune restaure explicitement l’affectation, la valeur ou l’autorité précédente. Les actions et points de vigilance ci-dessous précisent ce qui doit être contrôlé après ce retour.