— LiveStream

Managing AIX and Linux user IDs and groups on shared development servers means provisioning accounts with consistent UID/GID numbers, the right primary and secondary groups, correct home directories, and a clean audit trail. This guide walks through the full lifecycle on both platforms: creating users, building groups, resetting locked passwords, creating functional (service) accounts, and removing access cleanly.

The core challenge is that AIX and Linux use different command sets for the same job, and on multi-host environments a single person may already exist on one server with a UID that must be reused everywhere. Get the numbering or the group assignment wrong and you create login failures, broken file ownership, or security gaps. The patterns below keep user and group management consistent and reproducible.

The Problem: Consistent User Provisioning Across Mixed UNIX Hosts

On a development estate that mixes AIX and Linux, every new account request raises the same questions: What UID should this person get? Which primary group and which secondary groups? Where does the home directory live? Has this user already been created on another host with an existing UID you must match?

If UIDs drift between hosts, NFS-mounted home directories and shared files end up owned by the wrong account, because UNIX permissions are enforced by the numeric UID/GID, not the username. The whole point of central tracking files (a last-used-UID counter and a per-host script library) is to keep numbering deterministic so the same human always maps to the same number everywhere.

Before You Begin: Access and Information Checklist

Account provisioning is a privileged, auditable operation. Confirm you have the prerequisites before touching any host:

• Ticket / request access — pick up the open request from your intake queue and assign it to yourself so ownership is clear.
• Admin or sudo on each target development host where the account will live.
• Read access to your directory service (for example Active Directory) to confirm the user's official logon name across domains.
• Access to the provisioning toolkit directory on your management/jump host, where the UID counter and the per-host creation scripts are kept.

Gather four facts from the request first: the employee name, their role (which decides group membership), the exact host names they need, and the group assignment. If any of these is missing, send the ticket back for clarification rather than guessing — a wrong group is a security finding.

Confirm the Canonical Logon Name

Open your directory tool and locate the user's account. If your organization spans multiple domains (say an OFFICE domain and a SYSDEV domain), search the primary domain first and only fall back to the secondary one. Read the exact logon name from the Account tab — this becomes the UNIX username and must be spelled identically on every host.

Step-by-Step: Creating a New User Account

This is the heart of AIX and Linux user management. Work through it in order; the early steps prevent duplicate UIDs.

1. Change to the provisioning toolkit directory on your management host:
   cd /path/to/create_id_grp
2. Search for any existing account for this person by first and last name. Existing accounts on other hosts MUST reuse the same UID and username:
   grep -i billy *
grep -i gate *
   Inspect the GECOS field of any match to confirm it is the same human, not a name collision.
3. If the user already exists elsewhere, reuse that exact UID and username — do not allocate a new number.
4. If the user is new, read the last-used UID counter:
   cat /path/to/create_id_grp/last_id_num
   Example output: 3251
5. Allocate the next UID by incrementing: 3251 + 1 = 3252. Then write the new value back to the counter file so the next administrator does not collide:
   echo 3252 > /path/to/create_id_grp/last_id_num
6. Record the account in the per-host creation script for each target host (for example createid-host01.ksh). Keeping these scripts current is your audit trail and your disaster-recovery rebuild plan.
7. Decide the home directory root. Most hosts use /home; a few legacy hosts may use a different root such as /homecomm. Pick the correct root per host before you run the create command.
8. Run the creation command with sudo on the target host (see the platform-specific syntax below).

Creating the User on AIX

AIX uses mkuser, where attributes are passed as key=value pairs and the username comes last. Never assign the default staff group to a managed account — set the primary group (pgrp) and secondary groups (groups) explicitly:

sudo mkuser id=3252 pgrp=pvcs groups=grampim gecos='Billy Gate' home=/home/bgate01 fsize=-1 fsize_hard=-1 bgate01

The fsize=-1 fsize_hard=-1 pair removes the file-size ulimit so the account is not capped by AIX's default. If a host requires its home directory under a non-standard root, create the real directory there and symlink it into /home so paths stay predictable:

sudo ln -s /homecomm/bgate01 /home/bgate01

Creating the User on Linux

Linux uses useradd with short flags. The same logical account looks like this:

sudo useradd -u 3252 -g pvcs -G catread -c 'Billy Gate' -s /bin/ksh -d /home/bgate01 bgate01

Here -u is the UID, -g the primary group, -G the secondary group(s), -c the GECOS comment, -s the login shell, and -d the home directory. Add -m if you want useradd to create and populate the home directory from /etc/skel:

sudo useradd -u 3252 -g pvcs -G catread -c 'Billy Gate' -s /bin/ksh -m -d /home/bgate01 bgate01

AIX vs Linux Command Reference

Setting the Initial Password

After the account exists, set a temporary password and force a change at first login so the administrator never knows the user's permanent secret.

AIX flags new passwords for change automatically when set by root, so a single command is enough:

sudo passwd bgate01

Linux does not force a change just because root set the password, so add chage -d 0 to expire it immediately:

sudo passwd bgate01
sudo chage -d 0 bgate01

Creating Functional (Service) Accounts

A functional ID — a shared service or application account — needs extra care because no single human owns it. Always capture an accountable owner in the GECOS field, and make the account non-interactive and non-expiring so a scheduled job never breaks because the password aged out.

AIX:

sudo mkuser id=3252 pgrp=pvcs groups=grampim gecos='Functional ID for MS Server owned by Mark Liu' home=/home/mssvc fsize=-1 fsize_hard=-1 mssvc

Then disable remote login and password expiry:

sudo chuser login=true rlogin=false maxage=0 mssvc

Linux:

sudo useradd -u 3252 -g pvcs -G grampim -c 'Functional ID for MS Server owned by Mark Liu' -s /bin/ksh -d /home/mssvc mssvc

Disable expiry and remove interactive shell access:

sudo chage -M -1 mssvc
sudo usermod -s /bin/false mssvc

Setting the shell to /bin/false (or /sbin/nologin) means even if credentials leak, nobody gets an interactive session — the account can still run cron jobs and own files.

Creating and Removing Groups

Groups follow the same deterministic-numbering discipline as users: a shared GID must match across every host where the group exists.

1. Check whether the group already exists in your toolkit scripts:
   grep bclread *
   If it appears with a GID such as 1469, reuse that number everywhere.
2. If it is new, read and increment the group counter:
   cat last_grp_num → 1814, so the new GID is 1815. Write the new value back.
3. Record the group in the appropriate per-host script, then create it on the host.

AIX: sudo mkgroup -A id=1815 bclread (the -A flag makes it an administrative group).

Linux: sudo groupadd -g 1815 bclread

To remove a group once no files or users depend on it:

AIX: sudo rmgroup bclread
Linux: sudo groupdel bclread

Modifying Existing Accounts

The most common change is adjusting group membership. The flags matter: replacing groups versus appending to them are different operations, and confusing them silently strips access.

On AIX

Use the menu-driven smitty interface for guided edits:

sudo smitty user

Navigate to Change / Show Characteristics of a User, enter the username, and edit the group list. Commit with Enter, or cancel with Esc-3. You can also script it: sudo chuser groups=grp1,grp2 bgate01 replaces the secondary group list, and sudo chuser account_locked=true bgate01 disables an account.

On Linux

Change the primary group:

sudo usermod -g operator bgate01

Replace all secondary groups (this overwrites the existing list):

sudo usermod -G faadm,fadev bgate01

Append a secondary group without disturbing the others — note the critical -a:

sudo usermod -a -G faadm,fadev bgate01

Forgetting -a with -G is the single most common Linux user-admin mistake: it replaces the user's entire supplementary group set instead of adding to it.

Unlocking Accounts and Resetting Passwords

Lockouts come from two independent mechanisms — an explicit account lock and a failed-login counter — and you must check both. An account can read as unlocked while still being blocked by a failure count over the threshold.

1. Check lock status.
   AIX: sudo lsuser -a account_locked bgate01
   Linux: sudo passwd -S bgate01 (a status of LK means locked)
2. If locked, get approval from the user's manager before unlocking — this preserves the audit chain.
3. Unlock the account.
   AIX: sudo chuser account_locked=false bgate01
   Linux: sudo passwd -u bgate01
4. Reset the password on the host where the account lives: sudo passwd bgate01
5. Reset the failed-login counter to zero so a stale count does not re-lock the account.
   AIX: sudo chuser unsuccessful_login_count=0 bgate01
   Linux: sudo faillog -r -u bgate01

