Centrify 2017.3 - Container Linux by CoreOS is now supported

In this article, we'll discuss Centrify's support for Container Linux by CoreOS introduced with 2017.3 (5.4.3).  This is based on an article I wrote for the Centrify Community.

About Container Linux by CoreOS
"Container Linux by CoreOS (formerly CoreOS Linux) is an open-source lightweight operating system based on the Linux kernel and designed for providing infrastructure to clustered deployments, while focusing on automation, ease of application deployment, security, reliability and scalability. As an operating system, Container Linux provides only the minimal functionality required for deploying applications inside software containers, together with built-in mechanisms for service discovery and configuration sharing." - Source: Wikipedia.

Engineering Challenges
We had to overcome some challenges based on how Container Linux is architected.

• No package manager (required to deploy our solutions).
• Read-only /usr filesystem (Centrify usually installs under /usr/share/centrifydc and audit under /usr/share/centrifyda).
• No Perl (required by group policy and other utilities).
• Kernel not compiled with auditd support (required for file/monitoring).

Needless to say, our Engineering team was up to the task and was able to provide a solution that enabled our capabilities and maintained the ease-of-use that is common with Centrify solutions.

Solution

• Centrify provides an installation tarball with the 2017.3 agent bundle that includes Access and Audit components.
  
• A special version of the install.sh utility will allow for interactive or automatic installations.
• Centrify software is installed in the /opt/centrify folder.
• Limitations:  Express mode, deployment manager installation and monitoring service are not available.

Features
Host-Based Security

• Increased accountability - Container Linux users can sign-in with their Active Directory account.  We provide identity assurance with Multi-Factor Authentication.
  In AWS deployments, organizations don't need to rely on the shared SSH Key-based credential called "core"
• Centralized administration - Organizations don't have to duplicate effort and continue to leverage Active Directory as the directory of record.  No modifications required.
• Identity Management - Leverage Centrify zones to maintain a consistent UNIX namespace.
  You can leverage AD groups to control the memberships in the docker secondary UNIX group.
• Role-based Access Control - Use Centrify zones to control who can access a system, and what commands can be run with privilege.  For example:
  • You can create a role that defines who can elevate to root or the core accounts.
  • You can use Active Directory group membership to define who is a member of the docker(233) secondary group.
  • You can define very granular docker commands that can be granted to minimize risk or enforce separation of duties.
• Attestation and Security Operations -  Leverage Centrify Reports to facilitate attestation and Centrify Audit Trail to enrich security operations.
• Advanced Auditing -  Enjoy audit trail events as well as session capture and replay. 
• Extend host-based security to Linux Containers (LXC) - Centrify "bridges" capabilities to Linux Containers to enjoy the same level of accountability at the container level.

Vault-Based Security 

• Shared Account Password Management - if you need to use shared credentials, use the Centrify Privilege Service vault and enjoy the deployment flexibility and traditional password-related controls.
• Secure Access -  privilege Service connector infrastructure allows for Web, Native or SSH jumpbox client access regardless of on-premises or IaaS deployments. 
• Session Proctoring, termination and recording - Enjoy the benefits of session control as well as auditing without the need to add local capabilities.

Videos - Centrify + Container Linux in action

What's different in Container Linux

Host-based  Access Control, Identity Assurance and Role-Based Privilege Management
 
Vault-based Access Control, Shared Accounts and Secure Access

Using Role-based Access Control to manage and establish accountability for Docker operations


Centrify and Linux Containers (LXC)

[Labs] Centrify's SSH Gateway Explored - On Premises, AWS, Azure and GCP

This article illustrates the steps to set-up a lab to test the SSH Gateway capability of Infrastructure Service.  This capability provides secure access to on premises or IaaS (AWS, Azure or Google Cloud Platform) systems leveraging the Secure Shell protocol (SSH+File Transfer).

Background
Centrify Infrastructure Services provides a full-fledged secure shell and file transfer capability (SSH Gateway).  This "jumpbox"  supports all the core features of the platform including multi-factor authentication, workflow, real-time monitoring and session capture and replay.

Goals of this Lab

• Identity Consolidation:
  • Leverage existing Organizational Directory Services.
  • Accomodate for user populations outside the organization (e.g. Federation, other Directories, etc).
