Enable Logon Auditing

First, open the local group policy editor – press the Windows key, type gpedit.msc in the Start menu, and press Enter. (You can also enable logon event auditing on a domain controller if you administer a network with centralized logins.)

Navigate to the following folder: Local Computer Policy –> Computer Configuration –> Windows Settings –> Security Settings –> Local Policies –> Audit Policy.

Double-click the Audit logon events policy setting in the right pane to adjust its options. In the properties window, enable the Success checkbox to log successful logons. You can also enable the Failure checkbox to log failed logins.

Viewing Logon Events

Open Event Viewer.

Look for events with event ID 4624 – these represent successful login events.

4625 Represent the unsuccessful login events.

Description Fields in 4625 (status 0xC000006D)
Subject:

Identifies the account that requested the logon – NOT the user who just attempted logged on. Subject is usually Null or one of the Service principals and not usually useful information. See New Logon for who just logged on to the system.

  • Security ID
  • Account Name
  • Account Domain
  • Logon ID
Logon Type:

This is a valuable piece of information as it tells you HOW the user just logged on:  See 4624 for a table of logon type codes.

Account For Which Logon Failed:

This identifies the user that attempted to logon and failed.

  • Security ID:  The SID of the account that attempted to logon. This blank or NULL SID if a valid account was not identified – such as where the username specified does not correspond to a valid account logon name.
  • Account Name: The account logon name specified in the logon attempt.
  • Account Domain: The domain or – in the case of local accounts – computer name.
Failure Information:

The section explains why the logon failed.

  • Failure Reason: textual explanation of logon failure.
  • Status and Sub Status: Hexadecimal codes explaining the logon failure reason. Sometimes Sub Status is filled in and sometimes not. Below are the codes we have observed.
Status and Sub Status Codes Description (not checked against “Failure Reason:”) 
0xC0000064 user name does not exist
0xC000006A user name is correct but the password is wrong
0xC0000234 user is currently locked out
0xC0000072 account is currently disabled
0xC000006F user tried to logon outside his day of week or time of day restrictions
0xC0000070 workstation restriction, or Authentication Policy Silo violation (look for event ID 4820 on domain controller)
0xC0000193 account expiration
0xC0000071 expired password
0xC0000133 clocks between DC and other computer too far out of sync
0xC0000224 user is required to change password at next logon
0xC0000225 evidently a bug in Windows and not a risk
0xc000015b The user has not been granted the requested logon type (aka logon right) at this machine
Process Information:
  • Caller Process ID: The process ID specified when the executable started as logged in 4688.
  • Caller Process Name: Identifies the program executable that processed the logon. This is one of the trusted logon processes identified by 4611.
Network Information:

This section identifies where the user was when he logged on. Of course if logon is initiated from the same computer this information will either be blank or reflect the same local computers.

  • Workstation Name: The computer name of the computer where the user is physically present in most cases unless this logon was initiated by a server application acting on behalf of the user. Workstation may also not be filled in for some Kerberos logons since the Kerberos protocol doesn’t really care about the computer account in the case of user logons and therefore lacks any field for carrying workstation name in the ticket request message.
  • Source Network Address: The IP address of the computer where the user is physically present in most cases unless this logon was initiated by a server application acting on behalf of the user. If this logon is initiated locally the IP address will sometimes be 127.0.0.1 instead of the local computer’s actual IP address.  This field is also blank sometimes because Microsoft says “Not every code path in Windows Server 2003 is instrumented for IP address, so it’s not always filled out.”
  • Source Port: Identifies the source TCP port of the logon request which seems useless since with most protocols’ source ports are random.
Detailed Authentication Information:
  • Logon Process: (see 4611)
  • Authentication Package: (see 4610 or 4622)
  • Transited Services: This has to do with server applications that need to accept some other type of authentication from the client and then transition to Kerberos for accessing other resources on behalf of the client.  See http://msdn.microsoft.com/msdnmag/issues/03/04/SecurityBriefs/
  • Package name: If this logon was authenticated via the NTLM protocol (instead of Kerberos for instance) this field tells you which version of NTLM was used.  See security option “Network security: LAN Manager authentication level”
  • Key Length: Length of key protecting the “secure channel”.  See security option “Domain Member: Require strong (Windows 2000 or later) session key”.  If value is 0 this would indicate security option “Domain Member: Digitally encrypt secure channel data (when possible)” failed
Reference

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4625