0:00
/
Trascrizione

Intune Multi Admin Approval: come proteggere le operazioni critiche

Proteggi wipe, script e ruoli in Intune con un secondo admin che approva. Guida completa a Multi Admin Approval.

Specialisti IT, ciao a tutti! Oggi parliamo di Multi Admin Approval (MAA), una funzionalità di Microsoft Intune che permette di proteggere operazioni critiche richiedendo l’approvazione esplicita di un secondo amministratore prima che vengano eseguite. Uno strumento di governance concreto, che riduce il rischio di errori umani e azioni non autorizzate, aggiungendo un layer di controllo reale sulle operazioni più delicate del tuo ambiente gestito.


⚠️ Importante!

L’offerta editoriale di ITSpecialist.News si è arricchita con una nuova sezione in lingua inglese, che raccoglie una selezione dei miei contenuti principali.

Poiché si tratta in gran parte degli stessi articoli tradotti, potresti non volerli ricevere due volte, soprattutto se preferisci leggere in una lingua specifica.

Se vuoi scegliere in quale lingua ricevere i contenuti:

→ Vai su itspecialistnews.substack.com/account
→ Apri la sezione “Notifiche”
→ Se sei un lettore in inglese, attiva solo “ITSpecialist.News – Same Content, in English” e disattiva le altre opzioni.
→ Se sei un lettore in italiano, mantieni attiva solo “ITSpecialist.News | Riccardo Corna”.


Prerequisiti e licensing

Prima di mettere mano alla console, allineiamoci su quello che serve.

I requisiti sono abbastanza lineari:

  • Microsoft Intune Plan 1, non serve il Plan 2 per MAA.

  • Dispositivi gestiti da Intune.

  • Gli utenti coinvolti devono avere i permessi appropriati nel portale Intune (lo vedremo tra poco).

Per tutti i dettagli tecnici ti rimando alla documentazione ufficiale Microsoft, allegata in fondo all’articolo.

I tre attori coinvolti

Prima di iniziare la configurazione, è importante avere chiaro un concetto fondamentale: in uno scenario MAA entrano in gioco tre attori distinti.

  1. L’admin che crea e gestisce le policy MAA: decide quali operazioni devono essere soggette ad approvazione e chi ha il diritto di approvarle.

  2. L’admin approver: è il “secondo paio di occhi”. Riceve le richieste, le approva o rifiuta.

  3. Il change requestor: è l’operatore (tipicamente un Help Desk operator) che vuole eseguire un’operazione protetta e deve fare una richiesta esplicita di approvazione.

Questi tre ruoli interagiscono in sequenza. Nel tutorial li vedremo tutti in azione.

Pronti? Partiamo!

Creazione del gruppo Approver su Microsoft Entra

La prima cosa da fare è creare un gruppo security su Microsoft Entra ID che raccoglierà gli amministratori con ruolo di approver. MAA si basa su gruppi Entra per sapere chi può approvare cosa, quindi questo è il punto di partenza obbligato.

Vai sul portale di Microsoft Entra ID, crea un nuovo gruppo di sicurezza (io l’ho chiamato qualcosa di sensato tipo Intune MAA Approvers) e aggiungi come membro l’amministratore che farà da approver.

Niente di complicato fin qui. Però prima di passare alla policy MAA, c’è un passaggio che può sembrare strano ma è assolutamente fondamentale.

Non saltarlo e leggi attentamente le varie opzioni che ci sono a disposizione!

Assegnazione di un ruolo RBAC Intune al gruppo

Il gruppo di Entra appena creato deve essere assegnato a un ruolo RBAC di Intune.

Permessi necessari per approvare/rifiutare le richieste

L’approver deve:

  • avere i permessi di lettura (Read) su tutte le tipologie di oggetti / configurazioni / policy che deve approvare

  • Poter approvare le policy, con il permesso RBAC Approval for Multi Admin Approval che trovi all’interno della sezione Multi Admin Approval nell’elenco dei permessi del ruolo RBAC.

Quindi, tradotto in soldoni, hai due opzioni:

  • Se il tuo approver è Intune Administrator, non hai bisogno di creare un ruolo RBAC specifico e, quindi, potrai associare il tuo gruppo di approver ad un ruolo RBAC qualunque, anche il Read Only Operator. È quello che ho fatto io perché, banalmente, essendo un lab, non ho così tante licenze che coprano tutti gli utenti del caso. Ho scelto questa strada per semplicità e per farti capire che l’assegnazione del ruolo RBAC è fondamentale.

  • Se il tuo approver NON è Intune Administrator, allora dovrai associare il gruppo degli approver ad un ruolo RBAC ad-hoc con i permessi di Read per tutto quello che serve approvare più il permesso Approval for Multi Admin Approval.
    Ad esempio, potresti clonare il ruolo Read Only Operator e aggiungerci il permesso specifico Approval for Multi Admin Approval.

Tutto chiaro? Spero di sì. Ora assegnamo il ruolo al gruppo degli approver!

Perché è necessario? Perché se il gruppo non ha nessun ruolo assegnato in Intune, il sistema non lo considera rilevante e, attenzione, la membership del gruppo viene ripulita automaticamente. Gli approver spariscono, la tua configurazione smette di funzionare e non te ne accorgi subito.

