Solaris User ID Management

Solaris User ID Management is the process of creating, modifying, securing, and removing user accounts in a controlled and structured way.

In Solaris, every user is identified internally by a numeric User ID (UID), not just by a username. The system uses this UID to determine:

• File ownership
• Process ownership
• Access permissions
• Resource limits
• Audit records

Even if a username changes, the UID remains the true identity of the user at the system level.

UID Number Ranges in Solaris

Solaris uses defined UID ranges:

UID Range	Purpose
0	root (superuser)
1–99	Reserved for system accounts
100–60000+	Regular user accounts
Up to 2,147,483,647	Maximum supported UID (32-bit signed integer limit)

Important notes:

• UID 0 always has full administrative privileges.
• Multiple users must never share the same UID (unless intentionally configured).
• Duplicate UIDs can cause serious security and ownership issues.

To check UID availability:

awk -F: '{print $3}' /etc/passwd | sort -n

Core User Management Files

Solaris stores user data across several configuration files.

1. /etc/passwd

Stores basic account information.

Structure:

username:password:UID:GID:GECOS:home_directory:shell

Example:

sunadm:x:1500:10:Unix Administrator:/export/home/sunadm:/bin/bash

Field explanation:

• username → login name
• password → usually "x" (real password stored in /etc/shadow)
• UID → numeric user ID
• GID → primary group ID
• GECOS → full name or description
• home_directory → login home directory
• shell → default login shell

File permissions:

-r--r--r--

Readable by all users.

2. /etc/shadow

Stores encrypted passwords and password aging data.

Structure:

username:encrypted_password:lastchg:min:max:warn:inactive:expire:flag

Example:

sunadm:$5$abcd...$xyz...:19700:7:90:7:14::

Field explanation:

• encrypted_password → SHA-256 or SHA-512 hash
• lastchg → days since Jan 1, 1970
• min → minimum days before password change allowed
• max → maximum valid days
• warn → warning days before expiration
• inactive → days after expiration before lock
• expire → absolute account expiry date

File permissions:

-r--------

Readable only by root.

3. /etc/group

Stores group definitions.

Structure:

group_name:password:GID:user_list

Example:

staff:x:10:sunadm,user1,user2

Notes:

• Primary group defined in /etc/passwd
• Supplementary groups listed here
• Password field rarely used

To view group membership:

id sunadm

4. /etc/user_attr

Stores Solaris-specific attributes such as:

• Roles
• Profiles
• Authorizations
• Privileges
• Access time restrictions

Example:

sunadm::::profiles=File System Management;roles=Operator

Important fields:

• profiles → RBAC execution rights
• roles → assigned administrative roles
• auths → granular authorizations
• type → normal or role

Name Service Switch (NSS)

Solaris may not rely only on local files.

The file:

/etc/nsswitch.conf

Determines lookup order:

Example:

passwd: files ldap

group:  files ldap

This means:

• Check local files
• Then check LDAP

If using NIS or LDAP, user records may not appear directly in /etc/passwd.

To check full user record:

getent passwd sunadm

Creating Users – Detailed Explanation

Basic command:

useradd -m -d /export/home/sunadm -s /bin/bash -c "Unix Administrator" sunadm

Option breakdown:

• -m → create home directory
• -d → specify home path
• -s → login shell
• -c → GECOS information
• -u → specify custom UID
• -g → primary group
• -G → supplementary groups
• -e → expiry date

Example with specific UID:

useradd -u 1500 -g staff -G wheel,adm -m sunadm

Home directory skeleton files are copied from:

/etc/skel

These may include:

• .profile
• .bashrc
• .kshrc

Password Management

Set password:

passwd sunadm

Force change at next login:

passwd -f sunadm

Set password policies:

passwd -x 90   # max 90 days

passwd -n 7    # minimum 7 days

passwd -w 7    # warn 7 days before expiry

Lock account:

usermod -L sunadm

Unlock:

usermod -U sunadm

Locking usually inserts a special character in the encrypted password field.

Modifying User Accounts

Change shell:

usermod -s /bin/ksh sunadm

Change UID:

usermod -u 1600 sunadm

Important:

After changing UID, update file ownership:

find / -user 1500 -exec chown -h 1600 {} \;

Change home directory:

usermod -d /export/home/newhome -m sunadm

Add to groups:

usermod -G wheel,adm sunadm

Deleting Users

Delete account only:

userdel sunadm

Delete account and home directory:

userdel -r sunadm

Before deleting, check running processes:

ps -fu sunadm

Kill active sessions if necessary.

Role-Based Access Control (RBAC)

Solaris RBAC allows delegation of administrative tasks without giving full root access.

Instead of sharing root password, assign roles.

Key RBAC Files

• /etc/user_attr
• /etc/security/prof_attr
• /etc/security/exec_attr
• /etc/security/auth_attr

Assign Role

usermod -K roles=Operator sunadm

Switch to role:

su - Operator

Assign Profile

usermod -K profiles="Primary Administrator" sunadm

View profiles:

profiles sunadm

RBAC improves security by limiting command execution.

Solaris Projects and Resource Controls

Projects allow grouping users for resource management.

File:

/etc/project

Example:

development:2003:Developers:::task.max-lwps=(privileged,10,deny)

Resource control examples:

• task.max-lwps → limit lightweight processes
• process.max-address-space → memory limit
• project.cpu-shares → Fair Share Scheduler CPU allocation

Assign user to project:

usermod -K project=development sunadm

Check project membership:

projects sunadm

Fair Share Scheduler (FSS)

FSS distributes CPU based on shares assigned in project configuration.

Example:

project.cpu-shares=(privileged,20,deny)

More shares = more CPU time.

Activate FSS:

dispadmin -d FSS

Auditing and Security

Solaris auditing can track user actions.

Check audit configuration:

auditconfig -getpolicy

Audit logs stored in:

/var/audit/

Good practice:

• Disable unused accounts
• Enforce strong password policies
• Use RBAC instead of full root access
• Regularly review UID consistency
• Monitor failed login attempts

Best Practices

Always back up critical files before changes:

cp /etc/passwd /etc/passwd.bak

cp /etc/shadow /etc/shadow.bak

cp /etc/group /etc/group.bak

cp /etc/user_attr /etc/user_attr.bak

Avoid manual editing unless necessary.

Use vipw to safely edit passwd file.

Maintain UID consistency across servers in enterprise environments.

Use centralized identity management (LDAP) for large systems.

Periodically audit orphaned files:

find / -nouser

find / -nogroup