7.2 Managing Unix Users and Groups

Kali Linux Certified Professional KLCP

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 How to Use This Guide & Study Strategy 1.3 PEN-103 Syllabus & Study Path

2 About Kali Linux

2.1 A Bit of History: From BackTrack to Kali 2.2 Kali's Relationship with Debian 2.3 Purpose and Use Cases 2.4 Main Features and Design Policies

3 Getting Started with Kali Linux

3.1 Downloading and Verifying a Kali ISO 3.2 Booting Kali in Live Mode 3.3 Installation Options Overview 3.4 Troubleshooting Installations

4 Linux Fundamentals

4.1 What Linux Is and What It Does 4.2 The Command Line 4.3 The Filesystem Hierarchy Standard 4.4 Useful Commands: Files, Search, Environment

5 Permissions and Process Management

5.1 File Permissions and Ownership 5.2 Managing Processes 5.3 Shells, Variables, and the Environment

6 Installing Kali Linux

6.1 Minimal Installation Requirements 6.2 Step-by-Step Installation on a Hard Drive 6.3 Unattended Installations with Preseeding 6.4 ARM Installations

7 Configuring the Network, Users, and SSH

7.1 Configuring the Network 7.2 Managing Unix Users and Groups 7.3 Configuring SSH

8 Configuring Services

8.1 Apache Web Server 8.2 PostgreSQL Database 8.3 Managing Services with systemd

9 Helping Yourself and Getting Help

9.1 Documentation Sources 9.2 Kali Linux Communities 9.3 Filing Good Bug Reports

10 Security Policy and Network Services

10.1 Defining a Security Policy 10.2 Possible Security Measures 10.3 Securing Network Services

11 Firewalling and Monitoring

11.1 Netfilter and iptables Behavior 11.2 Writing iptables Rules and NAT 11.3 Monitoring and Logging

12 Debian Package Management: APT

12.1 Introduction to APT 12.2 The sources.list File 12.3 Kali Repositories 12.4 Basic Package Interaction with apt

13 dpkg and Advanced Package Management

13.1 dpkg Fundamentals 13.2 Inspecting .deb Files and Package State 13.3 Maintainer Scripts and Conffiles 13.4 APT Pinning and Package Authenticity

14 Advanced Usage

14.1 Modifying and Rebuilding Kali Packages 14.2 Recompiling the Kernel 14.3 Building Custom Kali Live ISO Images 14.4 USB Persistence with LUKS Encryption

15 Kali Linux in the Enterprise

15.1 Network Installation with PXE Boot 15.2 Configuration Management with SaltStack 15.3 Metapackages and Custom Repositories 15.4 Configuration Packages and Forking

16 Introduction to Security Assessments

16.1 Kali Linux in an Assessment 16.2 Types of Assessments 16.3 Types of Attacks 16.4 Formalization and the Road Ahead

7.2 Managing Unix Users and Groups

Key Takeaways Explain This Topic AI

adduser is Debian's interactive, high-level wrapper that creates a home directory and copies /etc/skel; useradd is the low-level tool that does neither unless you pass flags like -m

/etc/passwd holds public account fields (name, UID, home, shell) while /etc/shadow holds the encrypted password hash and aging data, readable only by root

Use usermod -aG sudo <user> to grant sudo rights — forgetting -a replaces the user's supplementary groups instead of appending

Since Kali 2020.1 the default live/install user is the non-root account kali (password kali); running daily work as root is discouraged, with root actions performed through sudo

passwd <user> changes passwords as root; deluser --remove-home <user> deletes an account along with its home directory

Last updated: July 2026

Creating Users: adduser vs useradd

Debian (and therefore Kali) offers two account-creation commands, and the exam expects you to distinguish them. useradd is the low-level, non-interactive binary from the shadow password suite, shipped on Debian and Kali in the passwd package. Called bare — useradd alice — it creates only the account entry: no home directory, no files copied, and on Debian the default shell may not even be set the way you expect. To get a usable account you must spell it out: useradd -m -s /bin/bash alice creates the home directory ( -m ) and sets the login shell ( -s ).

adduser is a Perl wrapper around useradd, driven by /etc/adduser.conf . It is interactive and opinionated: adduser alice prompts for a password and optional GECOS details, creates /home/alice , populates it from the /etc/skel skeleton directory, picks the next free UID, and sets the shell. For day-to-day administration on Kali, adduser is the recommended tool; useradd is for scripts where you want exact, flag-controlled behavior. The same split exists on the group side: addgroup admins (friendly wrapper) versus the low-level groupadd .

The Account Databases: /etc/passwd and /etc/shadow

Every local account is a line in /etc/passwd with seven colon-separated fields: kali:x:1000:1000:Kali,,,:/home/kali:/usr/bin/zsh