Ok, ora possiamo finalmente creare la policy.

Creazione della policy di Multi Admin Approval

Eccoci al cuore della configurazione.

Vai su Intune > Tenant Administration > Multi Admin Approval e crea una nuova Access Policy.

Qui definisci quale operazione deve essere protetta da approvazione. Nel nostro esempio proteggiamo il wipe dei dispositivi, una delle operazioni più impattanti che esistano in Intune, perfetta per dimostrare MAA in azione.

Imposta il tipo di operazione, seleziona il gruppo approver creato al passo precedente, e salva.

⚠️ Attenzione però: la policy non è ancora attiva. E qui arriva il primo dei passaggi “non ovvi” di MAA, che sorprende spesso chi la configura per la prima volta.

Permessi necessari per creare e gestire le Access Policy

C’è una da tenere a mente: l’account che crea e gestisce le policy di MAA deve avere i permessi giusti. Qui hai due strade.

La prima opzione è usare il ruolo Intune Administrator (noto anche come Intune Service Administrator su Microsoft Entra): ha accesso completo in lettura e scrittura su Intune, quindi può fare tutto.

Se dovessi scegliere questa strada, puoi creare direttamente la policy senza dover fare altro a livello di RBAC.

Nel video uso questo approccio per semplicità e, banalmente, perché non ho abbastanza licenze per provare il tutto con persone e admin diversi. 😆

Attenzione però: Microsoft stessa consiglia di non usarlo per la gestione ordinaria delle access policy, proprio perché è un ruolo privilegiato ad ampio raggio.

La seconda opzione, quella consigliata per ambienti di produzione, è creare un ruolo RBAC custom in Intune con i permessi specifici per MAA.

In questo caso, il ruolo RBAC dell’amministratore che crea e gestisce le policy è fondamentale e richiede i seguenti permessi Multi Admin Approval della tabella qui sotto👇

Il principio di least privilege, come sempre, è il tuo migliore amico.

L’approver approva la creazione della policy

Esatto: anche la creazione della policy MAA stessa richiede approvazione.

L’admin approver accede al portale Intune e va nella sezione Admin Tasks, dove trova la richiesta in attesa.

L’approver verifica la richiesta, aggiunge eventualmente una nota, e approva. Lo stato passa ad Approved.

Ma non è ancora finita! Manca un ultimo passaggio importantissimo.

Il primo admin completa la richiesta

Una richiesta in stato Approved non è una richiesta eseguita. L’admin che l’ha creata deve tornare su Admin Tasks e completarla esplicitamente.

Solo quando lo stato diventa Completed la policy è effettivamente attiva.

Questo comportamento vale sempre, per qualsiasi operazione protetta da MAA: non basta l’approvazione, bisogna anche completare il giro.

Lo vediamo anche nell’esempio del wipe qui sotto.

Hazel fa richiesta di wipe

Entra in scena Hazel, la nostra operatrice di Help Desk. Hazel ha il ruolo RBAC Help Desk Operator in Intune. Deve riassegnare un PC e, come prima cosa, ha bisogno di fare il wipe del dispositivo.

Hazel accede al portale Intune, trova il dispositivo, e clicca su Wipe.

Non parte nulla. Il portale mostra un messaggio che comunica che l’operazione richiede approvazione. Hazel ha fatto la sua parte: la richiesta è in coda.

Il dispositivo non viene toccato finché qualcuno non approva.

L’approver approva il wipe

L’approver riceve la notifica, accede al portale Intune e va in Admin Tasks, dove trova la richiesta di Hazel in attesa.

L’approver verifica il dispositivo, aggiunge una nota se necessario, e approva. La richiesta passa ad Approved.

Ora Hazel può fare la sua parte finale.

Hazel completa il wipe

Come detto prima: Approved non vuol dire eseguito. Hazel torna su Admin Tasks, trova la sua richiesta approvata e la completa.

Solo con lo stato Completed il wipe viene effettivamente avviato sul dispositivo.

Verifica sul client

E ora la parte che piace a tutti: andiamo a vedere cosa succede sul dispositivo.

Il dispositivo ha ricevuto il comando e sta eseguendo il reset.

Il flusso completo ha funzionato esattamente come previsto, dall’inizio alla fine.

📚 Documentazione ufficiale

Come sempre, trovi tutta la documentazione ufficiale Microsoft allegata qui sotto.

📎 Use multi admin approval in Intune — Microsoft Learn

STUDIALA! 😜

🏁 Conclusioni

Il wipe che abbiamo visto oggi è solo uno degli scenari in cui puoi applicare Multi Admin Approval. MAA supporta anche la distribuzione di script, l’assegnazione di ruoli e altre operazioni sensibili nella gestione degli endpoint, e Microsoft sta continuando ad espandere le categorie supportate.

È uno strumento che vale la pena valutare seriamente ogni volta che hai operazioni ad alto impatto nel tuo ambiente.

Grazie per aver letto fino in fondo. Se il contenuto ti è stato utile, iscriviti a ITSpecialist.News per ricevere ogni nuovo articolo direttamente in inbox.

A presto…

MITICI!

Assolutamente, procediamo.