On Linux you can inspect the failure counter directly with faillog -u bgate01. If either the password shows LK or the failure count exceeds the maximum, the account is effectively locked — clear both.

Securing Home Directory Files

Where legacy tooling relies on .rhosts or .netrc files, ownership and permissions are security-critical. A world-readable .netrc exposes stored credentials, and a writable .rhosts is a trust-exploitation risk:

1. touch .rhosts .netrc
2. chown root:system .rhosts .netrc (use root:root on Linux)
3. chmod 600 .rhosts .netrc

Note: modern best practice is to avoid .rhosts and .netrc entirely — they predate SSH and transmit or store credentials insecurely. Prefer SSH key authentication and a secrets manager. If a legacy application still demands these files, lock them down to 600 and owner-only so no other account can read the stored secrets.

Removing a User Cleanly

When access is revoked, remove the account on every host where it was created.

AIX: sudo rmuser bgate01 (add -p to also remove the user from the security databases).

Linux: sudo userdel bgate01 (add -r to delete the home directory and mail spool too).

Before deleting, check for files owned by the UID across shared filesystems so you do not orphan data: find /shared -uid 3252 2>/dev/null. Re-home or archive those files first.

Verification: Confirm Every Change Took Effect

Never close a ticket on faith. Confirm the account is correct on the actual host:

• Identity and groups: id bgate01 — confirms the UID, primary GID, and the full supplementary group list in one line on both AIX and Linux.
• Account attributes (AIX): lsuser bgate01 shows home, shell, groups, and lock state.
• Password aging (Linux): chage -l bgate01 confirms the force-change-at-login and expiry settings.
• Login test: have the user authenticate once, or test the shell yourself, to confirm the home directory and shell resolve correctly.
• Audit trail: update the ticket with the hosts granted, note when credentials were sent, and CC the requester.

Common Pitfalls to Avoid

• Allocating a new UID for an existing user. Always grep your records first; mismatched UIDs break shared-file ownership.
• Using -G without -a on Linux. It silently wipes existing secondary groups. Use usermod -a -G to append.
• Assigning the default group (staff on AIX) to managed accounts. Always set the correct primary and secondary groups explicitly.
• Forgetting chage -d 0 on Linux. Unlike AIX, Linux will not force a first-login password change on its own.
• Leaving service accounts interactive. Give functional IDs /bin/false and non-expiring passwords so jobs never break and stolen credentials are useless for login.
• Not resetting the failure counter after an unlock. A stale unsuccessful_login_count or faillog entry re-locks the account.

Key Takeaways

• AIX uses mkuser/chuser/mkgroup; Linux uses useradd/usermod/groupadd — same goal, different syntax.
• Keep UIDs and GIDs consistent across hosts by reusing existing numbers and maintaining a central counter; numeric IDs, not names, drive file ownership.
• Append groups with usermod -a -G — omitting -a replaces the entire supplementary group list.
• Force first-login password changes (automatic on AIX, chage -d 0 on Linux) and reset failed-login counters after every unlock.
• Harden service accounts with a non-login shell, a recorded owner, and a non-expiring password, and always verify with id before closing the request.

Frequently Asked Questions

What is the difference between mkuser and useradd?

mkuser is the AIX command and takes attributes as key=value pairs (for example pgrp=pvcs groups=grampim), while useradd is the Linux command and takes short flags (-g, -G, -u). Both create a user account, but they are not interchangeable across platforms.

How do I add a user to a group without removing existing groups in Linux?

Use sudo usermod -a -G groupname username. The -a (append) flag is essential — running usermod -G without it overwrites all of the user's existing secondary groups.

How do I check if a Linux user account is locked?

Run sudo passwd -S username; a status field of LK means the password is locked. Also check faillog -u username, because a failed-login count over the maximum locks the account independently of the password lock.

How do I create a service account that cannot log in interactively?

Create the account normally, then set its shell to a non-login shell: sudo usermod -s /bin/false username on Linux, or sudo chuser login=true rlogin=false username on AIX. Also set the password to non-expiring so scheduled jobs do not break.

For more hands-on Linux and AIX system administration walkthroughs, subscribe to our YouTube channel @explorenystream.