Day 3 – Linux User Management & Access Control

Introduction

User management is one of the most important responsibilities of a Linux Administrator.

In an enterprise environment, administrators need to manage:

• Users and groups

• Passwords and password aging

• File ownership and permissions

• ACLs

• Controlled administrative access using sudo

• SSH authentication

• User access troubleshooting

A Linux Administrator should be able to:

1. Create and delete users

2. Create and manage groups

3. Configure file and directory permissions

4. Manage passwords

5. Configure password aging

6. Provide controlled sudo access

7. Configure SSH key-based authentication

8. Troubleshoot user-access issues

---

1. Types of Users in Linux

Linux generally has three main categories of users.

1.1 Root User

The root user is the Linux superuser and has almost unlimited privileges.

[root@rocky8 ~]# id root
uid=0(root) gid=0(root) groups=0(root)

Because root has extensive privileges, direct root access should be carefully controlled in an enterprise environment.

---

1.2 System Users

System users are normally created for applications and services.

Examples:

apache
nginx
mysql

These accounts are generally used to run services rather than for interactive human login.

---

1.3 Regular Users

Regular users are created for people who need to log in and work on the system.

Examples:

john
admin
developer
support

---

2. Creating Linux Users

The basic syntax for creating a user is:

[root@rocky8 ~]# useradd user1

Create a user with a home directory and Bash shell:

[root@rocky8 ~]# useradd -m -s /bin/bash user2

Create a user with a comment:

[root@rocky8 ~]# useradd -m -s /bin/bash -c "DevOps Engineer" john

Create a user and assign a primary group:

[root@rocky8 ~]# useradd -m -g devops -s /bin/bash -c "DevOps Engineer" user4

Common useradd Options

Option	Description
-m	Create the user's home directory
-u	Specify UID
-g	Specify primary group
-G	Specify supplementary groups
-c	Add a comment
-s	Specify login shell
-d	Specify home directory

---

3. Enterprise Example – Creating a User with Specific UID and Groups

In enterprise environments, user information may be provided in a predefined format.

For example:

Parameter	Value
Username	a181361
User ID	9181361
Primary Group ID	3100000
Secondary Group ID	3100004
Comment	Vallabh Darole
Home Directory	Automatically created

The corresponding command is:

[root@rocky8 ~]# useradd -u 9181361 -g 3100000 -G 3100004 -c "Vallabh Darole" -m a181361

This is useful when an organization maintains standardized UID/GID mappings.

Enterprise Tip: Before assigning a specific UID or GID, verify that the ID is not already being used on the system.

Check whether a UID exists:

[root@rocky8 ~]# getent passwd 9181361

Check whether a GID exists:

[root@rocky8 ~]# getent group 3100000

---

4. Create User and Password

4.1 RHEL / Rocky Linux

On RHEL-based systems, passwd --stdin may be available depending on the OS version and configuration.

Example:

[root@rocky8 ~]# useradd -u 9181361 -g 3100000 -G 3100004 -c "Vallabh Darole" -m a181361
[root@rocky8 ~]# echo 'a181361:pass@1234' | chpasswd
[root@rocky8 ~]# passwd -e a181361

The passwd -e command forces the user to change the password at the next login.

An alternative often seen on older RHEL/Rocky environments is:

[root@rocky8 ~]# echo 'pass@1234' | passwd --stdin a181361

Note: passwd --stdin is not portable across Linux distributions. chpasswd is generally more portable for scripted password changes.

---

4.2 Ubuntu Linux

Ubuntu commonly uses chpasswd:

[root@ubuntu24 ~]# useradd -u 9181361 -g 3100000 -G 3100004 -c "Vallabh Darole" -m a181361
[root@ubuntu24 ~]# echo 'a181361:pass@1234' | chpasswd

---

4.3 SUSE Linux

SUSE Linux also commonly uses chpasswd:

[root@sles15 ~]# useradd -u 9181361 -g 3100000 -G 3100004 -c "Vallabh Darole" -m a181361
[root@sles15 ~]# echo 'a181361:pass@1234' | chpasswd

