1 10/05/2026 14/05/2026 8 min

Errore 0x516 in Desktop remoto: dove si rompe davvero

Quando Desktop remoto su Windows restituisce 0x516, il problema non è “RDP in generale”: quasi sempre il fallimento avviene nella fase iniziale della connessione, prima che la sessione venga aperta davvero. In pratica il client prova a negoziare il canale RDP, ma il server interrompe il flusso per un motivo preciso: credenziali non valide, Network Level Authentication che blocca l’accesso, account non abilitato, policy restrittiva, servizio remoto instabile o conflitto tra parametri della sessione.

Il punto utile è questo: 0x516 non identifica una singola causa. È il sintomo di un handshake fallito. Se lo tratti come un problema “di rete” rischi di perdere tempo; se lo tratti come “RDP rotto” fai ancora peggio. Conviene separare i controlli per livello: DNS e raggiungibilità, porta 3389 e risposta del server, autenticazione e NLA, autorizzazioni utente, stato del servizio TermService, infine policy o hardening che impediscono l’accesso.

Classificazione operativa

Categoria: troubleshooting. Se il problema riguarda un server di produzione, va trattato come un incidente con possibile impatto utenti.

Stato atteso: il client RDP si autentica e apre la sessione remota sul sistema Windows target. Stato osservato: la connessione fallisce con 0x516, spesso dopo l’inserimento delle credenziali o subito dopo il tentativo di handshake.

Ipotesi più probabili, in ordine

  1. NLA o credenziali respinte: il server richiede Network Level Authentication, ma l’account non è valido, la password è scaduta, l’orario è fuori sync o il dominio non risponde bene. Come falsificarla in meno di 5 minuti: prova con un account locale noto valido oppure verifica temporaneamente, su finestra controllata, se il problema sparisce con NLA disattivata.

  2. Account non autorizzato a RDP: l’utente non è nel gruppo Remote Desktop Users, non ha il diritto di logon via desktop remoto, oppure una policy locale o di dominio lo nega. Come falsificarla: verifica appartenenza ai gruppi e il diritto Allow log on through Remote Desktop Services.

  3. Servizio RDP o policy lato server incoerenti: il servizio TermService è in stato anomalo, il listener non risponde, oppure GPO e hardening hanno cambiato parametri critici. Come falsificarla: controlla lo stato del servizio, la porta 3389 in ascolto e i log eventi di Terminal Services.

Verifiche immediate: prendi prima evidenza, poi tocchi la macchina

Prima di modificare qualcosa, raccogli tre segnali semplici: raggiungibilità, autenticazione e log. L’obiettivo è capire se il problema è sul client, sul trasporto o sulla policy del server.

  1. Verifica che il server risponda sulla porta RDP. Da un host esterno alla macchina target esegui:

    Test-NetConnection nomehost-o-ip -Port 3389

    Se TcpTestSucceeded è False, il problema è sotto il livello applicativo: firewall, porta chiusa, servizio RDP fermo o NAT/ACL che blocca.

  2. Controlla il nome e la risoluzione. Se usi un nome DNS, verifica che punti all’IP giusto:

    nslookup nomehost

    Un record vecchio, un proxy DNS o un CNAME errato possono farti finire su un server diverso, magari con policy RDP incompatibili.

  3. Leggi gli eventi RDP sul server. Sul target apri Event Viewer e guarda sotto Applications and Services Logs > Microsoft > Windows > TerminalServices-*. Eventi di autenticazione fallita, logon negato o sessione interrotta sono più utili del messaggio generico del client.

  4. Verifica l’account. Sul server controlla che l’utente sia abilitato e non bloccato:

    net user nomeutente /domain

    Se è un account locale, usa la console utenti locali o lusrmgr.msc dove disponibile. Se l’account è scaduto o disabilitato, il client può restituire errori poco espliciti come 0x516.

Soluzione consigliata passo-passo

Qui conviene procedere con la modifica minima, reversibile, e solo dopo conferma dei log. Non ha senso disattivare protezioni a caso su un server esposto.

  1. Prova con un account noto funzionante. Se hai un amministratore locale o un account di servizio autorizzato, usalo per capire se il problema riguarda l’utente o la macchina. Se il login riesce, il nodo è l’autorizzazione del profilo originale, non RDP in sé.

  2. Controlla l’appartenenza al gruppo RDP. Sul server verifica che l’utente sia nel gruppo locale Remote Desktop Users oppure in un gruppo di dominio che eredita il diritto:

    net localgroup "Remote Desktop Users"

    Se l’utente non compare, aggiungilo solo se è coerente con il modello di accesso previsto. Dopo il cambio, chiudi e riapri la sessione RDP per forzare il refresh dei token.

  3. Verifica il diritto di accesso tramite policy. Anche un utente nel gruppo giusto può essere bloccato da una GPO o da una policy locale. Controlla il criterio Allow log on through Remote Desktop Services e l’eventuale negazione Deny log on through Remote Desktop Services. Se una deny policy è presente, prevale sempre.

  4. Allinea NLA con il contesto reale. Se il server è in dominio e il client sta usando credenziali cache o un account locale, il fallimento può dipendere da autenticazione anticipata e non da RDP puro. Verifica che il controller di dominio sia raggiungibile, che l’orario sia allineato e che l’account non richieda cambio password al primo accesso. Se serve un test rapido, prova in finestra controllata a disabilitare temporaneamente NLA sul server per distinguere un problema di autenticazione da un problema di sessione. Ripristina subito il valore originale dopo il test.

  5. Riavvia in modo mirato il servizio remoto solo se i log lo giustificano. Se TermService è bloccato o il listener non risponde, un riavvio del servizio può sbloccare la connessione senza reboot completo:

    sc query TermService
