Impostare la policy di esecuzione PowerShell con Intune e GPO

La regola che conta davvero: chi applica la policy per primo

Quando si parla di policy di esecuzione PowerShell, il punto non è solo impostare la regola, ma capire quale motore la sta imponendo. In ambiente Windows moderno puoi trovarla definita in tre posti diversi: criterio locale, Group Policy di dominio e gestione MDM tramite Intune. Se questi livelli non sono allineati, la macchina non “sceglie” la policy più comoda: applica quella che ha priorità e scope coerenti con il canale di gestione attivo.

La conseguenza pratica è semplice: una macchina ibrida, iscritta a Intune e joinata a dominio, può mostrare un comportamento diverso da quello atteso se la GPO sovrascrive la configurazione MDM oppure se il profilo Intune non è stato assegnato al gruppo corretto. Quindi la prima decisione architetturale è questa: stai governando endpoint cloud-only, domain-joined o hybrid? Da lì cambia il percorso corretto.

La policy di esecuzione non è un controllo di sicurezza assoluto

La Execution Policy di PowerShell non deve essere trattata come una barriera di sicurezza forte. Serve soprattutto a ridurre errori operativi e a governare l’esecuzione di script in modo coerente. Non sostituisce controlli come AppLocker, WDAC, firma del codice, controllo del canale di distribuzione o privilegi amministrativi. Se la usi come unico presidio, stai facendo affidamento su un meccanismo che l’utente esperto può aggirare in vari modi e che non protegge da molti vettori reali.

Le opzioni tipiche sono Restricted, AllSigned, RemoteSigned, Unrestricted e Bypass. In pratica, per workstation gestite, RemoteSigned è spesso il compromesso più usato; per ambienti più rigidi, AllSigned ha senso solo se hai davvero un processo di firma dei file .ps1 e gestione certificati solida. Bypass va usato per scenari specifici e temporanei, non come default di flotta.

Intune: quando conviene e dove si configura

Intune è il canale giusto se vuoi governare endpoint moderni senza dipendere dalla GPO di dominio. La configurazione passa dal profilo di tipo Settings catalog o, in alcuni casi, da Administrative Templates o Custom OMA-URI. Per la Execution Policy, il percorso più pulito è usare il catalogo impostazioni quando disponibile, perché ti lascia audit, assegnazione ai gruppi e stato di compliance in un’unica vista.

Il punto importante è che Intune non “magicamente” cambia il comportamento di PowerShell se il profilo non arriva davvero al device. Devi verificare l’assegnazione, il check-in e l’applicazione della policy sul client. La console ti mostra che il profilo esiste; il client ti dice se è stato recepito.

1. Apri Intune admin center.
2. Vai su Devices → Configuration profiles → Create profile.
3. Seleziona piattaforma Windows 10 and later e tipo Settings catalog.
4. Cerca la voce relativa a PowerShell Execution Policy, se presente nel catalogo del tenant.
5. Assegna il profilo a un gruppo di dispositivi o utenti coerente con la tua strategia.

Se nel tuo tenant la voce non è esposta nel catalogo, non inventare scorciatoie: verifica se il profilo necessario è disponibile in Administrative Templates oppure se devi usare un Custom profile con impostazione CSP/OMA-URI supportata dalla versione del sistema operativo e dal provider MDM.

GPO: utile nei domini, ma attenzione alla precedenza

In dominio, la GPO resta il metodo più prevedibile per server e client legacy, soprattutto se hai già OU ben strutturate e processi di change consolidati. La configurazione classica passa da Computer Configuration o User Configuration in base al tipo di criterio disponibile nel template usato. Il dettaglio che genera più errori è il targeting: una policy messa nella OU sbagliata o bloccata da inheritance non arriva mai al device, anche se la console mostra tutto “verde”.

Per questo, quando la GPO deve convivere con Intune, devi ragionare su precedenza e conflitto. Se il device riceve sia un criterio di dominio sia un profilo MDM, il comportamento dipende dal tipo di impostazione, dal canale e dal meccanismo di co-management. Non basta chiedersi “l’ho configurata?”; devi chiederti “quale valore è effettivamente scritto nel sistema?”.

1. Apri Group Policy Management.
2. Modifica la GPO destinata all’OU corretta.
3. Imposta la policy PowerShell nella sezione prevista dal template amministrativo in uso.
4. Verifica link, security filtering e eventuale block inheritance.
5. Forza un test su un endpoint campione con gpupdate /force.

Il test non finisce con il comando. Dopo il refresh devi controllare il risultato lato client, non solo lato controller di dominio.

gpresult /h C:	emp
sop.html

Apri il report e cerca la sezione relativa ai criteri applicati. Se la GPO non compare, il problema non è PowerShell: è scope, filtro o conflitto di ereditarietà.

Verifica lato client: il comando giusto prima di cambiare altro

Prima di modificare impostazioni, raccogli evidenza dal client. La verifica minima utile è capire quale execution policy è attiva e a quale scope appartiene. PowerShell espone più livelli di configurazione, quindi una policy a Process può mascherare quella di LocalMachine, e una policy di utente può creare confusione se stai testando con un account diverso da quello coinvolto dal profilo.

Get-ExecutionPolicy -List

