Limitare l’accesso degli utenti di dominio ai soli PC autorizzati (GPO + ADUC): guida completa

Obiettivo: impedire che gli utenti di dominio possano avviare sessioni su PC non assegnati, mantenendo la produttività e riducendo i rischi. In questa guida trovi una procedura concreta con GPO e ADUC, scenari avanzati, automazione e troubleshooting per una messa in sicurezza realmente efficace.

Indice

Panoramica del problema e modello di minaccia

In un ambiente Windows Domain tradizionale, un utente autenticato nel dominio può eseguire il logon interattivo su qualsiasi computer membro. Questo comportamento “aperto per impostazione predefinita” crea tre criticità:

Superficie d’attacco estesa: una password compromessa consente movimenti laterali su molteplici endpoint.
Privacy e conformità: dati locali (cache, file temporanei, profili) possono essere esposti su postazioni non autorizzate.
Auditing complesso: più dispositivi per utente complicano la tracciabilità.

Obiettivo architetturale: ogni dipendente deve poter eseguire l’accesso soltanto alla workstation assegnata (o a un set definito di workstation), bloccando a monte il caricamento del profilo su dispositivi non autorizzati.

Prerequisiti e buone pratiche preliminari

OU (Unità Organizzative) ben strutturate: separa Utenti e Computer; evita di applicare GPO all’intero dominio se non necessario.
Nomenclatura coerente dei computer (es. PC-Sede-001): semplifica filtri WMI ed elenchi di eccezioni.
Account break-glass documentati per emergenze, fuori da eventuali blocchi rischiosi.
Piano di test su gruppo pilota prima del rollout in produzione.

Procedura consigliata (passo–passo)

Passo	Dove	Cosa fare	Perché
Creare o modificare un GPO	Group Policy Management Console (GPMC)	a) Crea un nuovo oggetto Criteri di gruppo e collegalo all’OU che contiene i computer (non gli utenti). b) Apri l’editor del GPO (modalità Computer).	Applicando dal lato Computer eviti che gli utenti possano eludere la policy.
Configurare i diritti di logon “di rete”	Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment	– Access this computer from the network: includi solo gruppi/utenti che devono connettersi (es. Domain Admins, account di backup). – Deny access to this computer from the network: aggiungi gruppi generici (es. Domain Users) per bloccare connessioni indesiderate.	Riduce la superficie d’attacco via rete; non gestisce il logon interattivo, ma toglie capacità di movimento laterale.
Limitare il logon interattivo per utente	Active Directory Users and Computers (ADUC)	a) Apri l’account utente → Properties → tab Account → Log On To… b) Seleziona Only the following computers e inserisci i nomi NetBIOS o FQDN dei PC consentiti (attributo AD: `userWorkstations`).	Se l’utente tenta il logon su PC non elencati, la richiesta viene rifiutata prima del caricamento del profilo.
Aggiornare le policy	Prompt sui client	`gpupdate /force` (oppure attendi il normale refresh). In alternativa: `Invoke-GPUpdate -Computer PC-XYZ -RandomDelayInMinutes 0`.	Applica subito le nuove impostazioni, utile nelle fasi di test o emergenza.
Verifica end‑to‑end	PC autorizzato & PC non autorizzato	– Logon su PC autorizzato → deve riuscire. – Logon su altro PC → deve fallire con messaggio “You are not allowed to log on to this computer”.	Conferma che il GPO raggiunga l’OU corretta e che l’attributo `userWorkstations` sia coerente.

Dettagli operativi e note importanti

Inserimento corretto dei nomi delle workstation

Formati supportati: NetBIOS (es. PC-XYZ) o FQDN (es. PC-XYZ.contoso.local). Scegline uno e usalo in modo consistente.
Se rinomini una workstation, aggiorna l’elenco nell’attributo userWorkstations, altrimenti l’utente resterà bloccato su quel PC.
Non è possibile inserire gruppi nel campo Log On To…: accetta solo nomi di computer.

Distinzione tra tipi di logon

