Understanding DB2: Learning Visually with Examples (2nd Edition)

10.2. Authentication

Authentication is the process of validating a supplied user ID and password against a security facility. This authentication occurs when you try to connect to a database or attach to an instance. The security facility is external to DB2; user IDs and passwords are not stored in a DB2 server. Authentication can occur at any of the following:

  • At a DB2 server ( Figure 10.1, Instance 1)

  • At a DB2 client (Figure 10.1, Instance 2)

  • Using a customized loadable library via Generic Security Service (GSS) (Figure 10.1, Instance 3)

  • At a Kerberos security service (Figure 10.1, Instance 4)

The authentication process also determines which operating system groups the user belongs to. Group membership lookup is essential because it lets users inherit certain authorities or privileges through groups.

The following sections describe how to configure the authentication type by using configuration parameters at the DB2 server and at the client respectively. The combination of the client and server authentication configuration determines where and how the authentication will take place (the authentication method).

10.2.1. Configuring the Authentication Type at a DB2 Server

To configure the authentication type at a DB2 server, you use the Database Manager (DBM) Configuration parameter AUTHENTICATION. If you are not already familiar with DBM Configuration parameters, refer to Chapter 5, Understanding the DB2 Environment, DB2 Instances, and Databases. For completeness, we are including the command here to display the current DBM parameter settings:

get dbm cfg

From the output, locate the following line where the authentication type is specified:

Database manager authentication (AUTHENTICATION) = SERVER

SERVER is the default authentication type of an instance. Figure 10.2 shows this authentication type.

Figure 10.2. Configuring the authentication type at a DB2 server

To change the value to the KERBEROS authentication type, for example, use this DB2 command:

update dbm cfg using authentication KERBEROS

Alternatively, you can use the Control Center to make this change. Chapter 4, Using the DB2 Tools, describes the Control Center in detail.

Table 10.1 summarizes the values the AUTHENTICATION parameter accepts.

Table 10.1. Description of the Authentication Types

Authentication Type

Description

SERVER

Authenticates users at the DB2 server. This is the default value.

SERVER_ENCRYPT

Authenticates users at the DB2 server. When the user ID and password are sent to the server, they are both encrypted.

KERBEROS

Authenticates users at a Kerberos server.

KRB_SERVER_ENCRYPT

Authenticates users at a Kerberos server if both the DB2 server and client support Kerberos security service.

Use SERVER_ENCRYPT instead if the client does not support Kerberos security service.

GSSPLUGIN

Authenticates users using an external GSS Application Programming Interface (GSSAPI)-based security mechanism.

GSS_SERVER_ENCRYPT

Authenticates users using an external GSSAPI-based security mechanism if both the DB2 server and client support GSS.

Use SERVER_ENCRYPT instead if the client does not support GSS.

CLIENT

Authenticates users at the DB2 client depending on the settings of two other configuration parameters: TRUST_CLNTAUTH and TRUST_ALLCLNTS.

The output of the get dbm cfg command includes another authentication-related parameter, called server connection authentication (SRVCON_AUTH):

Server Connection Authentication (SRVCON_AUTH) = NOT_SPECIFIED

This parameter sets the authentication type at the DB2 server for incoming database connections. Note that only database connections evaluate the value of this parameter. Explicit instance attachment and operations that require implicit instance attachment still use AUTHENTICATION to resolve the authentication type.

These examples show how to implicitly attach to an instance:

update dbm cfg create database SAMPLE

By default, SRVCON_AUTH has a value of NOT_SPECIFIED. In this case, the value of AUTHENTICATION is used instead.

10.2.2. Configuring the Authentication Type at a DB2 Client

When a client is configured to connect to a database, you need to catalog the node and the database. The catalog database command has an option called AUTHENTICATION that allows you to indicate the authentication type to be used when connecting to the specified database from a DB2 client as shown in Figure 10.3.

Figure 10.3. Configuring the authentication type at a DB2 client

Figure 10.4 illustrates the syntax of the catalog database command.

Figure 10.4. Syntax of the CATALOG DATABASE command

