An account name in an audit event can be misleading after a user runs su or sudo. The process may have a new effective identity while the activity still belongs to the person who established the session. Linux audit records address that distinction with the audit login UID, commonly called auid, and a session identifier. Security teams that review only the effective UID lose the original login context.
The login UID is assigned to a session and inherited by tasks created within it. The linux-audit rules ship a rule intended to prevent tampering with that value. A review should confirm that login programs set it, that the kernel is collecting the relevant events, and that the collector preserves the field through normalization. A missing auid is not proof that no user was involved. It may mean the process started outside a login session or that the collection path dropped the attribute.
The audit sessionid provides another correlation key. It groups events associated with one login session and can connect a command to the authentication and session lifecycle around it. The exact event set depends on configuration and distribution, so an incident process needs to test its own records rather than assume a universal schema.
Read the identity fields together
Four values are often useful in the same investigation. The audit login UID records the original login identity. The effective UID shows the privileges of the running process. The real UID shows the invocation context. The session identifier links related activity. A sudo event may show the invoking user in one field and the root process in another. The event makes more sense when those distinctions are preserved.
Do not convert an unset login UID directly to “untrusted” or “system.” The kernel uses an invalid value when no login UID has been assigned. Daemons, containers, boot-time services, and processes launched through nonstandard authentication paths can all produce different patterns. Establish a baseline for each service and session type. Then alert when a human-facing service produces an unexpected missing or inherited identity.
The field is especially useful in change review. A deployment automation account may access a host under one service identity, while an operator invokes a command through a login session and then escalates. The audit record can show that the effective account was the same while the session context differed. That distinction matters for approval, attribution, and evidence retention.
Verify collection end to end
Start with a controlled login from a test account. Record the session, run a harmless command, and then inspect the raw audit record. Confirm the login UID, effective UID, session identifier, executable path, and terminal metadata. Repeat through the identity transitions used in production. Use one test for a direct login, one for su or sudo, and one for a scheduled job. Do not assume that all three use the same login path.
Next, inspect the collector. A JSON normalization step can rename the field, drop an integer, or replace a large unsigned value with a string. A parser may reject records it cannot map and forward an incomplete event. Compare a sample raw event with the normalized event in the search platform. Confirm that retention rules keep the original fields for the investigation window and that access controls prevent ordinary analysts from editing the source.
Rules should describe what they can actually prove. A rule that looks for activity by a specific auid is useful when every relevant login path populates the field. A rule that treats an absent value as a clean process is not. Pair the detection with a configuration check that reports login methods which do not establish the expected audit session context.
Containers need an explicit collection boundary
Containerized services add layers between the host login and the process. The container runtime, namespace configuration, and host audit policy determine what the host sees. A container may carry a session value from its launcher, or it may start without one. Do not infer user behavior from a container event unless the launch path and identity propagation were verified.
For host-level investigations, correlate the container start record with the image, command, runtime identity, and orchestrator request. For application logs, preserve the request identity separately. The audit login UID is a kernel-level attribution field, not a replacement for an application's authenticated user identifier.
Keep attribution and authorization separate
The login UID supports attribution, not authorization. A process with a valid auid can still be compromised, and a record can be incomplete because of a collection defect. Use the field to connect activity to a session, then verify the account, endpoint, change ticket, and application identity that make the action legitimate. A mature process tests the full identity path before relying on a single kernel attribute in a high-impact alert.