Users, Groups, and Principals

Who Can Do What — and Who Did It

Every action on a system is performed by an account. Understanding the types of accounts, how they are managed, and why accountability matters is fundamental to access control and security operations.

User Accounts

A user account represents a single human being. Each employee, contractor, and administrator should have exactly one account that is used only by that person. The account is the identity that the system uses to authenticate (verify who you are) and authorize (determine what you can do).

# View all user accounts
cat /etc/passwd
# Format: username:password:UID:GID:comment:home:shell

# View a specific user
id username
# Output: uid=1001(john) gid=1001(john) groups=1001(john),27(sudo),100(developers)

# Check currently logged-in users
who
w

The uniqueness principle: Every account must map to exactly one person. If two people share an account, you cannot determine who performed a specific action. This destroys accountability — the ability to trace actions to individuals.

Service Accounts

A service account is used by an application or system service, not by a human. Examples: the www-data account used by the web server, the mysql account used by the database, the backup account used by the backup script.

# Service accounts typically have:
# - No login shell (/usr/sbin/nologin or /bin/false)
# - No password (locked with ! or *)
# - A dedicated home directory for the service's files

# Check if an account can log in
grep username /etc/shadow
# If the password field is ! or *, the account cannot authenticate with a password

Service account security:

• Service accounts should have the minimum permissions needed for the service to function
• Service account passwords should be long, random, and stored in a secrets manager (not in scripts or configuration files)
• Service accounts should not be used for interactive login
• Service account credentials should be rotated regularly

Shared Accounts — The Accountability Killer

A shared account is used by multiple people. Examples: a generic admin account, a root account that multiple administrators use, a support account for the help desk.

Why shared accounts are dangerous:

1. No accountability: When an action is performed using a shared account, you cannot determine which person performed it. If a shared admin account deletes a critical file, you know the account was used but not who was at the keyboard.

2. No individual attribution: Audit logs record the account name, not the person. With shared accounts, the logs are useless for forensic investigation.

3. Password management nightmare: When a shared account's password must be changed (e.g., after an employee leaves), it must be communicated to all users of the account. This leads to passwords being written down, sent over email, or not changed at all.

4. No individual access revocation: When an employee leaves the organization, you cannot revoke their access to a shared account without affecting all other users. The password must be changed and redistributed.

The fix: Every person gets their own account. If multiple people need admin access, each has their own account that is a member of the admin group. When someone leaves, you disable their individual account — everyone else is unaffected.

# Instead of sharing root, use sudo with individual accounts
# /etc/sudoers:
%admin ALL=(ALL:ALL) ALL

# Each admin has their own account in the 'admin' group
# Their individual actions are logged with their username

Principals: The Broader Concept

In security, a principal is any entity that can be authenticated and authorized. This includes:

• Users: Human operators
• Service accounts: Applications and services
• Groups: Collections of users or service accounts
• Roles: Named sets of permissions that can be assumed by users or services
• Devices: Computers, phones, IoT devices that authenticate to the network

The principal is the "who" in every access control decision. The system authenticates the principal (verifies identity) and then authorizes the principal (determines permissions).

Account Lifecycle Management

Accounts have a lifecycle: creation → active use → modification → deactivation → deletion. Security failures often occur at the transitions:

Creation: Accounts should be provisioned with the minimum necessary permissions. New employees should not receive admin rights by default.

Active use: Permissions should be reviewed regularly. Employees who change roles should have their old permissions revoked and new ones granted.

Deactivation: When an employee leaves, their account must be disabled immediately — not at the end of the month, not after the exit interview, but immediately. Dormant accounts are prime targets for attackers because they are no longer monitored by their owners.

Deletion: Disabled accounts should be deleted after a retention period (e.g., 90 days) to prevent them from being reactivated by an attacker.

# Find accounts that have not logged in for 90+ days
lastlog -b 90

# Find accounts with no password
grep '^[^:]*:!' /etc/shadow

# Disable an account
passwd -l username
# or
usermod -L username

# Delete an account
userdel -r username

Why Groups Beat Individual Permissions

Managing permissions for individual users does not scale. In an organization with 500 employees, setting file permissions, firewall rules, and application access for each person individually is unmanageable and error-prone. Groups solve this by allowing you to define permissions once and apply them to many users.

How Groups Work

A group is a named collection of users. When a user is a member of a group, they inherit the permissions granted to that group.

# View all groups
cat /etc/group
# Format: groupname:password:GID:member_list

# View a user's groups
id username
# Output: uid=1001(john) gid=1001(john) groups=1001(john),100(developers),27(sudo)

# Create a group
groupadd developers

# Add a user to a group
usermod -aG developers john

# Remove a user from a group
gpasswd -d john developers

# Change a user's primary group
usermod -g developers john

Designing a Group Structure

A well-designed group structure reflects the organization's roles and responsibilities:

# Role-based groups
developers      — access to code repositories and dev environments
ops             — access to production infrastructure
security        — access to security tools and logs
finance         — access to financial systems
hr              — access to HR systems

# Environment groups
dev             — access to development environment
staging         — access to staging environment
prod            — access to production environment

# Function groups
db-admins       — database administration
net-admins      — network administration

A user who is a developer working on the production application would be a member of developers and prod. When they move to a different project, you remove them from prod — their developers membership remains.

The Revocation Advantage

The primary security advantage of group-based access is simplified revocation. When an employee leaves the organization:

# Remove the user from all groups
# This revokes all group-based permissions at once
for group in $(groups username); do
  gpasswd -d username $group
done

# Disable the account
passwd -l username

Without groups, you would need to find every individual permission grant and remove it — a process that is slow, error-prone, and often incomplete.

Group Nesting and Inheritance

Groups can be nested — a group can be a member of another group. This allows hierarchical permission structures:

# 'senior-developers' is a member of 'developers'
# Senior developers inherit all developer permissions plus additional ones

# /etc/group:
# developers:x:100:
# senior-developers:x:101:developers

However, nesting should be used carefully. Deeply nested groups make it difficult to determine a user's effective permissions, which leads to accidental over-privilege.

Service Accounts and Groups

Service accounts should also use groups for permission management:

# Instead of granting permissions directly to the 'app' service account,
# create a group 'app-prod' and grant permissions to the group

# /etc/group:
# app-prod:x:200:app,backup

# File permissions:
# chown root:app-prod /etc/myapp/config.yml
# chmod 640 /etc/myapp/config.yml

This way, if the service account needs to be replaced, you create a new account and add it to the group — the file permissions do not change.

Auditing Group Membership

Group membership should be audited as rigorously as individual permissions:

# List all members of a group
getent group sudo

# Find all groups a user belongs to
id username

# Find all users who are members of a privileged group
getent group sudo | cut -d: -f4 | tr ',' '\n'

# Audit: check for users who should not be in privileged groups
# This should be automated and run regularly

Key audit questions:

• Who is in the sudo or admin group? Should they be?
• Are there former employees still in any group?
• Are there service accounts in groups that grant them excessive permissions?
• Are there users in multiple conflicting groups (e.g., both developers and auditors)?