>>-CATALOG--+-DATABASE-+--database-name--+-----------+----------> '-DB-------' '-AS--alias-' >--+-------------------+----------------------------------------> +-ON--+-path--+-----+ | '-drive-' | '-AT NODE--nodename-' >--+--------------------------------------------------------------+--> '-AUTHENTICATION--+-SERVER-----------------------------------+-' +-CLIENT-----------------------------------+ +-SERVER_ENCRYPT---------------------------+ +-KERBEROS TARGET PRINCIPAL--principalname-+ +-SQL_AUTHENTICATION_DATAENC---------------+ +-SQL_AUTHENTICATION_DATAENC_CMP-----------+ '-GSSPLUGIN--------------------------------' >--+------------------------+---------------------------------->< '-WITH--"comment-string"-'

The authentication type SERVER is the default. To change this setting, explicitly specify the AUTHENTICATION keyword along with one of the supported values shown in Table 10.2. The following is an example of using GSSPLUGIN authentication.

catalog db sample at node dbsrv authentication gssplugin

Table 10.2. Authentication Types Supported at DB2 Clients

Supported Authentication Values

Description

SERVER

Authenticates users at the DB2 server where the database resides. This is the default value.

SERVER_ENCRYPT

Authenticates users at the DB2 server where the database resides. When the user ID and password are sent to the server, they are both encrypted.

KERBEROS

Authenticates users at a Kerberos server.

 

TARGET PRINCIPAL principalname

Fully qualify the Kerberos principal name for the target server.

For UNIX and Linux systems, use a name like:

  • name/instance@REALM

For Windows 2000, principalname is the logon account of the DB2 server service, which may look like one of the following:

  • userid@DOMAIN

  • userid@xxx.xxx.xxx.com

  • domain\userid

SQL_AUTHENTICATION_DATAENC

Authenticates users at the DB2 server. In addition, data encryption must be used for the connections.

SQL_AUTHENTICATION_DATAENC_CMP

Authenticates users at the DB2 server. In addition, data encryption must be used. If the client or server does not support data encryption, use SERVER_ENCRYPT instead.

GSSPLUGIN

Authenticates users with an external GSSAPI-based security mechanism.

CLIENT

Authenticates users at the DB2 client depending on the settings of two other configuration parameters: TRUST_CLNTAUTH and TRUST_ALLCLNTS

10.2.3. Authenticating Users at the DB2 Server

As mentioned earlier, authenticating a user and the associated password at the DB2 server is the default behavior. The DBM configuration parameter at the server and the authentication option in the database directory entry are both set to SERVER. DB2 does not maintain any user and password information. This implies that the user ID and password pair must be defined in the security facility built in the operating system of the server. Figure 10.5 demonstrates a few scenarios of server authentication.

Figure 10.5. Example of SERVER authentication

NOTE

As long as the database server authentication type is set to SERVER, authentication will always take place at the server.

In Scenario A, A1 issues a CONNECT statement to connect to the SAMPLE database that is remotely located in the dbsrv DB2 server. The user ID bob and the password bobpass are also provided. This pair of information is validated by the DB2 server security facility at A2. Once validated, bob is connected to SAMPLE in A3 provided that he has the appropriate CONNECT privilege (privileges are discussed later in this chapter).

Scenario B uses the same environment except that no user ID and password are provided in the CONNECT statement. When a remote database connection is requested, it is mandatory to supply a user ID and password. Therefore, the CONNECT statement specified in B1 fails.

Scenarios A and B are both remote requests. It is also very common to make local database connections from the DB2 server itself. Scenario C demonstrates such a request. Since you must have already logged into the server console with a valid user ID and password, it is not necessary to supply a user ID and password in the CONNECT statement at C1. If you choose to connect to the database with a different user ID, then you need to issue the CONNECT statement with the user ID and password you wish as shown in A1.

The SERVER_ENCRYPT authentication type behaves exactly the same as SERVER authentication except that both the user ID and password are encrypted.

10.2.4. Authenticating Users with the Kerberos Security Service

Kerberos is a network authentication protocol that employs secret-key cryptography to provide strong authentication for client/server applications. By using an encrypted key, Kerberos makes single sign-on to a remote DB2 server possible. Refer to Figure 10.6 to see how Kerberos authentication works with DB2.

Figure 10.6. Example of Kerberos authentication

In Figure 10.6:

  1. A user logs in to the Kerberos system.

  2. The Kerberos key distribution center generates a ticket and target principal name.

  3. The DB2 client requests a service ticket for a DB2 server.

  4. The Kerberos Key Distribution Center (KDC) grants a service ticket for the DB2 server.

  5. The DB2 client connects to the DB2 server using the service ticket.

  6. The DB2 server validates the service ticket and accepts the DB2 client connection request.

NOTE

