How to use Multi Admin Approval with Microsoft Intune

Introduzione

La gestione delle applicazioni tramite Microsoft Intune permette agli amministratori IT di distribuire software, modificare le configurazioni esistenti e intervenire sugli assignment. In un ambiente aziendale queste operazioni possono avere conseguenze importanti, soprattutto quando un’applicazione è assegnata a un numero elevato di dispositivi o una modifica viene eseguita utilizzando un account amministrativo compromesso.

Per introdurre un controllo aggiuntivo su queste attività, Microsoft Intune mette a disposizione Multi Admin Approval (MAA), una funzionalità che richiede l’approvazione di un secondo amministratore prima che determinate modifiche vengano applicate.

L’amministratore continua a utilizzare le normali funzionalità del portale Intune, ma quando interviene su una risorsa protetta deve specificare una giustificazione della modifica e sottoporre la richiesta all’approvazione. Un altro amministratore autorizzato può esaminarla, approvarla oppure rifiutarla. Dopo l’approvazione, il richiedente deve completare l’operazione affinché Intune applichi la modifica.

In questa guida vedremo come configurare Multi Admin Approval in un tenant di laboratorio, creare una Access policy di tipo App, predisporre gli amministratori autorizzati e verificare l’intero processo utilizzando un’applicazione Win32 di test.

L’obiettivo è arrivare a una configurazione funzionante, verificando anche le autorizzazioni necessarie e il comportamento del portale nelle diverse fasi.

Come funziona Multi Admin Approval

Multi Admin Approval utilizza delle Access policies per stabilire quali risorse amministrative devono essere protette e quali amministratori possono approvarne le modifiche.

Ogni Access policy è associata a un singolo tipo di risorsa, denominato Profile type. Tra le tipologie supportate troviamo App, Scripts, Compliance policies, Configuration policies, Device actions, Role-based access control e alcune configurazioni del tenant.

Nel nostro caso utilizzeremo esclusivamente il tipo App, che consente di sottoporre ad approvazione operazioni come la creazione, la modifica, l’assegnazione e l’eliminazione delle applicazioni gestite da Intune. Questo controllo riguarda la gestione delle applicazioni e non le App protection policies.

Il funzionamento prevede una Access policy che definisce il perimetro protetto, un gruppo Microsoft Entra contenente gli approver e gli amministratori che richiedono le modifiche.

Quando viene inviata una richiesta, Intune la mantiene in attesa e consente agli approver autorizzati di esaminarla. Il richiedente non può approvare autonomamente la propria modifica, anche quando possiede il ruolo Global Administrator o Intune Administrator.

Disponibilità e licensing

Per utilizzare lo scenario descritto in questa guida è necessario un tenant con il servizio Microsoft Intune attivo. Multi Admin Approval può essere configurato nell’ambito della gestione Intune di base.

Per gli account amministrativi coinvolti nel processo Microsoft prevede, per impostazione predefinita, una licenza Intune. È possibile utilizzare amministratori senza una licenza individuale quando nel tenant è abilitata l’opzione Allow access to unlicensed admins.

Questa impostazione si trova nel Microsoft Intune admin center seguendo il percorso Tenant administration > Roles > Settings > Unlicensed administrators. Nei tenant creati dopo luglio 2021 l’accesso degli amministratori senza licenza è abilitato per impostazione predefinita. Nei tenant precedenti può essere attivato manualmente: i cambiamenti dell’accesso possono richiedere fino a 48 ore per diventare effettivi.

Per verificare il comportamento dell’approvazione di una modifica alle proprietà di un’applicazione non è necessario disporre di un dispositivo Windows sul quale installarla. Un endpoint gestito diventa necessario se vogliamo estendere il test alla distribuzione effettiva del software.

Preparare il tenant di laboratorio

Per riprodurre lo scenario utilizzeremo tre account amministrativi con responsabilità separate, i rispettivi gruppi di sicurezza Microsoft Entra e una Win32 app già presente nel tenant.

