Perché delegare con scope

In un tenant Entra ID di medie dimensioni, concentrare i permessi in pochi Global Administrator viola il principio del least privilege e amplia la superficie d’attacco. Lo scenario tipico d’esame è opposto: un helpdesk regionale deve poter resettare le password e gestire gli account solo della propria sede, senza toccare il resto dell’organizzazione. La risposta corretta combina due leve: Administrative Units (AU) per delimitare quali oggetti si amministrano, e ruoli scoped per definire cosa si può fare su quegli oggetti.

Cosa sono le Administrative Units

Un’Administrative Unit è un contenitore logico di utenti, gruppi e device su cui assegnare ruoli con ambito ristretto. Un amministratore con ruolo scoped su un’AU vede ed opera esclusivamente sui membri di quella AU, non sull’intero directory.

I membri si popolano in due modi:

  • Assegnazione manuale dei singoli oggetti.
  • Dynamic membership rule, che aggiunge automaticamente gli oggetti in base ad attributi (es. user.department -eq "Milano" o user.city). Richiede licenze Entra ID P1.

Le AU sono la granularità di delega più fine del directory: rispondono a organizzazioni distribuite per sede geografica, business unit o filiale.

Restricted management Administrative Units

Una variante importante è la restricted management AU. Qui gli oggetti membri sono protetti: possono essere modificati solo dagli amministratori con ruolo scoped su quella AU. Nemmeno i ruoli con permessi a livello di tenant (inclusi ruoli molto potenti) possono agire sui membri, salvo il Global Administrator e il Privileged Role Administrator, che restano l’eccezione per gestione dei ruoli. Si usa per proteggere account sensibili (es. break-glass, dirigenti, service account) dall’amministrazione generalizzata. Attenzione: la membership di una restricted AU non può essere dinamica: gli oggetti vanno aggiunti manualmente.

Ruoli built-in vs custom, in ottica least privilege

Assegnare un ruolo significa scegliere il minor privilegio sufficiente al compito.

  • Ruoli built-in: coprono la maggior parte degli scenari. Per l’helpdesk che resetta password, la scelta corretta è Helpdesk Administrator (o User Administrator se serve creare/eliminare utenti), mai Global Administrator. Password Administrator è un’alternativa ancora più ristretta se serve solo il reset password.
  • Custom roles: si creano quando nessun ruolo built-in combacia con il set di permessi desiderato. Si compongono selezionando resource actions granulari (es. microsoft.directory/users/password/update). Richiedono Entra ID P1.

Sia i ruoli built-in sia i custom possono essere assegnati con scope = AU, applicando la delega solo agli oggetti della AU. La combinazione ideale per l’esame è spesso: ruolo built-in a minor privilegio + scope su una AU, evitando custom role complessi quando un built-in basta.

Come si assegna

L’assegnazione scoped si fa dal blade Administrative Units → Roles and administrators, oppure via PowerShell / Microsoft Graph indicando directoryScopeId puntato alla AU:

New-MgRoleManagementDirectoryRoleAssignment `
  -RoleDefinitionId <helpdeskAdminRoleId> `
  -PrincipalId <groupOrUserId> `
  -DirectoryScopeId "/administrativeUnits/<auId>"

Best practice: assegnare il ruolo a un gruppo role-assignable, non ai singoli, e portare le assegnazioni privilegiate sotto Privileged Identity Management (PIM) per renderle eligible e just-in-time.

Trappole tipiche d’esame

  • Scenario: vuoi una gerarchia “Italia → Milano → Team A” annidando AU dentro AU. → Le Administrative Units NON si annidano. Vanno modellate piatte; per la granularità usa AU separate o dynamic rules più specifiche.
  • Scenario: assegni un ruolo con scope su una AU ma alcuni permessi (es. gestione di applicazioni o policy tenant-wide) non funzionano. → Non tutti i ruoli sono assegnabili con scope AU. Solo un sottoinsieme (Helpdesk/User/Password/Groups/Authentication Administrator, ecc.) supporta lo scope AU; ruoli come Global Administrator agiscono sempre a livello di tenant.
  • Scenario: l’helpdesk deve solo resettare password di una sede e ti chiedono il ruolo. → Helpdesk Administrator scoped sulla AU, non Global Administrator (least privilege).
  • Scenario: devi proteggere account dirigenziali anche dagli altri admin, con membership automatica. → Serve una restricted management AU, ma la sua membership deve essere manuale: le dynamic rule non sono supportate sulle restricted AU.
  • Scenario: nessun ruolo built-in combacia esattamente con i permessi richiesti. → Crea un custom role (richiede Entra ID P1) con le sole resource actions necessarie, poi assegnalo con scope AU.