Different connectivity scenarios call for using different levels of authentication. Therefore, an administrator can set the lowest security authentication method required by the application requester (AR) when connecting to an application server (AS) by setting the preferred authentication method field in each RDB directory entry.
The administrator might also allow the decision about authentication method to be negotiated with the server, by choosing to allow a lower security authentication method. In this case the preferred authentication method is still attempted, but if the AS cannot accept the preferred method, a lower method can be used, depending on the server security setting and other factors such as the availability of cryptographic support. For example, if two systems are in a physically unprotected environment, the administrator might choose to require Kerberos authentication without allowing lower security authentication methods.
On the application requester (client) side, you can use one of the two methods to send a password along with the user ID on DRDA® TCP/IP connect requests. If you do not use either of these methods, the CONNECT command can send only a user ID.
The first way to send a password is to use the USER/USING form of the SQL CONNECT statement, as in the following example from the Interactive SQL environment:
CONNECT TO rdbname USER userid USING 'password'
In a program using embedded SQL, the values of the user ID and of the password can be contained in host variables in the USER/USING database.
In a program using CLI, the following example shows how the user ID and password are presented in host variables to the DRDA application requester (AR):
SQLConnect(hdbc,sysname,SQL_NTS, /*do the connect to the application server */ uid,SQL_NTS,pwd,SQL_NTS);
The second way to provide a password is to send a connect request over TCP/IP using a server authorization entry. A server authorization 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, the DB2 Universal Database™ for iSeries™ client (AR) checks the server authorization 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 authorization 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 connect request.
A server authorization 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® UDB for iSeries checks the server authorization 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 authorization 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 connect request.
To store a password using the Add Server Authentication Entry (ADDSVRAUTE) command, you must set the QRETSVRSEC system value to '1'. By default, the value is '0'. Type the following command to change this value:
CHGSYSVAL QRETSVRSEC VALUE('1')
The following example shows the syntax of the Add Server Authentication Entry (ADDSVRAUTE) command when using an RDB directory entry:
ADDSVRAUTE USRPRF(user-profile) SERVER(rdbname) USRID(userid) PASSWORD(password)
The USRPRF parameter specifies the user profile under which the application requester job runs. What you put into the SERVER parameter is normally the name of the RDB to which you want to connect. The exception is that if you are using DDM files which were not created to use the RDB directory, you should specify QDDMSERVER in the SERVER parameter. When you specify an RDB name, it must be in uppercase. The USRID parameter specifies the user profile under which the server job will run. The PASSWORD parameter specifies the password for the user profile.
If you omit the USRPRF parameter, it will default to the user profile under which the Add Server Authentication Entry (ADDSVRAUTE) command runs. If you omit the USRID parameter, it will default to the value of the USRPRF parameter. If you omit the PASSWORD parameter, or if you have the QRETSVRSEC value set to 0, no password will be stored in the entry and when a connect attempt is made using the entry, the security mechanism attempted will be user ID only.
You can use the Display Server Authentication Entries (DSPSVRAUTE) command to determine what authentication entries have been added to the server authentication list. The Retrieve Server Authentication Entries (QsyRetrieveServerEntries) (QSYRTVSE) API in a user-written program can also be used.
You can remove a server authorization entry by using the Remove Server Authentication Entry (RMVSVRAUTE) command. You can change a server authorization entry by using the Change Server Authentication Entry (CHGSVRAUTE) command
If a server authorization entry exists for a relational database (RDB), and the USER/USING form of the CONNECT statement is also used, the latter takes precedence.
Distributed Relational Database Architecture™ (DRDA) and distributed data management (DDM) can take advantage of Kerberos authentication if both systems are configured for Kerberos.
If a job's user profile has a valid ticket-granting ticket (TGT), the DRDA application requester (AR) uses this TGT to generate a service ticket and authenticate the user to the remote server. Having a valid TGT makes the need for a server authentication entry unnecessary, because no password is directly needed in that case. However, if the job's user profile does not have a valid TGT, the user ID and password can be retrieved from the server authentication entry to generate the necessary TGT and service ticket.
When using Kerberos, the remote location (RMTLOCNAME) in the RDB directory entry must be entered as the remote host name. IP addresses will not work for Kerberos authentication.
In cases where the Kerberos realm name differs from the DNS suffix name, it must be mapped to the correct realm. To do that, there must be an entry in the Kerberos configuration file (krb5.conf) to map each remote host name to its correct realm name. This host name entered must exactly match the remote location name (RMTLOCNAME). The remote location parameter displayed by the DSPRDBDIRE or DSPDDMF command must match the domain name in the krb5.conf file. The following figure shows an example of the DSPRDBDIRE display:
Display Relational Database Detail
Relational database . . . . . . . : RCHASXXX
Remote location:
Remote location . . . . . . . . . : rchasxxx.rchland.ibm.com
Type . . . . . . . . . . . . . . : *IP
Port number or service name . . . : *DRDA
Remote authentication method . . :
Preferred method . . . . . . . . : *KERBEROS
Allow lower authentication . . . : *NOALWLOWER
Text . . . . . . . . . . . . . . :
Relational database type . . . . : *REMOTE
Press Enter to continue.
F3=Exit F12=Cancel
Here is a portion of the corresponding krb5.conf file contents showing the domain name matching the remote location name (Note: The Display File (DSPF) command is used to display the configuration file contents):
DSPF STMF('/QIBM/UserData/OS400/NetworkAuthentication/krb5.conf')
[domain_realm]
; Convert host names to realm names. Individual host names may be
; specified. Domain suffixes may be specified with a leading period
; and will apply to all host names ending in that suffix.
rchasxxx.rchland.ibm.com = REALM.RCHLAND.IBM.COM
Jobs using Kerberos must be restarted when configuration changes occur to the krb5.conf file.