• Usability:  Provide secure access to systems running the SSH Service without visiting the Centrify portal.
• Access Control:  Align with best practices for security access controls, like:
  • Identity Assurance via Multi-factor Authentication.
  • Adherence to the Least Privilege principle  (users shall only access systems and accounts that they have a business need to access).
• Auditability:
  • Event tracking (who, what, when).
  • Allow the real-time proctoring of shell sessions as well as the session recording to be replayed later (e.g. PCI DSS 10.2.2).
• Simplicity and multi-use:  Provide these capabilities with minimal infrastructure or to reuse components of Centrify Infrastructure Service (E.g. leverage other services like AD or LDAP Proxy, or RDP jumpbox services).

Requirements

• A Centrify Infrastructure Services instance (SaaS or Customer Managed) - 17.10 and above.
• A Centrify Connector running the SSH gateway in all the subnets required for SSH jumpbox access.
• A handful of test systems running the SSH Service.
• SSH and sFTP client software.
• If testing "true MFA": An OATH OTP, configured RADIUS token or enrolled Mobile Authenticator.
• Familiarity with Centrify Infrastructure Services.
  • Policy and Authentication Profiles.
  • A configured "Corporate IP Range." 
  • Familiarity with CPS Roles, Permissions and Sets.
• Understanding of the communication paths for CPS (e.g. between connector and instance (HTTPS), between connector and SSH Servers (standard SSH port TCP 22).  Note that these ports are customizable.
• Understading of Infrastructure Services Role-based Access Control.

Conceptual Diagram


This diagram showcases the major components, the location, firewall rules, and additional details depend on the environment.

Diagram for this Lab


High-level Implementation Steps
AWS

• In this implementation, I'm using an AWS VPC as my "corporate HQ"  it has an AD domain, some systems (Windows and Linux) as well as a hosted AD domain.  This will allow me to have different user populations.
• I am leveraging an existing Active Directory and DirectAudit infrastructure.
• Launched a Windows 2012 R2 instance with a public IP address, Fthis instance is in a security group,  that allows inbound HTTPS and SSH from the internet to the instance, plus it can reach the rest of the systems internally, including AD (to allow for it to be joined).
• For internet name resolution, I created a CNAME record in the rpdemo.net DNS domain for the cps record that resolves to the public DNS name for the EC2 instance above
• Obtained a publicly rooted certificate, and exported it with the private key for Privilege Service to use.
• Installed Privilege Service (on-premises) in single-master mode (no HA);
  Note:  The single-master configuration does not provide HA or allows for upgrades.  This is for testing purposes only.
• Added a Centrify connector with the adproxy and SSH gateway services.
• Configured Privilege Service to use my ISP's IP address as part of the corporate IP range.  This is to provide the assurance that only I can access it.
• Configured 2 roles:  An Administrator, and a Least Access role.
• Configured Workflow for the resources.

Microsoft Azure

• Created inbound rules that allow the connector in AWS to reach the systems over RDP and SSH.
  Note: Depending on the services needed, an additional connector in Azure (or GCP) is needed.
• Launched existing Windows and Linux systems.

Test Matrix (Success Criteria)

Category	Description	Result
Identity Consolidation	Users from Active Directory and Centrify Directory can access systems via Web Portal or SSH Gateway.	Pass
Identity Assurance with MFA	Users must use an MFA or Step-up method to authenticate via Web portal or SSH Gateway.	Pass
Policy	Users can only access from a specific subnet.	Pass
Least Access	Users can only access the systems based on business need to know via Web Portal or SSH Gateway.	Pass
Access Request	Users must request temporary access to shared accounts.	Pass
Monitoring (real time)	SSH/RDP – Sessions can be monitored in real time. SFTP – Active sessions can be tracked.	Pass
Advanced Auditing	Sessions can be reviewed after the fact (indexing, replay, etc.)	Pass
Infrastructure Simplicity and Reuse	The same components can be used for other capabilities (e.g. RDP, etc).	Pass

Test Videos
Identity Consolidation and  Assurance with MFA

Policy, Least Privilege and Access Request

Real-time Monitoring  + Session Capture and Replay

Infrastructure Simplicity and Reuse

Examples of Identity Assurance with Centrify MFA in AWS (Console, EC2 and CLI with PowerShell)

Note:  This is a repost of an article I recently wrote for the Centrify Community Techblog

Background

Centrify recently commissioned a study with Forrester Research that yielded some important information about the state of Security.  Bottom-line, we have decided to throw money and resources to the problems around information security rather than rethinking our approach, the results are more breaches and exposures.

You can access the study results here: https://www.centrify.com/lp/rethink-security-ebook

A key conclusion on over 200 organizations surveyed is that those with higher Identity and Access Management (IAM) maturity were breached 50% less while maintaining operational efficiency. 

As you read the previous paragraph, you may ask yourself: what is the first step the journey to the continuous improvement required for IAM maturity?  As illustrated in the model below,

a the key component is to establish identity assurance with technologies like MFA or PKI, however this is challenging enough because many organizations have not achieved this on-premises, much less in IaaS/PaaS platforms like Amazon AWS.

This is where Centrify can help.  This article is about guiding you on how to use the Centrify platform to establish identity assurance in several use cases:  

• Accessing the AWS Consoles with shared accounts (like Amazon root) or Federated identities
• Accessing EC2 instances locally (Linux or Windows)
• Accessing AWS commands via the CLI (E.g. PowerShell or Python)

Please note that identity assurance concepts apply to both users and systems (due to API access);  in this use case we'll focus on interactive (user) use cases.  For system/system or app/app, other mechanisms like PKI or Kerberos can be used and we can cover in another entry.

The Centrify Advantage

The biggest advantage for Centrify lies in it's platform and integrations, as a company that covers both Identity as a Service (IDaaS) as well as Privileged Identity Management (PIM) we understand that everything starts with Identity Consolidation.   This is not the "legacy" (metadirectory/connector-based mid-2000s) identity consolidation, this is the "straight-to-the-source" standards based approach using Federation in the IDaaS side, plus direct-integration (with Kerberos) in the case of heterogeneous OS platforms.  We add to this a series of services:

• A policy service
• A multi-factor authentication engine (that includes modern and legacy-based support)
• A risk-based engine (analytics) 

Our native integrations with Active Directory make us a prime vendor to consolidate capabilities;  here's an example, if an organization wants to secure access to a web app, integrate a non-windows platform to a central directory like AD and get MFA, they may engage 3 distinct vendors, however Centrify can help with world-class solutions on the three areas.  Let's look at a the examples.

  

Securing Shared or Federated Access to the AWS Console

Centrify Identity Service provides several turn-key templates to help with shared or federated (via SAML or using the AWS API) SSO for Amazon Web Services.  We have covered these integrations here:

• For a shared credential (like the amazon account)
• Using SAML or Amazon API for federated SSO + Provisioning

However, the powerful policy engine and the support for multiple authentication profiles makes this integration simple and flexible.  

Here's a quick demo on how this integration is enabled and the user experience:

Notice how we achieved our goals:  identity consolidation and assurance while maintaining usability.

Securing Access to Linux and Windows AWS EC2 Instances

Centrify Server Suite provides native integration with Active Directory, regardless of your deployment model. 

By leveraging AD (hosted by you or in AWS), you are eliminating the duplication of identity sources caused by SSH keys with the addition of DirectAuthorize technology that provides role-based access control and privilege elevation and is fully-integrated with the policy and authentication profiles provided by Identity Service or Privilege Service.  We have discussed these integrations here:
 

• MFA for UNIX/Linux
• MFA for Windows 

Provided the Identity Service/Privilege Service setup is correct and the proper PKI trust is in place, for Access and Privilege elevation, all we need to do is set up the proper checkbox at the role, UNIX command or Windows desktop or application.

 

Here's the user experience that meets the requirements for identity assurance via MFA for both Linux and Windows in the context of access and privilege elevation.

 

Notice how we achieved our goals:  identity consolidation and assurance while maintaining usability.

Securing Access to AWS CLI (e.g. PowerShell)

Administration of AWS Services is often performed via the AWS CLI (implemented via Windows PowerShell or UNIX CLI).

If you're using Centrify Identity Service with SAML federation into AWS, you can implement the SSO plugin provided with the template.

References:

• PowerShell script module help
• Using Python commands

Here's the user experience in PowerShell.  Note that the experience will be based on the authentication profile that applies to the user by policy.

If you have multiple roles, you get to select them:

 

Finally, the authentication token is stored in the $me variable and the user can move-on to use AWS PowerShell commandlets.   See the pattern here?  Identity assurance with MFA and role-based access without compromising usability and achieving this with with a single solution set.

  

Metrics

A cliché of business schools is the statement "you can't manage what you can't measure"; but since we're dealing with IT security, you may want to track how we are performing towards our goal of consistent identity assurance, in these AWS examples, we can use AWS CloudWatch metrics to measure the percentage of access in the proper context (e.g. Console, EC2, etc) is performed with assurance.  Therefore a good metric to track would be:

 

MFA events are tracked for Linux, Windows and Identity Platform, this allows you to be creative and get information from CloudWatch or from Identity Service.

Note the CloudWatch widgets above.  In my Linux space, I have a ratio of close to 60% identity assurance (4 out of 7 successful logins were with MFA), however my track record on the sample data I created on Windows is much better (100%).  You use the same approach for privilege elevation via Centrify-enhanced sudo or Centrify Agent for Windows.

In the case of Identity Service or Privilege Service, the platform provide dashboards and reports like the Security Overview - User Logins

These dashboards allow for reviewing information within 7 days or 24 hours and to look at specific date-time ranges. 

Conclusion

Identity assurance is closer than what you think, with the "barriers of entry" for MFA solutions going down, it's all about working with the right partner and Centrify excels at securing apps, endpoints, infrastructure and secrets; finally, the obvious challenge is organizational dynamics;   If you still have groups opposed to centralizing directories or maintaining legacy infrastructure, you can split the project in several phases and attack the platforms that are easier from a people/process standpoint.  Once you can demonstrate identity assurance within those applications or infrastructure, it's going to be hard for those "holding on to the past" to ignore that the best practices are here to stay. The model applies to all aspects of any risk-sensitive information technology area and like every other framework it's not a silver bullet; new threats, attack vectors, compliance requirements and tools are introduced, therefore this has to evolve as well.

[Labs] Using Identity Platform as a RADIUS Client to support MFA with OTP tokens (e.g. SecurID, etc)

Background

With the 16.8 monthly release of Centrify Identity Service and Privilege Service, Centrify is adding the ability for the Identity  Platform to act as a RADIUS client.  This will open the opportunity for CIS and CPS users to have authentication profiles for MFA products that support RADIUS (e.g. RSA, Symantec, CA, Vasco, etc).

This lab will allow you to set up a Linux server to act as your AD-integrated OTP+RADIUS server.  Then we'll configure CIS/CPS to act as a RADIUS client and support it as an additional MFA option.

Disclaimers

• This is a lab entry.  Production designs require planning for people, process and technology.
• RSA SecurID, Symantec VIP, Vasco, YubiKey, Google Authenticator, FreeRADIUS and CentOS are registered trademarks of their respective owners.

Lab Design
 The proposed lab looks as follows:

As you can see, we're using the following components:

• Identity Service or Privilege Service (can be the on-premises version of CPS too)
• Cloud connector:  enabled for AD Bridging and RADIUS client
• Centos 6.x System:  this system acts as
  • RADIUS Server > FreeRADIUS configured for PAM
  • Google Authenticator PAM Module > will provide OTP codes for enrolled users
  • Centrify DirectControl > Provides AD integration and NSS/PAM based identification/authentication
• Active Directory:  Provides infrastructure identity services (directory, authentication, policy)

Implementation
In this lab we will not cover the setup of an identity service instance and cloud connector.  Some resources:

• Getting Started with Centrify Identity Service (Microsite)
• Identity Service Support FAQ
• Centrify Support's YouTube Channel
• Identity Service Documentation

 What you'll need:

• A CentOS 6.x system configured in the same subnet as the Cloud Connector or with TCP 1812 connectivity.
• Working knowledge of Identity Service or Privilege Service
• Familiarity with Pluggable Authentication Modules (PAM)
• Basic DirectControl knowledge (install, join AD)
• An OATH OTP client (Google authenticator, Yubico authenticator, etc)

This lab starts assuming that you can log in to your Identity Service or Privilege Service instance with a user with the System Administrator right.


RADIUS+OTP Server Setup
Configuration Overview

1. Adding the EPEL repo to be able to install Google Authenticator
2. Install Google Authenticator
3. Install FreeRADIUS and related tools
4. Configure FreeRADIUS for PAM
5. Install Centrify DirectControl and join Active Directory
6. Enroll users for Google Authenticator OTP
7. Test your configuration with the command line
8. Configure Identity Service/Privilege Service as a RADIUS client

Adding the EPEL repo for Centos 6.x 

$ wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm
$ sudo yum install epel-release-latest-6.noarch.rpm -y
[truncated]
Installed:
  epel-release.noarch 0:6-8

 Installing Google Authenticator

$ sudo yum install google-authenticator -y
[truncated]
Installed:
  google-authenticator.x86_64 0:0-0.3.20110830.hgd525a9bab875.el6

 Install FreeRADIUS and Tools

$ sudo yum install freeradius freeradius-utils -y
[truncated]
Installed:
  freeradius.x86_64 0:2.2.6-6.el6_7   freeradius-utils.x86_64 0:2.2.6-6.el6_7

Dependency Installed:
  perl-DBI.x86_64 0:1.609-4.el6

Configuring FreeRADIUS for PAM
a) User and Group for the Radius Daemon
To  allow the radiusd daemon to traverse the filesystem to read the Google Authenticator config files on each user's home directory, you have to change the user/group in the configuration file.  This may be undesirable in a production environment.
Edit the  /etc/raddb/radiusd.conf and find:

user = radiusd
group = radiusd

Change to

user = root
group = root

and save the file.

b) Enable PAM for the Default Site
Edit the  /etc/raddb/sites-enabled/default  and find:

        #  Pluggable Authentication Modules.
#       pam

uncomment the PAM module and save.

        pam

c) Configure Users for PAM
Edit the  and find

#DEFAULT        Group == "disabled", Auth-Type := Reject
#               Reply-Message = "Your account has been disabled."

uncomment and add the line as follows:

DEFAULT Group == "disabled", Auth-Type := Reject
                Reply-Message = "Your account has been disabled."
DEFAULT Auth-Type := PAM

 Tip:  To check your work so far

1. In one session window, run the radius daemon in verbose mode
   

   $ sudo radiusd -X
   [truncated]
   Ready to process requests.

   If there are any issues with the current configuration, you can verify it with the output.
2. Open another session and create a new user
   

   $ sudo useradd testing
   $ sudo passwd testing
   New password:
   BAD PASSWORD: it is based on a dictionary word
   Retype new password:
   passwd: all authentication tokens updated successfully.
   

   Now you have a user to test your RADIUS server via PAM.
3. In that same session, use the radtest utility with the client set for the localhost client.
   

    radtest testing Mysecret123! localhost 0  testing123       Sending Access-Request of id 204 to 127.0.0.1 port 1812
           User-Name = "testing"
           User-Password = "Secret123!"
           NAS-IP-Address = 192.168.81.34
           NAS-Port = 0
           Message-Authenticator = 0x00000000000000000000000000000000
   rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=204, length=20
   

   On the first window, you'll see the verbose output somewhat like this:
   

   rad_recv: Access-Request packet from host 127.0.0.1 port 53367, id=204, length=77
           User-Name = "testing"
           User-Password = "Mysecret123!"
           NAS-IP-Address = 192.168.81.34
           NAS-Port = 0
           Message-Authenticator = 0x8c11ad4b5c1dbd597764716d95d3d9e3
   # Executing section authorize from file /etc/raddb/sites-enabled/default
   [truncated]
   Sending Access-Accept of id 204 to 127.0.0.1 port 53367
   

   This verifies that things are set up correctly so far.  Cancel radiusd debug (CTRL+C)

