Setup Password no-expire for functional IDs in AIX

How to Set Up Non-Expiring Passwords for Functional IDs in AIX (Step-by-Step Guide)

If you manage AIX systems in an enterprise environment, you’ve likely encountered functional IDs—service accounts used by applications to connect to databases, middleware, or other backend systems. These accounts often require non-expiring passwords to avoid disruptions in automated workflows, but they must also comply with security policies that typically mandate password rotation. Fortunately, AIX allows you to configure functional IDs with passwords that never expire while still enforcing security best practices, such as disabling direct logins.

In this guide, I’ll walk you through the exact steps to configure a functional ID in AIX with a non-expiring password, explain the security implications, and show you how to verify and troubleshoot the setup. This is based on real-world experience managing AIX environments for large-scale applications like Unica, DB2, and WebSphere.

Why Functional IDs Need Non-Expiring Passwords

Functional IDs are service accounts used by applications to authenticate with databases, APIs, or other services. Unlike human user accounts, these IDs are embedded in configuration files, scripts, or application servers, and their passwords are rarely (if ever) entered manually. Examples include:

• Database connectors: A functional ID like uniadmn (used by Unica Listener) connects to DB2 without human intervention.
• Middleware services: WebSphere or MQ brokers often use functional IDs to authenticate with backend systems.
• Automated jobs: Cron jobs or scheduled tasks that run under a functional ID to perform maintenance or data processing.

If the password for these IDs expires, the application or job fails—often silently—until an administrator resets it. This can lead to outages, failed batch jobs, or broken integrations. At the same time, security teams rightly push back against hardcoding passwords or disabling expiration entirely. The solution? Configure the functional ID with a non-expiring password while disabling direct logins to mitigate risk.

Prerequisites

Before you begin, ensure you have:

• Root or sudo access to the AIX server where the functional ID resides.
• The exact username of the functional ID (e.g., uniadmn).
• AIX version 6.1 or later (this guide uses commands compatible with all modern AIX releases).
• Basic familiarity with smitty (AIX’s System Management Interface Tool) or command-line user management.

If you’re working in a regulated environment, check your organization’s security policy. Many enterprises allow non-expiring passwords for functional IDs only if direct logins are disabled. This guide follows that best practice.

Step 1: Log in to the AIX Server

SSH into the AIX server as

root or a user with sudo privileges:

ssh root@your-aix-server.example.com

If you’re using a non-root account with sudo, prefix commands with sudo where necessary.

Step 2: Launch SMITTY to Modify the User

AIX’s smitty tool provides a menu-driven interface for user management. Launch it with:

smitty user

This opens the Users menu. Navigate to Change / Show Characteristics of a User and press Enter.

Note: If you prefer the command line, you can use chuser instead (covered in the CLI Alternative section).

Step 3: Select the Functional ID

In the Change / Show Characteristics of a User screen, type the functional ID (e.g., uniadmn) in the User NAME field and press Enter. This loads the current settings for the user.

Step 4: Configure Non-Expiring Password and Disable Direct Logins

Modify the following fields in the user settings screen:

Field	Value	Explanation
User can LOGIN?	false	Disables direct logins to the account, reducing attack surface.
User can LOGIN REMOTELY (rsh, tn, rlogin)?	false	Prevents remote access via insecure protocols like rsh or rlogin.
Password MAX. AGE	0	Sets the password to never expire. 0 is the AIX standard for no expiration.

Here’s how the screen should look (fields may vary slightly by AIX version):

Change / Show Characteristics of a User

Type or select values in entry fields.
Press Enter AFTER making all desired changes.

[Entry Fields]
* User NAME                                    [uniadmn]
  User can LOGIN?                              false
  User can LOGIN REMOTELY (rsh,tn,rlogin)?     false
  Password MAX. AGE                            [0]

Press Enter to apply the changes. SMITTY will display a confirmation message if successful.

Step 5: Verify the Changes

After applying the settings, verify them using the lsuser command:

lsuser -f uniadmn

Look for these key attributes in the output:

uniadmn:
        id=205
        pgrp=staff
        groups=staff
        home=/home/uniadmn
        shell=/usr/bin/ksh
        login=false
        rlogin=false
        maxage=0

What to check:

• login=false: Confirms direct logins are disabled.
• rlogin=false: Confirms remote logins are disabled.
• maxage=0: Confirms the password never expires.

If any of these values are incorrect, revisit the SMITTY menu or use chuser to fix them.

CLI Alternative: Using chuser

If you prefer the command line, you can achieve the same result with:

chuser login=false rlogin=false maxage=0 uniadmn

Verify the changes with lsuser as shown above.

Common Pitfalls and Troubleshooting

1. "3004-694 User is currently logged in" Error

If the functional ID is in use (e.g., by an application or background process), AIX may block the changes. To resolve:

• Identify the process using the ID with ps -ef | grep uniadmn.
• Stop the application or service temporarily to free the ID.
• Retry the chuser or SMITTY command.

