1 11/10/2026 9 min

Perché toccare l’account Administrator locale con Intune

L’account Administrator locale è uno dei punti più delicati di un endpoint Windows. Se resta abilitato e con nome prevedibile, offre un bersaglio facile per tentativi di accesso locali, abuso di credenziali riutilizzate e movimenti laterali in caso di compromissione. Se invece lo disabiliti senza una strategia alternativa, rischi di tagliare fuori chi deve fare assistenza sul dispositivo. Con Intune il problema non è solo “abilitare o disabilitare”: il punto vero è farlo in modo governato, con una baseline chiara, un account amministrativo alternativo e un percorso di rollback già deciso.

Il criterio corretto è semplice: l’account Administrator locale non dovrebbe essere lasciato attivo per abitudine. Va tenuto sotto controllo, idealmente con una policy che lo disabiliti quando non serve, oppure lo abiliti solo per scenari precisi e temporanei. In ambienti gestiti, la scelta più pulita è combinare Intune con Windows LAPS o con un modello equivalente di gestione delle credenziali locali, così da non dipendere da una password statica e condivisa.

Decisione architetturale: disabilitare quasi sempre, abilitare solo per eccezione

Se stai progettando la configurazione, la regola pratica è questa: disabilita l’Administrator locale sui dispositivi standard e usa un altro account amministrativo locale o di dominio per il supporto. L’abilitazione dell’account built-in ha senso in casi limitati, per esempio durante migrazioni, recovery procedure o fasi iniziali di onboarding in cui serve una via di accesso di emergenza. Anche in quei casi, l’account va trattato come temporaneo, non come credenziale operativa permanente.

La parte che spesso viene sottovalutata è l’impatto operativo: se disabiliti l’account senza verificare che esista un canale alternativo di amministrazione, il problema non emerge subito. Esplode quando serve un intervento locale e non c’è più nessuno in grado di aprire una sessione elevata. Per questo, prima di cambiare la policy, devi sapere chi amministra i device, con quale account, e come recuperi un endpoint fuori banda.

Come Intune gestisce l’account locale Administrator

In Intune la gestione dell’account Administrator locale passa tipicamente da una policy di configurazione dei dispositivi Windows. A seconda della versione del tenant, puoi usare un profilo dedicato ai Local Users and Groups, un’impostazione equivalente tramite Settings catalog o una configurazione specifica per l’amministrazione degli account locali. L’obiettivo è sempre lo stesso: definire se l’account built-in deve essere abilitato, disabilitato, rinominato o mantenuto in uno stato coerente con la tua baseline.

Il dettaglio importante è che non stai lavorando su un utente qualsiasi. L’account built-in ha un’identità speciale nel sistema e in alcuni scenari può comportarsi in modo diverso dagli account creati manualmente. Per questo conviene evitare configurazioni “creative” e restare sul percorso supportato da Microsoft, controllando sempre il risultato sul client con strumenti locali e con la reportistica di Intune.

Abilitare o disabilitare: percorso operativo in Intune

Il modo più pulito per procedere è usare una policy mirata, assegnata a un gruppo di test prima della distribuzione ampia. Se il tenant espone il profilo per gli account locali, il flusso è questo: crei il profilo, scegli la piattaforma Windows, imposti il comportamento dell’account Administrator, assegni il gruppo e verifichi la ricezione sul device. Se invece la tua interfaccia usa il Settings catalog, cerchi l’impostazione che governa l’account locale integrato e applichi lo stesso principio: una sola fonte di verità, niente sovrapposizioni tra profili che si pestano i piedi.

Quando devi disabilitare, il punto chiave è evitare conflitti con altre policy che riabilitano l’account o ne cambiano il nome. Quando devi abilitare, verifica prima che la password sia governata correttamente e che non stai esponendo un accesso prevedibile e non monitorato. In pratica: l’abilitazione senza gestione della credenziale è solo un buco operativo più comodo da raggiungere.

Sequenza consigliata per un change controllato

Se vuoi ridurre il rischio, lavora in questa sequenza:

  1. Identifica i dispositivi target e il gruppo pilota in Intune.
  2. Verifica che esista un account amministrativo alternativo o una procedura di recovery.
  3. Controlla se Windows LAPS è già attivo; se non lo è, pianifica la gestione della password locale prima del cambio.
  4. Applica la policy su un sottoinsieme ristretto di device.
  5. Conferma lo stato sul client e nei report Intune prima di estendere la distribuzione.

Questa sequenza evita l’errore classico: cambiare la policy su tutta la flotta e accorgersi dopo che i tecnici non hanno più un account locale utilizzabile. In un ambiente reale, il problema non è quasi mai il toggle in sé; è il fatto che nessuno ha verificato il fallback amministrativo.

Verifiche sul client: cosa controllare davvero

Dopo l’applicazione della policy, non fermarti alla schermata di Intune che dice “Succeeded”. Serve una verifica locale. Sul dispositivo puoi controllare lo stato dell’account con strumenti amministrativi Windows e con le policy effettivamente applicate. Per esempio, puoi usare PowerShell per vedere se l’account esiste e se risulta abilitato:

Get-LocalUser -Name Administrator | Select-Object Name, Enabled, LastLogon

