User Accounts Management

Search Transfer and Protection of Information
Practice
Author

Andrei Biziuk

Published

June 12, 2025

User Accounts Management

1. Introduction: Why User Account Management Matters

  • Protection of Information:
    • Confidentiality: Ensuring only authorized individuals can access specific data.
    • Integrity: Preventing unauthorized modification of data and system configurations.
    • Availability: Ensuring systems and data are accessible to legitimate users when needed.
    • Accountability (Auditability): Tracking who did what and when. Without distinct user accounts, actions cannot be reliably attributed.
  • Principle of Least Privilege: Users should only have the permissions necessary to perform their tasks. This minimizes the potential damage from accidental misuse, compromised accounts, or malicious insiders.
  • Resource Management: Controlling access to system resources (CPU, memory, disk space, specific applications).

Poor user account management can lead to data breaches, system instability, and difficulty in tracing malicious activities.

2. Types of User Accounts in Debian

Debian, like other Linux distributions, categorizes users:

  • Root User (Superuser):
    • Username: root
    • UID (User ID): 0
    • Has unrestricted access to the entire system. Can do anything, including destroying the system.
    • Security Implication: Direct login as root should be heavily restricted or disabled. Use sudo for administrative tasks.
  • Regular Users:
    • Created for individual human users to perform their daily tasks.
    • UIDs typically start from 1000 upwards (configurable in /etc/login.defs).
    • Limited privileges by default, protecting the system from accidental damage and users from accessing each other’s private data.
  • System Users (Service Accounts):
    • Used by services and daemons (e.g., www-data for a web server, postgres for a database).
    • Typically have UIDs between 100 and 999.
    • Usually have no login shell (/usr/sbin/nologin or /bin/false) and no home directory, or a restricted one.
    • Security Implication: Isolates services. If one service is compromised, the damage is (ideally) limited to what that service account can access.

3. Key Files for User and Group Management

Understanding where user and group information is stored is crucial:

  • /etc/passwd:
    • Plain text file, world-readable.
    • Contains user account information (username, UID, GID, home directory, default shell).
    • Format (colon-separated fields): username:x:UID:GID:GECOS:home_directory:shell
    • The ‘x’ in the second field indicates the encrypted password is stored in /etc/shadow.
  • /etc/shadow:
    • Contains encrypted (hashed) passwords and password aging information.
    • Crucially, only readable by root. This is a vital security feature.
    • Format (colon-separated fields): username:encrypted_password:last_password_change_date:min_days_between_changes:max_days_before_change_required:warning_period:inactivity_period:expiration_date:reserved
  • /etc/group:
    • Plain text file, world-readable.
    • Defines groups and their members.
    • Format: group_name:x:GID:list_of_members_separated_by_commas
    • The ‘x’ indicates the group password (rarely used) would be in /etc/gshadow.
  • /etc/gshadow:
    • Contains encrypted group passwords (if used) and group administrator information.
    • Only readable by root.
  • /etc/login.defs:
    • Configuration file for shadow password suite.
    • Defines default password aging policies, UID/GID ranges for new users, home directory creation settings, etc.
  • /etc/skel:
    • “Skeleton” directory. Files and directories within /etc/skel are copied to a new user’s home directory when the account is created.
    • Useful for providing default configuration files (e.g., .bashrc, .profile).

4. Core Commands for User Management

Debian provides several command-line tools for managing users.

  • adduser (Recommended for interactive use):
    • A user-friendly Perl script frontend to useradd.
    • Interactively prompts for information (password, GECOS).
    • Automatically creates the home directory, copies files from /etc/skel.
    • Creates a default group with the same name as the user.
    • sudo adduser newuser
  • useradd (Low-level utility, good for scripting):
    • More basic, less interactive.
    • Does not create a home directory or set a password by default unless specified with options.
    • sudo useradd -m -s /bin/bash -c "New User Full Name" newuser2
      • -m: Create home directory.
      • -s /bin/bash: Set default shell.
      • -c "Comment": Set GECOS information.
      • -g GID_or_name: Set primary group.
      • -G group1,group2: Add to supplementary groups.
  • passwd:
    • Used to change passwords.
    • passwd newuser (as root, to set/change another user’s password)
    • passwd (as a regular user, to change their own password)
    • Options:
      • -l: Lock account (prevents password login).
      • -u: Unlock account.
      • -d: Delete password (allows login without password - DANGEROUS!).
      • -e: Expire password, forcing user to change it on next login.
  • usermod (Modify existing user account):
    • sudo usermod -s /bin/zsh newuser (change shell)
    • sudo usermod -d /home/newlocation -m newuser (move home directory)
    • sudo usermod -aG groupname newuser (add user to a supplementary group; -a is append)
    • sudo usermod -l new_username old_username (rename user)
    • sudo usermod -L newuser (lock account)
    • sudo usermod -U newuser (unlock account)
  • userdel (Delete user account):
    • sudo userdel newuser (deletes user but may leave home directory)
    • sudo userdel -r newuser (deletes user AND their home directory and mail spool - use with caution!)
  • chage (Change user password expiry information):
    • Manages password aging policies for individual users, overriding defaults from /etc/login.defs.
    • sudo chage -l newuser (list aging info)
    • sudo chage -M 60 newuser (set max days before password change to 60)
    • sudo chage -E YYYY-MM-DD newuser (set account expiration date)

