Managing outbound connection requests

If you plan to send requests to another Db2 subsystem, you need to consider the subsystem's security measures for network connections. You need to know what those measures are and make entries in your CDB to correspond to them.

About this task

If you are planning to send remote requests to a DBMS that is not Db2 for z/OS®, you need to satisfy the requirements of that system.

Db2 chooses how to send authentication tokens based on the network protocols that are used (SNA or TCP/IP). If the request is sent using SNA, the authentication tokens are sent in the SNA attachment request (FMH5), unless you are using Kerberos. If you use Kerberos, authentication tokens are sent with DRDA security commands. If the request uses TCP/IP, the authentication tokens are always sent using DRDA security commands. See Security mechanisms for DRDA and SNA for more information about using DRDA encryption.

At least one authorization ID is always sent to the server to be used for authentication. That ID is one of the following values:

  • The primary authorization ID of the process.
  • If you connect to the server using a CONNECT statement with the USER keyword, the ID that you specify as the USER ID. The CONNECT statement allows non-RACF® user IDs on the USER keyword. If connecting to a remote location, the user ID is not authenticated by RACF.

However, other IDs can accompany some requests. You need to understand what other IDs are sent because they are subject to translation. You must include these other IDs in table SYSIBM.USERNAMES to avoid an error when you use outbound translation. The following table shows the IDs that you send in the different situations:

Table 1. IDs that accompany the primary ID on a remote request
In this situation: You send this ID also:
An SQL query, using Db2DRDA-protocol access The plan owner
A remote BIND, COPY, or REBIND PACKAGE command The package owner

If the connection is to a remote non-Db2 for z/OS server using DRDA protocol and if the outbound translation is specified, a row for the plan owner in the USERNAMES table is optional.