Componente	Nome di esempio	Funzione
Amministratore A	MAA-Requester	Richiede e completa la modifica della Win32 app
Amministratore B	MAA-Approver	Approva o rifiuta le richieste MAA
Amministratore C	MAA-PolicyManager	Crea e completa l’attivazione della Access policy
Gruppo approver	ENJ-MAA-Approvers	Contiene MAA-Approver
Gruppo policy manager	ENJ-MAA-PolicyManagers	Contiene MAA-PolicyManager
Gruppo requester	ENJ-MAA-Requesters	Contiene MAA-Requester
Access policy	MAA – Windows Apps – LAB	Protegge le operazioni sulle applicazioni Windows
Applicazione Win32	ENJ-MAA-TestApp	Oggetto utilizzato per la modifica di test

I nomi riportati sono esempi e possono essere adattati alle convenzioni del proprio ambiente.

Prima di procedere, verifichiamo che nel tenant non siano già presenti Access policies di tipo App che potrebbero interferire con il test. Conviene anche predisporre l’applicazione Win32 prima di attivare Multi Admin Approval, così da concentrare la prova sulla modifica di un oggetto esistente.

Ruoli RBAC e autorizzazioni necessarie

Le autorizzazioni dei tre account sono diverse. L’appartenenza al gruppo approver, da sola, non è sufficiente a garantire il corretto funzionamento del processo. Bisogna distinguere tre responsabilità amministrative:

Account	Responsabilità	Autorizzazioni necessarie
MAA-PolicyManager	Creazione e gestione delle Access policies	Multi Admin Approval: Create access policy, Read access policy. Per modificare o eliminare le policy sono necessari anche Update access policy e Delete access policy.
MAA-Approver	Approvazione delle Access policies e delle modifiche alle applicazioni	Mobile apps: Read per approvare le modifiche alle applicazioni e Multi Admin Approval: Approval for Multi Admin Approval per approvare le operazioni di configurazione MAA. L’account deve appartenere direttamente al gruppo ENJ-MAA-Approvers, assegnato come Admin Group a un ruolo RBAC Intune.
MAA-Requester	Richiesta e completamento delle modifiche alle applicazioni Win32	Mobile apps: Read, Mobile apps: Update e Organization: Read.

Per approvare la creazione iniziale della Access policy, l’amministratore B (MAA-Approver) deve disporre anche dell’autorizzazione Multi Admin Approval > Approval for Multi Admin Approval. Questo permesso è specifico per l’approvazione delle modifiche alla configurazione MAA; per approvare la modifica a un’applicazione resta necessario il permesso di lettura della risorsa interessata e l’appartenenza al gruppo approver.

Creare gruppi e ruoli dei PolicyManager e Requester

Prima di creare la Access policy, configuriamo i ruoli per MAA-PolicyManager e MAA-Requester. La preparazione iniziale è eseguita da un amministratore già autorizzato a creare e assegnare ruoli RBAC Intune. I permessi per amministrare i ruoli sono distinti dalle autorizzazioni Multi Admin Approval usate durante il laboratorio.

• Gruppi Microsoft Entra: in Entra ID > Groups > All groups creiamo due gruppi di tipo Security con membership Assigned: ENJ-MAA-PolicyManagers, con membro diretto MAA-PolicyManager, e ENJ-MAA-Requesters, con membro diretto MAA-Requester. Il gruppo degli approver verrà creato nella sezione successiva.

• Ruolo del policy manager: in Tenant administration > Roles > All roles > Create creiamo il ruolo MAA - Access Policy Manager - LAB. In Permissions > Multi Admin Approval abilitiamo Create access policy e Read access policy. I permessi Update e Delete non sono necessari per creare la policy.

• Ruolo del requester: nello stesso percorso creiamo MAA - App Requester - LAB con Mobile apps > Read, Mobile apps > Update e Organization > Read. Questi permessi consentono di visualizzare e modificare la Win32 app del test, rispettando gli ambiti RBAC assegnati.

