DB2 Version 10.1 for Linux, UNIX, and Windows

Naming and mapping for Kerberos

Before you can use Kerberos with a DB2® database system, you must ensure that the client and server computers and principals belong to the same realm or to trusted realms.

Client principals

Any unique identity that can receive Kerberos tickets for authentication is known as a principal. A Kerberos principal identity is defined by either a two-part or multipart format, either name@REALM or name/instance@REALM. Because the name component is used in the authorization ID (AUTHID) mapping, the name must adhere to the DB2 database naming rules. Those rules limit a name to 128 characters and restrict the choice of characters.

Note: Windows operating systems directly associate a Kerberos principal identity with a domain user. An implication is that Kerberos authentication is unavailable to Windows operating systems that are not associated with a domain or realm. Furthermore, Windows operating systems support only the two-part format for defining principal identities, that is, name@domain.

Authorization ID mapping

Unlike operating system user IDs, whose scope of existence is usually restricted to a single computer, Kerberos principals can be authenticated in realms other than their own. You can avoid the potential problem of duplicate principal names by using the realm name to fully qualify the principal name. In Kerberos, a fully qualified principal name takes the following form:

name/instance@REALM

where instance can be multiple instance names separated by a forward slash (/), for example, name/instance1/instance2@REALM. Alternatively, you can omit the instance field.

The realm name must be unique within all the realms that are defined within a network. A one-to-one mapping is needed between the authorization ID and the principal name, that is, the name field in the fully qualified principal. This simple mapping is needed because the authorization ID is used as the default schema by the DB2 database manager and should be easily and logically derived. Be aware of the potential issues caused by the following mappings:

Principals with the same name but from different realms are mapped to the same authorization ID. For example, the following two principal names both map to an authorization ID of gregor1x:
- gregor1x@EXAMPLE.COM
- gregor1x@WWW.COM
Principals with the same name but on different instances are mapped to the same authorization ID. For example, the following two principal names both map to an authorization ID of gregor1x:
- gregor1x/bigmachine@EXAMPLE.COM
- gregor1x/littlemachine@EXAMPLE.COM

Therefore, follow these guidelines:

Maintain a unique namespace for a name in all the trusted realms that access the DB2 database server.
Make all principals with the same name field, regardless of the instance, belong to the same user.

Server principals

On UNIX and Linux operating systems, the server principal name for the DB2 database instance is assumed to be instance name/fully qualified hostname@REALM. This principal must be able to accept Kerberos security contexts, and it must exist before you start the DB2 database instance, because the server name is reported to the DB2 database instance by the plug-in at initialization time.

On Windows operating systems, the server principal is usually identified by the domain account that is used to start the DB2 database service. An exception to this situation is when the instance is started by the LocalSystem account. In this case, the server principal name is reported as host/hostname. This identity is valid only if both the client and server belong to Windows domains.

Windows operating systems do not support names that have more than two parts. For example: component/component@REALM. This creates an issue when a Windows client attempts to connect to a UNIX server. As a result, if you require interoperability with UNIX Kerberos, you must create a mapping between the Kerberos principal and a Windows account in the Windows domain. For instructions, see the appropriate Windows documentation.

You can override the Kerberos server principal name that is used by the DB2 server on UNIX and Linux operating systems by setting the DB2_KRB5_PRINCIPAL environment variable to the fully qualified server principal name. The replacement server principal name is recognized by the DB2 database system only after you restart the instance by issuing the db2start command.