Lab 03 — Linux IAM

Linux security begins with a fundamental question:

Who Can Access
the System?

But enterprise Identity and Access Management goes further:

WHO
   ↓
Can Access
   ↓
WHAT
   ↓
Using Which
PRIVILEGES
   ↓
Under Which
CONDITIONS

In this lab, you will build a practical Linux IAM environment and learn how Linux controls identities, groups, permissions, administrative privileges, service accounts, and remote access.

Mission Information

Lab: Linux IAM
Level: Intermediate
Estimated Time: 120–180 minutes
Environment: Authorized disposable Linux VM
Primary Role: Linux Security Administrator
Secondary Roles: Cloud Security Engineer, SOC Analyst, IAM Engineer, DevSecOps Engineer

Mission Scenario

Your organization is preparing a Linux server for three teams:

Developers

Operations

Security

The security team has asked you to design and validate access according to least privilege.

The requirements are:

Developers
      ↓
Access Development Files

Operations
      ↓
Perform Approved Administration

Security
      ↓
Read Security Evidence

Applications
      ↓
Use Dedicated Service Identity

Users must not receive unnecessary access simply because it is convenient.

Your mission is to implement:

Identity
   ↓
Group Membership
   ↓
Resource Ownership
   ↓
Permissions
   ↓
ACL
   ↓
Administrative Privilege
   ↓
SSH Access
   ↓
Audit and Review

Learning Objectives

By completing this lab, you should be able to:

Understand Linux identities
Explain UID and GID
Review local accounts
Create and manage users
Create and manage groups
Design role-based group membership
Manage account lifecycle
Review password and aging controls
Lock and unlock training accounts
Understand file ownership
Configure standard Linux permissions
Understand special permissions
Configure Access Control Lists
Review sudo access
Apply least privilege to administrative access
Understand service accounts
Review SSH-key-based access
Identify orphaned or excessive access
Perform a privileged-access review
Produce an IAM assessment report

Lab Architecture

                     Linux Server
                          |
          +---------------+---------------+
          |               |               |
          v               v               v
     Developers       Operations       Security
          |               |               |
          v               v               v
      devteam           opsadmin         secteam
          |               |               |
          +---------------+---------------+
                          |
                          v
                   Linux Resources
                          |
          +---------------+---------------+
          |               |               |
          v               v               v
        Files          Services          Logs

IAM Mental Model

Use this model throughout the lab:

IDENTITY
   ↓
AUTHENTICATION
   ↓
GROUP / ROLE
   ↓
AUTHORIZATION
   ↓
RESOURCE
   ↓
AUDIT

Authentication vs Authorization

Do not confuse these concepts.

Authentication

Answers:

Who Are You?

Examples:

Password

SSH Key

Central Identity

MFA

Authorization

Answers:

What Are You
Allowed to Do?

Examples:

File Permissions

Group Membership

ACL

sudo

Application Roles

Part 01 — Prepare the Lab

Create a workspace:

mkdir -p ~/linux-iam-lab

Enter it:

cd ~/linux-iam-lab

Create:

mkdir evidence reports

Step 01 — Confirm Your Identity

Run:

whoami

Then:

id

Record:

Username:

UID:

Primary GID:

Supplementary Groups:

Administrative Access:

Step 02 — Review Current Users

Run:

getent passwd

Each account generally contains information representing:

Username
   ↓
UID
   ↓
Primary GID
   ↓
Description
   ↓
Home Directory
   ↓
Login Shell

`/etc/passwd`

You can inspect:

cat /etc/passwd

Despite its name, modern Linux systems do not normally store plaintext passwords here.

Step 03 — Inspect Your Own Account

Run:

getent passwd "$(whoami)"

Record:

Username:

UID:

GID:

Home Directory:

Shell:

Part 02 — Understand UID

Linux internally identifies users primarily through:

UID

not simply usernames.

Conceptually:

Username
   ↓
UID
   ↓
Linux Kernel

A username is a human-friendly representation of an identity.

Step 04 — Review UID Values

Run:

getent passwd | cut -d: -f1,3

Observe:

Username:UID

Do not assume specific UID ranges without checking your distribution’s configuration.

Security Principle

The critical question is not:

Does the Username
Look Like root?

but:

Which UID
Does the Account Have?

Step 05 — Identify UID 0 Accounts

Run:

awk -F: '$3 == 0 {print $1 ":" $3 ":" $7}' /etc/passwd

UID:

represents root-level identity.

Any unexpected UID 0 account requires investigation.

Finding Example

Finding:
Unexpected UID 0 Account

