Enabling Db2 to receive RACF PassTickets for authenticating protected user IDs (deprecated)

To enable a Db2 server to receive requests from a Db2 requester over TCP/IP connections that use RACF protected user IDs and RACF PassTickets (as passwords), you must define an additional PTKTDATA profile and grant permission to that profile in RACF.

Before you begin

Complete the steps in Enabling Db2 to receive RACF PassTickets.

Deprecated function:

Start of change Receiving RACF PassTickets for authentication of RACF protected user IDs is deprecated. This deprecation does not apply to RACF PassTickets in general or any other use for them in Db2 for z/OS®. For best results, use one of the following alternatives to authenticate RACF-protected user IDs: End of change

Configure client certification authentication. For more information, see Encrypting your data with Secure Socket Layer (SSL) support.
In Db2 13 at function level 505 or later, enable token-based authentication. For more information, see Enabling Db2 for token authentication.

About this task

RACF protected user IDs cannot be associated with passwords and instead must use RACF PassTickets for authentication purposes. You must complete the following steps in RACF if protected user IDs are used in connection requests from a Db2 for z/OS requester to a Db2 for z/OS server.

Procedure

To enable Db2 as a server that can receive PassTickets for protected user IDs:

Define a PTKTDATA profile at the server system or sysplex that permits a particular stand-alone Db2 subsystem or a member of a Db2 data sharing group to evaluate whether a password is a PassTicket when a Db2 requester attempts to access that subsystem or member. If this permission profile does not exist, a connection that uses a RACF-protected user ID fails to connect. Issue one of the following commands:
```
RDEFINE PTKTDATA IRRPTAUTH.applname.userid
```
```
RDEFINE PTKTDATA IRRPTAUTH.applname.*
```
Where:
- applname is either the LUNAME or the IPNAME of the stand-alone subsystem or the GENERICLU or the IPNAME assigned to each member of the data sharing group.
- userid is either an asterisk ("*") or a specific protected user ID that you want to allow into the serving subsystem or a member of a data sharing group.
Permit the user ID that is assigned in the STARTED profile in the ssnmDIST address space to read the new profile by issuing one of the following commands:
```
PERMIT IRRPTAUTH.applname.userid CLASS(PTKTDATA) -
    ID(dist_userid) ACCESS(READ)
```
```
PERMIT IRRPTAUTH.applname.* CLASS(PTKTDATA) -
    ID(dist_userid) ACCESS(READ)
```
Where dist_userid is the user ID that is assigned in the STARTED profile in the ssnmDIST address space. If you use different STARTED user IDs for the ssnmDIST address space of members of the same Db2 data sharing group, you must give READ permission to this PTKTDATA profile to each of these user IDs.
Issue the SETROPTS command to enable the PTKTDATA profile that you created in the previous steps:
```
SETROPTS RACLIST(PTKTDATA) REFRESH
```

Example

The following example shows the RACF commands that define a PTKTDATA profile for SYEC1GLU for any user ID, that grant the ssnmDIST address space STARTED profile user ID (SYSDSP) READ access to that PTKTDATA profile; and that enable the new PTKTDATA profile:

RDEFINE PTKTDATA IRRPTAUTH.SYEC1GLU.*
PERMIT IRRPTAUTH.SYEC1GLU.* CLASS(PTKTDATA) -
     ID(SYSDSP) ACCESS(READ)
SETROPTS RACLIST(PTKTDATA) REFRESH