• Role assignments: apriamo ciascun ruolo appena creato, selezioniamo Assignments > Assign. Diamo un nome, ad esempio MAA - Requesters Assignment e MAA - PolicyManager Assignment ,e aggiungiamo, in Admin Groups, il rispettivo gruppo Microsoft Entra (ENJ-MAA-Requesters e ENJ-MAA-PolicyManagers). Impostiamo Scope (Groups) e Scope (Tags) in modo che il requester possa raggiungere la Win32 app del laboratorio, poi completiamo con Review + Create.

Al termine, MAA-PolicyManager può creare la Access policy di tipo App, mentre MAA-Requester può modificare l’applicazione dopo che la policy sarà attiva. L’account MAA-Approver riceverà le autorizzazioni necessarie alla fase di approvazione nel passaggio seguente.

Per il dettaglio dei permessi RBAC e delle assegnazioni sono disponibili le guide Microsoft Create a custom role in Intune e Assign Microsoft Intune roles.

Creare il gruppo degli Approver

Accediamo al Microsoft Entra admin center utilizzando un account autorizzato a gestire i gruppi e apriamo Entra ID > Groups > All groups.

Selezioniamo New group e configuriamo:

• Group type: Security
• Group name: ENJ-MAA-Approvers
• Membership type: Assigned
• Members: amministratore B (MAA-Approver)

Non occorre abilitare l’opzione Microsoft Entra roles can be assigned to the group per assegnare un normale ruolo RBAC Intune.

Dopo aver creato il gruppo, controlliamo che l’amministratore B (MAA-Approver) risulti membro diretto. Microsoft raccomanda di evitare le appartenenze tramite gruppi annidati per questa configurazione.

Assegnare il ruolo Intune al gruppo approver

Torniamo nel Microsoft Intune admin center e apriamo Tenant administration > Roles > All roles. Selezioniamo Create per creare un ruolo personalizzato con nome MAA - App Approver - LAB.

Nella sezione Permissions abilitiamo:

• Mobile apps > Read
• Multi Admin Approval > Approval for Multi Admin Approval
• Multi Admin Approval > Read access policy

Completiamo la creazione del ruolo e apriamo, selezioniamo il nuovo custom role MAA - App Approver - LAB, apriamo la scheda Assignments, quindi selezioniamo Assign.

Nella pagina Basics inseriamo un nome per l’assegnazione, ad esempio MAA - Approvers Assignment. Nella sezione Admin Groups aggiungiamo direttamente ENJ-MAA-Approvers.

Proseguiamo con Scope (Groups) e Scope (Tags), utilizzando un perimetro che consenta all’approver di visualizzare l’applicazione del laboratorio. Per una prova in un tenant dedicato è possibile utilizzare gli ambiti predefiniti appropriati, evitando di introdurre scope tags personalizzati non necessari.

Completiamo infine la procedura con Review + Create.

Creare una Access policy di tipo App

Dopo aver configurato i ruoli e il gruppo degli approver, accediamo al Microsoft Intune admin center con l’amministratore C (MAA-PolicyManager) e apriamo Tenant administration > Multi Admin Approval > Access policies. Per questa operazione l’account utilizza le autorizzazioni Create access policy e Read access policy configurate in precedenza.

Selezioniamo Create per avviare la procedura guidata.

Configurare Basics e il perimetro applicativo

Nella pagina Basics inseriamo un nome e una descrizione che permettano di riconoscere la policy.

Utilizziamo i seguenti valori:

Impostazione	Valore
Name	MAA – Windows Apps – LAB
Description	Richiede l’approvazione delle modifiche amministrative alle applicazioni Windows nel tenant di laboratorio
Profile type	App
Platforms	Windows only abilitato; Non-Windows only disabilitato