Observation:
An account other than the expected root
identity is configured with UID 0.

Risk:
The account effectively possesses
root-level operating-system identity.

Recommendation:
Validate the business requirement,
account ownership, authentication
controls, and remove unnecessary UID 0
assignments through the approved
change process.

Part 03 — Understand GID

Groups are identified through:

GID

Review:

getent group

For your identity:

id

You may have:

Primary Group

Supplementary Groups

Group-Based Access Model

Instead of:

Give User A Access

Give User B Access

Give User C Access

prefer:

Resource
   ↓
Group
   ↓
Approved Users

This becomes easier to administer and audit.

Part 04 — Create Training Groups

Create three training groups:

sudo groupadd devteam
sudo groupadd opsadmin
sudo groupadd secteam

Verify:

getent group devteam
getent group opsadmin
getent group secteam

Group Purpose

devteam
   ↓
Development Resource Access

opsadmin
   ↓
Approved Operational Administration

secteam
   ↓
Security Resource Access

Part 05 — Create Training Users

Create:

sudo useradd -m alice
sudo useradd -m bob
sudo useradd -m charlie

Verify:

getent passwd alice
getent passwd bob
getent passwd charlie

User Roles

Assign:

Alice
   ↓
Developer

Bob
   ↓
Operations Administrator

Charlie
   ↓
Security Analyst

Step 06 — Inspect Identities

Run:

id alice
id bob
id charlie

Record their:

UID

Primary GID

Supplementary Groups

Part 06 — Assign Group Membership

Add Alice:

sudo usermod -aG devteam alice

Add Bob:

sudo usermod -aG opsadmin bob

Add Charlie:

sudo usermod -aG secteam charlie

Validate:

id alice
id bob
id charlie

Important Command Lesson

When modifying supplementary groups, understand the difference between:

Replace Membership

and:

Append Membership

The -aG pattern is commonly used to append supplementary group membership.

Accidentally replacing groups can remove required access.

Part 07 — Create an IAM Matrix

Document:

User	Role	Required Group	Admin Required
Alice	Developer	devteam	No
Bob	Operations	opsadmin	Limited
Charlie	Security Analyst	secteam	No

This is your:

Expected IAM State

Later you will compare it against:

Actual IAM State

Part 08 — Account Lifecycle

Every account should have a lifecycle:

REQUEST
   ↓
APPROVE
   ↓
CREATE
   ↓
ASSIGN ACCESS
   ↓
REVIEW
   ↓
MODIFY
   ↓
DISABLE
   ↓
REMOVE

Security Problem

Many organizations perform:

CREATE

very well.

But forget:

REVIEW

and:

REMOVE

This creates:

Orphaned Accounts

Excessive Access

Privilege Accumulation

Part 09 — Review Password State

For authorized training accounts, inspect account information.

Example:

sudo chage -l alice

Review concepts such as:

Password Change

Expiration

Minimum Age

Maximum Age

Warning Period

Important

Do not apply arbitrary password-aging values simply because a generic benchmark recommends them.

Follow:

Organization Policy

Authentication Architecture

Risk Requirements

Part 10 — Account Locking

Suppose Alice temporarily leaves the project.

You may need:

Disable Access

without:

Delete Identity

In an authorized lab, you can explore account-locking mechanisms appropriate to your distribution.

The important concept is:

Temporary Access Removal
      ≠
Immediate Account Deletion

Why Preserve Accounts?

During:

Employee Leave

Incident Investigation

Legal Hold

Access Review

preserving identity records may be important.

Part 11 — Account Expiration

Temporary users may require:

Automatic Expiration

Examples include:

Contractors

Temporary Administrators

Project Staff

Vendor Accounts

The preferred model is:

Access Needed Until Date X
      ↓
Account Expires Automatically

rather than:

Someone Will Remember
to Remove It Later

Part 12 — Service Accounts

Applications and services may require dedicated identities.

Create a harmless training system account:

sudo useradd --system --shell /usr/sbin/nologin ghcapp

On some distributions the nologin path may differ.

Verify:

getent passwd ghcapp

Service Account Model

Application
   ↓
Dedicated Identity
   ↓
Minimum Required Access

Avoid:

Application
   ↓
root

unless there is a legitimate technical requirement that cannot be safely reduced.

Service Account Questions

For every service account ask:

Which Application Owns It?

Does It Need Interactive Login?

Which Files Does It Need?

Which Services Does It Access?

Does It Need sudo?

Who Reviews It?

Part 13 — Create Protected Resources

Create training directories:

