Pre-Requisites

The pre-requisites are the same as the previous post.  Because for the SSO plugin to work we need an AD account to create a keytab, we've added some additional steps.

A little bit of planning

Obtaining the AD Principal
A keytab file is usually tied to an AD principal;  all Centrified systems have one;  but in this case, we will have a service account and there are two ways to do this:

• If you have an AD account that can create user principals:  
  • you can use the setupdb2.sh script, option 2 and follow the prompts
  • you can use the adkeytab command with the --new option and perform everything in a single step.
• If you don't (which is quite common because of separation of duties), you need to request the account and then work in tandem with the AD folks to adopt the account.

Naming conventions

Because we're talking about AD accounts here, your organization may (hopefully) have a naming standard, if not, you have to keep in mind that you need to be able to identify the purpose of the AD account in AD.  A naming convention like this:  [instanceName-server]  is simple enough and descriptive.  In this example, my instance is db2inst1 and the server is engcen8, therefore my AD account will be called db2inst-engcen8.

Container OU

If your AD admin is not messy, most likely they will have an OU designated for Service Accounts.  In fact, if you worked with Centrify Professional Services, there should be an OU under UNIX with the same name.  

Active Directory Account and Keytab

AD Account creation
When you request the account, the AD sysadmin will create an account like this:

Typically the best practices for service accounts are to set the password to never expire, and that the account can't change it.

Issue #1 - At this point, the password for this service account is known at least by one person.  This will go away once the keytab is adopted, the password will be randomized.

Now there are two things that can happen - the AD admin can grant you temporary full control of the account until you run adkeytab, or can just type in their password in the adequate moment.

Verify the account 
Use adquery user and the -A option and inspect the UPN and cn.  Here's the truncated output:

$ adquery user -A db2inst1-engcen8
dn:CN=db2inst1-engcen8,CN=Service-Accounts,DC=centrifyimage,DC=vms
samAccountName:db2inst1-engcen8
userPrincipalName:db2inst1-engcen8@centrifyimage.vms
canonicalName:centrifyimage.vms/Service-Accounts/db2inst1-engcen8

Issue # 2, the account is missing a servicePrincipalName (SPN), 

Issue # 3, the the userPrincipalName is in a non-MIT Kerberos friendly format. 

This means that we need 

• To adopt the account, this will randomize the password and create a keytab file (options A or --adopt and K or --keytab);  e.g.  /home/db2inst1/db2inst1-engcen8.keytab  (permissioned accordingly)
• To update the UPN (option -U or --upn);  e.g. engcen8@CENTRIFYIMAGE.VMS
• To add an SPN (option -P or --principal) with the format instance/server@suffix@REALM; e.g. db2inst1/engcen8.centrifyimage.vms@CENTRIFYIMAGE.VMS
• To specify an AD account that perform the adoption the keytab (-u --user). e.g. dwirth
  needs to be able to change account attributes like the UPN, SPN and password.
• We need to know the canonicalName (cn) of the account.  e.g. db2inst1-engcen8

Adopt the keytab and modify the account attributes

Based on the information above, our adkeytab command looks like this (elevating with dzdo to write to the target folder):

$ dzdo adkeytab --adopt --principal db2inst1/engcen8.centrifyimage.vms@CENTRIFYIMAGE.VMS --upn db2inst1-engcen8@CENTRIFYIMAGE.VMS --user dwirth -V --keytab /home/db2inst1/db2inst1-engcen8.keytab db2inst1-engcen8

Here's the command output (truncated)

dwirth@CENTRIFYIMAGE.VMS's password:
Adding managed account keys to configuration file: db2inst1-engcen8
Changing account 'db2inst1-engcen8' password with user 'dwirth@CENTRIFYIMAGE.VMS' credentials.
Key Version = 3
Success: Adopt Account: db2inst1-engcen8

Inspect the account post-adkeytab

$ adquery user -A db2inst1-engcen8
dn:CN=db2inst1-engcen8,CN=Service-Accounts,DC=centrifyimage,DC=vms
userPrincipalName:db2inst1-engcen8@CENTRIFYIMAGE.VMS
servicePrincipalName:db2inst1/engcen8.centrifyimage.vms

 Notice how now the UPN was modified and how the account has a servicePrincipalName.

Make sure the keytab file has the right permissions

The owner of the keytab should be the instance account.

$ chown db2inst1:db2iadm1 /home/db2inst1/db2inst1-engcen8.keytab

Re-Configuration of the DB2 SSO Module

At this point, all we need to do is rerun the setupdb2.sh script and follow the prompts to add the SSO plugin; because we don't want to deactivate the existing ones, we will run option 1 again and point to the previously created keytab.

