Showing posts with label Google Authenticator. Show all posts
Showing posts with label Google Authenticator. Show all posts

Tuesday, August 16, 2016

[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: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 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:
    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 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.
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

Quick Video

Wednesday, June 8, 2016

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"
    register cc.png
  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]

    mfa role.png
  2. Authentication Profile
    Create an authentication profile that specifies the MFA methods to be used.
    Cloud Manager > Settings > Authentication > Authentication Profiles
    authprof.png
    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
    ssauth.png
    For Centrify Express, only the Access Profile applies.
  4. Verification of Methods
    Make sure your users have the step-up methods populated in AD:
    attrib.png
    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
emailmfa.png


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. 
pushmfa.png
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.
oath-google.png


Enhancements

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

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

Video Playlist

Monday, May 30, 2016

Centrify Suite 2016.1 Highlights

Last week Centrify made available the mid-year release (2016.1) that comes packed with new capabilities.

Given that the PCI DSS 3.2 focuses stresses multi-factor authentication Centrify is gearing-up to help organizations that are looking to align with it this fall both with their legacy solutions (e.g. RSA SecurID) and modern methods.

Multi-factor Authentication Extended
  • Centrify MFA with DirectAuthorize is now extended to HP-UX, AIX and Solaris  (this completes the UNIX/Linux ecosystem).
  • DirectAuthorize for Windows introduces MFA on Windows privilege elevation
  • Updated whitepaper RSA SecurID MFA integration that includes now server access and privilege elevation (instead of just PAM stacking).  QA'd with RSA 7.1 on AIX (5.3, 6.1, 7.1), HP-UX 11i v2/v3, RHEL (4.8, 5.8, 6.2), SUSE 11SP2, Solaris 11 & 10.
    Note that this is for non-GUI login and Centrify-enhanced sudo (dzdo)
  • OATH OTP (e.g. Google Authenticator, Yubico Authenticator, FreeOTP, Duo, etc.) is now usable via Centrify MFA with Identity Service.
  • Parameter-based MFA controls for supporting Centrify Auto Zone and Classic Zones.
  • The adcdiag command line tool was introduced to provide pre-flight checks for MFA setup.
  • Enhancements to PowerShell commands for provisioning of MFA fields.
OATH OTP support opens more possibilities with Google Authenticator or YubiKey
adcdiag should provide the same value to MFA implementations as adcheck does for AD joins.
Centrify auto zone other legacy modes get multi-factor at login and can be configured via GPOs


Microsoft AD, Kerberos, Certificates and Smart Card
  • AD Cross-forest authentication with alternate UPN is now supported
  • Support for Microsoft's  "Define host name-to-Kerberos host mapping" GPO
    Ref: https://support.microsoft.com/en-us/kb/947706 
  • Certificate Management and auto-enrollment now supports Elliptic Curve Algorithms.
  • Centrify Hierarchical Zones now support the sourcing of UNIX identity from pre-existing RFC2307 attributes.  This can simplify provisioning for organizations that use those fields.

UNIX/Linux Client and Utilities Enhancements
  • The NIS Proxy (adnisd) now has it's own watchdog process.
  • Enhanced argument checking for dzdo (Centrify-enhanced sudo)
  • New Events documented when MFA challenges fail or succeed
  • Centrify-enhanced OpenSSH is now based on OpenSSH 7.2p2
  • OpenSSL is based on 1.0.2g
  • Centrify LDAP Proxy now supports TLS 1.2
  • libcurl is based on 7.44.0
  • PuTTY is upgraded to version 0.64
  • A new command "adcdiag" has been added to troubleshoot MFA
  • A new command "adobjectrefresh" has been added to only refresh specific users or groups instead of the whole cache.
  • Parameter and utility enhancements to support Hortonworks Hadoop Ambari 2.1.2
adobjectrefresh will be a great addition for Centrify administrators
Added Platforms
  • AIX 7.2
  • Latest version of Amazon Linux AMI (x86, x86_64)
  • CentOS 7.2 (x86_64)
  • Debian Linux 7.10, 8.3, 8.4 (x86, x86_64)
  • Oracle Enterprise Linux 7.2 (x86_64)
  • Scientific Linux 7.2 (x86_64)
  • openSUSE 42.1 (x86_64)
  • SUSE 12 SP1 (x86_64)
  • Scientific Linux 7.2 (x86_64)
  • Ubuntu 16.04 LTS (x86, x86_64)
  • Windows 10 (App and network rights)

Removed Platforms
  • Debian Linux 6
  • Fedora 20
  • HPUX 11.11, 11.23
  • Oracle Solaris 9
  • Ubuntu 14.10
  • OS X 10.9
Windows Client Enhancements
  • MFA Challenge on Applications or Desktop launches
  • Audit Trail Events for MFA Challenges


Mac Platform Enhancements

  • Simplified setup
    There's no need to download DirectManage components.  Centrify has released a new "Mac Console" that contains the Centrify ADUC extension, GPOE and License Manager in a small (100 MB) bundle (contrast with 1.6GB for DirectManage).