sudo mkdir -p /srv/ghc/dev
sudo mkdir -p /srv/ghc/security
sudo mkdir -p /srv/ghc/application

Desired Access

/srv/ghc/dev
      ↓
devteam

/srv/ghc/security
      ↓
secteam

/srv/ghc/application
      ↓
ghcapp

Part 14 — Configure Development Ownership

Run:

sudo chown root:devteam /srv/ghc/dev

Then:

sudo chmod 2770 /srv/ghc/dev

Review:

ls -ld /srv/ghc/dev

Why `2`?

The leading:

sets SGID on the directory.

For shared directories, this can help newly created entries inherit the directory’s group ownership.

Desired Model

Development Directory
      ↓
Group = devteam
      ↓
Development Collaboration

Part 15 — Configure Security Directory

Run:

sudo chown root:secteam /srv/ghc/security

Then:

sudo chmod 2750 /srv/ghc/security

Interpret:

Owner
   ↓
Full Access

Group
   ↓
Read + Traverse

Others
   ↓
No Access

Part 16 — Configure Application Directory

Assign the training service account:

sudo chown ghcapp:ghcapp /srv/ghc/application

Apply restrictive permissions:

sudo chmod 750 /srv/ghc/application

Verify:

ls -ld /srv/ghc/application

IAM Principle

Permissions should follow:

Resource Requirement
      ↓
Identity
      ↓
Minimum Necessary Access

Part 17 — Test Access

Do not assume configuration works because:

chmod Succeeded

Validate actual access.

Use approved methods to test your training identities.

For example:

sudo -u alice ls /srv/ghc/dev

Test Charlie:

sudo -u charlie ls /srv/ghc/security

Then test whether Alice can access the security directory:

sudo -u alice ls /srv/ghc/security

If your permissions are working as designed, unauthorized access should fail.

Validation Model

AUTHORIZED USER
      ↓
ACCESS SUCCEEDS

UNAUTHORIZED USER
      ↓
ACCESS DENIED

Both tests matter.

Part 18 — Understand File Permissions

Linux discretionary permissions use:

OWNER

GROUP

OTHERS

with:

READ

WRITE

EXECUTE

Numeric Values

Read    = 4

Write   = 2

Execute = 1

Examples:

700
→ Owner only

750
→ Owner full
→ Group read/execute

770
→ Owner and group full

640
→ Owner read/write
→ Group read

Security Warning

Avoid using:

as a generic fix for:

Permission Denied

This usually solves the symptom by creating a larger access problem.

Part 19 — Troubleshoot Permission Denied

Use:

USER
   ↓
GROUPS
   ↓
FILE OWNER
   ↓
FILE GROUP
   ↓
FILE PERMISSIONS
   ↓
PARENT DIRECTORY
   ↓
ACL
   ↓
SELINUX / APPARMOR

Example Commands

id alice

ls -ld /srv/ghc/dev

namei -l /srv/ghc/dev

where namei is available.

This helps identify permission problems across the directory path.

Part 20 — Access Control Lists

Traditional permissions sometimes cannot express a business requirement cleanly.

Suppose:

Security Directory
      ↓
secteam Has Access

but Bob requires temporary read access without joining the security team.

This is where:

ACL

may help.

Step 07 — Check ACL Support

Where ACL utilities are installed:

getfacl /srv/ghc/security

Step 08 — Grant a Training ACL

In your authorized lab:

sudo setfacl -m u:bob:rx /srv/ghc/security

Review:

getfacl /srv/ghc/security

Test

sudo -u bob ls /srv/ghc/security

IAM Meaning

Bob now has:

Specific Access

without:

Permanent secteam Membership

Part 21 — Remove Temporary ACL

After testing:

sudo setfacl -x u:bob /srv/ghc/security

Verify:

getfacl /srv/ghc/security

Then test again.

Access Lifecycle

Grant
   ↓
Use
   ↓
Review
   ↓
Revoke

Revocation is just as important as granting access.

Part 22 — Default ACLs

Shared directories may require inherited access.

Conceptually:

Parent Directory ACL
      ↓
New Files
      ↓
Expected Access

Default ACLs can help implement this.

However, they must be designed carefully to avoid granting unintended permissions to future files.

Part 23 — Review ACLs Professionally

ACLs create flexibility but can make access harder to understand.

When investigating permissions, never stop at:

ls -l

Also consider:

ACL

SELinux

AppArmor

Application-Level Authorization

Part 24 — sudo

Linux administrators frequently use:

sudo

to perform privileged operations.

The objective is not:

Everyone Is Root

