GIM Category: authentication
The authentication category covers events where accounts or services attempt to access, validate, or terminate sessions on a system.
This includes, but is not limited to, logon activity, credential validation, and related events such as logoff, Kerberos requests, or policy checks.
Authentication events in this category are account-centric: each event must identify a user or service account (user_name) and the application or system (application_name) where the activity occurred.
logon
Logon events represent attempts to establish or resume an authenticated session on a system or service. The result should be captured in event_outcome (for example, success or failure). This is distinct from credential validation, which is the act of an authenticator checking submitted credentials.
Mapping guidance:
- If the platform emits separate records for logon and credential validation, assign a single, matching GIM code to each record respectively. Do not assign both codes to the same record.
- If the platform emits only a logon record that implies credential validation (for example, "user 'administrator' logged on successfully"), assign both the 'logon' and 'credential validation' event type codes to that single record.
- If the event reflects resuming an existing session without re-validating credentials (for example, a session reconnect), assign only the 'logon' code.
Required Fields
application_namedestination_referenceevent_outcomesource_referenceuser_name
Optional Fields
user_domain
| gim_event_type_code | gim_event_class | gim_event_category | gim_event_subcategory | gim_event_type | description |
|---|---|---|---|---|---|
|
100000 |
authentication |
authentication.logon |
logon |
A user or service performed a logon activity |
|
|
100003 |
authentication |
authentication.logon |
logon with alternate credentials |
A user or service has provided alternate credentials when authenticating |
|
|
100004 |
authentication |
authentication.logon |
session reconnect |
A user or service has resumed an existing session that was disconnected from but was not terminated |
credential validation
Credential validation events represent the act of an authentication system checking credentials provided by a user or service account. The outcome of this check (for example, success or failure) must be recorded in event_outcome.
Credential validation is distinct from logon. A system may emit both a credential validation event and a separate logon event (for example, Windows with Kerberos or NTLM), or it may emit only a logon event that implies credential validation. In the latter case, the logon description provides mapping guidance for assigning both codes to the single logon event.
Required Fields
application_nameevent_outcomesource_referenceuser_name
| gim_event_type_code | gim_event_class | gim_event_category | gim_event_subcategory | gim_event_type | description |
|---|---|---|---|---|---|
|
100500 |
authentication |
authentication.credential validation |
credential validation |
The validation of credentials provided by a user or service |
|
|
100501 |
authentication |
authentication.credential validation |
error |
An error was encountered when attempting to validate credentials provided by a user or service |
|
|
100502 |
authentication |
authentication.credential validation |
mfa |
The authenticating system asked for an additional authentication factor |
|
|
100503 |
authentication |
authentication.credential validation |
sms_send_message |
The authenticating system sent an authentication token via SMS |
|
|
100504 |
authentication |
authentication.credential validation |
voice_call |
The authenticating system sent an authentication token via a voice call |
access notice
Access notices are events that are generated during authentication that provide additional information related to authentication
Required Fields
application_nameuser_name
| gim_event_type_code | gim_event_class | gim_event_category | gim_event_subcategory | gim_event_type | description |
|---|---|---|---|---|---|
|
101000 |
authentication |
authentication.access notice |
special logon |
The user logging on has elevated privileges |
|
|
101001 |
authentication |
authentication.access notice |
error |
There was a system error encountered during the authentication process |
access policy
Access policy events record enforcement actions taken during authentication when an account, device, or session violates a defined policy. These events do not represent the credential validation process itself, but rather show when access is denied or restricted due to policy rules.
Examples include: - Access policy violations (such as time-of-day restrictions or geo-blocking) - Device policy violations (such as requiring managed devices) - Account policy violations (such as expired or disabled accounts)
Access policy events are security-relevant because they indicate that authentication was attempted but blocked or constrained by policy enforcement.
Required Fields
application_namesource_referenceuser_name
| gim_event_type_code | gim_event_class | gim_event_category | gim_event_subcategory | gim_event_type | description |
|---|---|---|---|---|---|
|
101500 |
authentication |
authentication.access policy |
access policy violation |
The account attempting to access a system or service has committed a violation of a defined access policy |
|
|
101501 |
authentication |
authentication.access policy |
device policy violation |
The account attempting to access a system or service has committed a violation of a defined device policy |
|
|
101502 |
authentication |
authentication.access policy |
account policy violation |
The account attempting to access a system or service has committed a violation of a defined account policy |
kerberos request
Kerberos request events represent authentication activity specific to the Kerberos protocol. These events capture the lifecycle of Kerberos ticket operations, including service ticket requests and renewals, ticket-granting ticket (TGT) requests, and errors encountered by the Kerberos subsystem.
Kerberos request events are distinct from generic credential validation or logon events. They should be assigned when the authenticator records Kerberos-specific ticket activity, even if additional logon or credential validation events are also present.
Required Fields
application_nameevent_outcomesource_referenceuser_name
| gim_event_type_code | gim_event_class | gim_event_category | gim_event_subcategory | gim_event_type | description |
|---|---|---|---|---|---|
|
102000 |
authentication |
authentication.kerberos request |
service ticket renewed |
A Kerberos service ticket has been renewed |
|
|
102001 |
authentication |
authentication.kerberos request |
service ticket requested |
A Kerberos service ticket has been requested |
|
|
102002 |
authentication |
authentication.kerberos request |
tgt request |
A Kerberos ticket-granting ticket (TGT) has been requested |
|
|
102003 |
authentication |
authentication.kerberos request |
error |
The Kerberos system has encountered an error |
logoff
Logoff events represent the termination of an authenticated session on a system or service. These events indicate when a user or service account intentionally ends a session, or when the system records a disconnect without fully terminating the session.
Logoff events provide closure to the authentication lifecycle, complementing logon events. They are valuable for tracking session activity and distinguishing between normal logoff behavior and disconnected sessions that remain idle or open.
Required Fields
application_nameuser_name
| gim_event_type_code | gim_event_class | gim_event_category | gim_event_subcategory | gim_event_type | description |
|---|---|---|---|---|---|
|
102500 |
authentication |
authentication.logoff |
logoff |
User has logged off from a system |
|
|
102501 |
authentication |
authentication.logoff |
session disconnect |
A user has disconnected from a system, leaving the user session idle and waiting for a reconnection |
default
The default subcategory is a fallback for authentication-related events that do not clearly fit into another defined subcategory. It should be used sparingly, and only when no more specific mapping is available.
Default mappings are useful for capturing unclassified or vendor-specific authentication events, but relying heavily on this subcategory reduces the consistency and analytic value of the information model. Whenever possible, events should be assigned to a more specific authentication subcategory.
Required Fields
application_nameuser_name
| gim_event_type_code | gim_event_class | gim_event_category | gim_event_subcategory | gim_event_type | description |
|---|---|---|---|---|---|
|
109999 |
authentication |
authentication.default |
authentication message |
Messages related to authentication |
