Showing posts with label SSO. Show all posts
Showing posts with label SSO. Show all posts

Friday, April 28, 2017

Examples of Identity Assurance with Centrify MFA in AWS (Console, EC2 and CLI with PowerShell)

Note:  This is a repost of an article I recently wrote for the Centrify Community Techblog

Background
Centrify recently commissioned a study with Forrester Research that yielded some important information about the state of Security.  Bottom-line, we have decided to throw money and resources to the problems around information security rather than rethinking our approach, the results are more breaches and exposures.
You can access the study results here: https://www.centrify.com/lp/rethink-security-ebook

A key conclusion on over 200 organizations surveyed is that those with higher Identity and Access Management (IAM) maturity were breached 50% less while maintaining operational efficiency. 

As you read the previous paragraph, you may ask yourself: what is the first step the journey to the continuous improvement required for IAM maturity?  As illustrated in the model below,
a the key component is to establish identity assurance with technologies like MFA or PKI, however this is challenging enough because many organizations have not achieved this on-premises, much less in IaaS/PaaS platforms like Amazon AWS.

This is where Centrify can help.  This article is about guiding you on how to use the Centrify platform to establish identity assurance in several use cases:  
  • Accessing the AWS Consoles with shared accounts (like Amazon root) or Federated identities
  • Accessing EC2 instances locally (Linux or Windows)
  • Accessing AWS commands via the CLI (E.g. PowerShell or Python)
Please note that identity assurance concepts apply to both users and systems (due to API access);  in this use case we'll focus on interactive (user) use cases.  For system/system or app/app, other mechanisms like PKI or Kerberos can be used and we can cover in another entry.

The Centrify Advantage
The biggest advantage for Centrify lies in it's platform and integrations, as a company that covers both Identity as a Service (IDaaS) as well as Privileged Identity Management (PIM) we understand that everything starts with Identity Consolidation.   This is not the "legacy" (metadirectory/connector-based mid-2000s) identity consolidation, this is the "straight-to-the-source" standards based approach using Federation in the IDaaS side, plus direct-integration (with Kerberos) in the case of heterogeneous OS platforms.  We add to this a series of services:
  • A policy service
  • A multi-factor authentication engine (that includes modern and legacy-based support)
  • A risk-based engine (analytics) 
Our native integrations with Active Directory make us a prime vendor to consolidate capabilities;  here's an example, if an organization wants to secure access to a web app, integrate a non-windows platform to a central directory like AD and get MFA, they may engage 3 distinct vendors, however Centrify can help with world-class solutions on the three areas.  Let's look at a the examples.
  
Securing Shared or Federated Access to the AWS Console
Centrify Identity Service provides several turn-key templates to help with shared or federated (via SAML or using the AWS API) SSO for Amazon Web Services.  We have covered these integrations here:

However, the powerful policy engine and the support for multiple authentication profiles makes this integration simple and flexible.  
Here's a quick demo on how this integration is enabled and the user experience:
Notice how we achieved our goals:  identity consolidation and assurance while maintaining usability.

Securing Access to Linux and Windows AWS EC2 Instances
Centrify Server Suite provides native integration with Active Directory, regardless of your deployment model. 
By leveraging AD (hosted by you or in AWS), you are eliminating the duplication of identity sources caused by SSH keys with the addition of DirectAuthorize technology that provides role-based access control and privilege elevation and is fully-integrated with the policy and authentication profiles provided by Identity Service or Privilege Service.  We have discussed these integrations here:
 
Provided the Identity Service/Privilege Service setup is correct and the proper PKI trust is in place, for Access and Privilege elevation, all we need to do is set up the proper checkbox at the role, UNIX command or Windows desktop or application.
 
Here's the user experience that meets the requirements for identity assurance via MFA for both Linux and Windows in the context of access and privilege elevation.
 
Notice how we achieved our goals:  identity consolidation and assurance while maintaining usability.

Securing Access to AWS CLI (e.g. PowerShell)
Administration of AWS Services is often performed via the AWS CLI (implemented via Windows PowerShell or UNIX CLI).
If you're using Centrify Identity Service with SAML federation into AWS, you can implement the SSO plugin provided with the template.
References:
Here's the user experience in PowerShell.  Note that the experience will be based on the authentication profile that applies to the user by policy.
If you have multiple roles, you get to select them:
 