The objective is:

Approved User
      ↓
Approved Administrative Action
      ↓
Auditable Privilege

Step 09 — Review Current sudo Access

Run:

sudo -l

Understand what your own lab account is authorized to perform.

Part 25 — Review sudo Configuration

Important locations may include:

/etc/sudoers

/etc/sudoers.d/

Never casually edit the main sudo configuration with an ordinary editor.

Use:

visudo

for validated changes.

Part 26 — Least-Privilege sudo Design

Suppose Bob’s role is:

Operations

That does not automatically mean:

Bob Needs Every Root Capability

Ask:

Which Tasks?

Which Commands?

Which Servers?

Which Time Period?

Which Approval?

Poor Model

Operations User
      ↓
Unlimited root

Better Model

Operations User
      ↓
Required Administrative Capability
      ↓
Controlled sudo
      ↓
Logging

Important Security Note

Command-level sudo restrictions can be complex.

Some apparently limited commands may allow shell escapes, file modification, or indirect privilege escalation.

Therefore enterprise sudo policy requires careful design and testing.

Part 27 — sudo Logging

Administrative activity should be observable.

Review authentication and privilege-related logs appropriate to your distribution.

Possible locations include:

systemd Journal

/var/log/auth.log

/var/log/secure

Security Question

Can you answer:

Who Used Privilege?

When?

From Where?

What Happened?

Part 28 — SSH Identity

Remote Linux access often combines:

Linux Account
      +
SSH Authentication

SSH keys provide:

Public Key

Private Key

The private key must remain protected by its owner.

SSH Authentication Model

Client
   |
   | Proves possession
   | of private key
   v
Server
   |
   | Matches approved
   | public key
   v
Linux Account

Part 29 — Generate a Training SSH Key

On your authorized lab workstation or disposable environment:

ssh-keygen -t ed25519

Follow your environment’s secure key-handling process.

Prefer a meaningful file name rather than overwriting an existing identity.

Critical Rule

Never share:

Private Key

The public key is designed to be distributed to systems that authorize that identity.

Part 30 — Review `.ssh`

For your own account:

ls -ld ~/.ssh

Then:

ls -la ~/.ssh

Do not display private key contents.

SSH IAM Review

Ask:

Which Keys Are Authorized?

Who Owns Them?

Are Any Shared?

Are Old Keys Present?

Can Keys Be Revoked?

Are Permissions Appropriate?

Part 31 — `authorized_keys`

Authorized public keys are commonly associated with:

~/.ssh/authorized_keys

Treat this file as:

Access Control Configuration

because adding a public key may grant remote access to the account.

Finding Example

Finding:
Unmanaged SSH Key

Observation:
An SSH public key is authorized for a
privileged Linux account but ownership
and business justification cannot be
confirmed.

Risk:
An unknown or former key owner may retain
remote access to the system.

Recommendation:
Identify the key owner and requirement.
Remove unauthorized keys and implement
centralized SSH key lifecycle management.

Part 32 — Shared Accounts

Suppose five administrators all use:

admin

This creates problems.

Administrator A
Administrator B
Administrator C
        ↓
     admin
        ↓
    Server

Logs may show:

admin performed action

but not clearly:

Which Human?

Better Model

Individual Identity
      ↓
Controlled Privilege
      ↓
Administrative Action

This improves:

Accountability

Revocation

Auditing

Investigation

Part 33 — Root Account

The root account represents:

Maximum Local Privilege

Treat it as:

Highly Sensitive

Administrative designs should generally favor:

Named Administrator
      ↓
Controlled sudo

rather than routine shared root sessions.

Part 34 — Privilege Escalation Review

During IAM assessment, investigate:

UID 0 Accounts

Administrative Groups

sudo Rules

SUID Files

SGID Files

Privileged Services

Scheduled Tasks

SSH Keys

IAM is broader than:

/etc/passwd

Part 35 — Review SUID

Inventory in your authorized lab:

sudo find / -xdev -type f -perm -4000 -print 2>/dev/null

Do not assume every SUID binary is malicious.

Instead ask:

Expected?

Package-Owned?

Required?

Approved Baseline?

Part 36 — Review SGID

Run:

sudo find / -xdev -type f -perm -2000 -print 2>/dev/null

Again:

Identify
   ↓
Understand
   ↓
Compare Baseline
   ↓
Investigate Deviation

Part 37 — Orphaned Files

Files may reference a UID or GID that no longer has a corresponding account.

In an authorized lab, you can review the local filesystem for orphaned ownership.

Conceptually look for:

