Db2 Connect authentication considerations

As a Db2 Connect administrator, in cooperation with your System z or IBM Power Systems database administrator, you can determine where user names and passwords are validated.

For example:
  • At the client
  • At the System z or IBM Power Systems server
  • Single sign-on and validation through a third-party system (Kerberos).
Note: If the remote client has not specified an authentication type, the client will try to connect using the SERVER_ENCRYPT authentication type first. If this type is not accepted by the server, the client will attempt to try using an appropriate value returned from the server. To help optimize performance, always specify the authentication type at the client to avoid this extra network flow.

Starting with Db2 Connect Version 8.2.2 (equivalent to Version 8.1 FixPak 9) the gateway is no longer a passive participant during authentication negotiation. Instead, the gateway takes an active role. The authentication type specified in the database directory entry at the gateway overrides the authentication type cataloged at the client. The client, gateway, and server must all specify compatible types. If the cataloged authentication type at the gateway has not been specified in the database directory entry, SERVER authentication will be the default type requested of the server. However, negotiation will still take place between the client and server if the server does not support SERVER authentication. This behavior is in contrast to the client which defaults to SERVER_ENCRYPT if an authentication type has not been specified.

The authentication type cataloged at the gateway is not used if DB2NODE or the SQL_CONNECT_NODE option of the Set Client API has been set at the client. In these cases negotiation is still strictly between the client and the server.

The following authentication types are allowed with Db2 Connect:
CLIENT
The user name and password are validated at the client.
KERBEROS
Enables the client to log into the server using Kerberos authentication instead of the traditional ID and password combination. This authentication type requires that both the server and client be Kerberos-enabled.
SERVER
The user name and password are validated at the System z or IBM Power Systems server database.
SERVER_ENCRYPT
As for SERVER authentication, the user name and password are validated at the System z or IBM Power Systems database server, but the transferred user IDs and passwords are encrypted at the client.
SERVER_ENCRYPT_AES
The transferred user IDs and passwords are encrypted using an Advanced Encryption Standard (AES) encryption algorithm at the client and validated at the System z database server.

Kerberos authentication is unique in that the client does not pass a user ID and password directly to the server. Instead, Kerberos acts as a third-party authentication mechanism. The user enters an ID and password once at the client terminal, and Kerberos validates this sign-on. After this, Kerberos automatically and securely passes the user's authorization to any local and network services requested. This means that the user does not need to re-enter an ID and password to log into a remote Db2® server. The single sign-on capability provided by Kerberos authentication requires that both Db2 Connect and the database server that it is connecting to provide Kerberos support.

Note: There is no support for the GSSPLUGIN authentication type.