— LiveStream

Creating AIX user accounts the right way means doing more than running one command: you reserve a consistent UID, create the user with mkuser, set a password, lock down the home directory, and verify the account before you hand it over. This guide walks through the full IBM AIX workflow, fixes the rough edges in older site runbooks, and shows the secure, modern way to provision users on AIX 7.x.

The problem: inconsistent, insecure AIX user provisioning

On a shared AIX estate, the same person often needs an account on several LPARs. If each server picks its own UID, the same login ends up owning different numbers across machines, which breaks NFS file ownership, rsh/ssh trust, backups, and audit reporting. Manual provisioning also tends to skip the security steps: weak default passwords, world-readable home directories, and the legacy .rhosts trust files that attackers love.

The goal of a good AIX user management process is therefore three things at once: a UID that is identical on every server, a hardened home directory, and a repeatable command you can keep as a record. AIX gives you all of this through the mkuser command and its supporting tools.

The solution: a repeatable mkuser workflow on AIX

AIX stores user definitions in /etc/passwd and /etc/security/user, with encrypted passwords in /etc/security/passwd and group data in /etc/group. You never edit those files by hand. Instead you use the high-level commands, which keep all of them consistent:

• mkuser — create a new account and set its attributes.
• passwd or pwdadm — set or administer the password.
• lsuser — display an account's attributes.
• chuser — change attributes after creation.
• rmuser — remove an account (and optionally its home).

Run every step as root (or via a role with the UserAdmin authorization in RBAC). Below is the end-to-end procedure.

Step 1: Check whether the user already exists

Before creating an AIX user account, confirm the person does not already have one on the target server or elsewhere in the estate. Use the same login name everywhere — typically the person's corporate or directory ID.

1. Check the local server:
   1. lsuser gzhang — prints the account if it exists, or an error if it does not.
   2. grep -i '^gzhang:' /etc/passwd — a quick local lookup.
2. Check your central UID registry — many shops keep a flat file or spreadsheet listing every login and its assigned UID. Search it for the username before allocating anything new.

Key rule: if the user already has a UID anywhere in your environment, re-use that exact UID on the new server. Consistent UIDs keep file ownership and trust relationships intact across machines.

Step 2: Reserve the next UID from your registry

If the user is genuinely new, allocate the next free UID from your central counter. A simple, common pattern is a single file (for example last_id_num) holding the highest UID used so far.

1. Read the current value: cat last_id_num
2. The new UID is that value plus one. Example: if the file shows 1495, the new user gets 1496.
3. Write the new value back so the next admin does not collide:
   1. echo 1496 > last_id_num

Keep UIDs comfortably above the system-reserved range. AIX reserves low UIDs for system accounts, so choose a starting point (for example 1000 or higher) for human users and never reissue a number that once belonged to someone else — recycling UIDs lets a new person inherit the old person's files.

Step 3: Confirm the directory / LAN ID

If you were not given the person's directory login (their LAN ID), look it up in your identity source — for example Active Directory Users and Computers or your IdP. The AIX login name should match that ID so the account is easy to map back to a real person during audits.

Step 4: Create the account with mkuser

Now run mkuser. The general form is one command with attribute=value pairs followed by the login name. Here is a corrected, working example based on the legacy runbook:

1. Build the command and keep a copy in your per-server script for the record:
   1. mkuser id=1496 pgrp=appusers gecos='George Zhang' home=/home/gzhang fsize=-1 fsize_hard=-1 gzhang

What each attribute does:

• id=1496 — the UID you reserved in Step 2.
• pgrp=appusers — the user's primary group. It must already exist; create it first with mkgroup appusers if needed. (The legacy note used a literal <newgroup> placeholder — replace it with a real group name.)
• gecos='George Zhang' — the full-name/comment field. Quote it because it contains a space.
• home=/home/gzhang — the home directory. mkuser creates it and copies the skeleton files from /etc/security/.profile when the parent filesystem exists.
• fsize=-1 and fsize_hard=-1 — set the soft and hard file-size ulimit to unlimited. Only do this when the application genuinely needs to write large files; otherwise leave the system default in place.
• gzhang — the login name, always last.

Useful extras you should consider adding: shell=/usr/bin/ksh (or /usr/bin/bash), groups=appusers,dba for secondary groups, and su=false if no one should su into the account. After running it, AIX writes consistent entries into /etc/passwd, /etc/group, and /etc/security/user in one shot.

Step 5: Set the password and force a change at first login

A brand-new account has no usable password and is effectively locked until you set one. Assign a strong initial password, then force the user to change it on first login so you never know their permanent secret.

1. Set the password: passwd gzhang (you will be prompted twice).
2. Require a reset at first login: pwdadm -f ADMCHG gzhang

The ADMCHG flag tells AIX the password was set by an administrator, so the user is prompted to choose a new one immediately. Confirm your password policy — minlen, minother, histsize, and maxage — in /etc/security/user so the temporary password is accepted.

Step 6: Handle home-directory files securely (skip legacy .rhosts)

Older AIX runbooks tell you to create .rhosts and .netrc files in the home directory. Be careful here: both are legacy, plaintext-trust mechanisms tied to the insecure rsh/rlogin/ftp family.

