Hai attivato Desktop remoto ma le credenziali vengono sempre rifiutate? In questa guida pratica per Windows 10/11 su rete locale trovi i passaggi dettagliati per capire quale nome utente usare, come abilitare i permessi corretti e quali controlli fare su password, firewall e configurazione RDP.
Panoramica del problema
Due PC Windows sulla stessa rete locale, il PC di origine avvia “Connessione Desktop remoto” (mstsc) verso il PC di destinazione, ma l’autenticazione fallisce: “Le credenziali non hanno funzionato” oppure “Il nome utente o la password non sono corretti”. La difficoltà più frequente riguarda quale nome utente immettere (account locale, Microsoft, Azure AD o dominio) e chi è autorizzato ad accedere via RDP sul computer remoto.
Come funziona davvero l’autenticazione RDP in Windows
Quando ti colleghi via RDP, il PC di destinazione verifica tre cose nell’ordine:
- Identità: esiste un account con quel nome che il sistema riconosce (locale, Microsoft, Azure AD o del dominio)?
- Segreto: la password inserita corrisponde a quell’account (attenzione: PIN/Windows Hello non sono validi al primo accesso RDP).
- Autorizzazione: quell’utente è autorizzato a eseguire “accesso tramite Servizi Desktop remoto” (appartenenza al gruppo Remote Desktop Users o privilegi di amministratore; assenza di criteri che lo negano).
Se uno dei tre anelli si rompe, l’accesso fallisce anche se gli altri due sono corretti.
Tabella riassuntiva dei passaggi e delle correzioni
| Passaggio | Spiegazione |
|---|---|
| Identificare il tipo di account sul PC di destinazione | Account locale: inserisci esattamente il nome utente locale (es. PC-DI-MARIO\mario o solo mario).Account Microsoft: usa l’intero indirizzo e‑mail (es. nome@outlook.com). In alcuni casi funziona anche il prefisso MicrosoftAccount\ (es. MicrosoftAccount\nome@outlook.com).Azure AD (Aziendale/istruzione): usa AzureAD\utente@azienda.com.Dominio Active Directory: usa DOMINIO\utente oppure utente@dominio.local (UPN). |
| Verificare il nome utente corretto | Esegui whoami nel Prompt dei comandi del PC di destinazione per ottenere il nome di accesso preciso. Utile anche whoami /user (SID), whoami /groups e whoami /all. |
| Aggiungere l’utente al gruppo “Remote Desktop Users” | Pannello di controllo → Sistema → Impostazioni Desktop remoto → “Seleziona utenti…”. L’utente che si collega deve essere in questo gruppo oppure avere privilegi di amministratore. |
| Metodo di autenticazione supportato | Windows Hello/PIN non è accettato al primo accesso via RDP. Servono le credenziali classiche (password). Dopo il primo accesso riuscito potrai continuare a usare PIN localmente. |
| Controllare e gestire gli account | Digita netplwiz per aprire “Account utente” e vedere/gestire nomi e tipi di account. Su edizioni Pro/Enterprise puoi usare anche lusrmgr.msc (Gestione utenti locali). |
Formati corretti del nome utente
Se non sei sicuro in che forma scriverlo, usa questa tabella come “anti-errore”.
| Scenario | Formato da usare in RDP (utente) | Esempio |
|---|---|---|
| PC non in dominio, account locale | nome oppure PC\nome | mario o DESKTOP-ABCD\mario |
| PC non in dominio, account Microsoft | indirizzo-email oppure MicrosoftAccount\indirizzo-email | nome@outlook.com o MicrosoftAccount\nome@outlook.com |
| PC Azure AD join | AzureAD\UPN | AzureAD\nome.cognome@azienda.com |
| PC in dominio Active Directory | DOMINIO\utente oppure UPN | CONTOSO\mario o mario@contoso.local |
Nota sugli alias Microsoft: se il tuo account Microsoft ha più alias (@outlook.com, @hotmail.com), usa quello che vedi in Impostazioni → Account sul PC di destinazione. In caso di rifiuto, prova il prefisso MicrosoftAccount\.
Abilitare Desktop remoto in modo corretto
Prima dell’autenticazione, il servizio deve essere attivo:
- Vai su Impostazioni → Sistema → Desktop remoto e attiva Abilita Desktop remoto.
- Lascia spuntata l’opzione “Consentire le connessioni solo dai computer che eseguono Desktop remoto con NLA” (più sicuro).
- Controlla che il PC di destinazione non vada in sospensione durante l’orario di lavoro (Impostazioni → Sistema → Alimentazione e sospensione).
Concedere i permessi RDP all’utente giusto
Anche con nome corretto e password valida, senza autorizzazione riceverai “L’account non è autorizzato all’accesso remoto”. Per risolvere:
- Apri SystemPropertiesRemote.exe (cerca “Impostazioni Desktop remoto” o “Consenti accesso remoto al computer”).
- Clic su Seleziona utenti… e aggiungi l’utente. Gli amministratori sono già autorizzati per impostazione predefinita.
In alternativa da PowerShell (amministratore) sul PC di destinazione:
Add-LocalGroupMember -Group "Remote Desktop Users" -Member "mario"
oppure per un account Microsoft locale al dispositivo:
Add-LocalGroupMember -Group "Remote Desktop Users" -Member "MicrosoftAccount\nome@outlook.com"
Azure AD:
Add-LocalGroupMember -Group "Remote Desktop Users" -Member "AzureAD\nome.cognome@azienda.com"
Password, PIN e Windows Hello
Desktop remoto richiede password. Il PIN/Hello funziona solo per l’accesso interattivo locale al dispositivo. Se conosci solo il PIN:
- Per account Microsoft, reimposta la password del tuo account (è la stessa usata per Outlook/OneDrive). Poi ripeti l’accesso via RDP con l’indirizzo e‑mail e la nuova password.
- Per un account locale, crea o modifica la password in Impostazioni → Account → Opzioni di accesso → Password oppure con
net user mario *eseguito come amministratore sul PC di destinazione.
Dopo il primo accesso RDP riuscito, puoi continuare a usare PIN o Hello localmente sul PC, ma RDP continuerà a richiedere la password.
Firewall, porta 3389 e test di connettività
L’attivazione di Desktop remoto crea regole firewall per la porta TCP 3389. Se l’autenticazione è corretta ma la connessione non parte (nessun prompt credenziali), verifica:
- Windows Defender Firewall → Regole connessioni in ingresso → Desktop remoto (TCP‑In) sia Abilitata per il profilo di rete in uso (Privato/Aziendale/Pubblico).
- Da PowerShell sul PC di origine:
Test-NetConnection NOMEPC -Port 3389. Se TcpTestSucceeded è False, c’è un blocco di rete/firewall o il servizio non è in ascolto. - Assicurati che il target non sia in sospensione/ibernazione.
Per chiarezza, prova anche la forma IPv4 del nome host:
ping -4 NOMEPC
mstsc /v:NOMEPC
mstsc /v:192.168.1.50
Verifica dell’edizione di Windows
Il PC di destinazione deve eseguire Windows Pro/Enterprise/Education. Windows Home può connettersi come client ma non può ospitare sessioni RDP con il servizio integrato. Controlla in Impostazioni → Sistema → Informazioni l’edizione installata.
Diagnosi guidata, passo dopo passo
- Raccogli l’identità esatta sul PC di destinazione:
whoami whoami /allAnnota DOMINIO\utente o AzureAD\utente@azienda.com o l’indirizzo e‑mail Microsoft. - Prova il login locale sul PC di destinazione con le stesse credenziali (non PIN). Se fallisce, la password è errata o l’account è bloccato.
- Verifica i permessi RDP (gruppo “Remote Desktop Users”, nessuna policy di deny attiva).
- Controlla connettività e servizio:
services.msc verifica: Servizi Desktop remoto (in esecuzione) Test-NetConnection NOMEPC -Port 3389 - Pulisci le credenziali salvate sul client (evita che mstsc riproponga credenziali sbagliate):
control /name Microsoft.CredentialManager Oppure: cmdkey /list cmdkey /delete:TERMSRV/NOMEPC - Riprova inserendo manualmente utente + password nella forma corretta.
Messaggi di errore comuni e rimedi
| Errore tipico | Causa probabile | Soluzione rapida |
|---|---|---|
| “Le credenziali non hanno funzionato” | Nome utente nel formato sbagliato o password errata; credenziali salvate non aggiornate. | Usa il formato corretto (tabella sopra); elimina le credenziali salvate; verifica login locale con password. |
| “L’account non è autorizzato all’accesso remoto” | Utente non nel gruppo Remote Desktop Users; policy che nega l’accesso RDP. | Aggiungi l’utente al gruppo; in secpol.msc → Assegnazione diritti utente verifica Consenti accesso tramite Servizi Desktop remoto e Nega accesso…. |
| “Un errore di autenticazione” / “CredSSP encryption oracle remediation” | Incompatibilità aggiornamenti di sicurezza (CredSSP) tra client e server. | Aggiorna entrambi i PC; temporaneamente (solo per test) imposta “Encryption Oracle Remediation” su Mitigated in criteri di gruppo o registro, poi ripristina. |
| La finestra credenziali non appare | Porta 3389 bloccata o servizio non in ascolto. | Controlla firewall; Test-NetConnection -Port 3389; verifica che il PC non sia in sospensione. |
| “Il metodo di accesso utilizzato non è consentito” | Imposti che richiedono NLA ma client obsoleto o credenziali non supportate. | Aggiorna il client; assicurati di usare password; valuta di disattivare NLA solo per test, poi riattivala. |
Controlli di sicurezza locali e criteri che possono bloccare l’accesso
- Password vuote: Windows può rifiutare accessi di rete con password vuote (sicurezza locale → Opzioni di sicurezza → Account: limita l’uso di password vuote). Imposta sempre una password.
- Account disabilitato o scaduto: verifica con
net user <utente>se l’account è attivo e non scaduto. - Obbligo di cambio password al prossimo accesso: se impostato, RDP può fallire finché non cambi la password localmente.
- Negazioni esplicite: in secpol.msc → Assegnazione diritti utente rimuovi l’utente da Nega accesso tramite Servizi Desktop remoto.
Azure AD e scenari ibridi
Se il PC di destinazione è Azure AD join (tipico in azienda/scuola):
- Usa
AzureAD\utente@azienda.comcome nome utente nel client RDP. - Aggiungi l’utente (o un gruppo Azure AD) a Remote Desktop Users tramite Impostazioni → Desktop remoto → Seleziona utenti… o PowerShell.
- Assicurati che NLA sia abilitata e che il client sia aggiornato.
In domini Active Directory, preferisci DOMINIO\utente o l’UPN utente@dominio; evita ambiguità con utenti omonimi su più domini.
Comandi utili per fare il punto in pochi minuti
# Sul PC di destinazione (Prompt o PowerShell come admin)
whoami
whoami /all
net user
net localgroup "Remote Desktop Users"
Get-LocalGroupMember "Remote Desktop Users" # PowerShell
Dal PC di origine
mstsc /v:NOMEPC /prompt # forzare nuovo prompt credenziali
mstsc /admin # prova connessione console (amministratori)
cmdkey /list # credenziali salvate
cmdkey /delete:TERMSRV/NOMEPC
Test-NetConnection NOMEPC -Port 3389 Checklist rapida prima di arrendersi
- Conferma il formato utente giusto: locale (
PC\utente), Microsoft (email), AzureAD (AzureAD\email), dominio (DOMINIO\utente). - Verifica il nome reale con
whoamisul PC di destinazione. - Usa la password, non il PIN/Hello.
- Aggiungi l’utente a Remote Desktop Users oppure usa un account amministratore.
- Controlla Desktop remoto abilitato e firewall (porta 3389 aperta sul profilo corretto).
- Conferma che il PC di destinazione sia Windows Pro/Enterprise.
- Pulisci le credenziali salvate e riprova con
/prompt.
Suggerimenti aggiuntivi per evitare falsi problemi
- Indirizzo IP corretto: in reti con DNS casalingo non sempre il nome host risolve; se necessario usa l’IP v4.
- Profili di rete: mantieni la rete come Privata per ridurre restrizioni automatiche del firewall.
- Stato di alimentazione: disattiva temporaneamente sospensione/ibernazione sul PC di destinazione quando ti serve l’accesso remoto.
- Salva una connessione “pulita”: crea un file .rdp con solo host/IP e lascia vuoto il campo utente per evitare caching errato.
- Event Viewer: controlla gli ID evento di sicurezza (4625 per accesso non riuscito) e i log TerminalServices per indizi precisi.
- Sicurezza: tieni RDP attivo solo quando serve; non esporre la porta 3389 su Internet; usa NLA e password forti.
- Windows Home: non può ricevere connessioni RDP nativamente; in quel caso valuta strumenti remoti di terze parti affidabili.
Esempi pratici di inserimento credenziali
Supponiamo che il PC di destinazione si chiami STUDIO‑PC e l’utente sia “mario”. Ecco alcune combinazioni funzionanti, a seconda dello scenario:
# Account locale
Utente: STUDIO-PC\mario
Password: <password-locale-di-mario>
Account Microsoft (MSA)
Utente: [mario.rossi@outlook.com](mailto:mario.rossi@outlook.com)
Password:
In alternativa (se necessario):
Utente: MicrosoftAccount\[mario.rossi@outlook.com](mailto:mario.rossi@outlook.com)
PC Azure AD join
Utente: AzureAD\[mario.rossi@azienda.com](mailto:mario.rossi@azienda.com)
Password:
PC in dominio AD
Utente: CONTOSO\mario
Password: Quando il problema è il nome utente “giusto ma sbagliato”
Capita che il profilo locale collegato a un account Microsoft abbia un nome breve diverso dall’e‑mail (es. mario), ma per RDP devi comunque usare l’indirizzo e‑mail completo. Se usi il nome breve e fallisce, non insistere: passa alla forma nome@outlook.com. Se vedi messaggi alternati di “credenziali non valide” e “accesso negato”, elimina le credenziali memorizzate (cmdkey) e riprova.
Configurazioni avanzate e casi speciali
- Cambio porta RDP: se hai modificato la porta di ascolto, ricorda di specificarla nel client (
host:porta) e di aggiornare le regole firewall. - CredSSP e NLA: mantieni aggiornati entrambi i PC. Disattivare NLA è una prova temporanea: riattivala subito dopo.
- Blocco account: troppi tentativi errati possono bloccare temporaneamente l’utente (policy aziendale). Attendi lo sblocco o contatta un amministratore per reimpostarlo.
Conclusione
Nella quasi totalità dei casi l’errore di autenticazione RDP nasce da due cause: nome utente in formato non corretto e mancanza di autorizzazione sul PC di destinazione. Identifica il tipo di account, recupera il nome esatto con whoami, usa la password (non il PIN) e assicurati che l’utente sia nel gruppo Remote Desktop Users. Con firewall e Desktop remoto configurati correttamente, la connessione in rete locale tra Windows 10/11 dovrebbe riuscire senza ulteriori ostacoli.
Appendice: mini‑procedura “da incollare”
1) Sul PC di destinazione:
- Impostazioni → Sistema → Desktop remoto → Abilita.
- SystemPropertiesRemote.exe → Seleziona utenti… → aggiungi l'account.
- whoami → annota il nome esatto.
- Verifica servizio e firewall (porta 3389).
2. Sul PC di origine:
- mstsc /v:NOMEPC /prompt
- Inserisci l'utente nel formato corretto (tabella in guida).
- Usa la password (non PIN/Hello).
- Se fallisce ancora: svuota credenziali (cmdkey) e riprova.