Quando Windows mostra che la connessione è stata negata perché l’account utente non è autorizzato all’accesso remoto, la password non è il problema. È stata accettata, la sessione è stata rifiutata un passaggio dopo, in fase di autorizzazione.
Due verifiche determinano questo esito: l’account deve appartenere al gruppo locale Utenti Desktop remoto o al gruppo Amministratori, e deve comparire nel criterio Consentire l’accesso tramite Servizi Desktop remoto in secpol.msc. Se ne manca una, questo è l’errore che ottieni.
Un’impostazione prevale su entrambe: Negare l’accesso tramite Servizi Desktop remoto. Se l’account, o qualsiasi gruppo a cui appartiene, è in quell’elenco, viene bloccato indipendentemente da tutto il resto configurato.
Sui computer aggiunti al dominio c’è un quarto livello. I Criteri di gruppo a livello di dominio o di OU possono silenziosamente ripristinare le impostazioni locali al successivo aggiornamento, annullando una correzione che sembrava fatta pochi minuti fa.
Inizia dall’appartenenza ai gruppi, è la causa più comune.
Percorso di correzione rapida
Se vuoi iniziare subito senza leggere la spiegazione completa, segui questi passaggi nell’ordine e fermati quando l’errore si risolve.
-
Aggiungi l’account al gruppo locale Utenti Desktop remoto sul computer di destinazione.
-
Apri secpol.msc e conferma che il gruppo dell’account sia presente sotto Consenti l’accesso tramite Servizi Desktop remoto.
-
Nella stessa posizione, verifica l’impostazione Negare l’accesso tramite Servizi Desktop remoto e conferma che l’account non sia elencato lì.
-
Se il computer è membro del dominio, controlla il GPO di dominio in GPMC, non solo i criteri locali in secpol.msc.
-
Elimina le credenziali salvate obsolete dalla Gestione credenziali solo dopo aver confermato che le impostazioni dei criteri sopra indicate sono corrette.
Cosa segnalano gli utenti reali riguardo a questo errore
Il problema più segnalato nei forum: sembra che tutto sia corretto, ma l’errore persiste comunque. Un amministratore di dominio su Microsoft Q&A ha descritto una workstation Windows 11 che rifiutava tutte le connessioni RDP non amministrative nonostante l’appartenenza ai gruppi fosse corretta e secpol.msc locale apparisse pulito. Il vero blocco era un GPO a livello di dominio che sovrascriveva in silenzio le impostazioni locali. (Microsoft Q&A, settembre 2024)
Sulle VM di Azure, un problema correlato si presenta come un ciclo: un account viene aggiunto manualmente, le sessioni funzionano, poi l’account scompare dopo un riavvio e l’errore ritorna. La causa era un GPO Restricted Groups che rimuoveva l’appartenenza a ogni aggiornamento dei criteri, e nessuna correzione dall’interfaccia utente rimane efficace finché non viene aggiornato il GPO stesso. (Microsoft Tech Community, giugno 2023)
Le credenziali salvate sono un fattore scatenante meno evidente. Un pool RDS che aveva funzionato per anni ha iniziato all’improvviso a rifiutare tutti gli utenti con questo errore. Le autorizzazioni non erano cambiate. L’eliminazione della password salvata e il suo reinserimento manuale hanno risolto immediatamente, come confermato da più utenti nello stesso thread. (Microsoft Q&A, ottobre 2022)
Sulle VM di Azure unite al dominio, un amministratore che gestiva 1.000 utenti ha aggiunto account al criterio Consenti accesso tramite Servizi Desktop remoto, ha eseguito gpupdate /force e ha comunque riscontrato l’errore. Il passaggio mancante era aggiungere gli utenti al gruppo locale Utenti Desktop remoto sulla VM stessa. Entrambi i controlli sono necessari. (Microsoft Q&A, novembre 2022)
Negli ambienti gestiti con Intune, lusrmgr.msc non mostra il dominio di Azure come percorso disponibile, quindi la correzione standard basata sull’appartenenza al gruppo non si applica. Un criterio di configurazione Intune riuscito non è sufficiente da solo. È necessario un criterio separato che assegni il diritto Consenti accesso tramite Servizi Desktop remoto per i dispositivi aggiunti a Entra. (Microsoft Q&A, dicembre 2024)
Come risolvere La connessione è stata negata perché l'account utente non è autorizzato all'accesso remoto
Soluzione 1: Aggiungi l'utente al gruppo Utenti Desktop remoto
L’assenza di appartenenza a un gruppo è la causa più comune di questo errore sulle macchine standalone. Esegui questi passaggi sul PC remoto, non sulla macchina da cui ti stai connettendo. Tieni presente che lusrmgr.msc non è disponibile nelle edizioni Home di Windows, sebbene le edizioni Home non possano neppure fungere da host RDP.
-
Premi Win + R, digita lusrmgr.msc e premi Invio.
-
Seleziona Gruppi nel riquadro sinistro, quindi fai doppio clic su Utenti Desktop remoto.
-
Fai clic su Aggiungi.
-
Digita il nome utente, fai clic su Controlla nomi per confermare che venga risolto, quindi fai clic su OK.
-
Fare clic su OK per chiudere la finestra delle proprietà del gruppo.
Per un’alternativa più rapida tramite Proprietà del sistema: premi Win + R, digita sysdm.cpl, seleziona la scheda Remoto, fai clic su Seleziona utenti e aggiungi lì l’account.
Da un prompt di PowerShell con privilegi elevati sulla macchina remota:
Add-LocalGroupMember -Group “Remote Desktop Users” -Member “username”
Sostituisci username con il nome effettivo dell’account. Non è necessario riavviare.
Soluzione 2: Verifica il criterio Consenti l'accesso tramite Servizi Desktop remoto
L’appartenenza al gruppo e il criterio dei diritti utente vengono verificati in modo indipendente. Entrambi devono essere soddisfatti e correggerne uno senza l’altro lascia l’errore invariato. Esegui questi passaggi sul PC remoto.
-
Premi Win + R, digita secpol.msc e premi Invio.
-
Vai a Impostazioni di sicurezza > Criteri locali > Assegnazione diritti utente.
-
Fare doppio clic su Consenti l’accesso tramite Servizi Desktop remoto.
-
Verifica che Utenti Desktop remoto e Amministratori siano entrambi elencati. Se uno dei due manca, fai clic su Aggiungi utente o gruppo, digita il nome del gruppo e fai clic su OK.
-
Fare clic su OK, quindi eseguire quanto segue da un Prompt dei comandi con privilegi elevati: gpupdate /force
Su un computer membro del dominio, una GPO di dominio in conflitto può sovrascrivere questa impostazione entro pochi minuti dal salvataggio. Se l’impostazione viene ripristinata, vai a Fix 4.
Soluzione 3: verifica se un criterio di negazione ha la precedenza sull'impostazione Consenti
Il criterio Nega l’accesso tramite Servizi Desktop remoto blocca l’accesso a prescindere dall’appartenenza a un gruppo o dal criterio Consenti. Verifica questo criterio anche quando le impostazioni di Consenti sembrano complete.
-
In secpol.msc, vai su Impostazioni di sicurezza > Criteri locali > Assegnazione diritti utente.
-
Fare doppio clic su Nega l’accesso tramite Servizi Desktop remoto.
-
Esamina l’elenco. Se l’account che si connette, o qualsiasi gruppo a cui appartiene, inclusi Guests o Domain Guests, appare qui, selezionalo e fai clic su Rimuovi.
-
Fai clic su OK, quindi esegui gpupdate /force.
Se l’impostazione continua a ripristinarsi dopo averla salvata ed eseguito gpupdate /force, un GPO di dominio sta controllandoSe l’impostazione continua a ripristinarsi dopo averla salvata ed eseguito gpupdate /force, un GPO di dominio sta controllando a livello di dominio. Gestisci questo criterio solo tramite Criteri di sicurezza locali o Gestione Criteri di gruppo. Evita di tentare di modificare direttamente nel Registro di sistema le assegnazioni dei diritti utente, poiché i diritti di accesso al logon di tipo Consenti e Nega sono gestiti da Windows come costanti di privilegio denominate (SeRemoteInteractiveLogonRight e SeDenyRemoteInteractiveLogonRight), non come semplici valori del Registro. Per l’auditing, usa secpol.msc, gpresult o secedit.
Soluzione 4: intervenire direttamente sul GPO del dominio
Su una macchina aggiunta al dominio in cui le modifiche locali continuano a essere ripristinate, un GPO di dominio le sta sovrascrivendo. Questa correzione richiede l’accesso alla Console di gestione dei criteri di gruppo, in genere disponibile su un controller di dominio o su una macchina con RSAT installato.
-
Apri GPMC tramite Server Manager > Strumenti > Gestione Criteri di gruppo.
-
Espandi il dominio, fai clic con il pulsante destro del mouse sul GPO che controlla il computer interessato e seleziona Modifica.
-
Vai su Configurazione computer > Criteri > Impostazioni di Windows > Impostazioni di sicurezza > Criteri locali > Assegnazione diritti utente.
-
Apri Consenti l’accesso tramite Servizi Desktop remoto e conferma che Utenti Desktop remoto e Amministratori siano entrambi elencati.
-
Apri Nega l’accesso tramite Servizi Desktop remoto e conferma che l’account interessato e i relativi gruppi non sono elencati.
-
Salva le modifiche, quindi esegui il seguente comando sul computer interessato: gpupdate /force
Se il GPO pertinente non è immediatamente evidente, esegui questo comando sul computer interessato e apri il file risultante per identificare quale criterio controlla l’Assegnazione dei diritti utente:
gpresult /h gpreport.html
Soluzione 5: Elimina le credenziali salvate obsolete da Gestione credenziali
Questa è una causa meno comune, ma vale la pena verificarla dopo aver confermato che l’appartenenza ai gruppi e le impostazioni dei criteri sono corrette. Le credenziali RDP salvate possono diventare obsolete dopo una modifica della password, una migrazione dell’account o modifiche a un pool RDS. In alcuni casi, ciò produce errori di accesso che somigliano a errori di autorizzazione. La soluzione, documentata in un thread Microsoft Q&A in cui un pool RDS con credenziali salvate da anni ha improvvisamente iniziato a fallire per tutti gli utenti, è stata cancellare la voce memorizzata e reinserire manualmente le credenziali.
-
Apri il Pannello di controllo, vai su Account utente, quindi fai clic su Gestione credenziali.
-
Seleziona Credenziali Windows.
-
Cerca le voci che iniziano con TERMSRV/ seguite dal nome del computer o dall’indirizzo IP del PC remoto.
-
Espandi ogni voce rilevante e fai clic su Rimuovi.
-
Chiudi Gestione credenziali e prova nuovamente la connessione RDP, inserendo le credenziali manualmente quando richiesto.
Soluzione 6: Usa HelpWire come alternativa gratuita mentre sistemi RDP
Se l’errore di autorizzazione sta bloccando l’accesso a una macchina di cui hai bisogno subito, HelpWire ti offre una connessione remota funzionante mentre sistemi la configurazione dei criteri. Non utilizza il servizio Desktop remoto di Windows né la porta 3389, quindi i problemi relativi all’appartenenza ai gruppi e ai diritti utente che producono l’errore “account utente non autorizzato” non lo riguardano.
HelpWire funziona su Windows, macOS e Linux ed è gratuito da usare. La configurazione richiede pochi minuti: installa il client dell’operatore sulla tua macchina, installa l’agente HelpWire sulla macchina remota e connettiti. Per l’accesso non presidiato a una macchina che gestisci, l’agente può essere configurato per essere eseguito come servizio in background senza richiedere che qualcuno all’estremità remota accetti ogni connessione.
Domande frequenti
Gli account amministratore appartengono al gruppo Amministratori locale, che Windows include sempre nel criterio Consenti l’accesso tramite Servizi Desktop remoto. Gli account utente standard non vengono aggiunti per impostazione predefinita al gruppo Utenti Desktop remoto né al criterio Consenti l’accesso tramite Servizi Desktop remoto, quindi l’accesso viene negato finché entrambi non vengono configurati esplicitamente.
Sì. Le impostazioni GPO di dominio applicate a livello di dominio, sito o OU sovrascrivono le impostazioni locali di secpol.msc a ogni aggiornamento dei Criteri di gruppo. Se una correzione locale continua a essere ripristinata, è attiva una GPO in conflitto. Utilizza GPMC per risolvere il problema a livello di dominio ed esegui gpresult /h gpreport.html sul computer interessato per identificare quale criterio sta controllando Assegnazione diritti utente.
Impedisce a qualsiasi account elencato al suo interno, o a qualsiasi gruppo che contenga tale account, di connettersi tramite RDP. Il criterio di diniego ha la precedenza sia sull’impostazione Consenti accesso tramite Servizi Desktop remoto sia sull’appartenenza al gruppo Utenti Desktop remoto. Gli account possono finire in un gruppo di diniego per errore, ad esempio perché appartengono al gruppo Ospiti, che molti ambienti con hardening includono nel criterio di diniego per impostazione predefinita.
“La connessione è stata negata perché l’account utente non è autorizzato all’accesso remoto” significa che la richiesta di sessione ha raggiunto la macchina di destinazione ed è stata rifiutata a livello di autorizzazione, tipicamente a causa della mancanza di appartenenza a un gruppo, di una lacuna nei criteri dei diritti utente o di un criterio di negazione attivo. “Accesso negato” è più ampio e può anche indicare restrizioni di Credential Guard, limitazioni di accesso al SAM o problemi generali di autorizzazioni non direttamente legati ai diritti di accesso remoto nello specifico. La distinzione è importante perché orienta verso percorsi di risoluzione dei problemi differenti.
