Bloccare il Prompt dei comandi con Intune

Bloccare il Prompt dei comandi con Intune senza rompere il resto

Se l’obiettivo è impedire l’uso di Prompt dei comandi su Windows gestiti con Intune, la strada più pulita è trattarlo come un controllo di accesso, non come un trucco locale. Il punto non è solo nascondere cmd.exe, ma decidere chi deve essere bloccato, su quali dispositivi e con quale impatto su supporto, automazioni e strumenti di amministrazione.

Nelle implementazioni reali il blocco totale è spesso una cattiva idea: gli utenti standard non devono aprire il prompt, ma i team IT, i task di manutenzione e alcune applicazioni legacy possono dipenderne. Per questo conviene separare il controllo in due livelli: una policy per gli utenti finali e una eccezione per i gruppi amministrativi o per i device di servizio.

Quale meccanismo usare in Intune

Su Intune il metodo più diretto è una Configuration profile basata su Settings catalog o su Administrative Templates, quando disponibile nella tua build di Windows. In alternativa, se vuoi un controllo più granulare o devi standardizzare su più versioni, puoi usare una policy custom che agisca sulle chiavi di registro o su impostazioni equivalenti supportate dal sistema operativo.

La logica da seguire è semplice: se l’interfaccia di Intune espone già l’impostazione “prevent access to the command prompt”, usa quella. Se non la trovi, non improvvisare con script invasivi: prima verifica la disponibilità nel catalogo impostazioni del tenant e la compatibilità con la versione di Windows in uso.

Decisione architetturale: blocco utente o blocco macchina

Prima di creare la policy, va chiarito se il blocco deve seguire l’utente oppure il dispositivo. In ambienti con utenti condivisi o postazioni kiosk, il blocco a livello macchina è più coerente. In scenari enterprise classici, invece, il blocco per gruppo utente è preferibile perché consente eccezioni più pulite e riduce il rischio di interrompere l’operatività IT.

Il criterio pratico è questo: se un device può essere usato da più persone con profili diversi, non legare tutto a una singola configurazione locale. Se il device è dedicato a un ruolo preciso, allora una policy device-scoped evita ambiguità e semplifica il supporto.

Impostazione consigliata in Intune

Il percorso operativo tipico è creare un profilo di configurazione, assegnarlo a un gruppo pilota e verificare prima la propagazione su un singolo endpoint. In pratica:

1. Crea un gruppo di test con pochi utenti o dispositivi.
2. Apri Intune admin center e vai su Devices > Windows > Configuration profiles.
3. Crea un nuovo profilo e scegli il tipo più adatto: Settings catalog se l’opzione è presente, oppure Administrative Templates se la policy è esposta lì.
4. Individua l’impostazione relativa al blocco del prompt dei comandi e impostala su Enabled.
5. Se disponibile, configura anche l’opzione che impedisce l’esecuzione degli script batch, perché altrimenti il blocco può essere aggirato da file .bat o .cmd.
6. Assegna il profilo al gruppo pilota e salva.

Se stai lavorando con policy che si traducono in registro, il comportamento tipico è quello di una chiave sotto HKCU o HKLM che controlla l’esecuzione del prompt e l’eventuale limitazione dei batch. Non dare per scontato il percorso esatto senza verificare il mapping del profilo nel tenant, perché tra versioni di Windows e modelli di policy il dettaglio cambia.

Perché bloccare solo cmd.exe non basta

Bloccare il prompt dei comandi è utile, ma non è una barriera completa. Molte attività possono essere portate avanti da PowerShell, strumenti remoti, script eseguiti da software di terze parti o interfacce grafiche che invocano comandi in background. Se il tuo obiettivo è ridurre l’abuso da parte dell’utente finale, devi ragionare sul comportamento complessivo della postazione, non sul singolo eseguibile.

In particolare, se lasci aperti PowerShell, Windows Terminal o launcher che accettano argomenti arbitrari, il blocco di cmd.exe diventa soprattutto un deterrente. È comunque valido, ma va presentato come un controllo parziale, non come un blocco assoluto dell’esecuzione di comandi.

Eccezioni: come non bloccare il team sbagliato

La parte che crea più problemi non è la policy in sé, ma l’eccezione. Se assegni il blocco a tutti e poi provi a escludere manualmente i tecnici, ti ritrovi presto con eccezioni sparse e non documentate. Molto meglio creare da subito tre gruppi distinti: utenti standard, operatori IT e dispositivi speciali.