• .rhosts grants password-less rsh access — a classic security hole. Modern equivalent: use SSH key-based authentication instead. If your environment is fully on SSH (it should be), you do not need .rhosts at all.
• .netrc stores FTP/login credentials in clear text. Replace it with sftp/scp and keys wherever possible.

If a legacy application still requires these files, create them correctly. Note the security model: .netrc must be owned by the user and readable only by them, while a per-user .rhosts is conventionally owned by the user too. The old runbook's instruction to chmod 755 .netrc is wrong — a world-readable credentials file is a serious exposure. Use restrictive permissions:

1. touch /home/gzhang/.rhosts /home/gzhang/.netrc
2. chown gzhang:appusers /home/gzhang/.rhosts /home/gzhang/.netrc
3. chmod 600 /home/gzhang/.rhosts
4. chmod 600 /home/gzhang/.netrc — .netrc is ignored by most clients unless it is 600 or stricter, precisely because it holds secrets.

For SSH key trust (the recommended path), create the .ssh directory instead:

1. mkdir /home/gzhang/.ssh
2. chown gzhang:appusers /home/gzhang/.ssh
3. chmod 700 /home/gzhang/.ssh — then drop the user's public key into authorized_keys at chmod 600.

Step 7: Update the central registry and request approval

Close the loop on governance. If the user is new to a tracked server, add them — in alphabetical order — to your inventory or license spreadsheet so the estate record stays accurate. Where your process requires sign-off from a system data manager or application owner, get that approval recorded before granting access. If the person already existed on a tracked server, no new registry entry is needed.

Common pitfalls when creating AIX user accounts

Even experienced admins trip over these. Watching for them saves a lot of cleanup:

• Primary group does not exist. mkuser fails if pgrp= points at a missing group. Run mkgroup first, or lsgroup ALL to confirm.
• Reusing or guessing a UID. Always pull the next number from your registry and write it back. Two users sharing a UID can read and delete each other's files.
• Leaving the account locked. If you forget passwd, the user cannot log in. Check with lsuser -a account_locked gzhang and unlock with chuser account_locked=false gzhang if needed.
• Wrong home-directory ownership. If the home or its dot-files are owned by root, the user cannot write their profile. Confirm with ls -la /home/gzhang.
• World-readable credential files. Never chmod 755 a .netrc. Use 600.
• Editing /etc/passwd by hand. Direct edits can desync the security databases. Use chuser/mkuser so AIX keeps everything consistent, then run usrck -t ALL to validate.
• Ulimit overreach. Setting fsize=-1 for every user is unnecessary; apply unlimited file size only where the workload needs it.

Verification: confirm the AIX account works

Never assume the account is good — prove it. Run these checks after provisioning:

The su - gzhang test is the single most reliable check: it confirms the shell, environment, and home directory all work together. Running id inside that session verifies the UID and group memberships landed exactly as planned.

Removing or modifying an account later

When the person leaves or moves teams, clean up properly so you do not leave orphaned files or stale trust:

• Change attributes: chuser shell=/usr/bin/bash gzhang or add a group with chuser groups=appusers,dba gzhang.
• Lock without deleting (common during offboarding): chuser account_locked=true gzhang.
• Remove the account and its home: rmuser -p gzhang then rm -r /home/gzhang after backing up any needed data.
• Decrement or annotate your UID registry only if your policy allows reuse — most do not, to prevent file-ownership bleed.

Always update the same inventory record on removal that you updated on creation, so the estate's user list stays trustworthy.

Key Takeaways

• Reserve a consistent UID from a central registry and re-use the same number for a user across every AIX server.
• Create accounts with mkuser id=… pgrp=… gecos=… home=… <login>; make sure the primary group exists first.
• Set a strong initial password with passwd and force a reset using pwdadm -f ADMCHG <login>.
• Skip legacy .rhosts/.netrc in favor of SSH keys; if you must keep them, set permissions to 600, never 755.
• Always verify with lsuser, usrck, and a real su - <login> login before handing the account over.

Frequently Asked Questions

What is the difference between mkuser and useradd on AIX?

On AIX the native command is mkuser; useradd is the Linux/Solaris equivalent and is not standard on AIX. mkuser writes to AIX's own security databases (/etc/security/user, /etc/security/passwd) and supports AIX-specific attributes such as fsize ulimits and login restrictions, so always use mkuser on AIX.

How do I set a password for a new AIX user without logging in as them?

As root, run passwd <username> and enter the temporary password twice, then run pwdadm -f ADMCHG <username> so AIX forces the user to choose their own password at first login. This way the administrator never knows the user's permanent password.

Why must I re-use the same UID across multiple AIX servers?

UIDs, not names, own files on UNIX. If a user has UID 1496 on one server and 1502 on another, NFS-mounted or migrated files will appear to belong to the wrong person, and trust relationships break. Re-using the same UID everywhere keeps ownership, permissions, and auditing correct across the whole estate.

Are .rhosts and .netrc files safe to use on AIX?

They are legacy and insecure. .rhosts enables password-less rsh and .netrc stores credentials in plain text. The modern, secure equivalent is SSH key authentication via ~/.ssh/authorized_keys. If a legacy app forces you to keep them, restrict permissions to 600 and owner-only access.

If this AIX walkthrough helped, subscribe to @explorenystream on YouTube for more hands-on sysadmin and UNIX guides.