Allow log on through Remote Desktop Services: “Add User or Group” disattivato su Windows Server (GPO/RDP) – guida completa

Se il pulsante “Add User or Group” nell’impostazione “Allow log on through Remote Desktop Services” è grigio su un server Windows, quasi sempre un GPO di dominio sta imponendo il criterio. In questa guida trovi diagnosi, soluzione e verifiche per ripristinare l’accesso RDP in modo sicuro.

Indice

Panoramica e sintomi

Scenario tipico: da un client RDP si tenta l’accesso a un server membro di dominio/Controller di dominio e compare l’avviso (o una finestra NLA che rifiuta l’autenticazione):

“Per connettersi in remoto occorre il diritto ‘Allow log on through Remote Desktop Services’…”

Contemporaneamente, aprendo l’Editor Criteri di sicurezza locali (secpol.msc) del server e navigando in Local Policies → User Rights Assignment → Allow log on through Remote Desktop Services, il pulsante “Add User or Group…” risulta disattivato (grigio).

Perché il pulsante è disattivato

Quando un diritto utente (user right) è definito da un GPO a livello di dominio/OU, il corrispondente controllo nell’editor locale diventa sola lettura. In altre parole:

  • Criterio gestito da GPO: il valore effettivo è quello del GPO “vincente”. L’editor locale mostra la configurazione ma non consente modifiche.
  • Permessi insufficienti: per cambiare il valore devi modificare la GPO che lo impone. Servono diritti adeguati (es. Domain Admins o deleghe specifiche alla modifica dei Criteri di gruppo).

Cos’è “Allow log on through Remote Desktop Services”

Il diritto Allow log on through Remote Desktop Services (noto anche come SeRemoteInteractiveLogonRight) controlla chi può avviare sessioni RDP sul computer. Alcune note essenziali:

  • Concedere il diritto a un gruppo è preferibile rispetto a singoli utenti: gestisci membership, non policy.
  • Il diritto “Deny log on through Remote Desktop Services” (SeDenyRemoteInteractiveLogonRight) ha precedenza su Allow: se un utente è in entrambi, l’accesso è negato.
  • Gli Amministratori locali in genere possono accedere via RDP, ma hardening aziendali o baseline di sicurezza possono modificarne il comportamento.
  • Sui Controller di Dominio, l’impostazione è tipicamente definita dalla Default Domain Controllers Policy. Non esistono gruppi locali: “Remote Desktop Users” è un gruppo di dominio.

Soluzione rapida (in sintesi)

  1. Apri gpmc.msc su un DC e individua il GPO che si applica al server.
  2. Modifica il percorso: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment → Allow log on through Remote Desktop Services.
  3. Aggiungi Remote Desktop Users (consigliato) oppure il gruppo/utente di dominio richiesto.
  4. Su quel server esegui gpupdate /force.
  5. Verifica con gpresult /h C:\gpo.html e controlla che il gruppo/utente compaia in Allow e non in Deny.
  6. Controlla la membership locale in lusrmgr.msc (se server non è un DC): l’utente deve essere dentro Remote Desktop Users.

Procedura dettagliata, passo‑passo

PassoAzioneDettagli
1Apri gpmc.msc (Group Policy Management Console)Esegui su un controller di dominio con un account che abbia diritti di modifica sulle GPO interessate.
2Individua la GPO applicata al serverControlla l’OU del server in Active Directory Users and Computers. Nella GPMC guarda i GPO Linked all’OU (ordine, “Enforced”, “Block Inheritance”). In ambienti semplici può essere la Default Domain Policy; meglio usare una GPO dedicata ai server.
3Modifica il diritto utentePercorso: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment → Allow log on through Remote Desktop Services. Spunta Define these policy settings, fai Add User or Group… e aggiungi Remote Desktop Users o il gruppo/utente di dominio richiesto.
4Aggiorna i criteri sul serverEsegui sul server: gpupdate /force. In alternativa attendi il normale refresh.
5Verifica lato criterioEsegui: gpresult /h C:\gpo.html && start C:\gpo.html Nel report verifica: Il GPO vincente per Allow log on through Remote Desktop Services. L’assenza dell’utente/gruppo in Deny log on through Remote Desktop Services.
6Controllo finale localeSe il server è membro (non DC), apri lusrmgr.mscGroupsRemote Desktop Users e verifica l’utente. Se non presente, aggiungilo (il diritto GPO abilita l’accesso, ma la membership facilita la gestione dei permessi applicativi).

Verifiche e diagnosi accurate

Capire quale GPO “vince”

  • gpresult: mostra l’elenco dei criteri applicati e il relativo ordine di precedenza.
  • RSoP (rsop.msc): generazione risultato criteri per vedere il valore effettivo di ogni impostazione.
  • GPMC → Group Policy Results: report lato amministratore, utile per confrontare più server/utenti.

Controllare il diritto “Deny”

Se il diritto Allow è corretto ma l’accesso è ancora negato, verifica Deny log on through Remote Desktop Services. Qualsiasi membership indiretta (annidata) in un gruppo presente in Deny blocca l’accesso, anche agli amministratori (a meno di esclusioni esplicite in policy di hardening).

