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.

•  Obtain the DB2 Express – C tarball from IBM
• Instructions: 
• Download link:  https://iwm.dhe.ibm.com/sdfdl/v2/regs2/db2pmopn/db2_v105/expc/Xa.2/Xb.aA_60_-idYiE_CQBnqJLzJNYLjR0g-_KdoeQpLzhdQ/Xc.db2_v105/expc/v10.5_linuxx64_expc.tar.gz/Xd./Xf.LPr.D1vk/Xg.7824906/Xi.swg-db2expressc/XY.regsrvs/XZ.oJ6tKMnlRFf0PQrahFUZYxkXjBg/v10.5_linuxx64_expc.tar.gz
  
  $ tar xzvf v10.5_linuxx64_expc.tar.gz$ cd expc$ ./db2prereqcheck$ ./db2_install (will launch the Java-based Setup Wizard on X Window)

• 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

Business Cases: Centrifying Java Application Servers to provide on premises AD-based SSO and Authorization

Background

Java application servers like JBOSS, Tomcat, WebSphere and WebLogic are pervasive in large enterprises.  So is Active Directory.  Just like with Apache HTTP, Centrify customers can leverage the tight AD integration in UNIX and Linux platforms and great support for the Windows platform as well. 

We covered the benefits during the Apache HTTP SSO discussion, and the principles are the same.
This post covers how to install the Java SSO module using Apache Tomcat as an example.

Requirements

• A Centrified Unix/Linux system running Apache Tomcat (Tomcat6 in this example)alternatively, you can follow on JBOSS, WebSphere or WebLogic as well.  The system should be joined to a domain either in zone or workstation mode.
•  Apache Tomcat running and accesible
• A domain-joined PC system (or a centrified Mac) to test access from an authenticated Windows system  with a web browser (SPNEGO is not available on Safari)

Implementation Steps

Information gathering

1.            Collect the OS version, architecture, version of Centrify adclient and if an SPN for HTTP is registered
uname -a, adinfo -v and adinfo -C | grep http provide that information

2.            Collect the service status, version, architecture and java version.
“service tomcat(x) status, rpm –qa | grep tomcat and java-versiont” should provide this.

3.            Make sure the Tomcat home page (if enabled) is accessible from the Windows client.

4.            Obtain the proper version of the J2EE SSO plugin from the Centrify Customer Support Center.
Based on the information from steps 1 and 2, you can select which package to download. For example, in my CentOS 6.x, 64bit, Tomcat6

$ 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

$ java -version

java version "1.7.0_71"

OpenJDK Runtime Environment (rhel-2.5.3.1.el6-x86_64 u71-b14)

OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)

$ adinfo -v

adinfo (CentrifyDC 5.2.0-218)

$ adinfo -C | grep http

$ dzdo adinfo -C | grep http

                           http/engcen8.centrifyimage.vms

                           http/engcen8

[dwirth@engcen8 lib]$ rpm -qa | grep tomcat

tomcat6-6.0.24-80.el6.x86_64

It looks like my service is running and that is a 64 bit CentOS with Tomcat 6 based on this information,  I will download the package " DirectControl for J2EE App Servers on RHEL 4, 5, 6, Fedora 14, 15, 16, 17 x86_64 " the version is 4.4.4 as of the original post in November 2014.

Installation

Unpack and install the SSO plugin

$ tar xzvf centrify-web-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-web-4.4.4-rhel3-x86_64.rpm

Preparing...                ########################################### [100%]

   1:CentrifyDC-web      ########################################### [100%]

Configuration of the Java Server and Sample Application

Centrify provides a script that allows for the configuration of JBoss, Tomcat, Websphere and Weblogic.  These servers can run on Microsoft Windows, so there are versions of the plugin for those platforms too.  The script is in /usr/share/centrifydc/java/web and it’s called configure.pl.  All you need to do is follow the prompts to configure Tomcat (options 1-3) and ignore everything about ADFS or certificates at this time.

# /configure.pl

=====================================================================

