Most mainframe owners are very concerned about the security of their system. Are they still using userids and passwords to sign on to mainframe applications? If they are, then they aren’t as concerned about security as they might say. Multi-factor authentication is the way to mitigate the risk of stolen passwords. And the latest IBM Z MFA 2.2 is now available. It can protect applications on z/OS, z/VM and Linux for z. This blog will focus on the enhancements for z/OS. 

MFA 2.2 introduces a new factor, usability, scale and operations improvements for z/OS. These are in addition to the dozens of factors already included within this offering.
 

New RSA REST API Factor

Recent RSA Authentication Manager servers (8.2 or later) support an HTTPS API called the SecurID Authentication API. This provides a superior ease of configuration vs. RSA-proprietary ACEv5 UDP protocol that’s leveraged for the existing z MFA factor:  AZFSIDP1. From a crypto perspective, this offers strong and industry-standard security for user credentials. For new customers that already use RSA SecurID, IBM recommends they start with this new factor that exploits the HTTPS REST API: AZFSIDP3.  

Usability Improvement

 
Masking or hiding a credential is now available for the web interface. When a user successfully satisfies an MFA policy via the out-of-band web interface, MFA issues a derived credential. This ”cache token credential” (CTC) was previously displayed in cleartext to the web browser user. Several customers complained about the clear value of this CTC. CTC masking, when enabled in STC settings, changes the end-user display so that the CTC value is initially hidden (but easily copied or revealed if requested. 

High usage and scale improvements

 
Any business with a large volume of users enabled for MFA will benefit from the scalability improvements.

Multiple Factor Instances

 
For service bureaus and other customers with segmented user populations, they can establish different factors and different external network services for different groups. This applies to the following external network services:
•       All RADIUS factors
•       All RSA SecurID variants
•       LDAP Simple Bind
•       AZFCKCTC (special factor for remote CTC checking)
 
For example: Different user populations supported by the same RACF database can authenticate against distinct RADIUS servers. Another example, with the LDAP factor, some users may be assigned to Microsoft Active Directory, while others might use OpenLDAP instances.

Automatic certificate approval options

 
For scaled deployments at customers using certificates, an automatic certificate approval process is now available such that end users can self-provision and reduce IT involvement and time. This reduces administrator overhead  by avoiding the approval step. This setting has three options and only applies to z/OS.

• N – for “Never”, default, requires admin approval
• E – for “External Security Manager” or ESM. RACF is an example of an ESM. This sses InitACEE to test for a pre-existing mapping that confirms a match between the presented X.509 certificate and the enrolling User ID. If a match is confirmed, the enrollment is auto-approved
• A – for ”Always”. A user who successfully completes self-service enrollment (by providing a trusted certificate and a correct User ID / Password combination) is immediately placed into REGSTATE:APPROVED.

Operational Improvements

 
Two operational improvements have been made. One is to collect factor/instance statistics and the other will be introduced soon after General Availability to invalidate CTCs.
 

 Factor/instance statistics collection

 
A new console modify command for diagnostic purposes has been introduced. It can be executed from an operator’s console or through SDSF. For example:

/f AZF#IN00,PLUGSTATS <factorName>
/f AZF#IN00,PLUGSTATS <factorInstanceName>
/f AZF#IN00,PLUGSTATS *ALL*
 
Currently, it only logs details to SYSPRINT when the STC is running at trace level 3. This function provides a foundation for future operations improvements.

Invalidate all CTCs for a given User ID

 
This will be introduced soon after GA via the service stream. A new console modify command will be made available for emergency use. In SDSF, for example:

/f AZF#IN00,CLEARCTCS <UserID>
 
The command works differently depending on the cache mode policy set. It is scoped to the Cache Name used by task that was targeted by the command. Customers will need to apply an APAR to enable this function.

Summary

 
All of these functions and new operations are intended to get MFA widely deployed across all businesses. Make sure that your business is truly a security expert by deploying IBM z MFA 2.2.​ Documentation can be found here. 

One note, make sure you pick up some last minute maintenance, in particular, PTF UI79156.