Today, protecting digital environments is more critical than ever. As cyber threats become more sophisticated, traditional password-based authentication methods are no longer enough to safeguard sensitive data and critical applications, even on z/OS. This is where IBM Z MFA (Multi-Factor Authentication) comes in.
IBM Z MFA enhances security by requiring users to verify their identity using multiple authentication factors, such as one-time passcodes, smart cards, biometrics, or mobile authentication apps. By implementing MFA on IBM Z systems, organizations can strengthen access controls, reduce the risk of credential theft, and meet compliance requirements for data security.
In this blog, we’ll briefly explore how IBM Z MFA works and showcase our experiences with its implementation.
IBM Z MFA initial setup
The initial setup is quite simple. SMP/E installation is done same as always, using the information from the program directory. The software package is fortunately not that big (around 120 cylinders). After the installation is done, there are some small customization steps done in z/OS, but nothing major. Things like copying and tailoring the started task procedure in our PROCLIB, APF authorizations, PPT customizations, all of which can be activated without disruption using operator commands.
RACF setup is a bit more involved though, since this is where most of the security architecture will be set up. As always, you need to define a started task user and a matching STARTED class profile, which should look something like this:
ADDUSER AZFSTC OWNER(STCGRP) DFLTGRP(STCGRP) NOPASSWORD OMVS(AUTOUID)
After that, it’s time to activate the class which will contain profiles which carry the settings for each authentication factor.
SETROPTS GENERIC(MFADEF) GENCMD(MFADEF) RACLIST(MFADEF) CLASSACT(MFADEF)
Next up is to define who will have access to the IBM Z MFA configuration panels, and to which level (read-only, or read-write). This is done using a profile in the FACILITY class named IRR.RFACTOR.MFADEF.AZFSTC. If a user has READ access, they are allowed to see all of the configuration options, while UPDATE or higher grants modification options to the user. READ is perfect for auditors, while UPDATE is meant for security administrators. If there aren’t any security auditors, perhaps it is worth considering granting READ rights to system administrators so that they can see for example what ports and network addresses need to be passed through and so on.
The documentation suggests that RACF be configured for mixed-case passwords (passphrases are always case-sensitive), but that can be very impactful to end-users, especially if they are used to case-insensitivity (even though it is a big no-no for a long time now). It might not just be a matter of end-users, but also of applications. If you have applications that still somehow depend on RACF’s case-insensitivity, then a change like this is a pure no-go area. For those scenarios, it is advisable to stick to the in-band authentication methods, and not to integrate with case-sensitive authentication factors like LDAP, RADIUS, SecurID or others.
IBM Z MFA supports a lot of authentication factors. They can be split into two groups: in-band and out-of-band factors. They can be easily explained by the following scenario: when you are logging into TSO/CICS/IMS and you can complete the whole authentication workflow without leaving your terminal emulator, those are in-band factors. These include generic RFC TOTP, Yubico tokens, SecurID tokens, or LDAP, just to name a few.
If you need to leave the terminal emulator to open a web page or another program to complete the authentication outside of the terminal and then return, then we’re talking about out-of-band factors. These include client certificate authentication (not to be confused with TN3270 Express Logon Feature), OpenID Connect, and so on.
For the sake of user experience, you might choose to go with in-band authentication, since it is the least disruptive to the end-user and has the least number of “moving parts”. In a scenario where in-band authentication is used, an end-user would log on to the mainframe normally and enter their password or passphrase together with the second factor (their AD domain password or TOTP token generated on their phone) in the same password field separated by a colon or a similar special character (which obviously can’t be reused in the passphrase). Another option is to have a two-step log on, where in the first step they would enter their username and password, same as before, and then they would be asked to enter their second factor on a separate screen.
TOTP
When configuring any type of authentication factor, IBM provides a helpful guide and checklist of steps involved, so it is very easy to follow along. Most of the steps are the same for each authentication method, so once you set it up, you’re likely done.
For TOTP (one-time tokens) you need to set up the IBM Z MFA web services started task, since this is where the end users will follow the on-boarding (provisioning) process. If you’ve ever enrolled yourself with an OTP token like Microsoft Authenticator, Google Authenticator or Authy, you will recognize the process. The STARTED profile will be the same as the one for the main started task, meaning that it will not have a password (or a phrase), it won’t have a TSO segment, but it will have an OMVS segment with a unique UID. Once you’ve defined a started task profile in RACF, you need to grant it access to a lot of CSF-related to PKCS#11 tokens and use of cryptographic services.
One important thing to be aware of is the fact that AT-TLS will be involved with the web services, since it is unwise to transmit access credentials via an unsecured Web connection. To spare you the worry and meddling with PAGENT policies, IBM ships a sample AT-TLS policy AZFTTLSX in the Z MFA SAMPLIB. You can use that as a good starting point and tailor it to your case. A clear example of code is worth 1000 pages of documentation.
Once you have done all that, all that’s left is to configure the web server using the ISPF panels.
After you are sure that the web services are up and running, you can define a new authentication factor in the MFADEF class:
RDEF MFADEF FACTOR.AZFTOTP1 OWNER(userid or group-name)
You also need to create a profile which is used to check who can change the settings of the TOTP factor:
RDEF FACILITY IRR.RFACTOR.MFADEF.AZFTOTP1 OWNER(userid or group-name) RDEF FACILITY IRR.RFACTOR.USER UACC(NONE) PERMIT IRR.RFACTOR.USER ACCESS(UPDATE) CLASS(FACILITY) ID(AZFWEB) PERMIT IRR.RFACTOR.MFADEF.AZFTOTP1 ACCESS(ALTER) CLASS(FACILITY) ID(user-id) PERMIT IRR.RFACTOR.MFADEF.AZFTOTP1 ACCESS(READ) CLASS(FACILITY) ID(AZFWEB)
Once that is done, you can use the ISPF panels to further configure the TOTP factor and decide how many digits will be generated, how often the keys are rotated etc.
After you’ve defined your defaults, it’s time to try and enroll a single user. User is configured for TOTP by executing:
ALU [Login ID] MFA(FACTOR(AZFTOTP1) ACTIVE TAGS(REGSTATE:OPEN))
That command only enables TOTP as an option for a user, after that the user needs to go to this URL, where they will log in using their ESM credentials and provision their token. Only after they are provisioned, will they be required to use it.
Bypass
Everything is fine and dandy when everything is working properly and is in shipshape, but what about when things go haywire? Personally, the idea of being locked out of the system due to the security system malfunction is at the top of my list of nightmares. Murphy’s law always strikes where it hurts the most, and the security system going on the fritz and preventing rightful logins is just too tempting. For that reason, IBM Z MFA contains a failsafe option to allow access in case of emergency for those IDs. There is an option to allow a password-only fallback in case the STC is down, or external servers return a “no decision” result, which is done by executing ALU user MFA(PWFALLBACK) command.
Bulk provisioning
When dealing with mainframe users, we’re typically talking about thousands and thousands of active users which are defined in the ESM. Enabling MFA for each of them manually is a monumental task, so IBM has helpfully provided an azfbulk utility which allows you to make a flat file listing all of the MFA users and their new authentication factors.
Translation of messages
One interesting feature of IBM Z MFA is that it supports translating all the web pages and messages to your native language, and since you have the original HTML pages at your disposal, you can also customize the look-and-feel of the portals to match your company design guidelines which helps ease users into the new functionality. To customize the translation, you need to specify an alternate USS location where the document files are stored and copy the original set of files to that location. The original files are stored in htdocs/i18n/ folder and they should not be modified. Once you copy them, you can edit the JSON to translate the messages themselves and style the HTML as much as you like, as long as the logic (field names and so on) stays the same.
