• Guide, Sicurezza, Sistemi Operativi
• 6 Novembre 2026

Gestire le postazioni di lavoro garantendo contemporaneamente sicurezza e operatività è da sempre uno dei compromessi più difficili nel mondo IT. Quante volte vi siete trovati costretti ad assegnare privilegi di amministratore locale a sviluppatori o power user, pur sapendo che il tradizionale User Account Control (UAC) non offre una vera barriera contro malware sofisticati ed escalation di privilegi? Nel modello classico, infatti, un utente amministratore opera con uno split token che espone costantemente il sistema al rischio di hijack della sessione.

Per risolvere questa criticità alla radice, Microsoft ha introdotto in Windows 11 la nuova funzionalità di Administrator Protection. L’approccio cambia radicalmente: l’utente lavora a tutti gli effetti come utente standard puro e i diritti di amministrazione non risiedono più nella sua sessione desktop. Nel momento in cui serve eseguire un’operazione critica, il sistema richiede una forte autorizzazione tramite Windows Hello for Business e genera al volo un token amministrativo isolato e temporaneo, valido unicamente per quel singolo processo.

Architettura e principi di funzionamento

Per comprendere il valore di Administrator Protection è necessario analizzare il cambio di paradigma introdotto a livello di sistema operativo. Nel modello UAC tradizionale, all’accesso dell’utente appartenente al gruppo Administrators locale vengono generati due token contestuali: un token filtrato standard per la sessione desktop ordinaria e uno split token elevato latente, pronto a essere sbloccato. Questo meccanismo ha storicamente esposto il fianco ad attacchi di manipolazione della memoria e injection, consentendo a malware eseguito nel contesto utente di tentare la scalata dei privilegi.

Con Administrator Protection, Windows 11 abbandona completamente lo split token permanente per adottare un’architettura basata su quattro pilastri fondamentali:

La prima caratteristica è l’elevazione Just-in-Time. L’utente opera costantemente in modalità completamente deprivilegiata e i diritti amministrativi vengono concessi esclusivamente per la singola operazione richiesta. Il token elevato ha una durata limitata: viene distrutto e scartato non appena il processo termina, per poi essere ricreato da zero soltanto se e quando si rende necessaria una nuova attività ad alto privilegio.

Il secondo cardine architetturale risiede nella separazione dei profili. Per isolare il contesto amministrativo da quello ordinario, il sistema operativo genera account utente nascosti e dedicati, identificati dal prefisso ADMIN_. Questo isolamento non riguarda soltanto il token di sicurezza, ma si estende all’intero profilo sul disco (con un percorso dedicato in C:\Users) e all’hive del registro di sistema (HKCU isolato). Grazie a questo confinamento ermetico, un processo non fidato o un malware in esecuzione nel contesto standard dell’utente non ha visibilità né facoltà di manomettere la sessione elevata.

Il terzo elemento è l’assenza di auto-elevazioni. Con Administrator Protection non esistono meccanismi di elevazione automatica o silenziosa: ogni singola richiesta amministrativa esige categoricamente un’autorizzazione interattiva ed esplicita da parte dell’operatore, mantenendo il pieno controllo di ogni variazione di stato del sistema operativo.

A garanzia di questo flusso interattivo interviene l’integrazione nativa con Windows Hello for Business. La convalida dell’elevazione non avviene tramite un banale clic o l’inserimento di password tradizionali, ma fa leva sull’infrastruttura di credenziali forti basata su PIN o biometria a livello di Secure Desktop, assicurando che chi autorizza l’operazione sia fisicamente e indiscutibilmente il titolare dell’account.

Figura 1: Schema architetturale di Administrator Protection: netta separazione tra il token standard dell’utente e il token elevato isolato generato Just-in-Time

Versioni di Windows supportate

La funzionalità ha fatto la sua prima comparsa nel canale Windows Insider Canary (Build 27718) ed è stata introdotta ufficialmente a partire da Windows 11 versione 24H2 (tramite aggiornamenti cumulativi come KB5067036 / KB5120998 e integrata nelle relative security baseline).

È supportata sulle edizioni Home, Pro, Enterprise ed Education, mentre restano attualmente esclusi gli ambienti virtualizzati remoti come Windows 365 Cloud PC e Azure Virtual Desktop (AVD).

Prerequisiti

Prima di mettere mano alla console di Intune, dovete verificare che le postazioni soddisfino alcuni requisiti architetturali non negoziabili.

La funzionalità richiede Windows 11 aggiornato alle build più recenti. Se distribuite la policy su versioni precedenti di Windows 11 o su Windows 10, i parametri di configurazione non avranno alcun effetto o restituiranno errore durante l’applicazione.

