Have you ever wondered why a failed sign-in can reveal more than a simple mistake? We open this guide with that question because failed logons often carry clues that matter for security and availability.
We define this record as the Windows security audit entry that is written when a user or service fails to authenticate on the computer that received the attempt. It appears on domain controllers, member servers, and workstations in the Security log.
In this introduction we highlight the key fields you will use during investigations: target account and name, failure status and substatus codes, logon type (interactive, network, RDP, service), process IDs, and network information such as workstation name and source IP.
Understanding these details helps teams triage password guessing, account enumeration, and service failures quickly. We position this guide as a practical reference to speed root-cause analysis and reduce unnecessary alerts.
Key Takeaways
- We log failed authentication on the computer that saw the attempt, not always centrally.
- Look first at account name, status codes, and logon type to scope the issue.
- Source port and IP help distinguish local versus remote attempts.
- Certain NTSTATUS codes point to lockouts, bad credentials, or unknown accounts.
- Baseline and alert on high-value accounts to prevent outages and noise.
Understanding Event 4625: Failed Logon Audits across Windows, Servers, and Domain Controllers
When a logon fails, Windows records the incident on the machine that processed the authentication request. This means the Security log on a workstation, member server, or domain controller holds the authoritative failure information.
Where it appears matters: a user’s PC records local sign-in rejects, while domain-level rejections appear on domain controllers. Knowing which computer produced the record speeds root-cause work.
Common logon types map to real scenarios. Type 2 is console (interactive). Type 3 is network access to a share. Type 5 denotes a service start. Type 10 is Remote Desktop. Less common types include 4 (scheduled tasks), 8 (cleartext), 9 (new credentials), and 11 (cached credentials).
Workstation name, Source Network Address, and Source Port help us tell local from remote attempts. Regular failures at the same time often point to scheduled tasks or misconfigured services rather than an attack.
- Plan monitoring across windows server hosts and workstations.
- Document expected logon types for key accounts and services.
- Correlate frequency, target account sensitivity, and source patterns before escalating a single record.
How to Read an Event 4625: Status/SubStatus, Logon Type, and Network Details
Status and SubStatus fields give immediate clues about why a sign-in attempt did not succeed. We start by mapping NTSTATUS codes to plain language so teams can spot common causes quickly.
Failure reasons and NTSTATUS mappings
Common codes: 0xC0000234 = account locked out; 0xC000006D = bad username or authentication information; 0xC0000064 = user does not exist.
Other useful values include 0xC000006A (bad password), 0xC0000072 (account disabled), 0xC000015B (logon right not granted), and 0xC000005E (no logon servers available).
Logon Type breakdown
Use the logon type to map the channel used for the attempt. Type 2 is Interactive (console). Type 3 is Network (share access). Type 5 is Service. Type 10 denotes RemoteInteractive (RDP). Type 11 is CachedInteractive.
Network information and workstation name
Workstation name and Source Network Address reveal origin. Localhost (127.0.0.1 or ::1) indicates a process on the same host, often a scheduled task or service.
Source Port behavior helps too: interactive attempts often show port 0, while network types use ephemeral ports.
Authentication details
Logon Process (for example, User32 or NtLmSsp) shows the credential path. Authentication Package (NTLM, Kerberos, Negotiate) tells which protocol was used. NTLM Key Length is typically 128; Kerberos or negotiated cases usually show 0.
| Status Code | Meaning | Recommended First Action |
|---|---|---|
| 0xC0000234 | Account locked out | Check lockout source and reset if legitimate |
| 0xC0000064 / 0xC000006D | User not found / bad credentials | Verify account name and password; check for enumeration |
| 0xC000005E | No logon servers available | Validate domain controller connectivity and Netlogon |
| 0xC0000070 | Unauthorized workstation | Review logon restrictions and endpoint assignment |
We recommend maintaining a quick-reference of the most relevant codes and expected authentication packages for high-value accounts. Correlate process IDs and process names with process creation logs to attribute attempts and speed remediation.
Troubleshooting event id 4625 microsoft-windows-security-auditing: Step-by-Step Fixes
A pattern of paired failed log entries from the same IP and changing source ports usually points to a local service or scheduled task. We begin on the endpoint and work outward, isolating processes before escalating to domain infrastructure.
Workstations: If you see repeated Logon Type 3 failures with Account Name “guest,” Status 0xC000006D and SubStatus 0xC0000064, check for background discovery or legacy software. Correlate the timestamps with Task Scheduler, services, and vendor updaters; stop suspected updaters during the window to isolate the trigger.
Servers and domain controllers
When failures concentrate on many accounts or return 0xC000005E, validate domain controller connectivity and Netlogon service health. For service account failures, verify stored credentials in services, IIS app pools, and scheduled tasks.
Computer account anomalies & process correlation
Investigate trust relationship warnings, stale machine accounts, or duplicate names in Active Directory. To attribute attempts, cross-reference authentication failures with process creation (4688), service state changes, and short-term Sysmon or netstat traces to map ephemeral ports to PIDs.
| Symptom | Likely Cause | First Action |
|---|---|---|
| Self IP, changing ports | Local service or agent | Inspect Task Scheduler and services |
| Many accounts, 0xC000005E | Domain controller unreachable | Check DC connectivity and Netlogon |
| Computer account failures | Password mismatch / duplicate AD object | Validate AD object and rejoin domain if needed |
- Start at the workstation: identify the process making NTLM calls (NtLmSsp/NTLM).
- Correlate with 4688 or collect Sysmon; use netstat/Get-NetTCPConnection to map ports to PIDs.
- If domain issues appear, validate machine account status in Active Directory and check trust relationships.
For ongoing patterns, document the timeframe and test by disabling candidates during the window. If you need community guidance on continuous failed logons, see this continuous failed logons thread.
Security Hardening and Monitoring for Event 4625
We focus monitoring where failed authentications carry the highest risk: privileged accounts, service principals, and local names on critical servers. Visibility into these targets lets us separate credential drift from probing attempts.
What to monitor: track failed records for admin and service account logons, local accounts on windows server hosts, and NTSTATUS values that indicate enumeration or policy blocks (for example 0xC0000064, 0xC000006A, 0xC000006D, 0xC000015B, 0xC000005E).
Reducing noise and risk
Disable the guest account, enforce strong passwords and lockout policies, and restrict where service accounts can authenticate from. Constrain by Workstation Name and Source Network Address so service credentials only come from approved hosts.
SIEM and use-case ideas
- Alert on NTLM-only authentication where Kerberos is expected; flag Key Length not equal to 128.
- Detect unexpected Logon Process values and correlate with process names to find nonstandard flows.
- Tune rules by NTSTATUS and account name to reduce false positives and prioritize high-value account logon failures.
| Monitor | Trigger | First Action |
|---|---|---|
| Privileged account | Repeated failures / unusual source address | Block source, validate password and MFA |
| Service account | Failures from unexpected computer | Check scheduled tasks, rotate credentials |
| Domain services | Status 0xC000005E or Netlogon errors | Verify domain controller health and time sync |
Conclusion
A failed authentication record packs concise clues—who tried, how they tried, and why the attempt stopped.
Event 4625 provides structured information about the account name, logon type, process context, NTSTATUS mappings, and the source computer or network. This lets teams pinpoint whether repeated failures are a misconfigured service, a scheduled task, or an external probe.
We recommend monitoring high-value accounts, enforcing least privilege, and baselining expected paths so SIEM rules surface real threats with less noise. Correlate process creation, scheduled activity, and directory checks to resolve recurring issues faster and harden systems over time.
FAQ
What does Event ID 4625 indicate on Windows servers and domain controllers?
It records a failed logon attempt on a Windows system. The entry shows which account name was used, the logon type (how the attempt was made), the workstation name, and network address when applicable. Administrators use this record to determine whether a failure was due to a bad credential, account restriction, or network/service issue.
Where is this record stored and how do we know which computer saw the failure?
The failed sign-in is written to the local Security log of the host that processed authentication. For domain account failures, the domain controller that evaluated the credential will contain the most relevant entry. Check the Computer field and the domain controller’s logs to locate the originating authentication decision.
When does a failed logon get logged and what are common logon types we should watch?
The failure is logged whenever an authentication attempt is denied. Common types include Interactive (console), Network (SMB/LDAP), Service (service account), RemoteInteractive (RDP), and CachedInteractive (cached credentials). Each type points to a different source and remediation path.
How do we interpret Status and SubStatus codes like 0xC000006D or 0xC0000234?
Status/SubStatus values map to NTSTATUS reasons. For example, 0xC000006D usually means bad credentials, 0xC0000064 indicates unknown user, and 0xC0000234 signals a locked account. Use vendor documentation or an NTSTATUS reference to convert codes into actionable causes.
How should we read the logon type field to prioritize investigation?
Match the logon type to expected behavior: Interactive failures on workstations suggest user issues; Network failures on servers suggest service or script problems; RemoteInteractive points to RDP; Service implies a service account. Prioritize high-risk types on critical systems and externally reachable hosts.
What network details in the record help identify the source of failed attempts?
The Network Information section lists the workstation name, source network address, and source port when available. An internal IP often indicates a scheduled task or device; an external IP suggests internet-originating attempts. Source ports can change, so correlate repeated attempts over time rather than a single port value.
How do Logon Process and Authentication Package fields inform troubleshooting?
Logon Process shows the component that initiated authentication (for example, RpcSs or NtLmSsp). Authentication Package identifies the protocol used — NTLM, Kerberos, or Negotiate. Key Length indicates encryption strength; low or zero values for NTLM may point to legacy systems or misconfiguration.
What steps do we take for repeated Network (Logon Type 3) failures from a workstation?
First, identify the source IP and process name if available. Look for scheduled tasks, mapped drives, services, or stored credentials on the workstation. Change detection on ports and timestamps helps rule out transient issues. Reset cached credentials and validate service account passwords where relevant.
How do we troubleshoot failures on servers and domain controllers tied to Active Directory?
Verify domain controller health and replication, check trust relationships, and confirm that time synchronization is accurate. Inspect account status in Active Directory for lockouts or password mismatches. Use domain controller logs to identify which DC rejected the authentication and why.
What causes computer account anomalies and how can we fix them?
Common causes include password mismatch for the machine account, duplicate computer names in Active Directory, or stale accounts after imaging. Fixes include resetting the machine account in AD, rejoining the domain, and ensuring unique hostnames and correct secure channel status.
How can we correlate failed attempts to a process or scheduled job?
Combine the failure record with related audit entries that list Process ID/Name, Task Scheduler events, or network session logs. Cross-reference timestamps and source addresses. Tracing the process path often reveals automated jobs, backup agents, or scripted tasks that present incorrect credentials.
Can you provide an example walkthrough for recurring NTLM failures that show the host itself as the source?
In that scenario, we isolate entries where source network address equals the server IP. Review Task Scheduler, services, and IIS application pools on that host for stored credentials. Inspect local scheduled tasks and service configuration, update credentials if rotated, and rerun authentication to confirm resolution.
What should we monitor to detect high-risk failed logons before they escalate?
Focus monitoring on high-privilege and service accounts, repeated NTSTATUS codes indicating lockouts or unknown accounts, unexpected authentication packages (NTLM on systems that should use Kerberos), and failures from external addresses. Alert thresholds should capture rapid repeated failures and cross-system patterns.
How do we reduce noise while keeping relevant alerts for failed sign-ins?
Disable legacy accounts such as Guest, enforce strong password policies, and restrict which accounts can authenticate over networks. Tune alerts to exclude known benign sources (with careful justification), and group similar failure codes to reduce duplicate notifications while preserving investigative detail.
What SIEM or use-case ideas help surface risky authentication behavior?
Implement alerts for NTLM-only authentications, unexpected Logon Process or Authentication Package changes, Key Length not equal to 128, and repeated failures for high-value accounts. Correlate failed attempts with successful logons and lateral movement indicators to detect compromise early.