Windows 10 Lots of ID 4648 in Event Viewer

[hack3rcon]

Hello,
I have a computer that is not a member of a Windows domain and I access a folder on the file server through a shortcut and username defined in Active Directory. When I check the Event Viewer, there are a lot of ID 4648 and the username is locked in Active Directory:

I unlock the username, but it gets locked again. I also checked the logs for runas.exe, but found nothing.

How do I find the problem?

Thank you.

 

[ChatGPT]

This is a classic case of an account lockout loop, typically triggered by multiple failed authentication attempts using a domain account. Event ID 4648 (“A logon was attempted using explicit credentials”) and repeated lockouts point toward something—usually a workstation, service, or cached credential—trying (and failing) to authenticate with the domain using the locked account.
Let’s break down the steps to identify and resolve the problem:

1. Understand the Source of Lockouts​

Since your computer is not domain-joined but uses a shortcut to access a file server with domain credentials, several things could be causing repeated bad logons:

• Cached credentials (Windows Credential Manager).
• Mapped network drives using outdated credentials.
• Applications/services attempting to use old credentials.
• Other machines or devices using this user’s credentials.

2. Investigate Event Viewer in Detail​

Although you checked for runas.exe, the culprit could be elsewhere. You want to focus on:

• Security logs on the domain controller (where lockout occurs).
• Security logs on the file server that hosts the share.
• Security logs on the client PC (the non-domain member).

Look especially at:

• Event ID 4625 (failed logon attempts).
• Event ID 4648 (explicit credential usage).

These events usually detail the source IP or computer, logon type, and the exact process if available.

3. Find the Source Machine​

On the domain controller, the event logs should show the source workstation or IP address responsible for the bad attempts. In the Event ID 4625/4648 entries, look for:

• Workstation Name
• Source Network Address
• Process Information (sometimes it will include the program trying to authenticate)

If you see the non-domain computer’s name or IP, it’s your source. If it’s another name/IP, that’s your real problem device.

4. Check Credential Manager and Mapped Drives​

On the non-domain PC:

• Open Control Panel → Credential Manager
  • Look for Windows Credentials relating to the file server. Remove any old or incorrect entries for the affected username.
• Open 'This PC' and review mapped drives. If any are set to reconnect at logon using the affected credentials, disconnect them.

5. Check for Saved Credentials In Apps/Services​

• Any scheduled tasks or background services using these credentials on this or other machines?
• Any applications (e.g., backup programs, automation scripts) configured with old domain credentials?

6. Reset the Password and Clear Locks​

• Reset the password for the affected AD account.
• Unlock the account.
• Re-enter the new credentials anywhere needed: mapped drives, Credential Manager, applications, services.

7. Monitor for Recurrence​

After these steps:

• Check domain controller event logs to make sure the lockouts stop.
• If they persist, investigate the source computer named in the event details.

Bonus: Microsoft Lockout Tools​

Microsoft provides the "Account Lockout and Management Tools," including LockoutStatus.exe and Netwrix Account Lockout Examiner, which can help track the source of account lockouts across your network.

---

Summary Checklist​

1. Find the source of bad logons in Event Viewer using Event ID 4625/4648 on the domain controller.
2. Remove outdated credentials from Credential Manager and mapped drives on the suspected machines.
3. Reset the password and carefully update all places the account is used.
4. Use lockout tools if the source remains elusive.

If you want step-by-step instructions for any of these actions, let me know! If you can share specific event details (timestamp, source computer/IP), I can help you interpret them.

 

[hack3rcon]

Non of them helped.

 

[ChatGPT]

Thanks for following up. Since the standard checks haven’t solved the issue, let’s dig deeper and approach this methodically:

Next Steps​

1. Share Event Log Details​

Can you please provide the full event details for one of the Event ID 4648 entries triggering the account lockout? The details pane of the event typically contains:

• Caller Computer Name or IP
• Process Name
• Logon Type
• Other useful fields: SubjectUserName, TargetUserName, Network Address, etc.

This information pinpointing the actual source of the bad logon attempts is crucial. If possible, copy the XML or General tab contents of the relevant event here. Alternatively, you can export the logs (filtered for this account and relevant Event IDs) and attach the file for analysis.

2. Check All Client Devices​

Are you certain only this one non-domain-joined PC uses the affected credentials? Sometimes an old laptop, VM, or mobile device keeps trying with cached credentials. Consider:

• Any old or secondary devices?
• Any remote access software or network shares elsewhere using these credentials?
• Any script or scheduled task running periodically?

3. Audit AD Account Properties​

Sometimes, user account lockouts are caused by services or tasks running as that user. On the domain controller:

• Check "Sessions", "Member Of", and "Logon Hours" for clues.
• Open the Event Viewer on the DC and filter Security logs for just the affected user.

4. Temporarily Change the Username​

If practical, temporarily rename the Active Directory username. If the lockout stops, this confirms a cached process/device is still trying (with the old username), bolstering the search for the rogue device/service.

5. Advanced Lockout Investigation​

If you can, use Microsoft’s Account Lockout Tools (LockoutStatus.exe) or Netwrix Account Lockout Examiner on your DC to find which host or process is causing the lockout.

---

If you upload the relevant Event Log extracts or more details, I’ll analyze them directly for you.​

Let me know how you’d like to proceed! If you have event logs or other files to share, please upload them and I’ll examine them right away.

 

[datawizard0103]

If an AD user account keeps getting locked and you're using a non-domain computer to access a shared folder, the issue is likely caused by repeated failed login attempts using saved credentials. To find the source, check the domain controller’s Event Viewer under Security logs for Event ID 4740. This will show the "Caller Computer Name" — the system causing the lockout. Go to that computer, open Credential Manager in Control Panel, and remove any saved credentials for the file server or domain account.

Check for mapped drives, scheduled tasks, or services that may be using the same credentials. If you're using a shortcut to access the share, right-click it and check if it contains login information. Delete or recreate it if needed. Reset the AD account password and restart the computer to clear cached credentials. You can also run net use * /delete in Command Prompt to remove stored network sessions. To monitor lockouts, use Microsoft’s LockoutStatus tool. This should stop the account from being locked repeatedly.

 

[ChatGPT]

Excellent, you’ve provided a step-by-step guide for tracking down and resolving persistent Active Directory account lockouts related to repeated failed login attempts, especially from non-domain computers. Your method is spot-on and covers the usual suspects:

• Checking for Event ID 4740 in the domain controller’s Security logs.
• Investigating the “Caller Computer Name” to find the lockout source.
• Clearing out old credentials via the Credential Manager.
• Inspecting mapped drives, scheduled tasks, or services using that account.
• Deleting or recreating problematic shortcuts.
• Resetting the problematic AD account password and restarting.
• Using net use * /delete to purge current network sessions.
• Monitoring lockouts with Microsoft’s LockoutStatus tool.

A couple of extra tips to reinforce your process:

• If the lockout persists after clearing credentials and scheduled tasks, check for third-party applications on the client (such as backup software or syncing tools) that might be holding onto old credentials.
• Be aware that some legacy apps or background services might run under user context without obvious appearance in Task Scheduler.

For reference, here’s Microsoft’s comprehensive troubleshooting guide:

http://[url="https://learn.microsof...ver/identity/troubleshoot-locked-out-accounts

Bottom line: Your approach is comprehensive and effective for this scenario. If you’re troubleshooting this for yourself or others, you’re on the right track! If you need help interpreting a particular Event Viewer entry or log, feel free to share details.