Il cuore di questa tecnologia è la verifica forte dell’identità: per questo motivo Windows Hello for Business deve essere obbligatoriamente configurato e attivo sulla macchina. L’elevazione Just-in-Time sostituisce il banale consenso visivo con la richiesta esplicita di PIN o biometria (impronta digitale o riconoscimento facciale). Se l’utente non ha registrato un PIN Hello valido, non potrà autorizzare l’elevazione. Avete già letto i miei articoli su Windows Hello for Business?

A livello di identità e privilegi, l’account dell’utente deve essere già membro del gruppo locale Administrators. Administrator Protection non serve per concedere privilegi a chi è un utente standard, ma per vincolare e blindare chi è già amministratore.

Infine, tenete presente che l’applicazione della policy richiede un riavvio del dispositivo prima che il nuovo modello di approvazione diventi operativo. Durante le vostre prove, assicuratevi di lavorare su un gruppo pilota ristretto di macchine test prima di pensare a una distribuzione estesa all’intera organizzazione.

Figura 2: Verifica del gruppo locale Administrators

Creazione della policy in Microsoft Intune tramite Settings Catalog

Per orchestrare la distribuzione centralizzata di Administrator Protection su tutti i dispositivi Windows 11 gestiti, lo strumento di riferimento è il Settings Catalog di Microsoft Intune.

Accedete alla console di Microsoft Intune admin center, navigate nel menu Devices > Manage devices > Configuration e selezionate Create > New Policy. Nella finestra di configurazione guidata, impostate come piattaforma Windows 10 and later e scegliete Settings catalog come tipologia di profilo.

Figura 3: Creazione di una nuova policy in Microsoft Intune

Assegnate al criterio un nome descrittivo e riconoscibile, ad esempio Windows 11 – Administrator Protection Configuration, prima di procedere alla schermata delle impostazioni.

Figura 4: Nome della Policy da creare

All’interno della sezione Configuration settings, cliccate su Add settings per aprire la libreria delle policy. Nel campo di ricerca digitate Local Policies Security Options e selezionate la categoria corrispondente. Tra le opzioni visualizzate, abilitate due impostazioni fondamentali: User Account Control Type Of Admin Approval Mode e User Account Control Behavior Of The Elevation Prompt For Administrator Protection.

Figura 5: Scelta delle impostazioni da configurare

Una volta aggiunte al pannello principale, configurate i singoli valori operativi:

Il parametro User Account Control Type Of Admin Approval Mode va impostato su Admin Approval Mode with Administrator protection. È questa la direttiva chiave che disattiva il modello split token tradizionale e costringe il sistema operativo a isolare i privilegi amministrativi in un profilo separato e temporaneo.

Il parametro User Account Control Behavior Of The Elevation Prompt For Administrator Protection determina la modalità di interazione dell’utente durante la richiesta di elevazione. Per rispettare i più rigorosi standard di sicurezza, selezionate Prompt for credentials on the secure desktop. In questo modo, qualsiasi richiesta di elevazione isolerà lo schermo nel Secure Desktop e richiederà obbligatoriamente l’autenticazione tramite PIN o biometria di Windows Hello for Business.

Figura 6: Configurazioni dei parametri

Conclusa la configurazione delle impostazioni, proseguite ignorando gli Scope tags se non previsti dalla vostra architettura e passate al tab Assignments. Il consiglio operativo è di assegnare inizialmente il profilo a un gruppo pilota dedicato di dispositivi Entra ID joined, evitando una distribuzione massiva immediata.

Figura 7: Assegnazione del profilo a un gruppo pilota dedicato

Figura 8: Schermata di riepilogo della creazione della policy per Administrator Protection

Figura 9: Creazione del profilo di configurazione completato con successo

Completato il salvataggio del profilo e forzata la sincronizzazione da parte dell’endpoint, ricordate che il riavvio completo della postazione è un passaggio obbligatorio: il kernel di Windows deve infatti riconfigurare il sottosistema dei token di sicurezza prima di rendere attiva la nuova modalità di elevazione.

Validazione della ricezione della policy e riavvio del client

Dopo aver avviato la sincronizzazione manuale dall’interfaccia delle impostazioni aziendali o aver atteso i normali tempi di applicazione delle policy, potete confermare che la postazione abbia effettivamente recepito le istruzioni aprendo il Registry Editor. Il percorso da ispezionare è HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\LocalPoliciesSecurityOptions. All’interno di questa chiave troverete registrati i valori UserAccountControl_TypeOfAdminApprovalMode e UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection, insieme alle stringhe che identificano il provider MDM vincente. La presenza di queste chiavi certifica che il profilo di Intune è stato applicato con successo sul dispositivo.

