DB2 Connect authentication considerations

As a DB2 Connect™ administrator, in cooperation with your host or System i™ database administrator, you can determine where user names and passwords are validated:

At the client
At the host or System i 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 default to SERVER_ENCRYPT. If this type is not accepted by the server, the client will attempt to retry 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.
SERVER: The user name and password are validated at the host or System i server database.
SERVER_ENCRYPT: As for SERVER authentication, the user name and password are validated at the host or System i database server, but the transferred passwords are encrypted at the client.
DATA_ENCRYPT: Provides the ability to encrypt user data during client/server communications.
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.

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.