Migrate to KDFAES for Stronger Encryption of RACF Passwords
By removing the password with the first command and then cleaning it out with the second, the password history entries are destroyed, because you don’t want legacy DES encrypted password history entries hanging around.
Hopefully everyone is backing up active primary and backup RACF databases nightly. If not, implement such a scheme before moving forward with AES. I would recommend specifying a limit of 255 on the generation data group you use for your RACF database backups if you have a virtual tape system installed because it could give you MIGRAT2 at MIGRAT1 speeds. The cost of keeping something on tape and the slow speed at which it recalls has become a thing of the past.
When upgrading to z/OS V2.2 note there is a new parm coded in IGGCATxx parmlib called GDGEXTENDED. By default it’s set to NO. When set to YES you can code a limit of up to 999 on your GDG bases. Imagine keeping almost three years of copies of RACF for historical purposes. Using zSecure you could compare differences between copies of RACF as well.
Backup All DES Encrypted Password Values
I recommend a strategy using zSecure’s advanced functions to backup all DES encrypted password values before converting to AES. If something goes bump then restore that individual password instead of having to backout the entire change. This method uses zSecure’s CKGRACF command, which is a Time Sharing Option authorized command. Using this technique you can manipulate and backup fields previously out of reach with native RACF commands like LJDATE, LJTIME, and previous and current passwords, to name a few. Yes, you can restore a UserID to its previous password value.
The CKGRACF command is secured using RACF profiles that start with CKG in the XFACILIT (eXtended FACILITY class) and is documented in the zSecure Admin and Audit Reference Guide.
Some sample CARLa for easily backing up all current password values en masse, provided by Rob van Hoboken of IBM, is:
new nopage f=ckrcmd nulls name=ckgpwd
select segment=base has_password=yes
/* Next two defines to accommodate systems pre-passasis */
define passasiskw(0 hdr$blank "passasis('") true where,
define passasisval(hex 0) as passasis where,
/* Next define to accommodate absence of PWDX */
define pwdxkw(0 hdr$blank "pwdx('") true where,
'field' class key(8) 'set',
"password('" | password(hex,0) | "'X)",
pwdxkw | pwdx(hex,0) | pwdxkw("'X)"),
"passdate('" | passdate(hex,6) | "'X)",
passasiskw | passasisval | passasiskw("'X)")
May I Have This RVARY Dance?
If you have password issues another strategy is to first turn off AES support in RACF as follows:
Then restore RACF from the prior night’s backup of the RACF database I highly recommended you set up earlier.
The downside to this strategy is that now you have to forward recover any work you’ve done since that backup was taken. If you have a problem with AES support even a week later then you’ll be trying to “redo” all of your prior updates to RACF.
You could also issue
ALTUSER UserID EXPIRE to force everyone to change their password which, once
SETR PASSWORD(NOALGORITHM) is issued, would force them back to a DES encrypted password. This method isn’t practical for non-human UserIDs since they are used by servers, etc.
Helpful Features With the New AES PTFs
If you must turn off AES support [
SETR PASSWORD(NOALGORITHM)], there are two pieces of design RACF development came up with that make it much easier:
AES encrypted password histories will still evaluate. Even with AES support off in SETROPTS, if you have AES encrypted histories, RACF will still evaluate them.
For systems that use the RACF Remote Sharing Facility, a mixed environment is acceptable. This means AES and DES encrypted RACF databases can co-exist in the same RACF sharing network and passwords between them will synchronize.
Now this is what I call intelligent and forward-thinking design. Thank you, RACF development and Bruce Wells specifically for his guidance with the AES technology over the years.
New ALTUSER Keywords
I’ve mentioned ALTUSER keywords throughout the article but want to call attention here.
ALTUSER UserID PWCLEAN
Run this as you convert to AES because we like a squeaky-clean RACF database. It will ensure any stale password history entries are gone. Have you lowered the number of password history entries you keep? The easiest thing to do is run this command. They run fast and it takes very little effort.
Raise your hand if you remember the CUTPWHIS utility from the RACF downloads page. I sure do. With the invention of PWCLEAN we no longer have a need for it.
We can finally forcibly expire a password. This is a new tool in your arsenal to save for a rainy day.
ALTUSER UserID EXPIRE
zSecure Command Verifier for Maximum Safety
If you have zSecure Command Verifier installed then I would highly recommend defining the following two RACF profiles in the XFACILIT class:
C4R.RACF.USER.PASSWORD.ALGORITHM UACC(NONE) AUDIT(ALL(READ))
C4R.RACF.USER.PASSWORD.SPECIALCHARS UACC(NONE) AUDIT(ALL(READ))
They should be defined with an empty access list as well. The goal here is to prevent either of these SETROPTS commands until you’ve taken appropriate steps to ensure that your installation is ready for them.
I also recommend building out the following profiles and only allow the security engineering personnel responsible for maintaining your RACF database UPDATE access:
C4R.USER.PWCONVERT.** UACC(NONE) AUDIT(FAILURES(READ))
C4R.USER.PWCLEAN.** UACC(NONE) AUDIT(FAILURES(READ))
Finally, with application of PTF UA81117 (zSecure v2.1.1) or UA81178 (zSecure v2.2.0) the existing C4R.USER.PWEXP.<owner>.<UserID> policy is enhanced to include the EXPIRE keyword.
I haven’t discussed special characters support in this article but, in short as a part of the APAR for AES support, RACF can now also support many unique characters like ? or ! in the password field. This support can come with its own caveats so again I recommend defining that profile above until you have taken the necessary steps to plan and make ready for its use.
I’ve taken you through the key planning and technical steps to migrate to AES support for RACF. If we consider the need for strong encryption in the ever-advancing age of technology we live in and the many standards that require stronger cryptography, such as PCI and NIST, the case for conversion to AES for RACF password encryption becomes clear. It’s not a nice to have feature, it’s a critical necessity.
Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.
comments powered by