Description Fields in 4624

Subject:

Identifies the account that requested the logon - NOT the user who just 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 sytem.

• Security ID
• Account Name
• Account Domain
• Logon ID

Logon Information:

• Logon Type: See below

Remaining logon information fields are new to Windows 10/2016

• Restricted Admin Mode: Normally "-"."Yes" for incoming Remote Desktop Connections where the client specified /restrictedAdmin on the command line.  Restricted admin mode is an important way to limit the spread of admin credentials in ways they can be harvested by malware using pass-the-hash and related techniques.  You should only see with for logon type 10.  When you remote desktop into a server with /restrictedAdmin you get full authority on that server but it doesn't carry with you if you access other systems from within that RDP session.  This field allows you to detect RDP sessions that fail to use restricted admin mode.
• Virtual Account: Normally "No". This will be Yes in the case of services configured to logon with a "Virtual Account".  Virtual Accounts only come up in Service logon types (type 5), when Windows starts a logon session in connection with a service starting up.  You can configure services to run as a virtual account which is what Microsoft calls a "managed local account".  They're "domain" is "NT Service" as in an instance of MS SQL Server named Supercharger running as NT SERVICE\MSSQL$SUPERCHARGER.  
• Elevated Token:  Yes or No.  It will be Yes if the user is a member of Administrators - kind of... The "kind of" applies to interactive logons, when you are an admin and you have User Account Control (UAC) enabled. Then when you logon you actually get 2 logon sessions.  One without the Administrators SID and related privileges in your security token and another session with all that authority.  Everything you do happens under the unprivileged logon session until you attempt to run something requiring admin authority.  After you approve the UAC dialog box, Windows runs that one operation under the other logon sesson.  So in the log you will see 2 of these events, one where this field is Yes and other No.  The 2 logon sessions are connected by the Linked Logon ID described below.

Logon Type:

This is a valuable piece of information as it tells you HOW the user just logged on:
 

Impersonation Level: (Win2012 and later)

From MSDN

New Logon:

The user who just logged on is identified by the Account Name and Account Domain.  You can determine whether the account is local or domain by comparing the Account Domain to the computer name.  If they match, the account is a local account on that system, otherwise a domain account.

• Security ID: the SID of the account
• Account Name: Logon name of the account
• Account Domain: Domain name of the account in either the DNS name (can be upper or lowercase) or pre-Win2k NETBIOS domain name.  In the case of special subjects (well known security principals) like SYSTEM, LOCAL SERVICE, NETWORK SERVICE, ANONYMOUS LOGON this field will be "NT AUTHORITY".  It can also be "NT Service" as in the case of virtual accounts for services.  See above.  Finally, if the account is a local account, this field will be the name of the computer.
• Logon ID: a semi-unique (unique between reboots) number that identifies the logon session just initiated.  Any events logged subsequently during this logon session will report the same Logon ID through to the logoff event 4647 or 4634.
• Linked Login ID: (Win2016/10) This is relevant to User Account Control and interactive logons.  When an admin logs on interactively to a system with UAC enabled, Windows actually creates 2 logon sessions - one with and one without privilege.  This is called a split token and this fields links the 2 sessions to each other.  See Elevated Token above.
• Network Account Name: (Win2016/10)  This appears to always be "-".  It seems connected to LogonUser() with LOGON32_LOGON_NEW_CREDENTIALS but I've not been able to produce an example.  If you have an event with this field filled in please open a forum posting on this page and let us see it.
• Network Account Domain: (Win2016/10)  see above
• Logon GUID: Supposedly you should be able to correlate logon events on this computer with corresonding authentication events on the domain controller using this GUID.  Such as linking 4624 on the member computer to 4769 on the DC.  But the GUIDs do not match between logon events on member computers and the authentication events on the domain controller.

Process Information:

• Process ID is the process ID specified when the executable started as logged in 4688.
• 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 intitiated 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 intitiated 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) CredPro indicates a logon initiated by User Account Control
• 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/.  MS says: Transmitted services are populated if the logon was a result of a S4U (Service For User) logon process. S4U is a Microsoft extension to the Kerberos Protocol to allow an application service to obtain a Kerberos service ticket on behalf of a user – most commonly done by a front-end website to access an internal resource on behalf of a user. For more information about S4U, see https://msdn.microsoft.com/en-us/library/cc246072.aspx
• 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".  This field only populated if Authentication Package = NTLM.  Possible values: “NTLM V1”, “NTLM V2”, “LM”
• 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.  MS says the length of NTLM Session Security key. Typically it has 128 bit or 56 bit length. This parameter is always 0 if “Authentication Package” = “Kerberos”, because it is not applicable for Kerberos protocol. This field will also have “0” value if Kerberos was negotiated using Negotiate authentication package.