Authentication Methods

Access to an instance or a database first requires that the user be authenticated. The authentication type for each instance:

Is set when the instance is created.
Determines how and where a user will be authenticated.
Is stored in the database manager configuration file at the server.
Is set as one authentication type per instance, which covers access to all the databases under its control.

NOTE

If you intend to access data sources from a federated database, you must consider data source authentication processing and definitions for federated authentication types.

The following authentication types are provided.

SERVER

This is the default security mechanism.
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 with the valid user ID and password combinations at the server to determine whether the user is permitted to access the instance.
If a user ID and password are not specified and the client OS is a trusted OS, then the user ID and password that you used to log on to the client is sent to the server for authentication.

SERVER_ENCRYPT

Specifies that the server accepts encrypted SERVER authentication schemes.
If the client authentication is SERVER_ENCRYPT, the client is authenticated by passing an unencrypted user ID and an encrypted password to the server.
If the client authentication is SERVER, the client is authenticated by passing an unencrypted user ID and an unencrypted password to the server.

CLIENT

Specifies that authentication occurs on the server/client 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 whether 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.

TRUST_ALLCLNTS

Trusted clients are clients that have a reliable, local security system. Specifically, all clients are trusted clients except for the Windows 95, 98, and ME operating systems.
To protect against unsecured clients accessing the databases, you can select Trusted Client Authentication by setting the TRUST_ALLCLNTS parameter to NO. This implies that only trusted platforms can authenticate the user on behalf of the server. The default for this parameter is YES.
In this case, the untrusted clients are authenticated on the server and must provide a valid user ID and password.
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.
To protect against all clients except DRDA clients from DB2 for OS/390 and z/OS, DB2 for VM and VSE, and DB2 for iSeries, 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.

TRUST_CLNTAUTH

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.

Let's look at Table 4.3: If you set TRUST_ALLCLNTS=YES and TRUST_CLNTAUTH=SERVER, then authentication for Trusted non-DRDA Client Authentication with password is at SERVER and Trusted non-DRDA Client Authentication no password is at CLIENT.

Table 4.3. Authentication Types
Parameter	Authentication Type
TRUST_ALLCLNTS	YES	YES	NO	NO	DRDAONLY	DRDAONLY
TRUST_CLNTAUTH	CLIENT	SERVER	CLIENT	SERVER	CLIENT	SERVER
Untrusted non-DRDA Client Authentication no password	CLIENT	CLIENT	SERVER	SERVER	SERVER	SERVER
Untrusted non-DRDA Client Authentication with password	CLIENT	SERVER	SERVER	SERVER	SERVER	SERVER
Trusted non-DRDA Client Authentication no password	CLIENT	CLIENT	CLIENT	CLIENT	SERVER	SERVER
Trusted non-DRDA Client Authentication with password	CLIENT	SERVER	CLIENT	SERVER	SERVER	SERVER
DRDA Client Authentication no password	CLIENT	CLIENT	CLIENT	CLIENT	CLIENT	CLIENT
DRDA Client Authentication with password	CLIENT	SERVER	CLIENT	SERVER	CLIENT	SERVER

KERBEROS Authentication

When dealing with authentication and Kerberos, three entities are involved:

the client, who is requesting service from
a server, the second entity, and
the Key Distribution Center (KDC) or Kerberos server, which is a machine that manages the database where all the authentication data is kept and maintained
- Kerberos is used when both the DB2 client and server are on operating systems that support the Kerberos security protocol. Kerberos security protocol enables the use of a single sign-on to a remote DB2 server.
- Kerberos is a third-party authentication service that uses conventional cryptography to create a shared secret key. It is a 56-bit encrypted key using the Data Encryption Standard (DES) algorithm. This key becomes a user's credential and is used to verify the identity of users during all occasions when local or network services and DB2 services are requested. The key eliminates the need to pass the user name and password across the network as clear text. This key is stored in the Kerberos server database.
- When a client needs the services of a server, the client must prove its identity to the server so that the server knows to whom it is talking.
- Tickets are the means the Kerberos server gives to clients to authenticate themselves to the service providers and to get work done on their behalf on the service's servers. Tickets have a finite life, known as the ticket life span.

The Kerberos authentication types are supported only on clients and servers running Windows 2000, Windows XP, and Windows .NET operating systems. In addition, both the client and server machines must either belong to the same Windows domain or belong to trusted domains.