Security Note

The password shown above is only a lab example.

Avoid putting real passwords directly into:

• Shell history

• Scripts

• Git repositories

• Automation files

• Documentation

In production, use a secure password-management or automation solution.

---

5. Verify the User

After creating a user, always verify the account.

Check User Information

[root@rocky8 ~]# id a181361

Example:

uid=9181361(a181361) gid=3100000 groups=3100000,3100004

Check Home Directory

[root@rocky8 ~]# ls -ld /home/a181361

Check /etc/passwd

[root@rocky8 ~]# grep '^a181361:' /etc/passwd

Check Login Shell

[root@rocky8 ~]# getent passwd a181361

---

6. Deleting a Linux User

Delete a user:

[root@rocky8 ~]# userdel user1

Delete a user and their home directory:

[root@rocky8 ~]# userdel -r user2

The -r option removes the user's home directory and associated local mail spool where applicable.

Enterprise Tip

Before deleting an account, check whether the user owns:

• Important files

• Running processes

• Scheduled jobs

• Application files

• Cron jobs

• Other resources

Find files owned by a user:

[root@rocky8 ~]# find / -user user1 -ls 2>/dev/null

---

7. Locking and Unlocking User Accounts

Administrators may need to temporarily disable an account.

Lock the Account

[root@rocky8 ~]# passwd -l a181361

Check Account Status

[root@rocky8 ~]# passwd -S a181361

Unlock the Account

[root@rocky8 ~]# passwd -u a181361

This is useful when an employee is temporarily unavailable, an account is suspected of compromise, or access needs to be suspended during an investigation.

---

8. Linux Group Management

Groups make it easier to manage permissions for multiple users.

For example, instead of assigning permissions individually to 20 users, an administrator can create one group and manage permissions for that group.

Create a Group

[root@rocky8 ~]# groupadd developers

Add a User to a Secondary Group

[root@rocky8 ~]# usermod -aG developers john

Verify Group Membership

[root@rocky8 ~]# id john

or:

[root@rocky8 ~]# groups john

Important: Always use -aG when adding a supplementary group. Without -a, existing supplementary group memberships can be replaced.

---

9. Primary and Secondary Groups

Linux users can have:

• One primary group

• Zero or more supplementary/secondary groups

Check the user's groups:

[root@rocky8 ~]# id john

Example:

uid=1001(john) gid=1001(john) groups=1001(john),1005(developers),1006(devops)

Here:

Primary group       : john
Secondary groups    : developers, devops

---

10. Password Aging

Linux provides the chage command to manage password expiration.

Set Maximum Password Age

Set the maximum password age to 90 days:

[root@rocky8 ~]# chage -M 90 john

Set Password Expiration Warning

Warn the user 10 days before password expiration:

[root@rocky8 ~]# chage -W 10 john

View Password Aging Information

[root@rocky8 ~]# chage -l john

Example:

Last password change                                    : Sep 11, 2026
Password expires                                        : Dec 10, 2026
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change         : 0
Maximum number of days between password change          : 90
Number of days of warning before password expires      : 10

Password aging is commonly used to implement organizational password policies.

---

11. Understanding /etc/login.defs

The /etc/login.defs file contains default settings used by several user-management utilities.

View the file:

[root@rocky8 ~]# cat /etc/login.defs

Some important settings include:

PASS_MAX_DAYS
PASS_MIN_DAYS
PASS_WARN_AGE
UID_MIN
UID_MAX
GID_MIN
GID_MAX
CREATE_HOME

Example:

PASS_MAX_DAYS   99999
PASS_MIN_DAYS   0
PASS_WARN_AGE   7

These settings can influence the default behavior when new users are created.

Note: Exact contents and defaults can vary between Linux distributions and versions. Modern systems may also use other mechanisms such as PAM configuration and authselect for authentication policies.

---

12. Important Linux User and Group Files

Linux stores user and group information in several important files.

/etc/passwd

Contains basic user-account information.

[root@rocky8 ~]# cat /etc/passwd

Example:

john:x:1001:1001:DevOps Engineer:/home/john:/bin/bash

The fields are:

Username
Password placeholder
UID
GID
Comment
Home directory
Login shell

---

/etc/shadow

Contains password hashes and password-aging information.

[root@rocky8 ~]# cat /etc/shadow

Access to this file should be restricted.

---

/etc/group

Contains group information.

[root@rocky8 ~]# cat /etc/group

---

/etc/gshadow

Contains secure group information.

[root@rocky8 ~]# cat /etc/gshadow

Security Note: Do not modify these files manually unless you understand the consequences. Prefer commands such as useradd, usermod, groupadd, groupmod, and passwd.

---

13. File Ownership and Permissions

Linux security is strongly based on file ownership and permissions.

Run:

[root@rocky8 ~]# ls -l

Example:

-rwxr-xr-- 1 alex developers 4096 May 10 12:30 deploy.sh

The permission string is:

-rwxr-xr--

It can be divided into:

- | rwx | r-x | r--
  |     |     |
  |     |     +---- Others
  |     +---------- Group
  +---------------- Owner

---

14. Linux File Types

The first character represents the file type.

Character	Meaning
-	Regular file
d	Directory
l	Symbolic link
c	Character device
b	Block device
s	Socket
p	Named pipe

Example:

-rw-r--r--   Regular file
drwxr-xr-x   Directory
lrwxrwxrwx   Symbolic link

---

15. Linux Permissions

There are three permission categories:

Owner
Group
Others

And three basic permissions:

r = read
w = write
x = execute

Example:

-rwxr-xr--

Means:

Owner  : rwx
Group  : r-x
Others : r--

---

16. Numeric Permissions

Linux permissions can also be represented numerically.

Permission	Value
Read (r)	4
Write (w)	2
Execute (x)	1

Therefore:

7 = 4 + 2 + 1 = rwx
6 = 4 + 2     = rw-
5 = 4 + 1     = r-x
4 = 4         = r--
3 = 2 + 1     = -wx
2 = 2         = -w-
1 = 1         = --x
0 = 0         = ---

For example:

755 = rwxr-xr-x

Meaning:

Owner  = 7 = rwx
Group  = 5 = r-x
Others = 5 = r-x

---

17. Changing Permissions with chmod

Add Execute Permission

[root@rocky8 ~]# chmod +x script.sh

Set Permissions Numerically

[root@rocky8 ~]# chmod 755 script.sh

Remove Write Permission from Others

[root@rocky8 ~]# chmod o-w sensitive_file.txt

---

18. Symbolic chmod

Permissions can be modified using:

u = user/owner
g = group
o = others
a = all

Give Owner Full Access

[root@rocky8 ~]# chmod u+rwx sensitive_file.txt

Give Group Full Access

[root@rocky8 ~]# chmod g+rwx sensitive_file.txt

Give Others Full Access

[root@rocky8 ~]# chmod o+rwx sensitive_file.txt

Remove Owner Permissions

[root@rocky8 ~]# chmod u-rwx sensitive_file.txt

Remove Group Permissions

[root@rocky8 ~]# chmod g-rwx sensitive_file.txt

Remove Others' Permissions

[root@rocky8 ~]# chmod o-rwx sensitive_file.txt

Security Tip: Always grant the minimum permissions required.

---

19. Common Permission Examples

Permission 644

rw-r--r--

Commonly used for regular files.

[root@rocky8 ~]# chmod 644 file.txt

The owner can read/write, while group and others can read.

---

Permission 600

rw-------

Only the owner has read/write access.

[root@rocky8 ~]# chmod 600 private.txt

Useful for sensitive files such as private configuration files and SSH private keys.

---

Permission 755

rwxr-xr-x

Commonly used for executable files, scripts, and directories where appropriate.

[root@rocky8 ~]# chmod 755 script.sh

---

20. Change File Ownership with chown

Change the owner:

[root@rocky8 ~]# chown alex config.yaml

Change owner and group:

[root@rocky8 ~]# chown alex:developers config.yaml

