Il ruolo dice che cosa puoi fare

Un ruolo è un insieme fisso di permessi. Microsoft Entra ID ne mette a disposizione circa sessanta come built-in roles e, quando nessuno di essi corrisponde al bisogno, permette di definire dei custom roles. La documentazione li raggruppa in tre categorie: i ruoli specifici di Microsoft Entra ID (User Administrator, Groups Administrator, Application Administrator), i service-specific roles che governano un singolo servizio (Exchange Administrator, SharePoint Administrator, Teams Administrator, Intune Administrator) e i cross-service roles che attraversano l’intera piattaforma, cioè Global Administrator, Global Reader e i ruoli di sicurezza e conformità come Security Administrator o Compliance Administrator.

Per AB-650 due nomi contano più degli altri. AI Administrator amministra Microsoft 365 Copilot, le istanze e le identità degli agenti e le app nella pagina Integrated Apps, ma non gestisce le licenze degli utenti umani né le loro sessioni di accesso; il consenso a livello di tenant per le Microsoft Graph application permissions resta riservato a Global Administrator. AI Reader vede le stesse superfici in sola lettura e non può pubblicare, attivare o modificare un agente. Ruoli come Global Reader, Security Reader, Reports Reader e User Experience Success Manager vedono l’agent registry, ma non possono installare né approvare nulla.

La regola operativa è sempre la stessa: assegnare il ruolo meno permissivo che basta e tenere il numero di Global Administrator il più basso possibile. In Microsoft 365 admin center i ruoli si assegnano dalla pagina Role assignments, dove la scheda Permissions elenca in dettaglio che cosa può fare quel ruolo; in Microsoft Entra admin center si passa da Roles & admins e dal pannello Add assignments. Attenzione a un dettaglio che l’esame ama: nell’elenco compaiono solo i gruppi role-assignable, non un gruppo di sicurezza qualsiasi. E per le identità degli agenti di Microsoft Entra Agent ID valgono limiti aggiuntivi: Global Administrator, Privileged Role Administrator e User Administrator non sono assegnabili a un’identità agente, i custom role non lo sono affatto, e un’identità agente non può essere membro di un gruppo role-assignable.

L’administrative unit dice su chi

Un’administrative unit non aggiunge permessi: restringe il perimetro su cui un ruolo già assegnato agisce. È un contenitore che può contenere soltanto users, groups o devices, non può essere annidato in un altro, e va popolato prima che l’assegnazione abbia senso. Il caso da manuale è il Helpdesk Administrator regionale, che reimposta password solo per gli utenti della propria area. Va tenuto a mente il rovescio della medaglia: se assegni un ruolo a una persona senza indicare un’administrative unit, l’ambito è l’intero tenant.

Non tutti i ruoli accettano questo ambito. Fra quelli documentati ci sono Authentication Administrator, Cloud Device Administrator, Groups Administrator, Helpdesk Administrator, License Administrator, Password Administrator, Privileged Authentication Administrator, SharePoint Administrator, Teams Administrator e User Administrator. Il tranello classico riguarda i gruppi: aggiungere un gruppo a un’administrative unit porta nell’ambito il gruppo, non i suoi membri. Un User Administrator con quell’ambito può rinominare il gruppo e modificarne la membership, ma non può toccare le proprietà o le password degli utenti che ne fanno parte, a meno che quegli utenti siano stati aggiunti direttamente come membri dell’unità. Le assegnazioni con ambito si fanno da Roles & admins > Admin units > Roles and administrators, e richiedono una licenza Microsoft Entra ID P1 per ciascun amministratore così delegato.

Caso particolare: la restricted management administrative unit, pensata per oggetti sensibili come gli account dei dirigenti. Qui perfino Global Administrator e Privileged Role Administrator, con ambito tenant, non possono modificare le proprietà Microsoft Entra degli oggetti contenuti: possono però gestire l’unità stessa e assegnarsi esplicitamente un ruolo su quell’ambito, il che è un evento tracciato nell’audit log. L’impostazione va scelta al momento della creazione e non è più modificabile dopo.

PIM dice per quanto tempo

Privileged Identity Management trasforma un ruolo permanente in un ruolo attivabile. Il vocabolario è esatto e va imparato: un’assegnazione eligible richiede che l’utente compia un’azione per usare il ruolo, un’assegnazione active no. L’azione si chiama activate e avviene da ID Governance > Privileged Identity Management > My roles, indicando una durata entro il massimo consentito e compilando il campo Reason; le richieste in sospeso si seguono in My requests.

Le regole si configurano per ruolo, in Role settings: Activation maximum duration, On activation, require multifactor authentication, Require justification on activation, Require ticket information on activation, Require approval to activate, e la coppia Allow permanent eligible assignment oppure Expire eligible assignment after (con l’equivalente per le assegnazioni active). Due sfumature che l’esame verifica volentieri: il numero di ticket è un campo puramente informativo e non viene correlato con nessun sistema di ticketing; e se abiliti l’approvazione senza indicare approvatori espliciti, gli approvatori predefiniti diventano i Privileged Role Administrator e i Global Administrator attivi, con il rischio concreto di restare fuori dal proprio tenant. Nota infine che utenti e gruppi dentro una restricted management administrative unit non sono gestibili con PIM, entitlement management, lifecycle workflows e access review: i due meccanismi non si sommano.

I contatti, e che cosa aspettarsi in sede d’esame

Un contatto non è un’identità che accede: è una voce di rubrica. In Exchange Online, sotto Recipients nell’Exchange admin center, un mail contact rappresenta una persona esterna all’organizzazione, ha un indirizzo di posta esterno ed è visibile nella global address list (GAL). Da non confondere con un mail user, che pure ha un indirizzo esterno ma possiede anche un account nell’organizzazione, e quindi può ricevere permessi. In Microsoft Graph l’oggetto corrispondente è l’orgContact, un contatto organizzativo gestito dagli amministratori, distinto dai contatti personali e in sola lettura tramite l’API, perché viene sincronizzato dall’ambiente on-premises o da Exchange Online.

AB-650 è in beta e Microsoft non pubblica durata e numero di domande, mentre la soglia di superamento è 700. Su questo blocco aspettati scenari in cui devi scegliere lo strumento giusto fra i tre assi: chi deve poter fare qualcosa di limitato ovunque prende un ruolo meno permissivo, chi deve poter fare molto ma solo su una parte dell’organizzazione prende lo stesso ruolo con ambito administrative unit, chi deve poter fare molto ma solo ogni tanto passa da PIM. Sono ortogonali e si combinano: un’assegnazione può essere eligible in PIM e limitata a un’administrative unit.