Event ID 4625: Decode a Failed Windows Logon, Free in Your Browser

Read three fields first: Logon Type, Status with Sub Status, and the Source Network Address with Workstation Name. The rest of the event adds context to them.

The logon type tells you how they tried

These values are from Microsoft’s 4625 and 4624 pages. The right column is our reading of what to ask when that type appears in a failure.

On a successful 4624, Microsoft’s page also lists type 0 (System, used only by the System account), 12 (cached remote interactive) and 13 (a cached workstation logon).

Status and Sub Status give the reason

A Status of 0xC000006D means only “bad user name or authentication information”.

The Sub Status holds the specific reason, so read it first. The codes below come from the monitoring table on the 4625 page; the decoder also knows a few more from the NTSTATUS list.

A mistyped password or guessing?

No single event proves intent, so read the pattern. The table below is our judgment, not a Microsoft rule.

Microsoft’s guidance is to watch for a run of 0xC000006A events, especially on critical or service accounts, and to treat several 0xC0000064 events in a row as a possible sign of user enumeration.

Lockout

Once an account is locked, further attempts fail with Status 0xC0000234.

• Event 4740. It records the lockout itself (read 2026-10-08).
• Caller Computer Name. The computer the logon attempt came from. That field is the shortest path to the saved credential or task that keeps failing.
• Where it is logged. Microsoft’s page lists domain controllers, member servers and workstations as places where user-account lockouts are logged.

Worked example. Load “Failed logon (4625)”. The server ERP01 reports logon type 3, authentication package NTLM, Status 0xC000006D and Sub Status 0xC000006A, from workstation WS-FIN-014 at 192.0.2.41.

Maria Lopez’s user name is correct, and the password sent over the network from her own finance workstation is wrong.

One event like this is almost always a typo or a stale connection. Count how many arrive, and from where, before you escalate.

A domain controller writes a 4768 each time it issues a ticket-granting ticket, and a non-zero Result Code marks a failure.

A wrong password does not appear here: Microsoft notes that result codes 0x10 and 0x18 are logged as 4771 instead.

The sample below is a successful request for Maria; paste it into the decoder to try it. It is fictional, in the field layout of Microsoft’s page.

A Kerberos authentication ticket (TGT) was requested.

Account Information:
  Account Name: maria.lopez
  Supplied Realm Name: ACME.EXAMPLE

Service Information:
  Service Name: krbtgt

Network Information:
  Client Address: ::ffff:192.0.2.41
  Client Port: 49254

Additional Information:
  Ticket Options: 0x40810010
  Result Code: 0x0
  Ticket Encryption Type: 0x12
  Pre-Authentication Type: 2

Reading it: pre-authentication type 2 is normal password pre-authentication (PA-ENC-TIMESTAMP), encryption type 0x12 is AES256, and ticket options 0x40810010 mean Forwardable, Renewable, Canonicalize and Renewable-ok.

Failures worth knowing in a 4768 (descriptions from Microsoft’s table, names based on RFC 4120):

Encryption types are the same in 4768 and 4771:

• 0x11 and 0x12 are AES128 and AES256.
• 0x17 is RC4-HMAC.
• 0x1 and 0x3 are DES, disabled by default since Windows 7 and Windows Server 2008 R2.
• 0xFFFFFFFF appears in failure events.

Microsoft’s page says to expect AES (0x11 and 0x12) on current systems. Trace any RC4 or DES to whatever still requests it.

After the January 14, 2025 cumulative update, Windows Server 2016 and later also show extra fields: the supported encryption types and available keys for the account, the service and the domain controller.

SSOGEN’s audit log is a separate record of SSOGEN’s own sign-ins: every sign-in, refusal, policy change and administrator action, kept as a tamper-evident chain.

The two records are independent. Windows events stay in the Windows Security log, and SSOGEN’s decisions stay in SSOGEN’s audit log.

The two meet at Windows desktop sign-in. A domain-joined computer proves who the person is with a Kerberos ticket, and SSOGEN signs them in with no password.

When that sign-in fails, the page does not show the exact reason. SSOGEN records it in the audit trail as a Windows sign-in refusal, and the guide lists the common causes:

• the browser sent NTLM instead of Kerberos;
• an out-of-date keytab;
• a clock more than five minutes out;
• a name registered on two accounts.

These are the same kinds of problem the codes above describe (0x25 for clocks, 0x8 for duplicate names), so you can read a domain controller event and an SSOGEN refusal together.

The Kerberos authentication page explains what users see, and Kerberos SSO for web applications covers how the browser and the gateway use tickets.