2. Password Still Expires After Setting maxage=0

If the password continues to expire, check for:

• System-wide password policies: Run lssec -f /etc/security/user -s default -a maxage to see if a global policy overrides your setting. If the output shows maxage=X (where X is a number), you may need to adjust the default policy or exempt the functional ID.
• LDAP or NIS integration: If the user is managed by LDAP or NIS, the password policy may be enforced centrally. Consult your directory services team.

3. Application Fails After Disabling Logins

If the application stops working after setting login=false, it may be trying to authenticate interactively. Common fixes:

• Ensure the application uses non-interactive authentication (e.g., SSH keys, Kerberos, or stored credentials).
• Check the application logs for authentication errors (e.g., Permission denied or Login incorrect).
• If the application requires a shell, set login=shell instead of false (but this is less secure).

4. "0518-504 Cannot change user" Permission Error

If you see this error, you lack sufficient privileges. Either:

• Log in as root.
• Use sudo if your account has sudo privileges: sudo chuser login=false rlogin=false maxage=0 uniadmn.

How to Verify the Setup Works

Beyond checking lsuser, test the functional ID’s behavior:

1. Test Direct Login (Should Fail)

Attempt to log in as the functional ID:

su - uniadmn

Expected output:

3004-501 Cannot su to "uniadmn" : The account is currently not available.

This confirms direct logins are disabled.

2. Test Remote Login (Should Fail)

Attempt a remote login via SSH (replace your-aix-server with the hostname):

ssh uniadmn@your-aix-server.example.com

Expected output:

uniadmn@your-aix-server.example.com's password:
Permission denied, please try again.

This confirms remote logins are disabled.

3. Test Password Expiration (Should Not Prompt)

If the functional ID is used by an application (e.g., Unica Listener), monitor the application logs for password expiration warnings. There should be none. For example, in DB2, check the db2diag.log for errors like:

SQL30082N  Security processing failed with reason "24" ("USERNAME AND/OR PASSWORD INVALID").

If you see this, the password may have expired despite maxage=0. Revisit the troubleshooting steps.

Key Takeaways

• Functional IDs need non-expiring passwords to avoid breaking automated workflows, but they must be secured by disabling direct logins.
• Use smitty user or chuser to set maxage=0, login=false, and rlogin=false for the functional ID.
• Verify changes with lsuser and test direct/remote logins to ensure the ID is locked down.
• Troubleshoot common issues like system-wide policies, LDAP/NIS overrides, or application authentication failures.
• Document the functional ID in your team’s runbook, including its purpose, owner, and any dependencies (e.g., "Used by Unica Listener for DB2 access").

FAQ

1. Can I set a non-expiring password for a functional ID without disabling logins?

Technically yes, but it’s a security risk. Functional IDs should never allow direct logins because:

• They often have elevated privileges (e.g., database access).
• Their passwords are typically stored in plaintext or weakly encrypted configuration files.
• Disabling logins reduces the attack surface for brute-force or credential-stuffing attacks.

If your security policy requires non-expiring passwords, always disable logins as a compensating control.

2. How do I reset the password for a functional ID if it’s locked?

If the functional ID’s password is locked or expired, reset it with:

passwd uniadmn

Then reapply the non-expiring settings:

chuser login=false rlogin=false maxage=0 uniadmn

Note: If the ID is locked due to too many failed login attempts, open up it first:

chuser account_locked=false uniadmn

3. What’s the difference between login=false and rlogin=false?

• login=false: Disables all direct logins, including local (su, ssh) and console access.
• rlogin=false: Specifically disables remote logins via insecure protocols like rsh, rlogin, and telnet. SSH is not affected by this setting.

For maximum security, set both to false.

4. How do I audit functional IDs in AIX?

To list all users with non-expiring passwords:

lsuser -a maxage ALL | grep maxage=0

To list all users with disabled logins:

lsuser -a login ALL | grep login=false

For a full audit, combine these with other attributes (e.g., rlogin, account_locked) and document the findings in your compliance reports.

5. Can I automate this setup for multiple functional IDs?

Yes! Use a loop with chuser in a shell script. For example:

#!/bin/ksh
for user in uniadmn appuser db2inst1; do
  chuser login=false rlogin=false maxage=0 $user
  echo "Configured $user: $(lsuser -a login,rlogin,maxage $user)"
done

Save this as configure_functional_ids.ksh, make it executable (chmod +x configure_functional_ids.ksh), and run it as root.

---

By following this guide, you’ve secured your functional IDs in AIX while ensuring they remain operational for your applications. This approach balances security and reliability—a core DevOps principle. Bookmark this page for future reference, and share it with your team to standardize functional ID management across your AIX environments.

Have you encountered other AIX user management challenges? Drop a comment below—I’d love to hear what you’re dealing with!

🛒 Recommended gear on Amazon

Disclosure: some links above are affiliate links — if you buy through them I may earn a small commission at no extra cost to you. Thanks for supporting the channel!