Files Without Valid User

Files Without Valid Group

Why This Matters

Suppose:

Old User UID = 1500

is deleted.

Later:

New User Receives UID = 1500

Old files may unexpectedly appear owned by the new user.

This is why identity lifecycle and file ownership are connected.

Part 38 — User Deprovisioning

Deleting a user is not simply:

userdel

A proper workflow asks:

Which Files Do They Own?

Which Groups?

Which SSH Keys?

Which Scheduled Tasks?

Which sudo Rules?

Which Applications?

Which Tokens or Secrets?

Which Processes?

Deprovisioning Workflow

Disable Access
      ↓
Preserve Required Evidence
      ↓
Transfer Ownership
      ↓
Remove Group Membership
      ↓
Remove SSH Access
      ↓
Remove Privilege
      ↓
Remove Account
      ↓
Validate

Part 39 — Find User-Owned Files

For your training user Alice:

sudo find /home /srv -user alice -print 2>/dev/null

This helps determine:

What Data
Would Need Review
During Deprovisioning?

Part 40 — Review Processes by User

Run:

ps -u alice

Repeat for other training identities where appropriate.

Before disabling or removing an identity, determine whether it currently owns important processes.

Part 41 — Review Scheduled Tasks

For an authorized training user:

sudo crontab -u alice -l

If none exists, that is acceptable.

The important point is:

Account Removed

should not leave unmanaged:

Scheduled Execution

Part 42 — IAM Access Review

Now compare:

EXPECTED ACCESS

against:

ACTUAL ACCESS

Your original matrix was:

User	Required Role
Alice	Developer
Bob	Operations
Charlie	Security

Validate:

Groups

Filesystem Access

ACLs

sudo

SSH

Service Access

Access Review Questions

For every user ask:

Does the Account Still Need to Exist?

Is the Owner Known?

Are Group Memberships Correct?

Is Privilege Appropriate?

Are SSH Keys Current?

Does the User Own Unexpected Files?

Does the User Have Unexpected ACL Access?

Part 43 — Privilege Creep

Privilege creep occurs when users accumulate access over time.

Example:

Year 1
Developer
   ↓
devteam

Year 2
Operations Project
   ↓
opsadmin Added

Year 3
Security Project
   ↓
secteam Added

Later:

Current Role
=
Developer

but access remains:

devteam
+
opsadmin
+
secteam

This is:

Privilege Accumulation

Control

Perform:

Periodic Access Reviews

Part 44 — Separation of Duties

Some activities should not be controlled entirely by one person.

Example:

User Requests Privilege

Same User Approves Privilege

Same User Grants Privilege

creates weak governance.

A stronger model:

Request
   ↓
Independent Approval
   ↓
Provision
   ↓
Review

Part 45 — Just-in-Time Privilege

Traditional model:

Administrator
      ↓
Permanent Privilege

More mature environments may use:

Administrator
      ↓
Request
      ↓
Approval
      ↓
Temporary Privilege
      ↓
Expiration

This is often called:

Just-in-Time Access

Part 46 — Least Privilege

Least privilege means:

Minimum Access

Required Resource

Required Task

Required Duration

It does not mean:

Give Everyone
Read-Only Access
to Everything

Even read access may expose sensitive information.

Part 47 — Zero Trust Connection

Linux IAM can support Zero Trust principles.

Instead of:

User Is Inside Network
      ↓
Trust User

think:

Verify Identity

Validate Access

Limit Privilege

Log Activity

Review Continuously

Part 48 — Linux IAM in Cloud

When Linux runs in the cloud, multiple IAM layers exist.

Example:

Cloud IAM
   ↓
VM Access
   ↓
Linux Account
   ↓
sudo
   ↓
Application

A user may have:

No Local Linux Password

yet still gain VM access through cloud identity mechanisms.

Therefore cloud security assessments must evaluate:

Cloud IAM
+
Linux IAM

Part 49 — Linux IAM and Containers

Containers may introduce:

Container User

Host User

Root Mapping

Service Identity

Running an application as:

root

inside a container may increase risk depending on runtime configuration and isolation.

Prefer:

Non-Root Workload

where technically appropriate.

Part 50 — Linux IAM and Kubernetes

Kubernetes adds another identity layer:

Human Identity
      ↓
Kubernetes RBAC
      ↓
Service Account
      ↓
Pod
      ↓
Container User
      ↓
Linux Kernel

Understanding Linux IAM makes Kubernetes security easier to understand.

Part 51 — Linux IAM and Active Directory

Enterprise Linux systems may integrate with centralized identity platforms.

