Enabling caching of MFA and RACF PassTickets credentials for clients without sysplex workload balancing

You can enable Db2 to store multi-factor authentication (MFA) credentials in the Db2 global authentication cache for distributed clients that do not use sysplex workload balancing or seamleass failover, and specify the amount of time that the entry remains if unused.

Before you begin

  • For clients that have sysplex workload balancing or seamless failover enabled, see Enabling caching of MFA-based authentication credentials for clients with sysplex workload balancing.
  • The multi-factor authentication support that is provided by Db2 is based on the IBM Z® Multi-Factor Authentication product, which provides enhanced logon security, addresses regulatory and industry requirements, and provides centralized and simplified management. If you are using IBM Z Multi-Factor Authentication, it must already be configured on MVS or across the z/OS® sysplex and must be configured in accordance with how clients will provide user authentication credentials from remote applications.
  • If you are using RACF PassTickets:

About this task

Multi-factor authentication (MFA) and RACF PassTickets are two distinct methods of providing additional authentication credentials at logon to verify a user's identity. Requiring an additional authentication credential ensures that a user's account cannot be compromised if one of their credentials is discovered.

Caching of MFA-based authentication credentials eliminates connection authentication failures that occur when clients that are not sysplex-WLB enabled connect to multiple members of a data sharing group on behalf of the original client application connection. Without caching of MFA-based authentication credentials enabled, connection authentication requests will fail because the additional authentication credential expires or becomes void because it's valid only for the initial connection request and cannot be reused for subsequent connection requests.

Procedure

To enable the caching of MFA credentials for clients that are not sysplex-aware, complete the following steps:

  1. If the AUTHEXIT_CACHEREFRESH subsystem parameter setting was NONE when Db2 started, issue a -STOP DB2 command.
    This step is required because online updates to the MFA_AUTHCACHE_UNUSED_TIME subsystem parameter are only supported if the AUTHEXIT_CACHEREFRESH setting is ALL when Db2 starts. Otherwise, Db2 issues message DSNZ014I with DSNZCMD1 for load-csect-name for any online attempt to update the MFA_AUTHCACHE_UNUSED_TIME value.
  2. Update the following subsystem parameters settings:
    • Set AUTHEXIT_CACHEREFRESH to ALL. In a Db2 data sharing group, this value must be set on every member. For more information, see AUTH EXIT CACHE REFR (AUTHEXIT_CACHEREFRESH subsystem parameter).
    • Set MFA_AUTHCACHE_UNUSED_TIME to a non-zero value, in the range 120–7200. The value that you specify is the number of seconds that an authentication cache entry for MFA-based authentication credentials can remain unused in the cache. The time limit resets each time that the cached authentication entry is used by a new connection from the same IP address. For more information, see MFA AUTH UNUSED TIME field (MFA_AUTHCACHE_UNUSED_TIME subsystem parameter).

      If the members of a data sharing group are started with different MFA_AUTHCACHE_UNUSED_TIME settings, the entire group uses the value the largest value specified for any member. For example, if member DB2A is started with a value of 120 and member DB2B is started with 7200, member DB2A requests the matching cached credentials in DB2B every 120 seconds until the cache in DB2B times out. The request for matching credentials in other members occurs only when either the cached credentials are not found in the current member or the cached credentials in the current member exceed its unused time and a new replay of the credentials has been received on a new connection request from the same IP address. For best results, set the parameter for all members of the group to the same “maximum” value.

      The request for matching credentials in other members occurs when the cached credentials are not found in the current member or the cached credentials in the current member exceed its unused time, and a new replay of the credentials is received on a new connection request from the same IP address.

  3. Issue a -START DB2 command.

What to do next

If Db2 issues message DSN3582I, take the required actions. For more information, see the system programmer response in DSN3582I.