User and Group Administration

Overview

User and group administration is about controlling who can log in or run processes on a system and what they are allowed to do. At the intermediate level, this moves beyond just running sudo and starts to include:

• Understanding where user and group data is stored.
• Creating and modifying local accounts and groups.
• Managing default settings for new users.
• Coordinating user IDs (UIDs) and group IDs (GIDs), especially across multiple machines.
• Dealing with locked accounts, expired passwords, and non‑login/system accounts.
• Preparing for centralized authentication (LDAP, AD, etc.) even if you’re not implementing it yet.

This chapter focuses on local user and group management using standard tools. Authentication policies and deeper security controls are handled in separate chapters.

User and Group Concepts (Intermediate View)

At this level, you should already know what a “user” and a “group” is conceptually. What matters now is:

• Users and groups are primarily identified by numeric IDs (UIDs and GIDs), not by their names.
• Files, processes, and permissions actually store/track these numeric IDs.
• A “user account” is a combination of:
• An entry in system databases (e.g. /etc/passwd, /etc/shadow).
• Optional home directory and default files.
• Group memberships.
• Authentication data (password/hash/keys), or sometimes no login capability.

You’ll also see a distinction between:

• Human (login) accounts: For people, usually with shells and passwords or SSH keys.
• System accounts: For services/daemons, often without home directories or valid shells, and not meant for interactive login.
• Service groups: For granting services and daemons specific access.

Key Files for User and Group Information

These files are central to understanding and troubleshooting user and group administration on a single system.

`/etc/passwd`

Stores basic user account information. Each line is one user, with fields separated by ::

username:x:UID:GID:comment:home_directory:login_shell

Example:

alice:x:1000:1000:Alice Smith:/home/alice:/bin/bash

Important details:

• UID: Numeric user ID. Critical for file ownership and process identity.
• GID: Primary group ID (links to /etc/group).
• home_directory: Where the user’s personal files live.
• login_shell: Program started at login (e.g. /bin/bash, /usr/bin/zsh, /usr/sbin/nologin).

The second field, often x, used to contain the encrypted password historically. Modern systems store password hashes in /etc/shadow instead.

`/etc/shadow`

Contains sensitive authentication information (password hashes and related data). Only root and certain privileged processes can read it.

Typical line format:

username:password_hash:last_change:min:max:warn:inactive:expire:reserved

You typically don’t edit this file by hand. Instead, you use tools like passwd, chage, or account management commands.

Key points:

• password_hash:
• ! or * or an empty value can indicate a locked account or no password.
• Hash format can show algorithm, e.g. $6$ for SHA‑512.
• min, max, warn and others relate to password aging/expiration, which you’ll use when setting policies.

`/etc/group`

Defines groups and their members. Format:

group_name:x:GID:user1,user2,user3

Example:

developers:x:1001:alice,bob

Important points:

• GID is used for file group ownership.
• The user list contains supplementary members. A user’s primary group is defined in /etc/passwd.

`/etc/gshadow` (if present)

Similar to /etc/shadow, but for groups. It can store group passwords (rarely used today) and is usually managed via group-related commands rather than manual editing.

UID and GID Management

Understanding and planning UID/GID ranges is important, especially when you manage multiple systems.

Common UID and GID Ranges

Typical conventions (exact numbers may vary by distribution):

• 0: root (superuser).
• 1–999 (or similar): System accounts/groups (services, daemons).
• 1000+ (or similar): Regular human users.

These ranges can vary (e.g. some systems start regular users at 500), but the idea is the same: low numbers are reserved for system use.

Why Consistent UIDs and GIDs Matter

Because ownership is stored by ID, not name:

• If alice is UID 1000 on machine A and 1001 on machine B, and you share files via NFS, she may not see correct permissions.
• For multi‑server environments, admins often maintain a central UID/GID policy or use directory services (LDAP/AD) so IDs line up.

On standalone machines, you mostly rely on the distribution’s defaults. On fleets of servers, you may need to explicitly assign UIDs/GIDs when creating accounts.

Creating and Managing Users

The main administrative tools for user management are:

• useradd / adduser (distribution-dependent).
• usermod.
• userdel.

Exactly which options exist can vary slightly between distros, so checking man pages on your system is important.

Creating a User with `useradd`

Basic automatic user creation (common syntax):

sudo useradd -m -s /bin/bash alice
sudo passwd alice

Key options you’ll commonly use:

• -m: Create the home directory if it doesn’t exist.
• -s SHELL: Set the login shell (e.g. /bin/bash, /bin/zsh, /usr/sbin/nologin).
• -u UID: Explicitly set UID (useful when coordinating with other machines).
• -g GID_or_NAME: Set the primary group (either existing group name or numeric GID).
• -G group1,group2: Add the user to supplementary groups.
• -d DIR: Use a custom home directory path.
• -c "Comment": Set the GECOS/comment field (often full name).

Example: Creating a User for a Human

sudo useradd -m -s /bin/bash -c "Alice Smith" -G wheel,developers alice
sudo passwd alice

• Creates /home/alice.
• Sets login shell to /bin/bash.
• Adds to supplementary groups wheel and developers (assuming they exist).
• Sets a password so the user can log in.

