Skip to main content

Migrate to KDFAES for Stronger Encryption of RACF Passwords

The need for strong encryption is increasing in the ever-advancing age of technology we live in, along with many standards that require stronger cryptography.

Blue background with lines like the wires on a circuit board. In the middle is a glowing white shield.


Out of all the recent advances in RACF technology, perhaps the one most overlooked is password encryption. Did you know RACF now offers Key Derivation Function Advanced Encryption Standard (KDFAES) encryption of RACF passwords (commonly referred to as AES)? Would you like peace of mind that your passwords are protected by strong AES technology? Support has been available since Nov. 3, 2014.

Strategies can make deployment of AES encryption of all RACF passwords easier.

Why Convert to AES?

In the 21st century there’s no such thing as “too much encryption.” We live in a world where technology is advancing so fast that we must keep pace with the exponential increase in CPU capacity. Numerous standards require use of the latest cryptographic technology—e.g., PCI and National Institute of Standards (NIST). Whatever the reason, there's no justification to continue to use the old single 56-bit Data Encryption Standard (DES) algorithm originally deployed for RACF decades ago.

Converting Any UserIDs With Masked Passwords: Required for z/OS V2.2

A required z/OS 2.2 migration action ensures you don’t have any UserIDs still using the “masking” method. Since this method predates RACF’s use of DES you probably don’t have any of these but you should trust but verify. If the return code of your ICHDEX01 is set to 08 then there aren’t any masked passwords. Two methods for validating if you have masked password values are:

1) Run ICHPSOUT with PARM=DES. According to Mark Nelson, RACF development, IBM:

  • This method attempts to de-mask a password before doing a DES encrypt operation
  • It will write error messages if the de-masked value contains any invalid password characters
  • DES encrypted passwords run through this de-masking utility have a very high chance of not having valid chars

2) Use zSecure Audit

  • Typing the command AU.V to reach the verify and cleanup security database options
  • Select “Password - UserIDs with trivial passwords”
  • zSecure can compute any passwords that are weak or still using masking

Plan For PTF Installation

A very wise systems programmer once said, “Joel, before you put your fingers on the keyboard you should stop and think.”

The biggest issue with getting AES enabled is ensuring you have all the necessary PTFs rolling out on schedule. IBM has a website with Informational APAR II14765 to document all the necessary PTFs to install.

Further, applications that use RACF for authentication (e.g., CICS) may need PTFs. For CICS V5.1 three PTFs are provided via APARs PI21866, PI33454 and PI39336

Some APARs recently opened for which there aren’t PTFs yet. I recommend monitoring for when PTFs become available. PI64443 for increased CPU usage by CICS, OA50846 which affects IMS Connect logins (recommend you don’t convert IMS UserIDs until after this fix is applied) and OA50748 for CPU usage for applications that use the R_Password callable service (IRRSPW00).


VLF Caching and CPACF

The virtual lookaside facility (VLF) needs to be properly configured to cache RACF information. It’s the first logon of the day that’s the costly one. If you don’t enable this option then you run the risk of experiencing a performance problem.

To enable VLF caching of logons in SYS1.PARMLIB(COFVLFxx) code:


While here, validate the following entries exist in the COFVLF parmlib member:





In order of appearance to the parmlib statements above:

  • Cache RACF Group Tree
  • Cache User Security Packet for z/OS UNIX
  • Cache z/OS UNIX Group IDs
  • Cache z/OS UNIX User IDs

Changing these parms requires a restart of VLF or IPL.

The Central Processor Assist for Cryptographic Functions (CPACF) needs to be enabled for hardware acceleration of AES. There are two ways to validate this support is enabled:

  1. See your systems programmer who can validate from the HMC that CPACF is enabled for every system.
  2. If you’re running the Integrated Cryptographic Services Facility, check it for message:

To Convert or Not to Convert

There are two schools of thought about migrating to AES. You can simply enable the support in RACF:


Then wait for passwords to convert as time marches on. Eventually every password in your password history will be converted to AES as users logon to change them. But do you have time to wait?

I prefer and recommend option two. Enable AES support in RACF the same way. Next, build RACF commands to convert all passwords to AES using the new command:


I prefer converting everything up front because I can tell my auditors I am “fully” converted to AES and I’d rather find out now rather than later if I have a problem. Your mileage may vary depending upon the business requirements so I provide both methods; choose the one that makes the most sense for your business.

Passphrase Considerations

If you have adopted passphrases before enabling AES then you’re in for a shock. There’s not any command you can use to convert a RACF passphrase from DES to AES. The only option you have available to you is to force the end user to change the password using command:


That’s right; RACF now supports expiration of passwords. You could forcibly expire the password of your passphrase users as one strategy.

If you have non-humans (i.e., servers), logging in using passphrases then consider this approach:

ALTUSER UserID Phrase(‘MyLongPasswordPhraseGoesHere’)

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.

Before Implementation

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,
  sortlist 'ckgracf',
           '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.


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.



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:


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:


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.

Be Proactive

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.

IBM Systems Webinar Icon

View upcoming and on-demand (IBM Z, IBM i, AIX, Power Systems) webinars.
Register now →