Finally, the authentication token is stored in the $me variable and the user can move-on to use AWS PowerShell commandlets.   See the pattern here?  Identity assurance with MFA and role-based access without compromising usability and achieving this with with a single solution set.
  
Metrics
A cliché of business schools is the statement "you can't manage what you can't measure"; but since we're dealing with IT security, you may want to track how we are performing towards our goal of consistent identity assurance, in these AWS examples, we can use AWS CloudWatch metrics to measure the percentage of access in the proper context (e.g. Console, EC2, etc) is performed with assurance.  Therefore a good metric to track would be:
 

MFA events are tracked for Linux, Windows and Identity Platform, this allows you to be creative and get information from CloudWatch or from Identity Service.
Note the CloudWatch widgets above.  In my Linux space, I have a ratio of close to 60% identity assurance (4 out of 7 successful logins were with MFA), however my track record on the sample data I created on Windows is much better (100%).  You use the same approach for privilege elevation via Centrify-enhanced sudo or Centrify Agent for Windows.

In the case of Identity Service or Privilege Service, the platform provide dashboards and reports like the Security Overview - User Logins
These dashboards allow for reviewing information within 7 days or 24 hours and to look at specific date-time ranges. 

Conclusion
Identity assurance is closer than what you think, with the "barriers of entry" for MFA solutions going down, it's all about working with the right partner and Centrify excels at securing apps, endpoints, infrastructure and secrets; finally, the obvious challenge is organizational dynamics;   If you still have groups opposed to centralizing directories or maintaining legacy infrastructure, you can split the project in several phases and attack the platforms that are easier from a people/process standpoint.  Once you can demonstrate identity assurance within those applications or infrastructure, it's going to be hard for those "holding on to the past" to ignore that the best practices are here to stay. The model applies to all aspects of any risk-sensitive information technology area and like every other framework it's not a silver bullet; new threats, attack vectors, compliance requirements and tools are introduced, therefore this has to evolve as well.

Sunday, August 30, 2015

In Depth: Centrify Privilege Service (August 2015)

What's Centrify's Privilege Service (CPS)? 

CPS is Centrify's complement to the existing Privilege Management capabilities offered by Server Suite.  The focus is on Shared Account Password Management (SAPM), Privilege Session Management (PSM) and more.

