IBM Books

Administration Guide


Using DCE Security Services to Authenticate Users

When considering security for your distributed database environment, Distributed Computing Environment (DCE) Security Services are a good option because DCE provides:

DB2 supports DCE default login contexts, connection login contexts, and delegated contexts. A default login context is established when a user does a dce_login on a client. Subsequent DB2 commands have access to this context and may perform user authentication without further user intervention (that is, no requirement for a user ID or password). A connection login context is established for a DB2 session using the user ID and password provided on CONNECT or ATTACH using the USER/USING clause. Finally, a delegated login context occurs when a DB2 client is used as part of a DCE server application. The DCE server application (that is also a DB2 client), receives requests from a DCE client application, from which point the original identity of the user originates. Provided the DCE client and DCE server are correctly configured to allow the DCE server to be a delegate for the DCE client, DB2 will obtain the delegated token and forward this to the DB2 server. This allows the DB2 server to use the original identity of the DCE client, rather than using the identity of the DCE server, to process requests. Information on how to establish a delegated login context can be obtained from the DCE documentation for your platform.
Note:There are several vendor products that support DCE. To ensure that DB2 UDB for Windows NT can work with IBM's DCE product in the area of security services, two new DLLs have been provided: db2dces.ibm and db2dcec.ibm. (These DLL files are only appropriate for Windows NT.) If you purchase and use IBM's DCE product for security services, these two files must be copied to db2dces.dll and db2dcec.dll respectively. If you are considering another vendor's DCE product, you should contact the vendor service organization and the DB2 UDB service organization to discuss whether the vendor's DCE implementation for security services will work with DB2 UDB.

How to Setup a DB2 User for DCE

Users must be registered in the Distributed Computing Environment (DCE) Registry and have correct attributes before being used with DB2. See the appropriate platform-specific DCE documentation for information on how to create a DCE principal.

Each DB2 user wishing to use a DCE-authenticated server must have a DCE principal and account defined in the DCE Registry with the client flag enabled. This principal must also have an entry in its Extended Registry Attributes (ERA) section showing what authorization name will be used for this principal when it connects to a particular DCE authenticated server.

You may also wish to have user principals be members of groups in order to use group privileges in the database. Similar information in the group ERA maps the group name to a DB2 authorization name. The authorization name is a secondary authorization name but the same restrictions apply. Please refer to your DCE documentation for additional information on how to create groups and add members.

The information in the ERA maps a user's DCE principal or group name to a DB2 authorization name for a particular server DCE principal name. To use an ERA, an ERA schema indicating the format of this attribute must be defined. This needs to be done once per DCE cell and is accomplished by completing the following steps:

  1. Login to DCE as a valid DCE administrator
  2. Invoke dcecp and enter the following at the prompt:
      > xattrschema create /.:/sec/xattrschema/db2map \
      > -aclmgr {{principal r m r m } {group r m r m }} \
      > -annotation {Schema entry for DB2 database access} \
      > -encoding stringarray \
      > -multivalued no \
      > -uuid 1cbe84ca-9df3-11cf-84cd-02608c2cd17b
    

This creates the Extended Registry Attribute db2map.

To view this mapping, issue the following command at the dcecp prompt:

  > xattrschema show /.:/sec/xattrschema/db2map

You will see the following:

{axlmgr
 {{principal {{query r} {update m} {test r} {delete m}}}
  {group     {{query r} {update m} {test r} {delete m}}}}}
{annotation {Schema entry for DB2 database access}}
{applydefs no}
{intercell rejects}
{multivalued no}
{reseved no}
{scope {}}
{trigbind {}}
{trigype none}
{unique no}
{uuid 1cbe84ca-9df3-11cf-84cd-02608c2cd17b}
Note:Restrictions on the contents of the authorization name recorded in the ERA are not enforced by DCE. If a DCE principal or group is given an invalid authorization name, an error results when an attempt is made by DB2 to authenticate that user. (Recall that authentication may occur at CONNECT, ATTACH, DB2START, or any other operation where authentication is required.) It is also highly recommended that you ensure the assignment of authorization names to DCE principals is one-to-one and unique. DCE does not check these conditions.

If a DB2 client is to access a DB2 UDB server, once they are registered as DCE principals, the ERA information must be added to provide the mapping from the principal name to the authorization name. This must be done once for each user or group; and, is accomplished by completing the following steps:

How to Setup a DB2 Server to Use DCE

Servers must be registered principals in the Distributed Computing Environment (DCE) Registry and have correct attributes before being used with DB2. See the appropriate platform-specific DCE documentation for information on how to create a DCE server principal.

The DCE Security client runtime code must be installed and accessible by the server instance.

Each DB2 server that wishes to use DCE as an authentication mechanism must register with DCE at the time of issuing DB2START. To avoid having to do this manually, DCE provides a method whereby a server maintains its own user ID and password (key) information in a special file called a keytab file. At DB2START, DB2 reads the database manager configuration file and obtains the authentication type for the instance. If it finds the authentication type is DCE, DCE calls are made by the DB2 server to obtain the information from the keytab file. It is this information that is used to register the server with DCE. This registration allows the server to accept DCE tokens from DCE clients and to use them to authenticate these users.

