Linux does not keep a universal username-change history, so investigate a suspected rename by following the stable UID through account files, ownership, and whatever audit logs were enabled.
A username is a label. The numeric user ID is what the kernel uses for ownership and permissions. That distinction gives an investigation a reliable starting point, but it cannot recreate audit evidence that the system never recorded.
Table of contents
- Start with the current account record
- Follow numeric ownership
- Search the evidence sources that may record the command
- Distinguish rename from a new account
- Improve future account-change evidence
- How this fits the rest of the stack
- FAQ
Start with the current account record
Read the account through getent, which respects the configured identity sources rather than assuming every user lives only in /etc/passwd. Record the username, UID, primary group, home directory, and shell. If identity comes from a directory service, investigate changes there too.
getent passwd suspected_name
id suspected_name
getent passwd | awk -F: '$3 == 1002 {print}'A local rename normally changes the login name while retaining the UID unless an administrator also changes it. Finding the same UID under a different name is strong continuity evidence, though it does not prove when or who made the change.
Follow numeric ownership
Files store numeric ownership. Use find carefully on relevant paths to locate objects owned by the UID, and inspect the home directory and service data. After a rename, tools display the new name for old files because name lookup maps the unchanged UID to the new label.
find /home /srv -xdev -uid 1002 -print 2>/dev/null
stat -c '%u %U %n' /home/*Do not launch an unrestricted filesystem scan on a busy server without considering I/O cost and pseudo-filesystems. Scope the search, schedule it, and preserve timestamps if the work is part of a formal investigation.
Search the evidence sources that may record the command
If auditd rules covered account files or execution, ausearch may reveal usermod, writes to /etc/passwd, and the responsible login session. Authentication logs, sudo logs, shell history, configuration-management logs, and central SIEM records may add context.
sudo ausearch -f /etc/passwd -i
sudo journalctl --since '2026-07-01' | grep -E 'usermod|useradd|passwd'
sudo grep -E 'usermod|sudo' /var/log/auth.logShell history is weak evidence: it can be disabled, edited, rotated, or written only when a shell exits. Treat it as a lead, not proof. Central audit records with protected retention carry more weight.
Distinguish rename from a new account
A new username with the old UID, continuous file ownership, and matching directory-service identity suggests a rename. A new UID, new home ownership, and separate authentication history suggests account replacement. Administrators can change both name and UID, so correlate several signals.
Also inspect scheduled jobs, service units, ACLs, SSH authorized keys, mail spools, and application records that may embed the old textual name. Kernel ownership survives a label change; application strings may not.
Improve future account-change evidence
Audit writes to account databases, log privileged command execution, forward records off-host, synchronize time, and define retention that matches security requirements. For centrally managed identities, keep provider audit logs and change approvals.
A good change record contains the old and new name, stable UID, operator, ticket, timestamp, affected services, home-directory action, and rollback plan. Without that record, the next incident becomes archaeology with root permissions.
How this fits the rest of the stack
If the account belongs to a deployed service, model the runtime, storage, and database before changing its host footprint in the RunxBuild hosting calculator. The RunxBuild dashboard keeps service configuration and deploy logs in one visible path.
Useful related references:
- Linux Check Disk Space: df, du, and Finding the Largest Files
- Linux Ubuntu Check Version: lsb_release, /etc/os-release, hostnamectl
- How to Check What RAM Type You Have (DDR4, DDR5) on Windows and Linux
- Database user management on RunxBuild
FAQ
Does Linux record every username change?
No. There is no universal rename-history database. Evidence depends on audit configuration, authentication logs, directory-service records, configuration management, and retention.
Does a username change also change the UID?
Normally usermod -l changes the login name while leaving the numeric UID unchanged. An administrator can change the UID separately.
Can file ownership prove a rename?
It can support continuity because files store numeric UIDs, but ownership alone does not prove when or who changed a name. Correlate it with logs and identity records.
Where should I search for usermod activity?
Check auditd, the system journal, sudo and authentication logs, central logging, configuration-management history, and the identity provider where applicable.
Can shell history prove who changed the username?
Shell history is incomplete and editable, so treat it as a lead. Protected audit and central records are stronger evidence.