Conceptually:

Enterprise Directory
      ↓
Linux Authentication
      ↓
Group Mapping
      ↓
sudo / Resource Access

Benefits may include:

Central Lifecycle

Central Authentication

Consistent Groups

Simpler Revocation

Local emergency identities may still exist depending on architecture.

Part 52 — Linux IAM and PAM

PAM stands for:

Pluggable Authentication Modules

It provides a framework used by Linux services for authentication-related controls.

Conceptually:

Application
   ↓
PAM
   ↓
Authentication Modules
   ↓
Decision

PAM may participate in controls related to:

Authentication

Account Restrictions

Sessions

Password Changes

Do not modify PAM configuration casually.

Incorrect changes can prevent legitimate authentication.

Part 53 — IAM Logging

Identity activity should generate useful evidence.

Important events include:

Login Success

Login Failure

sudo Use

Account Creation

Account Modification

Group Changes

Password Changes

SSH Activity

SOC Perspective

The SOC may ask:

Who Logged In?

From Where?

When?

Was sudo Used?

Was a New User Created?

Was Group Membership Changed?

Linux IAM controls should support answering these questions.

Part 54 — IAM Investigation Scenario

Suppose an alert reports:

New User Added
to Administrative Group

Investigate:

WHO
Who created the user?

WHAT
Which group was modified?

WHEN
When did it happen?

WHERE
Which server?

WHY
Was there an approved change?

IMPACT
What privilege did the user gain?

Part 55 — IAM Finding: Excessive Group Membership

Finding:
Excessive Group Membership

Observation:
A user belongs to privileged groups that
are not required for the user's current role.

Risk:
Unnecessary privileges increase the impact
of credential compromise and accidental
administrative actions.

Recommendation:
Perform role-based access validation and
remove group memberships that are not
required.

Part 56 — IAM Finding: Dormant Account

Finding:
Dormant Interactive Account

Observation:
An interactive user account remains
enabled despite no confirmed current
business requirement.

Risk:
Unused accounts increase the available
authentication attack surface.

Recommendation:
Validate ownership and business need.
Disable or remove the account through
the approved identity lifecycle process.

Finding:
Service Account Allows Interactive Login

Observation:
A service identity is configured with an
interactive login shell despite no
identified operational requirement.

Risk:
Compromise of the service credentials may
provide unnecessary interactive access.

Recommendation:
Confirm application requirements and
restrict interactive login where it is
not required.

Part 58 — IAM Finding: Shared Administrative Account

Finding:
Shared Administrative Account

Observation:
Multiple administrators use the same
privileged Linux identity.

Risk:
Administrative activity cannot be reliably
attributed to an individual person and
credential revocation becomes difficult.

Recommendation:
Use individually attributable identities
with controlled privilege escalation and
centralized logging.

Part 59 — IAM Finding: Stale SSH Key

Finding:
Stale SSH Authorization

Observation:
An authorized SSH key remains configured
for an identity whose current ownership
or business requirement cannot be verified.

Risk:
A former or unauthorized key holder may
retain remote access.

Recommendation:
Validate key ownership, remove stale keys,
and implement a managed SSH key lifecycle.

Part 60 — Build the IAM Report

Create:

Linux IAM Assessment Report

Include:

1. System Information

Hostname

Distribution

Date

Assessment Scope

2. User Inventory

Include:

Username

UID

Account Type

Login Shell

Owner

Status

3. Group Inventory

Include:

Group

GID

Purpose

Members

4. Privileged Access

Review:

UID 0

Administrative Groups

sudo

SUID/SGID

5. Remote Access

Review:

SSH Accounts

SSH Keys

Administrative SSH Access

6. Resource Access

Review:

Ownership

Permissions

ACLs

7. Service Accounts

Document:

Account

Application

Interactive Login

Privilege

Owner

8. Findings

For every issue include:

Title

Observation

Risk

Evidence

Recommendation

Priority

Part 61 — IAM Evidence Checklist

Capture appropriate non-sensitive evidence for:

Never include:

Passwords

Password Hashes

Private SSH Keys

Tokens

Secrets

Part 62 — IAM Validation Matrix

Before completing the lab, validate:

Identity	Dev Directory	Security Directory	Administrative Access
Alice	Allowed	Denied	No
Bob	As Required	Denied after ACL removal	Limited/As Designed
Charlie	Denied unless required	Allowed	No
ghcapp	Application only	Denied	No

Your exact implementation may differ, but every permission should have a reason.

Part 63 — Negative Testing

Security validation must test both:

What Should Work

and:

What Should Fail

Examples:

Alice Can Access Development
        ✓

Alice Cannot Access Security
        ✓

Charlie Can Access Security
        ✓

Service Account Cannot
Interactively Log In
        ✓

A control is not fully validated if you test only successful access.

Part 64 — Clean Up Temporary ACL

Confirm Bob’s temporary ACL has been removed:

getfacl /srv/ghc/security

Validate Bob no longer receives the temporary access.

Part 65 — Lab Cleanup

Only after completing your evidence collection, remove identities created solely for this disposable lab if they are no longer needed.

Before deletion review:

Files

Processes

Scheduled Tasks

Groups

ACLs

sudo

SSH

Then use your distribution’s approved account-removal process.

Do not remove legitimate system identities.

Part 66 — IAM Operational Runbook

A professional access request should follow:

REQUEST
   ↓
Identify User

JUSTIFICATION
   ↓
Why Is Access Required?

APPROVAL
   ↓
Who Authorizes It?

PROVISION
   ↓
Grant Minimum Access

VALIDATE
   ↓
Test Required Access

LOG
   ↓
Record Change

REVIEW
   ↓
Is Access Still Required?

REVOKE
   ↓
Remove When No Longer Needed

Part 67 — Access Review Frequency

High-risk access should be reviewed more frequently than low-risk access.

Examples:

Root / sudo
      ↓
High Priority

Service Accounts
      ↓
High Priority

Production SSH
      ↓
High Priority

Standard Low-Risk Access
      ↓
Periodic Review

The exact frequency should follow organizational policy and risk.

Part 68 — Linux IAM Security Model

Your final model should be:

PERSON
   ↓
INDIVIDUAL IDENTITY
   ↓
AUTHENTICATION
   ↓
GROUP / ROLE
   ↓
LEAST PRIVILEGE
   ↓
RESOURCE
   ↓
LOGGING
   ↓
PERIODIC REVIEW
   ↓
REVOCATION

Common Linux IAM Mistakes

Avoid:

Shared Administrator Accounts

Permanent Root Access

Unnecessary sudo

chmod 777

Unmanaged SSH Keys

Interactive Service Accounts

Stale User Accounts

Excessive Group Membership

No Access Reviews

No Account Owner

No Expiration for Temporary Access

Deleting Accounts Without Reviewing Files

Ignoring ACLs

Ignoring SUID/SGID

Ignoring Cloud IAM Above the VM

Career Connection

The skills in this lab directly support:

Linux Administrator

Linux Security Engineer

IAM Engineer

SOC Analyst

Cloud Security Engineer

DevSecOps Engineer

Incident Responder

Security Consultant

Interview Scenario 01

A developer says they need root because their application occasionally requires administrative changes. What should you do?

Use:

Understand Task
      ↓
Identify Required Privilege
      ↓
Determine Safer Delegation
      ↓
Apply Least Privilege
      ↓
Log Usage

Do not automatically grant unrestricted root access.

Interview Scenario 02

An employee leaves the organization. Is deleting their Linux account enough?

No.

Review:

SSH Keys

Groups

sudo

Files

Processes

Scheduled Tasks

Application Access

Tokens

Secrets

Interview Scenario 03

A user has correct Unix permissions but still cannot access a file. What else should you check?

Review:

Parent Directory Permissions

ACLs

SELinux

AppArmor

Application Controls

Interview Scenario 04

Why are shared administrator accounts problematic?

Because they reduce:

Accountability

Attribution

Revocation Precision

Audit Quality

Interview Scenario 05

What is privilege creep?

It is the accumulation of access over time as a user’s responsibilities change without previous permissions being removed.

40 Linux IAM Interview Questions

What is Linux IAM?
What is authentication?
What is authorization?
What is a UID?
What is a GID?
Why is UID 0 security-sensitive?
What is a primary group?
What is a supplementary group?
Why are groups useful for access management?
What is least privilege?
What is privilege creep?
What is separation of duties?
What is an account lifecycle?
Why should dormant accounts be disabled?
What is a service account?
Why should service accounts avoid interactive login when unnecessary?
What is file ownership?
What do rwx permissions mean?
What does permission 750 mean?
Why is 777 usually a poor troubleshooting solution?
What is SGID on a directory?
What is an ACL?
When would you use an ACL?
How do ACLs affect permission troubleshooting?
What is sudo?
Why is unrestricted sudo risky?
Why should sudo changes be validated?
Why are individual administrator accounts preferable to shared accounts?
What is an SSH public key?
Why must SSH private keys remain protected?
What is authorized_keys?
Why should stale SSH keys be removed?
What is SUID?
Why should SUID files be reviewed?
What are orphaned files?
Why should file ownership be reviewed before deleting a user?
What is just-in-time privileged access?
How does Linux IAM interact with cloud IAM?
How does Linux IAM support incident response?
How would you conduct a privileged-access review?

