Background

Many organizations have invested in multi-factor authentication solutions that work with the Remote Authentication Dial In User Service (RADIUS) protocol and they would like to re-use their investments with Centrify Identity Service and Centrify Privilege Service.

Earlier this year, as part of the MFA Everywhere initiative, Centrify added RADIUS server capabilities to the Identity Platform to provide MFA services to services that could act as RADIUS clients (e.g. VPN Gateways, etc.).

 

With the 16.8 monthly release, 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:radius-lab.png

 

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:

 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 file 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  file and find:

        #  Pluggable Authentication Modules.
#       pam

uncomment the PAM module and save.

        pam

c) Configure Users for PAM

Edit the /etc/raddb/users file 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:
    verify-radius.png

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 [your-client-name] {
            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.

cis-radius-setup.png

 

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" 

cis-cc-radius.png

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.
cis-cc-authprofile.png

 

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.

cis-cc-authprofile.png

 

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)
    verifiy-radius2.png
    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

 

CIS/CPS Setup Video

Announcing a new series!!!

 

I recently got some YubiKeys from HQ (thanks @Peter) and since they provide all-in-one smart card (PIV) and OTP (OATH) capabilities plus they work great with Centrify products. 

 

Here are the series links:

Part 1: Securing Windows Server Access and Privilege Escalation with Centrify, Active Directory and ...

Part 2: Securing local and remote access to UNIX/Linux with Centrify, Active Directory and YubiKey

Part 3: Using SmartCard (or YubiKey) to secure Apps, Shared Secrets an Sessions with CIS and CPS

 

 

About the Series

This new series showcases our  MFA Everywhere initiative and we'll be posting a series of HOWTO labs to cover several scenarios:

css-yubi-scenario.png

Strong Authentication (PKI) Smart Card / Yubikey

  • Leverage what you have:  Active Directory, Microsoft CA, Group Policies
  • Enforcing Smart Card access to UNIX/Linux/Mac systems  (Windows systems support this natively)
  • Use DirectAuthorize roles to limit access to strongly authenticated sessions

Strong Authentication for Windows Privilege Elevation

  • Applications
  • Desktops

We already covered Access and Privilege Elevation For UNIX/Linux using Centrify MFA here:  http://community.centrify.com/t5/Community-Tech-Blog/LABS-Setting-up-the-MFA-for-Servers-feature-of-...

 

css-yubi-scenario2.png

Strong Authentication (Smartcard/Yubikey) & OATH OTP access

  • IdP Portal Access
  • OnPrem or SaaS Application Access
  • Privilege Portal Access
  • Privilege Password Manager  (Shared Account Password Manager)
  • Privilege Session Manager (Jump Box)

 Here's a quick overview/demo

 

Lab - Base Setup

The base setup is the pre-requisite for all the Yubikey/SmartCard related labs.

 

What you'll need

  • Active Directory with Certificate Services
  • A domain joined member server with Centrify Server Suite 2016
    • .NET 3.x features enabled
    • Feature RSAT:  Active Directory, Group Policy Management and Certificate Services tools
  • One or two UNIX/Linux systems with Centrify Standard Edition 2016  (5.3+)  (if testing UNIX/Linux)
  • Access to Centrify Standard Edition installation files (evaluation or licensed)
  • Yubikey PIV Manager  (download link)
  • Yubikey 4, NANO or NEO
  • You need working knowledge of Active Directory and Centrify Zones

 Tip:  To set up a base configuration, you can build on the Microsoft Test Lab Guide.

 

Create Test Users and AD Group

On the member server

  1. Open Active Directory Users and Computers and navigate to your desired OU
  2. Right click and select New > User  and follow the wizard until the user is created.
  3. Right click the newly-created user and select properties.  In the general tab, update the Email to match the user principal name.
    e.g. user@corp.contoso.com and press OK.
  4. Right click the OU and select New > Group and make it a Global/Security group.  Call it "Smart Card Users"
  5. Right click the Group, select properties, go to the Members tab, press Add and add the user created in step 2.
  6. On the member server, grant the group or user the ability to log on remotely. 
    Computer > Properties > Remote Settings > Remote Desktop > Select Users  > Add > [select user or group] press OK twice.