Example: Creating a Non‑Login (Service) User

sudo useradd -r -s /usr/sbin/nologin -d /var/lib/myapp -c "MyApp Service" myapp

Typical options for service accounts:

• -r: Create a system account (UID/GID from system range; behavior may vary by distro).
• -s /usr/sbin/nologin or /bin/false: Prevent interactive logins.
• Custom -d (home-like directory where the service stores data).
• Often no password set, or the account is locked.

Editing Users with `usermod`

Use usermod to change existing user attributes.

Common options:

• -l NEWNAME OLDNAME: Rename user.
• -u UID USER: Change UID (requires care).
• -g GROUP USER: Change primary group.
• -G groups USER: Set supplementary groups (this replaces the list).
• -aG groups USER: Add supplementary groups (without removing existing ones).
• -d DIR: Change home directory path (does not move files by default).
• -m: Used with -d to move home directory contents.
• -s SHELL: Change login shell.
• -L / -U: Lock/unlock password.

Examples

Add alice to extra groups:

sudo usermod -aG docker,developers alice

Change alice’s login shell:

sudo usermod -s /usr/bin/zsh alice

Move home directory to another path:

sudo usermod -d /srv/users/alice -m alice

Deleting Users with `userdel`

Two main ways to remove a user:

• Keep their home directory:

  sudo userdel alice

• Remove user and home directory:

  sudo userdel -r alice

Points to consider:

• Deleting a user does not automatically change ownership of their files outside their home directory. Such files will still be owned by the (now numeric) UID.
• On production systems, you often:
• Disable or lock accounts first.
• Archive or reassign home directories.
• Use tools like find to locate files owned by a particular UID and reassign or archive as needed.

Creating and Managing Groups

Group management uses:

• groupadd.
• groupmod.
• groupdel.
• gpasswd or usermod (for membership changes).

Creating Groups with `groupadd`

Basic group creation:

sudo groupadd developers

Useful options:

• -g GID: Set an explicit GID.
• -r: Create a system group (from system GID range).

Coordinating GIDs matters, just like UIDs, in multi‑machine setups.

Modifying Groups with `groupmod`

You can rename or change GID:

sudo groupmod -n devteam developers
sudo groupmod -g 2000 devteam

Be cautious with changing GIDs on a live system because existing files may still have the old GID set; you’ll need to adjust filesystem ownerships accordingly.

Adding and Removing Users from Groups

Two common approaches:

1. Using usermod:
• Add alice to developers:

     sudo usermod -aG developers alice

• Replace alice’s supplementary groups with a new list:

     sudo usermod -G developers,sysadmins alice

2. Using gpasswd:
• Add alice to developers:

     sudo gpasswd -a alice developers

• Remove alice from developers:

     sudo gpasswd -d alice developers

Choose whichever interface fits your habits; under the hood they adjust /etc/group (and /etc/gshadow when present).

Deleting Groups with `groupdel`

To delete a group:

sudo groupdel developers

Things to consider:

• Files with that GID remain with that numeric GID; if a new group is later created with the same GID, it will appear to own those files.
• Ensure no critical processes or services rely on the group before removal.

Default Settings for New Users

When you create a new user, the system uses several defaults:

• Default home directory base (e.g. /home).
• Default shell (e.g. /bin/bash).
• Default primary group.
• Default skeleton files (/etc/skel).

These are controlled by configuration and templates.

`/etc/default/useradd` (or Distribution Equivalent)

On many systems, useradd uses a config file (often /etc/default/useradd or /etc/login.defs) to get defaults such as:

• HOME=/home
• SHELL=/bin/bash
• Default UMASK.
• Whether to create the home directory by default.

Use useradd -D to view current defaults on many distributions.

`/etc/skel` — Skeleton Directory

When a user is created with -m, the contents of /etc/skel are copied into their new home directory.

• Typical contents: .bashrc, .profile, .bash_logout, and sometimes default config dirs.
• If you want all new users to start with a particular file or configuration, place it in /etc/skel.

Example:

sudo cp /path/to/custom/.bash_aliases /etc/skel/

Future users created with useradd -m will get this file copied into their home.

Managing Passwords and Account States

Beyond simply setting a password, you often need to lock/unlock accounts and manage password aging.

Setting and Changing Passwords with `passwd`

• Set a password for a new user:

  sudo passwd alice

• Force user to change password at next login:

  sudo passwd -e alice

• Lock a user’s password (prevents password-based login):

  sudo passwd -l alice

• Unlock password:

  sudo passwd -u alice

Locking with passwd -l modifies the password hash (prefixing it with ! in /etc/shadow).

Account Locking vs Password Locking

There are multiple ways to prevent a user from logging in:

• Lock password via passwd -l:
• Prevents password authentication, but other methods (e.g. SSH keys) might still work.
• Lock account with usermod -L:
• Similar effect at the password level for many systems, but semantics may differ slightly.
• Change shell to /usr/sbin/nologin or /bin/false:
• Blocks interactive shell access but may not block all forms of authentication.
• Disable account in /etc/shadow:
• For example, by setting an expire date or using chage (see below).