Per le policy applicative, la selezione della piattaforma consente di distinguere le applicazioni Windows da quelle non Windows. Nel laboratorio abilitiamo il perimetro Windows, lasciando escluse le altre piattaforme. Le etichette dei controlli possono variare leggermente con gli aggiornamenti dell’interfaccia.

Configurare gli approver

Proseguiamo nella sezione Approvers e selezioniamo Add groups. Cerchiamo il gruppo ENJ-MAA-Approvers, creato in precedenza, e confermiamo la selezione.

Controlliamo che il gruppo sia disponibile nell’elenco. Se non compare, occorre verificare il tipo di gruppo Microsoft Entra e la corretta assegnazione RBAC.

La procedura non prevede exclusion groups per escludere alcuni amministratori dal gruppo di approvazione.

Exclusions e invio della policy

Nella pagina Exclusions è possibile aggiungere eventuali Enterprise applications da escludere dall’applicazione di MAA per le chiamate che utilizzano autenticazione applicativa.

Per il nostro laboratorio lasciamo questa sezione vuota.

Arrivati a Review + submit for approval, verifichiamo le impostazioni e compiliamo il campo Business justification con una motivazione, ad esempio:

Lab setup to test the Multi Admin Approval process on Windows applications managed by Microsoft Intune.

Selezioniamo Submit for approval.

A questo punto la policy è stata sottoposta al processo di approvazione, ma la protezione non è ancora attiva.

Approvare e completare l’attivazione della policy

Accediamo al portale Intune con l’amministratore B (MAA-Approver), utilizzando una sessione browser separata da quella dell’amministratore C (MAA-PolicyManager), che ha inviato la richiesta di creazione della Access policy denominata MAA - Windows Apps - LAB.

Apriamo Tenant administration > Multi Admin Approval > Received requests e individuiamo la richiesta relativa alla creazione della Access policy nella sezione All requests.

Apriamo la Access Policy MAA - Windows Apps - LAB, leggiamo il dettaglio della Business justification, verifichiamo le informazioni e selezioniamo Approve request, dopo aver compilato il campo Approver notes per documentare l’esito della verifica, ad esempio indicando che si tratta dell’attivazione autorizzata della protezione App nel tenant di test.

Torniamo all’amministratore C (MAA-PolicyManager), che ha creato la Access policy. In Tenant administration > Multi Admin Approval > My requests individuiamo la richiesta approvata, apriamola e selezioniamo Complete request.

Solo dopo il completamento Intune applica la nuova Access policy. Verifichiamo che la richiesta abbia raggiunto lo stato Completed e che la policy risulti disponibile e attiva nell’elenco.

Testare Multi Admin Approval su un’applicazione Win32

Dopo aver attivato la Access policy possiamo verificare il comportamento della funzionalità modificando un’applicazione Win32 esistente.

Per questa prova utilizziamo ENJ-MAA-TestApp, predisposta prima dell’attivazione di MAA e priva di assignment. Se nel tenant non è disponibile una Win32 app di test, possiamo crearne una utilizzando un pacchetto .intunewin, seguendo la normale procedura descritta nella documentazione Microsoft per la creazione delle Win32 app.

La preparazione iniziale dell’applicazione è indipendente dal test MAA. La guida si concentra sull’approvazione di una successiva modifica alle sue proprietà.

Richiedere una modifica con l’account requester

Accediamo con l’amministratore A (MAA-Requester) e apriamo Apps > All apps, quindi selezioniamo l’applicazione ENJ-MAA-TestApp. Nella pagina Properties, individuiamo la sezione App information e selezioniamo Edit. Modifichiamo il campo Description utilizzando un valore facilmente riconoscibile:

Ninja MAA LAB Endpoint - Change Approved

Questa scelta permette di verificare il funzionamento dell’approvazione senza modificare i comandi di installazione, i requisiti, le detection rules o gli assignment dell’applicazione.

Proseguiamo fino alla schermata di riepilogo e salvataggio tramite Review + submit for approval. Poiché la risorsa è protetta da Multi Admin Approval, il portale richiede una Business justification prima dell’invio.