Nello specifico, dovete verificare che la voce DWORD UserAccountControl_TypeOfAdminApprovalMode_ProviderSet sia impostata sul valore 2. Questo parametro numerico è fondamentale perché attesta che il sistema operativo ha abbandonato la modalità legacy (1) e ha recepito l’abilitazione di Admin Approval Mode with Administrator protection (2).

A questo punto il riavvio completo della macchina è un passaggio non negoziabile. Poiché Administrator Protection modifica profondamente il funzionamento del Local Security Authority Subsystem Service (LSASS) e la struttura di generazione dei token all’accesso, il sistema operativo deve ricaricare i criteri di sicurezza a livello di kernel prima che la protezione entri in funzione.

Figura 10: Verifica nel Registry Editor dell’avvenuta ricezione della policy e delle relative configurazioni

Esperienza utente, verifica dell’elevazione e token virtuale

Dopo il riavvio della macchina, l’accesso dell’utente avviene come di consueto tramite Windows Hello for Business digitando il proprio PIN o sfruttando la biometria. A questo punto, però, sotto il cofano il sistema operativo ha modificato radicalmente la struttura di sicurezza della sessione interattiva: non esiste più alcuno split token amministrativo latente.

Figura 11: Login a Windows utilizzando Windows Hello for Business

Nel momento in cui avviate uno strumento o un’applicazione che necessita di privilegi elevati, ad esempio facendo clic destro sul menu Start e selezionando Terminal (Admin), il comportamento del sistema operativo cambia drasticamente rispetto al passato. Non vedrete più comparire il classico riquadro UAC con il semplice clic di approvazione “Yes/No”. Windows oscura l’intero schermo entrando nel Secure Desktop e richiede obbligatoriamente un’autorizzazione esplicita tramite Windows Hello for Business, pretendendo l’inserimento del PIN o la scansione biometrica registrata dall’utente.

Figura 12: Nuovo prompt di elevazione di Administrator Protection su Secure Desktop: la classica richiesta UAC è sostituita dalla richiesta esplicita del PIN o della biometria di Windows Hello for Business per autorizzare l’esecuzione

La vera rivoluzione architetturale si manifesta subito dopo aver confermato l’accesso. Aprendo la console elevata ed eseguendo il comando whoami, noterete che l’identità del processo non corrisponde più al vostro account utente standard. Al suo posto, il sistema restituirà un account transitorio locale gestito direttamente da Windows, riconoscibile dal prefisso ADMIN_ (come ad esempio NOMEMACCHINA\ADMIN_nomeutente). Si tratta di un’identità virtuale creata Just-in-Time esclusivamente per quel processo, garantendo che le attività ad alto privilegio rimangano confinate e non possano contaminare la sessione desktop principale.

Figura 13: il comando whoami restituisce l’identità isolata transitoria

Come potete osservare, il processo non viene eseguito nel contesto dell’account Entra ID collegato alla sessione interattiva. Il sistema restituisce l’identità locale win11-26h2\admin_nicolaferrini e posiziona la directory di lavoro all’interno del percorso dedicato C:\Users\ADMIN_NicolaFerrini.

Questo significa che Windows ha istanziato al volo un account amministrativo locale temporaneo dedicato unicamente a racchiudere questa sessione di PowerShell e i suoi eventuali processi figli. La vostra sessione desktop primaria continua a operare come utente standard privo di credenziali amministrative dormienti, impedendo a qualsiasi minaccia informatica o script malevolo eseguito in background di ereditare o intercettare token ad alto privilegio.

Convalida dell’integrità del token e gestione dell’account transitorio

Eseguendo il comando whoami /groups all’interno della console elevata, potete analizzare nel dettaglio la struttura del token d’accesso assegnato al processo.

A differenza della sessione desktop standard (in cui il gruppo era limitato a fini di sola negazione), il processo elevato viene eseguito a High Mandatory Level e dispone dell’appartenenza attiva e funzionante a BUILTIN\Administrators.

Aprendo lo snap-in Computer Management (compmgmt.msc) e controllando le proprietà del gruppo locale Administrators sotto Local Users and Groups, noterete un comportamento emblematico: Windows ha registrato dinamicamente l’account transitorio ADMIN_NicolaFerrini direttamente all’interno del gruppo degli amministratori locali.

Questo account virtuale viene gestito interamente dal Local Security Authority: esiste unicamente per la durata delle operazioni elevate autorizzate ed evita qualsiasi esposizione del profilo primario dell’utente, garantendo un isolamento ermetico tra l’attività ordinaria e i privilegi di sistema.

