1 10/05/2026 4 min

Errore 0x516 in Desktop remoto: dove si rompe davvero

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

La cosa utile da sapere è questa: 0x516 non identifica una singola causa. È un sintomo di handshake fallito. Se lo tratti come errore “di rete” rischi di perdere tempo; se lo tratti come “RDP rotto” fai ancora peggio. Conviene invece dividere il controllo in livelli: DNS e raggiungibilità, porta 3389 e risposta del server, autenticazione/NLA, autorizzazioni dell’utente, stato del servizio Terminal Services, infine eventuali policy o hardening che impediscono l’accesso.

Classificazione operativa

Categoria: troubleshooting. Se il problema è su un server di produzione, va trattato come 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

Le tre cause che vedo più spesso, in ordine di probabilità, sono queste:

  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 disabilita temporaneamente NLA solo per test su una finestra controllata.

  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/di dominio lo nega. Come falsificarla: verifica l’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 TerminalServices.

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, usa quello 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