Creating and modifying user accounts

Why this matters

Account management is the most routine thing a Linux administrator does, and the place where sloppiness turns into an audit finding. Every account is a way in. Every account left behind after someone leaves is a way in that nobody is watching.

The commands are simple. What the exam actually tests is whether you know the difference between the low-level tool and the friendly wrapper, and whether you understand that locking an account and expiring an account are different things that fail in different ways.

The lesson

Three kinds of account

Before the commands, the distinction that shapes everything else.

User accounts belong to people. They have a home directory, a login shell, a password, and a UID at or above 1000 on most systems.

System accounts exist for the operating system itself — daemon, bin, sys. They are created by the distribution, have UIDs below 1000, and usually have /usr/sbin/nologin or /bin/false as their shell so nobody can log in as them.

Service accounts run a particular service — nginx, postgres, mysql. They exist so that a compromised web server does not have root's privileges. They also carry a non-login shell and typically no password at all.

The rule that follows: a service account should never be able to log in. If nginx has /bin/bash as its shell, that is a finding. The reason accounts have shells like nologin is not tidiness; it is containment.

Creating accounts

There are two layers, and knowing which is which is exam material.

useradd is the low-level tool. It does exactly what you tell it and nothing more — on many distributions it will not even create a home directory unless you ask.

useradd alice                          # minimal; often no home directory
useradd -m alice                       # -m creates /home/alice
useradd -m -s /bin/bash alice          # set the login shell
useradd -m -c "Alice Smith" alice      # comment/full name field
useradd -m -G sudo,developers alice    # supplementary groups
useradd -u 1500 -m alice               # choose the UID
useradd -r -s /usr/sbin/nologin svcapp # system/service account
useradd -e 2027-03-31 -m contractor    # account expiry date

adduser is a friendlier wrapper. On Debian and Ubuntu it is an interactive Perl script that creates the home directory, sets up the group, copies the skeleton files and prompts for a password. On Red Hat systems adduser is simply a symlink to useradd, so it behaves quite differently.

That asymmetry is worth remembering: a script written on Ubuntu using adduser interactively will not behave the same way on RHEL.

Creating a group is the same pattern:

groupadd developers
groupadd -g 5000 developers    # with a specific GID

New accounts have no usable password until you set one:

passwd alice      # prompts twice

Until then the account exists but cannot authenticate — which is by design, and is why a freshly created user "cannot log in".

Modifying accounts

usermod changes an existing account, and one flag on it causes more accidental damage than any other in this lesson.

usermod -s /bin/zsh alice          # change login shell
usermod -c "Alice Jones" alice     # change the comment field
usermod -l alicej alice            # rename the login
usermod -d /home/alicej -m alicej  # move the home directory too
usermod -L alice                   # LOCK the account
usermod -U alice                   # unlock
usermod -aG docker alice           # APPEND to supplementary groups
usermod -G docker alice            # REPLACE all supplementary groups

usermod -G without -a replaces every supplementary group the user has. Run usermod -G docker alice on an administrator and you have just removed them from sudo. The habit to build is that -aG is the normal form and plain -G is the exception you write deliberately.

Note also that usermod -l renames the login but does not rename the home directory or the primary group — you have to do those yourself with -d -m.

Two smaller tools do one job each:

chsh -s /bin/zsh alice     # change shell; a user may run this on themselves
groupmod -n devs developers   # rename a group
groupmod -g 5001 developers   # change its GID

Locking, expiring, and the difference

These are constantly confused, and they behave differently under key-based login — which is exactly why the distinction is examined.

Locking disables password authentication by prefixing the password hash in /etc/shadow with !. The hash is preserved, so unlocking restores the old password.

usermod -L alice     # lock
passwd -l alice      # the same thing
usermod -U alice     # unlock
passwd -u alice      # the same thing
passwd -S alice      # status: shows L (locked), P (usable password), NP (none)

Expiring disables the account itself, regardless of authentication method.

chage -E 2026-12-31 contractor   # account expires on this date
chage -E -1 contractor           # never expires
usermod -e 2026-12-31 contractor # the same, via usermod

The trap: locking only blocks the password. A user with an SSH key in ~/.ssh/authorized_keys can still log in to a locked account, because the key never touches the password hash. To stop someone completely you must expire the account, change the shell to nologin, or remove their key — and in practice you do all three.

Password ageing

chage manages the policy attached to a password.

chage -l alice                 # list every ageing setting
chage -M 90 alice              # must change at least every 90 days
chage -m 7 alice               # cannot change again within 7 days
chage -W 14 alice              # warn 14 days before expiry
chage -I 30 alice              # disable 30 days after password expires
chage -d 0 alice               # force a password change at next login

chage -d 0 is the one you will reach for most: it sets the last-change date to the epoch, so the password is immediately considered expired and the user must set a new one when they next log in. That is how you hand over a temporary password safely.

Defaults for new accounts live in /etc/login.defs (PASS_MAX_DAYS, PASS_MIN_DAYS, PASS_WARN_AGE) and /etc/default/useradd (default shell, home directory base, skeleton directory). Changing them affects accounts created afterwards, not existing ones.

Deleting accounts

userdel alice          # remove the account, LEAVE the home directory
userdel -r alice       # remove the account AND /home/alice and their mail spool
deluser alice          # Debian wrapper
deluser --remove-home alice
groupdel developers    # remove a group

userdel without -r leaves the home directory owned by a now-unused UID. That matters more than it sounds: create the next user and they may inherit that UID, and with it read access to the departed employee's files.

groupdel refuses to remove a group that is any user's primary group. Change those users' primary group first.

For a departing employee, expiring is often safer than deleting — it preserves file ownership and audit trails while stopping access immediately, and you can delete later once you are sure nothing depended on the account.

On the exam

• usermod -aG appends; usermod -G replaces. Expect a scenario where the missing -a removes someone from sudo.
• Locking blocks password login only; SSH keys still work. Expiring stops the account entirely.
• useradd is low-level and may not create a home directory; -m does. adduser is an interactive wrapper on Debian and a symlink to useradd on Red Hat.
• userdel -r removes the home directory; plain userdel does not.
• chage -d 0 forces a password change at next login.
• UID below 1000 means a system account; 1000 and above means a human.
• Service accounts should have nologin or /bin/false as their shell.