The 3am Wake-Up Call You Didn’t Need: Service Account Password Expiration
If your web services or overnight batch jobs have ever thrown a wobbly because a password decided to expire at the worst possible moment, you are not alone. On IBM i systems, password expiration is one of those security features that works brilliantly for normal interactive users and can become a right pain for everything else.
How IBM i Password Expiration Actually Works
IBM i tracks the date each user profile last changed its password. It then adds the password expiration interval to calculate when the password must be changed again.
You control that interval in two places:
- The system value QPWDEXPITV sets the global default (number of days).
- Each user profile has its own PWDEXPITV setting. This can inherit the system value (*SYSVAL), specify its own number of days, or be set to *NOMAX so the password never expires.
When the calculated expiration date arrives, the next sign-on attempt (interactive or batch) forces a password change before anything else can happen. For a developer sat at a green screen this is just a minor annoyance. For a service account quietly powering web services, APIs, FTP transfers or scheduled jobs? It is the digital equivalent of your automated process arriving at work to find the door locked and nobody with a key.
Why Service Accounts Cause Headaches
Service accounts are the user profiles that exist purely for automated processes. They rarely (if ever) sign on interactively. When their password expires there is nobody sitting there ready to type a new one. The result is failed jobs, broken integrations, support tickets at silly o’clock, and developers wondering why everything was fine yesterday but not today.
This is exactly why proactive monitoring is so useful. You want to know about expiring passwords while you still have time to do something about them, rather than discovering the problem when the phone rings.
A Quick Way to See Who Is About to Expire
Modern IBM i makes this easy with the QSYS2.USER_INFO catalog view. A simple SQL statement will show you exactly which enabled profiles have passwords coming up for renewal:
SQL
SELECT
user_name,
coalesce(text_description, 'No description set') as description,
date_password_expires,
(date_password_expires - CURRENT DATE) as days_remaining
FROM qsys2.user_info
WHERE date_password_expires BETWEEN CURRENT DATE AND CURRENT DATE + 14 DAYS
AND status = '*ENABLED'
ORDER BY date_password_expires;You can wrap something like this in a quick script, write the results to an IFS file, email it to the team, and clean up afterwards. Perfect for the occasional manual check.
A Proper, Production-Ready Monitoring Tool
For something you can trust to run every day without thinking about it, I built the Password Expiration Monitor (PWDExpMon).
It is a clean, modern IBM-i Command (with a Control Language, SQL RPG and Service Program under the covers). All written in modern fully free-format ILE style. The program:
- Accepts a simple parameter for the warning window (*WEEK for the next 7 days, *MONTH for 30 days, or *YEAR for a full lookahead). It defaults to 7 days if nothing is passed.
- Uses embedded SQL to efficiently scan QSYS2.USER_INFO for profiles whose passwords are about to expire.
- Builds a clear, readable report and writes it to an IFS file (handy for audit trails or feeding other processes).
- Sends an email alert so the security or operations team sees the information without having to go hunting for it.
The code is deliberately modular. User profile logic lives in service program procedures, email handling is kept separate, and there is proper logging and error handling throughout. You can call it manually for a quick look, or (much better) schedule it with ADDJOBSCDE so it runs automatically every night or every Sunday evening. That way you stay ahead of any expiration drama instead of reacting to it.
The complete working code sample, including the full SQLRPGLE source, data structures, compilation instructions (CRTSQLRPGI), parameter examples, and everything you need to get it running, is available here:
Before you compile it, remember to update the email configuration constants at the top of the program with your own SMTP server address, from address, and recipient addresses. Once that is done it is ready to go.
Final Thoughts
Password expiration exists for very good security reasons. Service accounts just need a bit of extra care and feeding so they do not cause unnecessary outages. With a simple monitoring program like this one in place you get the visibility you need without the 3am surprises.
Schedule it, let it run, and enjoy the peace of mind that comes from knowing your automated processes will not be ambushed by an expired password.
Drop this into your environment and I hope you find it useful (or if you extend it to do even more clever things).
Stay safe out there, and keep those service accounts happy.
