Windows 10 Lots of ID 4648 in Event Viewer

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.

Non of them helped.

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.

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:
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.