Inseriamo una motivazione come:

Controlled change of the ENJ-MAA-TestApp application description to verify the Multi Admin Approval flow.

Confermiamo l’invio tramite il comando Submit for approval.

Verificare la richiesta in attesa

Dopo aver inviato la modifica, apriamo Tenant administration > Multi Admin Approval > My requests. La richiesta deve comparire nell’elenco con stato Needs approval.

Prima di procedere, riapriamo le proprietà dell’applicazione e controlliamo la Description. Il valore effettivamente salvato dovrebbe essere ancora quello precedente, perché la modifica non è stata completata.

Questo controllo permette di verificare che la richiesta sia stata intercettata dal processo di approvazione e che l’applicazione non sia stata ancora aggiornata.

Approvare la modifica con l’account approver

Apriamo una sessione separata del portale Intune utilizzando l’amministratore B (MAA-Approver). Navighiamo in Tenant administration > Multi Admin Approval > All requests e individuiamo la richiesta inviata dall’amministratore A (MAA-Requester).

Selezionando il collegamento alla Business justification, possiamo aprire il dettaglio della richiesta e controllare l’operazione richiesta, l’oggetto interessato e la motivazione fornita.

Prima di approvare, verifichiamo che la richiesta riguardi l’applicazione prevista e che il tipo di operazione corrisponda alla modifica concordata. Nel campo Approver notes inseriamo, ad esempio:

Change approved for Endpoint Ninja lab. Changed description of test Win32 application verified.

Selezioniamo Approve request. L’amministratore B (MAA-Approver) ha concluso la propria attività di approvazione. Rimane ancora un passaggio necessario per applicare la modifica.

Completare la modifica con l’account requester

Torniamo alla sessione dell’amministratore A (MAA-Requester) e apriamo nuovamente My requests dal percorso Tenant administration > Multi Admin Approval. La richiesta approvata risulterà disponibile per il completamento. Selezioniamola e utilizziamo il button Complete request.

Intune può impiegare un breve intervallo per elaborare la richiesta. Quando l’operazione viene applicata correttamente, lo stato passa a Completed.

Torniamo quindi in Apps > All apps > ENJ-MAA-TestApp > Properties e verifichiamo che la Description riporti il nuovo valore:

Ninja MAA LAB Endpoint - Change Approved

A questo punto possiamo considerare completato il test amministrativo, perché la modifica è stata applicata soltanto dopo la richiesta, l’approvazione di un altro amministratore e l’operazione finale di completamento.

Monitorare le richieste e gli audit log

Multi Admin Approval permette agli amministratori di seguire il ciclo di vita delle richieste attraverso il portale Intune.

La sezione My requests mostra quelle inviate dall’account corrente, mentre la vista delle richieste ricevute permette agli approver di esaminare le operazioni che richiedono un loro intervento. Gli stati principali sono i seguenti:

Stato	Significato
Needs approval	La richiesta è in attesa dell’intervento di un approver
Approved	La richiesta è stata approvata; rimane il completamento da parte del richiedente e l’elaborazione in Intune
Completed	La modifica è stata applicata correttamente
Rejected	Un approver ha rifiutato la richiesta
Canceled	Il richiedente ha annullato la richiesta prima dell’approvazione
Expired	La richiesta non è stata completata entro il periodo previsto

Per le richieste che non vengono portate avanti fino al completamento, la scadenza è di tre giorni. Una richiesta scaduta deve essere inviata nuovamente. I cambiamenti di stato rimangono consultabili fino a 30 giorni dopo la relativa transizione.

È inoltre possibile annullare una richiesta ancora in attesa utilizzando Cancel request dalla pagina My requests.

Verificare gli eventi negli audit log

