Authentication and Authorization in IBM DB2

Authorization is the process of determining access information about specific database objects and actions based on a supplied user ID. Privileges can be granted to specific users or to groups of users. Users that are a member of a group automatically inherit the group’s privileges. As mentioned before, these users and groups are defined outside the DB2 UDB; for example, in Active Directory.

DB2 supports replacement plug-ins for authentication and authorization. The authentication plug-ins can replace the default user name and password method, and support alternative authentication methods including GSSAPI. DB2 also supports the use of multiple plug-ins for authentication.

Authentication for DB2 Security and Authentication Plug-Ins

Authentication Service for IBM DB2 package provides plug-ins that allow you to connect or attach to a DB2 database using either an Active Directory or a UNIX user identity. In addition, the package includes a group plug-in used for authorization.

The package provides two security plug-ins for authentication:

  • centrifydc_db2userpass: a username/password plug-in to replace the DB2 default.
  • centrifydc_db2gsskrb5: a GSSAPI plug-in for single sign on support.

The security plug-ins can be used independently or in conjunction with one another.

  • If you specify and configure both the username/password plug-in and the GSSAPI plug-in, the GSSAPI plug-in is used when the user connects without specifying a user name and password. The user account can be on an Active Directory domain controller or UNIX computer. If the user does specify a user name and password, the username/password plug-in is used instead.
  • If only the GSSAPI plug-in is configured, only Active Directory users can connect to the database instance. In addition, the Active Directory user name instead of the UNIX user name must be used in the SQL GRANT or REVOKE statements when granting or revoking permissions. In this case, the Active Directory user name should follow the DB2 user naming conventions.

DB2 and Delinea Plug-In Compatibility

Starting with DB2 release 10.5.4, DB2 does not allow security plug-ins to fork a process to authenticate DB2 users. To support this behavior, the Delinea plugins starting with Delinea for DB2 5.2.3 use the CentrifyDC service to authenticate Active Directory and local users.

If your environment contains DB2 10.5.4 or later:

  • Only Delinea for DB2 5.2.3 or later plug-ins are supported, and
  • Before you install Delinea for DB2, you must install the Server Suite 2015.1 or later agent (that is, agent version 5.2.3+) on each DB2 server, and
  • You must ensure that the agent (that is, the centrifydc service) is running on each DB2 server.

Username-Password Plug-In

The Delinea username/password plug-in, centrifydc_db2userpass, supports authentication from both Active Directory and non-Active Directory users. A non-Active Directory user may be one of the following:

  • a UNIX user from local stores such as /etc/passwd and Name Service Switch (NSS)

  • any user who has been authenticated using Pluggable Authentication

    Modules (PAM)

  • any user who has been authenticated using the AIX Loadable Authentication Module (LAM)

The Delinea username/password plug-in, like the IBM default username/password plug-in, gives you the option to allow users who are already logged in to a DB2 server machine to connect to a database instance without entering a user name or password. However, the default is to require a logged in user to re-enter the user name and password to access the database instance.

GSSAPI Plug-In

The GSSAPI plug-in, centrifydc_db2gsskrb5, supports single sign on to a DB2 instance using the user’s Active Directory account. This plug-in assumes that the user requesting access to the database is already logged in to the client computer and has been authenticated through the Kerberos mechanism.

The GSSAPI plug-in allows users to run the connect and attach commands without specifying a user name and password even if the user is connecting from a remote DB2 client. It requires the user to have a valid Kerberos ticket. Generally, users obtain a Kerberos ticket automatically when they log in as an Active Directory user. However, in the following situations the user does not obtain a ticket automatically:

  • The user logs in to the DB2 server as a local, non-Active Directory user.
  • The user enters the UNIX command su - user as root to get a shell owned by another Active Directory user or local user.
  • The user logs in as a user who has both an Active Directory account and a local user account. However, the Active Directory account is not in the same zone as the machine you logged in to.

In each of these cases, the user needs to obtain Kerberos tickets before single sign-on support is provided.

To obtain tickets for an Active Directory user, type kinituser. The user is prompted for a password. To avoid being prompted, you can create a keytab file in advance using the adkeytab command, set the environment variable KRB5_ KTNAME to the full path of your keytab file, and then run kinit -k user@DOMAIN to obtain the tickets.

If a user name is explicitly provided when only the GSSAPI plug-in is installed (for example, by entering the DB2 command connect to testdb user username using password), the plug-in first authenticates the given user to the Kerberos Key Distribution Center (KDC), and then obtains a ticket-granting ticket (TGT) upon success. The plug-in next uses the TGT to get a service ticket for the DB2 server.

Group Plug-In

You install the Group plug-in, centrifydc_db2group to retrieve the list of groups to which a user belongs for authorization. The group plug-in is called automatically after user authentication by DB2. The group info retrieved is used by DB2 to check a user’s access rights and determine whether the user has privilege to do specific tasks; for example, connect, query, perform database management, and so on.

The Group plug-in queries Active Directory first for the groups to which the user belongs, and then it looks in the local groups on the host. The two lists are then merged, with duplicates removed and returned to DB2.

Make Connections to the DB2 Administration Server

The DB2 Administration Server (DAS) allows administrators to manage DB2 instances remotely. Using utilities such as DB2 Control Center (db2cc) to perform operations such as creating, removing, starting, or stopping a database instance remotely require a DAS connection. Tasks that can be performed on a running instance (such as creating or dropping a table in the instance) do not require a DAS connection.

The DAS uses a separate authentication scheme from the instance authentication. The DAS does not call into the DB2 security plug-ins or PAM when authenticating users. If you want to log in as an Active Directory user and use utilities such as DB2 Control Center to remotely administer an instance, you have the following options, irrespective of the plug-ins that you select:

  • Run the utility that connects to the DAS (such as db2cc) on the DB2 server machine as the user who can perform the desired administrative tasks.

    Make sure that this user is in the same zone as the DB2 server machine.

  • Install and configure either the Microsoft or Delinea password synchronization service. For more details about the Delinea password synchronization service, refer to the Administrator’s Guide for Windows.

  • Create a local user on the DB2 server machine and enter that user’s user name and password when DB2 Control Center (or other utility connecting to the DAS) requests a user name and password.

Next Step:

Install and Configure the Server