$ dzdo /usr/share/centrifydc/bin/setupdb2.sh inst=db2inst1
Is db2inst1 a DB2 server install?
Enter y for yes, n for no [y]: y

db2inst1 is a 64 bit instance
DB2 server and client setup will be done.

Is this DB2 version 9.5 or later?
Enter y for yes, n for no [n]: y


Which DB2 auth method do you want to use?
[1] Username/Password and Single sign-on
[2] Single Sign-on only
[3] Username/Password only
[4] Skip this step
Select a number from the menu [1]:

Select a number from the menu [1]: 1


Use the CentrifyDC group plugin?
Enter y for yes, n for no [y]: y


Do you want to configure the instance user db2inst1 as a service account?
You must do this step if you want to use the GSS-Plugin.  If you already did
this step for this instance, select the option to indicate the keytab file
name.

[1] Use adkeytab to create a service account in Active Directory and keytab
    file.  NOTE: You need to specify a user name with administrator privileges
    on the domain to use adkeytab.
[2] Provide the name of an already existing keytab file.
[3] Skip this step
Select a number from the menu [1]: 2


What is the name of the keytab file? Full path please.
[ /home/db2inst1/db2inst1.keytab ]: /home/db2inst1/db2inst1-engcen8.keytab                          

What group should be used as the group owner of this file? All DB2 instances
that you want to use the username/password plugin must be in this group.
[db2iadm1]:


*********** adkeytab setup (required for GSS-plugin) ***********
Using /home/db2inst1/db2inst1-engcen8.keytab for the keytab file for instance: db2inst1
# db2set DB2ENVLIST=KRB5_KTNAME

adkeytab setup successfully!


******* Installing the plugins into instance: db2inst1 *******
Installing client side auth plugin
# rm -f sqllib/security32/plugin/client/centrifydc_db2gsskrb5.so

# cp /usr/share/centrifydc/lib/libcentrifydc_db2gsskrb5.so sqllib/security32/plugin/client/centrifydc_db2gsskrb5.so


Continuing will stop the DB2 instance: db2inst1, update the configuration
and then start the instance.
Continue? y

New configuration:
 Group Plugin                             (GROUP_PLUGIN) = centrifydc_db2group
 GSS Plugin for Local Authorization    (LOCAL_GSSPLUGIN) = centrifydc_db2gsskrb5
 Server List of GSS Plugins      (SRVCON_GSSPLUGIN_LIST) = centrifydc_db2gsskrb5
 Server Userid-Password Plugin        (SRVCON_PW_PLUGIN) = centrifydc_db2userpass
 Server Connection Authentication          (SRVCON_AUTH) = GSS_SERVER_ENCRYPT
 Database manager authentication        (AUTHENTICATION) = SERVER
Starting instance
# db2start
SQL1063N  DB2START processing was successful.
The plugins for DB2 instance: db2inst1 were set up successfully!

I recommend a reboot at this point.

Verify that everything is working as expected

1. Log in with an AD user to the DB2 server
   Issue the klist command to verify that you have a TGT (ticket-granting ticket), if not issue the /usr/share/centrifydc/kerberos/bin/kinit command and type your AD password when prompted.
   

   1. $ klist
      Ticket cache: FILE:/tmp/krb5cc_1627391058
      Default principal: dwirth@CENTRIFYIMAGE.VMS
      
      Valid starting     Expires            Service principal
      11/16/14 22:19:10  11/17/14 08:19:13  krbtgt/CENTRIFYIMAGE.VMS@CENTRIFYIMAGE.VMS
              renew until 11/17/14 22:19:10

    

2.  Try to connect to the sample database without specifying the user
   

   $ db2 
   db2  => connect to sample
   
      Database Connection Information
   
    Database server        = DB2/LINUXX8664 10.5.0
    SQL authorization ID   = DWIRTH
    Local database alias   = SAMPLE
   db2  => quit 

    

3. Now verify that you have a Kerberos service ticket requested via GSSAPI.

$ klist
Ticket cache: FILE:/tmp/krb5cc_1627391058
Default principal: dwirth@CENTRIFYIMAGE.VMS
Valid starting     Expires            Service principal
11/16/14 22:19:10  11/17/14 08:19:13  krbtgt/CENTRIFYIMAGE.VMS@CENTRIFYIMAGE.VMS
        renew until 11/17/14 22:19:10
11/16/14 22:22:36  11/17/14 08:19:13  db2inst1/engcen8.centrifyimage.vms@CENTRIFYIMAGE.VMS
        renew until 11/17/14 22:19:10

And there you have it, just like magic!

Video

 (10 minutes, 15 seconds)