Linux User & Group Management for Security: Complete 2026 Guide [Tutorial 15/105]

## Introduction to Linux User & Group Management Linux administration is a fundamental skill for any security professional, system administrator, or penetration tester. Understanding user and group management is critical not only for maintaining secure systems but also for identifying privilege escalation vectors during security assessments. In this comprehensive guide—the 15th tutorial in our 105-part Kali Linux series—we'll explore the complete ecosystem of Linux user and group management. Whether you're just getting started with [Kali Linux installation](/tutorials/how-to-install-kali-linux-in-virtualbox-complete-2026-guide) or preparing for advanced penetration testing, mastering these concepts is essential. By the end of this tutorial, you'll understand how Linux stores user information, how to manage users and groups effectively, and—most importantly—how these concepts relate to security and privilege escalation attacks. **⚡ Quick Navigation:**
- [Understanding /etc/passwd](#passwd-structure) - [The /etc/shadow File](#shadow-file) - [Adding & Managing Users](#user-management) - [Group Management](#group-management) - [Sudo Configuration](#sudo-configuration) - [Security & Pentesting Perspective](#security-perspective) - [FAQ](#faq)
## Understanding the /etc/passwd File Structure The `/etc/passwd` file is the cornerstone of Linux user administration. Despite its name, modern Linux systems don't store passwords here (they're in `/etc/shadow`). Instead, this file contains essential user account information readable by all users on the system. ### Anatomy of /etc/passwd Entries Let's examine a typical entry from `/etc/passwd`: `kali:x:1000:1000:Kali Linux,,,:/home/kali:/bin/bash ``` Each line contains seven colon-separated fields:
- **Username** (`kali`): The login name used to authenticate - **Password placeholder** (`x`): Indicates the encrypted password is in /etc/shadow - **User ID (UID)** (`1000`): Unique numeric identifier for the user - **Group ID (GID)** (`1000`): Primary group numeric identifier - **GECOS field** (`Kali Linux,,,`): Comment field for user information (full name, room number, phone, etc.) - **Home directory** (`/home/kali`): User's home directory path - **Login shell** (`/bin/bash`): Default shell when user logs in
### Special User Accounts When reviewing `/etc/passwd`, you'll notice several system accounts with UIDs below 1000: `root:x:0:0:root:/root:/bin/bash nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin ```
- **root (UID 0)**: The superuser with unrestricted access - **nobody**: Unprivileged user for running untrusted processes - **www-data**: Web server user (Apache/Nginx) - **System services**: Many daemons run as dedicated users (mysql, postgres, ssh, etc.)
🔒 **Security Note:** From a penetration testing perspective, compromising service accounts like www-data is often the first step in a privilege escalation chain. Understanding which groups these accounts belong to is crucial for [penetration testing methodology](/articles/pentest-methodology-the-complete-guide-for-2026). ## The /etc/shadow File: Where Passwords Live The `/etc/shadow` file stores actual password hashes and password policy information. Unlike `/etc/passwd`, this file is only readable by root, providing a critical security layer. ### Shadow File Structure `kali:$6$rounds=5000$salt$hash:19000:0:99999:7::: ``` The nine colon-separated fields are:
- **Username**: Matches the entry in /etc/passwd - **Encrypted password**: The hashed password (more on this below) - **Last change**: Days since Jan 1, 1970 that password was last changed - **Minimum days**: Minimum days between password changes - **Maximum days**: Maximum days password is valid - **Warning period**: Days before password expiry to warn user - **Inactivity period**: Days after expiry before account is disabled - **Expiration date**: Days since Jan 1, 1970 when account expires - **Reserved field**: Currently unused
### Password Hash Formats The password field format tells us which hashing algorithm is used:
- `$1$`: MD5 (legacy, insecure) - `$5$`: SHA-256 - `$6$`: SHA-512 (current default on most systems) - `$y$`: yescrypt (newer, more secure) - `!` or `*`: Account locked/no password set
To view the shadow file (requires root): `sudo cat /etc/shadow | grep kali ``` ## Understanding /etc/group: Group Management The `/etc/group` file defines all groups on the system and their members. Groups are essential for Linux administration, providing a way to manage permissions for multiple users simultaneously. ### Group File Format `sudo:x:27:kali,john docker:x:999:kali wireshark:x:130:kali ``` Each line contains four fields:
- **Group name**: Human-readable group identifier - **Group password**: Usually x or blank (rarely used) - **Group ID (GID)**: Numeric group identifier - **Group members**: Comma-separated list of usernames
### Security-Critical Groups Certain groups grant significant privileges and are prime targets during privilege escalation:
- **sudo/wheel**: Can execute commands as root - **docker**: Can run containers (effectively root access) - **lxd/lxc**: Container management (privilege escalation vector) - **disk**: Raw disk access (can read/write entire filesystem) - **video**: Access to framebuffer devices - **wireshark**: Can capture network packets - **www-data**: Web server group - **adm**: Can read log files in /var/log
## Adding and Managing Users in Linux Linux administration requires a solid understanding of user creation and modification commands. Let's explore the primary tools available. ### Creating Users: useradd vs adduser Linux provides two main commands for creating users, each with different approaches: #### useradd: The Low-Level Command `useradd` is the native binary that directly modifies system files. It requires explicit options for a complete setup: `# Basic user creation (minimal setup) sudo useradd pentest1 # Create user with home directory and default shell sudo useradd -m -s /bin/bash pentest2 # Create user with specific UID and custom home directory sudo useradd -u 1500 -d /home/custom -m -s /bin/bash pentest3 # Create user with comment and multiple groups sudo useradd -m -c "Pentester Account" -G sudo,wireshark -s /bin/bash pentest4 ``` **Common useradd options:**
- `-m`: Create home directory - `-s`: Specify login shell - `-u`: Set specific UID - `-g`: Set primary group - `-G`: Add to supplementary groups - `-c`: Add comment (GECOS field) - `-d`: Specify home directory path - `-e`: Account expiration date (YYYY-MM-DD)
#### adduser: The Interactive Helper Script On Debian-based systems (including Kali Linux), `adduser` is a Perl script that provides a more user-friendly interface: `# Interactive user creation (recommended for beginners) sudo adduser pentest5 ``` This command will interactively prompt for:
- Password (twice for confirmation) - Full name - Room number, phone numbers - Confirmation
For Kali Linux beginners who have just completed the [default password and user management guide](/tutorials/kali-linux-default-password-user-management-guide-for-beginners-2026), `adduser` is typically the recommended approach. ### Setting User Passwords `# Set password for user sudo passwd pentest1 # Force password change on next login sudo passwd -e pentest1 # Lock a user account sudo passwd -l pentest1 # Unlock a user account sudo passwd -u pentest1 ``` ### Modifying Existing Users: usermod The `usermod` command allows you to modify existing user accounts without deletion and recreation: `# Add user to supplementary group (append mode) sudo usermod -aG sudo pentest1 # Change username sudo usermod -l newname oldname # Change home directory and move contents sudo usermod -d /home/newhome -m pentest1 # Change default shell sudo usermod -s /bin/zsh pentest1 # Change primary group sudo usermod -g developers pentest1 # Set account expiration date sudo usermod -e 2026-12-31 pentest1 # Lock account sudo usermod -L pentest1 # Unlock account sudo usermod -U pentest1 ``` ⚠️ **Warning:** When adding users to groups, always use `-aG` (append) instead of just `-G`. Using `-G` alone will remove the user from all other supplementary groups! ### Deleting Users: userdel `# Delete user (keeps home directory and files) sudo userdel pentest1 # Delete user and remove home directory sudo userdel -r pentest1 # Force deletion even if user is logged in sudo userdel -f pentest1 ``` ## Group Management Commands Effective Linux administration requires managing groups alongside users. Here's your complete toolkit: ### Creating Groups `# Create a new group sudo groupadd developers # Create group with specific GID sudo groupadd -g 2000 security-team # Create system group (GID < 1000) sudo groupadd -r webservices ``` ### Modifying Groups `# Rename a group sudo groupmod -n newgroupname oldgroupname # Change GID sudo groupmod -g 2500 developers ``` ### Managing Group Membership Multiple commands can manage group membership: `# Add user to group using gpasswd sudo gpasswd -a pentest1 docker # Remove user from group using gpasswd sudo gpasswd -d pentest1 docker # Add multiple users to group sudo gpasswd -M pentest1,pentest2,pentest3 security-team # Set group administrator sudo gpasswd -A pentest1 security-team ``` ### Viewing User Groups `# Show groups for current user groups # Show groups for specific user groups pentest1 # Detailed group information id pentest1 # List all members of a group getent group sudo ``` ### Deleting Groups `# Delete a group sudo groupdel developers ``` Note: You cannot delete a group if it's the primary group of any user. ## Sudo Configuration: Granting Root Privileges The `sudo` (superuser do) mechanism is central to Linux administration and security. It allows permitted users to execute commands as root or other users. ### Basic Sudo Usage `# Execute single command as root sudo apt update # Execute command as different user sudo -u www-data whoami # Start interactive root shell sudo -i # Start shell as root maintaining environment sudo -s # Edit file with elevated privileges sudo nano /etc/sudoers # Check sudo privileges sudo -l ``` ### The /etc/sudoers File The `/etc/sudoers` file controls who can use sudo and what commands they can run. **Never edit this file directly with a text editor—always use `visudo`**, which performs syntax checking to prevent lockouts. `# Edit sudoers file safely sudo visudo ``` #### Sudoers File Syntax Basic format: `user HOST=(USER:GROUP) COMMANDS` `# Allow user to run all commands as root pentest1 ALL=(ALL:ALL) ALL # Allow without password prompt pentest2 ALL=(ALL) NOPASSWD: ALL # Allow specific commands only pentest3 ALL=(ALL) /usr/bin/apt, /usr/bin/systemctl # Allow group members %sudo ALL=(ALL:ALL) ALL # Run specific commands as specific user pentest4 ALL=(www-data) /usr/bin/php # Allow commands without password pentest5 ALL=(ALL) NOPASSWD: /usr/bin/nmap, /usr/bin/tcpdump ``` ### Sudoers Drop-in Files Instead of modifying `/etc/sudoers`, you can create files in `/etc/sudoers.d/`: `# Create drop-in file sudo visudo -f /etc/sudoers.d/pentesters ``` Add your rules: `# Allow pentest team specific tools %security-team ALL=(ALL) NOPASSWD: /usr/bin/nmap, /usr/bin/metasploit-framework ``` ### Switching Users: su vs sudo `# Switch to root user (requires root password) su - # Switch to specific user su - pentest1 # Run command as root using sudo (requires user password) sudo -i # Start shell as user sudo -u pentest1 -s ``` **Key Difference:** `su` requires the target user's password, while `sudo` requires your own password (if you have sudo privileges). After [configuring your Kali Linux system](/tutorials/kali-linux-configuration-essential-settings-updates-2026-guide), you'll typically use sudo for administrative tasks. ## Password Aging and Account Security Linux administration includes managing password policies to enforce security standards. ### The chage Command `chage` (change age) manages password expiration and aging policies: `# View password aging information sudo chage -l pentest1 # Set password expiry date sudo chage -E 2026-12-31 pentest1 # Set maximum password age (90 days) sudo chage -M 90 pentest1 # Set minimum days between password changes sudo chage -m 7 pentest1 # Set warning period (7 days before expiry) sudo chage -W 7 pentest1 # Set inactivity period (30 days after expiry) sudo chage -I 30 pentest1 # Force password change on next login sudo chage -d 0 pentest1 # Remove account expiration sudo chage -E -1 pentest1 ``` ### Account Locking and Unlocking `# Lock account (multiple methods) sudo passwd -l pentest1 sudo usermod -L pentest1 # Unlock account sudo passwd -u pentest1 sudo usermod -U pentest1 # Check if account is locked sudo passwd -S pentest1 ``` When an account is locked, an exclamation mark (!) is prepended to the password hash in /etc/shadow. ## Security and Pentesting Perspective Understanding Linux user and group management isn't just about administration—it's essential for identifying privilege escalation vectors during penetration testing. ### Privilege Escalation via Group Membership As a penetration tester following a solid [penetration testing methodology](/articles/pentest-methodology-the-complete-guide-for-2026), you should always check group memberships when you compromise an account. #### Docker Group Exploitation If a user is in the `docker` group, they can escalate to root: `# Check if user is in docker group groups id # Mount host filesystem and spawn root shell docker run -v /:/mnt --rm -it alpine chroot /mnt sh # Or use simple privilege escalation docker run -v /:/hostfs --rm -it alpine sh cd /hostfs/root cat .ssh/id_rsa ``` #### LXD/LXC Group Exploitation `# Initialize LXD if not initialized lxd init --auto # Import alpine image lxc image import alpine-image.tar.gz --alias myimage # Create privileged container mounting host root lxc init myimage privesc -c security.privileged=true lxc config device add privesc host-root disk source=/ path=/mnt/root recursive=true lxc start privesc lxc exec privesc /bin/sh ``` #### Disk Group Exploitation Users in the `disk` group can read/write raw disk devices: `# List block devices lsblk # Read SSH keys directly from disk debufs /dev/sda1 debugfs: cat /root/.ssh/id_rsa # Or mount the filesystem mkdir /tmp/mount mount /dev/sda1 /tmp/mount cat /tmp/mount/etc/shadow ``` #### Sudo Group = Root Access Obviously, users in the `sudo` or `wheel` group can become root: `sudo su - sudo -i ``` ### Enumerating Users and Groups During Pentests `# List all users with UID >= 1000 (human users) cat /etc/passwd | awk -F: '$3 >= 1000 {print $1}' # List all users with bash shell cat /etc/passwd | grep "/bin/bash" # Find users with sudo privileges grep -Po '^sudo.+:\K.*$' /etc/group # Check your own sudo permissions sudo -l # Find world-writable files owned by root find / -type f -perm -002 -user root 2>/dev/null # Find SUID binaries find / -type f -perm -4000 2>/dev/null # Check for misconfigured sudo (GTFOBins) sudo -l # Then check https://gtfobins.github.io/ ``` ### Defensive Measures From a defensive Linux administration standpoint:
- **Principle of Least Privilege:** Only grant users the minimum groups necessary - **Audit Group Membership:** Regularly review who is in privileged groups - **Avoid NOPASSWD:** Require password for sudo unless absolutely necessary - **Use Specific Commands:** In sudoers, specify exact command paths rather than ALL - **Monitor /etc/passwd and /etc/shadow:** Use file integrity monitoring (AIDE, Tripwire) - **Enforce Password Policies:** Use PAM modules for complexity requirements - **Regular Audits:** Check for accounts with UID 0 other than root
`# Find all UID 0 accounts (should only be root) awk -F: '$3 == 0 {print $1}' /etc/passwd # Find accounts with empty passwords sudo awk -F: '$2 == "" {print $1}' /etc/shadow # Check for duplicate UIDs cut -d: -f3 /etc/passwd | sort | uniq -d ``` ## Practical Scenarios for Linux Administration ### Scenario 1: Setting Up a Web Developer Account `# Create user with home directory sudo adduser webdev # Add to www-data group for web files access sudo usermod -aG www-data webdev # Grant limited sudo for web services only sudo visudo -f /etc/sudoers.d/webdev ``` Add line: `webdev ALL=(ALL) NOPASSWD: /usr/sbin/service nginx *, /usr/sbin/service apache2 * ``` ### Scenario 2: Creating a Pentesting Lab User `# Create pentester account sudo adduser pentester # Add to security-relevant groups sudo usermod -aG wireshark,docker pentester # Allow specific security tools without password sudo visudo -f /etc/sudoers.d/pentester ``` Add: `pentester ALL=(ALL) NOPASSWD: /usr/bin/nmap, /usr/bin/tcpdump, /usr/bin/john ``` ### Scenario 3: Temporary Contractor Access `# Create user with expiration sudo useradd -m -e 2026-03-31 -s /bin/bash contractor1 sudo passwd contractor1 # Set password to expire forcing change sudo chage -d 0 contractor1 # Set maximum password age sudo chage -M 60 contractor1 ``` ## Linux Administration Best Practices
- **Never Share Root Password:** Use sudo for privilege delegation - **Regular Audits:** Review user accounts, group memberships, and sudo rules monthly - **Strong Password Policy:** Enforce minimum length, complexity, and expiration - **Disable Unused Accounts:** Lock or delete accounts no longer needed - **Use SSH Keys:** Disable password authentication for SSH when possible - **Monitor Sudo Usage:** Review `/var/log/auth.log` for sudo activity - **Separate Accounts:** Use dedicated accounts for different roles/services - **Document Everything:** Maintain records of users, groups, and their purposes - **Test Before Production:** Try user management changes in VM first - **Backup Critical Files:** Keep backups of `/etc/passwd`, `/etc/shadow`, `/etc/group`
## Common Troubleshooting ### User Can't Sudo `# Check if user is in sudo group groups username # Add to sudo group sudo usermod -aG sudo username # User must log out and back in for group changes to take effect ``` ### "Username is not in the sudoers file. This incident will be reported." This means the user lacks sudo privileges. Fix it: `# Switch to root su - # Add user to sudo group usermod -aG sudo username # Or edit sudoers file visudo ``` ### Home Directory Not Created If you used `useradd` without `-m`: `# Create home directory manually sudo mkdir /home/username sudo cp -r /etc/skel/. /home/username/ sudo chown -R username:username /home/username sudo chmod 700 /home/username ``` ### Can't Delete User (User Currently Logged In) `# Check if user has running processes ps -u username # Kill user processes sudo pkill -u username # Or force deletion sudo userdel -f username ``` ## Quick Reference: Essential Linux Administration Commands | `useradd` | Create user (low-level) | `sudo useradd -m -s /bin/bash john` | `adduser` | Create user (interactive) | `sudo adduser john` | `usermod` | Modify user | `sudo usermod -aG sudo john` | `userdel` | Delete user | `sudo userdel -r john` | `passwd` | Set/change password | `sudo passwd john` | `groupadd` | Create group | `sudo groupadd developers` | `groupmod` | Modify group | `sudo groupmod -n newname oldname` | `groupdel` | Delete group | `sudo groupdel developers` | `gpasswd` | Manage group membership | `sudo gpasswd -a john docker` | `groups` | Show user's groups | `groups john` | `id` | Show user/group IDs | `id john` | `su` | Switch user | `su - john` | `sudo` | Execute as superuser | `sudo apt update` | `visudo` | Edit sudoers file safely | `sudo visudo` | `chage` | Modify password aging | `sudo chage -M 90 john` | `getent` | Query system databases | `getent passwd john` | `who` | Show logged in users | `who` | `w` | Show who's logged in and what they're doing | `w` | `last` | Show login history | `last john` | `lastlog` | Show most recent logins | `lastlog` ## Advanced Topics ### PAM (Pluggable Authentication Modules) PAM provides flexible authentication mechanisms. Configuration files are in `/etc/pam.d/`: `# Require strong passwords sudo apt install libpam-pwquality sudo nano /etc/security/pwquality.conf ``` Set: `minlen = 12 minclass = 3 maxrepeat = 2 ``` ### User Skeleton Files The `/etc/skel/` directory contains default files copied to new users' home directories: `# Add custom bashrc for all new users sudo nano /etc/skel/.bashrc # Add welcome message sudo nano /etc/skel/README.txt ``` ### Login Scripts and Limits `# Set resource limits sudo nano /etc/security/limits.conf ``` Example: `pentest1 hard nproc 100 pentest1 hard nofile 1024 ``` ## External Resources
- [Linux.org Official Documentation](https://www.linux.org/) - [Kali Linux Official Documentation](https://www.kali.org/docs/) - [Linux Man Pages: passwd(5)](https://www.linux.org/docs/man5/passwd.html) - [Linux Man Pages: shadow(5)](https://www.linux.org/docs/man5/shadow.html)
## Frequently Asked Questions (FAQ) ### 1. What's the difference between useradd and adduser in Linux administration? `useradd` is the low-level system binary that directly modifies `/etc/passwd`, `/etc/shadow`, and `/etc/group`. It requires explicit flags to create a home directory or set a shell. `adduser` is a Perl script (on Debian-based systems like Kali Linux) that provides a more user-friendly, interactive interface. For beginners, `adduser` is recommended because it automatically creates the home directory, copies skeleton files, prompts for password, and asks for user information interactively. For automation scripts, `useradd` is preferred because of its consistent behavior across distributions. ### 2. How can I check what groups a user belongs to in Linux? You can check group membership using several commands: `groups username` shows a simple list of group names; `id username` displays UID, GID (primary group), and all supplementary groups with their numeric IDs; `getent group groupname` shows all members of a specific group. For the currently logged-in user, simply run `groups` without arguments. Remember that group changes only take effect after the user logs out and back in, so if you just added someone to a group, they'll need to start a new session to see the change with `groups`. ### 3. Why is being in the docker group a security risk? Membership in the `docker` group is equivalent to having root access on the system. This is because Docker allows users to mount the host filesystem inside containers and run containers with elevated privileges. An attacker with docker group membership can easily mount the entire root filesystem (`/`) into a container and access any file on the host, including `/etc/shadow`, SSH keys, or sensitive configuration files. They can also use the container to spawn a privileged shell with full root access. This makes the docker group one of the most critical privilege escalation vectors during penetration testing. Similar risks apply to groups like `lxd`, `lxc`, and `disk`. ### 4. How do I safely edit the sudoers file in Linux? Always use the `sudo visudo` command to edit the sudoers file—never edit `/etc/sudoers` directly with nano, vim, or other text editors. The `visudo` command performs syntax checking before saving changes, preventing configuration errors that could lock you out of sudo access completely. If you make a syntax error, visudo will alert you and ask if you want to re-edit or abort. For adding custom rules, use drop-in files in `/etc/sudoers.d/` with `sudo visudo -f /etc/sudoers.d/filename`. This keeps your custom rules separate from the main sudoers file and makes management easier. ### 5. What does the 'x' in /etc/passwd mean? The 'x' in the second field of `/etc/passwd` is a placeholder indicating that the user has an encrypted password stored in the `/etc/shadow` file. In older UNIX systems, the actual encrypted password hash was stored directly in `/etc/passwd`, but since that file is world-readable (any user can view it), this posed a security risk—attackers could copy the hashes and attempt offline password cracking. Modern Linux systems use shadow passwords: the actual password hashes are stored in `/etc/shadow`, which is only readable by root. If you see a '*' or '!' instead of 'x', it typically means the account is locked or has no password set and cannot be used for login. ## Conclusion Mastering Linux administration through user and group management is essential whether you're securing systems or conducting penetration tests. Understanding the structure of `/etc/passwd`, `/etc/shadow`, and `/etc/group`, along with commands like `useradd`, `usermod`, `groupadd`, and `sudo` configuration, gives you the foundation for both defensive security and offensive security testing. From a penetration testing perspective, always enumerate group memberships when you compromise an account—groups like `docker`, `lxd`, `disk`, and `sudo` are prime vectors for privilege escalation. From a defensive standpoint, apply the principle of least privilege, regularly audit group memberships, and implement strong password policies. This tutorial—the 15th in our comprehensive 105-part Kali Linux series—provides you with practical, hands-on knowledge for real-world Linux administration and security work. Practice these commands in your lab environment (perhaps the [Kali Linux VM you've set up](/tutorials/how-to-install-kali-linux-in-virtualbox-complete-2026-guide)), and you'll develop the muscle memory that separates theory from expertise. **Next Steps:**
- Practice creating users and groups in a test environment - Set up sudo rules for specific use cases - Audit your system for potentially dangerous group memberships - Explore GTFOBins for sudo privilege escalation techniques - Continue to Tutorial 16 in our series for more advanced Kali Linux topics
📝 **Written by:** Andrax Pentester / Syed Abrar 🏷️ **Tutorial:** 15 of 105 🔖 **Category:** Kali Linux Administration & Security ⏰ **Last Updated:** 2026 *Stay secure, keep learning, and remember: with great privilege comes great responsibility in Linux administration.*