[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

Mac OS X Extras: Using Centrify and your Windows Infrastructure to provide 802.1x EAP-TLS to Mac OS X Systems

Background

Secure access to Wifi or Ethernet networks is a goal of any security conscious IT infrastructure team, however diversity of platforms makes this goal very hard to achieve, especially when organizations are looking to standardize but have diverse client platforms.

In a Windows world, capabilities such as Active Directory Certificate Services, Group Policies, the Network Policy Service and Windows clients make this goal relatively simple.  The popularity of Mac Workstations has forced many organizations to face this challenge.

The good news is that Centrify has worked very hard to make sure that IT Infrastructure folks can leverage their existing Windows infrastructure to solve this challenge on the macs.
The challenge for any technical lead is that the expertise required just to meet the prerequisites is going to be scattered all over the organization; this means that it's time to flex the ability to coordinate and get people to work together.  Hopefully this post provides a lot of clarity.

How easy is it to implement?

It is as easy as enabling one of the Centrify-provided GPOs for Mac OS X.  Specifically the "Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > 802.1x Settings" and you can pick your flavor:

• Enable Machine Ethernet Profile
• Enable Machine Wi-Fi Profile
• Enable User Ethernet Profile
• Enable User Wi-Fi Profile

However, this entry would not be useful if I just show you that you can enable the GPO, perform a policy refresh and just like magic: network access.

What I've noticed from prospects or customers that are looking to test these capabilities is that they don't understand all the moving pieces that need to be in place in order for this to work. 

In this post we'll use a checklist to make sure that you understand what needs to be in place to be successful.  

Note:  If you already have 802.1x EAP-TLS running with your Windows infrastructure today, you are very well-positioned for success.

Pre-Requisites

• About adcert
• Certificate Auto-enrollment on Mac OS
• Lab Setup: Microsoft Test Lab Guide (read on the PKI parts)

Building Blocks

Active Directory and Windows Services:  There are several ways to accomplish this goal, but in this particular instance, because our goal is to consolidate processes, knowledge and infrastructure, we are leveraging Windows capabilities like Active Directory, AD Certificate Services and the Network Policy Service.  AD Groups will be key to provide access controls;  OUs will determine the scope of GPOs to be used.

Public Key Infrastructure:  PKI is needed to provide the encryption, non-repudiation and authentication between the back-end infrastructure (Active Directory) and the client (Ethernet or Wifi).  The key here is the certificate life-cycle management, this is where Windows PKI uses Group Policy.
PKI Disclaimer:  PKI is not joke.  Any proper implementation needs to provide the assurances that PKI is aligned with your security policy.  If your organization does not have a policy for PKI (general assurances, handling of private keys, policies, templates,  Root and SubCAs) consult an expert.

A Policy/Configuration Management Engine:  Group Policy provides the rules and the enforcement for configuration items and even provides certificate auto-enrollment - a way to manage the certificate lifecycle (issuance, renewal, revocation, etc); in addition, GPOs will be the way that Centrify will provide the Apple profile information.

Network Policy Service: The NPS service on Windows provides the services like Remote Authentication Dial-in User Service (RADIUS) and the policy rules to enable 802.1x.  The NPS Service interacts with Active Directory to leverage groups and attributes.

802.1x-Capable Network Devices:  Any modern switch or access point supports 802.1x EAP and RADIUS.

Centrify Agent for Mac OS X:  This use case showcases the power of the Centrify agent.  Not only it leverages its ability to integrate with AD, but to use advanced services and perform this cohesively within the MacOS platform.  Key capabilities:  Certificate Auto-Enrollment, System Profiles, GPO Engine.

The Lab

• For AD and PKI:  Modified Microsoft Test Lab Guide:  Provides the corp.contoso.com domain with a running Microsoft CA.  The RootCA (corp-DC1-CA) certificates are deployed using GPOs.
  Translation:  A common Certificate Authorithy with the proper Certificate Revocation publication methods needs to be provisioned. I did not set APP1 as a SubCA.
• For RADIUS and Policies:  I'm piggybacking on my APP2 Windows 2012 server
• Network Devices:  I'm using Cisco small business (300 series) switch and a TPLink (TL-WA90x) Wireless Access Point.
• Mac Client:  Old Macbook running 10.7 and Centrify 5.2.1

Basic Checklist

OS X System is Centrified
Centrify agent is connected  (run adinfo -m)

PKI Checklist

All Systems have a Root CA in their trust chain?
The Network Policy Server has a computer certificate?
A proper 802.1x certificate template was set up for Mac Systems?
The Mac Auto-Enrollment GPO has been properly deployed?

Was the computer Certificate on the Mac based on the proper template?

You may need to look in the CA's Issued Certificates.

With PKI it's all about consistency.  All systems trust the Enterprise CA; All Certs are Issued by the CA or SubCAs and Programs (like NPS) are using the same trust chain.

NPS/Network Device Checklist

RADIUS clients have been set up properly on the NPS Server
RADIUS servers are properly configured on the network devices
Is there connectivity between RADIUS clients and servers?

Connection Request Policies are set up appropriately (Conditions/Settings)
Network Policies are set up to Allow access based on Conditions
Clients Meet the Conditions

Any conditions added (like AD group membership) must be met in order to have successful connections.

For example, if you're using a condition in which your Mac has to belong to a group called "Mac Workstations 802.1x" you can use the 'adquery user -A computername$ | grep MemberOf'  command to enumerate the AD groups that the computer belongs to

$ adquery user rpmacbook$ -A | grep memberOf

memberOf:corp.contoso.com/Mac/Corporate/Mac Workstations 802.1x,corp.contoso.com/Users/Domain Computers

802.1x Mac Group Policy

Is the Mac System Wifi-capable?
Wifi SSID is correct?
Template Name is correct?

The template Display Name may be different than the template Name

Has the policy been refreshed?  (adgpupdate - remember replication!)
System Preferences > System > Profiles contains payload?

Connected?


Video Playlist