🔄 Topic

I turned a Google Cybersecurity Certificate Linux activity into a blog-ready lab: creating a user, assigning groups, changing file ownership, adding secondary access, deleting the user, and cleaning up leftover groups.

🎯 Goal

Practice the basic Linux account lifecycle as an access-control workflow: onboarding, role assignment, ownership transfer, role change, offboarding, and cleanup.

🛠 What I Did

The lab followed a small but realistic account-management scenario.

Main areas covered:

  • created a new Linux user with useradd
  • assigned the user to the correct primary group with usermod -g
  • changed ownership of a project file with chown
  • added the user to a secondary group with usermod -a -G
  • deleted the user with userdel
  • removed the leftover group with groupdel
  • documented common command-line mistakes from the session
  • created the lab write-up as Lab 06 / Day 155
  • verified the Jekyll front matter and confirmed the site builds with the correct Ruby version

🔗 Key Cybersecurity Connections

User and group management is identity and access management at the operating-system level. The commands are simple, but the security idea is serious: access should follow a person’s role, and access should disappear when the role ends.

The lab also showed how easy it is to make small syntax mistakes that change or break an administrative command. In real environments, that is why verification commands such as id, ls -l, and careful review matter.

🔍 Investigation Questions

  • Does the user have the correct primary group?
  • Was file ownership transferred to the right account?
  • Was secondary access appended instead of replacing existing groups?
  • Did offboarding remove the account and unnecessary leftover group?
  • Can I explain the security meaning of each command, not just type it?

🚨 Detection Opportunities

Potential checks in a Linux environment:

  • user account exists after offboarding should be complete
  • user has unexpected supplementary groups
  • project file owner does not match the responsible user
  • leftover personal group remains after account deletion
  • command history shows repeated failed administrative attempts that may need review

Example:

system=linux-lab
signal=offboarded_user_still_present
risk_area=identity_and_access_management
triage=check_passwd_group_membership_and_file_ownership

🧭 MITRE ATT&CK Techniques

Relevant defensive framing:

  • T1078 — Valid Accounts: attackers benefit from accounts that remain active or over-permissioned
  • T1098 — Account Manipulation: understanding legitimate account changes helps recognize suspicious ones

🗺 Visual Investigation Diagram

New employee joins
    ↓
Create user
    ↓
Assign primary group
    ↓
Transfer project ownership
    ↓
Add secondary group for changed role
    ↓
Delete user when they leave
    ↓
Remove leftover group

⚠ Challenges

The mistakes were small but instructive: missing spaces, wrong group names, and incorrect usermod flag syntax. The shell does not guess intent. It does exactly what was typed or fails bluntly.

📚 What I Learned

I learned to see Linux user commands as more than memorized syntax. They are a practical way to implement authorization decisions and clean up access when business context changes.

➡ Next Steps

  • Keep building lab posts from certificate activities
  • Add verification commands after every administrative change
  • Practice reading /etc/passwd, /etc/group, and file permission output more fluently
  • Connect Linux account lifecycle tasks to IAM concepts used in cloud and enterprise environments

🧠 Reflection

This was a good “back to fundamentals” day. The flashy agent work is fun, but the basics — users, groups, ownership, cleanup — are still the bones of access control.

🧩 Lessons Learned

What worked

Turning a simple course activity into a structured lab with security meaning.

What broke

A few shell commands failed because of spacing, naming, or flag syntax mistakes.

Why it broke

Linux commands are literal and case-sensitive; small syntax changes matter.

Fix / takeaway

Administrative actions need verification, especially when they change identity, group membership, or file ownership.

📈 Skill Progression Context

This supports my cybersecurity progression because Linux user and group management is foundational for understanding access control, privilege, and account lifecycle risk.

😄 TL;DR

Practiced Linux user/group management as a real access-control workflow: onboard, assign access, transfer ownership, change roles, offboard, and clean up.