Linux users and groups: security configuration and audit

Linux user management: where access separation breaks

A shared account on servers looks convenient right up until the first incident.

All actions in the log are signed with the same uid, and determining who exactly restarted the database or edited the configuration is impossible — the investigation drags on for days, and the culprit is sought by indirect signs.

If such an account is also stored in the notes of the entire team, revoking it is faster than figuring out who has it.

The second typical breakdown is permissions granted “temporarily.” A sudo rule with password prompting disabled remains in the file after the task is closed, an employee is forgotten in a group with container permissions, and a departed employee’s public key continues to sit in authorized_keys on dozens of hosts at once.

Revocation was not part of the process, so excessive privileges live for years and surface only during an audit or after a failure.

Hence the third problem: access audit does not answer a simple question — who and when gained access to the server.

Numeric identifiers are reused after an account is deleted, old log lines start pointing to another person, and log retention is often shorter than the lifespan of a key. Access separation stops being a formality: without personal accounts, an investigation is nullified.

We break down how this is closed: personal accounts with roles via groups, limited privilege lifespan, regular key reconciliation, and audit rules by which access can be confirmed or refuted from the log.

What order in accounts and access rights provides

A unified access model is not about administrative convenience, but about predictable numbers: how much time granting and revoking rights takes, how many privileged accounts exist across the fleet, and whether the picture of an incident can be reconstructed from login logs.

Granting and revoking rights — one operation for the entire fleet

Rights are distributed through groups, not manually across servers — the standard Linux mechanism is carried into a unified access model.

An employee is added to the required group and receives rights everywhere it is declared; termination or a role change means removal from the group, and access disappears on all nodes simultaneously.

The share of servers under a common policy tends toward 100%, and revocation no longer depends on whether the on-call engineer remembers a specific machine.

Privileged accounts — a handful, lifespan limited

Instead of a shared root account on every host — named accounts and role-based sudo rules, and for one-off work — temporary access with an expiration date. The number of privileged accounts is reduced to a handful, and every login under them is explainable.

The lifespan of a contractor’s or intern’s account is set in advance: the account expires on its own, and no one needs to be reminded about it.

Incidents are investigated from logs

Logging of logins, sudo calls, and changes in groups goes to centralized collection, where the record is tied to a person, not to a machine address.

Investigating the question “who and when gained access to this node” takes minutes instead of a day of correspondence with the team.

Access separation in Linux: local accounts, directory, domain

The account scheme is determined not by fleet size, but by where the source of truth lives and who is responsible for revoking access.

Local accounts in /etc/passwd and /etc/group work while there are dozens of machines: terminating an employee turns into a walk through all hosts, identifiers diverge between environments, and legacy in sudoers has to be reconciled manually.

Below are three schemes that are actually chosen between. Each has its own support cost, and it becomes visible only in the second year of operation.

In practice, a hybrid scheme almost always emerges: the domain is responsible for people and groups, while local accounts are responsible for services that do not need the domain (daemons, backups, monitoring).

The key here is to reserve identifier ranges for each role in advance; otherwise, when a host is connected to the directory, existing files will change owner and the application will stop reading its data.

The second condition is managing groups through rules, not by editing files on the host: then access revocation is verified with a single command and remains in the audit log.

How implementation proceeds: from account audit to policy

Implementation does not start with editing configs, but with a complete picture: in a server fleet, accounts accumulate, “temporary” access remains forever, upon termination system login is blocked, but keys in authorized_keys, sudo rules, and cron jobs are forgotten.

Therefore, the order is the reverse of the usual: first we record what exists, then we design roles, and only then do we change the configuration.

1. Account audit. We collect the list of users and groups from hosts, analyze sudoers, password expiration, keys, and service accounts, and reconcile against actual employees and process owners.
2. Permission inventory. We build a matrix of “who — which group — which sudo rule — on which hosts,” mark excessive rights with password prompting disabled and access to directories that do not need it.
3. Access scheme. We formulate roles — administrator, on-call engineer, developer, service account — and rules: rights are granted through groups, not personally, root login by password is closed, a centralized source of accounts is mandatory.
4. Configuration. We transfer the scheme into a configuration description so access is reproduced on a new host rather than configured manually: groups, sudo policies, session restrictions, logging actions to the system journal.
5. Testing in staging, then in production. We verify rule syntax before applying, roll out in server groups while preserving the previous configuration version — rollback takes minutes.
6. Post-implementation verification. We run tests from the perspective of each role: the required command passes, an extra one is rejected, an attempt at privilege escalation goes into the log. The output is a “before and after” report by number of accounts and rules.
7. Policy handover. We provide the document: how to create and how to close an account, what to do upon termination, who reviews rights and how often; we train the responsible people and hand over verification templates.

Configurations, access schemes, and account policies

Account management does not end with a working server login, but with a set of artifacts by which your team can manage access without us. Everything lies in the same repository as the infrastructure configuration — with change history and the ability to roll back an edit.