Prior to DB2 Version 8.2, Kerberos only supported Windows 2000 platforms. With Version 8.2, Kerberos extended support to the Linux and UNIX platforms too.

The AUTHENTICATION type KERBEROS allows Kerberos-enabled clients to be authenticated at the Kerberos server. Although Kerberos is gaining popularity, there will be clients that do not have Kerberos support enabled. To accommodate these clients and at the same time ensure all clients are able to connect securely, you can set the authentication type at the DB2 server as KRB_SERVER_ENCRYPT. This option allows all Kerberos-enabled clients to be authenticated with Kerberos security service, while other clients use SERVER_ENCRYPT authentication instead.

Table 10.3 summarizes the resolved authentication types based on different client and server authentication settings related to Kerberos.

Table 10.3. Summary of Kerberos-Related Client/Server Authentication Types

Client Specification

Server Specification

Client/Server Resolution

KERBEROS

KRB_SERVER_ENCRYPT

KERBEROS

Any other setting

KRB_SERVER_ENCRYPT

SERVER_ENCRYPT

10.2.5. Authenticating Users with Generic Security Service Plug-ins

With DB2 Version 8.2, you can write authentication mechanisms to implement your own security model. These authentication modules follow the Generic Security Service Application Programming Interface (GSSAPI) standard as documented in the Internet's Requests for Comments (RFC) (see www.rfc-editor.org/rfc.html).

To employ the authentication plug-in, set the AUTHENTICATION type to GSSPLUGIN or GSS_SERVER_ENCRYPT so that the specified library modules are loaded at instance start time. DB2 clients then load an appropriate plug-in based on the security mechanism negotiated with the server during CONNECT or attach. You use the LOCAL_GSSPLUGIN Database Manager Configuration parameter to specify the name of the plug-in and must include the library name when using GSSPLUGIN or GSS_SERVER_ENCRYPT. Figure 10.7 illustrates an example of GSS.

Figure 10.7. Example of GSS authentication

When clients do not support the GSSPLUGIN security mechanism, you can use the GSS_SERVER_ENCRYPT authentication type, which allows those clients to establish database connections with behavior equivalent to SERVER_ENCRYPT.

The DB2 Version 8.2 authentication scheme requires plug-ins to manage the following:

  • Group membership

  • Authentication at the client

  • Authentication at the server

If you do not specify the loadable libraries, DB2-supplied plug-ins are used instead. A few Database Manager Configuration parameters are introduced to support authentication plug-ins, and they are listed in Table 10.4. Table 10.4 lists the new Database Manager Configuration parameters that support authentication plug-ins.

Table 10.4. Database Manager Parameters for Authentication Plug-ins

Database Manager Parameter

Description

GROUP_PLUGIN

The name of the group management plug-in library.

CLNT_PW_PLUGIN

The name of the client-side password authentication plug-in. The functions in the named plug-in will also be used for local instance-level actions if the AUTHENTICATION parameter is set to SERVER, CLIENT, SERVER_ENCRYPT, DATAENC, or DATAENC_COMP.

CLNT_KRB_PLUGIN

The name of the client-side Kerberos plug-in. This plug-in will also be used for local instance-level actions, that is, when the AUTHENTICATION parameter is set to KERBEROS or KRB_SERVER_ENCRYPT.

SRVCON_PW_PLUGIN

The name of the server-side password authentication module.

SRVCON_GSSPLUGIN_LIST

The list of names of all GSSAPI plug-ins separated by commas. The number of plug-ins supported by the server is unlimited; however, the maximum length of the list of plug-in names is 256 characters, and each plug-in name must be fewer than 32 characters.

This list should be stated with the most preferred plug-in first.

SRV_PLUGIN_MODE

Indicates if the plug-in is to be run in fenced or unfenced mode. (Fenced means that the plug-ins run in a different address space from the DB2 system controller process and unfenced means executing the plug-ins in the same address space.) It is recommended to run user-defined modules in fenced mode to protect the system controller.

Since this is an instance-level parameter, it applies to all plug-ins within the same instance.

The default value is FENCED.

DB2 provides sample plug-ins so you can develop your own plug-ins more easily. You must place the library files in the designated directory where DB2 looks for:

  • Client-side user authentication plug-ins in the directory

    $DFTDBPATH/security/client-plugins (for Linux/UNIX)

    $DFTDBPATH\security\client-plugins (for Windows)

  • Server-side user authentication plug-ins in the directory

    $DFTDBPATH/security/server-plugins (for Linux/UNIX)

    $DFTDBPATH\security\server-plugins (for Windows)

  • Group plug-ins in the directory

    $DFTDBPATH/security/group-plugins (for Linux/UNIX)

    $DFTDBPATH\security\group-plugins (for Windows)

