Account Creation, Locking, Expiration and Removal

An account is no longer needed. Locking its password, expiring the account, ending its sessions and deciding what happens to its files are separate actions. A safe lifecycle starts with a unique identity and ends with a verified disposition of access and data.

This lab uses a disposable full clone of bl02, named bl04-accounts-lab, with a separate disk and UEFI NVRAM. Use the powered-off virt-clone procedure from the bootloader chapter, confirm the original is off and the destination name and disk path are new, and attach the clone to blpractice. The clone retains the original guest’s hostname and credentials; identify it by its manager name and disk path and never run it concurrently with bl02. Keep the existing learner console and administrative access throughout. Do not run the account changes on a personal host or shared machine.

Plan the identity and its scope

The exercise creates one local user blstudent and one supplementary group blreviewers. This is a human-style test identity, not an administrative or service account. It has no deliberate sudo grant and no real data. Before creation, ensure both names are unused:

getent passwd blstudent
getent group blstudent
getent group blreviewers
test ! -e /home/blstudent

Each getent query should return no record and exit with status 2 for a missing key; the home-path test must succeed. Check each result separately. An error other than a missing key, an existing name, or a remote identity source you do not understand is a stop condition. Inspect /etc/nsswitch.conf as in the previous chapter; a local tool may not know every remote identity that could later appear. Choose a different lab name rather than reusing an existing identity.

Record the available console and baseline. Before real provisioning, also specify a unique numeric UID/GID policy, identity authority, ownership scope, expiration, credentials, approval and recovery owner. Default automatic UID allocation in this disposable lab is not a fleet-wide identity plan.

Create and verify

Ubuntu provides the interactive adduser tool; this lab uses explicit lower-level useradd options so the intended home and shell are visible. The useradd manual describes the options and notes Debian-family preferences.

sudo useradd -m -U -s /bin/bash blstudent &&
  sudo passwd blstudent &&
  sudo groupadd blreviewers &&
  sudo usermod -aG blreviewers blstudent

The && operators stop the sequence if a command fails. If it stops, inspect the partial state before retrying. -m requests a home, -U a same-named private group, and -s the login shell. Enter a unique disposable password at the interactive prompts; do not place it in the command line or record it in notes. -aG appends a supplementary group. Using -G without -a can replace the supplementary group list; the usermod manual documents that distinction.

Inspect the result:

getent passwd blstudent
getent group blreviewers
id blstudent
sudo passwd -S blstudent
ls -ldn /home/blstudent

Record the observed UID, primary GID, supplementary group and home ownership. Verify a new session from the learner console:

su - blstudent

Authenticate with the lab user’s password. In the new shell run id, pwd and exit. The group should appear in the new process credentials and the home should be usable. If su fails, retain the error and inspect the account, password state, shell and local authentication policy; do not grant sudo or edit protected databases by hand. A new group entry is not proof that an existing session received the group.

Lock, expire and recover deliberately

A password lock disables that local password as an authentication method. It is not a universal account disable: an existing session or a different authentication method may still work. Account expiration is a separate account-policy input, and services can interpret policy differently. The passwd manual describes password lock and status.

With the blstudent session exited and the learner administrator session retained:

sudo passwd -l blstudent
sudo passwd -S blstudent

The status should indicate a locked password. From the ordinary learner shell, an attempted su - blstudent using the previously working password should fail under the lab’s local policy. Do not run this test through sudo, which uses a different authorization path. If the test behaves differently, preserve the evidence and stop rather than assuming the account has no access. Restore the prior usable password state for this known lab account:

sudo passwd -u blstudent
sudo passwd -S blstudent

Unlocking is appropriate here because the account had a working password before the lock. It is not a general instruction to unlock unknown accounts or create passwordless access.

Demonstrate an expired account with an explicit past date, then remove that expiration:

sudo usermod --expiredate 1970-01-02 blstudent
sudo chage -l blstudent
sudo usermod --expiredate '' blstudent
sudo chage -l blstudent

Read the displayed account-expiration field after each step. Expiration and password locking are distinct controls; neither command proves existing sessions have ended. These changes affect only the test user, never learner.

Revoke membership and retire the test user

Remove the test user’s supplementary membership and check the database view:

sudo gpasswd -d blstudent blreviewers
id blstudent
getent group blreviewers

Previously running processes may retain old credentials. For a real departure, coordinate session termination, remote keys, tokens, scheduled jobs, application accounts and service ownership as applicable. Changing a local group list alone is not complete revocation.

Before deleting the lab account, make sure no blstudent session remains and record its UID and home path. Remove only the account record, leaving its home as evidence:

sudo userdel blstudent
getent passwd blstudent
ls -ldn /home/blstudent

The lookup should no longer return the local account; check its exit status. The numeric owner on the retained home illustrates that deleting a name does not remove every file. A different NSS source with the same name would complicate this result; stop if one appears. userdel may also remove the user’s private group according to local policy. It does not establish that files outside the home, jobs or credentials elsewhere have been handled. The userdel manual describes its scope.

After confirming blreviewers has no other intended members or use, remove this lab-only group:

getent group blreviewers
sudo groupdel blreviewers
getent group blreviewers

Do not use forced deletion or reuse the old UID while retained files remain. Keep the home and its ownership record on this disposable clone until a deliberate cleanup or retirement. Shut the clone down before returning to the original guest. A real account removal requires an explicit data retention, ownership transfer and credential-revocation plan.

Diagnose and recall

If creation fails, distinguish an existing name, unavailable identity source, occupied home path and insufficient privilege. If a login fails, distinguish lookup, password state, expiration, shell and session policy. If access persists after revocation, inspect the running process credentials and other authentication paths. Preserve a separate administrator and console recovery path throughout.

• Create identities only after checking name, numeric ownership and source authority.
• Append supplementary groups intentionally; verify a new session’s credentials.
• Password lock, account expiration and session termination are different controls.
• Deleting an account does not decide what happens to its files or external credentials.