Come risolvere l’errore account bloccato su VPS RDP

Account bloccato su VPS RDP: prima cosa da capire

Quando una VPS Windows via RDP restituisce un blocco account, il problema quasi mai è “il server non risponde”. Di solito il layer è uno di questi: autenticazione locale, policy di lockout, tentativi falliti da servizi esterni, password salvata male su un client, oppure un account amministrativo esposto a brute force. Se tratti il caso come un semplice guasto RDP rischi di perdere tempo e, peggio, di peggiorare il lockout con ulteriori tentativi.

Lo stato atteso è semplice: l’utente si autentica via Remote Desktop e ottiene una sessione. Lo stato osservato, invece, è un messaggio del tipo “The referenced account is currently locked out and may not be logged on to” oppure un rifiuto in Event Viewer con eventi di failed logon ripetuti. La priorità è sempre verificare quale account è bloccato, da dove arrivano i tentativi e se il blocco è locale o di dominio.

Diagnosi rapida: il layer giusto prima di toccare qualcosa

In un ambiente VPS RDP il blocco account nasce quasi sempre a livello di autenticazione, non di rete. La sequenza corretta è: verificare accesso alla console del provider, distinguere account locale da account di dominio, controllare i log di sicurezza e solo dopo intervenire sullo sblocco. Se l’account è quello amministrativo usato da automazioni, script o servizi, il problema può ripetersi subito dopo lo sblocco.

1. Verifica se hai accesso alla console out-of-band del provider. È il canale più utile quando RDP non entra più. Se il provider offre VNC, serial console o “rescue console”, usa quello prima di qualsiasi modifica.
2. Controlla se l’account è locale o di dominio. Un account locale si gestisce da lusrmgr.msc o PowerShell; un account di dominio può richiedere intervento su Active Directory, non sulla VPS.
3. Apri i log di sicurezza e cerca eventi di lockout e failed logon. I più utili sono 4740 per il lockout account e 4625 per i tentativi falliti.

Se non hai ancora una prova del punto di origine, non fare tentativi ripetuti di login. Ogni prova sbagliata può estendere il blocco o riattivare la policy di lockout.

Cause più probabili e come falsificarle in pochi minuti

1) Password salvata male su client o servizio. È il caso più comune. Un vecchio profilo RDP, un task scheduler, una mappatura rete o un servizio Windows stanno usando credenziali obsolete. Lo falsifichi cercando eventi 4625 con Workstation Name o Source Network Address riconducibili a un host specifico.

2) Brute force o tentativi automatizzati da Internet. Se la VPS espone RDP su porta pubblica, il lockout può arrivare da scansioni e tentativi ripetuti. Lo falsifichi guardando gli eventi di sicurezza con origine IP ripetuta o pattern di accesso distribuito. Se hai un firewall o un provider con log di rete, confronta gli orari con il lockout.

3) Account di dominio bloccato a monte. Se la VPS è in dominio, sbloccare localmente non basta. Lo falsifichi controllando se il nome account è nel formato dominioutente o UPN e verificando su domain controller gli eventi di lockout. Se non hai accesso al dominio, il gap va chiuso lì, non sulla VPS.

Verifiche immediate sulla VPS Windows

Le verifiche sotto non sono distruttive e servono a capire il punto di intervento. Se puoi, esegui tutto da console locale del provider, non da RDP finché l’account è in lockout.

1. Controlla gli eventi di sicurezza recenti. Da PowerShell amministrativo:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4740} -MaxEvents 20 | Select-Object TimeCreated, Id, Message

Atteso: trovi un evento con il nome dell’account bloccato. Se non c’è, allarga il filtro ai failed logon:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 50 | Select-Object TimeCreated, Id, Message

Atteso: vedi uno o più eventi con nome utente e, idealmente, indirizzo IP o workstation sorgente. Se non hai audit attivo, questo è un gap da chiudere dopo il ripristino.

1. Verifica la policy di lockout locale:

net accounts

Atteso: vedi Lockout threshold, durata e finestra di reset. Se il threshold è basso, anche pochi tentativi errati bastano a bloccare l’account.

1. Controlla lo stato dell’account locale:

net user NOMEUTENTE

Atteso: se l’account è bloccato, la voce Account active resta sì ma il login fallisce finché non lo sblocchi. Se l’account è disabilitato o scaduto, il problema non è il lockout.

Sblocco sicuro: procedura consigliata

La regola è semplice: prima sblocca, poi ferma la causa. Se fai il contrario e la causa è ancora attiva, il blocco torna in pochi secondi o minuti.

1. Accedi alla console del provider con un account che non sia bloccato. Se il provider offre una modalità rescue o seriale, usala per evitare di premere ancora sul canale RDP già compromesso.
2. Se l’account è locale, sbloccalo con PowerShell amministrativo:

Unlock-LocalUser -Name NOMEUTENTE

Se il cmdlet non è disponibile sulla tua versione di Windows, usa l’interfaccia grafica lusrmgr.msc, apri Users, fai doppio clic sull’utente e verifica eventuali opzioni di sblocco o stato account. In alternativa, se il blocco è legato a policy e non a un lockout persistente, puoi anche resettare la password dell’account locale dalla console del provider, ma solo se hai un piano di rollback e sai aggiornare subito tutte le credenziali salvate.

1. Se l’account è di dominio, sbloccalo sul domain controller o tramite strumenti AD. Da un host con RSAT disponibile:

Get-ADUser -Identity NOMEUTENTE -Properties LockedOut | Select-Object SamAccountName, LockedOut

Se risulta bloccato, lo sblocco va fatto sul dominio, non sulla VPS. Il comando operativo dipende dagli strumenti disponibili, ma il punto è verificare il flag LockedOut prima di cambiare altro.

1. Se il lockout è causato da un servizio o task, disattiva temporaneamente la sorgente del problema prima di riaprire l’accesso. Controlla services.msc, Task Scheduler e credenziali memorizzate in Credential Manager.
2. Riprova l’accesso RDP solo dopo aver confermato che la sorgente dei tentativi è stata fermata. Un solo test pulito basta: se fallisce ancora, torna ai log invece di insistere.

Se il problema è un servizio, un task o una password salvata

Molti lockout “misteriosi” non arrivano da un utente umano ma da un componente che tenta di autenticarsi in background. Il classico esempio è un servizio Windows configurato con una password vecchia, oppure un’attività pianificata che usa l’account amministrativo per copiare file, interrogare una share o lanciare uno script.

Per chiudere il cerchio, cerca i punti dove quella credenziale viene riutilizzata: services.msc, taskschd.msc, mapping di rete persistenti e salvataggi in Control Panel > Credential Manager. Se trovi un riferimento all’account bloccato, aggiorna la password e verifica il successivo evento 4624 o l’assenza di nuovi 4625.

Se il client RDP dell’operatore ha memorizzato la password sbagliata, elimina la sessione salvata e ricrea il profilo di connessione. In molti casi il lockout si ripete perché l’operatore continua a cliccare sullo stesso collegamento con credenziali stale.

Se il problema è brute force o esposizione pubblica

Se la VPS espone RDP direttamente su Internet, il blocco account può essere solo il sintomo. In quel caso sbloccare l’utente senza ridurre l’esposizione significa aspettarsi un nuovo lockout a breve. Qui la mitigazione minima è limitare l’accesso con firewall, allowlist IP o VPN, e verificare che la porta RDP non sia raggiungibile da chiunque.

Controlla anche se il provider offre un firewall a monte, perché spesso è il punto più rapido per tagliare i tentativi prima che arrivino a Windows. Dopo il blocco, cerca negli eventi 4625 se compaiono IP remoti ricorrenti; se sì, il problema non è la password in sé ma la superficie esposta.

Se devi lasciare RDP aperto temporaneamente, alza la soglia di visibilità, non quella di tolleranza: monitora i failed logon, imposta alert sui lockout e conserva i log almeno per il tempo necessario a correlare gli orari.

Controlli finali dopo lo sblocco

Quando l’accesso torna disponibile, la verifica non finisce con il primo login riuscito. Devi controllare che il blocco non si ripresenti e che la causa sia stata rimossa.

1. Esegui un solo accesso RDP con credenziali corrette e verifica l’apertura della sessione.
2. Ricontrolla i log con gli stessi filtri usati prima, per confermare che non partano nuovi 4625 o 4740 dopo lo sblocco.
3. Se hai toccato password o account, aggiorna subito tutti i riferimenti esterni: servizi, task, script, client RDP e credenziali salvate.
4. Se il lockout era di dominio, verifica con il team AD che il flag sia rientrato anche lato controller e che non ci siano repliche o ritardi di sincronizzazione.

Rollback: se lo sblocco o la modifica della password non risolve e il lockout torna, ripristina temporaneamente la configurazione precedente solo se hai già identificato la sorgente dei tentativi. Altrimenti rischi di riaprire l’accesso senza aver spento la causa.

Assunzione: l’accesso alla console del provider è disponibile e l’account bloccato non è l’unico amministrativo necessario per recuperare la VPS.

Come evitare che il blocco si ripeta

La prevenzione vera non è “aspettare che passi”: è ridurre i vettori che generano tentativi errati e rendere il lockout più leggibile. Se l’account è usato da persone e automazioni, separa i ruoli: un utente nominativo per l’accesso umano, un account dedicato per i servizi, credenziali diverse e policy chiare di rotazione.

Per una VPS esposta su Internet, sposta RDP dietro VPN o gateway, limita gli IP consentiti e lascia audit e log attivi. Se la macchina è in dominio, allinea la policy di lockout con il rischio reale: troppo aggressiva blocca gli utenti per errori banali, troppo permissiva lascia spazio a brute force.

Infine, documenta dove vengono salvate le credenziali. Il punto debole più frequente non è il server ma il client: profili RDP vecchi, task dimenticati, servizi configurati mesi prima e mai più rivisti.

Quando non basta lo sblocco

Se dopo lo sblocco il blocco ritorna in pochi minuti, non sei davanti a un “account da sbloccare”, ma a un flusso da interrompere. In quel caso la priorità diventa identificare la sorgente precisa nei log, isolare temporaneamente l’accesso e ripulire la configurazione che riusa la password sbagliata.

Se non hai log sufficienti per risalire alla sorgente, il gap non si risolve con altri tentativi di login. Va chiuso con auditing, firewall logging o con il supporto del provider, perché senza evidenza stai solo iterando sul sintomo.

La regola operativa è semplice: sblocca una volta, verifica subito la causa, poi metti in sicurezza il canale. Su una VPS RDP, il vero fix non è il click sul pulsante di unlock, ma il fatto che il blocco non debba più tornare.