Atteso: Enabled deve riflettere il comportamento desiderato. Se la policy dice disabilitato ma il comando mostra ancora True, hai un problema di conflitto, ritardo di sincronizzazione o applicazione fallita. In quel caso controlla anche il log MDM locale e la sincronizzazione del device con Intune.

Un secondo controllo utile è verificare il profilo effettivamente ricevuto dal client. Sul piano operativo, i log da guardare sono quelli del canale MDM e dell’enrollment. Se il client non riceve la policy, non ha senso inseguire il sintomo sul sistema locale: devi prima capire se il device è davvero in scope, se il gruppo Azure AD è corretto e se non esistono filtri di assegnazione che escludono il dispositivo.

Il caso più comune: la policy sembra applicata, ma l’account resta attivo

Questo è il classico scenario da troubleshooting. Le cause più probabili sono tre. La prima: c’è un’altra policy che sovrascrive la tua configurazione. La seconda: il device non ha ancora completato la sincronizzazione MDM o è in stato non sano. La terza: stai usando un metodo di configurazione non coerente con la versione del profilo o con la release di Windows installata sul client.

La falsificazione rapida si fa così: controlli in Intune la pagina del dispositivo, verifichi lo stato del profilo, poi sul client controlli l’ultimo sync e lo stato dell’account locale. Se il profilo risulta fallito, hai già il primo indizio. Se il profilo risulta riuscito ma il sistema non cambia, devi cercare un conflitto o un’impostazione concorrente. Se invece il profilo non compare proprio sul device, il problema è di targeting o di assegnazione, non dell’account.

Windows LAPS: il pezzo che rende sicuro il cambio

Disabilitare l’Administrator locale senza una gestione credenziali è una mezza soluzione. La combinazione corretta, nella maggior parte dei casi, è disabilitare l’account built-in e usare Windows LAPS per conservare un canale di accesso locale controllato e ruotato. In questo modo non dipendi da una password condivisa tra tecnici o da un account lasciato attivo per comodità.

Il vantaggio pratico è doppio: abbassi la superficie d’attacco e hai una procedura di recupero più pulita. Se un device perde il canale di gestione, puoi recuperare la password locale secondo i permessi previsti, senza riabilitare per forza l’account built-in. Questo è il punto che spesso fa la differenza tra una baseline solida e una configurazione fragile che funziona solo finché tutto va bene.

Blocco operativo: cosa fare se devi riabilitare Administrator

La riabilitazione ha senso solo se c’è un motivo chiaro e temporaneo. Per esempio: un device isolato, una procedura di recovery, una migrazione di strumenti di supporto o un intervento in cui l’account alternativo non è disponibile. In quel caso, applica il cambio in modo limitato, su un gruppo ristretto, e pianifica già il ritorno allo stato precedente.

Prima di riabilitare, verifica sempre due cose: che la password sia sotto controllo e che il dispositivo non sia esposto inutilmente a login locali non necessari. Dopo l’intervento, riporta la policy allo stato più restrittivo possibile. L’obiettivo non è lasciare l’account attivo “per sicurezza”; l’obiettivo è usarlo come strumento di eccezione e poi richiuderlo.

Errori che vedo spesso nei tenant Intune

Il primo errore è avere più configurazioni che toccano lo stesso comportamento: una policy di sicurezza, una baseline, un profilo custom. Il risultato è un comportamento apparentemente casuale. Il secondo errore è assegnare la policy a gruppi troppo ampi senza test su un sottoinsieme rappresentativo. Il terzo è non documentare chi possiede il rollback e quale impostazione va rimossa per tornare allo stato precedente.

Un altro errore frequente è confondere il nome dell’account con il suo stato. Rinominare l’account built-in non equivale a metterlo in sicurezza. Disabilitarlo senza gestire il resto dell’accesso locale non basta. La sicurezza vera nasce dalla combinazione di stato dell’account, gestione della password, privilegi minimi e tracciabilità.

Checklist pratica per produzione

Prima di cambiare l’account Administrator con Intune, tieni questa checklist corta ma concreta:

  • Ho un account amministrativo alternativo o una procedura di recovery testata.
  • Ho verificato se Windows LAPS è attivo o pianificato.
  • Ho una sola policy che governa l’account locale, senza conflitti.
  • Ho un gruppo pilota e un criterio di estensione graduale.
  • So come verificare sul client lo stato reale dell’account.
  • Ho un rollback: quale policy rimuovere o quale impostazione ripristinare.

Se anche uno di questi punti manca, il cambio non è pronto per la produzione. Non è un problema teorico: sui device reali i dettagli di assegnazione, timing e sincronizzazione contano più della teoria della policy.

Quando conviene documentare il cambio invece di improvvisare

Ogni volta che l’account Administrator locale entra in un perimetro gestito da Intune, vale la pena scrivere due righe operative: stato atteso, stato osservato, chi approva il cambio, chi verifica il client e come si torna indietro. È una di quelle configurazioni dove la memoria di team non basta. Dopo qualche mese nessuno ricorda più se l’account era disabilitato per design, per test o per una deroga temporanea.

La regola che funziona è semplice: se l’account serve, abilitalo in modo controllato; se non serve, disabilitalo e sostituiscilo con una gestione credenziale seria. Intune è lo strumento di enforcement, non la soluzione architetturale completa. La parte importante resta il modello di accesso amministrativo che decidi prima di premere “Assign”.