Conflitti e eredità GPO

  • Enforced (forza): un GPO impostato come “Enforced” prevale su override a valle.
  • Block Inheritance: se l’OU blocca l’eredità, solo i GPO linkati lì o “Enforced” si applicano.
  • Security Filtering e WMI Filtering: assicurati che il computer account del server rientri nell’ambito di applicazione.

Eventi e log utili

  • Event Viewer → Windows Logs → Security: eventi 4625 (Failure) indicano esito di logon fallito e motivazione (user rights).
  • Applications and Services Logs → Microsoft → Windows → TerminalServices‑LocalSessionManager/Operational: log specifici del servizio RDP.
  • System: conferma che il servizio TermService è avviato e che il firewall consente 3389/TCP (regole “Remote Desktop”).

Buone pratiche di progettazione

  • GPO dedicata al diritto RDP: crea un GPO specifico per Allow log on through Remote Desktop Services e collegalo all’OU dei server RDP. Evita di cambiare la Default Domain Policy.
  • Principio del privilegio minimo: concedi il diritto solo al gruppo necessario (es. “Server‑RDP‑Users”) e gestisci membership dal reparto IT.
  • Replica AD: assicurati che la replica tra i DC sia in salute; ritardi possono posticipare l’efficacia del criterio.
  • Non rimuovere “Authenticated Users” dal Read: se restringi il Security Filtering, lascia almeno il permesso Read a “Authenticated Users” e limita Apply group policy ai soli computer target (o usa un gruppo di computer dedicato).
  • Niente utenti individuali nei GPO: usa gruppi di sicurezza di dominio per semplificare auditing e governance.

Casi particolari

Controller di Dominio

Sui DC la policy è comunemente gestita dalla Default Domain Controllers Policy o da una GPO dedicata ai DC. Usa GPMC per modificarla; lusrmgr.msc non è disponibile (niente SAM locale). Aggiungi gli utenti/ gruppi al gruppo di dominio Remote Desktop Users o a un gruppo dedicato incluso nel diritto.

Server non in dominio (workgroup)

Se il server non è membro di dominio, il pulsante non dovrebbe essere grigio. Puoi agire da secpol.mscUser Rights AssignmentAllow log on through Remote Desktop Services e aggiungere utenti locali o Microsoft Account (se permesso dalle policy).

Ambienti MDM/Security Baseline

Alcuni tenant applicano i diritti utente tramite baseline di sicurezza o criteri MDM. In quel caso la sorgente di verità non è la GPO di dominio, ma il profilo assegnato. Sposta la modifica nel profilo corretto o allinea baseline e GPO per evitare “ping‑pong” di configurazioni.

Checklist operativa

  • 🔎 Identifica il GPO vincente (GPMC, RSoP, gpresult).
  • 🛠️ Modifica il diritto in GPO: aggiungi Remote Desktop Users o un gruppo dedicato.
  • 🚫 Verifica che l’utente/gruppo non sia in Deny log on through Remote Desktop Services.
  • 🔁 Forza l’aggiornamento con gpupdate /force.
  • 🧭 Controlla membership locali (solo server non‑DC) e l’abilitazione RDP nelle proprietà di sistema o via GPO.
  • 📄 Documenta la modifica: GPO, OU coinvolta, gruppi concessi, ticket di change.

Comandi e strumenti utili

Verifica rapida stato GPO

gpresult /r
gpresult /h C:\gpo.html
rsop.msc

Aggiornamento criteri

gpupdate /force

Controllo membership e gruppo locale (server membro)

lusrmgr.msc
net localgroup "Remote Desktop Users"
whoami /groups

Firewall e servizio RDP

sc query TermService
Get-NetFirewallRule -DisplayGroup "Remote Desktop"

Tabella di riferimento veloce

ElementoPercorso / NomeNote
Diritto “Allow”User Rights Assignment → Allow log on through Remote Desktop ServicesSID interno: SeRemoteInteractiveLogonRight
Diritto “Deny”User Rights Assignment → Deny log on through Remote Desktop ServicesHa precedenza su Allow
Abilitazione RDPSystem Properties → Remote (o GPO: RDS → Session Host → Connections)Serve oltre al diritto; attiva anche regole del firewall
GPMCgpmc.mscUsata per identificare/modificare GPO
Report criterigpresult /h, rsop.mscConferma GPO vincente e valori effettivi
Gruppo consigliatoRemote Desktop UsersAggiungi qui gli utenti; evita utenti individuali nella GPO

Risoluzione dei problemi: scenari comuni

Utente in “Remote Desktop Users”, ma accesso negato

  • Controlla Deny log on through Remote Desktop Services (inclusioni indirette via gruppi annidati).
  • Verifica OU e GPO: un GPO diverso potrebbe sovrascrivere il diritto più a valle.
  • Esamina gli eventi 4625 per motivazioni “user rights assignment” o “logon restriction”.

GPO corretta ma l’editor locale mostra ancora il pulsante grigio

