Setting Up User Profiles Without Passwords
March 29, 2006 Hey, Joe:
I’m a little confused as to what happens when you set a user ID’s Password parameter (PASSWORD) to *NONE. I’m not sure whether it determines if a password is or is not required for that user to log on to the system. A little explanation here would be helpful.
Setting a user’s password to *NONE is a relatively simple concept, but it has a few confusing aspects. Here’s how it works.
You can set the User Password parameter to *NONE when you create the user profile or when you run the following Change User Profile command (CHGUSRPRF):
CHGUSRPRF USRPRF(user_profile_name) PASSWORD(*NONE)
User passwords can also be set to *NONE in the iSeries Navigator’s user Properties screen. You can navigate to this screen by opening the Users and Groups, then the All Users mode in iSeries Navigator, right-clicking on the user profile you want to change, and then selecting Properties from the pop-up menu that appears. Once you’re on the user’s Properties screen, click on the Password dropdown box and select No password (sign-on not allowed) and save your new user properties.
Changing a user profile password to *NONE prevents a user from interactively signing on to an i5, iSeries, or AS/400 system. It essentially disables a user from performing any type of interactive work on the system, including starting a 5250 telnet session, performing an FTP transfer, or reading and updating system information through ODBC or JDBC. When a no-password user profile tries to start a 5250 telnet session on an i5 partition, for example, it will receive a CPF1118 message, No password associated with user &1 (where &1 is a parameter containing the user profile name). If the user password was changed to *NONE through iSeries Navigator, you may also see a CPF1193 message, User Profile &1 cannot sign on, when the user tries to start a 5250 session.
But just because a user profile does not contain a password, it does not mean that profile cannot be used to perform work on the system. There are two specific situations where it is extremely handy to use user profiles without passwords for system functions.
So if you want to run a batch job under a user profile that has no password, you can submit the job for batch work with a Submit Job command (SBMJOB), like this:
SBMJOB CMD(CALL PGM(library/program_name)) JOB(job_name) USER(no_password_user)
And this job will run just fine in batch mode. In fact, several IBM-supplied user profiles that are solely used for i5/OS server functions are now shipped without a password. This is also a great technique for running nightly batch jobs where you want all of your nightly jobs to run with extended authorities under a single user profile that will never be allowed to sign on.
The other issue that administrators run into with no-password users is in identifying which users do and do not require passwords to sign on to the system. When viewing individual user profiles on the green screen by using the Display User Profile command (DSPUSRPRF) or in an iSeries Navigator user Properties screen, there is no option that tells you whether a user is set up with a password of *NONE.
However, you can produce a list of all user profiles and whether or not they have a password by using the Display Authorized User command (DSPAUTUSR), like this:
DSPAUTUSR will display all the user profiles defined on your system and whether or not each profile has a password. If a user profile’s PASSWORD parameter contains a value of *NONE, an “X” will appear for that profile under the column marked No password. To print this display as a spooled file report, run DSPAUTUSR using these parameters.
DSPAUTUSR SEQ(*USRPRF) OUTPUT(*PRINT)
As a side issue, DSPAUTUSR can also be run to display the same user profile information sorted by group membership. So if you want to see whether or not your group profiles are set up with a password, you can run DSPAUTUSR this way.
DSPAUTUSR SEQ(*GRPPRF) OUTPUT(*)
And those are the ins and outs of creating a user with no password. As I said, it’s a very easy technique to implement as long as you understand the way the system works.