3.4 User and Group Administration

Introduction

User and group administration is one of the core responsibilities of a Linux system administrator. At this level you move beyond simply using accounts and begin to control who can log in, what they can access, and how they are organized. This chapter focuses on practical administration tasks and concepts that build on the basic ideas of users, groups, and permissions that you encountered earlier in the course, but here you will actually manage accounts and their environment.

Accounts, Identity, and Authentication

Every action on a Linux system is associated with a numeric user ID, or UID, and one or more group IDs, or GIDs. The kernel cares about these numbers, while humans use the corresponding names. When you manage users and groups as an administrator, you are really manipulating these identifiers and their associated metadata.

Users are typically divided into a few broad categories. The superuser, usually named root, has UID 0 and effectively unrestricted access to the system. System users and system groups usually have low UIDs and GIDs that are reserved for services and daemons, such as sshd or www-data. Regular human users, often called local users, are assigned UIDs from a higher numeric range. The exact ranges are controlled by configuration files and can vary between distributions.

Authentication is the process that checks whether a user is really who they claim to be. On most standalone systems this is handled through local password hashes stored in the shadow password file, combined with Pluggable Authentication Modules, often called PAM. Centralized or network authentication methods, such as LDAP or Kerberos, build on the same underlying concepts but are typically configured in larger environments and will not be set up by default on a single desktop or small server.

Local User Management Concepts

Local users are accounts that exist only on a specific machine. When you use commands to create, modify, or delete users, you are usually working with this local database. A user account is defined by several key properties: a username, a numeric UID, a primary group, a home directory, a login shell, and authentication details that are stored as a password hash rather than a plain password.

The primary group is the group that the user belongs to by default. In many modern Linux distributions, each user gets a unique primary group with the same name. This is often referred to as the user private group model. Additional memberships are called supplementary groups. Together, these groups control which files and resources the user can access.

The home directory is the user’s personal space under the filesystem hierarchy. For most local users it is located under /home, for example /home/alice. Configuration files for the user, such as shell startup files and application preferences, live there as so called dotfiles. The login shell defines which program is executed for interactive logins, often /bin/bash for a traditional shell or another shell such as /bin/zsh. When you administer accounts, you decide whether an account is a normal login account with a real shell, or a restricted account that does not permit interactive logins.

Group Management Concepts

Groups are collections of users that share certain permissions. Instead of granting access to each user independently, you grant access to a group, then add or remove users from that group as needed. This separation is central to scalable administration, because it lets you manage privileges in one place while user membership changes over time.

There are system groups, often associated with services, and normal groups, which you use to represent teams, roles, or shared projects. A user has exactly one primary group, but can belong to many supplementary groups. When a user creates a new file, by default that file is owned by the user and the user’s primary group, unless a special directory setting such as the setgid bit on a directory changes this behavior.

On most systems, group information is managed locally in a plain text file that stores group names, GIDs, and member lists. When a system is attached to a directory service, groups can also come from external sources, but the local file still exists and often contains important system groups.

Core User Information Files

Several text files in the filesystem describe user accounts and their authentication data. These are central to user and group administration, and you must treat them with care.

The password database is stored in /etc/passwd. Despite its name, this file does not contain actual passwords on modern systems. Instead, it contains one line per user with a colon separated structure that includes the username, UID, primary GID, home directory, and login shell. Historically, encrypted passwords lived there, but to improve security they were moved to a separate file.

That separate file is /etc/shadow, which is readable only by the superuser and certain privileged processes. Each line in that file corresponds to a user and stores the password hash, plus additional fields with password aging information such as minimum and maximum password lifetimes. The shadow file is vital to the authentication process. If it is damaged or misconfigured, users can be locked out.

Groups are defined in /etc/group. Each line describes a group name, its numeric GID, and a comma separated list of members. While tools usually update this file for you, you can inspect it to verify group membership or diagnose problems. There is also /etc/gshadow, which is a shadow style file for groups that holds group passwords and is used when group passwords are enabled, something that is rare on typical systems.

Because these files are so important, they are often backed up or protected by configuration management systems. Before making manual changes, it is common to create a backup copy. Using command line tools instead of manual editing helps prevent syntax errors, but you still need to understand the structure in order to debug problems.

Creating and Removing Users

On a typical Linux system you manage users through utilities that wrap direct edits to the account files. The most common tool to create users is useradd. As the superuser, or through sudo, you run it with options that define the characteristics of the new account.

