Lab Objective

Practice the basic Linux account lifecycle from a security analyst point of view:

  • create a new user
  • assign the user to the correct primary group
  • transfer ownership of a project file
  • add the user to a secondary group when their role changes
  • remove the user and clean up the leftover group

The technical commands are simple, but the security idea is important: access should follow the user’s current role, and it should be removed when the role or employment relationship ends.

Lab Environment

  • Course: Google Cybersecurity Certificate
  • Activity: Add and manage users with Linux commands
  • Shell: Linux Bash
  • Starting user: analyst
  • Target user: researcher9
  • Primary group: research_team
  • Secondary group: sales_team
  • Project file: /home/researcher2/projects/project_r.txt

All administrative commands in this lab require sudo because user, group, and ownership changes affect the system, not just the current shell session.

Scenario

A new employee joins the Research department with the username researcher9.

At first, they only need Research access. Later, their role expands and they also need Sales access. Eventually, they leave the organization and their account must be removed.

This is a small version of a real identity and access management workflow:

  1. onboarding
  2. role assignment
  3. ownership transfer
  4. role change
  5. offboarding
  6. cleanup

Commands Practiced

Command Purpose
useradd Create a new Linux user account
usermod -g Set a user’s primary group
chown Change file ownership
usermod -a -G Add a user to a supplementary group
userdel Delete a user account
groupdel Delete an unused group

Step 1 - Add the New User

The first task was to create the new employee account:

sudo useradd researcher9

Then I assigned researcher9 to the Research department group as their primary group:

sudo usermod -g research_team researcher9

What This Means

The primary group is the user’s default group identity. Files created by the user are usually associated with this group unless another rule changes that behavior.

From an access-control perspective, this matters because group membership is one of the main ways Linux decides what a user can read, write, or execute.

Step 2 - Assign Project File Ownership

The new employee became responsible for project_r, so the project file needed a new owner:

sudo chown researcher9 /home/researcher2/projects/project_r.txt

Why This Matters

Ownership is not just a label. On Linux, ownership affects who can control a file, especially when combined with permission bits.

This is a practical authorization task:

  • the employee needs responsibility for the project file
  • the system must reflect that responsibility
  • the previous owner should not remain the owner only because nobody updated the file metadata

Useful verification command:

ls -l /home/researcher2/projects/project_r.txt

The owner field should show researcher9.

Step 3 - Add the User to a Secondary Group

Later, the employee starts working with both Research and Sales. Their primary group remains research_team, but they also need access through sales_team.

The correct command is:

sudo usermod -a -G sales_team researcher9

Important Detail

The flags are case-sensitive:

  • -a means append
  • -G specifies supplementary groups

The -a flag matters because without it, a usermod -G command can replace the user’s existing supplementary group list instead of adding to it.

Useful verification command:

id researcher9

The output should show research_team as the primary group and sales_team as an additional group.

Step 4 - Delete the User

When researcher9 leaves the organization, the account should no longer exist:

sudo userdel researcher9

The lab expects a message like this:

userdel: group researcher9 not removed because it is not the primary group of user researcher9.

That message is not a failure. It happens because Linux may create a same-named group when a user is created. Since the user’s primary group was changed to research_team, the leftover researcher9 group is no longer the user’s primary group.

The cleanup command is:

sudo groupdel researcher9

Security Meaning

Offboarding is not complete when the user stops working at the company. The account and unnecessary access artifacts must be removed from the system.

Leftover accounts and groups create confusion. In worse cases, they can become access paths that nobody remembers to review.

Mistakes I Made and Fixed

This lab was useful because a few small command-line mistakes appeared immediately.

Mistake 1 - Missing Space Between Username and Command

I accidentally typed a username and command together:

researcher9sudo chown /home/researcher2/projects/project_r.txt researcher9

Bash interpreted researcher9sudo as the command name and returned:

command not found

Fix:

sudo chown researcher9 /home/researcher2/projects/project_r.txt

Lesson: the shell is literal. If spacing is wrong, Bash does not infer what I meant.

Mistake 2 - Wrong Group Name

I tried:

sudo usermod -g salesteam researcher9

The system replied that salesteam did not exist. The correct group name was sales_team with an underscore.

Fix:

sudo usermod -a -G sales_team researcher9

Lesson: exact names matter in access control. A missing underscore means a different identity object.

Mistake 3 - Incorrect usermod Option Syntax

I typed:

sudo usermod -a G sales_team researcher9

This caused usermod to print its usage help because G was not passed as the -G option.

Fix:

sudo usermod -a -G sales_team researcher9

Lesson: Linux command options are strict, and capitalization matters.

Cybersecurity Relevance

This lab connects directly to identity and access management.

In a real organization, defenders care about these questions:

  • Who has an account?
  • Which groups is the account in?
  • Which files and systems can the account access?
  • Was access updated when the user’s job changed?
  • Was access removed when the user left?

The commands in this lab are basic, but the workflow is the foundation of least privilege.

Bad access hygiene often starts with boring mistakes: old accounts, stale groups, wrong ownership, and users keeping access after changing roles. Linux gives analysts direct ways to inspect and correct those issues.

Key Takeaways

  • sudo is required for account and group administration because these changes affect the whole system.
  • useradd creates the account, but the account still needs the correct group context.
  • usermod -g changes the primary group.
  • usermod -a -G adds supplementary groups without removing existing ones.
  • chown changes file ownership and should match operational responsibility.
  • userdel removes the user account, but cleanup may still be needed with groupdel.
  • Tiny syntax mistakes are part of learning Linux; the important part is reading the error and correcting the command carefully.

Reflection

This lab made access management feel less abstract. Authentication proves who a user is, but authorization decides what that user can touch after logging in.

Creating researcher9, moving them into the correct groups, assigning project ownership, and then deleting the account showed the full lifecycle in miniature. The commands were short, but each one represented a security decision.

The biggest lesson was that access control is operational discipline. If the user’s role changes, the system has to change too.