• Username — kali
• Password placeholder — always x on modern systems; the real hash lives in /etc/shadow
• UID — user ID; regular users start at 1000, root is 0
• GID — primary group ID
• GECOS — comment field (full name, room, phone)
• Home directory

Login shell — the image's own kali account uses zsh ( /usr/bin/zsh ) since Kali 2020.4, but accounts you create afterwards still get /bin/bash from adduser (and /bin/sh from a bare useradd ); /usr/sbin/nologin here denies interactive login (common for service accounts)

/etc/passwd must be world-readable because so many programs map UIDs to names. That is precisely why passwords were moved to /etc/shadow , which is readable only by root. Its nine colon-separated fields: username, encrypted password hash, date of last change, minimum days between changes, maximum days a password is valid, warning period, inactivity lockout, account expiration date, and a final reserved field. The hash field tells a story on sight: $y$ or $6$ prefixes indicate yescrypt or SHA-512 crypt, ! or * is not a valid crypt() result, so no password can ever match and password login is impossible (SSH keys may still work) — which is different from an empty field, meaning no password is required at all, and ! in front of a hash is exactly what passwd -l writes to lock an account. Aging is manipulated with chage , for example chage -l alice to list her policy.

Groups and /etc/group

/etc/group lists each group as name:x:GID:member-list , where the member list holds supplementary members only — a user's primary group comes from /etc/passwd and need not be repeated. Group password hashes, rarely used, live in /etc/gshadow . Every user gets a same-named private group by default (user private group scheme), so id alice shows uid=1000(alice) gid=1000(alice) groups=1000(alice),... .

• To modify membership, the canonical command is: usermod -aG sudo alice
• G sets the user's supplementary groups to exactly the list you give
• a appends instead of replacing

Omitting -a is the classic disaster: usermod -G wireshark alice silently strips alice from every other supplementary group, including sudo. The exam loves this distinction. Changes to group membership apply to new logins — a running session keeps its old groups until re-login (or newgrp ). Other useful group commands: gpasswd -a alice wireshark (add one member), gpasswd -d alice wireshark (remove), groups alice to view membership, and addgroup / delgroup / groupmod to create, remove, or renumber groups. Debian's own shorthand for adding an existing user to an existing group — the form Kali Linux Revealed documents — is simply adduser alice wireshark , and newgrp / sg switch group identity inside the current session.

Two more command families round out the account toolkit. To query the account databases through NSS rather than reading the files directly, use getent : getent passwd alice , getent group sudo . To modify individual fields, use the targeted tools instead of editing by hand: chfn (the GECOS/full-name field), chsh (login shell — non-root users may only pick a shell listed in /etc/shells ), chage (password aging), and passwd -e alice to force a change at next login. usermod -L alice / usermod -U alice lock and unlock exactly like passwd -l / passwd -u , both writing and stripping a leading ! on the hash. For direct file edits, vipw and vigr take the proper locks.

sudo and the sudo Group

Root privileges on Kali are exercised through sudo , configured by /etc/sudoers (edit it only with visudo , which syntax-checks before saving). Debian's convention is the line %sudo ALL=(ALL:ALL) ALL , meaning every member of the sudo group may run any command as any user . So granting admin rights is just group membership: usermod -aG sudo alice . Related groups worth recognizing: adm (read system logs), wireshark (capture packets without root), and kaboxer / docker -style service groups. Prefix a command with sudo to run it as root; sudo -i or sudo su - opens a root shell, and sudo caches credentials for a few minutes so you are not re-prompted per command.

Passwords and Account Removal

A normal user changes their own password with passwd ; root changes anyone's with passwd alice . Useful root options: passwd -l alice locks the account (prefixes the hash with ! ), passwd -u unlocks, and passwd -e alice expires the password to force a change at next login.

To remove an account, prefer deluser , adduser's counterpart: deluser alice removes the account, and deluser --remove-home alice also deletes her home directory and mail spool. The low-level equivalent is userdel -r alice . Deleting a user does not magically delete every file they owned elsewhere — orphaned files keep the numeric UID and can be found with find / -uid 1001 -nouser .

Kali's Non-Root Policy

Historically, BackTrack and early Kali ran everything as root — acceptable for a live pentest session, terrible as a daily-driver habit. Since Kali 2020.1 , the default model changed: live images and standard installs log you in as the non-root user kali with default password kali (on live media), and administrative actions go through sudo. The reasoning is defense in depth: a browser exploit or mistyped command as a normal user cannot instantly own the whole system, sudo leaves an audit trail in the logs, and modern Kali is used as a primary OS, not just a throwaway live session. The root account itself is locked for direct login by default — you elevate per command instead of inhabiting root. This mirrors Debian and Ubuntu practice and is a frequently tested cultural point: Kali is a security distribution that nonetheless applies basic security hygiene to itself.