Vuoi consentire l’accesso RDP a Windows Server 2022 soltanto da 15 PC, anche se il server è raggiungibile via VPN da circa 50? In questa guida trasformiamo RDP in una vera whitelist combinando diritti utente e filtri IP, con procedure dettagliate via GUI e PowerShell, verifiche e opzioni avanzate.
Scenario e obiettivo
Hai un Windows Server 2022 Standard esposto solo sulla rete VPN aziendale. Circa 50 client possono raggiungere il server a livello IP, ma desideri autorizzare la connessione Desktop Remoto (porta TCP 3389, con relativo canale UDP) esclusivamente da 15 di questi computer. L’aver aggiunto “quei PC” (o meglio, gli utenti che li utilizzano) al gruppo locale Remote Desktop Users non ha impedito a altri client di collegarsi: questo perché la membership in quel gruppo controlla il diritto di accesso dell’utente, non il percorso di rete da cui la richiesta arriva.
Perché “Remote Desktop Users” non basta
Il gruppo locale Remote Desktop Users è uno dei modi con cui Windows applica il diritto “Allow log on through Remote Desktop Services” (Consenti accesso tramite Servizi Desktop remoto). Se un account possiede quel diritto, può aprire una sessione RDP da qualunque macchina in grado di raggiungere il server. Nulla, a livello di sistema operativo, vincola la connessione alla sorgente (il PC) a meno che tu non introduca un controllo di rete.
Inoltre, anche utenti che non sono in “Remote Desktop Users” potrebbero comunque riuscire ad accedere se appartengono ad altri gruppi con diritti equivalenti (ad esempio Administrators) o se policy sovrapposte concedono l’accesso. Ecco perché la sola gestione per-utente non realizza una whitelist di client.
Approcci possibili e confronto
| Livello | Tecnica | Vantaggi | Limiti / Criticità |
|---|---|---|---|
| Controllo utenti | Crea un gruppo AD dedicato (es. RDP-Allowed). Aggiungi solo gli utenti autorizzati. In Criteri di sicurezza locali → Diritti utente → Allow log on through Remote Desktop Services (o GPO equivalente) concedi il diritto solo a quel gruppo (oltre agli Administrators, se necessario). Rimuovi il gruppo predefinito Remote Desktop Users dal criterio. | Semplice da mantenere se l’utente usa un solo PC “autorizzato”. Nessuna modifica al firewall necessaria per funzionare. | Se un utente valido usa un PC “non autorizzato”, la connessione funziona comunque. Non protegge da uso di account compromessi su altri dispositivi. |
| Controllo di rete | In Windows Defender Firewall con sicurezza avanzata crea o modifica una regola in entrata sulla porta 3389 (TCP) e 3389 (UDP). In Ambito → Indirizzo IP remoto imposta Questi indirizzi IP specificando gli IP dei 15 PC (o una subnet/pool VPN dedicato). Azione: Consenti la connessione solo da quegli IP. | Blocca qualsiasi client fuori lista, indipendentemente dall’utente. Sfrutta strumenti nativi, niente software aggiuntivo. | Richiede IP statici o prenotazioni DHCP. Se gli IP cambiano, va aggiornata la regola o va usata una subnet dedicata in VPN. |
| (Richiesta smentita) | Filtro per NOME computer (DNS/NetBIOS) nel firewall | — | Non supportato su Windows Server 2022: le regole di firewall interpretano indirizzi IP (IPv4/IPv6) e subnet, non nomi di host, per il traffico in entrata. |
Strategia consigliata
Combina i due livelli: usa un gruppo AD per limitare gli utenti e una regola di firewall per limitare gli IP. Così ottieni due barriere complementari:
- Un account rubato non può essere usato da fuori elenco IP.
- Un PC fuori elenco IP non entra anche se l’utente è nel gruppo corretto.
Prerequisiti e buone pratiche
- Inventario dei 15 PC autorizzati: hostname, utente titolare, indirizzo IP VPN assegnato.
- IP stabili: scegli IP statici o prenotazioni DHCP; in alternativa crea un pool VPN dedicato da filtrare come subnet.
- Canale d’emergenza: prima di applicare i blocchi, predisponi accesso di console (iDRAC/iLO, KVM, Hyper‑V VMConnect o accesso fisico) per poter ripristinare in caso di errore.
- Profili firewall: verifica che le regole si applichino al profilo corretto (Domain/Private/Public) in uso sull’interfaccia VPN del server.
- UDP per RDP: Windows usa anche UDP 3389 per migliorare la reattività; ricorda di allineare sia la regola TCP sia la regola UDP.
Implementazione passo‑passo (GUI)
Impostare i diritti di accesso per utente
- In Active Directory crea un gruppo globale, ad es. RDP-Allowed, e aggiungi solo gli utenti autorizzati.
- Apri Gestione Criteri di Gruppo (gpmc.msc), crea un nuovo GPO (es. “RDP – Solo utenti autorizzati”) e collegalo all’OU del server.
- Modifica il GPO e vai in:
Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment → Allow log on through Remote Desktop Services.
Imposta: Administrators e RDP-Allowed. Rimuovi il predefinito Remote Desktop Users. - Attenzione: evita di usare “Deny log on through Remote Desktop Services” contro Domain Users, perché tutti gli utenti di dominio (compresi quelli autorizzati) ne fanno parte; la deny prevale sulla allow.
Vincolare gli IP ammessi sul firewall
- Apri Windows Defender Firewall con sicurezza avanzata sul server.
- Vai su Regole in entrata e trova le regole di gruppo Remote Desktop (o “Desktop remoto”). Di solito sono:
- Remote Desktop – User Mode (TCP‑In)
- Remote Desktop – User Mode (UDP‑In)
- Per ciascuna delle due regole:
- Apri Proprietà → scheda Ambito.
- In Indirizzi IP remoti seleziona Questi indirizzi IP e inserisci:
- gli IP singoli dei 15 client, oppure
- la subnet del pool VPN dedicato (es.
10.10.15.0/28).
- Conferma e applica.
- Non creare regole di blocco generico su 3389: un block troppo ampio ha precedenza su allow e rischia di tagliarti fuori. Meglio restringere l’ambito delle regole allow predefinite.
Implementazione passo‑passo (PowerShell)
Se preferisci automatizzare o distribuire via GPO, puoi usare i seguenti esempi. Le stringhe dei nomi regola possono variare a seconda della lingua di sistema; il filtro sulla Service TermService (Remote Desktop Services) è più robusto.
# <ESEMPIO> Elenco degli IP autorizzati (IPv4 singoli e/o subnet)
$Allowed = @(
'10.10.15.10','10.10.15.11','10.10.15.12','10.10.15.13','10.10.15.14',
'10.10.15.15','10.10.15.16','10.10.15.17','10.10.15.18','10.10.15.19',
'10.10.15.20','10.10.15.21','10.10.15.22','10.10.15.23','10.10.15.24'
)
Recupera tutte le regole RDP in entrata (TCP e UDP) legate a TermService
$RdpInbound = Get-NetFirewallRule -Direction Inbound |
Where-Object { $_.Service -eq 'TermService' }
Applica l'ambito IP autorizzato a entrambe le regole (TCP/UDP)
$RdpInbound | Set-NetFirewallAddressFilter -RemoteAddress $Allowed
Verifica: stampa l’ambito IP effettivo
$RdpInbound | Get-NetFirewallAddressFilter | Format-Table -Auto RemoteAddress
Nota: se preferisci costruire regole ad hoc (anziché modificare le predefinite), disabilita le regole RDP standard e creane due nuove “Consenti” con -RemoteAddress limitato. Esempio:
# Disabilita le regole standard del gruppo "Remote Desktop"
Get-NetFirewallRule -DisplayGroup 'Remote Desktop' -Direction Inbound | Disable-NetFirewallRule
Crea regola TCP consentita solo dagli IP elencati
New-NetFirewallRule -DisplayName 'RDP (TCP) - Solo IP autorizzati' `
-Direction Inbound -Action Allow -Protocol TCP -LocalPort 3389 `
-RemoteAddress $Allowed -Service TermService -Profile Any
Crea regola UDP analoga
New-NetFirewallRule -DisplayName 'RDP (UDP) - Solo IP autorizzati' `
-Direction Inbound -Action Allow -Protocol UDP -LocalPort 3389 `
-RemoteAddress $Allowed -Service TermService -Profile Any
Consiglio: per ambienti multi‑lingua, al posto di -DisplayGroup 'Remote Desktop' usa sempre il filtro Where-Object { $_.Service -eq 'TermService' }.
Gestire gli IP in modo stabile
- IP statici o prenotazioni DHCP: assegnali ai 15 PC per evitare aggiornamenti frequenti della regola.
- Pool VPN dedicato: crea un pool (es.
10.10.15.0/28) e inserisci solo i 15 PC in quel pool. Nel firewall ti basta autorizzare l’intera subnet. Meno manutenzione, massima chiarezza. - Attenzione al NAT della VPN: se il server “vede” come sorgente sempre lo stesso IP (la traduzione del concentratore), il filtro per singolo client non è applicabile sul server. In quel caso il filtraggio va spostato sul gateway VPN (o su un firewall di front‑end).
- IPv6: se la VPN usa IPv6, aggiungi anche gli indirizzi IPv6 dei client o disabilita l’IPv6 sulla VPN per semplificare il perimetro.
Verifiche rapide da linea di comando
# Mostra le regole RDP abilitate e il relativo ambito IP
Get-NetFirewallRule -Direction Inbound | Where-Object {$_.Service -eq 'TermService'} |
Get-NetFirewallAddressFilter | Format-List RemoteAddress
Elenco delle regole RDP per protocollo/porta
Get-NetFirewallRule -Direction Inbound | Where-Object {$_.Service -eq 'TermService'} |
Get-NetFirewallPortFilter | Select-Object Name,Protocol,LocalPort | Format-Table -Auto
Verifica listener RDP (server)
Get-NetTCPConnection -LocalPort 3389 | Format-Table -Auto Per testare dal client, usa Test-NetConnection <server> -Port 3389 -InformationLevel Detailed oppure prova una sessione con mstsc. Verifica anche i log: Windows Firewall (abilita il logging) e TerminalServices‑RemoteConnectionManager per tentativi riusciti/negati.
Misure di sicurezza complementari (consigliate)
- NLA obbligatoria: in System Properties → Remote attiva Allow remote connections only from computers running Remote Desktop with Network Level Authentication.
- Certificato TLS valido per RDP (facilita la difesa contro MITM interni e riduce warning agli utenti).
- Account hardening: password robuste, blocco degli account (lockout), MFA dove possibile. Riduci al minimo gli amministratori locali.
- Mai esporre 3389 a Internet: mantieni l’accesso dietro VPN o, meglio, dietro RD Gateway.
- Log e auditing: attiva il log del firewall (
Set-NetFirewallProfile -LogAllowed True -LogBlocked True) e monitoraggio eventi 4624/4625, 1149.
Alternative avanzate (opzionali)
- RD Gateway (Remote Desktop Gateway): pubblica RDP solo via HTTPS/443, applica CAP (Connection Authorization Policy) e RAP (Resource Authorization Policy) con criteri per utenti e, indirettamente, per host di destinazione. Consente MFA e auditing centralizzato.
- Network Access Control / 802.1X: se la tua infrastruttura lo permette, vincola l’accesso VPN a dispositivi “conformi” (certificato macchina, posture), così l’IP assegnato diventa correlato al dispositivo.
- IPsec con regole di sicurezza connessione: puoi richiedere autenticazione a livello IP (certificato macchina) per il traffico RDP; in pratica solo i client con il certificato valido stabiliscono il canale.
- Conditional Access (ibrido): se sei in scenari ibridi, integra con criteri di accesso condizionale per consolidare l’autorizzazione lato identità e dispositivo.
Checklist di messa in sicurezza
- Creato gruppo AD RDP-Allowed e popolato con gli utenti giusti.
- GPO applicata: “Allow log on through Remote Desktop Services” = Administrators + RDP‑Allowed; rimosso Remote Desktop Users.
- IP stabili: statici, prenotazioni DHCP o pool VPN dedicato/subnet.
- Regole RDP TCP/UDP con Ambito → Indirizzo IP remoto limitato agli IP/subnet autorizzati.
- Logging firewall attivo; test effettuati da IP ammesso e non ammesso.
- Canale di accesso d’emergenza pronto (console fisica/virtuale).
Risoluzione dei problemi
- Ho perso l’accesso RDP: usa la console d’emergenza e ripristina temporaneamente l’ambito a “qualsiasi IP”. Poi correggi la lista.
- Gli IP cambiano spesso: passa a prenotazioni DHCP o usa un pool VPN dedicato da filtrare come blocco di indirizzi.
- La VPN fa NAT: se il server vede solo l’IP del concentratore, applica i filtri sul gateway VPN o su un firewall a monte del server.
- Connessioni lente: verifica che UDP 3389 sia consentito dagli IP ammessi; in caso contrario RDP cade su TCP con performance inferiori.
- Regole non si applicano: controlla il profilo attivo (Domain/Private/Public) dell’interfaccia; la regola deve includere quel profilo.
FAQ
Posso filtrare per nome del computer (DNS/NetBIOS) anziché IP?
No. Per il traffico in entrata su Windows Server 2022 il firewall lavora con indirizzi IP e subnet, non con nomi di host. Per vincolare a “quella macchina” usa IP, subnet dedicate o meccanismi a monte (VPN, NAC, IPsec).
Ha senso cambiare la porta 3389?
Può ridurre il “rumore” ma non è una misura di sicurezza. Mantieni 3389 e concentrati su autenticazione, whitelist IP e, se possibile, RD Gateway con MFA.
Devo toccare anche le regole in uscita?
Di norma no: per l’accesso a questo server conta l’inbound. Valuta l’outbound solo se hai policy egress restrittive.
Conclusione
Su Windows Server 2022 non è possibile filtrare l’RDP in base al nome del computer; bisogna usare indirizzi IP. La soluzione più sicura e pratica unisce controllo utenti (gruppo AD con diritto “Allow log on through Remote Desktop Services”) e controllo di rete (regole firewall RDP TCP/UDP con Ambito limitato agli IP o a una subnet VPN dedicata). Metti in piedi un ambiente di test, valida la connettività da un IP ammesso e da uno non ammesso, e mantieni sempre un canale di accesso d’emergenza prima di applicare i blocchi in produzione.
Esempio operativo compatto
# 1) Gruppo AD: RDP-Allowed → aggiungi gli utenti autorizzati
2) GPO: Allow log on through Remote Desktop Services = Administrators + RDP-Allowed
3) Firewall sul server: limita l'ambito IP delle regole RDP
$Allowed = '10.10.15.0/28' # es. pool VPN dedicato ai 15 PC
Get-NetFirewallRule -Direction Inbound |
Where-Object { $_.Service -eq 'TermService' } |
Set-NetFirewallAddressFilter -RemoteAddress $Allowed
Verifica
Get-NetFirewallRule -Direction Inbound |
Where-Object { $_.Service -eq 'TermService' } |
Get-NetFirewallAddressFilter | Format-List RemoteAddress Risultato: solo gli utenti del gruppo RDP‑Allowed e solo dai client con IP nella lista/subnet possono aprire sessioni RDP sul server.