Logon locale (interattivo): controllato da Log On To… (utente) e dai diritti Allow/Deny log on locally (computer).
Logon RDP: governato da Allow/Deny log on through Remote Desktop Services; opzionalmente applica anche Log On To… per ulteriore controllo.
Accesso di rete (es. condivisioni): influenzato da Access/Deny access this computer from the network e dalle ACL delle risorse.

Gestione dei laptop e della modalità offline

Il controllo Log On To… viene verificato durante l’autenticazione dal Domain Controller. Se un laptop è offline, Windows può consentire il logon con cached credentials (impostazione predefinita: 10 logon memorizzati). Valuta se ridurre o disabilitare la cache:

Security Options → Interactive logon: Number of previous logons to cache: imposta 0 per disabilitare (sconsigliato su PC che lavorano spesso offline), oppure riduci a un valore minore del default.

Account privilegiati e di servizio

Evita di inserire Domain Admins e gruppi altamente privilegiati in liste di deny: potrebbero avere diritti che bypassano restrizioni locali, o potresti bloccare scenari legittimi di amministrazione.
Per gli account di servizio, gestisci i diritti dedicati (Log on as a service, Log on as a batch job) e documenta i PC autorizzati a eseguire tali servizi.

Alternative GPO e configurazioni complementari

Oltre a Log On To… puoi irrigidire ulteriormente la superficie d’accesso con i seguenti diritti lato computer:

Allow/Deny log on locally: gestione per computer dei gruppi consentiti/bloccati al logon interattivo. Utile quando gestisci PC condivisi: consenti il logon solo al gruppo “PC‑XYZ Users”.
Allow/Deny log on through Remote Desktop Services: per controllare il logon interattivo remoto (RDP). Limita a gruppi specifici (es. Remote Desktop Users ristretto).
WMI Filtering: applica dinamicamente il GPO a workstation con un certo nome o attributo hardware. Esempio: SELECT * FROM Win32_ComputerSystem WHERE Name LIKE "PC-XYZ%"

Scenario: PC condivisi a turni

Se più utenti condividono la stessa postazione:

Crea un gruppo AD “PC‑XYZ Users” e inserisci gli utenti che possono usare quel PC.
Sul GPO applicato al PC, in User Rights Assignment, usa Allow log on locally (e, se necessario, Allow log on through Remote Desktop Services) per consentire l’accesso solo a “PC‑XYZ Users”.
Facoltativo ma consigliato: per ogni utente del gruppo, aggiungi PC-XYZ anche nella finestra Log On To… (così, se quell’utente prova altrove, verrà bloccato).

Nota: il campo Log On To… non accetta gruppi; per questo si combina una gestione per utente con una per computer, ottenendo massima granularità e manutenzione ridotta.

Automazione: gestione in massa con PowerShell

Per ambienti con molti utenti, aggiorna l’attributo userWorkstations in blocco.

Impostare i PC consentiti per un utente

# Consenti logon solo su PC-001 e PC-002
Set-ADUser -Identity mario.rossi -LogonWorkstations "PC-001,PC-002"

Import da CSV

# CSV con colonne: SamAccountName,Workstations (elenco separato da ;)
Import-Csv .\assegnazioni.csv | ForEach-Object {
    $user = $_.SamAccountName
    $pcs  = ($_.Workstations -replace ';',',')
    Set-ADUser -Identity $user -LogonWorkstations $pcs
}

Verifica attribuzione

Get-ADUser -Filter * -Properties userWorkstations |
  Select-Object SamAccountName,userWorkstations |
  Sort-Object SamAccountName

Rimozione vincolo (ripristino “Any workstation”)

Set-ADUser -Identity mario.rossi -Clear userWorkstations

Monitoraggio e auditing

Per tracciare accessi concessi o negati:

Abilita l’audit Logon/Logoff in Advanced Audit Policy Configuration.
Eventi rilevanti nel registro Security:
- 4624: logon riuscito.
- 4625: logon fallito. Il Sub Status 0xC0000070 indica Invalid Workstation (utente non autorizzato su quel PC). Il codice 0xC000015B indica logon type not granted (diritti mancanti, es. RDP non consentito).

