Quando RDP si connette ma si blocca al login
Il caso classico è questo: la sessione RDP arriva fino alla schermata di accesso, le credenziali vengono accettate, poi la finestra resta nera, si chiude, oppure rimane ferma su Securing remote connection, Preparing your desktop o un desktop vuoto che non carica mai. Su Windows 11 come su Windows Server, il problema raramente è “RDP rotto” in senso generico. Di solito il blocco avviene in uno di questi punti: autenticazione con NLA, caricamento del profilo utente, inizializzazione della shell, policy/GPO, oppure un componente di sessione che non risponde abbastanza in fretta da far completare l’avvio.
La regola pratica è semplice: prima si capisce in quale layer si ferma, poi si interviene con la modifica minima e reversibile. Se si inizia a toccare servizi, profili o policy senza osservare i log, si allunga solo il tempo di diagnosi e si rischia di peggiorare il problema su più utenti.
Layer da isolare: rete, autenticazione, profilo, shell
Il flusso RDP, semplificando, passa da trasporto e TLS, autenticazione, creazione sessione, caricamento profilo, avvio explorer o shell alternativa. Il blocco al login indica spesso che la connessione è arrivata al server, ma l’utente non riesce a completare il bootstrap della sessione. Questo è importante perché cambia completamente l’approccio: se il problema fosse di rete pura, vedresti timeout o rifiuto della porta 3389; qui invece la porta risponde, ma qualcosa si rompe dopo l’handshake.
Le cause più frequenti, in ordine di probabilità operativa, sono:
NLA o credenziali/Kerberos/SSO che non completano correttamente l’autenticazione, spesso per policy, trust o mismatch di tempo.
Profilo utente corrotto o bloccato, con caricamento lento o fallito di hive, cache o impostazioni di shell.
Shell o GPO che impediscono l’avvio del desktop, per esempio un logon script, una policy di redirect o un’applicazione che parte al login e si pianta.
Se il blocco è sistematico su un solo utente, il profilo o le policy personali sono i primi sospetti. Se colpisce tutti gli utenti, il problema è più probabilmente lato server, dominio, servizi di autenticazione o aggiornamento recente.
Verifiche immediate lato client e lato server
Prima di cambiare qualcosa, raccogli evidenza minima. Serve capire se la sessione fallisce in modo ripetibile, se il problema riguarda solo un host, se dipende da un account specifico o da più account. Se hai accesso alla macchina server in console locale o tramite hypervisor, meglio ancora: puoi guardare i log anche quando RDP non entra.
Dal client verifica che la porta sia raggiungibile e che non ci siano problemi di base con il trasporto.
Test-NetConnection server.example.local -Port 3389Atteso: TcpTestSucceeded : True. Se è false, il problema non è il login ma il percorso di rete, firewall o servizio non in ascolto.
Prova una connessione con debug minimo e senza salvare credenziali, per escludere un profilo client corrotto.
mstsc /v:server.example.localSe il client Windows mostra un comportamento diverso rispetto ad altri client RDP, il problema può stare anche nel profilo locale o nelle credenziali memorizzate.
Sul server, controlla i log degli eventi di Remote Desktop e del profilo utente.
Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-LocalSessionManager/Operational" -MaxEvents 30 | Select-Object TimeCreated,Id,LevelDisplayName,Message
Get-WinEvent -LogName "Microsoft-Windows-User Profile Service/Operational" -MaxEvents 30 | Select-Object TimeCreated,Id,LevelDisplayName,MessageAtteso: nessun errore ripetuto di caricamento profilo, logon failure, shell failure o disconnessione immediata.
Controlla se il servizio RDP è attivo e se il server accetta nuove sessioni.
Get-Service TermServiceAtteso: stato Running. Se il servizio è avviato ma le sessioni non si aprono, il problema è più in alto nello stack.
Se hai una macchina in dominio, vale la pena verificare anche la sincronizzazione oraria. Un clock fuori tolleranza rompe Kerberos e in certi casi manda in crisi NLA, con sintomi che sembrano un blocco generico al login.
NLA e autenticazione: il punto più facile da falsare
Network Level Authentication è utile, ma quando qualcosa nel dominio non torna diventa il primo punto di rottura. Se il server è membro di dominio e il client usa account dominio, un problema di trust, ticket, DNS o orario può far fallire l’accesso prima ancora che la sessione venga creata davvero. Il sintomo visto dall’utente spesso non è un messaggio chiaro, ma una chiusura immediata o un blocco su schermata nera.
La verifica rapida è guardare se il problema sparisce usando un account locale amministrativo, o da una console fuori banda. Se il login locale funziona e quello di dominio no, NLA, policy di sicurezza o dominio sono in cima alla lista. Se invece nessun utente entra, il problema è più probabilmente lato host o profilo globale.
Per testare senza fare danni, puoi disabilitare temporaneamente NLA solo come prova controllata, sapendo che riduce la superficie di sicurezza. Va fatto solo in finestra di manutenzione e con rollback pronto.
Apri System Properties > Remote e verifica la spunta su Allow connections only from computers running Remote Desktop with Network Level Authentication.
Se serve una prova rapida, rimuovi temporaneamente la spunta, testa il login e osserva se la sessione si completa.
Se il login funziona senza NLA, il problema è quasi certamente nel sottosistema di autenticazione, nel trust di dominio o nella policy client/server.
Rollback: riattiva NLA appena terminata la verifica.
In ambienti gestiti, controlla anche le GPO applicate con gpresult /h. Un criterio di sicurezza che impone Smart Card, restrizioni di logon, eventuali limitazioni sui gruppi autorizzati o policy di sessione può bloccare il login senza che il problema sia evidente dal lato client.
Profilo utente corrotto o bloccato
Il profilo è un colpevole ricorrente. Se il blocco avviene dopo l’inserimento delle credenziali e la sessione resta sospesa o nera, spesso il sistema sta provando a caricare un profilo danneggiato, un hive bloccato o una cartella profilo con permessi incoerenti. In questi casi, il problema può presentarsi solo per un utente, oppure per più utenti se la cartella di profilo è su storage condiviso o se c’è un redirect mal configurato.
Un controllo utile è la presenza di eventi del servizio profilo, soprattutto errori di caricamento, creazione di profilo temporaneo o accesso negato. Se il sistema crea un profilo temporaneo, l’utente può anche riuscire a entrare ma con desktop vuoto, impostazioni mancanti o sessione che si interrompe subito dopo.
Controlla il registro eventi del profilo utente.
Get-WinEvent -LogName "Microsoft-Windows-User Profile Service/Operational" -MaxEvents 50 | Format-Table TimeCreated,Id,Message -WrapAtteso: nessun errore di caricamento o creazione profilo temporaneo.
Verifica se esiste un profilo temporaneo o duplicato sotto C:\Users e se il nome utente è associato a più cartelle o SID incoerenti nel registro.
Se il problema riguarda un solo account, rinomina la cartella profilo interessata e lascia che Windows ne ricrei una nuova al prossimo accesso, dopo backup dei dati utente.
Rollback: ripristina la cartella originale se la nuova sessione non si comporta meglio e hai bisogno dei dati precedenti.
Qui il punto non è “cancellare il profilo” a occhi chiusi. Prima salva dati e hive necessari, poi fai una prova controllata. Se hai ambienti con roaming profile o folder redirect, verifica anche i path di rete e i permessi sul file server, perché il blocco può essere causato dal backend e non dal client Windows in sé.
Shell, Explorer e logon script che bloccano la sessione
Un desktop che non compare non significa per forza che l’utente non sia autenticato. Può darsi che la shell non parta, che explorer.exe si chiuda, o che uno script di logon tenga la sessione in attesa troppo a lungo. In ambienti con GPO vecchie, script batch, mapping di drive verso share lente o applicazioni legacy, il login RDP si trasforma facilmente in un collo di bottiglia.
Se puoi aprire una console alternativa, prova a lanciare manualmente explorer o a vedere se il sistema risponde. Se la shell parte da console ma non da RDP, la causa spesso è in una policy utente, in un task schedulato al logon o in un componente grafico che va in timeout solo nella sessione remota.
Controlla le GPO applicate all’utente e al computer.
gpresult /h C:\Temp\gpresult.htmlAtteso: nessuna policy che imponga shell custom, script bloccanti o restrizioni anomale sul desktop remoto.
Verifica la presenza di script di logon in Active Directory o tramite Group Policy Management.
Se sospetti un logon script, disabilitalo temporaneamente per un account di test o applica una OU di prova.
Rollback: riabilita lo script solo dopo aver confermato che non è la causa e, se serve, riscrivilo con timeout e logging.
Un indizio forte è quando il problema compare dopo un cambiamento apparente “innocuo”: nuova policy di sicurezza, modifica di un drive mapping, installazione di agent EDR o aggiornamento di un software che si aggancia al logon. In questi casi il confronto con un account di test pulito è più veloce di qualsiasi analisi teorica.
Servizi, patch e regressioni dopo aggiornamenti
Windows 11 e Windows Server possono mostrare regressioni dopo update cumulativi, driver grafici, componenti di sicurezza o hardening. Se il blocco al login è iniziato subito dopo una manutenzione, la prima ipotesi da prendere sul serio è una regressione introdotta dal change. Qui il dato più utile non è “il server è lento”, ma il momento esatto in cui il sintomo è comparso rispetto al rilascio.
Per ridurre il blast radius, confronta un host sano con uno guasto: stessa build, stesso dominio, stessa policy, stesso gruppo di applicazione. Se il problema si concentra su una sola macchina, il rollback del change è la strada più pulita. Se invece è trasversale, il target è più probabilmente una GPO, un servizio comune o un update distribuito in massa.
Verifica gli ultimi aggiornamenti installati.
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10Atteso: nessun update appena installato in coincidenza temporale con il problema, oppure una corrispondenza chiara da testare.
Controlla il Visualizzatore eventi per errori applicativi e di sistema nella finestra temporale del login fallito.
Se il problema è iniziato dopo un update, valuta il rollback del pacchetto più recente su una macchina di test o in finestra controllata.
Rollback: disinstalla l’update solo se hai un punto di ripristino o una procedura di rientro già validata.
In ambienti server, controlla anche eventuali agent di sicurezza, DLP, EDR o tool di gestione remota. Sono componenti legittimi, ma possono interferire con il logon se aggiornati male o se una policy troppo aggressiva blocca processi di sessione.
Checklist di diagnosi rapida in 10 minuti
Se devi fare triage veloce, questa è la sequenza più efficiente. L’obiettivo è capire se il problema è di rete, autenticazione, profilo o shell, senza cambiare più di una cosa per volta.
Verifica connettività e porta 3389: Test-NetConnection server -Port 3389.
Prova con un account locale o un account diverso per capire se è legato all’utente.
Controlla i log TerminalServices e User Profile Service per errori nello stesso timestamp.
Confronta comportamento con e senza NLA, solo come test controllato.
Se il problema è iniziato dopo un change, sospendi o reverti l’ultimo elemento modificato: update, GPO, agent, script, profilo.
Se uno di questi passi produce un risultato diverso dal previsto, hai già ristretto molto il campo. Per esempio: porta aperta ma login fallito con tutti gli utenti = problema lato server; login fallito solo per un utente = profilo o policy; login che funziona con NLA disattivato = autenticazione o trust; sessione nera dopo autenticazione = shell, script o driver grafico.
Fix strutturale: come evitare che ricapiti
Una volta individuata la causa, il fix strutturale non è solo “far ripartire RDP”. Serve ridurre la probabilità di ricaduta. Se il problema era un profilo corrotto, conviene standardizzare backup e ricreazione profilo con documentazione chiara. Se era una GPO, va separata la policy di sicurezza da quella di comodità operativa, così non rompi il logon di tutti per una singola modifica. Se era un update, serve una pipeline di test almeno su un host pilota prima della distribuzione larga.
In più, conviene tenere una baseline minima: tempo di login medio, percentuale di sessioni fallite, ultimi eventi di profilo e terminal services, stato degli update recenti. Non è un lusso da enterprise; è il modo più semplice per capire quando il problema è ancora locale e quando sta diventando sistemico.
Assunzione operativa: i comandi mostrati sono da eseguire con privilegi adeguati e in finestra di manutenzione quando si toccano NLA, GPO, profili o aggiornamenti.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.