Implement multifactor authentication for privileged users accessing the z/OS platform, using CA Top Secret and RSA SecureID Suite.
Is there is a way to encrypt the link between the z/OS TSSMFA STC and the RSA server using ICSF keystores. This internal connection is already secured via TLS 1.2, but is not encrypted via key labels.
Release : 16.0
Component : CA Top Secret for z/OS
apar's SO10511 & S009436
Enabling Multi-Factor Authentication
Multi-factor authentication allows increased diligence in verifying the identity of users who seek access to z/OS. Mainframe authentication capabilities are designed to prevent data breaches and address compliance requirements. CA Top Secret supports the use of IBM Multi-Factor Authentication (IBM MFA) during system entry validation for RSA SecurID users and Generic Radius users.
This article addresses CA Top Secret support of IBM Multi-Factor Authentication. CA Top Secret also supports using IBM Multi-Factor Authentication with CA Advanced Authentication Mainframe, which allows increased diligence in verifying the identity of users who seek access to z/OS. Advanced authentication capabilities can help prevent data breaches and address compliance requirements. For more information about using IBM Multi-Factor Authentication with CA Advanced Authentication Mainframe, see the CA Advanced Authentication Mainframe documentation.
Enable RSA SecurID Authentication Under IBM MFA
As a system administrator or security administrator, you want to mandate that users be authenticated by supplying RSA SecurID credentials (through IBM® Multi-Factor Authentication for z/OS® (IBM MFA)).
CA Top Secret reverts to using the regular ACID password/password phrase for signon validation when one of the following conditions is true:
Start the Multi-Factor Authentication Started Task
Before activating multi-factor authentication services, you need to initiate the started task. You can also stop the started task (STOP AZF#IN00) if you want users to use their regular password or password phrase for logon. From the console, issue the following command to start the multi-factor authentication started task:
Activate Multi-Factor Authentication Services Globally
After starting the multi-factor authentication started task, you can use the MFA control option to globally activate multifactor authentication services
Although this process activates global settings, you can add/modify the fallback capability for individual users.
To control multi-factor authentication services globally, issue the following command:
TSS MODIFY MFA(IBMRSA(factor_activation,FALLBACK|NOFALLBACK))
- NO (Default) Deactivates the factor (which means this factor is never called for signon authentication). –
- YES Activates the factor. Validation is subject to specific factor data for the given user.
– FACILITY Activates the factor and specifies that validation is subject to facility-specific permits for the given user.
Specifies to attempt native password validation (FALLBACK) or deny entry validation (NOFALLBACK) when factor authentication is not available.
Example: Activate the IBM RSA Authentication Factor and Allow Password Fallback
This example activates the IBM RSA authentication factor and allows for native password validation if factor authentication becomes unavailable:
TSS MODIFY MFA(IBMRSA(FACILITY,FALLBACK))
Example: Disable the IBM RSA Authentication Factor
This example deactivates the IBM RSA authentication factor:
TSS MODIFY MFA(IBMRSA(NO))
Example: Activate the IBM RSA Authentication Factor and Disallow Password Fallback
This example activates the IBM RSA authentication factor and disallows native password validation if factor authentication becomes unavailable:
TSS MODIFY MFA(IBMRSA(YES,NOFALLBACK))
Define PERMITs for Controlling Authentication by Facility
If you activate MFA(IBMRSA) using the FACILITY option, all users must have USE access to the following resource in the CASECMFA resource class:
– For CICS, IMS, or APPC/MVS applications, this is the facility name.
– For TSO, it is the characters TSO.
– For z/OS batch jobs, it is the characters BATCH. Consult your product documentation for details regarding the facility name that is used by your product.
Member MFAITSS2 in yourhlq.CFF7JCL0 contains the JCL to create the PERMIT and provide the proper access.
To define the PERMIT for controlling authentication, take one of the following actions:
The PERMIT may be assigned to a profile so that all users attached to the profile become controlled.
Example: Create the PERMIT Manually
This example creates a PERMIT manually. With this PERMIT in place, the user must provide RSA credentials when signing on to TSO.
TSS ADD(dept) CASECMFA(TSSMFA.IBM)
TSS PERMIT(user) CASECMFA(TSSMFA.IBM.TSO) ACC(USE)
Add, Modify, or Remove Factor Authentication Data for an ACID
A Master Security Control ACID (MSCA) or Central Security Control ACID (SCA) with proper authorities can add a factor to an ACID record; define user mapping; and modify/remove existing factors or user mapping for the ACID.
After activation of RSA SecurID factor authentication, users can sign on with their multi-factor authentication credentials
Add a Factor or Data Element to an ACID
To add a factor to an ACID, use the following command syntax:
TSS ADD(acid) MFACTOR(AZFSIDP1)
– YES Specifies that the factor is active for this ACID.
– NO Specifies that the factor is disabled and never called for signon authentication.
– FACILITY Specifies that the factor is controlled by facility-specific PERMITs for the user. With this setting, authentication is required only if the user has a PERMIT to resource TSSMFA.IBM.facility in the CASECMFA class.
Important! To successfully validate the tag data, the IBM RSA server (AZF#IN00) must be actively running.
Tag data limit: 1024 characters
Example: Define a Factor for an ACID
This example defines a factor for an ACID, specifying that the IBM RSA factor is active for this ACID:
TSS ADD(mfauser) MFACTOR(AZFSIDP1)
Example: Add User Mapping to an Existing Factor for an ACID
This example adds user mapping to an existing factor for an ACID:
TSS ADD(NADIA) MFACTOR(AZFSIDP1)
Remove a Factor or User Mapping from an ACID
To remove a factor or user mapping from an ACID, use the following command syntax:
On a REMOVE command, the product allows only MFACTOR and MFADATA specifications.
TSS REM(acid) MFACTOR(AZFSIDP1)
Example: Remove User Mapping from an ACID This example removes user mapping from an ACID:
TSS REM(mfauser) MFACTOR(AZFSIDP1) MFADATA(SIDUSERID:ibmusr1)
Example: Remove a Factor from an ACID
This example removes an entire factor from an ACID:
TSS REM(mfauser) MFACTOR(AZFSIDP1)
Modify Factor Data for an ACID
To modify factor data for an ACID, use the following command syntax:
TSS REP(acid) MFACTOR(AZFSIDP1)
Example: Modify Factor Data for an ACID
This example replaces user mapping for an ACID:
TSS REP(mfauser) MFACTOR(AZFSIDP1)