In the almost two years of Centrifying we have discussed Identity Consolidation with AD and Single Sign-on at length. 90% of organizations have Active Directory but sometimes over-complicate things when it comes to identity consolidation and SSO.
I had the chance to speak about this in a seminar and these two videos consolidate many entries that we've covered in this blog over the years.
Direct Integration
Name Service Switch, Pluggable Authentication Modules, GSSAPI, Kerberos and Proxies
OpenSSH SSO over an outgoing external non-transitive AD one-way trust
NSS and PAM using Oracle DB as an example (externally identified user)
The idea is to eliminate complexity and promote reuse by committing to Active Directory, let the Centrify DirectControl agent do the heavy-lifting for Direct Integration and use the SPNEGO plugins when needed.
For the full briefing, including marketing slideware go here.
When running IBM DB2 on UNIX and Linux platforms, organizations are often faced with the following challenges:
They find themselves maintaining local users and groups in the local user store (/etc/passwd or /etc/group) to support DB2.
They face challenges with the 8-character username limitation
Entitlements are managed with groups that are local to that system
Users either make the password the same or use simpler passwords if policy is not enforced
This means:
Each OS hosting DB2 becomes an identity silo, this means:
Policy must be enforced
Access control rules must be in place
Reporting and attestation are needed
This often means audit comments for untimely offboarding of DB2 local users
Promotes complexity and affects user productivity.
Centrify has had the IBM DB2 SSO Module for years now, but I still see organizations struggle. We covered the set up of the plugin in a previous post, but this 20-minute playlist has a technical briefing with demo for those who are looking to overcome this challenge:
In summary, Centrify IBM DB2 SSO plugin provides:
User/Password plugin: Allows users to authenticate to DB2 with their AD credential, no short names required or local identities.
Group plugin: Exposes user's AD groups to DB2, this is an avenue to assign entitlements in a more effective way
GSSAPI plugin: Provides SSO services via GSS interfaces.
Less identity silos, more productivity, more operational efficiency....
The user/password plugin that leverages OS authentication (via PAM) to enable DB2 access to AD users.
The group plugin that exposes AD group memberships to DB2
The GSS (SSO) plugin that allows silent sign-on to DB2 and can be leveraged in AIX systems that are using LAM instead of PAM
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 gathered above, our adkeytab command looks like this (elevating with dzdo to write to the target folder):
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.
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
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.
Organizations can always count with the
reliability of IBM hardware, operating systems and utilities for mission
critical applications. That’s why
Centrify has invested in certifying the product lines with IBM infrastructure.
This post discusses the DB2 SSO Module; this
plugin (like the Apache HTTP and Java plugins) leverages the Active Directory
integration capabilities and robustness of the Centrify agent to provide
additional value and functionality to DB2 implementations.
The DB2 plugin provides the following benefits:
No need
to keep users local to the UNIX/Linux system to support DB2: When used natively, DB2 users need to have
user accounts in the local /etc/passwd file.
The DB2 enables AD users to access DB2 so the benefits of Unified
Identity, Centralized Administration, Streamlined Authentication and Policy
Enforcement are organically attained. In practical terms: no more getting dinged by auditors when the
account of a long-gone user is found active in the /etc/passwd of a DB2 system.
Long
login names: Support for logins that are longer than 8 characters
Single
Sign-on (SSO): Centrify enables SSO to
DB2 leveraging the GSSAPI
Active
Directory Group Support: AD
group memberships can be leveraged to grant entitlements inside DB2.
This is one of the best Database to AD integration models out
there.
This article covers setup, configuration and
testing of the DB2 plugin on Linux 64 bit in a lab environment. Like any other DBMS, a true production
implementation requires planning and understanding of the current environment.
Requirements
A Centrified Unix/Linux system running a DB2 Instance (we’ll be
using DB2 10.5 on Linux) Setup is pretty much the same if you have an IBM AIX system. The only caveat is that if you’re using LAM
instead of PAM, you’ll need to use the GSSAPI (SSO) plugin rather than the
user/password plugin.
You need to know the DB2 Instance user name and password
You need to have the ability to create an AD service account or
have an account prepared for you that can be adopted with AD Keytab (GSSAPI SSO
plugin only).
Implementation Steps
Information and requirements gathering
Collect the OS version, architecture, version of Centrify
adclient.uname -a, adinfo -v and adinfo -C provide that information
Collect the DB2 database version, architecturethe db2level command provides this information
Request an AD service account OR have
credentials to run adkeytab. $ cat /etc/redhat-release CentOS release 6.6 (Final)
$ uname -a Linux engcen8.centrifyimage.vms 2.6.32-504.el6.x86_64 #1 SMP Wed
Oct 15 04:27:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ adinfo -v adinfo (CentrifyDC 5.2.0-218)
$ db2level DB21085I This instance or
install (instance name, where applicable: "db2inst1") uses "64" bits and DB2 code
release "SQL10050" with level identifier "0601010E". Informational tokens are "DB2 v10.5.0.0",
"s130528", "LINUXAMD64105", and Fix Pack "0". Product is installed at "/opt/ibm/db2/V10.5".
My server64 bit CentOS with DB2
10.5 64 bit, the instance name is db2inst1. I will download the package DirectControl for IBM DB2 running on RHEL 4, 5,
6 x86_64 " the version is 4.4.4 as of the original post in November
2014.
Installation
Unpack and install the DB2 SSO plugin
$ tar xzvf centrifydc-db2-4.4.4-rhel3-x86_64.tgz
The installation file on RHEL for this version is called
centrifydc-apache-4.4.4-rhel3-x86_64.rpm, so perform a yum or rpm install.
Installing and
Configuring the User/Password and Group Plugins
The user/password plugin allows for DB2 to use PAM to provide
access to AD users. The group plugin
allows the use of AD group memberships for the purposes of entitlements inside
DB2.
The master script is called setupdb2.sh and it is on
/usr/share/centrifydc/bin. The syntax is
setupdb2.sh inst=<instancename> In
my case the instance is called db2inst1.