net stop TermService
net start TermService

    Su macchine con sessioni attive, questo può interrompere utenti collegati: trattalo come change con impatto e fai il passaggio solo in manutenzione o dopo verifica del blast radius.

  6. Controlla firewall, ACL e NAT. Se la porta risulta chiusa dall’esterno ma il servizio è attivo localmente, verifica regole Windows Firewall, security group cloud, ACL per subnet e eventuale port forwarding. La porta standard resta 3389, ma in ambienti hardenizzati può essere stata spostata: in quel caso controlla il listener reale sul server prima di assumere che il problema sia la rete.

Controlli mirati sul server Windows

Se hai accesso locale o out-of-band, questi controlli riducono il tempo di diagnosi e ti dicono se il problema è di configurazione o di stato del servizio.

  1. Verifica che RDP sia abilitato. Dal pannello di sistema controlla Remote Desktop nelle impostazioni di accesso remoto. Su sistemi recenti il percorso è in System Properties > Remote. Se l’opzione è disattivata, il client può fallire in modi non sempre intuitivi.

  2. Controlla il listener. Sul server verifica che la porta sia in ascolto:

    netstat -ano | findstr :3389

    Se non compare alcun listener, il servizio non sta pubblicando RDP oppure la porta è stata modificata.

  3. Leggi i log di autenticazione. Oltre ai log di Terminal Services, controlla Security per eventi di logon fallito e System per errori del servizio. Un pattern ripetuto di fallimenti con codice coerente è molto più affidabile del solo errore lato client.

  4. Controlla eventuali limitazioni di sessione. Policy come il numero massimo di sessioni, il timeout o la chiusura automatica delle sessioni disconnesse possono impedire l’accesso se il server è saturo o mal configurato. In ambienti terminal server o VDI il problema può sembrare di autenticazione, ma in realtà è capacità o licenza.

Quando il problema non è RDP ma il contesto

Ci sono casi in cui 0x516 è solo il messaggio finale di un problema a monte. Un dominio con replica in ritardo, un DNS che punta al server sbagliato, una password appena cambiata ma non ancora propagata, oppure una macchina appena clonata con SID o policy incoerenti possono produrre lo stesso sintomo. Se il server è in cloud, aggiungi al controllo anche security group, NACL, appliance di sicurezza e eventuali regole del provider.

Un dettaglio frequente in ambienti aziendali è l’uso di hardening aggressivo: disabilitazione di protocolli legacy, restrizioni su NTLM, blocco degli account locali o rimozione del gruppo amministratori dai diritti di logon remoto. Sono scelte legittime, ma vanno documentate perché cambiano il comportamento atteso di RDP e rendono più difficile interpretare un errore generico come 0x516.

Rollback e impatto operativo

Ogni modifica fatta per testare la causa va riportata indietro se non risolve il problema. Se hai disattivato NLA, riattivala subito dopo il test. Se hai aggiunto un utente al gruppo Remote Desktop Users, rimuovilo se non autorizzato. Se hai toccato una GPO locale, annota il valore precedente prima di applicare il cambio. Se hai riavviato TermService, verifica che le sessioni già aperte non abbiano subito effetti collaterali.

Assunzione operativa: su server di produzione ogni modifica a RDP ha blast radius potenzialmente alto, perché può impattare l’accesso amministrativo e la continuità delle sessioni attive. Per questo la sequenza corretta resta sempre: evidenza, test reversibile, verifica, solo dopo eventuale correzione strutturale.

Verifica finale: cosa deve cambiare quando il problema è risolto

  1. La connessione RDP si apre senza 0x516 e il client arriva al desktop remoto.

  2. Il log del server non mostra nuovi errori di autenticazione per quell’utente o per quel tipo di accesso.

  3. La porta e il servizio restano coerenti: Test-NetConnection nomehost-o-ip -Port 3389 restituisce True e TermService è in esecuzione.

  4. Le modifiche temporanee sono state annullate, soprattutto se hai usato NLA o policy locali come leva diagnostica.

In pratica, 0x516 si risolve quasi sempre smontando l’ipotesi sbagliata prima di cambiare impostazioni. Se parti da log, gruppo utenti, NLA e stato del servizio, arrivi alla causa vera molto più in fretta che non tentando riavvii o disattivazioni casuali.