If you invoke useradd with only a username, it uses default settings from configuration files such as /etc/login.defs and from the system’s skeleton directory. These defaults determine where home directories are created, the UID and GID ranges, and whether a private group is created automatically. Distribution specific tools exist as well, for example some systems provide a more user friendly wrapper that guides you through the process with prompts.

After creating an account, you must set a password with the passwd command so the user can log in with traditional password authentication. Without a set password, the account may be effectively locked for interactive use, unless you configure another authentication method. It is often best practice to require the user to change this initial password on first login, using password aging parameters.

Removing users is handled with userdel. You can choose whether to simply delete the account entry or to also remove the home directory and mail spool. Account removal does not automatically take ownership of files outside the home directory, so files on shared directories or external storage may remain with the old UID. If that UID is later reused by a different user, it can create confusing and potentially insecure situations. For that reason, serious administrators often avoid reusing UIDs and may search for and handle remaining files manually.

There is an important distinction between disabling a user and fully deleting the account. In some environments you may wish to preserve data for auditing or future reference while preventing logins. In that case you can lock the account rather than remove it entirely. Account locking typically modifies the password field in the shadow file so that no valid password can match.

Modifying Existing Accounts

User administration frequently involves changing properties of existing accounts as people change roles or requirements evolve. The usermod command is the primary tool for this purpose. It lets you alter the login name, the home directory, the primary group, the shell, and group memberships.

If you change a user’s home directory, you can optionally move existing data into the new location. This is necessary if you restructure storage or adopt a new layout. Changing the login shell is another common action when someone prefers a different interactive environment or when you want to restrict normal access by assigning a limited shell or even a special program that runs at login.

You can also lock or unlock accounts with passwd options or with specific user management commands. Locking does not remove the account, instead it temporarily disables authentication. This is often used when an employee leaves an organization or during security incidents while you investigate suspicious activity.

Whenever you modify account properties, be aware of side effects. Changing UIDs or GIDs after files exist is particularly sensitive, because many files may still be owned by old identifiers. Specialized tools can help adjust ownerships across the filesystem in a controlled way when such changes are unavoidable.

Password and Account Policies

Security policies around passwords and account aging are central to responsible administration. On Linux systems, these policies combine settings in several configuration files with PAM modules that enforce rules at password change and login time.

Password aging parameters live in the shadow database and specify a minimum number of days before a password can be changed again, a maximum age before it must be changed, and warning and inactivity periods. The chage command is commonly used to inspect and modify these values for individual users. It allows you to set when a password expires, how long before expiry the user is warned, and when an account should be disabled after the password expiration.

To enforce password complexity, reuse limits, or history checks, systems use PAM configuration files that call specialized modules. These modules can enforce rules such as minimum length, required character classes, or checks against known weak passwords. Administrators decide which PAM modules to use and in what order. The PAM configuration files are sensitive, so you need to be careful when editing them because mistakes can lock out all users, including the administrator.

Account lockouts after several failed login attempts are another part of policy. PAM modules can count failed attempts and temporarily lock accounts to mitigate brute force attacks. You must balance security with usability, because overly strict settings can increase support overhead and frustrate legitimate users.

Passwordless mechanisms, such as SSH keys or multifactor authentication, complement or replace password policies. They are configured separately but still rely on the user identity framework that local user and group administration provides.

Managing Groups and Memberships

Creating and maintaining groups parallels user administration. The groupadd command creates new groups with specified names and optionally explicit GIDs. As with user IDs, it is best to let the system assign GIDs automatically in the normal range, and reserve manual assignment for special circumstances like shared storage that must match an external system.

You can modify existing groups with groupmod to change names or GIDs, and remove groups with groupdel. Before deleting a group, consider any files that might still be owned by it. Removing the group will leave those files with a numeric group ID that no longer maps to a name. The files will still work, but management becomes harder and intentions less clear.

User membership in groups can be managed with several tools. The usermod command can append or remove supplementary groups for a user. Some systems also provide a gpasswd command that allows administrators to control group administrators and group passwords where those features are used. The groups or id commands help you verify which groups a user belongs to.

Group membership can affect much more than file access. On desktop systems, membership in privileged groups can grant device access or specific capabilities like managing printers or using virtualization features. On servers, membership in certain groups can enable service management or restricted administrative roles. For that reason, it is important to understand and periodically audit membership of sensitive groups.

Login Shells and User Environments

The login shell determines how a user interacts with the system when they log in. It is configured per user in the account database and can be any program listed in /etc/shells. Most users will use a traditional command interpreter such as bash, zsh, or fish. Some accounts, especially service accounts, use shells like /usr/sbin/nologin or /bin/false to prevent interactive access entirely.