Platform shared capabilities
  • Active Directory Integration:  CPS uses Centrify's leading AD Bridging capabilites to provide organizations AD integration to the solution.  It leverages the assets of Centrify Identity Service (formerly known as user suite).
  • Single Sign-on (SSO): When users have an authenticated Windows session, if configured by the administrator and with a supported browser, the privileged users will get SSO to the portal or apps.
  • Password Wallet:  Users and Administrators can use the built-in password wallet for Web Apps that 
  • Multi-factor Authentication:  The platform uses several mechanisms for MFA (Centrify Mobile Authenticator from the registered device's Centrify app, one-time-passwords using SMS, E-mail link, or voice call placed to the user's business or mobile phone.
  • Geo-Fencing: Identity platform leverages geo-location for several purposes: access policy, smart MFA, reporting and analytics.
  • Multiple Identity Stores:  CIS today supports users from connected or disconnected (no trust-relationship) Active Directory forests, but also users form the Centrify Cloud Directory or LDAP; (the list of sources grows as I type).
  • Per-App VPN (reverse-proxy):  Allows the elimination of persistent VPN connections and provide remote access just to the individual application.
  • Role-based Access Control:  System access, and system rights are all based on roles that can be assigned to users from any source.
  • Federated Identity Support:  Enable user access to applications or resources from your partners with a few simple steps.
  • User Access Request (Workflow and Approvals):  Access to apps, login sessions to servers, password checkouts and more can be tied to requests and approvals built-in to the platform.
  • Enterprise Mobility Management:  In the modern enterprise, with apps being accessed from anywhere, mobile phones/tablets being used as secondary factors of authentication, providing MDM, MCM and MAM is very important and this has been a key capability for iOS, MacOS, Android and other platforms.
  • Self-Service Capabilities:
    • App portal for a consolidated view of the user's apps and servers
    • Device portal to allow the user to enroll and manage their devices
    • Activity portal to self-review activities
    • AD or Cloud user self-service password reset
    • Self-Service from Mobile App
  • Management Portal:  Wizards, Dashboards, Apps, Policies, Roles, Reports, Settings, etc.
  • Simple architecture:  On-premise capabilities like AD Bridge, App Gateway (reverse-proxy), support for LDAP are available by installing components that sit behind the corporate firewall (even behind the Proxy).
  • Datacenter and geographical redundancy plus multi-language:  The Identity platform is distributed across Microsoft's Azure infrastructure and it has been translated to over 15 languages.
  • PKI - Certificate Services:  An independent built-in Certificate Authority for each tenant to provide additional encryption services, mutual trust and authentication using PKI certs in the context of data at rest and in transit, federation assertions, end-point certificates, etc.
  • Bottom-line:  CIS is a full-fledged Identity as a Service (IDaaS) solution that eliminates the need for complex federation infrastructure and can be used for multipurpose scenarios of over 3,000 apps.  
Privilege Service capabilities
  • Privilege Session Access:  CPS provides the ability to access system resources from a central set of servers (jumpbox).  The CPS infrastructure components can be deployed in a few minutes anywhere the organization has IT footprint.
  • Privilege Session Proctoring and Session Abort:  Allows a supervisor to view remote sessions in real time, as well as triggering remote disconnections.
  • Shared Account Password Management lifecycle management:  CPS provides the ability to request access to, check out, check-in and rotate passwords in Windows, UNIX, Linux and a variety of network devices.
  • Mobile First:  Remote access and Password operations are available from the Centrify mobile app with PIN or bio-metric compatibility.
  • Self-Service Workspace:  Provides the privileged user with a consolidated view that includes status of their password checkouts, sessions, recent and favorite resources.
  • Privilege Session Recording:  Leverages Centrify's DirectAudit to provide proxy-based auditing or end-to-end auditing if Centrify Server Suite Enterprise is deployed.
  • Flexible Storage of Secrets:  Organizations have the flexibility to store secrets with the built-in Secure Storage (secured with their individual CA key) or they can use their own Hardware Secure Module.  Centrify has partnered with Safenet to deliver integration with KeySecure devices.

Explore:  The Platform from the End User Perspective



Explore:  The Platform from the Administrator's Perspective


Explore:  CPS User Experience

Explore:  CPS Privilege Session Brokering and Proctoring and Termination



Explore:  CPS Shared Account Password Management



Explore:  Privileged Session Auditing



Explore:  Worklfow and Approvals (User Access Request)


Explore:  Flexible Storage


Sunday, August 23, 2015

Using Centrify's AD Technology to Overcome IBM DB2 Database Access and Identity Challenges

Background

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....

Sunday, November 16, 2014

Business Cases: IBM DB2 Extra - Configuring GSSAPI/Kerberos SSO with the Centrify GSS Plugin

This is the continuation of our previous post about integrating DB2 to AD by using the Centrify IBM DB2 SSO module.  The IBM DB2 SSO module provides 3 basic plugins:
  • 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):

$ 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

Configuration of the SSO Module and DB2

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.


 /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

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.

$ 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

Attempt to access the sample database without specifying the username

$ 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 

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

Video

(10 minutes, 15 seconds)


Business Cases: Using the Centrify IBM DB2 SSO Module to Centralize Database Access in UNIX/Linux with AD

Background


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
  1.  Collect the OS version, architecture, version of Centrify adclient.uname -a, adinfo -v and adinfo -C provide that information
  2.  Collect the DB2 database version, architecturethe db2level command provides this information
  3. 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.
$ dzdo rpm -Uvh centrifydc-db2-4.4.4-rhel3-x86_64.rpm
Preparing...                ########################################### [100%]
   1:CentrifyDC-web      ########################################### [100%]

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.

$ 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]: 3


Which data sent to DB2 should be encrypted?
[1] Nothing
[2] The username and their password
[3] All data going to the server
[4] Encrypt and compress all data going to the server
[5] Skip this step
Select a number from the menu [2]: 3


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


In order for the username/password plugin to work, the executable:
/usr/share/centrifydc/bin/db2userpass_checkpwd must be set uid and the
instance users must be allowed to run it.
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]:

Are the following PAM settings OK for the centrifydc_db2userpass PAM service?
These settings will only affect the Centrify DB2 username/password module.
No other PAM services or DB2 plugins will be affected.  If these settings are
not OK, then you will have to set up PAM yourself.

#%PAM-1.0
auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
auth       include      system-auth
account    required     pam_nologin.so
account    include      system-auth

Enter y for yes, n for no [y]: y

<output truncated>

The DB2 configuration will be updated to:
SRVCON_AUTH  =  DATA_ENCRYPT
SRVCON_PW_PLUGIN  =  centrifydc_db2userpass
LOCAL_GSSPLUGIN  =  NULL
SRVCON_GSSPLUGIN_LIST  =  NULL
AUTHENTICATION  =  SERVER
GROUP_PLUGIN  =  centrifydc_db2group

Continuing will stop the DB2 instance: db2inst1, update the configuration
and then start the instance.
Continue?
Enter y for yes, n for no [y]: y


Stopping instance: db2inst1
# db2stop
<output truncated>

New configuration:
 Group Plugin                             (GROUP_PLUGIN) = centrifydc_db2group
 GSS Plugin for Local Authorization    (LOCAL_GSSPLUGIN) =
 Server List of GSS Plugins      (SRVCON_GSSPLUGIN_LIST) =
 Server Userid-Password Plugin        (SRVCON_PW_PLUGIN) = centrifydc_db2userpass
 Server Connection Authentication          (SRVCON_AUTH) = DATA_ENCRYPT
 Database manager authentication        (AUTHENTICATION) = SERVER
Starting instance
# db2start

At this point DB2 has been configured for the user/password (PAM) and Group plugins and we’re ready to test.

Testing the User/Password & Group Plugins


In my environment I enabled the sample database.

Test 1:  Sign-in with any AD account that is allowed to log into the system

Open the sample database
$ db2
db2 => connect to sample user fred.thomas
Enter current password for fred.thomas:

   Database Connection Information

Database server        = DB2/LINUXX8664 10.5.0
SQL authorization ID   = FRED.THO...
Local database alias   = SAMPLE

Note that Fred’s user ID is longer than 8 characters

Test 2:  Enumerate group memberships.

First, use adquery user –A | grep MemberOf to see the group memberships in AD

$ adquery user fred.thomas -A | grep memberOf
memberOf:centrifyimage.vms/Groups/DBA Staff - Contract,centrifyimage.vms/Groups/Demo Users,centrifyimage.vms/Groups/Google Apps

Based on this output my user belongs to DBA Staff – Contract, Domain Users, Demo Users and Google Apps

Connect to DB2 again and type the query below

db2 => SELECT * FROM table (SYSPROC.AUTH_LIST_GROUPS_FOR_AUTHID (CURRENT USER)) AS ST

GROUP                                                                             
------------------------------------------------------
DBA STAFF - CONTRACT                                                                                
DEMO USERS                                                                                         
DOMAIN USERS                                                                                       
GOOGLE APPS  

At this point we have verified that DB2 can enumerate the user’s groups from Active Directory.

Where to next?


You can engage your DBAs to test this solution.  The benefits are huge for organizations that are looking to consolidate processes in AD.
A follow-up post will discuss the SSO (GSSAPI) plugin.


Video Playlist

(2 videos, 10:36 total)



Appendix

Installing DB2 Express – C on CentOS 6.x
  • DB2 Setup uses the X-Window system, if you don’t have it
    # yum groupinstall "Desktop" "X Window System" "Fonts" "Desktop Platform"
  • Disable SELinux  (this is a requirement of DB2)
    Set the following line in /etc/selinux/config

    SELINUX=disabled

    And reboot your system.
  • Setup DB2 in graphical interface(I set up a database instance with all defaults – remember the instance user password)
  • Install the sample database
          $ dzdo su –db2inst1
     $ db2sampl
  • Test connectivity to the sample database

    $ db2 connect to sample user db2inst1
    Enter current password for db2inst1:


    Database Connection Information
    Database server        = DB2/LINUXX8664 10.5.0
    SQL authorization ID   = DB2INST1
    Local database alias   = SAMPLE