Tipi di identità in Microsoft Entra ID

Microsoft Entra ID è il directory service cloud che governa autenticazione e autorizzazione al piano delle identità. Ogni account utente appartiene a una di tre categorie, e riconoscerne la provenienza è decisivo negli scenari d’esame.

  • Cloud-only: utente creato e gestito direttamente in Entra ID. La sua source è Microsoft Entra ID. Password e attributi si modificano nel cloud.
  • Sincronizzato (synced): utente originato da un Active Directory on-premises e proiettato nel cloud tramite Microsoft Entra Connect (o Cloud Sync). La source è Windows Server AD. Attributi e password restano gestiti on-premises: non puoi rinominare o cambiare l’UPN dal portale, devi farlo in AD e attendere il ciclo di sync. Eccezione: con Password Hash Sync o self-service password reset writeback alcune operazioni tornano indietro verso l’on-premises.
  • Guest / external (B2B): identità esterna invitata nel tenant. Lo userType è Guest e l’UPN assume la forma nome_dominioesterno#EXT#@tuotenant.onmicrosoft.com. Il guest si autentica con le proprie credenziali (home tenant), ma riceve accesso a risorse del tuo tenant. È lo strumento corretto per far collaborare partner o consulenti senza creare account interni.

Gruppi: tipo e appartenenza

In Entra ID i gruppi si classificano su due assi indipendenti.

Tipo di gruppo

  • Security group: usato per assegnare permessi e accessi (Azure RBAC, licenze, accesso condizionale, applicazioni). Può contenere utenti, dispositivi e altri gruppi.
  • Microsoft 365 group: pensato per la collaborazione; porta con sé risorse condivise (mailbox, SharePoint, Teams). Non è la scelta giusta per assegnare permessi RBAC su risorse Azure.

Appartenenza (membership)

  • Assigned: i membri vengono aggiunti manualmente.
  • Dynamic membership: i membri sono calcolati automaticamente da una regola su attributi (es. user.department -eq "Sales"). Esistono i dynamic user e i dynamic device, ma un singolo gruppo non può mescolare i due. La dynamic membership richiede licenze Entra ID P1.

Un gruppo dinamico non permette l’aggiunta manuale: cambiare l’attributo dell’utente è l’unico modo per farlo entrare o uscire.

Self-service password reset e operazioni bulk

Il self-service password reset (SSPR) consente agli utenti di reimpostare autonomamente la password dopo aver registrato metodi di autenticazione (telefono, email alternativa, Microsoft Authenticator, domande di sicurezza). Richiede Entra ID P1 per gli utenti e va abilitato per tutti/gruppo/nessuno. Per gli utenti sincronizzati, perché il reset si propaghi in AD serve il password writeback configurato in Entra Connect.

Le bulk operations (import/export CSV) servono a creare, invitare, eliminare utenti o popolare gruppi in massa dal portale: utili quando lo scenario chiede l’onboarding di molti utenti o guest senza scripting.

Piano identità vs piano risorse

Concetto architetturale chiave: il tenant Entra ID (piano dell’identità) e la subscription (piano di billing e risorse) sono separati. Un tenant può ospitare più subscription, e una subscription è trusted da un solo tenant. Spostare una subscription sotto un altro tenant significa perdere le assegnazioni RBAC, perché i principal risiedono nell’identità di origine.

Ruoli directory vs Azure RBAC

I ruoli directory Entra (es. Global Administrator, User Administrator, Groups Administrator) governano oggetti dell’identità: utenti, gruppi, app registration, tenant. I ruoli Azure RBAC (Owner, Contributor, Reader) governano l’accesso alle risorse Azure (VM, storage, subscription) e si assegnano su uno scope. Sono due sistemi distinti: essere Global Administrator non dà automaticamente controllo sulle risorse Azure (esiste solo un toggle di elevate access opzionale), e un Owner su una subscription non può gestire gli utenti del tenant.

Trappole tipiche d’esame

  • Rinominare l’UPN di un utente sincronizzato dal portale → non si può: l’oggetto è read-only nel cloud, la modifica va fatta on-premises in AD e poi sincronizzata.
  • Assegnare permessi su risorse Azure a un gruppo → usa un Security group, non un Microsoft 365 group: solo il Security group è supportato per le assegnazioni RBAC.
  • Global Administrator che non riesce a gestire una VM → confusione tra i due piani: serve un ruolo Azure RBAC (es. Contributor) sullo scope, non un ruolo directory.
  • Collaborazione con un partner esterno senza creare account interni → invito B2B (guest): il partner riconserva le proprie credenziali del tenant di origine.
  • Aggiungere manualmente un membro a un gruppo dinamico → operazione bloccata: modifica invece l’attributo referenziato dalla regola di membership.