La société pour laquelle je travaille a récemment fait un gros pas en avant sur l’adoption d’Intune pour la gestion de nos postes windows 10. Travaillant à l’international avec un seul tenant Azure, nous avons rapidement été confronté à un soucis : comment permettre aux équipes pays d’administrer Intune, tout en limitant leurs droits à l’étendue de leurs seuls utilisateurs ? C’est là qu’RBAC (Role-Based access control) intervient.

La documentation écrite par Microsoft à ce sujet est assez claire si on prend le temps de regarder leurs vidéos, mais personellement je préfère toujours voir un petit TUTO écrit !

Les rôles dans Intune

Pour consulter les rôles d’administration présent dans votre tenant intune, dirigez vous vers la page devicemanagement.microsoft.com et accédez au menu « Tenant Admin » > « Intune roles | All roles ».

Sur cette page, on peut voir les différents rôles existants. On en trouve par défaut des « Built-in » qui ne peuvent pas être modifiés et dont vous trouverez la description ici.
Si vous souhaitez créer vos propres rôles d’administration, en mixant les permissions disponibles à votre convenance ou en restreignant l’étendue de celles ci, vous pouvez créer un rôle « Custom ».

Un rôle Custom est constitué des éléments suivants :

  • Nom : Bah, oui, c’est toujours mieux …
  • Autorisations – Permissions : L’ensemble des droits que vous souhaitez attribuer sur les fonctions d’intune
  • Etendue (balises) – Scope (tags) : La partie intéressante, les balises (tags en anglais) permettent d’étiqueter chaque ressources créée (Périphérique, politique, application …). En limitant un rôle custom à une ou plusieurs étiquettes, les utilisateurs ayant ce rôle ne pourront voir que les ressources portant ces étiquettes … et par là ne pourront agir que sur celles ci.

Une fois ces éléments définis, vous devez créer des assignations pour celui ci. Un rôle peut porter plusieurs assignations, et une assignation consiste en les éléments suivants :

  • Nom : Encore !
  • Membres : quels utilisateurs bénéficieront de cette assignation ? A noter que vous ne pouvez ajouter que des groupes de sécurité, pas directement des utilisateurs.
  • Etendue (Groupes) – Scope (Groups) : Ici, vous devez renseigner un groupe de sécurité contenant les utilisateurs susceptibles d’être administrés par ce rôle. Les administrateurs membres du groupe ne pourront gérer que ces utilisateurs.
  • Etendue (balises) – Scope (tags) : Comme vu à la création du rôle, on peut encore restreindre ici à certaines étiquettes, utile si vous souhaitez scinder une fois de plus la population.

Dans mon cas, je souhaitais déléguer à mes collégues Roumains un accès administrateur Intune qui soit complet au niveau des droits, mais en les limitant strictement à la gestion des éléments en rapport avec leurs utilisateurs.

La première chose à faire est de créer une étiquette qui sera utilisée pour identifier tous les éléments en rapport avec la Roumanie

L’étiquette se crée facilement dans « Tenant admin » > « Scope (Tags) ».
On note qu’il existe par défaut une étiquette « Default » qui est assignée à tous les éléments créés.

Vient ensuite la création du rôle avec les éléments suivants :

  • Name : Adm Intune RO
  • Permissions : toutes sont cochées car je souhaite leur offrir toute la largesse possible, YMMV
  • Scope (Tags) : je choisis ma nouvelle étiquette « RO »

Au niveau des assignations, je crée la suivante :

  • Name : RO ADMIN ASSIGN
  • Members : je choisis un groupe de sécurité créé pour l’occasion, contenant les admins intune du pays
  • Scope (Groups) : je choisis un groupe dynamique contenant toute ma population Roumaine

Pour finir, je n’oublie pas d’assigner une licence intune aux admins qui vont bénéficier de ce rôle, je parle d’expérience !
Passé un petit délai le temps que tout ça s’active pour l’utilisateur, on peut tester :

Mon accès admin global voit l’ensemble des politiques créées :

Le nouvel utilisateur admin « pays » ne voit que la politique qui porte l’étiquette « RO » :

Si l’utilisateur essaye de créer une politique, il se voit imposer l’étiquette « RO » :

De même, l’utilisateur ne peut pas appliquer une politique à un groupe n’étant pas compris parmi ses utilisateurs désignés :

Mission accomplie ! enfin presque, reste un détail : étiquetter les périphériques. Il n’est pas pour le moment possible de le faire « en masse » sur des périphériques, il faut donc soit passer par un script powershell, soit assigner les périphériques à un groupe dynamique qui se chargera, lui, d’étiquetter ses membres.
A l’enrollment de postes, deux choix sont possibles :

  • Le déploiement par Autopilot peut intégrer un étiquetage, défini à l’importation du fichier .csv
  • Dans une situation d’enrollment par un package de provisionement, la seule solution qui m’est apparue consisterait à peupler un groupe de sécurité en s’appuyant sur l’identité du package d’enrollment, puis à laisser ce groupe appliquer les tags.

N’hésitez pas à me signaler toute erreur !