You specify the name of the plug-in as a Database Manager Configuration parameter. Use the full name of the library file, but do not include the file extension or the path. For example, to configure the group plug-in, issue:

update dbm cfg using group_plugin mygrplib

10.2.6. Authenticating Users at the DB2 Clients

When you want to allow DB2 clients to perform their own authentication, set the server authentication type to CLIENT. This setting does not mean that client authentication applies to every client; qualified clients are determined by two other DBM Configuration parametersTRUST_ALLCLNTS and TRUST_CLNTAUTH.

TRUST_ALLCLNTS (as you can tell from the name) specifies whether DB2 is going to trust all clients. DB2 categorizes clients into these types:

  • Untrusted clients do not have a reliable security facility, such as Windows 98, Windows ME, and Classic Mac OS.

  • Trusted clients have reliable security facilities like Windows 2000, AIX, z/OS, and Linux.

  • Distributed Relational Database Architecture (DRDA) clients are on host legacy systems with reliable security facilities, including DB2 for z/OS, DB2 for iSeries, and DB2 for VM and VSE.

NOTE

Even though all DB2 Version 8 clients use the DRDA database communication protocol to communicate with DB2 servers, only clients running on mainframe legacy systems are considered as DRDA clients for historical and backward compatibility reasons.

TRUST_ALLCLNTS accepts any of the values summarized in Table 10.5.

Table 10.5. Values Allowed for TRUST_ALLCLNTS

TRUST_ALLCLNTS value

Description

YES

Trusts all clients. This is the default setting. Authentication will take place at the client. See the exception mentioned in the TRUST_CLNTAUTH discussion.

NO

Trust only clients with reliable security facilities (i.e., trusted clients). Untrusted clients must provide user ID and password for authentication to take place at the server.

DRDAONLY

Trusts only clients that are running on iSeries, zSeries, VM, and VSE platforms. All other clients must provide user IDs and passwords.

You can specify a more granular security scheme with TRUST_ALLCLNTS. For example, you can let trusted clients perform authentication on their own and, at the same time, force untrusted clients to be authenticated at the server.

Consider a scenario in which you log into a Windows 2000 machine as localuser and connect to the remote database without specifying a user ID and password. localuser will be the connected authorization ID at the database. What if you want to connect to the database with a different user ID, for example, poweruser, who has the authority to perform a database backup? To allow such behavior, use TRUST_CLNTAUTH to specify where authentication will take place if a user ID and password are supplied in a CONNECT statement or attach command. Table 10.6 presents the values for TRUST_CLNTAUTH.

Table 10.6. Values Allowed for TRUST_CLNTAUTH

TRUST_CLNTAUTH Value

Description

CLIENT

Authentication is performed at the client; user ID and password are not required.

SERVER

Authentication is done at the server only if the user ID and password are supplied.

DB2 evaluates TRUST_ALLCLNTS and TRUST_CLNTAUTH only if you set AUTHENTICATION to CLIENT on the DB2 server. Figures 10.8, 10.9, 10.10, and 10.11 illustrate how to use these parameters.

Figure 10.8. Example 1: TRUST_ALLCLNTS and TRUST_CLNTAUTH

Figure 10.9. Example 2: TRUST_ALLCLNTS and TRUST_CLNTAUTH

Figure 10.10. Example 3: TRUST_ALLCLNTS and TRUST_CLNTAUTH

Figure 10.11. Example 4: TRUST_ALLCLNTS and TRUST_CLNTAUTH

In Figure 10.8, TRUST_ALLCLNTS is set to YES, so all clients are considered trusted and can perform their own authentication.

In Figure 10.9, TRUST_ALLCLNTS is set to NO, so only trusted clients perform their own authentication. Authentication for untrusted clients is done at the server.

In Figure 10.10, TRUST_CLNAUTH is set to SERVER. When user ID and password are specified in the CONNECT statement, authentication is performed at the server.

In Figure 10.11, TRUST_CLNTAUTH is set to SERVER and both clients provide user ID and password in the CONNECT statement. Hence, authentication is performed at the server for both clients.

Related

Категории