Figura 14: Convalida dei privilegi e dell’appartenenza al gruppo amministratori locali

Configurazione alternativa tramite Group Policy

Se gestite dispositivi appartenenti a un dominio Active Directory locale o se desiderate testare la funzionalità su una singola postazione senza transitare da Microsoft Intune, potete implementare Administrator Protection sfruttando direttamente le Group Policy (GPO di dominio) o il Local Group Policy Editor (gpedit.msc).

All’interno dell’editor delle policy, il percorso da raggiungere è: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.

In questa sezione dovete individuare e configurare due impostazioni chiave: User Account Control: Configure type of Admin Approval Mode e User Account Control: Behavior of the elevation prompt for administrators running with Administrator protection, come mostrato nella figura sotto:

Figura 15: Configurazione di Administrator Protection tramite Group Policy

Dopo aver confermato le modifiche, se state operando in un contesto di dominio eseguite un aggiornamento forzato delle policy tramite gpupdate /force. Per completare l’applicazione dei criteri e ricaricare l’architettura dei token nel Local Security Authority, il riavvio completo della postazione è un passaggio obbligatorio. Al successivo accesso, ogni richiesta di privilegi amministrativi attiverà la procedura di elevazione protetta.

Limitazioni note e considerazioni operative

L’adozione di Administrator Protection comporta una serie di impatti e vincoli operativi che dovete tenere in considerazione prima di procedere con la distribuzione negli ambienti di produzione.

Strumenti di amministrazione remota (RSAT) e deleghe Kerberos

Poiché il processo elevato non viene eseguito con il vostro account Entra ID ma con l’identità locale isolata ADMIN_, tutti gli strumenti che si basano sull’autenticazione integrata Windows o su ticket Kerberos di dominio (come gli strumenti RSAT, Active Directory Users and Computers, Group Policy Management Console o connessioni PowerShell remote) non possono riutilizzare il token dell’utente per autenticarsi sui server remoti. In questo scenario è necessario invocare esplicitamente credenziali amministrative separate oppure ricorrere a workstation di gestione dedicate (PAW).

Accesso remoto e sessioni di rete

Per impostazione predefinita, l’account transitorio ADMIN_ non può essere utilizzato per stabilire sessioni remote di rete o connessioni RDP con privilegi elevati. I criteri visibili nella Group Policy locale consentono di definire eccezioni per consentire il logon remoto con privilegi elevati a utenti o gruppi specifici di dominio, ma l’attivazione di tali eccezioni riduce la superficie di isolamento garantita dal modello Zero Trust locale.

Compatibilità con Windows LAPS e task pianificati

I processi pianificati tramite Utilità di pianificazione (Task Scheduler) configurati per essere eseguiti con i massimi privilegi richiedono l’autenticazione esplicita e non possono sfruttare l’elevazione Just-in-Time interattiva. Inoltre, gli scenari di supporto helpdesk basati su Windows LAPS (Local Administrator Password Solution) rimangono separati: LAPS gestisce la password dell’account amministratore locale integrato (disattivato di default), mentre Administrator Protection protegge gli utenti standard autorizzati a compiere elevazioni locali temporanee.

Conclusioni

L’introduzione di Administrator Protection in Windows 11 rappresenta uno dei cambiamenti architetturali più rilevanti degli ultimi anni nella gestione dei privilegi a livello endpoint, colmando un divario storico nel modello User Account Control. Per oltre quindici anni, il concetto di split token ha rappresentato un compromesso accettabile tra operatività quotidiana e sicurezza, lasciando tuttavia esposta la sessione a vettori di attacco mirati alla manipolazione dei token dormienti e ai movimenti laterali.

Passare da un token amministrativo silente a una vera elevazione Just-in-Time isolata concretizza in modo tangibile i principi cardine del modello Zero Trust: non fidarsi mai implicitamente del contesto di esecuzione, verificare sempre l’identità dell’operatore tramite canali a prova di phishing come Windows Hello for Business e concedere esclusivamente i privilegi minimi necessari per la durata strettamente indispensabile.

La creazione dinamica di account transitori dedicati per ogni singolo processo elevato interrompe definitivamente la catena di attacco sul desktop interattivo, impedendo che software malevolo o script in background possano scalare i privilegi all’insaputa dell’utente. Sebbene l’implementazione richieda un’attenta valutazione dell’impatto su strumenti legacy, deleghe Kerberos e procedure di assistenza remota, la possibilità di distribuire e centralizzare questa funzionalità tramite Microsoft Intune o Group Policy fornisce ai team IT uno strumento essenziale per elevare in modo netto la postura di sicurezza dell’intero parco macchine aziendale.