If you don't understand how users and groups work, you will either lock legitimate people out of important files or accidentally give a stranger the keys to the entire company's data. This chapter solves that exact problem by teaching you how to control who can do what on a Linux system. For the EX200 exam, this is non-negotiable: you will be asked to create, modify, and delete user and group accounts, so getting these commands and concepts straight is your first step to passing.
Jump to a section
A simple way to picture User and Group Administration
A busy apartment building with a front security desk.
The security guard keeps a register of every person who lives there, their flat number, and a set of keys that only open their specific apartment and the main entrance. This is like a user account – a unique identity with specific permissions. Now, the building also has common areas: the gym, the laundry room, and the rooftop garden. Instead of giving every single resident a separate key for each of these three rooms, the security guard issues a 'Facilities Pass'. Anyone on the list for that pass can enter all three common areas. If a plumber needs to fix a pipe on the roof, the guard doesn't add their name to the building register; they just temporarily add the plumber to the 'Facilities Pass' list. When the job is done, the plumber is removed.
This is precisely how Linux groups work. The 'Facilities Pass' is the group. Instead of managing permissions for each user individually (a nightmare in a building of 200 flats), you manage the one pass. To grant access to the roof, you just add a user to the group. Evicting someone is simply removing them from the group, not taking away three separate keys. The security desk (the system's authentication service) checks the register and the pass list every time someone tries to enter an area. This separation of identity (the individual key) from role (the group pass) is the entire foundation of user and group administration on a Linux system.
At its heart, a Linux system is a multi-user environment. That means several people can log in and use it at the same time, but they should only see and touch their own work. The system needs a way to know who is who and what each person is allowed to do. This is where users and groups come in.
First, let's define the most basic unit: a user. A user is simply an identity. Every user has a username (for convenience, like 'jane_doe') and a User ID (UID), which is a number the system actually uses internally. When you log in, the system says, 'Ah, this is UID 1001, jane_doe.' It then checks what jane_doe is allowed to do. Every user also has a home directory (usually /home/jane_doe) where they can store personal files. A user's primary group is a group that is automatically assigned to every file they create.
But if we only had users, managing permissions for a team of five people who all need to edit the same project file would be a nightmare. You would have to tell the system, 'Let jane write this file, let bob write this file, let alice write this file...' That's tedious. Instead, we create a group. A group is a logical container for users. You create a group called 'project_x' with its own Group ID (GID). You then add Jane, Bob, and Alice to that group. Now, you set the permissions on the project file to say: the user who owns it can do anything, the group 'project_x' can read and write, and everyone else can do nothing. That is three steps instead of twelve.
How does the system actually store all this? It uses a few key files:
/etc/passwd: This file lists every user account on the system. It contains the username, an 'x' (which means the password is stored elsewhere for security), the UID, the GID of the primary group, the user's full name (or comment), the home directory, and the login shell (usually /bin/bash). It is world-readable because other programs need to look up usernames.
/etc/shadow: This is the secured file that actually stores the password hash (a scrambled version of your password), as well as password expiration and ageing information. Only the root user (the system administrator) can read this file. Moving the password here was a critical security improvement.
/etc/group: This file lists every group. It contains the group name, a placeholder for a group password (rarely used), the GID, and a list of usernames that are secondary members of the group.
/etc/gshadow: Like /etc/shadow but for group passwords, which are used for group administration if a non-member wants to temporarily join a group.
Now, let's talk about privileges. The most powerful user on any Linux system is called root (UID 0). The root user can do absolutely anything: delete files, change passwords, install software, access any file. Because of this immense power, standard users never log in as root for daily tasks. Instead, they use a tool called sudo (short for 'superuser do') to run single commands with root privileges. The list of who can use sudo is stored in the /etc/sudoers file.
When the EX200 exam asks you to create a user, you will use the useradd command. For example:
sudo useradd jane_doeThis adds a new user with default settings. You can customise it with options like -u (to specify a UID), -g (to specify a primary group by GID or name), -G (to add the user to secondary groups), and -d (to set a custom home directory).
To modify a user who already exists, you use usermod. Common options include -aG (append the user to a group without removing them from others) and -L (lock the account, preventing login).
To delete a user, you use userdel. By itself, userdel removes the user from /etc/passwd and /etc/shadow but leaves their home directory. To remove the home directory and mail spool as well, you add the -r flag.
For groups, the commands are similar: groupadd creates a new group, groupmod modifies its name or GID, and groupdel deletes it.
Finally, you need to understand password policies. Red Hat expects you to control password ageing with the chage command. chage allows you to set:
-M (maximum number of days a password is valid)
-m (minimum days before a password can be changed)
-W (number of days of warning before password expires)
-E (an exact date the account expires)
-I (inactive days after password expiry before account is locked)
For example, to force Jane to change her password every 90 days and give her a warning 7 days before, you run:
sudo chage -M 90 -W 7 jane_doeAll of this seems like a lot, but the logic is simple. You are the bouncer at a nightclub. The bouncer has a list of members (users) and a list of VIP sections (groups). You use the commands above to update those lists. That is user and group administration.
Create the Group
Before you create users who need shared access, create the group they will belong to. Use `sudo groupadd developers`. This establishes the container that users will be added to later, ensuring the GID exists before you assign it to a user.
Create the User
Create the user with `sudo useradd -c "Jane Developer" -G developers jane`. The -c flag adds a comment (full name), and the -G flag adds the user to the 'developers' group as a secondary membership. If you omit -G, the user will only have their private primary group.
Set the Password and Force Change
Set a temporary password with `sudo passwd jane` and then force a change on first login with `sudo chage -d 0 jane`. The -d 0 sets the password's 'last changed' date to epoch (Jan 1, 1970), making it appear as if the password has never been changed, which forces the user to update it immediately.
Configure Password Ageing
Set password maximum age to 90 days with `sudo chage -M 90 jane`, and give a warning 7 days before expiry with `sudo chage -W 7 jane`. This automates security compliance without manual intervention.
Set Permissions on Shared Directory
Create a shared directory with `sudo mkdir /srv/projects`, set the group ownership to 'developers' with `sudo chown jane:developers /srv/projects`, and set the permissions with `sudo chmod 2770 /srv/projects`. The setgid bit (2) ensures all new files inherit the group.
Verify and Lockout (if needed)
Verify the user's configuration with `id jane` and `groups jane`. If the user is leaving, lock the account with `sudo usermod -L jane` before ultimately deleting with `sudo userdel -r jane`.
Imagine you are the sole IT administrator for a small design agency called 'Pixel Perfect'. The company has 15 employees. You have just installed a new Red Hat Enterprise Linux file server that will host all the shared project files. Without proper user and group administration, the new hire on the ground floor could accidentally delete the CEO's project files, or a departing contractor could walk out the door with every client asset. Here is how you would use the principles from this chapter in a real business setting.
First, you set up the users. When the CEO, Alice, joins, you create her user account:
sudo useradd -c "Alice CEO" -u 1001 alice
sudo passwd aliceYou set a temporary password and force her to change it on first login using:
sudo chage -d 0 aliceAs the company grows, you get a new graphic designer, Bob. You create his account:
sudo useradd -c "Bob Designer" -u 1002 bobNow, all the designers need to access a shared folder called /srv/projects. You could add each designer's user account to the permissions of that folder, but that would be messy and error-prone. Instead, you create a group for them:
sudo groupadd designersThen, you make Bob and his future colleagues secondary members of this group:
sudo usermod -aG designers bobNow, you set the permissions on the /srv/projects folder. You make Alice the owner (since she is the boss), and you change the group to 'designers':
sudo chown alice:designers /srv/projects
sudo chmod 2770 /srv/projectsThe number 2770 means:
The owner (Alice) gets read, write, and execute access (7)
The group (designers) gets the same permissions (7)
Others (anyone else) get nothing (0)
The leading 2 is the 'setgid' bit, which ensures any new file created in that folder automatically belongs to the 'designers' group, not the creator's primary group.
Later, a designer named Carol leaves the company. You cannot just delete her account without careful thought; she might have personal files in her home directory that the company needs or that need to be archived. You first lock her account to prevent login:
sudo usermod -L carolYou then check her home directory (/home/carol) for any company assets. Once you have transferred what you need, you back up the home directory and then delete her account with:
sudo userdel -r carolThe -r flag ensures her home directory and mail spool are removed, keeping the system clean.
You also have a freelancer who needs temporary access for two weeks. Instead of adding them to the 'designers' group permanently, you create a separate group called 'temp' and set a password expiration policy on their user account so it automatically expires after 14 days:
sudo useradd -c "Freelancer Dave" -G temp dave
sudo chage -E $(date -d "+14 days" +%Y-%m-%d) daveThis real-world workflow shows you exactly why the EX200 exam tests this subject so heavily: it is not just about memorising commands, but about designing a secure, manageable system for real people with real jobs. You have to think about who gets access now, who gets access later, and who needs to be cut off cleanly when they leave.
The EX200 exam (now part of RHCSA under Red Hat Enterprise Linux 9) will test 'User and Group Administration' in a very direct, practical way. You will not be asked high-level theory questions like 'What is the purpose of /etc/shadow?' Instead, you will be given a set of requirements and you must execute the correct commands to fulfil them. The exam is performance-based, meaning you log into a live system and complete tasks. Here is exactly what to expect and how to avoid the common traps.
What they love to test: - useradd, usermod, userdel with specific options. Expect tasks like 'Create a user named jane with UID 2000 and primary group sales'. - groupadd, groupmod, groupdel tasks, often requiring you to create a group first and then add users to it. - Setting password expiry rules using chage. A classic task is 'Set the password of user bob to expire every 45 days, with a warning 3 days before expiry'. - Using the -aG flag with usermod. This is the most common trap. If you use usermod -G designers bob without the -a (append) flag, you will remove bob from all OTHER secondary groups he might be in, effectively locking him out of other resources. The correct pattern is always usermod -aG groupname username. - Understanding UID and GID ranges. Regular user UIDs start at 1000. System accounts (like daemons) use UIDs below 1000. Creating a user with a UID of 50 is unusual and would be a explicit request. - The /etc/skel directory. When you create a user with useradd, the contents of /etc/skel are copied to the new user's home directory. The exam may ask you to ensure new users have a specific file (like a welcome message) in their home directory, which means you would create that file in /etc/skel first.
Key traps to watch for:
Forgetting the -r flag with userdel. The exam might not explicitly say 'delete the user and their home directory', so if you just run userdel, the home directory remains, and if they check for disk space, you could lose marks.
Confusing primary and secondary groups. When you create a user with useradd without the -g flag, the system creates a private group (same name as the user). When you later add that user to another group with usermod -aG, you are adding a secondary membership. They might ask you to change a user's primary group, which requires the -g flag (lowercase) on usermod, not -G (uppercase).
The sudoers file. You must know how to use visudo (the safe way to edit sudoers) to grant specific users or groups the ability to run commands as root. They will not ask you to edit the file directly with a text editor; they expect visudo.
Password aging vs. account expiry. chage -M sets password max age; chage -E sets the account expiry date (a date after which the account cannot be used at all). These are different and the exam will test both.
The answer pattern for most tasks is a single command. If the task says 'Create user harry with a home directory of /home/charry', your answer is:
useradd -d /home/charry harryIf the task says 'Ensure harry can use sudo without a password', you would edit the sudoers file and add:
harry ALL=(ALL) NOPASSWD: ALLPractise these commands in a virtual machine until you can do them without looking at notes. The exam is timed, and fumbling for the command syntax will cost you.
The useradd command creates a user but does not set a password; you must separately run passwd to assign one.
Always use the -a flag with usermod -G to append a user to a secondary group without removing them from other groups.
The /etc/shadow file is only readable by root and stores the encrypted password hash, not the plain text password.
The chage command controls password expiry settings, and the -d 0 flag forces a user to change their password on the very next login.
Deleting a user with userdel -r removes both the account and their home directory and mail spool in one step.
The /etc/skel directory acts as a template; any files placed there will appear in every new user's home directory automatically.
These come up on the exam all the time. Here's how to tell them apart.
Primary Group
Automatically assigned to every file a user creates.
Only one per user (set in /etc/passwd or via useradd -g).
Defined by GID in the user's entry in /etc/passwd.
Secondary Group
Grants access to shared resources and directories.
A user can belong to many secondary groups simultaneously.
Managed via usermod -aG and listed in /etc/group.
useradd
Creates a brand new user account from scratch.
Copies skeleton files from /etc/skel into the new home directory.
Does not modify existing user accounts.
usermod
Modifies an existing user's settings (groups, UID, home directory).
Does not create a home directory or copy skeleton files.
Used to lock accounts, change expiry dates, and adjust group memberships.
chage -M
Sets the maximum number of days a password can be used before it must be changed.
Affects password expiration, not account access.
After the max days, the user is forced to change their password.
chage -E
Sets an absolute date when the account itself becomes disabled and cannot be used.
Affects account availability, regardless of password status.
The account is locked after this date, even if the password is correct.
userdel (no flag)
Removes the user entry from /etc/passwd and /etc/shadow.
Leaves the user's home directory and mail spool intact on disk.
Useful when you need to archive or inspect data before removal.
userdel -r
Removes the user entry from /etc/passwd and /etc/shadow.
Also removes the user's home directory and mail spool files.
Final clean-up; no recovery of user files after running.
Mistake
Deleting a user with userdel also automatically deletes their home directory and all their files.
Correct
By default, userdel only removes the user from /etc/passwd and /etc/shadow. Their home directory and files remain on disk unless you use the -r option.
This misconception comes from a desire for simplicity. Beginners assume a single command should do a complete clean-up, but Red Hat intentionally leaves the home directory to allow an admin to recover files before fully purging the user.
Mistake
Adding a user to a group with usermod -G groupname appends them to the group without affecting their other group memberships.
Correct
Without the -a (append) flag, the -G option replaces the user's entire list of secondary groups with only the group you specify, removing them from all other groups.
The -G flag is easily confused with 'grant' or 'give', but it actually means 'set the groups list to this'. The -a flag is the safety guard. This is a classic exam trap because it feels counterintuitive.
Mistake
The /etc/shadow file can be viewed by any user because it is just a text file.
Correct
Only the root user and users with appropriate sudo privileges can read /etc/shadow. It contains the password hash and is protected by strict file permissions (000 or 400).
Beginners see that /etc/passwd is world-readable and assume the same is true for its companion file. They do not realise that moving the password hash to /etc/shadow was a specific security improvement to prevent password cracking.
Mistake
A user's primary group is the same as the groups they belong to for accessing shared files.
Correct
A user's primary group is the group automatically assigned to files they create. Secondary groups (added with -aG) are what grant access to shared resources. They are distinct concepts.
The word 'primary' sounds like 'most important', so beginners assume it controls all access. Actually, for shared folder access, secondary groups are far more relevant.
Mistake
You do not need to worry about password policies because the user will just be told to change their password regularly.
Correct
Systems enforce password policies programmatically using the chage command. If you do not set -M, the password never expires, which is a major security vulnerability. The exam actively tests this.
In small or informal environments, admins rely on human communication. The exam tests that you know the system enforces rules without manual intervention.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
-G (uppercase) adds the user to secondary groups. -g (lowercase) changes the user's primary group. They are completely different options and using the wrong one will not do what you want.
The userdel command does not remove the home directory by default. You must use userdel -r to remove the user's home directory and mail spool along with the account.
Run sudo chage -d 0 username. This sets the password's last change date to 0, forcing the system to prompt for a new password on the next login.
The 'x' indicates that the user's password hash is stored in the /etc/shadow file instead of directly in /etc/passwd for security reasons.
Yes. Use usermod -aG group1,group2,group3 username. The -a flag appends, so you must use it to avoid overwriting existing group memberships.
Run the groups command followed by the username, like `groups jane`. You can also use `id jane` for more detailed UID and GID information.
You've finished User and Group Administration. Continue through the EX200 study guide to build a complete picture of the exam.
Done with this chapter?