Lab Completion Checklist

Identity

Groups

Account Lifecycle

Permissions

ACL

Privilege

Service Accounts

Created training service account
Restricted interactive login
Assigned application resource
Reviewed service-account privilege

SSH

Security Review

Mission Accomplished

You have now built and assessed a practical Linux IAM model covering:

Users

UIDs

Groups

GIDs

Account Lifecycle

Service Accounts

Ownership

Permissions

ACLs

sudo

SSH Keys

Privileged Access

Access Reviews

Deprovisioning

You have moved from:

Creating Linux Users

to understanding:

Enterprise Linux
Identity and Access Management

The professional IAM mindset is:

WHO
   ↓
NEEDS WHAT
   ↓
FOR WHICH PURPOSE
   ↓
FOR HOW LONG
   ↓
WITH WHICH PRIVILEGE
   ↓
HOW WILL IT BE AUDITED
   ↓
WHEN WILL IT BE REMOVED

What’s Next?

➡️ Lab 04 — Linux Networking

In the next lab, you will move from identity security to Linux network administration and security.

You will work through:

Network Interfaces
      ↓
IP Addressing
      ↓
Subnetting
      ↓
Routing
      ↓
Default Gateway
      ↓
DNS
      ↓
TCP and UDP
      ↓
Listening Ports
      ↓
Connections
      ↓
Network Services
      ↓
Host Firewall
      ↓
Network Troubleshooting
      ↓
Security Analysis

Your Linux lab journey continues:

Lab 01 — Linux Administration
        ↓
Lab 02 — Linux Hardening
        ↓
Lab 03 — Linux IAM
        ↓
Lab 04 — Linux Networking
        ↓
Lab 05 — Linux Security
        ↓
Runbook 01 — Linux Incident Investigation
        ↓
Runbook 02 — Linux Security Assessment
        ↓
Runbook 03 — Linux Server Hardening

Lab 03 — Linux IAM

Mission Information

Mission Scenario

Learning Objectives

Lab Architecture

IAM Mental Model

Authentication vs Authorization

Authentication

Authorization

Part 01 — Prepare the Lab

Step 01 — Confirm Your Identity

Step 02 — Review Current Users

/etc/passwd

Step 03 — Inspect Your Own Account

Part 02 — Understand UID

Step 04 — Review UID Values

Security Principle

Step 05 — Identify UID 0 Accounts

Finding Example

Part 03 — Understand GID

Group-Based Access Model

Part 04 — Create Training Groups

Group Purpose

Part 05 — Create Training Users

User Roles

Step 06 — Inspect Identities

Part 06 — Assign Group Membership

Important Command Lesson

Part 07 — Create an IAM Matrix

Part 08 — Account Lifecycle

Security Problem

Part 09 — Review Password State

Important

Part 10 — Account Locking

Why Preserve Accounts?

Part 11 — Account Expiration

Part 12 — Service Accounts

Service Account Model

Service Account Questions

Part 13 — Create Protected Resources

Desired Access

Part 14 — Configure Development Ownership

Why 2?

Desired Model

Part 15 — Configure Security Directory

Part 16 — Configure Application Directory

IAM Principle

Part 17 — Test Access

Validation Model

Part 18 — Understand File Permissions

Numeric Values

Security Warning

Part 19 — Troubleshoot Permission Denied

Example Commands

Part 20 — Access Control Lists

Step 07 — Check ACL Support

Step 08 — Grant a Training ACL

Test

IAM Meaning

Part 21 — Remove Temporary ACL

Access Lifecycle

Part 22 — Default ACLs

Part 23 — Review ACLs Professionally

Part 24 — sudo

Step 09 — Review Current sudo Access

Part 25 — Review sudo Configuration

Part 26 — Least-Privilege sudo Design

Poor Model

Better Model

Important Security Note

Part 27 — sudo Logging

Security Question

Part 28 — SSH Identity

SSH Authentication Model

Part 29 — Generate a Training SSH Key

Critical Rule

Part 30 — Review .ssh

SSH IAM Review

Part 31 — authorized_keys

Finding Example

`/etc/passwd`

Why `2`?

Part 30 — Review `.ssh`

Part 31 — `authorized_keys`