Processing of TCP/IP-based connection requests

The Db2 server completes a sequence of authentication tasks when handling a remote connection request that uses the TCP/IP protocol.

  1. As the following diagram shows, Db2 checks to see if an authentication token (RACF® encrypted password, RACF PassTicket, DRDA encrypted password, or Kerberos ticket) accompanies the remote request. See Security mechanisms for DRDA and SNA for more information about using DRDA encryption.
    Figure 1. Db2 processing of TCP/IP-based connection requests
    Begin figure description. DB2 processing of TCP/IP-based connection requests. End figure description.
  2. If no authentication token is supplied, Db2 checks the TCPALVER subsystem parameter to see if Db2 accepts IDs without authentication information.
    Recommendation: Setting the TCPALVER subsystem parameter to SERVER_ENCRYPT provides the best security because connections are accepted only if user credentials are provided to authenticate the user ID, and strong encryption is used to protect the user ID and credentials in the network. For more information, see Sending encrypted passwords or password phrases from Db2 for z/OS clients.
    • If TCPALVER=SERVER_ENCRYPT, Db2 requires a userid and a password. In addition, it requires that the security credentials be AES-encrypted or that the connection is accepted on a port that ensures AT-TLS policy protection, such as a Db2 Security Port (SECPORT). Kerberos tickets are accepted. RACF PassTickets, or non-encrypted security credentials, are accepted only when the connection is secured by the TCP/IP network.
    • If TCPALVER=NO or SERVER, Db2 requires the minimum of a userid and a password.
    • If TCPALVER=YES or CLIENT, Db2 accepts TCP/IP connection requests that contain only a userid.

    For more information, see TCP/IP ALREADY VERIFIED field (TCPALVER subsystem parameter)

  3. The identity is a RACF ID that is authenticated by RACF if a password or PassTicket is provided, or the identity is a Kerberos principal that is validated by Kerberos Security Server, if a Kerberos ticket is provided. Ensure that the ID is defined to RACF in all cases. When Kerberos tickets are used, the RACF ID is derived from the Kerberos principal identity. To use Kerberos tickets, ensure that you map Kerberos principal names with RACF IDs.

    In addition, depending on your RACF environment, the following RACF checks may also be performed:

    • If the RACF APPL class is active, RACF verifies that the ID has access to the Db2 APPL. The APPL resource that is checked is the LU name that the requester used when the attachment request was issued. This is either the local Db2 LU name or the generic LU name.
    • If the RACF APPCPORT class is active, RACF verifies that the ID is authorized to access z/OS® from the port of entry (POE). The POE that RACF uses in the RACROUTE VERIFY call depends on whether all the following conditions are true:
      • The TCP/IP Network Access Control is configured
      • The RACF SERVAUTH class is active
      If all these conditions are true, RACF uses the remote client's POE security zone name that is defined in the TCP/IP Network Access Control file. If one or more of these conditions is not true, RACF uses the literal string 'TCPIP'.

      If this is a request to change a password, the password is changed.

  4. The remote request is now treated like a local connection request (using the DIST environment for the DSNR resource class). Db2 calls RACF to check the ID's authorization against the ssnm.DIST resource.
  5. Db2 invokes the connection exit routine. The parameter list that is passed to the routine describes where the remote request originated.
  6. The remote request has a primary authorization ID, possibly one or more secondary IDs, and an SQL ID. (The SQL ID cannot be translated.) The plan or package owner ID also accompanies the request. Privileges and authorities that are granted to those IDs at the Db2 server govern the actions that the request can take.