Admin Alert: How to Retrieve Password Parameters for Auditors
October 5, 2011 Joe Hertvik
Your organization’s fiscal year may have ended on September 30. Meaning you could soon be visited by auditors looking for information on how your organization operates its AS/400-class machine (iSeries, System i, Power i). Your auditors will be particularly interested in your password configuration parameters and whether they meet standards. To that end, here’s a quick drill for retrieving password setup values at audit time. What Auditors Want Auditors generally require you to provide the following sets of password related parameters.
Here’s how to retrieve both groups of information. Password Configuration Parameters Auditors always request system password configuration parameters, the rules users must follow when selecting a new password. There are two ways to retrieve these settings on AS/400-class machines. You can generate a printout from a 5250 green screen; or you can copy them from System i Navigator (OpsNav) password screens. The green screen method is the easiest to use. Run the following Work with System Values (WRKSYSVAL) command to print all your password configuration settings. WRKSYSVAL SYSVAL(QPWD*) OUTPUT(*PRINT) All password system value names start with QPWD (QPWDMAXLEN for maximum password length, QPWDMINLEN for minimum password length, etc.). Each value is listed with its current setting, its shipped (default) setting, and its system value description. OpsNav can be used to present password parameters more clearly. But it takes a little more work to prepare the printout. Here’s how to pull and present password parameters from OpsNav. 1. Open a new Microsoft Word document. 2. Open the Security→Policies node under your target partition. Click on the Password Policy entry that appears in the right-hand pane. This brings up the Password Policy Properties screen shown here. 3. Click on the General tab on the Password Policy Properties screen and press the ALT→PrtSc keystroke combination. This copies just the general password policy parameters to the Windows clipboard. Alt→Tab over to Word and paste this screen copy into your document. 4. Go back to the Password Policy screen and repeat the process after clicking on the Validation and the Expiration tabs. Copy these screens into the Word document. 5. Give the saved Word document to your auditors. Password Validation Programs and Auditors Many shops use a password validation program (PVP) to impose extra restrictions on passwords that differ from what the system password parameters require. Auditors are also interested in these programs. To explain how PVPs affect your audit, let’s assume a shop requires minimum 15-character pass phrases for all users. Let’s also say Program X (a third-party iSeries client software) requires users to sign on to your iSeries machine using a 10-character password input field. This means that any 15-plus-character pass phrase user can’t access Program X. Because Program X users need 10-character or less passwords, we must allow for 10-character maximum password users as well as 15-plus-character minimum passphrase users on the system. That’s where a PVP comes in. A PVP is a custom-written program that runs after a newly-created password has been validated by your system’s password parameters. The PVP performs additional password checking beyond your system values, and it approves or denies new passwords based on these additional checks. To create our two-tier password system, we would set up our Maximum password length (QPWDMINLEN) system value to 10 characters, and our Minimum password length (QPWDMINLEN) system value to six characters. This means every user needs to create passwords that are six-to-10 characters long. For every Program X user, we would add them to a special Program X user group. Then we would write a PVP according to IBM standards that evaluates new passwords by doing two things:
The PVP is attached to IBM’s exit point for password validation. In this way, the PVP creates our two-tier password system by imposing additional password standards above what the system requires. For a more detailed explanation of password validation programs, see this article on placing additional restrictions on i/OS passwords. Why Auditors Like PVPs Auditors are interested in PVPs because they create a secondary password verification system. For a two-tier password system, the auditors must ensure that only the exemptions get the shorter passwords (i.e., you’re not accidentally or intentionally skirting the requirements). To document PVP usage, you can provide the auditor with the following items from your iSeries system. First, a printout of the Password Validation Program (QPWDVLDPGM) system value. QPWDVLDPGM either contains the name and library of your PVP or it contains the literal *REGFAC. When QPWDVLDPGM is set to *REGFAC, the program name is retrieved from the QIBM_QSY_VLD_PASSWRD system exit point. Use the following Display System Value (DSPSYSVAL) command to print out the QPWDVLDPGM value. DSPSYSVAL SYSVAL(QPWDVLDPGM) OUTPUT(*PRINT) Give the resulting printout to the auditor. Then, if the program name is registered with the system validation exit point (QIBM_QSY_VLD_PASSWRD), run these commands to get a printout of your exit point and the name of your exit program. Use the Work with Registration Information (WRKREGINF) command to display the QIBM_QSY_VLD_PASSWRD exit point. WRKREGINF EXITPNT(QIBM_QSY_VLD_PASSWRD) Take Option 8=Work with exit program to display the name of your PVP on this screen. Print and give this screen to the auditor. Finally, if you’re using a PVP, print the PVP source code and give it to the auditor. i OS Password Related System Values Finally, here are the names and description of all the password system values. This list can be given to the auditors to help them understand what each system value does.
RELATED STORY Placing Additional Restrictions on i/OS Passwords
|
Excellent documentation. Helpful and composed all the details targeting the user to collect everything required in one click.