Centralizza i log (SIEM) per avere visibilità su tentativi anomali e trend di policy violation.

Hardening correlato (consigli pratici)

Riduci i membri dei gruppi locali “Administrators” e “Remote Desktop Users” tramite Restricted Groups o Group Policy Preferences → Local Users and Groups.
LAPS (Local Administrator Password Solution): password locali univoche e ruotate per gli admin locali, limitando gli abusi post‑logon.
Disabilita SMBv1 e servizi legacy; aggiorna costantemente i criteri di sicurezza dei client.
Privileged Access Workstations (PAW): postazioni dedicate per amministratori, con policy più restrittive e isolamento di rete.

Scenari ibridi con Azure AD / Intune

In ambienti ibridi puoi ottenere risultati equivalenti o complementari:

Intune: criterio Device restrictions → Local user group membership per popolare i gruppi locali (“Administrators”, “Remote Desktop Users”) solo con gli utenti previsti; Endpoint Security → Account protection per i diritti utente.
Conditional Access: richiedi che l’accesso alle app avvenga da dispositivi compliant e Hybrid/Azure AD joined. Con i device filters puoi restringere a dispositivi con determinati attributi (nome, categoria, tag), avvicinandoti alla logica “utente ↔ dispositivo assegnato”.

Risoluzione dei problemi (troubleshooting)

Problema	Possibile causa	Soluzione
L’utente non riesce ad accedere al PC assegnato	Nome della workstation errato o non aggiornato (rinomina del PC non recepita)	Verifica `userWorkstations` dell’utente e correggi con il nome corrente (NetBIOS o FQDN coerente).
L’utente accede comunque da un altro PC	Logon offline con credenziali in cache; GPO non ancora applicata; utente in gruppi con diritti più ampi	Forza `gpupdate`, valuta di ridurre/disabilitare la cache dei logon, rivedi l’appartenenza ai gruppi locali/dominio.
Errore 4625 con Sub Status 0xC000015B	Il tipo di logon richiesto (es. RDP) non è consentito	Aggiungi l’utente/gruppo a Allow log on through Remote Desktop Services oppure rimuovi una regola Deny conflittuale.
Amministratori bloccati su alcune postazioni	GPO con Deny log on locally applicato in modo troppo ampio	Rivedi il GPO, escludi le OU degli amministratori o crea eccezioni esplicite (filtri di sicurezza o WMI).
Servizi di backup non funzionano più	Restrizioni su “Access this computer from the network”	Garantisci i permessi di rete ai servizi (account del servizio o gruppi dedicati) nella voce “Allow”.

FAQ operative

Il controllo “Log On To…” vale anche per RDP?
Sì, può essere applicato anche al logon remoto, ma è buona pratica usare inoltre i diritti Allow/Deny log on through Remote Desktop Services per governare esplicitamente l’RDP.

È meglio NetBIOS o FQDN nei campi di autorizzazione?
Entrambi sono supportati. Mantieni coerenza (standard di naming aziendale) per semplificare manutenzione e audit.

Posso assegnare “un PC a più utenti” facilmente?
Sì. Crea il gruppo “PC‑XYZ Users” e usa i diritti lato computer (Allow log on locally) per consentire l’accesso a quel gruppo; opzionalmente compila anche Log On To… per ciascun utente del gruppo.

E se un utente cambia PC?
Aggiorna la lista in Log On To… (o lo script di provisioning) e, se gestisci i diritti per computer, aggiorna l’appartenenza al gruppo “PC‑XYZ Users”.

Questa impostazione protegge anche i domain controller?
I DC hanno criteri specifici per il logon locale. Mantieni le best practice standard (gli utenti normali non devono poter accedere ai DC) e non usare policy sperimentali sui DC.

Piano di rollout consigliato

Inventario: mappa utenti ←→ PC assegnati (CSV sorgente di verità).
GPO base: diritti di rete e RDP allineati allo standard; nessuna rottura.
Pilota: applica Log On To… a un reparto ristretto; monitora eventi 4624/4625 e ticket Help Desk.
Estensione graduale: per OU o per sede, con finestra di rollback definita.
Operatività: integra nei flussi HR/IT (onboarding, change, offboarding) lo script per aggiornare userWorkstations e i gruppi per PC condivisi.