Il risultato atteso è una tabella con gli scope. Se vedi MachinePolicy o UserPolicy, significa che una Group Policy sta imponendo un valore. Se invece compare solo LocalMachine o CurrentUser, la gestione è locale o non vincolata da policy di dominio/MDM. Questo è il passaggio che evita ore di tentativi ciechi.

Se il comportamento che osservi non coincide con quanto impostato in Intune o in GPO, il passo successivo è controllare i log di applicazione policy.

Get-WinEvent -LogName Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin -MaxEvents 50 | Select-Object TimeCreated, Id, LevelDisplayName, Message

Su endpoint gestiti da Intune, questo log è spesso il più utile per capire se il profilo è arrivato, se è fallito il parsing o se il dispositivo non ha sincronizzato di recente.

Scelta pratica: RemoteSigned, AllSigned o Bypass

La scelta non va fatta per abitudine. Va fatta in base a come distribuisci gli script e a quanto controllo hai sulla supply chain interna. Se gli script sono creati in casa, distribuiti da repository controllato e firmati solo in alcuni casi, RemoteSigned è spesso la soglia minima accettabile per endpoint standard. Consente l’esecuzione di script locali non firmati, ma richiede firma per quelli scaricati da Internet o marcati come provenienti dall’esterno.

AllSigned è adatto quando hai un processo di firma solido e vuoi che ogni script venga verificato. Funziona bene in ambienti regolati, ma introduce attrito operativo: rinnovo certificati, trust chain, validazione firma e gestione degli script temporanei. Se non hai questi pezzi, finisci per creare eccezioni continue.

Bypass non è una policy da standardizzare. Ha senso in task automation molto controllate, durante troubleshooting o in scenari di bootstrap, ma va trattata come eccezione temporanea. Se diventa permanente, hai solo spostato il problema.

Con Intune e GPO insieme: schema di lavoro pulito

Il modo corretto per evitare conflitti è decidere un source of truth. Se il device è domain-joined e la governance primaria è ancora on-prem, allora la GPO deve definire il comportamento e Intune deve evitare di sovrascriverlo. Se invece stai migrando verso cloud management, conviene invertire il modello: Intune governa e la GPO viene progressivamente ritirata o limitata ai soli gruppi non ancora migrati.

Il peggio che puoi fare è impostare la stessa cosa in entrambi i canali senza documentare chi vince. In quel caso, quando qualcosa si rompe, nessuno sa se correggere la policy cloud, la GPO o il targeting. La governance sana prevede un elenco semplice:

1. chi gestisce l’impostazione;
2. su quali device;
3. in quale finestra di change;
4. come si verifica il risultato;
5. come si torna indietro.

Se il tuo parco è ibrido, una pratica utile è testare prima su un gruppo pilota ben definito, con un endpoint che rappresenti il caso peggiore: join ibrido, utente standard, software di protezione attivo, policy precedenti già presenti. Se funziona lì, hai meno probabilità di trovare sorprese in massa.

Snippet operativo: controllo e correzione con minimo rischio

Se devi verificare rapidamente lo stato e fare una correzione reversibile, usa questa sequenza. Non cambia nulla finché non applichi il passo di modifica, e ti lascia una traccia chiara dello stato iniziale.

Get-ExecutionPolicy -List

gpresult /scope computer /h C:	emp
sop-computer.html

gpresult /scope user /h C:	emp
sop-user.html

Se il client è gestito da Intune, aggiungi la verifica del check-in:

dsregcmd /status

Controlla che il device sia effettivamente registrato e che il canale MDM sia attivo. Se il dispositivo non risulta correttamente joinato o enrolled, la policy non arriverà nel modo previsto.

Rollback e pulizia del conflitto

Ogni modifica a policy di esecuzione deve avere un rollback esplicito. Se hai applicato una GPO, il rollback è disabilitare il link, spostare la GPO in OU di test o riportare il valore precedente dal backup della policy. Se hai usato Intune, il rollback tipico è rimuovere l’assegnazione del profilo o sostituirlo con una policy correttiva. Non cancellare a caso il profilo se non hai prima verificato chi dipende da quella configurazione.

Per evitare ambiguità, documenta sempre il valore precedente. Un approccio semplice è esportare la configurazione della GPO o annotare il set di impostazioni del profilo Intune prima del change. Nel caso di un errore diffuso, sapere se il valore precedente era RemoteSigned o AllSigned evita di fare rollback “a memoria”.

Se devi ripristinare un comportamento locale temporaneo per sbloccare un’attività, fallo in modo puntuale e con scadenza. Per esempio, una modifica a livello di processo è più sicura di un cambio permanente di macchina, perché non altera la baseline del sistema oltre il necessario.

Messaggio finale operativo

La policy di esecuzione PowerShell non va trattata come un flag isolato, ma come una parte della governance endpoint. Intune è più comodo nel cloud, GPO resta forte nel dominio, e il problema nasce quando i due canali vengono usati senza una gerarchia esplicita. Se definisci bene il source of truth, verifichi lo scope con Get-ExecutionPolicy -List e controlli l’applicazione con gpresult e i log MDM, eviti quasi tutti i casi classici di “ho impostato la policy ma non funziona”.

Assunzione operativa: l’endpoint è in produzione o vicino alla produzione, quindi ogni change va fatto con test su gruppo pilota, verifica lato client e rollback già pronto.