The Windows RDP account locked out error means Windows has blocked the account after repeated failed sign-in attempts. This guide shows how to restore access, trace the source, and adjust the lockout policy on Windows Server 2016, 2019, 2022, and 2025 in about 10 minutes.
Prerequisites
- Windows Server 2016, 2019, 2022, or 2025 with Desktop Experience for the graphical steps. Server Core can be managed with PowerShell and a remote console.
- A second local administrator account, administrator access to the domain, or console access through the VPS control panel. If RDP is the only working path, open the VNC console from the VPSLake client area and then launch the VPS control panel (Virtualizor).
- The exact locked username and whether it is local (
SERVER_NAME\USERNAME) or domain-based (DOMAIN\USERNAME). - Five minutes of console access and enough disk space for normal Windows Security event logging; no special RAM or storage allocation is required.
- A VPSLake Windows RDP server if you need a Windows environment for this procedure.
Step 1: Identify the account and get a recovery session
Use an administrator session that is not the locked account so you do not keep generating failed attempts while trying to repair it.
At the Windows console, sign in with another administrator. If you are already connected over RDP as that administrator, open Windows PowerShell → Run as administrator and run:
whoami
hostname
The result should identify the working administrator and server:
SERVER_NAME\ADMIN_USERNAME
SERVER_NAME
If no account can sign in over RDP, open the VPSLake client area, enter the VPS control panel, and choose the server’s VNC Console. A console session bypasses the RDP logon screen and gives you a way to repair the account without changing the RDP service.
Step 2: Unlock a local Windows account
The Local Users and Groups console clears a local account’s lockout flag without changing its password or disabling the account.
Open Computer Management → Local Users and Groups → Users, double-click YOUR_USERNAME, and clear Account is locked out. Select Apply → OK. If that checkbox is not selected, the account may be disabled, expired, or locked by a domain policy instead.
You can check the local account’s basic state from the elevated PowerShell window:
Get-CimInstance Win32_UserAccount -Filter "Name='YOUR_USERNAME' AND LocalAccount=True" | Format-List Name,Domain,Disabled,Lockout
Expected output after the local unlock:
Name : YOUR_USERNAME
Domain : SERVER_NAME
Disabled : False
Lockout : False
If the Lockout value returns False but RDP still rejects the sign-in, continue to Step 3. A saved old password, a disabled account, or an incorrect local/domain username prefix can produce a similar failure.
Step 3: Unlock a domain account
Domain lockouts are controlled by Active Directory, so clearing a local server setting will not release a domain user.
On a domain controller or an administrator workstation with RSAT, open Server Manager → Tools → Active Directory Users and Computers. Browse to the user’s organizational unit, right-click YOUR_USERNAME, choose Properties → Account, clear Unlock account, and select Apply → OK.
If the ActiveDirectory PowerShell module is installed, the same action is:
Import-Module ActiveDirectory
Unlock-ADAccount -Identity "YOUR_USERNAME"
Get-ADUser -Identity "YOUR_USERNAME" -Properties LockedOut | Select-Object SamAccountName,LockedOut
Successful verification resembles:
SamAccountName LockedOut
-------------- ---------
YOUR_USERNAME False
Use Microsoft’s Unlock-ADAccount reference if the command is unavailable. You need permission to unlock the account, and the domain controller must be reachable.
Step 4: Find what caused the lockout
Unlocking the account is temporary if a phone, service, scheduled task, mapped drive, or saved RDP credential is still sending an old password.
Open Event Viewer → Windows Logs → Security, choose Filter Current Log, and filter for event IDs 4740 and 4625. Event 4740 records the locked account and, where available, the caller computer name; event 4625 shows failed logons. You can query recent events from an elevated PowerShell prompt:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4740} -MaxEvents 10 | Select-Object TimeCreated,Id,Message
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 10 | Select-Object TimeCreated,Id,Message
For a domain account, run the 4740 query on the domain controller handling the lockout. Look for Caller Computer Name, then inspect that computer for Control Panel → Credential Manager → Windows Credentials, saved RDP entries, mapped drives, services, and scheduled tasks using the affected username. Microsoft’s Event 4740 documentation explains the fields.
If the caller is unknown or the events show repeated attempts from an unexpected host, change the password after unlocking the account, remove stale credentials, and restrict RDP to trusted source addresses or a VPN. Do not repeatedly unlock an account while an active password-guessing attempt continues.
Step 5: Adjust the account lockout policy
Change the policy only after fixing the source; a higher threshold can hide a broken service or make password attacks harder to notice.
For a standalone server, open Local Security Policy → Account Policies → Account Lockout Policy. For a domain, edit the effective domain GPO through Group Policy Management → Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Account Lockout Policy.
Set these values according to your security policy:
- Account lockout threshold: Use a nonzero value such as
10to preserve brute-force protection. Set it to0only when you intentionally want to disable lockouts and have compensating controls such as IP-restricted RDP, a VPN, and strong unique passwords. - Account lockout duration:
15minutes is a practical starting point for temporary lockouts. - Reset account lockout counter after:
15minutes, or another value no greater than the lockout duration.
Select Apply → OK, then refresh policy from an elevated prompt if this is a domain-managed server:
gpupdate /force
Expected output includes successful computer policy processing:
Computer Policy update has completed successfully.
These settings are documented in Microsoft’s Account Lockout Policy guidance. Domain policy or fine-grained password policy can override a local setting, so verify the effective policy on the domain controller.
Verify the RDP sign-in
Verification must use a fresh authentication attempt and the correct account scope, not just an unlock confirmation.
- Keep the console or administrator session open.
- Remove the old saved credential on the connecting computer under Control Panel → Credential Manager → Windows Credentials.
- Start a new RDP connection to
SERVER_IPand enterSERVER_NAME\YOUR_USERNAMEfor a local user orDOMAIN\YOUR_USERNAMEfor a domain user. - After signing in, confirm that the RDP listener is reachable from the client:
Test-NetConnection -ComputerName SERVER_IP -Port 3389
The important result is:
TcpTestSucceeded : True
If the connection succeeds and no new 4625 or 4740 event appears, the lockout is fixed. Keep the recovery console available until you have confirmed that services and scheduled tasks also use the current credential.
Troubleshooting
“The referenced account is currently locked out” after unlocking
Another device or process is still submitting the old password, or a domain controller has not replicated the unlock yet. Check event 4740 again, stop the offending service or scheduled task, update its stored credential, and retry after the domain controllers show the same account state.
The Account is locked out checkbox is missing
You may be viewing a domain account, using an account without administrator rights, or running an edition without the Local Users and Groups console. Use Active Directory Users and Computers for a domain user, or open the VPS control panel’s VNC console with another local administrator.
Unlock-ADAccount is not recognized
The ActiveDirectory module or RSAT tools are not installed, or the command is being run on a standalone server. Use Server Manager → Tools → Active Directory Users and Computers on an RSAT-enabled administrator workstation, or repair the local account through Computer Management → Local Users and Groups.
The account locks again immediately
Treat this as a source problem, not a policy problem. Inspect event 4740, saved credentials, Windows services, scheduled tasks, mapped drives, email clients, and RDP clients; if the caller is unfamiliar, change the password and restrict the RDP firewall rule to trusted IP addresses.
Hardening
- Keep the lockout threshold nonzero unless you have a documented reason to disable it; threshold
0removes a useful brute-force signal. - Use a separate named administrator for routine work and a long, unique password for every Windows server.
- Restrict inbound RDP in Windows Defender Firewall to trusted source IP addresses or a VPN, and avoid exposing it to the entire internet when possible.
- Review Security log retention and alert on repeated 4625 and 4740 events so a future lockout has an identifiable source.
FAQ
Does restarting Windows unlock an RDP account?
No. Restarting does not reliably clear a local or domain account lockout, and it will not stop another device from sending an outdated password. Unlock the account through the appropriate local or domain administrator tool and fix the process causing the failures.
How long does a Windows RDP account stay locked?
It depends on Account lockout duration. A nonzero duration unlocks the account automatically after that period; a duration of 0 keeps it locked until an administrator clears it. Domain policy can differ from the local server policy.
Can I disable account lockout completely?
Yes, setting Account lockout threshold to 0 disables lockouts for that policy scope. It also removes protection against repeated password guessing and lets an attacker create fewer lockout alerts, so use IP restrictions, a VPN, strong passwords, and monitoring before choosing this setting.
Why does the account lock again after I change the password?
A service, scheduled task, mapped drive, mobile device, or saved RDP credential may still contain the old password. Find the caller in event 4740 or nearby 4625 events, update or remove that credential, and then unlock the account again.