If you surveyed your users, you'd find that most would rather give blood than change their password. And if you're operating in an IBM SNA peer-to-peer environment with multiple AS/400s, users have to go through the process for each machine. If MIS isn't administering the process, users are bombarded with the "Password has expired" message each time they sign on to a different machine. If MIS is administering the password change, someone must oversee the change and send out all those "confidential" new- password memos - a waste of time and paper.
Instead of administering password changes, I leave it in the users' hands. Because many of my users use the same profile at each facility (four AS/400s operating in a SNADS network via high-speed digital circuits), I created utility PWDRMT to change a user's password on local and remote AS/400s at the same time.
PWDRMT doesn't validate passwords, but always accepts the new password from the system and then structures the CHGUSRPRF (Change User Profile) command for submission at each remote facility. The concept is simple:
- Before you start, the system security officer must install PWDRMT and specify it in system value QPWDVLDPGM (details about how QPWDVLDPGM works in conjunction with the user- defined program are available online).
- When a user's password expires at periodic intervals, it must be changed. The next time the user signs on, the system calls the CHGPWD (Change Password) command, which prompts the user for a new password.
- After the system accepts the new password, it calls PWDRMT (the password validation program specified in system value QPWDVLDPGM).
- PWDRMT submits individual network jobs using the SBMNETJOB (Submit Network Job) command to execute the CHGUSRPRF command on each remote machine (more information about SBMNETJOB is available online).
Before you run PWDRMT, you must set up profiles to receive and run the network job at each remote facility. For instance, we name each AS/400 after the town where it's located. Thus, in the town of Pontotoc, the system name is PONTOTOC. Then we create user profile PON with the directory entry:
User ID/Address. . . . . . . PON PON
Description . . . . . . . . SNADS DIRECTORY
System name/Group . . . . . PONTOTOC
User profile . . . . . . . . PON
Network user ID . . . . . . PON PON
Defining profile PON on all four AS/400s provides a generic way of sending information and running processes on the PONTOTOC AS/400. User profile PON accepts all remote jobs sent to the PONTOTOC machine.
Once you've created these user profiles with directory entries, add them to each location's physical file SYSTEMS - which you create at each site for the purpose of listing each system and/or profile to which the local machine has a connection. PWDRMT will read SYSTEMS sequentially and submit jobs to each remote machine.
Changing Passwords Simultaneously
When PWDRMT (Figure 1) is called, it is passed the new password, the old password, and a return status value.
PWDRMT issues a RTVJOBA (Retrieve Job Attributes) command to retrieve the user profile name and a RTVNETA (Retrieve Network Attributes) command to retrieve the system name. PWDRMT moves the system name (e.g., PONTOTOC) from eight-character field &plt to three-character field &host (truncating PONTOTOC to PON, for example). PWDRMT compares the SNADS profile name retrieved from file SYSTEMS to the value of the variable &host to avoid submitting the CHGUSRPRF command on the local machine.
Using the new password, user profile name, and current system name, PWDRMT executes CHGUSRPRF on the remote machine(s) via the SBMNETJOB command. (The system changes the local password after executing PWDRMT.) To submit the remote jobs, PWDRMT sequentially accesses physical file SYSTEMS to obtain the remote SNADS system profiles. PWDRMT's main loop cycles through the list of AS/400s, submitting the CHGUSRPRF command to each remote machine in turn until the user's password has been changed on each or until an error occurs.
Source file RMTCL is the source file for the SBMNETJOB command. An error occurs if RMTCL is unavailable or if the SBMNETJOB command fails. Both errors cause PWDRMT to be terminated. When PWDRMT terminates abnormally, the system sends a message to the system security officer, so be sure to specify your security officer in variable &secofr.
Whether PWDRMT is executed successfully or aborts, PWDRMT always sets the return value to 0 to force the local machine to accept the password as valid so that users aren't prevented from changing their passwords locally.
Make Source File Dynamic
Because I use the SBMNETJOB command with a static source file, I created RPG program CHGSRC to make the source file as dynamic as the variety of user profiles and new passwords. In variable &line1, PWDRMT strings together a call to CL program RMTPWD (which I'll discuss in a moment) with the parameters for the user profile and the new password, then passes &line1 to CHGSRC (Figure 2). CHGSRC adds the string to the batch job command string in CHGSRC's compile-time array and writes it to batch file RMTCL.
Figure 3 shows a sample batch source that CHGSRC created and placed in file RMTCL; the string sent from PWDRMT to CHGSRC is listed on the third line. The batch string contains a scrambled version of the user name and the new password.
After regaining control, PWDRMT issues a SBMNETJOB command to the remote system. After PWDRMT submits the network job specified in RMTCL, PWDRMT repeats the steps for each remote site specified in file SYSTEMS.
Before you can use CHGSRC, you must
- modify the initial library list and job description listed with the BCHJOB (Batch Job) command, which is contained in the compile-time array, to suit your environment, and
- set the file type option to *SRC when you compile source file RMTCL. Unless RMTCL is set to *SRC, the SBMNETJOB command won't recognize the batch string as a CL source data file.
Once received at the remote system, the batch source calls CL program RMTPWD (Figure 4), which resides on each remote machine. RMTPWD descrambles the user name and password (see next section for information about encrypting the name and password) and executes the CHGUSRPRF command to change the remote password.
To provide some security when transmitting data to remote locations, I wrote program SCRAMFLD to encrypt the user's name and password. On the local machine, PWDRMT calls SCRAMFLD immediately after it issues the RTVNETA command (discussed in section Changing Passwords Simultaneously, above). SCRAMFLD (Figure 5) specifies that bits 1 (variable BIT1) and 6 (variable BIT2) of each character passed to SCRAMFLD are to be flipped. The values specified for variables BIT1 and BIT2 can be changed to modify the program's encryption, but you must then make the same changes to SCRAMFLD at the remote location. When the remote machine receives the scrambled characters, SCRAMFLD descrambles them by flipping the bits back to their original settings.
Before installing this utility, make sure SCRAMFLD meets your company's security policy. If it doesn't, you should explore other encryption options. (Complete instructions for getting utility PWDRMT up and running are available online.)
Some shops don't give all users the authority to submit network jobs. If this is the case in your facility, you can create a program to capture user names and passwords to a database file to be updated in batch at night. Passwords would be updated a day late, but that is still useful to users unable to submit remote jobs themselves. If you want to administer password changes but don't have an application that changes them, you can modify PWDRMT to update passwords on local and remote machines based on a master file.
Gain Remote Control
The AS/400 doesn't provide a capability for changing remote passwords, no doubt in part because of potential security problems. The PWDRMT utility is one way to fill this gap.
Dalton C. Middleton is a programmer in Verona, Mississippi, specializing in manufacturing and warehousing systems. He has three years' experience on IBM midrange systems and holds an MSBA from Mississippi State University. You can reach him at firstname.lastname@example.org.
Sidebar: System Value QPWDVLDPGM
System value QPWDVLDPGM lets you specify a user-written program (PWDRMT in the accompanying article) to do additional password manipulation. QPWDVLDPGM is shipped with a value of *NONE. If, after looking over the system validation options, you decide that none of those options provides what you want, you can write a program customized for your needs. Enter the program's name in the QPWDVLDPGM system value, and the system will execute that program whenever a user changes a password using the CHGPWD (Change Password) command, the change password option from the ASSIST menu, or API QSYCHGPW. All the program must do is accept and return (in order):
New Password - 10 character field
Old Password - 10 character field
Return Value - 1 character field
When the system executes the CHGPWD command at sign-on or when the user enters it on the command line, the system performs all the system-provided validation checks. If the system accepts the new password, it then passes that password to your password validation program for additional checking. Have your program return a 0 to signal that the program accepts the new password. Any other returned value causes the system to reject the new password.
Although system value QPWDVLDPGM indicates which program (if any) is the user-written password validation program, the program specified doesn't have toperform any type of password validation.
Sidebar: SBMNETJOB Command
You can use the SBMNETJOB (Submit Network Job) command to submit jobs on remote members of a SNADS network. In a batch source file (for example, Figure 3's RMTCL, discussed in the article), you can specify the specifics of the job's operation as well as the commands to be issued on the remote machine. Pay special attention to Figure 3's BCHJOB command, which indicates the beginning of the batch string and the attributes needed to run the job (such as job name, job description, and initial library list). When submitting a network job, you specify the source file, the user profile the job is to run under, and the remote device name.
Sidebar: Installation Outline
1. Create user profiles for each machine with corresponding directory entries. In the following example, change the USRPRF, CURLIB, JOBD and OUTQ parameters to the appropriate values for your system. USRPRF should equal your abbreviated system names (see Preparation section in accompanying article).
USRPRF(profile) USRCLS(*pgmr) +
CURLIB(library) INLMNU(*SIGNOFF) +
TEXT('SNADS PROFILE FOR DISTRIBUTIONS') +
SPCAUT(*ALLOBJ *SECADM) +
SPCENV(*NONE) DSPSGNINF(*NO) +
Change USRID, USRD, USER, and SYSNAME to match the values on your system. USRID and USER should equal your abbreviated system names (see Preparation section in accompanying article). SYSNAME should equal the system name in question.
ADDDIRE USRID(profile profile) +
USRD('SNADS DIRECTORY ENTRY') +
2. Compile physical file SYSTEMS and use the CL UPDDTA (Update Data) command to enter each profile created in step 1. In the following example, replace the value library/srcfile with the name of the library and source file on your system that contains your DDS source code.
CRTPF FILE(library/SYSTEMS) +
3. Compile RMTCL, setting the file type to *SRC. In the following example, replace the value library/srcfile with the name of the library and source file on your system that contains your DDS source code.
CRTPF FILE(library/RMTCL) +
4. Compile RPG program SCRAMFLD. If you want to change the bits specified, do it after the first successful run. In the following example, replace the value library/srcfile with the name of the library and source file on your system that contains your DDS source code.
CRTRPGPGM PGM(library/SCRAMFLD) +
5. Edit the compile-time array listed in CHGSRC to suit your environment. Compile CHGSRC. In the following example, replace the value library/srcfile with the name of the library and source file on your system that contains your DDS source code.
CRTRPGPGM PGM(library/CHGSRC) +
6. Edit all libraries (that is, those to contain CHGSRC, SCRAMFLD and RMTCL) listed in PWDRMT to suit your program and file locations. Because PWDRMT could be run before your initial program (at sign-on), the necessary libraries might not be available. Be sure to add the libraries before the security section in PWDRMT. Compile. In the following example, replace the value library/srcfile with the name of the library and source file on your system that contains your DDS source code.
CRTCLPGM PGM(library/PWDRMT) +
7. Compile RMTPWD. In the following example, replace the value library/srcfile with the name of the library and source file on your system that contains your DDS source code.
CRTCLPGM PGM(library/RMTPWD) +
8. Repeat steps 1-7 at all network locations.
9. Change system value QPWDVLDPGM on local system to call PWDRMT.
10. Issue the CHGPWD command to test. After a successful run, change system value QPWDVLDPGM to call PWDRMT at all remote locations.