Change directory ownership:

[root@rocky8 ~]# chown alex:developers app/

Change ownership recursively:

[root@rocky8 ~]# chown -R www-data:www-data /var/www/html

Caution: Always verify the target path before using chown -R. A recursive ownership change on the wrong directory can cause major application or system problems.

---

21. Security Rule – Avoid chmod 777

Avoid using:

[root@rocky8 ~]# chmod 777 file

as a quick fix for permission problems.

777 gives:

Owner  : rwx
Group  : rwx
Others : rwx

This can create a serious security risk.

Instead, identify:

1. Correct owner

2. Correct group

3. Required permissions

4. Whether ACLs are required

5. Whether SELinux is also involved

A better troubleshooting approach is:

[root@rocky8 ~]# ls -l file
[root@rocky8 ~]# namei -l /path/to/file

---

22. Enterprise Access-Control Example

Let's create a simple enterprise scenario.

We have the following users:

webadmin1
webadmin2
dbadmin1
dbadmin2
help-desk

We will use:

web-grp
db-grp

Our requirement is:

User	Requirement
webadmin1	Web application administration
webadmin2	Web application administration
dbadmin1	Database administration
dbadmin2	Database administration
help-desk	Read-only access to web and database data

---

23. Step 1 – Create Groups

[root@rocky8 ~]# groupadd web-grp
[root@rocky8 ~]# groupadd db-grp

Verify:

[root@rocky8 ~]# getent group web-grp
[root@rocky8 ~]# getent group db-grp

---

24. Step 2 – Create Users

For a lab environment:

[root@rocky8 ~]# useradd -m webadmin1
[root@rocky8 ~]# useradd -m webadmin2
[root@rocky8 ~]# useradd -m dbadmin1
[root@rocky8 ~]# useradd -m dbadmin2
[root@rocky8 ~]# useradd -m help-desk

Set passwords interactively:

[root@rocky8 ~]# passwd webadmin1
[root@rocky8 ~]# passwd webadmin2
[root@rocky8 ~]# passwd dbadmin1
[root@rocky8 ~]# passwd dbadmin2
[root@rocky8 ~]# passwd help-desk

Using interactive passwd is preferable to exposing passwords directly in shell history.

---

25. Step 3 – Add Users to Groups

Add web administrators:

[root@rocky8 ~]# usermod -aG web-grp webadmin1
[root@rocky8 ~]# usermod -aG web-grp webadmin2

Add database administrators:

[root@rocky8 ~]# usermod -aG db-grp dbadmin1
[root@rocky8 ~]# usermod -aG db-grp dbadmin2

Verify:

[root@rocky8 ~]# id webadmin1
[root@rocky8 ~]# id dbadmin1

---

26. Step 4 – Create Application Directories

Create the web and database directories:

[root@rocky8 ~]# mkdir /web-data
[root@rocky8 ~]# mkdir /db-data

---

27. Step 5 – Set Group Ownership

For web administrators:

[root@rocky8 ~]# chown root:web-grp /web-data

For database administrators:

[root@rocky8 ~]# chown root:db-grp /db-data

Verify:

[root@rocky8 ~]# ls -ld /web-data /db-data

---

28. Step 6 – Set Directory Permissions

Give the owner and group full access:

[root@rocky8 ~]# chmod 770 /web-data
[root@rocky8 ~]# chmod 770 /db-data

The configuration becomes:

/web-data
Owner : root
Group : web-grp
Mode  : 770

/db-data
Owner : root
Group : db-grp
Mode  : 770

Therefore:

web-grp → Full access to /web-data
db-grp  → Full access to /db-data
Others  → No access

---

29. Step 7 – Verify Access

Check directory permissions:

[root@rocky8 ~]# ls -ld /web-data
[root@rocky8 ~]# ls -ld /db-data

You can test access by switching users:

[root@rocky8 ~]# su - webadmin1

Then:

[webadmin1@rocky8 ~]$ cd /web-data
[webadmin1@rocky8 ~]$ touch test.txt

The user should be able to create files in /web-data.