Per esaminare le attività registrate da Intune apriamo Tenant administration > Audit logs con un account che ha i permessi sufficienti per poter verificare gli audit logs (per consultare gli audit log è necessaria l’autorizzazione Audit data > Read, oppure un ruolo amministrativo che la includa). Da questa sezione possiamo utilizzare i filtri per data, categoria e attività, individuando gli eventi relativi alla richiesta amministrativa e al processo di approvazione.

Nel laboratorio possiamo confrontare gli eventi con l’orario di invio della richiesta, l’approvazione eseguita dall’amministratore B (MAA-Approver) e il completamento effettuato dall’amministratore A (MAA-Requester).

Gli audit log consentono di documentare le operazioni amministrative, mentre lo stato Completed e la verifica delle proprietà dell’applicazione permettono di confermare l’effettiva applicazione della modifica.

Limitazioni e aspetti da considerare

Prima di utilizzare Multi Admin Approval in un tenant di produzione è opportuno conoscere alcuni comportamenti che incidono sulla gestione quotidiana.

La prima limitazione riguarda il perimetro della Access policy. Per il tipo App, la protezione interessa le applicazioni della piattaforma selezionata. Non è possibile creare una policy destinata esclusivamente alla singola Win32 app utilizzata durante questo laboratorio.

Un altro comportamento importante riguarda le richieste concorrenti. Quando esiste già una richiesta in attesa di approvazione per lo stesso oggetto, Intune impedisce l’invio di un’altra richiesta e visualizza un messaggio informativo. Chi gestisce frequentemente le applicazioni deve quindi tenere conto anche delle operazioni già in sospeso.

Microsoft specifica inoltre che Intune non invia automaticamente notifiche quando viene creata una richiesta o quando il suo stato cambia. Per le attività urgenti conviene prevedere un canale operativo attraverso il quale il richiedente possa contattare gli approver.

L’approvazione non sostituisce le normali autorizzazioni RBAC. L’amministratore che richiede una modifica deve continuare a possedere i permessi necessari per eseguirla, mentre l’approver deve avere accesso in lettura alla tipologia di risorsa protetta. Eventuali scope tags e scope groups devono consentire la visualizzazione dell’oggetto interessato.

Le Access policies consentono di definire esclusioni per specifiche Enterprise applications che utilizzano autenticazione applicativa, fino a un massimo di 50 per policy. Queste esclusioni valgono soltanto per le chiamate app-auth e introducono un’eccezione alla protezione; le operazioni effettuate con autenticazione delegata continuano a essere soggette a MAA. Le modifiche alle esclusioni richiedono a loro volta un’approvazione.

La documentazione Microsoft dedicata alle integrazioni con Microsoft Graph descrive il comportamento delle API e le modifiche richieste alle automazioni. Non è necessario intervenire sulle API per riprodurre la procedura illustrata in questa guida.

Per chi utilizza la nuova esperienza Deployments e Deployment Plans, è utile sapere che MAA può intervenire anche nelle operazioni di creazione, ripresa, annullamento ed eliminazione dei Deployment relativi ai payload protetti. Il funzionamento di queste distribuzioni, disponibili in Public Preview alla data della verifica, è descritto nell’articolo Microsoft Intune: Deployments & Deployment Plans pubblicato qui su Endpoint Ninja.

Le richieste MAA possono essere consultate anche nella sezione centralizzata Admin tasks del Microsoft Intune admin center. Questa esperienza verrà approfondita in un articolo separato.

Verifiche in caso di problemi

Se durante il laboratorio qualcosa non funziona come previsto, ripartite dalla fase nella quale il processo si è interrotto. Ad esempio:

Il gruppo approver non compare nella configurazione della Access policy. Controlliamo che sia un normale security group di Microsoft Entra, che l’amministratore B (MAA-Approver) sia membro diretto e che il gruppo sia stato assegnato come Admin Group a un ruolo RBAC Intune.

