In the almost two years of Centrifying we have discussed Identity Consolidation with AD and Single Sign-on at length. 90% of organizations have Active Directory but sometimes over-complicate things when it comes to identity consolidation and SSO.
I had the chance to speak about this in a seminar and these two videos consolidate many entries that we've covered in this blog over the years.
Direct Integration
Name Service Switch, Pluggable Authentication Modules, GSSAPI, Kerberos and Proxies
OpenSSH SSO over an outgoing external non-transitive AD one-way trust
NSS and PAM using Oracle DB as an example (externally identified user)
The idea is to eliminate complexity and promote reuse by committing to Active Directory, let the Centrify DirectControl agent do the heavy-lifting for Direct Integration and use the SPNEGO plugins when needed.
For the full briefing, including marketing slideware go here.
Active Directory provides a Public Key Infrastructure (PKI) capability with the Microsoft Certificate Authority. This is quite convenient to system administrators especially when combined with Group Policy since it allows for the automation of the Certificate lifecycle: issue, renew, revoke, supersede templates, etc.
We've discussed this before, but Centrified clients can also take advantage of Certificate auto-enrollment. This can happen automatically or manually using the adcert utility.
How it works?
The process works as follows:
When a system is joined to AD using Centrify, as part of the join the system will read the domain controller's SYSVOL for Group Policies. The system may download the trust chain (containing the trusted CAs or the local root CA) and any revocation information to the /var/centrify/net/certs folder.
If the auto-enrollment policy that applies to the system points to a usable template, the agent will attempt to enroll automatically when the GPO refresh interval starts. Note: there are different auto-enrollment GPOs depending on the version of Active Directory.
The agent will use the computer's credentials with the adcert utility and connect to the CA or Intermediate CA to obtain a certificate set for autoenrollment.
adcert will issue pkcs10 request for each template, if an issuing CA is found for the templates in question and the certificates, chain and private key (if defined exportable by the template) will be placed in the /var/centrify/net/certs folder with this format: [name of template].cert [name of template].key [name of template].chain
Once the certificate is in your system, you may be able to use it as is, or you may have to change the encoding using OpenSSL tools.
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.
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
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.
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:
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:
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
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
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.
Make sure the Apache home page (if enabled) is accessible from the Windows client.
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.
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
Sign-in to a Windows client that is a member of your AD Domain
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!
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.
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:
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
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)
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.
