Administration Guide

Selecting an Authentication Method for Your Server

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:

SERVER

Specifies that authentication occurs on the server using local operating system security. If a user ID and password are specified during the connection or attachment attempt, they are compared to the valid user ID and password combinations at the server to determine if the user is permitted to access the instance. This is the default security mechanism.

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.

CLIENT

Specifies that authentication occurs on the database partition where the application is invoked using operating system security. The user ID and password specified during a connection or attachment attempt are compared with the valid user ID and password combinations on the client node to determine if the user ID is permitted access to the instance. No further authentication will take place on the database server.

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. 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_clntauthparameter is only used to determine where to validate the information provided on the USER/USING clauses.

Table 21. 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

DCS

Primarily used to catalog a database accessed using DB2 Connect. (Refer to the DB2 Connect User's Guide section on Security for more details on this topic.) When it is used to specify the authentication type for an instance in the database manager configuration file, it means the same as for authentication SERVER, unless the server is being accessed via the Distributed Relational Database Architecture (DRDA) Application Server (AS) architecture using the Advanced Program-To-Program Communications (APPC) protocol. In this case, using DCS indicates that authentication will occur at the server, but only in the APPC layer. Further authentication will not occur in the DB2 code. This value is only supported when the APPC SECURITY parameter for the connection is specified as SAME or PROGRAM.

DCE

Specifies that the user is authenticated using DCE Security Services. For more information on DCE Security, see "Using DCE Security Services to Authenticate Users".

Notes:

1. 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.

2. 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:
   • AUTHENTICATION *
   • SYSADM_GROUP *
   • TRUST_ALLCLNTS
   • TRUST_CLNTAUTH
   • SYSCTRL_GROUP
   • SYSMAINT_GROUP

   * 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:

   • UNIX platforms: the instance owner
   • NT platform: someone belonging to the local "administrators" group
   • OS/2 platform: a UPM administrator
   • Other platforms: there is no local security on the other platforms, so all users pass local security checks anyway

3. See Appendix R. "How DB2 for Windows NT Works with Windows NT Security" for addtional information on Windows NT Security.

[ DB2 List of Books | Search the DB2 Books ]