Add QDDMDRDASERVER server authentication entry special value

In some environments, it is cumbersome to maintain server authentications in DRDA and RDB DDM file environments. As systems are added to the network topology, per user profile server authentications for every server have to be administered. Customers with many users and many servers face the decision of whether to restrict/control access on each server using the Change DDM TCP/IP Attributes (CHGDDMTCPA) command or on each client using the Add Server Authentication Entry (ADDSVRAUTE) command.

The dilemma faced when choosing to enforce password validation on the servers is that every user who needs to connect to the server needs admin work done on their behalf using ADDSVRAUTE, for every target server or require every user to supply a userid and password on each CONNECT statement.
 

Improvement:

A special value QDDMDRDASERVER has been added to the ADDSVRAUTE command SERVER parameter for DDM & DRDA connections. This special value allows an administrator to configure a user to work with all possible DDM or DRDA connections to any system in the TCP/IP network via a common userid and password. Once configured for a specific user, no additional changes need to be made for that user as systems are added to the Relational Database Directory.

As before, this does not allow a customer to connect over DRDA/DDM unless they specify a valid userid and password on the server authentication entry or CONNECT statement.

What are server authentication entries?
A server authentication entry is a way to define a userid & password to send via a connect request over TCP/IP. A server authentication list is associated with every user profile on the system. By
default, the list is empty; however, you can add entries by using the Add Server Authentication Entry (ADDSVRAUTE) command. When you attempt a DRDA connection over TCP/IP without specifying a userid and password, the DB2 for i client (AR) checks the server authentication list for the user profile under which the client job is running. If it finds a match between the RDB name on the CONNECT statement and the SERVER name in an authentication entry (which must be in uppercase), the associated USRID parameter in the entry is used for the connection user ID. If a PASSWORD parameter is stored in the entry, that password is also sent on the connection request.

A server authentication entry can also be used to send a password over TCP/IP for a DDM file I/O operation. When you attempt a DDM connection over TCP/IP, DB2 for i checks the server authentication list for the user profile under which the client job is running. If it finds a match between either the RDB name (if RDB directory entries are used) or QDDMSERVER and the SERVER name in an authentication entry, the associated USRID parameter in the entry is used for the connection user ID. If a PASSWORD parameter is stored in the entry, that password is also sent on the connection request.

Usage details:

The special value QDDMSERVER already exists which allows the ability for non-RDB DDM file users to make DDM connections to servers with a common userid and password. The new special value QDDMDRDASERVER is a superset of QDDMSERVER expanding this support to RDB DDM files and DRDA connections.

For DRDA connection requests, if a server authentication entry specifying the system name exists, and a user ID and password are not passed in on CONNECT statement, the user ID and password associated with the server authentication entry will take precedence over the server authentication entry for QDDMDRDASERVER.

For DRDA connection requests, if a server authentication entry specifying the system name exists, and a user ID and password are passed in on CONNECT statement, the user ID and password associated with the CONNECT statement will take precedence over any server authentication entry.

For RDB DDM file connection requests, the server authentication entry specifying the system name will take precedence over the server authentication entry for QDDMDRDASERVER.
For non-RDB DDM file connection requests, the server authentication entry QDDMSERVER will take precedence over the server authentication entry for QDDMDRDASERVER.

Example 1:

Environment: Three systems (SYSA, SYSB, SYSC)

SYSA is the application requestor (AR)
SYSB and SYSC are the application servers (AS)

On SYSA:
ADDSVRAUTE USRPRF(YOURPRF) SERVER(QDDMDRDASERVER) USRID(youruid) PASSWORD(yourpwd)
STRSQL
CONNECT TO SYSB
CONNECT TO SYSC

At this point you have two connections made with userid 'youruid' and password 'yourpwd'.


Example 2:

Environment: Three systems (SYSA, SYSB, SYSC)

SYSA is the application requestor (AR)
SYSB and SYSC are the application servers (AS)

On SYSA:
ADDSVRAUTE USRPRF(YOURPRF) SERVER(QDDMDRDASERVER) USRID(youruid) PASSWORD(yourpwd)
ADDSVRAUTE USRPRF(YOURPRF) SERVER(SYSB) USRID(yourotheruid) PASSWORD(yourotherpwd)
ADDSVRAUTE USRPRF(YOURPRF) SERVER(SYSC) USRID(yourotheruid) PASSWORD(yourotherpwd)
STRSQL
CONNECT TO SYSB
CONNECT TO SYSC

At this point you have two connections made with userid 'yourotheruid' and password 'yourotherpwd'. This occurs because server authentication entries specifying the real system name take precedence over server authentication entries specifying QDDMDRDASERVER.

Example 3:

Environment: Three systems (SYSA, SYSB, SYSC)

SYSA is the application requestor (AR)
SYSB and SYSC are the application servers (AS)

On SYSA:
ADDSVRAUTE USRPRF(YOURPRF) SERVER(QDDMDRDASERVER) USRID(youruid) PASSWORD(yourpwd)
ADDSVRAUTE USRPRF(YOURPRF) SERVER(SYSB) USRID(yourotheruid) PASSWORD(yourotherpwd)
STRSQL
CONNECT TO SYSB user testuserid using 'testpassword'
CONNECT TO SYSC

At this point you have two connections. The connection to SYSB would be made with userid 'testuserid' and password 'testpassword'. This occurs because specifying userid and password on a CONNECT statement takes precedence over server authentication entries. The connection to SYSC would be made with userid 'youruid' and password 'yourpwd' since it will use the QDDMDRDASERVER authentication entry when no other server authentication entry exists specifying the system name.

Example 4:

Environment: Three systems (SYSA, SYSB, SYSC)

SYSA is the application requestor (AR)
SYSB and SYSC are the application servers (AS)

On SYSA:
ADDSVRAUTE USRPRF(YOURPRF) SERVER(QDDMDRDASERVER) USRID(youruid) PASSWORD(yourpwd)
ADDSVRAUTE USRPRF(YOURPRF) SERVER(QDDMSERVER) USRID(youruid2) PASSWORD(yourpwd2)
ADDSVRAUTE USRPRF(YOURPRF) SERVER(SYSC) USRID(yourotheruid) PASSWORD(yourotherpwd)
CRTDDMF FILE(QTEMP/DDMF) RMTFILE(FILE) RMTLOCNAME(SYSB *IP)
CRTDDMF FILE(QTEMP/DDMF2) RMTFILE(FILE) RMTLOCNAME(*RDB) RDB(SYSB)
CRTDDMF FILE(QTEMP/DDMF3) RMTFILE(FILE) RMTLOCNAME(*RDB) RDB(SYSC)

SBMRMTCMD CMD('DSPLIB YOURLIB') DDMFILE(QTEMP/DDMF)

The connection to SYSB would be made with userid 'youruid2' and password 'yourpwd2'. This occurs because non-RDB DDM files will use QDDMSERVER for userid and password at connection time. If QDDMSERVER didn't exist, QDDMDRDASERVER would be used.

SBMRMTCMD CMD('DSPLIB YOURLIB') DDMFILE(QTEMP/DDMF2)

The connection to SYSB would be made with userid 'youruid' and password 'yourpwd'. This occurs because RDB DDM files will use QDDMDRDASERVER for userid and password at connection time if a server authentication entry doesn't exist specifying the system name.

SBMRMTCMD CMD('DSPLIB YOURLIB') DDMFILE(QTEMP/DDMF3)
The connection to SYSC would be made with userid 'yourotheruid' and password 'yourotherpwd'. This occurs because RDB DDM files will not use QDDMDRDASERVER for userid and password at connection time if a server authentication entry exists specifying the system name.