Gestire i Local User Group Membership con Microsoft Intune
Introduzione
La gestione del gruppo Administrators locale sui pc Windows è uno di quei temi che spesso vengono rimandati, ma che in realtà ha un impatto diretto sulla superficie di attacco dell’ambiente. In molte aziende capita di trovare dispositivi dove, nel tempo, sono stati aggiunti utenti locali, utenti di dominio o gruppi non più necessari, con un risultato prevedibile: privilegi amministrativi troppo estesi e poca visibilità su chi ha davvero accesso elevato.
Con Microsoft Intune, oggi è possibile gestire in modo centralizzato la membership dei gruppi locali built-in (incluso Administrators) usando il profilo Local user group membership nell’area Endpoint security > Account protection. Questo profilo consente di aggiungere, rimuovere o sostituire i membri del gruppo, con un modello molto più governabile rispetto ad approcci manuali o non uniformi. È importante anche chiarire un punto chiave. Se l’obiettivo è togliere tutti tranne Administrator, l’azione corretta è un replace della membership del gruppo Administrators, includendo esplicitamente l’account built-in Administrator (più eventuali account/gruppi autorizzati). Questo passaggio non è opzionale, infatti la documentazione Microsoft specifica che l’account built-in Administrator deve restare membro del gruppo Administrators e che il tentativo di rimuoverlo fallisce a livello SAM/OS.
In questo articolo vediamo perché conviene gestire la membership locale con Microsoft Intune, come configurarla correttamente in modo sicuro e cosa controllare in fase di troubleshooting.
Perché gestire Local user group membership
Il gruppo Administrators locale dispone di privilegi molto elevati sul dispositivo. Lasciare membri residui, obsoleti o non strettamente necessari in questo gruppo significa aumentare il rischio operativo e la superficie di attacco. Microsoft stessa, nella documentazione di Microsoft Intune e Windows LAPS, evidenzia che i privilegi amministrativi locali sono un elemento sensibile da governare con attenzione, sia per ridurre il rischio di movimenti laterali sia per proteggere gli scenari di supporto remoto e recupero dei dispositivi.
Se volete approfondire la configurazione di Windows LAPS con Intune come approfondimento pratico complementare a questo contenuto, ho trattato il tema in un articolo dedicato che trovate alla pagina How to set up Windows LAPS in Microsoft Intune.
Negli scenari Microsoft Entra joined, inoltre, è importante ricordare che al momento del join alcuni security principal vengono aggiunti automaticamente al gruppo degli amministratori locali del dispositivo: il ruolo Microsoft Entra Joined Device Local Administrator, il ruolo Global Administrator e l’utente che esegue il join. Questo spiega perché, in assenza di una governance esplicita, sia facile ritrovarsi con privilegi amministrativi non desiderati sui client.
Se si utilizza Windows Autopilot, Microsoft prevede anche l’opzione User account type per evitare che l’utente che esegue il provisioning diventi amministratore locale, impostandolo come Standard user. È una misura molto utile in fase di enrollment, ma non sostituisce il controllo centralizzato della membership del gruppo Administrators: i due approcci sono complementari.
Un altro motivo forte per usare il profilo in Microsoft Intune è il superamento dei meccanismi legacy. Il CSP moderno LocalUsersAndGroups supporta sia logiche di Update (aggiunta/rimozione selettiva) sia di Replace (sostituzione completa della membership) ed è il modello raccomandato da Microsoft a partire da Windows 10 versione 20H2. Al contrario, applicare LocalUsersAndGroups insieme a RestrictedGroups sullo stesso dispositivo non è supportato e può produrre risultati imprevedibili.
Infine, la gestione tramite Intune offre un vantaggio operativo concreto con assegnazioni centralizzate, reporting, stati di applicazione, visibilità nel per-setting status con le specifiche del profilo, e la possibilità di forzare il check-in tramite azione remota Sync dal portale durante rollout e troubleshooting. Questo livello di controllo cambia in modo sostanziale la qualità della gestione rispetto ad approcci non centralizzati.
Come gestire Local user group membership
Vediamo ora come gestire la funzionalità Local user group membership tramite Microsoft Intune. Questo profilo è supportato sui dispositivi Windows 10 versione 20H2 e successive e Windows 11, e la configurazione viene applicata tramite il CSP Windows LocalUsersAndGroups.
Nel Microsoft Intune admin center, il percorso è Endpoint security > Account protection dove è disponibile il profilo Local user group membership. Microsoft ha inoltre consolidato i precedenti profili di identity/account protection nel nodo Account protection, che oggi rappresenta il punto di riferimento per queste configurazioni.
Prima di iniziare con la configurazione passo-passo, è utile richiamare una best practice operativa che ripeto ormai in ogni articolo. Prima di un rollout esteso, conviene sempre usare un gruppo pilota e validare comportamento, applicazione della policy e reporting su un numero limitato di dispositivi rappresentativi (ad esempio Microsoft Entra joined e Microsoft Entra hybrid joined, se entrambi presenti). Questo non è un vincolo imposto dal prodotto, ma è particolarmente importante quando si interviene sulla membership del gruppo Administrators locale.
Dal punto di vista funzionale, il profilo consente di gestire i gruppi locali built-in tramite regole che definiscono:
- il gruppo locale da modificare
- l’azione da applicare (Add, Remove, Replace)
- la modalità di selezione dei membri (Users oppure Manual). In particolare, la modalità Users è supportata solo per dispositivi Microsoft Entra joined, mentre la modalità Manual è supportata sia per dispositivi Entra joined sia Entra hybrid joined e consente di specificare utenti/gruppi tramite SID, domain\username o username.
È utile ricordare anche che la lista dei gruppi locali gestibili da questa policy non è arbitraria. Microsoft Intune limita la selezione ai gruppi locali built-in supportati (quelli valutati al logon), come documentato da Microsoft. Questo è un dettaglio importante da chiarire subito, perché evita aspettative errate su gruppi personalizzati o non supportati.
Attenzione: i gruppi Microsoft Entra distribuiti con questa policy non si applicano alle connessioni Remote Desktop. Se l’obiettivo è governare i permessi RDP su dispositivi Microsoft Entra joined, Microsoft indica di aggiungere il SID dell’utente individuale al gruppo locale appropriato, anziché usare solo il gruppo Entra
Creazione del profilo in Microsoft Intune
Nel portale Microsoft Intune admin center navigate su Endpoint Security > Account protection e fate clic su Create Policy. Il profilo Local user group membership è disponibile in questo nodo e consente di gestire la membership dei gruppi locali built-in sui dispositivi Windows supportati
Impostate Platform = Windows e Profile = Local user group membership, quindi proseguite facendo clic su Create. Questo profilo usa il CSP Windows LocalUsersAndGroups per applicare le configurazioni sui client.
Nella sezione Basics proseguite con nome e descrizione del profilo (in questo esempio ho impostato Manage Administrators Local Group). Una naming convention chiara aiuta molto nelle fasi successive di monitoraggio e troubleshooting. Al termine, fate clic su Next.
Come togliere tutti tranne Administrator
Se il vostro obiettivo è ripulire il gruppo Administrators lasciando solo l’account built-in Administrator (più eventuali gruppi/utenti autorizzati), dovete usare l’azione di sostituzione completa della membership. Nella pagina Configuration settings fate click su Add per creare una nuova regola
Come possiamo notare in Figura 5, la policy non è generica su qualsiasi gruppo locale. In Intune, la lista è limitata ai sei gruppi built-in valutati al logon. Nello specifico abbiamo Administrators, Users, Guests, Power Users, Remote Desktop Users e Remote Management Users. Potete trovare maggiori informazioni alla pagina ufficiale Account protection policy for endpoint security in Intune. Nel nostro scenario il focus è il gruppo Administrators, quindi in Local group selezionate il gruppo Administrators
In Group and user action selezionate Add (Replace). Questa opzione sostituisce i membri del gruppo con quelli che specificheremo ed è, di fatto, equivalente al comportamento di un Restricted Group. I membri non esplicitamente indicati nella policy verranno quindi rimossi.
Attenzione: se sullo stesso gruppo coesistono configurazioni di tipo Replace e Update, prevale Replace
Microsoft Intune ci offre due modalità di selezione per i membri del gruppo:
- Users: selezione diretta di utenti o gruppi da Microsoft Entra ID (supportata solo su device Microsoft Entra joined)
- Manual: inserimento manuale tramite SID, domain\username o username (supportata su device Entra joined e Entra hybrid joined)
Nel nostro caso, in User selection type selezioniamo Manual. Infine, facciamo click su Select user(s) che aprirà il pannello di inserimento manuale dei membri
Nel wizard che si apre, facciamo click su Add e quando apparirà la textbox per l’inserimento dell’account utente, digitiamo Administrator. Infine, proseguiamo con Save.
Attenzione: quando usate il replace sul gruppo Administrators, dovete includere esplicitamente l’account built-in Administrator tra i membri da mantenere come mostrato in Figura 8. Se invece provate a rimuoverlo, l’operazione fallisce con errore 0x55b – ERROR_SPECIAL_ACCOUNT (“Cannot perform this operation on built-in accounts”)
Una volta chiuso il wizard, verificate che i valori inseriti siano corretti. Se necessario, potete fare nuovamente clic su Add per creare un’altra regola (ad esempio per un diverso gruppo locale o un’altra azione). Quando avete terminato, proseguite con Next. Tenete presente che in una singola regola potete anche selezionare più gruppi locali, ma la stessa azione si applicherà a tutti i gruppi scelti in quella regola.
Nella sezione Scope tags (opzionale) lasciare Default, oppure selezionare uno scope tags già creato in precedenza nel vostro ambiente Intune. Nel nostro caso lasceremo quello di default. Successivamente cliccate su Next.
Nella sezione Assignments assegnate la policy al target desiderato. Cercate il gruppo su cui volete applicare la configurazione tramite il campo di ricerca, selezionatelo e proseguite con Next
Arrivati alla sezione Review + create, verificate che tutti i dettagli della configurazione siano corretti, inclusi i gruppi di assegnazione. Se è tutto ok, proseguire cliccando su Save.
A questo punto, tornando nella pagina principale di Endpoint security > Account protection, troverete la policy appena creata nell’elenco delle policy disponibili (nel mio caso “Manage Administrators Local Group”). Da qui potrete aprirla per verificare assegnazioni e stato di distribuzione, e poi passare alle attività di monitoraggio e troubleshooting.
Vediamo adesso come verificare che l’impostazione sia stata applicata correttamente al nostro device di test. Apriamo la policy appena creata e, nel riquadro Device and user check-in status, facciamo clic su View report
La vista View report mostra il dettaglio dei dispositivi e degli utenti che hanno ricevuto la policy, inclusi lo stato di check-in e l’ultima sincronizzazione relativa a quel criterio. Nel nostro caso, la policy risulta correttamente applicata e il Check-in status riporta esito positivo
Troubleshooting
Vediamo adesso alcuni scenari ricorrenti di troubleshooting. In questa sezione verificheremo end-to-end che il workflow funzioni correttamente e dove intervenire in caso di anomalie, sia dal portale Microsoft Intune sia lato client Windows.
La policy non si applica subito: check-in e sync
Uno dei motivi più comuni di non vedere ancora i risultati è semplicemente il timing del check-in. Il ciclo di manutenzione standard è circa ogni 8 ore, con check-in più frequenti subito dopo l’enrollment. Per accelerare la verifica, puoi forzare un sync dal portale Intune navigando in Devices > All devices > [select_your_device] > Sync. La remote action Sync forza il device a fare check-in con Intune e a ricevere policy pendenti, ed è pensata proprio per validazione e troubleshooting senza attendere il prossimo ciclo schedulato.
Log lato client: Event Viewer
Se volete capire il motivo reale di un errore, la documentazione del CSP LocalUsersAndGroups è molto chiara. Dopo l’applicazione della policy, dovete controllare il log eventi in Event Viewer > Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin e cercare la stringa LocalUsersAndGroups. È il punto migliore per vedere il risultato effettivo dell’elaborazione della policy lato client. Questo passaggio è prezioso soprattutto quando Intune mostra solo uno stato di errore generico ma ti serve il dettaglio tecnico, ad esmepio il nome account non risolto, SID errato, tentativo di rimuovere built-in Administrator, ecc.
Nel nostro caso, come mostrato in Figura 17, l’operazione è andata a buon fine e il gruppo Administrators contiene solo l’account built-in Administrator. Se il gruppo avesse contenuto altri membri non inclusi nella configurazione Add (Replace), questi sarebbero stati rimossi, come previsto dal comportamento di replace/restrict del CSP.
Errore classico: escludere l’account built-in Administrator dal Replace
Vediamo adesso un caso particolare: l’esclusione dell’account Administrator dal Replace. Questo uno degli errori più frequenti quando si prova a ripulire tutto troppo aggressivamente. Se usate Add (Replace) sul gruppo Administrators e non includete l’account built-in Administrator, il sistema blocca la rimozione a livello SAM/OS e restituisce l’errore 0x55b – ERROR_SPECIAL_ACCOUNT con il messaggio “Cannot perform this operation on built-in accounts”. La fix è molto semplice, è sufficiente modificare la policy e aggiungere Administrator tra i membri da mantenere. La documentazione Microsoft indica esplicitamente che, in modalità Replace, l’account built-in Administrator va sempre incluso (vedi Policy CSP – LocalUsersAndGroups).
Conflitti e sovrapposizioni di policy
IN caso di conflitti di policy, ci sono due situazioni diverse da distinguere quando si gestisce la membership dei gruppi locali con Local user group membership:
- stesso gruppo con azioni di Replace e Update
- conflitti tra policy
Nel primo caso, se sullo stesso gruppo vengono configurate azioni di tipo Replace/Restrict e Update, vince Replace. Questo comportamento è previsto e non viene considerato conflitto in quel caso specifico.
Nel secondo caso, se più policy producono una configurazione in conflitto per la stessa membership, Intune segnala il conflitto nel portale e le impostazioni in conflitto non vengono inviate al dispositivo. In questo scenario è necessario riallineare le policy prima che la configurazione possa essere applicata correttamente.
Attenzione: non mescolare le impostazioni di LocalUsersAndGroups con RestrictedGroups sullo stesso dispositivo. Microsoft lo sconsiglia perché è un comportamento non supportato e potenzialmente imprevedibile
Problemi di Name/SID lookup
Se state usando la modalità Manual e inserite nomi o SID, il rischio principale è l’errore di risoluzione dell’identità. La documentazione del CSP LocalUsersAndGroups segnala che:
- nomi o SID di gruppi non validi vengono saltati
- le parti valide della policy vengono comunque applicate
- l’errore viene restituito a fine processing
- per i gruppi di dominio conviene usare il formato domain\group_name (formato fully qualified)
È utile aggiungere anche due dettagli pratici spesso trascurati:
- per utenti Microsoft Entra inseriti manualmente, il formato richiesto è AzureAD\userUPN
- per i gruppi Microsoft Entra, il nome del gruppo non è supportato in questa policy e va usato il SID del gruppo (securityIdentifier)
Esiste anche un metodo specifico per il troubleshooting del lookup SID/Nome, con logging LSA (lsp.log) lato client. Di seguito i comandi PowerShell, da eseguire come amministratore, per attivare il logging (il file di log viene scritto in C:\Windows\debug\lsp.log):
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LspDbgInfoLevel -Value 0x800 -Type dword -Force
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LspDbgTraceOptions -Value 0x1 -Type dword -Force
Per disattivare il logging:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LspDbgInfoLevel -Value 0x0 -Type dword -Force
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LspDbgTraceOptions -Value 0x0 -Type dword -Force
Conclusioni
Gestire la membership del gruppo Administrators locale con Microsoft Intune non è solo una comodità amministrativa, ma una misura concreta di governance. Il profilo Local user group membership dell’area Endpoint security > Account protection consente di standardizzare i privilegi locali sui pc Windows in modo centralizzato, con reporting e troubleshooting integrati. Come misura complementare, è fortemente consigliato abbinare questa governance a Windows LAPS gestito da Intune (vedi articolo How to set up Windows LAPS in Microsoft Intune), così da proteggere e ruotare la password dell’account amministratore locale built-in che, per definizione, resta presente sul sistema.
