AIX user administration: mkuser/chuser/lsuser, /etc/security/user, and forcing a password change

What it is

AIX splits user account data across more files than a minimal /etc/passwd-only Linux mental model expects. mkuser, chuser and lsuser are the supported commands for creating, changing and listing accounts; they write to /etc/passwd and to the security database, chiefly /etc/security/user (per-user policy attributes such as login time restrictions) and /etc/security/passwd (password hash and flags); password history is kept separately in /etc/security/pwdhist. mkuser deliberately does not set a password: the man page states it does not create password information for a user, so a freshly created account has an asterisk in its password field and cannot log in with a password until an administrator sets one, typically with passwd or pwdadm.

pwdadm administers password-related flags separately from the password value itself: pwdadm -f ADMCHG <user> forces a change at the next login independent of setting a specific password (a password set by an administrator normally carries this flag already), and pwdadm -q <user> shows the current flags. /etc/security/user also carries login restrictions such as logintimes, which limits when an account may log in; because that attribute lives outside /etc/passwd, a login failure with no obvious cause in /etc/passwd often traces back to this file, and lsuser output can appear inconsistent if the value is malformed rather than merely restrictive.

Enhanced Role Based Access Control (RBAC) is the AIX mechanism for delegating specific privileged commands without full root: lsattr -El sys0 -a enhanced_RBAC shows whether it is active; lssecattr -F -c <path> checks whether a command already carries a privilege/role association before you build a custom one; a role is displayed with lsrole -f <rolename> and assigned with chuser roles=<rolename> <user>. Changes to roles or privileged-command entries only reach the kernel after setkst is run; a user then activates an assigned role with swrole <rolename>, which prompts for that user's password.

Why it matters

Treating /etc/passwd as the full picture misses the controls that actually gate access: a locked account, a time-of-day restriction, or a forced-change flag can all block a login while /etc/passwd looks unremarkable. RBAC lets an operational task run without a shared root password, but only if the administrator checks for an existing privilege/role first — duplicating one invites conflicting authorizations.

How to apply

• Create accounts with mkuser (as root), then set an initial password and make sure ADMCHG is set (pwdadm -q <user>, else pwdadm -f ADMCHG <user>) so the temporary password is never the account's long-term credential.
• Inspect the security database, not just /etc/passwd, when a login fails unexpectedly: lsuser -a logintimes <user> and a direct look at /etc/security/user for that stanza.
• Before scripting a custom RBAC role for a command, check lssecattr -F -c /path/to/command to see whether it already has one.
• Confirm Enhanced RBAC mode before relying on roles: lsattr -El sys0 -a enhanced_RBAC.

Pitfalls

• Assuming a new mkuser account is usable immediately; it has no password until one is set.
• Reading only /etc/passwd and missing a logintimes or similar restriction in /etc/security/user.
• Building a new RBAC role for a command that already has an authorization, creating two overlapping paths to the same privilege.