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. See "Authentication Type (authentication)" 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.
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 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. For more information on this parameter, see "Trust All Clients (trust_allclnts)".
| 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. See "Trusted Clients Authentication (trust_clntauth)" 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. |
Table 20. Trusted Client Options
| TRUST_ALLCLNTS | TRUST_CLNTAUTH | Trusted Client Authentication no password | Trusted Client Authentication with password | Untrusted Client Authentication password required |
|---|---|---|---|---|
| YES (default) | CLIENT (default) | CLIENT | CLIENT | N/A |
| YES (default) | SERVER | CLIENT | SERVER | N/A |
| NO | CLIENT (default) | CLIENT | CLIENT | SERVER |
| NO | SERVER | CLIENT | SERVER | SERVER |
| Note: | When DB2 Connect is part of the system environment, the authentication types have slightly different meanings. Also, here we are presenting the authentication type that is stored in the database manager configuration file for the DB2 Universal Database. In DB2 Connect, the authentication types used are those stored in the database directory. Refer to the section on Security in the DB2 Connect User's Guide for more details on this topic. |
| Note: | The type of authentication you choose is only important if you have remote database clients accessing the database. Most users accessing the database through local clients are always authenticated on the same machine as the database. An exception may exist when DCE Security Services are used. For information about supporting and using remote clients, see your Quick Beginnings manual. |
| Note: | Do not inadvertently lock yourself out of your instance when you are changing
the authentication information, since access to the configuration file itself
is protected by information in the configuration file. The following database
manager configuration file parameters control access to the instance:
* 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 failsafe 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 failsafe user remotely or for any other DB2 command. This special user is identified as follows:
|