Protecting connection requests that use the TCP/IP protocol

You can set your Db2 subsystem to send or receive connection requests that use the TCP/IP network protocol. You need to authorize the started task user ID (SYSDSP) that is associated with the DDF address space (ssnmDIST) to use the z/OS® UNIX System Services.

Procedure

To secure connection requests over TCP/IP:

Create an OMVS segment in the RACF® user profile for the started task user ID (SYSDSP)
Specify a z/OS UNIX user identifier of 0 and the maximum number of files of that the user is allowed to have concurrently active to 131702 in the following command:
```
ADDUSER ddfuid OMVS(UID(0) FILEPROCMAX(131702))
```
If the ddfuid ID already exists, use:
```
ALTUSER ddfuid OMVS(UID(0) FILEPROCMAX(131702))
```
The started task user ID of the Db2 distributed address space only needs a z/OS UNIX user identifier of 0 (UID(0)). A UID 0 is considered a superuser. If you don't want to grant the superuser authority to the started task user ID that is associated with the ssnmDIST address space during the Db2 installation, you can specify a value other than 0 for the UID parameter. Make sure that the value is a valid z/OS UNIX user identifier.
If you want to assign a z/OS group name to the address space, assign an OMVS segment to the z/OS group name by using one of the following RACF commands:
```
ADDGROUP ddfgnm OMVS(GID(nnn))... 
```
```
ALTGROUP ddfgnm OMVS(GID(nnn))...
```
where ddfgnm is the z/OS group name and nnn is any valid, unique identifier.

The standard way to assign a z/OS userid and a z/OS group name to a started address space is to use the z/OS Security Server (RACF) STARTED resource class. This method enables you to dynamically assign a z/OS user ID by using commands instead of requiring an IPL to have the assignment take effect. The alternative method to assign a z/OS user ID and a z/OS group name to a started address space is to change the RACF started procedures table, ICHRIN03.

Results

You can also manage TCP/IP requests in a trusted context. A trusted context allows you to use a trusted connection without needing additional authentication and to acquire additional privileges through the definition of roles.

The TCP/IP Already Verified (DSN6FAC TCPALVER) controls whether Db2 accepts TCP/IP connection requests that contain only a user ID. However, in the case of a trusted context, it is the definition of the trusted context, not the TCPALVER setting, handles the requirement for switching users of a trusted connection.

Do not set DSN6FAC TCPALVER to YES if you use a trusted context. If you set TCPALVER to YES in the definition of the trusted context, you need to define the authorization ID that establishes the trusted connection in the USER clause to enforce the authentication requirement.