Certificate Services

Modify the Smart Card User template

  1. Open the Certification Authority console  (Start > Search > Certification Authority)
    If you get an error, retarget the console to the appropriate server (e.g. DC1)
  2. On the left pane, right click "Certificate Templates" and select Manage.  This will open the Certificate Templates console.
  3. In the template list, right-click the SmartCard User template and select "Duplicate Template"
  4. In the General tab, give the template a descriptive name.  I used "Smart card User V2"  (this is the display name, the actual template name is SmartcardUserV2)
  5. Click on the Security tab, press Add, select the newly-created Smart Card Users group, check the Enroll and Autoenroll boxes, then press OK and close the Certificate Templates console.

Publish the Newly-Created Template

  1. In the Certification Authorities console, on the left pane, right click "Certificate Templates" and select New > Certificate Template to Issue
  2. Select the newly-created version of the Smart Card User template  (e.g. Smart Card User v2) and press OK.

Provision the Smart Card User Certificate into your Yubikey

  1. Log on to your member system with the test user.
  2. Open the Yubikey PIV manager tool with the Test User  (shift+right click > run as different user)
  3. If you're using a VM, connect the Yubikey to your virtual machine.
    Note:  If you're using VMWare, you need to add the parameter below for the Yubikey to be available to your VM.
    usb.generic.allowHID = "TRUE"
    This step is performed by editing the .vmx file and editing it with your current text editor while the VM is off.
  4. Initialize the Yubikey if brand new.  Do not forget the PIN.
    yubikey-win-init.png
  5. In Yubikey PIV manager, press Certificates > Generate New Key and make sure you type the Certificate Template name (not the display name) and press OK.
  6. Type the PIN when challenged, and select your existing CA.  In my case I use the non HTTP link and press OK
    yubikey-enroll-cert.pngyubikey-enroll-cert2.png
    yubikey-enroll-cert3.png
  7. To test the smart card authentication, either lock your screen or logoff.  If you can unlock or login successfully, you should be ready for the next steps.
    yubikey-cert-test.png

 

Lab Verification Video

This is a continuation of our previous article, in which we discussed how to eliminate the poor practice of sharing the root, administrator (or any other privileged account) across UNIX, Linux and Windows platforms using Centrify Standard Edition.

 

We build on this knowledge to tackle a bigger challenge:  privileged execution of individual apps tied to session capture and replay.

 

Why implement granular Role-Based Access?

Prospects and customers come to us because of one or more of these issues:

 

In UNIX & Linux systems:

  • They use sudo, but realize that there are challenges related to the administration and reporting of privileges based on that model.
  • Privileged users end up doing this  "sudo su -" or "dzdo su -"  this makes it hard to truly detect who performed what actions in critical systems.

In Windows

  • There are poorly written but critical apps that require Administrator privileges to run, this means that a large population of users have admin rights in their PCs.
  • There are too many members in privileged groups in AD just to be able to perform simple tasks.
  • You are using Windows 2012 or Windows 8 and the "quick and easy" privileged elevation provided by Centrify's DirectAuthorize for Windows (New Desktop) is not available in these platforms.

 

Across all platforms

Organizations may have adopted a control (such as a password vault), and although now they have a better handle of who has access to a privileged account (and can approve/deny access) and the passwords are rotated, they realized that:

  • They can't pass tougher audits that require the implementation of a strict Role Based Access Control
  • Certain actions can't still be accounted for (some folks bypass the vault system and connect directly)
  • Costs for added capabilities and users are growing exponentially
  • The approvals process is too lax due to the fact that a lot of users need privileged actions as part of their job (even for simple operational tasks)
  • Due to costs, the vault system is not replicated in Dev, QA environments and production processes are not uniform across the board.

Although there's been a significant investment in the capability of log aggregation, it is very hard to be able to reproduce the actions performed by privileged users or to assess suspicious activity.

Read more...

Showing results for 
Search instead for 
Do you mean 
Labels
Leaderboard

Community Control Panel