• Possible Field Prefixes: source_* (e.g. source_user_name) or destination_* (e.g. destination_user_name)

  • Where messages describe an action taken by one account impacting another account, the actor (account taking the action) will be described by the source_user_* fields and the subject (account for which the action was taken) will be described by the user_* fields. Examples include:

    • Authentication, where the authenticating service account context is provided

    • IAM events, where a user or service has performed an action that impacts a user or group

User Fields
Field Name Example Values Field Type Notes
user_command   keyword  
user_command_path   keyword  
user_domain mycorp.internal keyword AD or LDAP domain
user_email user@mycorp.internal keyword  
user_id   keyword Mapped to SID or UID, etc.
user_name   keyword (normalized:loweronly)  
user_session_id 0x534, 1055 keyword User logon session identifier

 

Derived and Enriched Fields (values will be derived or added from external sources)
Field Name Example Values Field Type Notes
user_category vip, default account, finance, help desk keyword Future: From entity mapping
user_name_mapped Built in\Administrators keyword (normalized:loweronly) When a user identity or identities is mapped from a source outside of the message itself it is written to this field. This is where Windows well-known SIDs are resolved.
user_priority critical, high, medium, low keyword Future: From entity mapping
user_priority_level 4-Jan byte Numeric value representing the priority of the user account, 1 = low, 2 = medium, 3 = high, 4 = critical
user_type user, computer, well-known sid, group, {any vendor-provided value} keyword Experimental field ** This is still being researched - need to look at what winlogbeats/nxlog may provide in terms of SID resolution in different configurations, and consider different technologies use of “types”