Centrify Identity Platform - Making Strides and Taking Names

Centrify Identity Platform consists of two products:  Identity Service and Privileged Service

Centrify Identity Service (formerly User Suite) has continued its meteoric rise and I want to congratulate many of my coworkers on their hard work and dedication.

In the past two weeks, to major publications have continued to highlight its critical acclaim:

• 2015 Gartner Magic Quadrant for Identity and Access Management as a Service
• Positions Centrify as a visionary, proving and validating the completeness of the vision that combines On-Prem/SaaS SSO with Enterprise Mobility Management plus robust policy, Multi-factor Authentication and VPN-less Access.
• Ranks #3 among the solutions in a year that saw Salesforce, IBM and Microsoft enter the market and continues to beat the leader in execution and completeness of vision (#2 in pure play).  It's only a matter of time given Centrify's leadership.
• This is all looking at data from last year!!!!  This is before App Gateway, Privileged Service, ServiceNOW integration and others were ready to go.
  Get the report here.
• Network World Names Centrify Identity Service the best SSO tool for 2015
• Calls out the integration of SSO+EMM+MFA+Management interface.  Everyone else left to eat the dust.

Centrify Privileged Service (CPS) is a new entry (announcement) to the hybrid family of products that has a pure play in two areas (and growing):  Shared Account Password Management (SAPM) and Secure Remote Access, but it builds on the existing capabilities of the Identity Service to deliver complementary capabilities to Server Suite.

RBAC continues to be the preferred method for Privileged Account Management (PAM), however, for emergency, one offs and change control, using a shared privileged account can be useful.  Here's a video that illustrates the differences between the approaches:

Capabilities of CPS

Shared Account Password Management

Use your AD account and Multi-factor authentication to check out UNIX, Linux or Windows accounts, enforce policy, access anywhere (centrally or via mobile app).  Upon check-out, the password is rotated for you.

Secure Remote Access

Leverage the existing cloud connector infrastructure to deliver secure remote access to resources regardless of their location (on premises or in the cloud IaaS).  

Apps, UNIX, Linux and Windows sessions can be presented to users in a cohesive way

Much more to come, and many synergies with Server Suite

Very exciting time to be at Centrify and especially to help out prospects and existing customers.

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.