When you assign or change shells, consider both user preferences and security. Allowing an unrestricted shell on a shared system grants significant power even to non administrative users, since they can run arbitrary programs within their own permission boundaries. For restricted scenarios, administrators may provide limited shells or even forced commands through mechanisms beyond user and group settings, but the shell choice is still one of the first gates.

The user environment includes variables, aliases, and startup scripts that control how the shell behaves. These are configured through files in the user’s home directory, often created from templates in /etc/skel when the account is first made. From an administrative perspective, you decide what defaults every new user receives. For example, you can place a preconfigured prompt, editor preference, or path settings into the skeleton directory so that new accounts start with a sensible environment.

Centralized control of the environment becomes more important in multi user or production systems, where consistency matters. You might define organization wide environment variables or security related shell options in global configuration files such as /etc/profile or shell specific equivalents. Users can usually override some of these in their own dotfiles, but you can harden or lock down critical aspects when necessary.

Service Accounts and Nonlogin Users

Not all accounts correspond to humans. Services and daemons often run under dedicated service accounts that exist only to provide an identity for processes. These accounts usually have no password, no real home directory, and a shell that does not permit interactive logins. Their UIDs are often in a special system range, different from regular users.

Running services under dedicated accounts limits damage if a service is compromised. File and process permissions can be tailored to each service, so even if an attacker takes control of a particular daemon, they cannot easily access unrelated data. This principle of least privilege is fundamental to secure system design.

When you install software through the package manager, it may automatically create such service accounts. As an administrator, you must understand their purpose before removing or altering them, because changing their settings can break running services. You can also create your own service accounts for custom applications, following similar patterns.

Sometimes you need accounts that can own files or act as placeholders, yet must not be used for logins. By assigning a locked password and a nonlogin shell, you can create such noninteractive accounts. They fit well for shared file ownership or automation tasks where processes authenticate with keys or other mechanisms rather than interactive passwords.

Centralized and Network Based Accounts

In larger environments, managing local users and groups on every machine quickly becomes unmanageable. Instead, organizations rely on centralized identity services that supply user and group information to many hosts at once. While the details of these systems are outside the beginner scope, you should understand how they relate to local administration.

Network based accounts might be provided by directory services such as LDAP, Active Directory, or identity management systems that integrate Kerberos for authentication. On Linux, these external sources are combined with local accounts via the Name Service Switch, usually configured in /etc/nsswitch.conf. From the user’s perspective, a network account looks very similar to a local one, but it is defined and managed centrally.

As an administrator of a single machine that participates in such a system, you generally avoid creating conflicting local accounts with the same names or IDs as centralized users. Local accounts are still used for system purposes and break glass access if the network is unavailable. In mixed environments, it becomes important to understand which accounts are local and which are remote, and to know how your distribution integrates with central directory services.

Security Considerations in Account Administration

User and group administration is directly tied to system security. Every account is a potential entry point, and every misconfigured group membership can grant unintended access. You must adopt habits and policies that reduce risk while keeping the system usable.

Inactive or unused accounts are a common weakness. Accounts for former users, test logins that were never removed, or defaults left by software packages can all increase the attack surface. Regular reviews of the account list, along with prompt disabling and eventual deletion of unneeded accounts, are part of good hygiene.

Group sprawl is another concern. Over time, users may accrete memberships as they take on different tasks, but those memberships are rarely removed. Excessive group privileges can allow users to bypass controls, read confidential files, or control services they should not touch. Periodic audits that compare group memberships to current roles help maintain the principle of least privilege.

Password policies are only effective if accompanied by user education and technical enforcement. Weak or reused passwords defeat the purpose of account separation. Similarly, failing to secure administrator level accounts or leaving default passwords unchanged nullifies the protection that user separation is supposed to provide.

Auditing and logging are closely related to administration. While detailed logging is discussed elsewhere, you should be aware that user and group changes themselves can be logged by the system or by audit frameworks. This provides accountability and can help you reconstruct what happened during an incident.

Finally, avoid direct manual editing of core account files whenever possible. Mistakes in /etc/passwd, /etc/shadow, or /etc/group can cause subtle bugs or even make the system unbootable or inaccessible. Use the provided user and group management tools that understand the correct formats and handle concurrent updates safely.

Summary

User and group administration connects abstract concepts like identities and permissions to the real day to day tasks of managing accounts on a Linux system. By understanding how local users and groups are represented, how their core files are structured, and how tools create, modify, and remove them, you can control who may log in, which resources they can access, and how safely services run. These skills form the basis for more advanced topics such as shell configuration, centralized identity management, and full system hardening.