Welcome to Centrify DirectControl for J2EE Servers Configuration.

 At any prompt, enter ? for help, or return to accept the default value (shown in brackets []).

Please select what type of J2EE server to configure:

[0] Tomcat.

[1] JBoss.

[2] WebLogic Server.

[3] WebSphere Application Server.

[4] Exit this configuration program.

Enter selection:

[0] > 0

===== Configure Tomcat Server for Centrify =====

[0] Run full configuration (all options below).

[1] Copy Centrify jar files to Tomcat server.

[2] Configure Tomcat Server for Centrify.

[3] Setup and deploy Centrify samples.

[4] Configure Tomcat for SSL.

[5] Exit this script

[0] > 1

 === Copy Centrify jar files to Tomcat server ===

Enter the directory where Tomcat Server is installed:

[/usr/share/tomcat6] >

Enter the directory where Java SDK is installed:

[/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.33.x86_64] >

Enter the Tomcat Server version (7.0.x, 6.0.x, 5.5.x or 5.0.x):

[6.0.x] >

You have entered the following:

Tomcat Server directory = /usr/share/tomcat6

Java SDK directory = /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.33.x86_64

Tomcat Server version = 6.0.x

Is this correct (y/n) ?

[y] > y

Copying /usr/share/centrifydc/java/web/scripts/tomcat/centrifydc_jaas.config to /usr/share/tomcat6/c

<...>

===== Configure Tomcat Server for Centrify =====

[0] Run full configuration (all options below).

[1] Copy Centrify jar files to Tomcat server.

[2] Configure Tomcat Server for Centrify.

[3] Setup and deploy Centrify samples.

[4] Configure Tomcat for SSL.

[5] Exit this script

Enter selection:

[0] > 3

=== Copy Centrify jar files to Tomcat server ===

Enter the directory where Tomcat Server is installed:

[/usr/share/tomcat6] >

Enter the directory where Java SDK is installed:

[/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.33.x86_64] >

Enter the Tomcat Server version (7.0.x, 6.0.x, 5.5.x or 5.0.x):

[6.0.x] >

You have entered the following:

Tomcat Server directory = /usr/share/tomcat6

Java SDK directory = /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.33.x86_64

Tomcat Server version = 6.0.x

Is this correct (y/n) ? y

<...>

===== Configure Tomcat Server for Centrify =====

[0] Run full configuration (all options below).

[1] Copy Centrify jar files to Tomcat server.

[2] Configure Tomcat Server for Centrify.

[3] Setup and deploy Centrify samples.

[4] Configure Tomcat for SSL.

[5] Exit this script

Enter selection:

[0] > 3

=== Setup and deploy Centrify samples ===

Enter the directory where Tomcat Server is installed:

[/usr/share/tomcat6] >

Enter the directory where Java SDK is installed:

[/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.33.x86_64] >

Enter the Tomcat Server version (7.0.x, 6.0.x, 5.5.x or 5.0.x):

[6.0.x] >

You have entered the following:

Tomcat Server directory = /usr/share/tomcat6

Java SDK directory = /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.33.x86_64

Tomcat Server version = 6.0.x

Is this correct (y/n) ?

[y] > y

Do you want to setup the Centrify ADFS samples now (y/n) ?

