Basics: Centrify Support for Single Sign-on (SSO) on UNIX/Linux

Background

It seems that SSO or Single Sign-on means different things to different people:

• To some people, it means having a single-set of sign-on credentials across multiple systems regardless of the authentication experience.  I would call this unified credentials or unified identity.
• To others, SSO means silent sign-on, or authenticate once to a system, and then you don't have to authenticate again regardless of the systems that are accessed.
• Finally, some other people hear SSO and immediately they think about Web application SSO.

Garner has the following definition:

"Single sign-on (SSO) provides the capability to authenticate once, and be subsequently and automatically authenticated when accessing various target systems. It eliminates the need to separately authenticate and sign on to individual applications and systems, essentially serving as a user surrogate between client workstations and target systems. Target applications and systems still maintain their own credential stores and present sign-on prompts to client devices. Behind the scenes, SSO responds to those prompts and maps the credentials to a single login/password pair. SSO is commonly deployed in enterprise, Web and federated models."

This means that the best way to talk about SSO is to qualify it.  I like to look at it from the perspective of how its implemented.

• Direct Access:  In this case, there's a central directory, like Active Directory, that provides secure authentication services (like Kerberos) and the systems (e.g. like UNIX, Linux) or Services (like Apache, Tomcat, Java, etc) can provide authentication services directly, with minimal or no middleware required.  For example:  An Apache server can leverage shared objects and libraries to extend OS authentication services (like Kerberos) out to clients.
  I prefer this approach because requires next to zero infrastructure, processes, technology, etc. and the barrier of implementation relatively simple.
• Through Middleware:  In this case, we have servers, processes, people, technology that implement transformations, synchronizations, claims, transactions, capabilities, etc that provide SSO services.
  This method is very complex.

SSO Services Provided by Centrify for UNIX and Linux

Centrify provides SSO services to access to UNIX/Linux and Services (Web, Java, SAP, etc with plugins) with the user's Active Directory account leveraging Kerberos or the Generic Security Services Application Programming Interface (GSSAPI).  Here's an example:

Using Secure Shell (SSH)

1. A UNIX-enabled Active Directory user logs into their Windows computer
At this point, the user gets a ticket-granting ticket as part of the Kerberos process in Windows.  This can verified with the klist command:

#0>     Client: jessie.matthews @ CORP.CONTOSO.COM

        Server: krbtgt/CORP.CONTOSO.COM @ CORP.CONTOSO.COM

        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

        Ticket Flags 0x60a00000 -> forwardable forwarded <...>

        Start Time: 1/16/2014 23:03:42 (local)

        End Time:   1/17/2014 9:03:41 (local)

        Renew Time: 1/23/2014 23:03:41 (local)

        Session Key Type: AES-256-CTS-HMAC-SHA1-96

2. The user uses an SSH client that supports GSSAPI or Kerberos to access a Centrified UNIX/Linux host that is running a version of the SSH server that supports GSSAPI or Kerberos.

At this point, the Kerberos negotiation process obtains/validates a ticket to access the host.

On the server, the version supports GSSAPI and the option is enabled.

OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013

$ dzdo grep GSSAPIAuthentication /etc/ssh/sshd_config

GSSAPIAuthentication yes

When the Centrify software was installed, the Centrify shared libraries and PAM modules are put in place.  When the computer is joined to the domain, the Service Principal Names are registered for the system for example, here are the ones for CEN1:

Notice the host SPN

3. The user types in his username, and does not have to type the password and is securely authenticated.

After this successful login, here's the ticket for this host (notice the Server field that matches the SPN above)

#2>     Client: jessie.matthews @ CORP.CONTOSO.COM

        Server: host/cen1.corp.contoso.com @ CORP.CONTOSO.COM

        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

        Ticket Flags 0x40a00000 -> forwardable renewable <...>

        Start Time: 1/16/2014 23:05:10 (local)

        End Time:   1/17/2014 9:03:41 (local)

        Renew Time: 1/23/2014 23:03:41 (local)

        Session Key Type: AES-256-CTS-HMAC-SHA1-96

This is the same experience that someone that opens, let's say Microsoft Outlook, in their enterprise and is not prompted for a password.  Also, believe it or not, this happens in the back end when you access a file or printer share.  For example, everyone has to read the SYSVOL share of the domain controller.  Notice the CIFS ticket for DC1:

#3>     Client: jessie.matthews @ CORP.CONTOSO.COM

        Server: cifs/dc1.corp.contoso.com @ CORP.CONTOSO.COM

        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

        Ticket Flags 0x40a40000 -> forwardable renewable <...>

        Start Time: 1/16/2014 23:03:42 (local)

        End Time:   1/17/2014 9:03:41 (local)

        Renew Time: 1/23/2014 23:03:41 (local)

        Session Key Type: AES-256-CTS-HMAC-SHA1-96

From an SSH perspective, I am of the opinion that leveraging Kerberos or the GSSAPI is preferable than using user keys.  The former is tied to the user's identity and the latter introduces the risk of key management.

The topic of how Centrify offers services to Web and Java applications running on UNIX/Linux will be covered in future business problems, but for now, as discussed in the Kerberos post, there three common aspects:

1. An LDAP directory and a Kerberos environment (provided by AD)
2. Kerberized (or GSSAPI-compliant) services and clients
3. Centrify shared libraries.

Centrify also provides Kerberized client versions of Secure FTP, SMB, etc. as well as their own version of Kerberos tools.  For environments that have complex domain infrastructures like one-way trusts, Centrify provides their own enhanced version of OpenSSH, but it's not required to get these services.

When to use Centrify-enhanced OpenSSH

Centrify OpenSSH is a distribution of OpenSSH compiled with Centrify's Kerberos libraries, it's only required if you have a complex AD Domain infrastructure that scenarios like:

• One-way trusts
• Cross forest-trusts (External)

Centrify OpenSSH differs from stock SSH in that the name of the service, location of the binaries and config files are different.  As of version 2013.3, Centrify-OpenSSH is based on OpenSSH 6.2 P2.

Centrify PuTTY provides Kerberos authentication.