• Configuration files — login rules, sudo restrictions, and directory connection settings, arranged by roles and hosts, rather than one common snapshot for the entire fleet.
• Role and group map — a table “role → groups → hosts → access level,” which immediately shows who gets where.
• Password and key policies — lifespan, complexity, lockout after failed attempts, key requirements, and a second factor for administrative accounts.
• Policy for granting and revoking rights — request, approver, duration of temporary access, procedure for termination and transfer.
• Permission review procedure — scheduled reconciliation of active accounts with HR data and a separate review of service accounts and service keys.
• Account documentation — where the reference configuration is, how to check for a discrepancy on a host, what to do if login is denied.
• Support service instructions — typical scenarios: an employee left, changed role, lost a key, needs one-off access for a day.

We verify every item: we deploy access on a clean staging environment strictly according to the documentation and see where it was insufficient. Usually after such a run-through, the instructions become shorter and the role map more accurate.

Case study: a unified access model instead of scattered accounts

What it was like before the work

Retail Chain came to us with a fleet of 40 servers, where access lived in local files: each administrator had their own entry in sudoers or in the wheel group, passwords were sent via messengers, and ssh keys were not revoked after termination.

The inventory showed 340 entries with elevated rights — some belonged to contractors who had not touched the infrastructure for a year.

Investigating a single incident with a service crash took three days: from the logs it was impossible to understand whose account ran the command and what exactly changed on disk.

What was changed and what the result was

Accounts were consolidated into a single directory, and rights were described by roles according to areas of responsibility, not by people.

Permanent privileges were left only for the on-call shift, monitoring agents, and service accounts; for everyone else, we grant temporary ones — for 4 hours, with the task specified and automatic expiration.

Passwords were removed in favor of keys, and every action with elevated rights is written to a common log tied to a specific person.

Permanent privileged accounts went from 340 down to 27. Granting access takes 15 minutes via an approved request, revocation takes minutes: we disable the account in the directory, and it stops working on all servers at once, without manually going through machines.

Incident investigation was reduced to an hour and a half: it is clear who ran the command, from which machine, and what happened before and after.

We separately established a policy: quarterly reconciliation of the directory with actual connections, role review upon a change of position, and mandatory investigation of every case of privilege escalation outside a request.

What to do if accounts have already scattered across servers?

You cannot wipe out local accounts and enable a centralized directory all at once: on the servers, file owners with specific UIDs, access keys in home directories, sudo rules with point exceptions, and scheduled service jobs are already fixed.

A mass replacement breaks not only people’s logins, but also exchange between services — backups, exports, and mailings stop without a clear error in the logs.

The first step on live infrastructure is an inventory, not edits. We collect from all hosts the local users and groups, their UIDs, group membership, sudo rights, owners of data directories, and active access keys.

We do this with a fact collector (in our case — Ansible), and the output is a summary table where it is immediately clear who must not be touched at all, and who can be migrated in the first wave.

Next is a gradual migration.

We create new users in the directory, and leave local accounts while the name, UID, and groups match: files created before and after the migration are read the same way — this is the backward compatibility for which the migration is stretched over weeks.

We move sudo rules as separate files into the include directory, rather than editing a common file: then an error in one line does not disable sudo for everyone at once.

Application and service accounts are left local — they are tied to a fixed UID, and migration breaks access to data and permissions on directories. For responsible people during the transition, we keep an emergency local login with password rotation and logging.

We disable the old mechanism only after reconciliation: if there are no logins via local accounts for a specified period, we archive them.

Technical questions about accounts and access rights

Accounts and permissions are an area where changes accumulate for years and are rarely reviewed. Below are answers to the questions that most often arise when analyzing access and handing over a policy.

How should service accounts be created?

Without a login shell and with minimal rights: nologin shell, access to the required directories through a group, not through write permission for everyone. This way the service does not turn into a ready entry point for an attacker.

How do you give a contractor access without losing control?

A separate account, key-based login, a limited set of commands via sudo, and an expiration date. After the work, access is blocked, the key is revoked, and actions remain in the log.

Can rights be granted temporarily?

Yes, this is a standard mode: we put the granting rules into separate files, enable and disable them on a schedule, and limit the lifespan of the account itself with a separate parameter.

Who owns the policy after handover?

You do. We hand over the access matrix, the procedure for granting and revoking rights, the termination checklist, and the configurations themselves with comments — the policy can be executed and changed without our involvement.

Tell us about your server fleet — we will come back with a plan

For the assessment to be to the point and not template-based, a few inputs are enough. We need to understand where accounts come from, how server login is arranged, and where events are stored — then the access audit is calculated from the real picture, not from guesses.

What to send to start the discussion:

• Source of accounts: local files, an LDAP directory or an Active Directory domain, and whether hybrid schemes exist.
• Login rules: SSH settings — password prohibition for service accounts, restriction by groups, whether direct superuser login is disabled.
• List of privileged roles: who gets elevated rights and through what, whether there are one-off exceptions in sudoers.
• Lifecycle policy: password expiration, lockout after failed attempts, termination and key revocation procedure.
• Where login and permission change logs are written: local files, a dedicated collection server, or an external system.
• Inventory: how many servers, which image groups, whether there are environments with separate access requirements.

In response, we return specifics you can base a decision on. An access map: who goes where, through which group, where excessive rights are granted.

The scope of work with an explicit list of what is included and what remains on your side, and the verification procedure: a checklist for each server, the rollback method, and the point at which changes are recorded.

Handover of results — configurations, role scheme, policy for granting and revoking access, and a short instruction for the on-call shift. Describe the task — we will come back with an assessment and a plan.