Unités administratives Entra ID : déléguer par filiale ou par pays sans rôles globaux
Dans les groupes multi-entités ou multi-pays, le support local a besoin de réinitialiser des mots de passe et de gérer des groupes. Trop souvent, on lui attribue pour cela un rôle qui s'applique à tout le locataire. Les unités administratives offrent une alternative bien plus maîtrisée.
Le principe
Une unité administrative (UA) est un conteneur logique regroupant des utilisateurs, des groupes et des appareils. On y attribue des rôles dont la portée est limitée à ce conteneur : un administrateur du support belge, par exemple, peut réinitialiser les mots de passe des seuls utilisateurs de l'UA « Belgique ». Les administrateurs qui bénéficient d'une attribution limitée à une UA doivent disposer d'une licence Entra ID P1.
Les rôles concernés
Seule une partie des rôles peut être limitée à une UA. Parmi les plus utilisés :
- administrateur du support technique et administrateur des utilisateurs ;
- administrateur des groupes ;
- administrateur d'authentification ;
- administrateur de licences ;
- administrateur d'appareils cloud.
Consultez la liste à jour dans la documentation Microsoft : elle évolue, et un rôle absent de la liste ne peut être attribué qu'à l'échelle du locataire.
Alimenter les unités
L'appartenance peut être attribuée manuellement ou par une règle dynamique, par exemple sur l'attribut pays ou société. La règle dynamique garantit que chaque nouvel arrivant se retrouve automatiquement dans la bonne UA, à condition que l'attribut source soit fiable et contrôlé.
Un piège classique. Ajouter un groupe à une UA ne place pas ses membres dans l'UA. L'administrateur délégué peut gérer le groupe lui-même (nom, appartenance), mais pas les comptes qui le composent, sauf si ceux-ci sont ajoutés à l'UA séparément.
Les unités administratives à gestion restreinte
Une UA à gestion restreinte va plus loin : les objets qu'elle contient ne peuvent être modifiés que par les administrateurs dont le rôle est limité à cette UA. Même un administrateur des utilisateurs ou un administrateur général à l'échelle du locataire ne peut pas les modifier directement. C'est utile pour protéger des comptes sensibles (direction, comptes d'urgence, comptes de service critiques) contre des administrateurs du support qui disposent de droits larges. Un administrateur général pourrait toutefois s'attribuer un rôle sur l'UA : le dispositif réduit les erreurs et les abus, il ne remplace pas la surveillance des rôles les plus élevés.
Les limites à garder en tête
- Les UA ne s'imbriquent pas : pas de hiérarchie entité, pays, site.
- Les rôles limités à une UA ne permettent pas d'agir sur les comptes détenant des rôles d'administration plus élevés.
- Les applications, les stratégies d'accès conditionnel et les paramètres du locataire restent hors du périmètre des UA.
- Une règle dynamique mal écrite peut inclure des comptes indésirables, y compris des invités.
Par où commencer
Identifiez les attributions de rôles à l'échelle du locataire accordées au support local ou aux équipes de filiales. Pour chacune, déterminez si une UA avec le même rôle suffirait. Créez les UA en fonction d'un attribut fiable, testez sur une entité pilote, puis remplacez progressivement les attributions globales. Enfin, placez vos comptes les plus sensibles dans une UA à gestion restreinte.