Install Centrify DirectControl and Join AD
We'll use the Centrify Repo and join AD in Workstation mode.

$ sudo yum install CentrifyDC -y
[truncated]
Installed:
  CentrifyDC.x86_64 0:5.3.1-398
$ sudo adjoin -w -u [user.name] domain.name
user.name@DOMAIN.NAME's password:
Using domain controller: dc.centrify.vms writable=true
Join to domain:centrify.vms, zone:Auto Zone successful

Centrify DirectControl started.

At this point, if you want another sanity check, you can repeat the same debugging but with an AD user credential.

Configure the Radius PAM directives for Google Authenticator
Edit the /etc/pam.d/radiusd perform two modifications.
Add  this line on the top of the file auth required pam_google_authenticator.so and comment the auth module.
Here what we'll achieve is to provide the Google Authenticator code as our one-time password via RADIUS.  Other combinations of PAM modules can achieve a Password+Code. 
The final result should look like this:

#%PAM-1.0
auth       required     pam_google_authenticator.so

#auth       include     password-auth
account    required     pam_nologin.so
account    include      password-auth
password   include      password-auth
session    include      password-auth

This configuration challenges for the OTP code only and ignores the password.

Enroll an AD user with Google Authenticator

1. Log in with a test AD user to your Linux system
2. Run the google authenticator setup (google-authenticator)
   

   Last login: Thu Aug  4 06:22:50 2016 from 192.168.81.11
   $ google-authenticator
   https://www.google.com/[truncated]  <= copy this URL and paste it on your browser
   Your new secret key is: ETIQLTKPBQV4TVLH
   Your verification code is 2647620
   Your emergency scratch codes are:
     08703664
   [truncated]
   

   Follow the prompts until you complete setup.
