DRDA over native TCP/IP does not use OS/400 communications security services and concepts such as communications devices, modes, secure location attributes, and conversation security levels which are associated with APPC communications. Therefore, security setup for TCP/IP is quite different.
Two types of security mechanisms are supported by the current DB2/400 implementation of DRDA over TCP/IP:
For a DB2 Universal Database for AS/400 application server (AS), the default security is user ID with password. That means that, as the system is installed, inbound TCP/IP connect requests must have a password accompanying the user ID under which the server job is to run. The CHGDDMTCPA command can be used to specify that the password is not required. To make this change, enter CHGDDMTCPA PWDRQD(*NO). You must have *IOSYSCFG special authority to use this command.
For a DB2 Universal Database for AS/400 application requester (AR, or client), there are two methods that can be used to send a password along with the user ID on TCP/IP connect requests. In the absence of both of these, only a user ID will be sent.
The first way to send a password is to use the USER/USING form of the SQL CONNECT statement. The syntax is:
CONNECT TO rdbname USER userid USING 'password'
where the lowercase words represent the appropriate connect parameters. In a program using embedded SQL, the userid and password values can be contained in host variables.
The other way that a password can be provided to send on a connect request over TCP/IP is by use of a server authorization entry. Associated with every user profile on the system is a server authorization list. By default the list is empty, but with the ADDSVRAUTE command, entries can be added. When a DRDA connection over TCP/IP is attempted, DB2 Universal Database for AS/400 checks the server authorization list for the user profile under which the client job is running. If a match is found between the RDB name on the CONNECT statement and the SERVER name in an authorization entry, the associated USRID parameter in the entry is used for the connection user ID, and if a PASSWORD parameter is stored in the entry, that password is also sent on the connect request.
In order for a password to be stored using the ADDSVRAUTE command, the QRETSVRSEC system value must to set to '1'. By default, the value is '0'. To make the chnage, enter:
CHGSYSVAL QRETSVRSEC VALUE('1')
The syntax of the ADDSVRAUTE command is:
ADDSVRAUTE USRPRF(user-profile) SERVER(rdbname) USRID(userid) PASSWORD(password)
The USRPRF parameter specifies the user profile under which the application requester job runs. The SERVER parameter specifies the remote RDB name, and the USRID parameter specifies the user profile under which the server job will run. The PASSWORD parameter specifies the password for the user profile at the server.
| Note: | It is very important that the RDB name in the SERVER parameter be specified in upper case. |
If the USRPRF parameter is omitted, it will default to the user profile under which the ADDSVRAUTE command is being run. If the USRID parameter is omitted, it will default to the value of the USRPRF parameter. If the PASSWORD parameter is omitted, or if the QRETSVRSEC value is 0, no password will be stored in the entry and when a connect attempt is made using the entry, the security mechanism used will be user ID only.
A server authorization entry can be removed by use of the RMVSVRAUTE command, and can be changed by use of CHGSVRAUTE. See the "AS/400 Command Reference" for complete descriptions of these commands.
If a server authorization entry exists for an RDB, and the USER/USING form of the CONNECT statement is also used, the latter takes precedence.