Check‑list di conformità

GPO applicato lato Computer sull’OU corretta.
Impostazioni Access/Deny this computer from the network definite e testate.
Utenti con Log On To… popolato e coerente con l’inventario.
Diritti Allow/Deny log on locally e Allow/Deny log on through RDS allineati al modello d’uso.
Audit attivo con verifica degli eventi 4624/4625 e codici di stato.
Gestione cache logon decisa (valori documentati per laptop/desktop).
Processi di provisioning/deprovisioning integrati con PowerShell e CSV master.

Approfondimenti utili (riassunti e ampliati)

Gruppi di sicurezza dedicati
Per i PC condivisi, usa gruppi AD tipo “PC‑XYZ Users” e gestiscili nel GPO lato Computer (diritti Allow log on locally e/o Allow log on through RDS). Ricorda: il pannello Log On To… accetta computer, non gruppi; per gli utenti del gruppo puoi comunque aggiungere il PC nella loro lista Log On To… per bloccare l’uso di altre postazioni.
Protezione da privilegi impliciti
Non usare deny aggressivi contro gruppi ad alta priorità (es. Domain Admins). Definisci eccezioni pulite e documentate.
Alternative GPO avanzate
Deny log on locally per bloccare gruppi specifici su host non autorizzati; WMI Filtering per applicazioni mirate (per modello, periferiche, sede).
Monitoraggio
Abilita l’audit “Logon/Logoff” e segui gli Event ID 4625/4624. I codici 0xC0000070/0xC000015B aiutano nel troubleshooting.
Scenari ibridi con Azure AD/Intune
In cloud‑hybrid sfrutta Intune per membership dei gruppi locali e i filtri di dispositivo in Conditional Access. L’obiettivo resta: utente ↔ dispositivo assegnato e conforme.

Riepilogo finale

Strumento principale: combinazione di Group Policy (lato Computer) + impostazione Log On To… (lato Utente).
Effetto: l’utente può eseguire logon soltanto sui PC autorizzati; gli altri tentativi si bloccano prima della creazione della sessione.
Benefici: meno accessi non autorizzati, inventario più pulito, auditing chiaro e riduzione del movimento laterale.
Attenzione: testa sempre su un gruppo pilota; documenta eccezioni e account di emergenza; sincronizza la procedura con onboarding/movimenti del personale.

Esempi pratici: playbook rapido

Playbook A — Utente con una sola workstation

In ADUC, utente → Account → Log On To… → “Only the following computers” → PC-001.
GPO lato computer: verificare diritti RDP e di rete minimali.
Su PC-001: gpupdate /force e test.

Playbook B — Postazione condivisa

Crea gruppo AD PC-RECEP-Users e aggiungi gli utenti.
Nel GPO dell’OU del PC: Allow log on locally → aggiungi PC-RECEP-Users; rimuovi “Domain Users” se presente.
Facoltativo: per ogni utente del gruppo, aggiungi PC-RECEP in Log On To….

Playbook C — Rollout massivo con CSV

Prepara CSV assegnazioni.csv (utente, elenco PC).
Esegui lo script PowerShell di import.
Verifica con Get-ADUser ... -Properties userWorkstations e Dashboard di eventi 4625.

Note di sicurezza e manutenzione

Documenta lo scope del GPO e gli eventuali filtri di sicurezza (Security Filtering) per tenere traccia delle eccezioni.
Evita sovrapposizioni conflittuali tra GPO (regola d’oro: meno è meglio). Quando necessario, usa Enforced e precedenze con cautela.
Definisci procedure di rename dei PC che includano l’aggiornamento del campo userWorkstations.
Pianifica controlli periodici: utenti senza workstation assegnata o workstation orfane (rimosse, ma ancora presenti negli attributi).

Adottando questo approccio ibrido — vincolo per utente con Log On To… e vincoli per computer con i diritti di logon — trasformi un dominio “aperto” in un ambiente least‑privilege, dove ogni logon è esplicitamente previsto e verificabile.