3. Paste the URL in a web browser and use your Authenticator QR Capture function to capture the code.
   Alternatively you can add the code manually.
4. Repeat this process for all your test users.

Verify RADIUS functionality with OTP

1. In a session, open Radiusd in verbose mode.  [sudo radiusd -X]
2. In another browser, test the authentication with the code from the OATH OTP authenticator.
   radtest [username] [oath otp code] localhost 0 [pharaphrase]
   In my environment it looks like this:
   

You have verified functionality.

Set up the Cloud Connector as a RADIUS Client
On the FreeRADIUS Server you have to set up the connector as a client.

1. If you haven't done so, close the radiusd debugger.
2. Edit the following file  /etc/raddb/clients.conf go to the end and add:
   

   client member2.centrify.vms {
           secret          = [Insert Complex String Here]
           shortname       = [Friendly Name]
   }
   

   Notes:
   - You can use the IP address or FQDN of your RADIUS-enabled connector
   - You must choose a decent complex string as your secret and save it for the next section.
3. Save the file.

Note:  In some Linux systems/versions you may need to set SELinux to permissive.  This is to allow radiusd to interact with PAM.

Centrify Identity Service or Privilege Service Setup
Overview

1. Configure the RADIUS Server
2. Configure Connector for RADIUS
3. Enable RADIUS in your Policy
4. Enable 3rd Party RADIUS in your Authentication Profile(s)
5. Verify Functionality
6. Modify RADIUS service startup

