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.
- 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.
- If no authentication token is supplied, DB2 checks the TCPALVER subsystem
parameter to see if DB2 accepts
IDs without authentication information.
- If TCPALVER=NO | SERVER, DB2 requires the minimum of a userid and a password.
- 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=YES | CLIENT, DB2 accepts TCP/IP connection requests that contain only a userid.
- 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 current operating system is z/OS V1.5 or later
- The TCP/IP Network Access Control is configured
- The RACF SERVAUTH class is active
If this is a request to change a password, the password is changed.
- 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.
- DB2 invokes the connection exit routine. The parameter list that is passed to the routine describes where the remote request originated.
- 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.