In Kerberos terms, making a Kerberos authenticated service provider work on the behalf of a client is a three-step process:

Get a ticket-granting ticket (TGT).
Get a service ticket (ST).
Get the work done on the service provider.

The main role of the ticket-granting ticket service is to avoid unnecessary password traffic over the network, so the user should issue his or her password only once per session. What this ticket-granting ticket service does is to give the client systems a ticket that has a certain time span, whose purpose is to allow the clients to get service tickets (STs) to be used with other servers without the need to give them the password every time they request services.

Every service that uses Kerberos is registered with the Kerberos service. To use a kerberized service, you must request a ticket for that service from Kerberos. To request tickets, you must have a special ticket called a ticket-granting ticket (TGT). You get a Kerberos TGT by running the kinit program. Once you have a TGT, you don't have to enter your password anymore when you want to get other Kerberos tickets.

Once a user has a TGT, if the user requests a kerberized service, he or she has to get an ST for it. To get one, the kerberized command sends an encrypted message containing the requested service name, the machine's name, and a timestamp to the Kerberos server. The Kerberos server decrypts the message, checks whether everything is in order, and if so, sends back an ST encrypted with the service's private key, so that only the requested service can decrypt it. The client sends a request, along with the just-received ticket, to the service provider, who in turn decrypts and checks authorization, and, if it is in order, provides the requested service to the client.

An example of how Kerberos authentication works in a Windows environment:

A user logging on to the client machine using a domain account authenticates to the Kerberos KDC at the Windows domain controller. The KDC issues a TGT to the client.
During the first phase of the connection, the server sends the target principal name, which is the service account name for the DB2 server service, to the client. Using the server's target principal name and the TGT, the client requests an ST from the ticket-granting service that also resides at the domain controller. If both the client's TGT and the server's target principal name are valid, the ticket-granting service issues a ST to the client.
The client sends this ST to the server via the communication channel.
The server validates the client's ST. If the client's ST is valid, the authentication is completed.

NOTE

It is possible to catalog the databases on the client machine and explicitly specify the Kerberos authentication type with the server's target principal name. In this way, the first phase of the connection can be bypassed. If a user ID and a password are specified, the client will request the TGT for that user account and use it for authentication.

KRB_SERVER_ENCRYPT

One of the values of KERBEROS authentication is that the userid and password verification can be performed at a Kerberos server using the Kerberos security protocol for authentication. With an authentication type of KRB_SERVER_ENCRYPT at the server and clients that support the Kerberos security system, the effective system authentication type is KERBEROS. If the clients do not support the Kerberos security system, the effective system authentication type is equivalent to SERVER_ENCRYPT.

NOTE

The type of authentication you choose is most important when you have remote database clients accessing the database or when you are using federated database functionality. Most users accessing the database through local clients (i.e., running on the same server as the DB2 instance) are always authenticated on the same machine as the database.
Do not inadvertently lock yourself out of your instance when you are changing the authentication information, because access to the configuration file itself is protected by information in the configuration file. The following database manager configuration parameters control access to the instance:
- SYSADM_GROUP
- SYSCTRL_GROUP
- SYSMAINT_GROUP
- AUTHENTICATION
- TRUST_ALLCLNTS
- TRUST_CLNTAUTH

Authentication Considerations for Remote Clients

When cataloging a database for remote access, the authentication type may be specified in the database directory entry.

SERVER authentication is assumed if a value is not specified for database accessed using DB2 Connect.
The authentication type is not required. If it is not specified, the client will default to SERVER_ENCRYPT. If the server does not support SERVER_ENCRYPT, the client attempts to retry using a value supported by the server. If the server supports multiple authentication types, the client will not choose among them but will instead return an error. This is done to ensure that the correct authentication type is used. In this case, the client must catalog the database using a supported authentication type.
If an authentication type is specified, authentication can begin immediately, provided that the value specified matches that at the server. If a mismatch is detected, DB2 attempts to recover. Recovery may result in more flows to reconcile the difference or in an error if DB2 cannot recover. In the case of a mismatch, the value at the server is assumed to be correct.

Partitioned Database Authentication Considerations

In a partitioned database, each partition of the database must have the same set of users and groups defined. If the definitions are not the same, the user may be authorized to do different things on different partitions. Consistency across all partitions is highly recommended.