To configure the RADIUS Server
Go to Cloud Manager > Settings > Authentication > Radius Connections > Servers Tab and press Add
Name: A descriptive name (e.g. SecurID PIN+Code)
Description: Optional
Server IP Address:  The IP address of your server
Port:  Change if not default (1812)
Server Secret:  Must match the secret you set up in the previous step.


Configuring a Connector for RADIUS
You need at least one connector enabled for RADIUS that can reach the RADIUS server.
Go to Cloud Manager > Settings > Network > Cloud Connectors > [connector] > RADIUS > and Check
"Enable connections to external RADIUS servers" 

Also make sure that the RADIUS Client service is enabled.

Enable RADIUS in your User Authentication Policy
Go to Cloud Manager > Policies > [click on the policy that applies to the user(s)] > Expand User Security Policies and Click RADIUS.  Set "Allow 3rd Party RADIUS" to Yes and Save.


Enable 3rd Party RADIUS in any corresponding Authentication Profiles
Cloud Manager > Settings> Authentication Profiles > [click profile that you want to enable] and check
"3rd Party RADIUS Authentication" and press OK.  Repeat with other profiles if needed.


Verify Functionality

1. Launch radiusd in debug mode (sudo radiusd -X) on your Linux system.
2. Trigger a Step-up protected event in CIS/CPS  (private login, secure access, password checkout)
   
   Monitor the debug log for any errors.  If everything goes as expected, keep testing with other users.

Tidy-up:  Set up the Radius Service for Automatic Startup

$ sudo chkconfig radiusd on
$ sudo service radiusd start

