User Fields¶
- 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
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 |
Field Name | Example Values | Field Type | Notes |
---|---|---|---|
user_category | vip, default account, finance, help desk | keyword | Future: From entity mapping |
user_name_mapped | Built inAdministrators | 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 | 1-4 | byte | 1 = Critical, 2 = High, 3 = Medium, 4 = Low |
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” |