(You must have the ADFS server's hostname and SSL port to setup the ADFS samples.)

[n] >

Verify that everything is working as expected

1.            Sign-in to a Windows client that is a member of your AD Domain

2.            Clear your Kerberos ticket cache by opening a command line and typing "klist purge"
C:\Users\dwirth>klist purge
Current LogonId is 0:0x9bb0d
Deleting all tickets:Ticket(s) purged!

3.            Open Internet Explorer and go to Internet Options > Security > Local Intranet > Sites > Advanced and make sure that your browser has the FQDN or the suffix of the SPN for HTTP registered by the server.
If using Firefox, go to about:config and search for network.automatic-ntlm-auth.trusted-uris, add the SPNs suffix or FQDN there.

4.            Go browse to http://<your-server>/centrifydc-samples.  This will expose the Centrify Sample pages.  Click on Kerberos.  If everything is correct, you should be able to see output that looks like this:

5. Now if you inspect your kerberos ticket cache, you'll something like this (truncated):
   C:\Users\dwirth>klist
   Current LogonId is 0:0x9bb0d
   #0>     Client: DWirth @ CENTRIFYIMAGE.VMS
   Server: krbtgt/CENTRIFYIMAGE.VMS @ CENTRIFYIMAGE.VMS
   
   #1>     Client: DWirth @ CENTRIFYIMAGE.VMSServer: HTTP/engcen8.centrifyimage.vms @ CENTRIFYIMAGE.VMS

Ticket # 0 is a Kerberos TGT and #1 is a service ticket that was requested by Diana to access the Apache HTTP service on engcen8.

Using the Java Plugin

The Java plugin has exposed the methods to leverage AD authentication via Centrify.  For example, the web.xml file of a server may add directives like these:

<login-config>

     <auth-method>SPNEGO</auth-method>

     <realm-name>CENTRIFYDC</realm-name>
</login-config> 

The Centrify Java Guide, explains to J2EE Web Admins and developers how to use these directives and methods.

Video Playlist

(7 minutes total)

Business Cases: Centrifying Apache HTTP Server to provide on premises AD-based SSO and Authorization

Background

Apache is the de facto Web Server for many apps and organizations have  the challenge of providing access to enterprise users that are very likely coming with Active Directory credentials;  not an issue for Centrify customers because fortunately, every centrified Unix/Linux  system has a single, secure connection to AD.

This approach results in centralized administration, streamlined authentication, policy enforcement and role-based access controls (privileged management) and since the underlying technology simplified  AD connectivity by leveraging native features and topologies (sites and services, global catalogs, subnets, one-way or cross-forest trusts, DC telemetry and caching)

In order to extend these benefits to web apps, Centrify offers the Apache HTTP SSO plugin that natively extends the authentication mechanisms of Apache to provide SPNEGO via the GSSAPI; the result is having the capability of Windows Integrated Authentication in UNIX/Linux-based Apache servers.

Translation: SSO via Kerberos or NTLM, authorization based on AD principals and the exposure of AD-attributes via native Apache APIs.  This post covers how to install the Apache plugin on a centrified server, how to get the sample application up and running, and how to incorporate it to existing Apache sites (we'll use phpPgAdmin as an example).

What is SPNEGO?

SPNEGO stands for "simple and protected GSSAPI negotiation mechanism" microsoft likes to call it IWA (Integrated Windows Authentication) and basically enables the capability for a browser to negotiate the authentication mechanism based on capabilities.  If configured correctly, the browser will attempt to use Kerberos, downgrade to NTLM if not possible fall back to basic authentication.   This means that for any Authenticated AD session, provided the browser is configured correctly the user will get SSO, otherwise they will get challeged via NTLM.

What you'll need

• A Centrified Unix/Linux system running Apache
  Joined to the domain either in zone or workstation mode.
• Apache HTTP server running
  You need to know the version and architecture to obtain the right version.
• A domain joined PC system to test access from an authenticated Windows system (or a centrified Mac) with a web browser (SPNEGO is not available on Safari)

Implementation Steps

Information gathering

1. Collect the OS version, architecture, version of Centrify adclient and if an SPN for HTTP is registered
   uname -a, adinfo -v and adinfo -C | grep http provide that information
2. Collect the service status, version, architecture and if dynamically loaded modules are enabled.
   httpd -V and httpd -l (look for mod_so.c) provide this info.
3. Make sure the Apache home page (if enabled) is accessible from the Windows client.
4. Obtain the proper version of the Apache HTTP SSO plugin from the Centrify Customer Support Center.
   Based on the information from steps 1 and 2, you can select which package to download. For example, in my CentOS 6.x, 64bit, Apache 2.2
   
   
   $ uname -a
   Linux cen3.corp.contoso.com 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)

   $ adinfo -C | grep http
   

                              http/cen3.corp.contoso.com

                              http/cen3

   $ dzdo service httpd statushttpd (pid  2811) is running...

   $ httpd -V

   Server version: Apache/2.2.15 (Unix)

   Architecture:   64-bit

   $ httpd -l | grep mod_so.c

     mod_so.c
   
   It looks like my server is running CentOS 6.x and Centrify 5.2;  the SPN for HTTP is cen3.corp.contoso.com. As far as Apache goes it is a 64 bit Apache 2.2.  Based on this information,  I will download the package "DirectControl for Apache HTTP Server on RHEL 4, 5, 6, Fedora 14, 15, 16, 17 x86_64" the version is 4.4.3 as of the original post in November 2014.  

Installation

Unpack and install the SSO plugin

$ tar xzvf centrify-apache-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-apache-4.4.4-rhel3-x86_64.rpm

Preparing...                ########################################### [100%]

   1:CentrifyDC-apache      ########################################### [100%]

Configuration of the Sample Application

Centrify provides a working sample app that can be used to see how to use the directives of the plugin.  To enable it, just include the path to the corresponding config file in the /etc/httpd/conf/httpd.conf file.  The sample app is in /usr/share/centrifydc/apache/samples and since I'm running Apache 2.2.x 64 bit, all I need to do is add this line 

Include /usr/share/centrifydc/apache/samples/conf/centrify22_64.conf

and restart the Web Server.

$ dzdo vi /etc/httpd/conf/httpd.conf    

==>then 'G' to go to the end and 'o'' to insert a line

# Include of Centrify Samples

Include /usr/share/centrifydc/apache/samples/conf/centrify22_64.conf  

==>Then <ESC> wq! to save

$ dzdo service httpd restart

Stopping httpd:                                            [  OK  ]

Starting httpd:                                            [  OK  ]

Verify that all is working as expected

1. Sign-in to a Windows client that is a member of your AD Domain
2. Clear your Kerberos ticket cache by opening a command line and typing "klist purge"
   C:\Users\jerry.seinfeld>klist purge
   Current LogonId is 0:0x9bb0dDeleting all tickets:Ticket(s) purged!
3. Open Internet Explorer and go to Internet Options > Security > Local Intranet > Sites > Advanced and make sure that your browser has the FQDN or the suffix of the SPN for HTTP registered by the server.
   If using Firefox, go to about:config and search for network.automatic-ntlm-auth.trusted-uris, add the SPNs suffix or FQDN there.
4. Go browse to http://<your-server>/samples.  This will expose the Centrify Sample pages.  Click on Kerberos.  If everything is correct, you should be able to see output that looks like this:
   
5. Now if you inspect your kerberos ticket cache, you'll something like this (truncated):
   C:\Users\jerry.seinfeld>klist
   Current LogonId is 0:0x9bb0d
   #0>     Client: jerry.seinfeld @ CORP.CONTOSO.COM
           Server: krbtgt/CORP.CONTOSO.COM @ CORP.CONTOSO.COM
   
   #1>     Client: jerry.seinfeld @ CORP.CONTOSO.COM
          Server: HTTP/cen3.corp.contoso.com @ CORP.CONTOSO.COM

Ticket # 0 is a Kerberos TGT and #1 is a service ticket that was requested by Jerry to access the Apache HTTP service on CEN3.

From a domain-joined computer, as it's configured by default, any valid AD user should have access. The directives to add to your Apache web sites is as follows:

 AuthType           CENTRIFYDC    # This directive enables the Centrify Plugin for the Site.

    EnableBasicAuth    true               # This directive enables Basic Auth (use only with SSL)

    EnableNtlmAuth     true               # This directive enables NTLM authentication

    EnableKerberosAuth true           # This directive enables Kerberos authentication

    Require            valid-user             # This directive controls authorization. Valid user is any AD authenticated user.

The require directive can be used for AD-based authorization, For example, if I want to only allow the members of the "Demo Users"  AD group, the Require will look like this:

Require group "Demo Users"

Plugin in Action - phpPgAdmin

In this example, we'll use the Apache SSO Plugin to AD-enable the phpPgAdmin app.  phpPgAdmin provides a web interface to manage PostgreSQL.  To install it  (e.g. in CentOS 6.x)

Add the repository

$ wget http://yum.postgresql.org/9.1/redhat/rhel-6.3-x86_64/pgdg-centos91-9.1-4.noarch.rpm

$ rpm -Uvh pgdg-centos91-9.1-4.noarch.rpm

Install the app

$ dzdo yum install phpPgAdmin

Configure the App to accept local connections

Edit the /etc/httpd/conf.d/phpPgAdmin.conf for example:

allow all from 10.0.0.0

Restart the Web Server

$ dzdo service centrifydc restart

Verify Access by browsing to your server in the /phpPgAdmin virtual directory:

To enable access with the Centrify plugin, just add the directives below inside the Location stanza of the /etc/httpd/conf.d/phpPgAdmin.conf file.  In this case we are limiting access based on membership on the Demo Users AD group.

 AuthType           CENTRIFYDC  

    EnableBasicAuth    true              

    EnableNtlmAuth     true               

    EnableKerberosAuth true           

    Require group "Demo Users"

Don't forget to restart the Apache Server!!!

Video Playlist

(11 minutes, 30 seconds total)

Security Corner: Centrify and SANS Critical Security Controls - A Near Perfect Fit (4/5)

This is part 4 of the series on leveraging Centrify to implement SANS Critical Security controls - Section 12: "Controlled use of Administrative Privileges".  (Also relates to PCI DSS 10.2)

CSC 12-11

Configure systems to issue a log entry and alert when unsuccessful login to an administrative account is attempted.

Why should you do this?
This is a detective control.  You can't control what you're not tracking.  Security operations typically leverage log aggregation technologies that tap into the native OS log facilities and centralize all this information into a centralized logging infrastructure that may or may not offer intelligence.

What is the typical approach?
On Windows:  Harvest and mine of the Windows event logs.  Surprisingly, a lot of outfits are not auditing the logon/log-off success/failure events.
On UNIX:  Harvest and mine the UNIX syslogs.

What is the real challenge for organizations?
Data vs. Noise.   How can organizations reconcile all the sources of data into meaningful information?  This is not Centrify's main capability, but it can certainly help by requiring meaningful data (e.g. change control/authorization numbers) and if all logs fail, there's always the session capture/replay capability.

Centrify's enhancers:

• Use what's native:  Uses syslog and event logs.  Unix logon/logoff success or failure are logged in the security log of the domain controller if configured by the Windows sysadmin.
• Enhance to differentiate the data from the noise:  Centrify can be configured to require reference information upon elevation, for example, change control number.
• Contextualize with DirectAudit to "clear the noise":  Enterprise Edition offers session capture and replay for both UNIX, Linux and Windows.
• Adding DirectAudit (Enterprise Edition) exceeds the requirements of PCI DSS 10.2 "reconstruct events"

Have a look:

How privileged elevation is logged (syslog) and recorded with Centrify on UNIX:

How with the Centrify dzdo validator, you can add more meaningful data to privilege elevation

How privileged elevation is logged (eventlog) and recorded with Centrify on Windows:

Security Corner: Centrify and SANS Critical Security Controls - A Near Perfect Fit (3/5)

This is part 3 of the series on leveraging Centrify to implement SANS Critical Security controls - Section 12: "Controlled use of Administrative Privileges".

CSC 12-7

Utilize access control lists to ensure that administrative accounts are used only for system administration activities, and not for reading e-mail, composing documents, or surfing the Internet. Web browsers and e-mail clients especially must be configured to never run as administrator.

Why should you do this?
To limit the exposure of administrative accounts to malware.

What is the typical approach?
On Windows:  Two sets of accounts are given to administrators,  a "dash-a" account and a normal account.  On the server side, to access the internet there's an air gap or the proxy server does not allow the servers or the "dash-a" account to go out to the internet.  The IE Enhanced Security mode is enforced.

On UNIX:  Systems are crippled from internet access or GUIs.  The email/surfing computer is different from the server systems.

What is the real challenge for organizations?
Human nature - people find ways to go around this, especially in the process of doing their actual jobs.  In the times of "knowledge on demand" having an internet browser to consult FAQs and community boards is very common.

Centrify's enhancers:
It's not all about just giving separate accounts, but being able to establish additional controls, like scope of systems, types of roles, privilege effectiveness, logon experience and flexible assignments.

CSC 12-10

Configure systems to issue a log entry and alert when an account is added to or removed from a domain administrators' group, or when a new local administrator account is added on a system.

Why should you do this?
At basic level this is a detective control, all administrative access should be traced back to an approval, otherwise this is misuse or a data-breach.

What is the typical approach?
Log aggregation.  Logs from multiple systems are sent to an enterprise security operations dashboard.

What is the real challenge for organizations?
Log aggregation lends itself for NOISE, then the log aggregation needs to be complemented by a data mining engine;  this is all to make sure that what's happening out there is authorized.

Centrify's enhancers:

• A Centrify deployment limits the local root or administrator account to break-glass situations.  They are not needed.
• Centrify (without any modification) augments log aggregation.  Therefore, the existing collection mechanisms can have richer data.
• Plus, Centrify reporting shows you what are the AD principals that grant the administrative roles, if things are tied to a Workflow or an IDM, anything that is not there by way of approvals will be identified quickly or rolled back.
• Plus Centrify DirectAudit provides the ability to view or audit who makes changes to the governance model.

Short video:

Basics: Centrify User Suite

Background

Centrify has two product lines.  Server Suite and User suite. With the release of Suite 2014.1, we are starting to see some synergy between product lines and since the blog has focused exclusively on server suite, we figured we need to expand, but first, let's explore this product.

What is Centrify User Suite?

Well, let's see:

• It's a cloud-based Identity Provider
• It provides access and SSO to on premise and cloud apps
• Provides Mobile Device, Application and Container Management
• It provides self-service capabilities (device enrollment, management, self-service password reset)
• Provides a catalog of over 2500 templates for fast publishing of Web, SaaS (SAML, WS-Fed, etc) and Mobile Apps.
• Provides Multi-factor Authentication
• Provides AD-based, Cloud-based or Mixed Identity
• Works with Active Directory in a non-intrusive (no directory duplication) and secure way
• Provides a policy engine for the directory
• Provides Role-Based Access for Application access and Privilege Management
• Provides multi-geography, shared or dedicated hosting
• Provides an interface that
• Provides access in rich (web) and mobile clients
• Provides tenants with their own publicly-rooted certification authority
• Provides access to apps can be via a self-service portal (provider-initiated) or application initiated.
• Extensible by way of an SDK, customizations and branding.
• Recognized by Gartner as a visionary in the 2014 IDaaS MQ.
• Continues to add capabilities at a near monthly rate

Where's the value?

In my opinion, the biggest value of user suite is that in the same spirit of server suite, for any organization with AD, provides the fastest, most efficient and secure way to adopt SaaS applications, it does it without breaking the bank and without aspiring to become the organization's directory of record.  The mobile, directory and hybrid identity and policy services are the cherry on top.

Here's what you don't need to do with user suite:

• Deal with servers in the DMZ
• Deal with understanding on premise federation technologies
• Deal with understanding app authentication or federation patterns
• Deal with publicly rooted certificates
• Pay for expensive MDM solutions
• Pay for 2-factor authentication solutions
• Worry about geographically located solutions
• Worry about language and branding
• Worry about having a split strategy for mobile devices

This translates to tighter control, time to market, added capabilities, etc.

What you must know and have:

• What are the different Cloud IdPs and their pros and cons.
• A policy for cloud-based access controls
• A plan for service availability

We'll explore topics related to cloud in Security Corner.

User Suite Tour

Labs and User Suite

Updated labs logo

We will keep things practical expect a lot of labs, howto's, etc.  We will be using Office365, Google Apps and Salesforce as our key apps given that they either provide a free or cheap version.  As we can find trial apps we will explore them.  As it relates to mobile, we will use iOS, Android and OS X.