Quick Video

Labs: Setting-up Step-up and MFA for Centrify Express for UNIX/Linux

Background

Note:  In this rare occasion I will discuss a capability related to Centrify Express.  This product is limited to a number of systems and Centrify has added additional capabilities that enhance the value of the solution. 

Last month, with the release of Centrify Suite 2016.1, Centrify expanded on the MFA Everywhere strategy adding support for UNIX systems (AIX, HP-UX, Solaris) for Server Login and Privilege Elevation.  In addition, Centrify added MFA login support for Auto Zone.  This means that Centrify Express for UNIX/Linux customers can use the industry-recognized Centrify Identity Service tenants can implement MFA or Step-up Authentication on login. 

This quick article covers the steps to implement MFA as an additional control to access systems integrated to AD with Centrify Express for UNIX/Linux.  The information in this article can also be applied to Classic zones and Auto Zone (workstation mode).
For an in depth discussion on Centrify Server Suite MFA, you can read this lab entry.
For information on how to get started with Centrify Identity Service, visit the Getting Started page.

Planning

Potential Stakeholders

• Centrify SMEs: 
• Security Lead:  The security lead can answer questions like these:
  a) What servers require step-up authentication for login?
  b) What users will be challenged for Multi-factor at login?
  c) What users will have the rights to log in without multi-factor or for troubleshooting purposes?
• IT/AD Infrastructure lead:   This SME will help setting up a Windows Server to act as the cloud connector

Technical Requirements

• Active Directory
• A supported Centrify Express OS with Centrify DirectControl 5.3.1
• A Centrify Identity Service tenant  (you can sign-up for a trial here) with a Cloud Connector
  Cloud Connectors run on 64-bit Windows Servers and require outbound HTTPS connectivity (can be behind a proxy)
