Feeding the Auditor: Taking Care of Problem User Profiles
September 29, 2010 Hey, Joe
|
Help. My iSeries shop is being audited. The auditors want a list of all users who have default passwords. They also want us to automatically disable any user profiles that haven’t been active for 60 days. I don’t want to automatically disable my inactive users because I have a lot of profiles that should never be disabled on our system. How do I handle this? I’m on i/OS V5R4M5. –Brett Finding your default password users is easy. Simply run the following Analyze Default Password (ANZDFTPWD) command and you’ll get a listing of all system users whose password is equal to their user profile name. ANZDFTPWD ACTION(*NONE) Even though *NONE is the default setting for the Action Taken Against Profiles (ACTION) parameter, I always run this command with ACTION set to *NONE. I do this because ANZDFTPWD can also be set up to either: 1) automatically disable all user profiles with default passwords; or 2) automatically expire the passwords for all default password profiles. If I run the command with an action of *NONE, ANZDFTPWD simply produces a report that I can look at and determine which profiles I need to take action for. After you run ANZDFTPWD, you can examine the generated report to help you straighten out any obvious issues that you don’t want the auditors to see. After making adjustments, you can then rerun the report, and give the second report to the auditors. As produced, the generated ANZDFTPWD report tells you two things about each default password user profile.
The command also issues the following CPC2232 message to your desktop and to your joblog: "&1 user profiles have default passwords of which &2 have the status of *ENABLED" Where parameter 1 (&1) equals the total number of default password users and parameter 2 (&2) is equal to the number of default password users whose user profiles are enabled. With this information (total number of active users with default passwords as well as which individual users have active non-expired default passwords), you can respond to the auditors depending on how serious the issue is. If it turns out that the majority of your default password users are disabled or have expired passwords, you may be able to remediate the problem by correcting the remaining user profiles and running ANZDFTPWD a second time. After settling on a course of action, you can run ANZDFTPWD in one of the following two modes. ANZDFTPWD ACTION(*PWDEXP) Or: ANZDFTPWD ACTION(*DISABLE) Running ANZDFTPWD with the ACTION parameter equal to *PWDEXP, sets all the default password user passwords to *EXPIRED, which means that those users will have to change their passwords the next time they sign on, eliminating each user’s default password problem. The second option, where ACTION is set to *DISABLE, disables ALL of your default password users, which can put a number of active users immediately out of commission. I only recommend automatic disablement if the number of active default password users is relatively low and automatically disabling users won’t hinder production or cause a flood of calls to your Help Desk. As for automatically disabling any users who haven’t signed on to your system in 60 days, that’s easily doable, but there are a few pitfalls. i/OS offers three commands to help you perform this function.
There are a few ins and outs to using these commands. Before working with the Profile List commands, check out this article on The Joys and Pains of Automatically Disabling User Profiles for more information. But given your requirement for automatically disabling inactive users, these commands can help you meet that goal. HTH –Joe RELATED STORY The Joys and Pains of Automatically Disabling User Profiles
|
