Sunday, December 28, 2014

Business Cases - Web-Mobile SSO Planning Session II: Apps

Planning for Applications

When we plan for Applications (Web or Mobile), we need to think about different strategies.  These types of questions arise:
  • How will the application be published?  
    Centrify provides the user portal, however, depending on your environment, you may have an intranet or content management platform that is used as a hub for applications.
  • What is the policy to access these applications?
    Apps can have different assurance requirements.  Maybe certain portions of the HR app are for intranet-only access with step-up (or two-factor) authentication.  Maybe your Netsuite-based ERP should only be available from inside of the United States.
  • Who should be entitled to access each app?
    Your security team may want to grant access based role or job function.  Centrify User Suite uses AD or Cloud Directory principals for app visibility.
  • What are the authentication capabilities of the app?
    Modern (especially cloud-based apps) provide federation technologies (like SAML, etc) but legacy apps don't have those capabilities or aren't available in the current version.  Also (and unfortunately) not all apps may be looking at the corporate directory (e.g. AD) as the identity repository (which can enable Kerberos or NTLM).  CUS offers the flexibility of password-vaulting and replaying.
  • How is the application provisioning model?
    This topic impacts the bottom-line of the business because the timely deprovisioning of cloud apps can impact the billing depending on how the application provider is metering the usage of the application.  In addition, some apps need to have entitlements provisioned as well for the purposes of role-based access.
  • What is the strategy for on-premise apps?
    Are these apps accessible via an existing VPN infrastructure (e.g. CheckPoint, Cisco, Microsoft's DirectAccess or others) or will you make use of the Centrify App Gateway (VPN-less access)?
These are high-level categories, there are advanced topics like timeouts, attribute-mapping, provisioning of certificates for federation trust, etc; but we will cover each scenario individually.

We will start by publishing these Web applications:
  • On-premises SharePoint (as a shortcut)
  • On-premises Apache or Java-based apps (leveraging NTLM, Kerberos & ADFS-less WS-Fed apps)
  • Google Apps
  • Salesforce
  • Office365.
Later we'll move on to Mobile apps on the Google Play and Apple App Store.

Tuesday, December 16, 2014

Labs - Web-Mobile SSO Planning Session I Videos

The videos below correspond to the first planning session for the Web-Mobile SSO use cases.

Lab 1 - Centrify User Suite Branding and Domains



Lab 2a - Cloud Connectors and Active Directory Integration



Lab 2b - Cloud Connectors and Active Directory Integration



Lab 2c - Exploring the AD Integration using Centrify Cloud Connectors



Lab 2d -  Understanding Login Suffixes

Business Cases - Web-Mobile SSO Planning Session I - Global Settings

In a previous post, we discussed the requirements for the Web and Mobile SSO use case, and although our labs are aimed to help with testing or proofs of concepts, we typically address the planning.  Many of the topics in the requirements are huge (like o365 or GoogleApps migration), but we'll do the best we can to outline some of the key parts of planning.

Project Management and Methodology - the PMO would like to use the same methodology (DEV-QA to PROD) for this project.

What this means is that you need to have multiple cloud tenants a test and a production tenant.  Ideally, you will have a test environment that mimics your existing infrastructure.  My advice is that you use a rolling wave when it comes to IdaaS as well.  Scenarios like switching how people access your CRM (e.g. Salesforce) or ERP (e.g. Netsuite) can affect the bottom-line.  I won't be implementing this, but keep it in mind when implementing any cloud service.

Marketing - Branding and imaging should be maintained.

Organizations pay a lot of money to establish a brand identity;  your Cloud-based solutions should allow you to maintain that branding.  Centrify offers the ability to implement logos for the self-service portal, email invitations, mobile enrollment, etc. In addition, the main corporate color can be implemented as well.  This means that ahead of time you need to collect:
  • The Pantone color code for your organization (main color) for the portal ribbon
  • The corporate logo in several sizes:
    • 137x35 to be used as the login image
    • 160x36 to be used as the portal image

Business Requirement - The IT organization wants to shift capital expense (capex) to operational costs (opex)

From an accounting perspective, organizations prefer to shift costs to the capital expense category due to tax benefits;  in addition, clouds allow for commoditization of IT infrastructure services that in the traditional way would require space, power, cooling and personnel to support those solutions. The biggest example is email; HOWEVER, this has to be reconciled with security requirements.

Access to these applications has to be granted to Active Directory users, but there are instances in which partners need access as well (who won't have AD accounts).  

A lot is stated in this paragraph.  In the context of Centrify User Suite this means:
  • Deployment of Cloud Connectors (CC):  CCs are Windows computers that use the service bus to talk to the Centrify Cloud Service and internally to Active Directory.  They provide many capabilities, but the main one is the avoidance of explicit replication of data to the cloud. When planning for Cloud Connectors
    • Keep in mind the requirements:  As you add more users, keep in mind that the cloud connector's cache will grow.  At the time of this writing Cloud Connectors require a 64bit system with a multicore processor and 8GB of RAM with 4GB dedicated for the cache.
    • Availability requirements:  You need at least two cloud connectors for basic load-balancing and fail-over.  If you are in a multi-national organization, placement of the cloud connectors should be based on the data-center location in the cloud.
    • Internal placement:  Like any AD services, the closer you are to a global catalog domain controller the better.
    • If using the Microsoft CA, make sure that you place the cloud connector near an issuing CA.
    • Connectivity:  Although cloud connectors only perform OUTBOUND connections, there are certain domains that need to be reachable.  A list is here.
    • Active Directory permissions:  Although no changes will be made to AD (in terms of schema extensions or services) the computer running the cloud connector will be able to access AD.  Permissions are required for this operation.  The instructions are here.
    • Allowing MDM capabilities from Active Directory Users and Computers (ADUC) and Group Policy Management:  You must plan which administrators will provide helpdesk-assisted MDM capabilities using ADUC or which AD admins will be allowed to edit Mobile-related GPOs.
  • Use of the Centrify Cloud Directory:  In those instances in which third parties (contractors, partners) need access to internal apps, but can't have an AD accounts, this will be the preferred method.

These users may access using rich clients (browser) or mobile devices (iOS/Android browser and mobile apps);  connections can be centralized via a portal, directly initiated or via intranet shortcuts.  In the case of Office365, users will continue to use their full clients (Outlook, Lync, etc) on their Windows and Mac workstations.

This paragraph also contains major implications.
  • Mobile Access:  This means that corporate information may be accessed from devices that aren't under the control of IT.  Fortunately User Suite provides Mobile Device, Container and Application management for iOS and Android.
  • iOS:  Managing iOS devices means that an APNS certificate needs to be configured in the cloud service.  In addition, if apps are purchased by corporate or devices are running in kiosk mode
  • Portals, Direct Connections and Shortcuts:  Centrify provides the cloud portal for self-service of apps, mobile and AD/cloud directory; however it's possible that users may access apps directly, in that case, users will be redirected to be authenticated by Centrify if they don't have an active valid session.  Shortcuts can be deployed in the intranet as well.
  • The topic of Office 365 migration is huge, however, from a rich client perspective, this means that the lowest version of office has to be Office 2010 with the latest and greatest service packs.

Availability - As a global company, close to 100% uptime, geographical layout and redundancy are a most.

As of this writing, Centrify relies on a robust infrastructure (Microsoft Azure) to provide high performance, high availability and redundancy.  Stats on the availability of the service can be viewed at http://www.centrify.com/cloud/service-status.asp 

Disjointed Namespace - The solution should accommodate for a different domain (for AD) than the business name (Internet DNS name).  It uses corp.contoso.com internally, vs. centrifying.net outside.

This is very common;  typically the Active Directory suffix of the UPN (user principal name) is different than the DNS suffix commonly used to do business  (typically the suffix of the email address);  this means that a company may do business as na.ad.company.com;  but users of that region use @na.company.com as the common suffix.  Centrify User Suite provides settings to accommodate this scenario.

Monday, December 15, 2014

Cloud Lab # 0 - Signing-up for a Centrify Cloud Tenant

In a previous post, I discussed the capabilities of the Centrify Cloud Service.  Unfortunately this post will become obsolete because Centrify adds capabilities and tweaks the service every month, but as of December 2014 (v 14.10), here are the high-level capabilities:

To register for a Centrify cloud tenant you'll need an email address.  Follow these instructions:

  1. Go to http://www.centrify.com/lp/trial/centrify-solutions.asp and request a trial.  Alternatively, you can register for an Express account via www.centrify.com > Free Products > Centrify Express for SaaS > Request a Trial.  After 30 days, the premium features will be disabled.  Fill out the form:
  2. You will receive an email from Centrify on the email address specified. Click on the validation link:
  3. Upon validation you will be assigned a tenant ID.  Press the button to log in to Cloud Manager

    You will also receive an email with your initial credentials.
  4. When you attempt to log in to the cloud manager with your password, you'll be asked to provide an additional authentication method - since e-mail is the only option, you'll receive an email to your account, click on the link and you'll be signed in.
  5. Upon login, you'll be welcome by the configuration wizard.

What happens when a tenant is created?
The Centrify Cloud service runs in Microsoft Azure platform;  note that when the tenant was created, you had the chance to create your tenant in different places based on your region.  In the background, these tasks are created:

  • Multiple copies of the service and basic data are created inside the cloud (for redundancy)
  • Sets of different encryption keys are created (for encryption services)
  • An internal dedicated Certificate Authority is created.
  • The initial login suffix is created based on the user's email address.
  • The tenant is branded with Centrify's logo and colors.
This is obviously a simplified list, but it's important that they are understood for future posts.  This lab contains no videos.


Next-up:  Initial setup and customization.

Business Cases - Web/Mobile SSO Case Requirements

We will start a series focusing on the Centrify User Service and to give it the right context, just like we did a year ago with Server Suite we are basing this in a set of business requirements.


Here's a summary of the requirements:

Web and Mobile SSO
Our organization currently uses Salesforce, Office365, Google Apps, Sharepoint (internally), has Apache/Java (internally) and they need SSO;  some of these apps are SAML, WS-Fed, User/Password or may be using the Centrify on-premise app plugins.

Access to these applications has to be granted to Active Directory users, but there are instances in which partners need access as well (who won't have AD accounts).  These users may access using rich clients (browser) or mobile devices (iOS/Android browser and mobile apps);  connections can be centralized via a portal, directly initiated or via intranet shortcuts.  In the case of Office365, users will continue to use their full clients (Outlook, Lync, etc) on their Windows and Mac workstations.

Security Requirements
Confidentiality - no synchronization of personal identifiable information off premises; encryption in traffic and at rest is required.
Access Control - the security department wants to have the flexibility to set policies that allow to control access based on time/day, network or geographical location (to limit apps to be intranet accessible only, not via the web);
Step-up Auth - One-time-passwords (two-factor) should be an option for sensitive use cases.
Governance -   Entitlement management and separation of duties should be enforced.
Availability
Availability - As a global company, close to 100% uptime, geographical layout and redundancy are a most.

Infrastructure Requirements
Business Requirement - The IT organization wants to shift capital expense (capex) to operational costs (opex);
Self-Service - the solution should provide flexible self-service options to minimize calls to the help-desk.
Office 365 - all features (rich or web clients) should be supported, ideally without added infrastructure complexity.
Decrease VPN usage - ideally this solution should provide alternatives to VPNs for internal-only apps.
Disjointed Namespace - The solution should accommodate for a different domain (for AD) than the business name (Internet DNS name).  It uses corp.contoso.com internally, vs. centrifying.net outside.

Other Requirements
Project Management and Methodology - the PMO would like to use the same methodology (DEV-QA to PROD) for this project.
Marketing - Branding and imaging should be maintained.


Go to Planning Session I:  http://centrifying.blogspot.com/2014/12/business-cases-web-mobile-sso-planning.html

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