• A user with a supported MFA or step-up method (Phone Number, Mobile Number (for SMS), Centrify Mobile Authenticator for Push MFA, OATH OTP (Google Authenticator, FreeOTP, YubiKey, DUO, etc).
• If using Centrify Mobile Authenticator or Google Authenticator  you'll need an iOS or Android device

Centrify Parameters for MFA on Auto Zone
Centrify Express joins Active Directory in workstation mode.  This allows for quick integration with AD for all users without worrying about UNIX identity.  UNIX login, UID, primary group, GECOS, home and Shell are generated by the Centrify client.  Configuration can be managed via parameters.   The parameters introduced for MFA are the following:

• adclient.legacyzone.mfa.enabled: This parameter turns on MFA and it is set to false by default.
• adclient.legacyzone.mfa.cloudurl: This is the Centrify Identity Service tenant URL that is configured to grant MFA to the system.
• adclient.legacyzone.mfa.required.groups (or users):  These parameters specify which users (or members of the AD group) that will be challenged for multi-factor on login.
• adclient.legacyzone.mfa.rescue.users: These are the users that can access the system in case no tunnel can be established with the MFA service.

Other relevant parameters:

• adclient.cloud.connector:  This parameter can be used to specify a proxy server if in use.

Implementation

Scenario
We will get started with a Centrify Identity Service that has the Cloud Connector set up with the AD Bridge enabled.
To learn how to set up a cloud connector you can always review the Getting Started guide.
First, we will enable MFA using information from a user in AD (e-mail, mobile phone, phone), then we will walkt the user through the process of enrolling a mobile device (to enable Centrify Mobile Authenticator for push MFA) and we'll also use Google Authenticator for OATH OTP.

Configuring a Cloud Connector
Cloud connector configuration steps are outlined here. However, the steps are as follows:

1. In Cloud Manager, navigate to Settings > Network > Cloud Connectors
2. Click the "Add Cloud Cloud Connector"
   
3. Download the bits and run setup.  All you need is the cloud connector componetn.
4. You have to authorize the Cloud Connector following the steps on the wizard.  Refer to the link below for a video detailed steps.

Configuring your Centrify Identity Service tenant for Server MFA
There are 4 tasks to configure MFA for Servers in the Cloud Manager side:

1. Role Creation
   Create a role that has the "Server Login and Privilege Elevation" right and contains the computer accounts that will be requiring multifactor authentication.
   Cloud Manager > Roles > New Role > [Rights and Members]
   
   
2. Authentication Profile
   Create an authentication profile that specifies the MFA methods to be used.
   Cloud Manager > Settings > Authentication > Authentication Profiles
   
   Notes:  It is important to make the distinction between step-up authentication and multi-factor authentication (sometimes used interchangeably).  In addition to the login password challenge, an e-mail link delivered to your inbox qualifies as step-up, but Push MFA from a registered mobile device (something you have).
   Note that I've left out password and user-defined security question.  Checking password will re-prompt the user for their AD password and the answer to a security question is just another secret that can be obtained by social-engineering.
3. Set up an Authentication profile for Server Suite Authentication
   Cloud Manager > Settings > Authentication Profiles > Server Suite Authentication
   
   For Centrify Express, only the Access Profile applies.
4. Verification of Methods
   Make sure your users have the step-up methods populated in AD:
   
   If looking to provide Step-up via email, the user has to have a valid e-mail address.  For phone call, phone/mobile are required, for SMS mobile is required.

Configuring Centrify Express for MFA at login
This is a parameter-based configuration.  As defined above, you need at least 4 parameters in the /etc/centrifydc/centrifydc.conf file:

# set this one to true
adclient.legacyzone.mfa.enabled: true

# to require MFA, you can either use individual users or groups.
# groups are more efficient

adclient.legacyzone.mfa.required.groups: mfa-required
# all members of mfa-required AD group will be prompted

# rescue rights can be assigned for HA in case all CCs are down
# or there's no redundant connectivity to the cloud service

adclient.legacyzone.mfa.rescue.users: vip.user1, vip.user2
# vip users can access systems in case of comm failure

# The cloud URL is the key parameter to specify your tenant
# note that no direct internet connectivity is required, the CC
# will broker this.

adclient.legacyzone.mfa.cloudurl: https://unique-id.my.centrify.com:443/
# Use the unique URL instead of the vanity URL if you expect
# any changes.

# There are other parameters (e.g. for a Proxy server)

After these changes, save your work and restart the centrifydc service.

Use adcdiag to check your work:

$  sudo /usr/share/centrifydc/bin/adcdiag
VERSION   : Verify that DirectControl version supports MFA               : Pass
JOINSTATE : Verify that DirectControl is in connected mode               : Pass
ZONECHK   : Verify that MFA is supported in the zone                     : Pass
SSHDCFG   : Verify that SSHD enables ChallengeResponseAuthentication     : Warning
          : Can not read sshd configuration file. Probably you are not
          : using Centrify openssh. SSH login for MFA users will fail
          : if option ChallengeResponseAuthentication is not set to
          : yes.
          : Please check and ensure ChallengeResponseAuthentication is
          : set to yes in sshd configuration file.
CDCCFG    : Verify that MFA options in centrifydc.conf are correct       : Pass
CLDINST   : Verify that trusted cloud instance is specified              : Pass
CNTRCFG   : Verify that cloud connectors are configured correctly        : Pass
CURCNTR   : Verify that DirectControl has selected a workable cloud
          : connector                                                    : Pass
CLOUDROLE : Verify that this machine has permissions to perform Centrify
          : cloud authentication                                         : Pass
AUTHPROF  : Verify that authentication profiles for Server Suite have
          : been specified.                                              : Pass
MFA checking passed with warnings. MFA still works on this server. We recommend 
checking the warnings before proceeding.

In my case, I just need to make sure that ChallengeResponse is set, since I'm using stock SSH.

$ grep Challenge /etc/ssh/sshd_config
ChallengeResponseAuthentication yes 

Verification

E-mail method

Device enrollment for Push MFA with Centrify's Mobile Authenticator
Push MFA enhances the experience and provides more meaningful information.  This requires that the current policy allows the user to enroll an Android or iOS device. 

OATH OTP (Google Authenticator, FreeOTP, Yubico Authenticator, Duo and more)
OATH OTP opens more possibilities with this open standard.  Users are easy to onboard, and there are a variety of Authenticators that can be used.

Enhancements

For those using Centrify Standard Edition with classic zones or workstation mode, you can use GPOs to manage the settings (or DevOps tools)

Centrify has also enhanced the documentation available for solutions like SecurID.  Check out the Documentation Center.

Video Playlist