Encryption of link between TSS MFA and RSA Server secured via TLS 1.2
search cancel

Encryption of link between TSS MFA and RSA Server secured via TLS 1.2

book

Article ID: 202618

calendar_today

Updated On:

Products

Top Secret

Issue/Introduction

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.

Environment

Release : 16.0

Component : CA Top Secret for z/OS

Resolution

apar's  SO10511 & S009436

Additional Information

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.

TIP

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)).

NOTE

  • Only one RSA agent can be active on the z/OS platform. If the CA RSA and IBM RSA authentication factors are both active, CA Top Secret uses the CA RSA rules to perform authentication.
  • The MSCA is exempt from RSA authentication.

CA Top Secret reverts to using the regular ACID password/password phrase for signon validation when one of the following conditions is true:

  • The MFA control option setting is FACILITY, and the user does not have a PERMIT in the CASECMFA class to resource TSSMFA.IBM.facility with ACC(USE).
  • The MFA control option setting includes a FALLBACK specification (or a fallback attribute is assigned to an ACID), and the RSA server is not available.
  • The Advanced Authentication Mainframe interface is deactivated through started task shutdown or an MFA control option specification—for example, MFA(IBMRSA(NO)). Perform the following tasks to enable RSA SecurID factor authentication under IBM MFA:

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:

START AZF#IN00

WARNING

  • The started task must start after TCP/IP is available.
  • If TCP/IP is stopped, the address space terminates and cannot be restarted until TCP/IP is restarted. At startup, messages appear, confirming initialization. Now you can activate multi-factor authentication services globally

 

 

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

NOTE

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))

  • IBMRSA Selects the IBM RSA authentication factor.
  • factor_activation Dictates whether the authentication factor is active: –

- 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.

  • FALLBACK|NOFALLBACK

Specifies to attempt native password validation (FALLBACK) or deny entry validation (NOFALLBACK) when factor authentication is not available.

Default: FALLBACK

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:

 TSSMFA.IBM.facility

  • IBM Specifies IBM RSA as the service provider.
  • facility Is the CA Top Secret facility where a security event occurs:

– 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.

WARNING

  • Do not place this type of PERMIT in the ALL record.
  • AUDIT records are never cut for the access checks, even if auditing is active for the user. • If the security file is shared, the PERMIT can be qualified by the SYSID() restriction.

To define the PERMIT for controlling authentication, take one of the following actions:

  • Follow the instructions in each job step in the MFAITSS2 JCL to update it, then submit the MFAITSS2 job.
  • Create the PERMIT manually.

TIP

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.

NOTE

  • To administer the authentication data, the MSCA/SCA needs ACID(MAINTAIN) authority and UPDATE access to CASECAUT resource class entity TSSCMD.ADMIN.IBMRSA.
  • Although you can assign multiple factors to a user, only one factor can be active at any given time. After adding or modifying factor authentication data, you can list the factor authentication data portion of a security record to verify settings.

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)

                         MFADATA(SIDUSERID:user_id)

                         MFACTIVE(YES|NO|FACILITY)

  • MFACTOR(AZFSIDP1 ) Specifies the factor name.
  • MFACTIVE Determines whether the factor is active:

 – 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.

  • MFADATA(SIDUSERID:user_id ) (Case-sensitive and required only for user ID mapping) Maps the CA Top Secret user ID to the associated RSA user ID that is defined in the RSA Server. SIDUSERID is the required tag name when MFACTOR(AZFSIDP1) is specified (to activate IBM RSA authentication).

Important! To successfully validate the tag data, the IBM RSA server (AZF#IN00) must be actively running.

Tag data limit: 1024 characters

Example: SIDUSERID:ibmusr1

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)

                                 MFACTIVE(FACILITY)

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)

                              MFADATA(SIDUSERID:ibmusr1)

                               MFACTIVE(YES)

Remove a Factor or User Mapping from an ACID

To remove a factor or user mapping from an ACID, use the following command syntax:

NOTE

On a REMOVE command, the product allows only MFACTOR and MFADATA specifications.

TSS REM(acid) MFACTOR(AZFSIDP1)
                          MFADATA(SIDUSERID:user_id)

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)

                         MFADATA(SIDUSERID:user_id)

                         MFACTIVE(NO|YES|FACILITY)

 Example: Modify Factor Data for an ACID

This example replaces user mapping for an ACID:
 TSS REP(mfauser) MFACTOR(AZFSIDP1)

                                 MFADATA(SIDUSERID:ibmusr1)

 

 

 

 

 

Powered by Wolken Software