You can combine approaches depending on security requirements.

Password Aging with `chage`

chage interfaces with the password aging fields in /etc/shadow.

Common operations:

• Show password aging info:

  sudo chage -l alice

• Set maximum days between password changes (e.g. 90):

  sudo chage -M 90 alice

• Set minimum days between changes (prevent immediate reuse, e.g. 1):

  sudo chage -m 1 alice

• Set warning days before expiration (e.g. 7):

  sudo chage -W 7 alice

• Set account expiration date (after which login is disabled):

  sudo chage -E 2025-12-31 alice

Password and account policies are discussed in more depth in the dedicated Password Policies chapter; here you only need enough to manage individual accounts.

System vs Human Users

On a running system, you’ll see many accounts that never log in interactively.

Characteristics of System Accounts

Typically:

• UIDs in the system range (e.g. below 1000).
• No home directory or use system directories (e.g. /var/lib/service).
• Shell set to /usr/sbin/nologin or /bin/false.
• Often have locked or empty passwords.

Examples might include www-data (web server), postgres (database), or sshd.

When you install packages, they often create these accounts automatically. You should:

• Avoid giving these accounts passwords or interactive shells.
• Use them to run services with the least privileges needed.

Creating Custom Service Accounts

For your own services, it’s best practice to use a dedicated account instead of running as root.

Example:

sudo useradd -r -s /usr/sbin/nologin -d /var/lib/myapp -c "MyApp Service" myapp
sudo mkdir -p /var/lib/myapp
sudo chown myapp:myapp /var/lib/myapp

Then configure your service (e.g. in a systemd unit) to run as User=myapp and Group=myapp.

Inspecting and Querying Users and Groups

You’ll often need to check account details or find which groups a user belongs to.

Listing Users and Groups

• Show all user entries:

  getent passwd

• Show all group entries:

  getent group

getent is preferred over directly reading /etc/passwd or /etc/group because it works with centralized identity services too (LDAP, NIS, etc.), not just local files.

Checking a Single User

• Show alice’s entry:

  getent passwd alice

• Show groups for alice:

  groups alice
  id alice

id shows:

• UID and primary GID.
• Names and IDs of supplementary groups.

Checking File Ownership vs Users

Sometimes you need to correlate file ownership with accounts:

• Example: List files owned by a particular UID or username in a directory tree:

  sudo find / -uid 1005 -ls
  # or by name (resolved via current user database)
  sudo find / -user alice -ls

This is helpful when:

• You’ve removed a user but need to reassign their files.
• You’re standardizing UIDs across systems.

Handling Common Administrative Tasks

Here are some typical real-world tasks that tie concepts together.

Onboarding a New User

Example workflow for adding a new developer:

1. Create user with home directory and shell:

   sudo useradd -m -s /bin/bash -c "Jane Doe" jane

2. Set initial password and force change on first login:

   sudo passwd jane
   sudo passwd -e jane

3. Add to required groups:

   sudo usermod -aG developers,docker jane

4. Verify:

   id jane

Offboarding a User

Example workflow when a user leaves:

1. Lock the account immediately:

   sudo passwd -l jane
   # or
   sudo usermod -L jane

2. Optionally set an expire date in the near future:

   sudo chage -E 2025-01-01 jane

3. Archive home directory:

   sudo tar czf /var/archives/jane-home.tar.gz /home/jane

4. Reassign ownership of important files (if needed) to another user.
5. Remove the account and home directory once safe:

   sudo userdel -r jane

Converting a Regular Account into a Service Account

If a user account is no longer used interactively but needs to run background services:

1. Remove interactive shell:

   sudo usermod -s /usr/sbin/nologin serviceuser

2. Lock the password:

   sudo passwd -l serviceuser

3. Ensure the user owns only the directories needed for the service.

Integration with Centralized Authentication (High-Level)

While this chapter focuses on local user and group administration, it’s important to understand how it fits into larger setups:

• On systems integrated with LDAP, NIS, or Active Directory:
• Local accounts in /etc/passwd may coexist with remote accounts.
• getent shows combined results.
• UIDs/GIDs might come from the directory rather than local files.

Best practices in mixed environments:

• Reserve local UIDs/GIDs for actual local accounts or emergency admin users.
• Avoid UID/GID clashes with directory-provided identities.
• Use local groups for host-specific permissions, and directory groups for global roles where appropriate.

Details of configuring LDAP/AD and PAM are covered in other chapters, but everything you learned here about interpreting and managing local accounts still applies as a foundation.

Summary

In this chapter, you learned to:

• Understand where user and group information is stored (/etc/passwd, /etc/shadow, /etc/group, /etc/gshadow).
• Manage UIDs/GIDs and appreciate why consistency matters.
• Create, modify, and delete users and groups with tools like useradd, usermod, userdel, groupadd, and groupmod.
• Manage default settings for new users and use /etc/skel.
• Lock/unlock accounts and manage password aging using passwd and chage.
• Distinguish human accounts from system/service accounts and create dedicated service users.
• Query and audit user/group information with getent, id, groups, and find.

These skills form the core of day‑to‑day Linux system administration for handling identities and access control at the account level.