The same concept applies to dbadmin1 and /db-data.

---

30. Access Control Using ACL

Sometimes standard Linux permissions are not enough.

For example:

webadmin1 → Full access to /web-data
webadmin2 → Full access to /web-data
help-desk → Read/Traverse access to /web-data

The help-desk user is not a member of web-grp.

Instead of changing the primary group structure, we can use an ACL.

---

31. Check Existing ACL

[root@rocky8 ~]# getfacl /web-data

and:

[root@rocky8 ~]# getfacl /db-data

---

32. Give Help-Desk Access Using ACL

Give help-desk read and traverse permissions:

[root@rocky8 ~]# setfacl -m u:help-desk:rx /web-data
[root@rocky8 ~]# setfacl -m u:help-desk:rx /db-data

Verify:

[root@rocky8 ~]# getfacl /web-data
[root@rocky8 ~]# getfacl /db-data

---

33. Important ACL Concept

For a directory:

r = list directory contents
w = create/delete/rename directory entries
x = enter/traverse the directory

Therefore:

rx

allows a user to list and traverse the directory but does not allow them to modify directory entries.

However, directory ACLs alone do not automatically make every file inside readable.

If help-desk must actually read files inside /web-data, the files themselves must have appropriate read permissions/ACLs.

For newly created files and directories, default ACLs can be used.

Example:

[root@rocky8 ~]# setfacl -m u:help-desk:rx /web-data
[root@rocky8 ~]# setfacl -d -m u:help-desk:rx /web-data

---

34. Expected Access

User	/web-data	/db-data
webadmin1	Read/Write/Execute	No access
webadmin2	Read/Write/Execute	No access
dbadmin1	No access	Read/Write/Execute
dbadmin2	No access	Read/Write/Execute
help-desk	Read/Traverse	Read/Traverse

This is a practical example of implementing role-based access control using:

Linux Users
     ↓
Linux Groups
     ↓
Ownership
     ↓
Permissions
     ↓
ACL

---

35. SUDO – Controlled Administrative Access

Instead of giving users the root password, Linux administrators can provide controlled administrative access using sudo.

Check sudo access:

[root@rocky8 ~]# sudo -l -U username

The main sudo configuration is:

[root@rocky8 ~]# cat /etc/sudoers

Important: Do not directly edit /etc/sudoers using a normal text editor.

Always use:

[root@rocky8 ~]# visudo

visudo checks the configuration syntax before saving it.

---

36. SUDO Using Groups

Instead of granting administrative privileges to individual users, users can be placed into groups.

For example:

web-grp
db-grp
helpdesk-team

A sudo rule can be configured for a group.

Example:

%web-grp ALL=(ALL) /usr/bin/systemctl restart httpd, /usr/bin/systemctl status httpd

This allows members of web-grp to perform specific Apache service operations without automatically giving them unrestricted root access.

Best Practice: Restrict sudo permissions to the exact commands and arguments required by the user's job.

---

37. Principle of Least Privilege

The Principle of Least Privilege means:

Give users only the permissions they actually need.

For example, if a web administrator only needs to restart Apache, avoid giving:

ALL=(ALL) ALL

when a more restrictive rule can be used.

A restricted rule is safer than unrestricted root access.

---

38. SUDO Command Aliases

Command aliases can simplify sudo configuration.

Example:

Cmnd_Alias USERMGMT = /usr/sbin/useradd, /usr/sbin/usermod

Then:

%helpdesk-team ALL=(ALL) USERMGMT

This allows members of helpdesk-team to execute the specified user-management commands.

Always verify command paths first:

[root@rocky8 ~]# which useradd
[root@rocky8 ~]# which usermod

On some systems, command -v can also be used:

[root@rocky8 ~]# command -v useradd
[root@rocky8 ~]# command -v usermod

---

39. SSH Key-Based Authentication

SSH key-based authentication is commonly used for:

• Linux administration

• Ansible

• Automation

• Server-to-server communication

• CI/CD pipelines

Instead of authenticating using a password, SSH uses a key pair:

Private Key  → Stored securely on client
Public Key   → Stored on destination server

---

40. Generate an SSH Key

On the source server:

[root@rocky8 ~]# ssh-keygen

For a modern RSA key:

[root@rocky8 ~]# ssh-keygen -t ed25519

The key files are normally stored under:

~/.ssh/

For example:

id_ed25519
id_ed25519.pub

Security Rule: Never share the private key. The .pub file is the public key and can be copied to the destination server.

---

41. Copy the Public Key to Another Server

Use:

[root@rocky8 ~]# ssh-copy-id user@server

For example:

[root@rocky8 ~]# ssh-copy-id ansadmin@ans01

The public key is added to:

~/.ssh/authorized_keys

on the destination server.

---

42. Test SSH Key Authentication

Connect to the destination:

[root@rocky8 ~]# ssh user@server

Example:

[root@rocky8 ~]# ssh ansadmin@ans01

If configured correctly, SSH can authenticate using the key instead of asking for the user's password.

This is particularly useful for Ansible automation.

---

43. SSH Troubleshooting

If key-based authentication does not work, check:

Check SSH Service

[root@rocky8 ~]# systemctl status sshd

Check .ssh Directory

[root@rocky8 ~]# ls -ld ~/.ssh

Check authorized_keys

[root@rocky8 ~]# ls -l ~/.ssh/authorized_keys

Typical permissions are:

~/.ssh              → 700
authorized_keys     → 600

Fix permissions if required:

[root@rocky8 ~]# chmod 700 ~/.ssh
[root@rocky8 ~]# chmod 600 ~/.ssh/authorized_keys

Use verbose SSH output:

[root@rocky8 ~]# ssh -vvv user@server

This is one of the most useful commands for troubleshooting SSH authentication.

---

44. Troubleshooting Linux User Access

When troubleshooting Linux user-access problems, start with the user's identity and group membership.

Check User Information

[root@rocky8 ~]# id username

Check Account Status

[root@rocky8 ~]# passwd -S username

Check Password Aging

[root@rocky8 ~]# chage -l username

Check SUDO Permissions

[root@rocky8 ~]# sudo -l -U username

Check Recent Logins

[root@rocky8 ~]# last

Check Failed Login Attempts

On systems using faillog:

[root@rocky8 ~]# faillog -u username

On systems using systemd:

[root@rocky8 ~]# journalctl -u sshd

---

45. Troubleshooting File Permission Problems

When a user cannot access a file or directory, check:

1. User identity

[root@rocky8 ~]# id username

2. File ownership

[root@rocky8 ~]# ls -l /path/to/file

3. Directory permissions

[root@rocky8 ~]# ls -ld /path/to/directory

4. Parent-directory permissions

[root@rocky8 ~]# namei -l /path/to/file

5. ACL

[root@rocky8 ~]# getfacl /path/to/file

6. SELinux

On RHEL/Rocky systems:

[root@rocky8 ~]# getenforce

Check the security context:

[root@rocky8 ~]# ls -Z /path/to/file

This is important because a Linux user may have correct Unix permissions but still be denied by SELinux.

---

46. Real-World Example – Unauthorized Access Attempt

Suppose a user attempts to execute an administrative command without having the required privileges.

The administrator can investigate systematically.

Step 1 – Check User Identity

[root@rocky8 ~]# id username

Step 2 – Check Account Status

[root@rocky8 ~]# passwd -S username

Step 3 – Check SUDO Permissions

[root@rocky8 ~]# sudo -l -U username

Step 4 – Check Login Activity

[root@rocky8 ~]# last username

Step 5 – Check Authentication Logs

On RHEL/Rocky:

[root@rocky8 ~]# journalctl -u sshd

Depending on the system configuration, authentication information may also be available in:

/var/log/secure

The administrator can verify:

• User identity

• Group membership

• Account status

• Password expiration

• Sudo permissions

• Login activity

• SSH authentication

• File permissions

• ACLs

• SELinux context

Correct user and sudo configuration helps prevent unauthorized administrative access.