È normale: l’editor locale resta in sola lettura se il criterio è definito a livello di dominio. Concentrati sui report RSoP/gpresult per confermare il valore effettivo.

Accesso RDP ai soli amministratori, altri utenti esclusi

Molte baseline consentono RDP solo a Administrators. Aggiungi il gruppo Remote Desktop Users (o un gruppo aziendale) al diritto Allow log on through Remote Desktop Services nella GPO dedicata ai server interessati.

Server demo o laboratorio in workgroup

Il tasto non dovrebbe essere grigio. Se lo è, verifica se sono stati importati criteri locali tramite strumenti come LGPO o script di sicurezza. In tal caso, reimposta il criterio locale o rimuovi l’import.

Procedura consigliata di implementazione in produzione

  1. Crea gruppi di sicurezza: ad es. GGRDPAmministrazione, GGRDPAppTeamX.
  2. Crea un GPO dedicato (es. GPO‑RDP‑UserRights) e linkalo all’OU che contiene i server target.
  3. Imposta il diritto Allow includendo i gruppi creati e lascia Administrators se necessario per emergenze.
  4. Verifica Deny: assicurati che nessuno dei gruppi sopra sia richiamato nel diritto Deny.
  5. Documenta (runbook): quali OU, quali gruppi, chi gestisce membership, tempi di replica.
  6. Test pilota su un server non critico; poi estendi l’applicazione.

Domande frequenti (FAQ)

Il problema può dipendere dal firewall?
Il firewall non rende grigio il pulsante; ma se RDP è abilitato e i diritti sono corretti, un firewall che blocca 3389/TCP impedirà comunque la connessione. Verifica le regole “Remote Desktop”.

Serve anche aggiungere l’utente al gruppo locale “Remote Desktop Users”?
Su server membro è buona pratica. Su DC operi solo con gruppi di dominio. Il diritto GPO governa l’autorizzazione al logon, la membership locale incide su permessi applicativi e semplifica la gestione.

Posso forzare da locale ignorando il GPO?
No. Una volta che il GPO definisce l’impostazione, la configurazione locale è sovrascritta ad ogni refresh. Intervieni sempre sulla GPO vincente.

È meglio usare utenti o gruppi nella GPO?
Gruppi, per scalabilità e auditing. Evita riferimenti a singoli account nelle policy.

Esempio completo: dal sintomo all’esito

  1. Il tecnico riceve il messaggio “Per connettersi in remoto occorre il diritto ‘Allow log on through Remote Desktop Services’…”.
  2. In secpol.msc vede il pulsante “Add User or Group” grigio: deduce che il criterio è gestito da GPO.
  3. In gpmc.msc individua il GPO dell’OU dei server e modifica Allow log on through Remote Desktop Services aggiungendo il gruppo aziendale GGRDPAppTeamX.
  4. Esegue gpupdate /force sul server.
  5. Con gpresult /h verifica che il GPO modificato sia winning e che non esista un Deny confliggente.
  6. Aggiunge (se server membro) l’utente al gruppo locale Remote Desktop Users.
  7. Nuovo tentativo di accesso: RDP riuscito.

Modello di change e nota di sicurezza

Registra sempre in ticketing: server/OU, GPO modificata, gruppi aggiunti, motivazione, approvatore, data/ora. Applica il principio del privilegio minimo: solo chi ne ha effettiva necessità deve ottenere il diritto RDP, con revisione periodica delle membership.


Appendice: script e controlli (facoltativi)

PowerShell – verifica rapida membership e servizio

# Verifica servizio RDP
Get-Service -Name TermService

Regole firewall Remote Desktop

Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Where-Object Enabled -eq True

Gruppi dell'utente corrente (utile su server membro)

whoami /groups 

Verifica impostazione RDP lato sistema

# Mostra se il Desktop Remoto è abilitato (1=abilitato, 0=disabilitato)
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections

Promemoria percorsi GPO

  • Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment
  • Computer Configuration → Policies → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Connections

Conclusione

Pulsante grigio = criterio imposto da GPO: non è un errore del sistema, ma un comportamento atteso. La correzione deve avvenire nella GPO che governa il server. Seguendo i passaggi indicati — modifica del diritto in GPMC, refresh dei criteri e verifica con gpresult/RSoP — ripristini in modo controllato l’accesso via RDP, mantieni la conformità alle policy aziendali e riduci i rischi di configurazioni incoerenti tra server.


Esito atteso

  1. L’account/gruppo è stato aggiunto a Allow log on through Remote Desktop Services nella GPO corretta.
  2. L’utente (o il gruppo) è presente in Remote Desktop Users sul server membro (se applicabile).
  3. Dopo gpupdate /force la connessione RDP ha esito positivo.

Note operative finali

  • Pulsante grigio = modificare in GPMC, non in secpol.msc.
  • Miglior pratica: GPO dedicata e link all’OU dei server.
  • Replica AD: verifica salute e latenza.
  • Privilegio minimo: concedi il diritto RDP solo a chi serve.

Indice