Access to an instance or a database first requires that the user be authenticated. The authentication type for each instance determines how and where a user will be verified. The authentication type is stored in the database manager configuration file at the server. It is initially set when the instance is created. Refer to "Configuring DB2" in Administration Guide, Performance for more information on this database manager configuration parameter. There is one authentication type per instance, which covers access to that database server and all the databases under its control.
If you intend to access data sources from a federated database, you must consider data source authentication processing and definitions for federated authentication types. See Federated Database Authentication Processing for more information.
The following authentication types are provided:
| Note: | The server code detects whether a connection is local or remote. For local connections, when authentication is SERVER, a user ID and password are not required for authentication to be successful. |
If the remote instance has SERVER authentication, the user ID and password must be provided by the user or retrieved by DB2 and provided to the server for validation even though the user has already logged on to the local machine or to the domain.
If the client authentication is DCS or SERVER, the client is authenticated by passing the user ID and password to the server. If the client authentication is DCS_ENCRYPT or SERVER_ENCRYPT, the client is authenticated by passing a user ID and encrypted password.
If SERVER_ENCRYPT is specified at the client and SERVER is specified at the server, an error is returned because of the mismatch in the authentication levels.
If the user performs a local or client login, the user is known only to that local client workstation.
If the remote instance has CLIENT authentication, two other parameters determine the final authentication type: trust_allclnts and trust_clntauth.
CLIENT level security for TRUSTED clients only:
Trusted clients are clients that have a reliable, local security system. Specifically, all clients are trusted clients except for Macintosh, Windows 3.1, and Windows 95 operating systems.
When the authentication type of CLIENT has been selected, an additional option may be selected to protect against clients whose operating environment has no inherent security.
To protect against unsecured clients, the administrator can select Trusted Client Authentication by setting the trust_allclnts parameter to NO. This implies that all trusted platforms can authenticate the user on behalf of the server. Untrusted clients are authenticated on the Server and must provide a user ID and password. You use the trust_allclnts configuration parameter to indicate whether you are trusting clients. The default for this parameter is YES.
| Note: | It is possible to trust all clients (trust_allclnts is YES) yet have some of those clients as those who do not have a native safe security system for authentication. |
You may also want to complete authentication at the server even for trusted clients. To indicate where to validate trusted clients, you use the trust_clntauth configuration parameter. The default for this parameter is CLIENT. Refer to "Configuring DB2" in Administration Guide, Performance for more information on this parameter.
| Note: | For trusted clients only, if no user ID or password is explicitly provided when attempting to CONNECT or ATTACH, then validation of the user takes place at the client. The trust_clntauth parameter is only used to determine where to validate the information provided on the USER/USING clauses. |
To protect against all clients except DRDA clients from DB2 for MVS and OS/390, DB2 for VM and VSE, and DB2 for OS/400, set the trust_allclnts parameter to DRDAONLY. Only these clients can be trusted to perform client-side authentication. All other clients must provide a user ID and password to be authenticated by the server.
The trust_clntauth parameter is used to determine where the above clients are authenticated: if trust_clntauth is "client", authentication takes place at the client. If trust_clntauth is "server", authentication takes place at the client when no password is provided and at the server when a password is provided.
Table 22. Authentication Modes using TRUST_ALLCLNTS and TRUST_CLNTAUTH Parameter Combinations.
| TRUST_ ALLCLNTS | TRUST_ CLNTAUTH | Untrusted non- DRDA Client Authen- tication no password | Untrusted non- DRDA Client Authen- tication with password | Trusted non- DRDA Client Authen- tication no password | Trusted non- DRDA Client Authen- tication with password | DRDA Client Authen- tication no password | DRDA Client Authen- tication with password |
|---|---|---|---|---|---|---|---|
| YES | CLIENT | CLIENT | CLIENT | CLIENT | CLIENT | CLIENT | CLIENT |
| YES | SERVER | CLIENT | SERVER | CLIENT | SERVER | CLIENT | SERVER |
| NO | CLIENT | SERVER | SERVER | CLIENT | CLIENT | CLIENT | CLIENT |
| NO | SERVER | SERVER | SERVER | CLIENT | SERVER | CLIENT | SERVER |
| DRDAONLY | CLIENT | SERVER | SERVER | SERVER | SERVER | CLIENT | CLIENT |
| DRDAONLY | SERVER | SERVER | SERVER | SERVER | SERVER | CLIENT | SERVER |
If the client authentication is DCS or SERVER, the client is authenticated by passing the user ID and password to DB2 Connect. If the client authentication is DCS_ENCRYPT or SERVER_ENCRYPT, the client is authenticated by passing a user ID and encrypted password.
If DCS_ENCRYPT is specified at the client and DCS is specified at the server, an error is returned because of the mismatch in the authentication levels.
If the client authentication is SERVER or DCS, the client is authenticated by passing the user ID and password to the server. If the client authentication is SERVER_ENCRYPT or DCS_ENCRYPT, the client is authenticated by passing a user ID and encrypted password. The authentication type of the client cannot be specified as DCE_SERVER_ENCRYPT. If the authentication type of an instance is specified as DCE_SERVER_ENCRYPT, all local applications will use DCE as the authentication scheme. This also applies for any utility commands that do not require a database connection or an instance attachment.
In addition to allowing a mix of DCE and SERVER_ENCRYPT authentication types, the DCE_SERVER_ENCRYPT authentication type also alleviates one of the limitations when using groups within DCE. When the authentication type is set to DCE_SERVER_ENCRYPT, the assumption is that the group list being requested other than at authentication time, come from the base operating system and not from DCE. You, as the administrator, can then set up a user on the server to match the short DCE name in order to provide group list support outside that which is supported at authentication time.
Notes:
* Indicates the two most important parameters, and those most likely to cause a problem.
There are some things that can be done to ensure this does not happen: If you do accidentally lock yourself out of the DB2 system, you have a fail-safe option available on all platforms that will allow you to override the usual DB2 security checks to update the database manager configuration file using a highly privileged local operating system security user. This user always has the privilege to update the database manager configuration file and thereby correct the problem. However, this security bypass is restricted to a local update of the database manager configuration file. You cannot use a fail-safe user remotely or for any other DB2 command. This special user is identified as follows: