Repository navigation
[System] : ECS user field mapping issues in password change, account creation, and group membership events #20105
Description
Activity
Pinging @elastic/sec-linux-platform (Team:Security-Linux Platform)
Hi,
We have noticed issue for these logs too - Security event admin changes, please help to consider the below details-
2026-06-11T12:04:47.472486+01:00 dyl10971app05 userdel[19490]: delete user 'testuser'
event.action, user.name is missing
we need testuser in user.target.name not in user.name -
2026-06-11T12:09:27.267125+01:00 dyl10971app05 groupdel[95582]: group 'siemqa' removed
event.action is missing -
2026-06-11T12:09:27.267125+01:00 dyl10971app05 groupdel[95582]: group 'siemqa' removed
event.action, group.name is missing -
Jun 8 12:23:51 crc-uk.fm-manager01 userdel[67083]: removed group 'admin' owned by 'admin'
event.action is missing
-
elastic-vault-github-plugin-prod commented
on Jul 24, 2026 ContributorPackage system - 2.22.0 containing this change is available at https://epr.elastic.co/package/system/2.22.0/
@nicholasberlin , We should not get user.name and user.target.name field values same, still it is the case for all the events, we are getting user.target.name correctly but without getting the actor details, we are having user.name which should not be the case, user.name field should be unset , please refer to the comments added on expected to see section
-
Password Change event, PFB
current mapping
"user": {
"name": "john_test",
"target": {
"name": "john_test"
We didn't get the expected behaviour as mentioned, please help to check on this below for expected result
{
"user.target.name": "siem_test"
}
user.name should remain unset because the actor is not available in the source log. -
Account Creation
"user": {
"name": "siem_test",
"id": "12345",
"target": {
"name": "siem_test",
"id": "12345"
expected , user.name should remain unset unless additional auditd/sudo/PAM events are correlated.- Privilege Account Activity
user.name shouldnot be populated
2026-06-11T12:04:47.472486+01:00 dyl10971app05 userdel[19490]: delete user 'testuser' ==> username should not be populated
- Security event admin changes Worked
please help to consider these log types also as mentioned above
- 2026-06-11T12:09:27.267125+01:00 dyl10971app05 groupdel[95582]: group 'siemqa' removed
- event.action is missing
- 2026-06-11T12:09:27.267125+01:00 dyl10971app05 groupdel[95582]: group 'siemqa' removed
- event.action, group.name is missing
- Jun 8 12:23:51 crc-uk.fm-manager01 userdel[67083]: removed group 'admin' owned by 'admin'
- event.action is missing
-
We should not get user.name and user.target.name field values same
This was done intentionally so that existing rules were not broken. Instead of removing
user.name, we posted a deprecation message to the change log, so that users can have a chance to update their rules, dashboard, etc.Populate
user.target.name(anduser.target.idfor useradd) with the affected account for useradd account creation, usermod group membership, userdel deletion, and PAM password change events, and extractuser.target.nameandgroup.namefrom userdel messages. For backward compatibility these events keep writing the affected account touser.name/user.id; this duplication is deprecated and will be removed in a future major version — update detection rules, dashboards, and other content that reads the affected account fromuser.nameto useuser.target.nameinstead.There are two PRs up that follow through with the depracation. One that swaps known dashboards from
user.nametouser.target.nameand one that removesuser.nameas a breaking change. I haven't decided on a timeline for merging them though. How long is long enough to make a change? Not sure.Hi @nicholasberlin, This issue is currently impacting the onboarding of multiple data sources and is becoming a blocker for ongoing integration work. We would appreciate it if this could be treated with high priority.
Could you please provide an update on the status of the outstanding PRs and an estimated timeline for their review and merge? Understanding the expected schedule will help us plan our onboarding activities and manage dependencies accordingly.
why is it a blocker?
status: both PRs have not been reviewed/approved.
timeline: still trying to figure out how long to wait, was originally thinking a month.- added 2 commits that reference this issue
on Aug 3, 2026 Hi nicholas, team agreed to ignore user.name field as workaround for now and will wait for the PR to merge
Ah, cool. Thanks for the update.
elastic-vault-github-plugin-prod commented
on Sep 15, 2026 ContributorPackage system - 2.24.0 containing this change is available at https://epr.elastic.co/package/system/2.24.0/
Integration Name
System [system]
Dataset Name
system.auth
Integration Version
2.20.0
Agent Version
8.19.11
Agent Output Type
logstash
Elasticsearch Version
9.3.3
OS Version and Architecture
OEL 8
Software/API Version
NA
Error Message
No parsing errors are observed in the ingested events. The issue is related to ECS field mappings for Linux account management events processed through the default ingestion pipeline.
Event Original
Password Change
Jul 9 08:25:33 mnonoidnsc passwd: pam_unix(passwd:chauthtok): password changed for john_test
Account Creation
Jul 9 08:18:16 mnonoidnsc useradd[245678]: new user: name=siem_test, UID=12345, GID=45678, home=/home/siem_test, shell=/bin/bash
Privilege Account Activity
Jul 9 08:34:53 mnonoidnsc usermod[2778973]: add 'siem_test' to group 'hbldump
Security event admin changes
Jul 9 08:35:35 mnonoidnsc userdel[2499712]: delete 'siem_test' from group 'tcpdump'
What did you do?
Validated Linux authentication and account management events processed through the default Linux ingestion pipeline.
Source → Elastic Agent → Logstash → Kafka → Logstash → Elasticsearch
Reviewed the ECS field mappings generated for Password Change, Account Creation, and Group Membership Modification events.
What did you see?
Current Mapping
{
"user.name": "siem_test",
"user.target.name": "siem_test"
}
Account Creation
Current Mapping
{
"user.name": "siem_test"
}
The source log contains information about the newly created account (siem_test) but does not contain information about the user who performed the account creation. Therefore, the created account should be mapped to user.target.name, while user.name cannot be derived from the event.
Privilege Account Activity
The source log contains the affected user (siem_test). But the affected user is not mapped to user.target.name even though that information is available in the event.
Security event admin changes
Current ECS Mapping
{
"event.category": ["iam"],
"event.type": ["user", "deletion"],
"event.outcome": "success"
}
What did you expect to see?
Password Change
{
"user.target.name": "siem_test"
}
user.name should remain unset because the actor is not available in the source log.
Account Creation
Expected Behavior
{
"user.target.name": "siem_test"
}
Since the log represents the creation of the account siem_test, the affected account should be mapped to user.target.name.
The account creator cannot be determined from the source log, therefore user.name should remain unset unless additional auditd/sudo/PAM events are correlated.
Privilege Account Activity
{
"user.target.name": "siem_test"
}
Security event admin changes
The integration should extract:
Expected Behavior
{
"user.target.name": "siem_test",
"group.name": "tcpdump",
"related.user": ["siem_test"],
"event.action": "removed-user-from-group"
}
Anything else?
Require additional auditd/sudo/PAM correlation to identify the actor for Password Change and Account Creation events.