The instance administrator must create the keytab file for the instance using DCE commands. Detailed information on how to create a keytab file is included in the DCE documentation for your platform. In that document, refer to the details associated with the keytab file and the commands dcecp keytab or rgy_edit. The DB2 keytab file must be named keytab.db2 and must reside in the security subdirectory of the sqllib directory for the instance. (For Intel-based operating systems, the file must reside in the security subdirectory of the INSTANCENAME subdirectory of the sqllib directory. INSTANCENAME is the instance name of the database you are working with.) It should contain only one entry for the server principal for the specified instance; anything else results in an error at DB2START time. On UNIX operating system platforms, this file must be protected with file permissions to only allow read/write for the instance owner.

Following is an example of the creation of the keytab file:

To start DB2 using DCE authentication once the DCE configuration is complete, you must tell DB2 it is to use DCE authentication by updating the database manager configuration file with authentication type "DCE". This is done by issuing the following CLP command:

   db2 update database manager configuration using authentication DCE
    sysadm_group DCE_group_name

Then perform a dce_login to a valid DB2 DCE user who has SYSADM authority and issue DB2START.
Note:Before starting DB2 using DCE authentication, ensure you have defined a DCE user principal to be used as your SYSADM for the instance so that you have a valid DCE user ID from which to start, stop, and administer the instance. Please see "How to Setup a DB2 User for DCE" for instructions on how to do this.

In addition to these instructions, ensure the principal created is a member of the SYSADM_GROUP for the instance. By default, this group name is DB2ADMIN for DCE authentication when no group is explicitly specified (that is, when the SYSADM_GROUP is null), but it can be updated before changing the authentication type for the instance to a group name (authorization name) of your choice. The DCE group that you select must have an ERA defined that maps it to the specified SYSADM_GROUP authorization name.

One of the functions of the DB2 Administration Server is to start DB2 instances. When AUTHENTICATION = DCE, the DCE principal used in the DB2 keytab file for the instance must have a valid DCE principal to DB2 authid mapping. This mapping is required for the DB2 Administration Server to start the DB2 instance. The valid mapping allows this ID to act as a client as well as a server.

How to Setup a DB2 Client Instance to Use DCE

A client-only instance may be established to use DCE authentication for local operations by updating the database manager configuration file and setting the authentication type to DCE. There is no requirement to have a keytab file for a client-only instance since there is no server that needs to register to DCE. In general, it is not recommended (or required) that a client-only DB2 instance use DCE authentication, but it is supported.

A client that wishes to access a remote database using DCE security requires access to the applicable DCE Security product. Optionally, the client may choose to catalog the authentication type for the target database in the database directory. If the client chooses to specify DCE authentication, the fully-qualified DCE server principal name must also be specified. If DCE authentication is not specified in the directory, the authentication and principal information is obtained from the server at CONNECT time.

DB2 Restrictions Using DCE Security

Using DCE authentication places some restrictions on certain SQL functions provided by DB2 and related to group support. The following restrictions exist when using DCE authentication:

  1. When using the GRANT or REVOKE statements, the keywords USER and GROUP must be specified to qualify the authorization name specified, otherwise an error is issued.
  2. When using the AUTHORIZATION clause of the CREATE SCHEMA statement, the group membership of the authorization name specified will not be considered in evaluating the authorizations required to perform the statements that follow this clause. This may result in an authorization failure during execution of the CREATE SCHEMA statement.
  3. When a package is rebound by a user other than the original binder of the package, the privileges of the original binder are reevaluated. In this case, group membership of the original binder are not considered when reevaluating privileges. This may result in an authorization failure during rebinding.

DCE authentication as performed by DB2 flows DCE Tickets obtained using the OSF DCE Generic Security Services Application Programming Interface (GSSAPI). As such, all authentication for DCE Security takes place at the database protocol layer. Certain communication mechanisms may provide additional communication layer security, which is not necessarily integrated with DCE. In cases where the communication layer authentication can be kept entirely independent of the database protocol layer authentication, no restrictions will be enforced. However, the criteria for both the database protocol layer and the communication layer authenticating must be satisfied before a connection can be successfully established. In cases where the database protocol layer and the communication protocol layer authentication mechanisms interact, their use may be restricted if some combinations result in a security exposure.

DCE authentication may be used in conjunction with TCPIP SOCKS support; however, the two security mechanisms work independent of one another. This may mean that not only must the user provide a valid DCE login context, but must also be logged on to a local operating system user ID that meets the criteria of the SOCKS Server.

DCE authentication may be used in conjunction with NT Named Pipes; however, the two security mechanisms work independent of one another. Not only must the user provide a valid DCE login context, but he must also be logged on to the NT Domain to a user ID that meets the criteria for the NT Named Pipes support.

In order to address possible confusion where DCE principals and local operating system user IDs are both used for authentication, as in the above two examples, an integrated DCE logon can be used. In this case, when logging on to a system, the user is automatically logged into the appropriate DCE principal as well. See the DCE documentation for your platform for details on how to use this feature, if it is supported. Note that in using this approach, the same name is used for the DCE principal and the local operating system ID. This may mean that the same value that is contained in the DCE encrypted ticket also flows on the wire unencrypted in the communication layer.

DCE authentication can only be used with APPC communications when the SECURITY parameter is set to NONE. This is to avoid the possibility of sending an unencrypted principal and/or password in the communication layer, while using an encrypted DCE token for the same principal in the database protocol layer. DCE Security at the APPC layer is not supported by DB2 at this time.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]

[ DB2 List of Books | Search the DB2 Books ]