• Utenti standard: blocco attivo.
• Operatori IT: esclusi o coperti da una policy diversa.
• Dispositivi speciali: valutazione separata, soprattutto se eseguono manutenzione locale o applicazioni legacy.

Il vantaggio è operativo: quando un ticket arriva, non devi capire se il problema è la policy o il profilo del singolo utente. Guardi l’assegnazione del gruppo e chiudi subito il dubbio.

Verifica sul client: cosa controllare davvero

Dopo l’assegnazione, non limitarti a vedere che la policy risulta “Succeeded” nel portale. La verifica utile è lato endpoint, perché lì emergono i conflitti tra profili, la latenza di sincronizzazione e le eventuali sovrascritture locali.

1. Forza una sincronizzazione da Accesso lavoro o scuola nelle impostazioni di Windows, oppure attendi il normale refresh di Intune.
2. Controlla lo stato del profilo nel portale Intune nella sezione del dispositivo o dell’utente assegnato.
3. Apri il client e verifica se cmd.exe si avvia o se compare un messaggio di blocco.
4. Controlla i log di gestione MDM se il risultato non corrisponde all’atteso.

Se il comportamento è incoerente, il primo posto da guardare non è il prompt, ma la coerenza tra assegnazione, gruppo e tipo di policy. In molti casi il profilo è corretto, ma finisce su un gruppo sbagliato o in conflitto con una configurazione precedente.

Diagnosi dei casi che sembrano fallimenti ma non lo sono

Ci sono tre situazioni frequenti in cui sembra che la policy non funzioni, mentre in realtà il problema è altrove. La prima è il ritardo di propagazione: il dispositivo ha ricevuto la policy, ma l’utente non ha ancora fatto logoff/logon o il refresh non è completato. La seconda è il conflitto con un’altra policy che riabilita il prompt. La terza è l’uso di un canale alternativo, come PowerShell o un’applicazione che lancia comandi in background.

Per falsificare queste ipotesi in pochi minuti: verifica lo stato della policy nel portale, confronta i gruppi assegnati e testa un secondo account sullo stesso dispositivo. Se il secondo account è bloccato e il primo no, il problema è quasi sempre nel targeting utente o nelle eccezioni.

Approccio più robusto: affiancare il blocco con controlli di applicazione

Se stai progettando un ambiente con requisiti più severi, il blocco del prompt va affiancato a controlli di esecuzione applicativa. In pratica, non basta impedire l’apertura di una shell: devi decidere quali binari, script e strumenti siano consentiti. Altrimenti l’utente trova un’altra strada e il controllo perde valore.

Qui il punto non è fare hardening aggressivo a tutti i costi, ma costruire una baseline coerente. Per esempio, in un parco macchine destinato a ufficio, il prompt può essere bloccato insieme a regole che limitano script non autorizzati e strumenti di amministrazione non necessari. In un reparto tecnico, invece, il blocco può essere riservato solo ai profili non privilegiati.

Rollback e impatto operativo

Il rollback deve essere immediato e documentato. Se la policy blocca utenti che devono lavorare, la correzione più veloce è rimuovere l’assegnazione dal gruppo interessato o impostare il profilo su Not configured. In Intune questa è la vera leva di sicurezza: il controllo centralizzato ti consente di tornare indietro senza toccare manualmente ogni macchina.

Prima di estendere il blocco a tutta l’organizzazione, misura il blast radius: quanti utenti usano ancora il prompt per attività legittime, quali applicazioni dipendono da batch file e quali team hanno bisogno di eccezioni. Se non hai questi dati, il rischio non è tecnico ma operativo: trasformi un piccolo controllo in un ticket storm.

Una regola pratica che evita errori inutili

La regola migliore è questa: blocca il Prompt dei comandi solo dove hai una ragione chiara e un gruppo ben definito. Non usarlo come scorciatoia per “migliorare la sicurezza” in modo generico. Funziona quando è parte di una politica di endpoint coerente, con eccezioni controllate e verifica lato client. Funziona molto peggio quando diventa un toggle buttato in produzione senza analisi delle dipendenze.

In sintesi, Intune ti dà il controllo centrale; sta a te usarlo con targeting preciso, test pilota e rollback semplice. È questo che rende il blocco del prompt un intervento utile invece che un problema nuovo travestito da hardening.