L’amministratore B (MAA-Approver) non riesce ad approvare la richiesta. Verifichiamo l’appartenenza al gruppo previsto dalla policy, il permesso Mobile apps: Read e l’assegnazione RBAC. Se il problema riguarda l’approvazione della creazione della Access policy, controlliamo anche la presenza del permesso Approval for Multi Admin Approval.

La modifica dell’applicazione non genera alcuna richiesta. Verifichiamo che la Access policy sia stata approvata e completata, che protegga la piattaforma Windows e che non esistano configurazioni o esclusioni pertinenti al tipo di autenticazione utilizzato. Controlliamo inoltre che l’oggetto modificato sia effettivamente una risorsa inclusa nel perimetro protetto.

La richiesta risulta Approved, ma la Description dell’applicazione non è cambiata. Torniamo nella sessione dell’amministratore che ha inviato la richiesta e controlliamo se è ancora necessario selezionare Complete. Se la richiesta risulta completata ma la modifica non compare, verifichiamo le notifiche del portale e gli audit log.

Una nuova modifica alla stessa applicazione non può essere inviata. Verifichiamo la presenza di una richiesta già in sospeso per l’oggetto. Occorre prima gestire quella richiesta secondo il flusso previsto.

Se il test viene successivamente esteso alla distribuzione dell’app su un dispositivo Windows, ricordiamo che l’approvazione della modifica amministrativa e l’installazione del software sono due operazioni distinte. Per eventuali errori di installazione sarà necessario utilizzare i report applicativi e, quando opportuno, i log descritti nella guida Microsoft Intune Management Extension logs: guida pratica al troubleshooting.

Verifica finale del laboratorio

Al termine della procedura abbiamo una Access policy App creata da MAA-PolicyManager, approvata da MAA-Approver e attivata dal policy manager. Successivamente, MAA-Requester invia e completa la modifica della Win32 app dopo l’approvazione dell’account MAA-Approver.

Il test è riuscito quando la Access policy risulta attiva, la modifica della Win32 app compare in My requests, l’amministratore B (MAA-Approver) la approva e l’amministratore A (MAA-Requester) completa l’operazione. La nuova Description deve risultare salvata nelle proprietà dell’applicazione.

Prima di ripetere la configurazione in produzione, conviene documentare il gruppo approver, i relativi ruoli RBAC, le persone autorizzate a intervenire e le eventuali automazioni interessate dalla protezione.

Le Access policies dovrebbero essere introdotte dopo aver verificato che gli approver siano effettivamente in grado di operare e che il processo di completamento delle richieste sia stato compreso dagli amministratori coinvolti. Anche le modifiche alle Access policies richiedono l’approvazione di un altro amministratore.

Conclusioni

Multi Admin Approval introduce un controllo aggiuntivo sulle operazioni amministrative di Microsoft Intune, permettendo di sottoporre le modifiche alle risorse protette alla verifica di un secondo amministratore. La configurazione richiede pochi passaggi, ma è importante prestare attenzione alla gestione delle autorizzazioni RBAC, alla composizione del gruppo degli approver e al completamento delle richieste dopo l’approvazione.

Il laboratorio descritto in questa guida permette di verificare il funzionamento di MAA su un’applicazione Win32, osservando come una modifica venga mantenuta in attesa fino al completamento del processo autorizzativo. Lo stesso meccanismo può essere applicato alle altre tipologie di risorse supportate, valutando per ciascuna le conseguenze sulle attività amministrative quotidiane.

Prima di abilitare Multi Admin Approval in produzione, è consigliabile individuare le operazioni da proteggere, definire chi può approvarle e verificare l’impatto sugli strumenti di automazione già utilizzati. Particolare attenzione va riservata alla disponibilità degli approver e alla gestione delle richieste in sospeso, soprattutto negli ambienti in cui le configurazioni Intune vengono modificate frequentemente.

Una volta completate queste verifiche, Multi Admin Approval può contribuire a ridurre il rischio di modifiche accidentali o non autorizzate, rendendo le operazioni amministrative soggette a un processo di approvazione verificabile.