5. Core Commands for Group Management

  • addgroup (Recommended for interactive use):
    • sudo addgroup newgroup
  • groupadd (Low-level utility):
    • sudo groupadd project_alpha
  • groupmod (Modify existing group):
    • sudo groupmod -n new_group_name old_group_name (rename group)
    • sudo groupmod -g GID new_group_name (change GID)
  • groupdel (Delete group):
    • sudo groupdel oldgroup (Note: Will fail if it’s the primary group for any user.)
  • gpasswd (Administer /etc/group and /etc/gshadow):
    • sudo gpasswd -a username groupname (add user to group)
    • sudo gpasswd -d username groupname (remove user from group)
    • sudo gpasswd -M user1,user2 groupname (set exact list of members)

6. Privilege Escalation: sudo

  • The Problem with Root: Constantly working as root is dangerous. A single typo can cripple the system.
  • sudo (Superuser Do): Allows permitted users to execute specific commands as root (or another user) without needing the root password.
  • Configuration: /etc/sudoers (ALWAYS edit with visudo to prevent syntax errors that could lock you out).
    • Example entry: username ALL=(ALL:ALL) ALL (Allows username to run any command as any user/group on any host).
    • More granular: webadmin ALL=(ALL) /usr/sbin/service apache2 *, /usr/bin/systemctl restart nginx
  • Benefits:
    • Accountability: Commands run via sudo are logged (typically in /var/log/auth.log or /var/log/secure), attributing actions to the original user.
    • Least Privilege: Grant only necessary commands.
    • Security: Users don’t need to know the root password.

7. Best Practices for User Account Management (Information Protection Focus)

  1. Enforce Strong Password Policies:
    • Use /etc/login.defs for system-wide defaults.
    • Consider libpam-pwquality or libpam-cracklib for complexity, length, and history.
    • Regularly enforce password changes (chage).
  2. Principle of Least Privilege:
    • Users should only have access to data and commands essential for their job.
    • Use groups effectively to manage permissions on files and directories.
  3. Avoid Shared Accounts: Each individual user should have their own unique account for accountability.
  4. Regularly Audit User Accounts:
    • Identify and disable/remove dormant or unnecessary accounts.
    • Review user privileges.
    • Commands like last, lastlog, who can help.
  5. Disable Direct Root Login: Especially over SSH (PermitRootLogin no in /etc/ssh/sshd_config). Rely on sudo.
  6. Secure Home Directories: Default permissions are usually 700 or 750 (user-only or user and group). Ensure sensitive data is not world-readable.
  7. Use System Accounts for Services: Do not run services as root unless absolutely necessary.
  8. Manage /etc/skel: Ensure new users get appropriate default configurations, potentially including security-conscious settings.
  9. Implement Account Lockout: After a certain number of failed login attempts (can be configured via PAM modules like pam_tally2).
  10. Offboarding Process: When a user leaves, promptly disable or delete their account, archive their data as per policy, and revoke access.

8. Practical Demonstration / Scenario (Illustrative)

Imagine we need to:

  1. Create a new user jdoe for a developer.
  2. Add jdoe to the developers group.
  3. Give jdoe sudo rights to restart the apache2 web server.
# 1. Create the developers group (if it doesn't exist)
sudo addgroup developers

# 2. Create the user jdoe, add to developers group, set bash as shell
sudo adduser --ingroup developers --shell /bin/bash jdoe
# (adduser will prompt for password and GECOS info)
# Alternatively, with useradd and subsequent commands:
# sudo useradd -m -s /bin/bash -g users -G developers -c "Jane Doe" jdoe
# sudo passwd jdoe

# 3. Grant sudo rights (using visudo)
sudo visudo
# Add this line to /etc/sudoers:
# jdoe ALL=(ALL) /usr/sbin/service apache2 restart, /usr/sbin/service apache2 status
# Or using systemd:
# jdoe ALL=(ALL) /usr/bin/systemctl restart apache2.service, /usr/bin/systemctl status apache2.service

# Verify:
id jdoe
sudo -l -U jdoe
# As jdoe:
# sudo service apache2 status

Practice tasks

User Account Management in Debian Linux

Objective: To practically apply the concepts and commands learned in the lecture for managing user accounts, groups, and privileges in a Debian Linux environment, with an emphasis on security best practices.

Prerequisites:

  • A Debian Linux virtual machine (or a dedicated test system).
  • Root access or sudo privileges on the Debian system.
  • Familiarity with basic Linux command-line operations.

Important Notes:

  • Always use sudo for commands requiring root privileges, unless explicitly told otherwise or if you are logged in as root in a controlled test environment (which is generally discouraged for real systems).
  • Be careful with userdel -r as it permanently removes user data.
  • Always use visudo to edit the /etc/sudoers file.
  • Document your steps and any outputs requested. This could be via screenshots, text file outputs, or a written report.

