SSOGEN / Free tools / Event ID 4624: Decode a Successful Windows Logon, Free in Your Browser
Free tool
Event ID 4624: Decode a Successful Windows Logon, Free in Your Browser
Event ID 4624 is logged each time Windows creates a logon session on a computer. Paste the event into this free decoder to read the logon type, authentication package, NTLM version and key length, with nothing uploaded.
Paste an event and read it
Paste the text from Event Viewer, or the XML from its Details tab. To see the output first, press Successful network logon (4624) to load an Acme sample.
From Event Viewer: open the event, then copy the General text, or the XML from the Details tab (XML View). Events 4624, 4625, 4634, 4647, 4648, 4672, 4740, 4768, 4769, 4771 and 4776 are recognized.
Private by design. Decoding happens in this page and nothing is sent anywhere. Event text holds account names, host names and IP addresses: use a copy you are allowed to look at, and remove anything you must not share.
Free, in your browser. No sign-up and no limit. The page makes no network request when you decode, so the event never leaves your computer.
Event text still contains account names and addresses, so use a copy you are allowed to read.
What event 4624 is
Event ID 4624 is the Windows Security log entry for “an account was successfully logged on”. Microsoft’s page says Windows writes it when a logon session is created, on the computer that was accessed.
Five fields carry most of the meaning:
- The logon type: how the user or program logged on.
- The authentication package: Kerberos, NTLM or Negotiate.
- The Logon ID: the handle that joins this event to others.
- The source address.
- The process that requested the logon.
This free decoder reads a pasted event and explains each field.
What 4624 records, and where it is logged
Microsoft files 4624 under the Audit Logon subcategory. That page says these events cover the creation of logon sessions and occur on the computer that was accessed:
- For an interactive logon, the event is written on the machine the user sat at.
- For a network logon, such as opening a file share, it is written on the machine that hosts the share (Microsoft Learn, Audit Logon, read 2026-10-11).
As a result, a user’s laptop records nothing about the servers they used.
To see which servers a user signed in to, you need each server’s Security log, or a collector that gathers them. The same page lists the other events in the subcategory:
| Event | What it records | Related page |
|---|---|---|
| 4624 | An account was successfully logged on | This page |
| 4625 | An account failed to log on | Event ID 4625 |
| 4648 | A logon was attempted using explicit credentials | Event ID 4648 |
| 4675 | SIDs were filtered | Not covered here |
Microsoft’s audit page rates event volume as low on a client computer and medium on a domain controller or network server.
Medium is still high in practice: a file server can write one 4624 for every connection. When you search for one user’s activity, filter before you read.
The fields, in the order they appear
Microsoft’s page describes three versions of the event:
- Version 0 shipped with Windows Server 2008 and Vista.
- Version 1 (Windows Server 2012 and Windows 8) added Impersonation Level.
- Version 2 (Windows 10) added a Logon Information section, which now holds the logon type, plus Restricted Admin Mode, Virtual Account, Elevated Token, Linked Logon ID and the Network Account name and domain.
If a field from the list below is missing, the event is probably an older version.
Subject and New Logon: who asked, and who got in
These two blocks are the most commonly misread part of the event.
Subject is the account that reported or requested the logon. On a typical server it is the machine account (a name ending in $) or SYSTEM, because the computer’s own logon service requests the logon on behalf of the user.
New Logon is the account the session was created for, which is usually the account you are investigating. Microsoft’s monitoring notes use “New Logon\Security ID” for almost every account-based check, so read that block first.
Account Domain comes in several formats: the NetBIOS name (CONTOSO), the lowercase domain name or the uppercase domain name. For local accounts it is the computer name. Do not match on one spelling only.
Logon type
The logon type is the field most readers open the event for. Microsoft’s page lists these values:
| Type | Title | Microsoft’s description |
|---|---|---|
| 0 | System | Used only by the System account, for example at system startup |
| 2 | Interactive | A user logged on to this computer |
| 3 | Network | A user or computer logged on to this computer from the network |
| 4 | Batch | Used by batch servers, where processes run on behalf of a user without their direct intervention |
| 5 | Service | The Service Control Manager started a service |
| 7 | Back from lock screen | The workstation was opened again after a lock |
| 8 | NetworkCleartext | Network logon where the password was passed to the authentication package unhashed; Microsoft notes the built-in packages hash credentials before sending, so they do not cross the network in plaintext |
| 9 | NewCredentials | A caller cloned its current token and specified new credentials for outbound connections |
| 10 | RemoteInteractive | Logged on remotely using Terminal Services or Remote Desktop |
| 11 | CachedInteractive | Logged on with network credentials stored locally; the domain controller was not contacted |
| 12 | CachedRemoteInteractive | Same as RemoteInteractive; used for internal auditing |
| 13 | Back from lock screen, cached | Workstation logon |
Three pairs are commonly confused.
Type 3 against type 10. Type 3 is the common one: a connection from the network, such as a file share, a service call or a remote command.
Type 10 is a Remote Desktop or Terminal Services session that provides a desktop.
- A type 10 means a user (or tool) opened a remote session.
- A type 3 can be a user, but it is more often a program.
Microsoft’s page does not say which is riskier, so do not treat the number as a verdict.
Type 9. NewCredentials behaves differently from the others. In Microsoft’s words, the new logon session has the same local identity but uses different credentials for other network connections.
- Locally. It acts as the caller.
- On the network. It presents other credentials.
- Network Account fields. “Network Account Name” and “Network Account Domain” are valid only for this type and hold the outbound identity. For any other type they contain a dash.
Type 11 against type 2. Both are a user at the keyboard.
- Type 11. Windows checked the password against a local copy and never contacted the domain controller.
- Result. That sign-in has no matching request at the domain controller. A missing 4768 next to it is expected, not a gap in your logs.
Authentication package and package name
Microsoft names the common packages: NTLM (NTLM-family authentication), Kerberos, and Negotiate, which selects between Kerberos and NTLM. Negotiate selects Kerberos unless one of the systems involved cannot use it or the calling application did not provide enough information.
A Negotiate logon may be Kerberos or NTLM underneath. The Key Length and Package Name fields show which.
When the package is NTLM, Package Name (NTLM only) shows the sub-package: “NTLM V1”, “NTLM V2” or “LM”.
Microsoft’s monitoring recommendations suggest alerting on anything other than NTLM V2, if your organization uses a single version. The decoder flags V1 and LM and treats V2 as expected.
Key length
Key Length is the length of the NTLM session security key. Microsoft says it is typically 128 or 56 bits.
Its monitoring note says that if the package is NTLM, watch for a key length that is not 128, “because all Windows operating systems starting with Windows 2000 support 128-bit Key Length”.
A 56 on a current system means one side negotiated a weaker key than necessary. Identify the client that did it.
Logon process, process name and the network block
Logon Process. The trusted process used for the logon. Microsoft suggests keeping a list of trusted processes and monitoring for any other.
Process Name. The full path of the program that requested the logon. Microsoft suggests monitoring it to catch software that is not authorized to request logons.
Process ID. It is hexadecimal, so convert it to decimal before you compare it with Task Manager.
Source Network Address. The client’s IPv6 or IPv4 address; ::1 or 127.0.0.1 means localhost.
Source Port. It is 0 for interactive logons.
Workstation Name. The machine the attempt came from.
Elevated token, restricted admin mode and impersonation
Elevated Token. A Yes/No flag. Yes means the session is elevated and has administrator privileges. To track every logon that carries administrator rights, Microsoft suggests monitoring this event with Elevated Token “Yes”.
Restricted Admin Mode. Filled in only for RemoteInteractive (type 10). It shows whether the credentials were passed using Restricted Admin mode.
Microsoft notes the mode arrived in Windows 8.1 and Server 2012 R2, but the event field arrived only in Windows 10. If you require the mode for certain accounts, alert on a type 10 logon where it says “No”.
Impersonation Level. Four values on Microsoft’s page: Anonymous (shown as an empty string), Identification, Impersonation (the most common) and Delegation.
Delegation means the server process can act as the client on remote systems, so review it closely.
What joins a 4624 to other events
One logon event records one moment. These three identifiers let you follow the session.
| Identifier | Joins 4624 to | Source |
|---|---|---|
| Logon ID (New Logon) | 4672 (special privileges assigned) and 4634 (logged off) | Microsoft’s 4624, 4672 and 4634 pages |
| Logon GUID | 4769 (Kerberos service ticket) on the domain controller; 4648 and 4964 on the same computer | Microsoft’s 4624 page |
| Process ID | 4688 (a new process was created) | Microsoft’s 4624 page |
Three details are easy to miss.
The same Logon ID joins three events.
- A session starts with a 4624.
- If the account holds sensitive privileges, Windows writes a 4672 with the same Logon ID.
- When the session ends, a 4634 carries the same Logon ID.
Microsoft’s page for 4634 says it may be positively correlated with a 4624 using the Logon ID, and adds that Logon IDs are only unique between reboots on the same computer.
Join on Logon ID plus the computer name and a time window, never on the ID alone.
The Logon GUID joins across machines. The 4624 on the server and the 4769 on the domain controller share a Logon GUID, which ties a server logon to the Kerberos ticket behind it.
Microsoft warns the value might not be captured, in which case it shows all zeros. A zero GUID is not an error.
Not every field is filled in. Microsoft states that the IP address, port and workstation name depend on the authentication context and protocol, and that LSASS audits only what the authenticating service shares with it.
Its example: network logons with Kerberos likely have no workstation information, and NTLM logons have no TCP/IP details.
A blank workstation name does not make a logon suspicious; check the package first.
A worked example
Load the Successful network logon (4624) sample. It is a fictitious Acme event in the field layout of Microsoft’s page.
On the server ERP01, the account maria.lopez signed in with logon type 3, from the workstation WS-FIN-014 at 192.0.2.41, using the Kerberos package. Read it in this order:
- Logon type 3. A network logon: Maria was not at ERP01 and connected to it from another machine.
- Kerberos. The domain controller issued her a ticket for this server. Key length for Kerberos is always 0, because it does not apply to Kerberos, Microsoft says. Nothing to flag.
- Subject: ERP01$. The machine account reported the logon, which is normal for this event.
- Source address. Check whether 192.0.2.41 is in the subnet Maria’s laptop normally uses. The sample has an address, but on a real Kerberos network logon those fields might be blank, as described above.
Three variations would change the reading:
- If the package were NTLM with Package Name NTLM V1, the question is which client still uses the old protocol.
- If the logon type were 10, the question is whether Maria is supposed to open Remote Desktop sessions on ERP01.
- If the Subject were not SYSTEM or a machine account, Microsoft suggests you report it, since SYSTEM typically triggers this event.
Why not every 4624 deserves a look
On a busy server most 4624 events are services and scheduled tasks. Microsoft’s own monitoring page does not ask you to read them all; it asks you to choose questions, then filter. Its recommendations include:
- High-value accounts. Watch every logon by the database administrators, built-in local administrator, domain administrators, service accounts and domain controller accounts, using the New Logon Security ID.
- Accounts that should never be used. Alert on any 4624 for disabled, guest or retired accounts. A success means someone still has a working credential.
- Allowlists. If only a set of accounts may do something, review New Logon Security IDs outside the set.
- Account and logon type mismatch. Microsoft’s example: logon type 4 (batch) or 5 (service) used by a member of a domain administrative group.
- Source restrictions. A service account that should only come from internal addresses; an account that should not log on from a specific workstation.
- NTLM use. If NTLM should not be used at all, alert on any 4624 with Authentication Package NTLM. If it should be used, alert on Package Name other than NTLM V2, and on Key Length other than 128.
- Managed service accounts. Events with Virtual Account “Yes”.
One pitfall is not on Microsoft’s page, but it follows from two statements that are:
- Microsoft says to monitor for Key Length not equal to 128 when the package is NTLM.
- It also says Key Length is 0 for Kerberos, and 0 when Kerberos was negotiated through Negotiate.
A rule that says only “Key Length is not 128” fires on every Kerberos logon on your network. Filter on Authentication Package = NTLM first. The decoder applies that condition for you.
Where to find the event
- Open Event Viewer, then Windows Logs, then Security, on the computer that was logged on to. Reading this log requires an administrator account.
- Filter the current log by event ID 4624, or search for the account name.
- Open the event and copy the text from the General tab, or the XML from the Details tab, then paste it above.
Auditing must be switched on for this subcategory. The Audit Logon page expects success and failure auditing on domain controllers, member servers and workstations alike.
Microsoft’s Sentinel documentation shows the weight Microsoft gives this event: 4624 and 4625 are in the Minimal set it collects, while 4634, which is high volume, is only in the Common set (read 2026-10-11).
Where this meets SSO
A Windows logon is where single sign-on appears in your logs. When a user opens a shared drive without typing a password, the 4624 on the file server is the record, and the package usually shows Kerberos.
The 4768 and 4769 events on the domain controller show how the ticket was issued. See event ID 4768 and event ID 4769 for those, and event ID 4672 for the privileges the session received.
SSOGEN uses a related flow for the web:
- A user already signed in to a managed Windows computer opens SSOGEN or a protected application.
- The browser presents a Kerberos ticket.
- SSOGEN validates it against your Active Directory.
This happens in the browser and at SSOGEN, so it creates no Windows logon on your file servers.
Details are in the Windows desktop sign-in guide, the Kerberos authentication page, and the SSO audit log page, which describes SSOGEN’s own record, separate from your Windows Security log.
For the failure side of this event, see event ID 4625.
Questions people ask
What is Windows event ID?
What does Event ID 4729 mean?
What does Event ID 4722 mean?
What does Event ID 4668 mean?
What is the difference between event 4624 and 4625?
What does logon type 3 mean in event 4624?
Which event joins to 4624 for a logoff?
Where to go next
- Browse the other free tools.
- Read what Kerberos is.
- Open the event ID 4625 decoder for the failed-logon side.
Sources, all read 2026-10-11: Microsoft Learn pages for events 4624, 4625, 4634, 4672 and 4722, the Audit Logon page, the Appendix L events to monitor, the event 4728 and 4729 article and the Microsoft Sentinel event sets.
Microsoft and Windows are trademarks of their owner; SSOGEN is not affiliated with Microsoft.