Part 1: Basic User and Group Creation

  1. Create New Users:

    • Use adduser to create a new user named alice. During the interactive process, provide a strong password and fill in some GECOS information.

    • Use useradd to create another user named bob.

      • Ensure bob gets a home directory created (-m).
      • Set bob’s default shell to /bin/bash (-s).
      • Add a comment (GECOS) for bob like “Bob The Builder” (-c).

    • Set a password for bob using the passwd command.

    • Verification:

      • Check the last few lines of /etc/passwd and /etc/group. Can you identify the entries for alice and bob?
      • Log in (or switch user using su - alice) as alice in a new terminal. Check her home directory contents.
      • Log out from alice’s session.
  2. Create a New Group:

    • Create a new group named projects.

    • Verification: Check the last few lines of /etc/group to confirm its creation.

  3. Add Users to Group:

    • Add both alice and bob as supplementary members to the projects group. Use one method for alice (e.g., usermod) and a different method for bob (e.g., gpasswd).

    • Verification:

      • Use the groups alice and groups bob commands to verify their group memberships.
      • Inspect the projects group entry in /etc/group.

Part 2: Modifying User Accounts and Password Policies

  1. Modify User Attributes:

    • Change bob’s default shell to /bin/zsh (if zsh is installed; if not, choose /bin/sh or another available shell).

    • Lock alice’s account. Try to log in as alice. What happens?

    • Unlock alice’s account.

    • Verification:

      • Check bob’s entry in /etc/passwd to see the shell change.
      • Observe the login attempts for alice when locked/unlocked. Check /etc/shadow (as root) for changes related to account locking (look for ! or * at the beginning of the password hash field).
  2. Password Aging and Expiry:

    • For user bob, use chage to:

      • Set the maximum number of days between password changes to 90 (-M).
      • Set the warning period before password expiry to 14 days (-W).
      • Force bob to change his password upon next login (-d 0 or passwd -e bob).

    • Verification:

      • Use chage -l bob to display and verify the new password aging settings.
      • Log in as bob. What happens? (You might need to set an initial password for bob again if the forced change prevents login without one).
  3. Exploring System Defaults:

    • Examine the /etc/login.defs file.

    • Identify the default UID range for regular users.

    • Identify the default settings for password aging (e.g., PASS_MAX_DAYS, PASS_MIN_DAYS, PASS_WARN_AGE).

    • Question: How do the user-specific settings made with chage relate to the system-wide defaults in /etc/login.defs?

Part 3: Privilege Escalation and Security

  1. sudo Configuration:

    • Create a new user named sysadmin_trainee. Set a password for this user.

    • Use visudo to grant sysadmin_trainee the ability to run the apt update command AND the tail /var/log/syslog command as root, but nothing else.

    • Verification:

      • Log in as sysadmin_trainee.
      • Try to run sudo apt update. It should work after prompting for sysadmin_trainee’s password.
      • Try to run sudo tail /var/log/syslog. It should work.
      • Try to run sudo reboot. This should be denied.
      • As sysadmin_trainee, run sudo -l. What does this output tell you?
  2. The /etc/skel Directory:

    • As root, create a file named .bash_aliases inside /etc/skel with the following content:

      alias ll='ls -alF'
alias update='sudo apt update && sudo apt upgrade -y'

    • Create a new user named charlie using adduser.

    • Verification: Log in as charlie.

      • Check if the .bash_aliases file exists in charlie’s home directory and if its content is correct.
      • Try using the ll alias. Does it work? (You might need to source .bashrc or log out and back in).
  3. User Deletion (Handle with Care!):

    • First, ensure bob has some files in his home directory (e.g., touch /home/bob/testfile.txt).

    • Delete the user bob without removing his home directory.

    • Verification:

      • Check if bob still exists in /etc/passwd.
      • Check if /home/bob still exists.
      • What is the ownership of the files in /home/bob now (use ls -l /home/bob)?

    • Now, delete the user charlie AND his home directory.

    • Verification:

      • Check if charlie still exists in /etc/passwd.
      • Check if /home/charlie still exists.

Part 4: Security Considerations & Scenario

  1. Scenario: Offboarding an Employee
    • An employee named alice is leaving the company. Outline the steps you would take to securely offboard her account from the Debian system. Consider:
      • Preventing future logins.
      • Dealing with her data/home directory (archiving vs. deletion, based on company policy - assume for this task you need to archive it first then remove the account).
      • Checking for any running processes or cron jobs owned by alice.
      • Removing her from any special groups or sudo privileges.
    • Deliverable: A written list of commands and actions, with brief explanations for each step.
  2. Discussion Question (Information Protection Focus):
    • Explain why using distinct user accounts (instead of everyone sharing a single account or using root directly) is crucial for:
      • Accountability/Auditability: How does it help in tracking who did what?
      • Principle of Least Privilege: How does it help enforce this principle?
      • Containment: How can it limit the damage if one account is compromised?
Back to top