Introduction

This article is an attempt to provide the background information, tools and mechanisms to spot and correct Public Key Infrastructure-related issues for those who are setting-up Centrify Multi-factor Authentication or trying to enroll Identity Broker clients.

 

Background

Public Key Infrastructure is at the heart of how many Internet and corporate infrastructure services are secured today and Centrify has always provided ways to make PKI simpler for organizations.  A big example is adcert, this tool provides support for enterprise trust and auto-enrollment for Microsoft Certification Authority for UNIX, Linux and Mac. 

 

After the introduction of Identity Service and Privilege Service and the advent of high-profile data breaches and industry guidance like PCI 3.2 Data Security Standard (Requirement 8, Sections 3, 10, 11 & 12), many organizations are rushing to implement Multi-factor Authentication.   Another big milestone is the popularity of hybrid clouds;  Centrify has introduced a new capability called Identity Broker, this new Linux Agent allows organizations to "enroll" in Centrify Privilege Service and to "bridge" multi-source enterprise directories like Active Directory, LDAP, Google Directory and Centrify directory.

 

All these scenarios make use of Public Key Infrastructure to establish the assurance that clients are talking to the right entity (non-repudiation) and encryption in transit is enforced.  An important point to understand about every Centrify SaaS or on premises tenant is that it has an internal certification authority that is used for multiple uses including encryption, non-repudiation, mobile management and authentication.

 

PKI Trust and Multi-factor Authentication

With Centrify Identity Service and Privilege Service, it's possible for current users of Centrify Express or Centrify Standard Edition to implement MFA in a very quick and effective way; supporting both modern and legacy-based (RADIUS) solutions.  In the platform's 16.10 release, Centrify proactively deprecated Integrated Windows Authentication (SPNEGO) over HTTP to exclusively use HTTPS.  

Before release 16.10, Centrify announced the deprecation of IWA over HTTPBefore release 16.10, Centrify announced the deprecation of IWA over HTTP

The implication for users is that any interaction that used IWA (SPNEGO) required PKI trust in the authentication framework for MFA negotiation.

 

This means that framework after 16.10 looks like this:

mfa model.png

As you can see from the framework above, there are 3 ways you can make sure the PKI requirements are satisfied:

  • Enterprise Trust:  This is the preferred method. Ideally, an organization has a properly-implemented PKI trust capability. Unfortunately, this is relatively obscure especially in the mid-market.  A great benefit to organizations using Microsoft PKI is that Centrify DirectControl agents will take care of the enterprise trust automatically by bundling the Root and Intermediate CAs into the proper UNIX or Linux bundle.
  • Public Trust:  This was a bit expensive a while back, but the easiest way to make sure that PKI trust works out of the box is to use certificates issued by a public vendor like Verisign or GoDaddy.
  • Tenant Trust:  Each Centrify tenant will automatically create IWA certificates for all the Centrify connectors in the deployment.  This means that customers can either manually, with DevOps or with Microsoft GPOs can set up a trust chain.  This can be automated but requires a bit of work.
    The tentant will give you the option to download the IWA root certificate or the connector's host certificateThe tentant will give you the option to download the IWA root certificate or the connector's host certificate

How to determine if your UNIX/Linux system is ready for MFA

Centrify provides a tool (adcdiag) that will allow users to spot issues with the MFA configuration.   For example, in a Centrified system with an AD environment with Microsoft PKI, the root CA certificate is automatically downloaded to the /var/centrify/net/certs folder and appended to the bundle corresponding to the platform.  

Here's a sample output from a Centrified system with Enterprise Trust:

adcdiag-explained.png

This output is favorable because DirectControl (adclient) is making sure a lot of the moving parts are in place including making sure that any root or intermediate CA certificates are in the trust chain.  The reason why this "just works" is because a few seconds after joining AD, and if the system is allowed to certificate auto-enrollment, the client will make sure all the proper certs are provisioned to the system and the CA bundle is updated.  This makes this process work like plug and play. 

 

In cases when there is no trust, then the ca-bundle has to be updated with the IWA trust certificate from the tenant.  When you run the adcdiag, several checks will fail including this one:

cntrcfg.png

 If you inspect the file referenced by adcdiag, there will be the following information in this section: 

"Error setting certificate verify locations" and this will point to the CA bundle for the platform (e.g. /etc/pki/tls/certs/ca-bundle.crt).  There are several ways to solve this issue:

  • Enterprise:  Appending the root CA certificate in PEM format to the CA bundle file
  • Public:  Making sure the CA bundle is up-to date
  • Tenant:  Appending the IWA root ca in PEM format to the CA bundle file.

 

Fixing MFA CA Trust issues in UNIX/Linux platforms

You'll need to know:

  1. How to get the certificate in question
  2. The encoding of the certificate you're receiving
  3. The location of the bundle for the operating system in question
  4. For large production deployments, you'll need to use a viable distribution method

 

Scenario

adcdiag failed in a CentOS 6 system.  The issue is with the /etc/pki/tls/certs/ca-bundle.crt.  I am working with a SaaS instance of Identity Service.

Locate the IWA Cert and Determine the Encoding

  1. In Admin Portal > Settings > Network > Centrify Connectors > click the connector > IWA Service  and click "Download your IWA root CA certificate"
    iwa.png
  2. Locate the file and try to open it with a text editor.  If the text reads "--- begin certificate"  you are dealing with a usable certificate.
  3. Save the file and transfer it to your target system (e.g. IWACert.crt)

Append the certificate to the CA bundle

  1. In the target system, concatenate the contents of the certificate file to the platform CA bundle.  E.g.
    $ sudo cat /home/user/IWACert.crt >> /etc/pki/tls/certs/ca-bundle.crt
    Note:  there are OS utilities like "update-ca-trust" that perform this step the correct way.  This is for illustration only.
  2. Re-run adcdiag and verify the results.

Enterprise Environments

As you can see, the steps above won't scale in a large environment.  This is why the preferred method is to have enterprise trust in place.  Other ways to distribute certificate settings include scripts, DevOps solutions like Chef or Puppet and in Microsoft PKI scenarios, you can use Group Policy.

 

How to determine if your Windows system is ready for MFA

Windows systems may be easier to work with when it comes to Enterprise Trust but  you have to be skillful to troubleshoot as well. 

 

Windows Tools

  • Certificates MMC snap-in:  This allows you to review all certificate store.
    Note that you have to be a local administrator to view the computer certificate store and that Centrify will add certificates in the local store of systems running the Connector.
    Make sure you review the Enterprise Trust certs in that scenario.Make sure you review the Enterprise Trust certs in that scenario.
  • Certutil:  This is one of the most powerful tools around "certutil -viewstore root" will display the trusted root CAs.

 

Centrify Access Manager

This Microsoft management console provides the capability to perform an end-to-end testing in scenarios where DirectAuthorize Roles are being used for MFA.  You'll need to be at least on version 2016.
am-test.png

This option is under right-click Direct Manage Access Manager > Test Centrify Cloud Connection.

 

Diagnostics and Centrify Logger Service

 

The DirectAuthorize applet provides a "troubleshooting" tab that enables advanced capabilities like Diagnostics or Log inspection.

 

The diagnostics functon has been enhanced to help identify or troubleshoot issues with Identity Platform, this functionality is available if you are running version 3.4 (suite 2017) and above,:
dzwin-diag.png

 

The Centrify logger service is installed with Centrify Server suite.  You can add it to the Centrify Agent for Windows(tm) for advanced troubleshooting capabilities.
dzwin-logger.png

 

Identifying Issues

The Centrify Agent for Windows will provide you visual feedback when there's a PKI-related issue (see below) but internally it's checking the Certificates directory under \ProgramData\Centrify\DirectAuthorize for the binary blob that represents the tenant's certificate.

dzwin-error.png

 In this case, the same solutiona applies, but in this case, we're placing the certificate in the trust store for Windows.

cert-import.png

Like we discussed before, in large Enterprises, ideally Enterprise or Public trust is set up with automation tools or Group Policy.

Microsoft provides a great article on the topic:  https://technet.microsoft.com/en-us/library/cc772491(v=ws.11).aspx

 

 Bottom-line:  When attempting to configure MFA, don't forget this checklist:

  • Is there a PKI trust between the system and the Centrify service?
  • Can the system authenticate via Kerberos?  (is it joined to the domain natively (Windows) or via Centrify (UNIX/Linux))
  • Is the machine added to a Centrify role that allows for Computer Login?
  • Are all the ports required for communication cleared  (8443 or custom)?

 

PKI Trust and Identity Broker

Identity Broker is Centrify's newest capability that allows for multi-directory authentication in private or public clouds.

IB also requires trust for operations like enrollment. 

 

Identifying issues with cdebug

Depending on the state of the Linux system (if the ca-bundle is non-existent, modified or outdated) the enrollment operation will fail.  Let's look at a failed enrollment log using two PuTTY windows.

 

Window 1:  /usr/share/centrifycc/bin/cdebug on
Window 1:  tail /var/centrify/centrifycc.log -f

Window 2: cenroll -t tenant.my.centrify.com -c [code] -F all -l Identity-Broker-Users
Window 2: Failed to initialize connection to Centrify identity platform: Failed to connect to Centrify identity platform
Window 1:
Dec 17 18:16:07 engcen6 cenroll[9201]: DEBUG <centrify/cloud.post> Failed
to post HTTP request: Post https://tenant.my.centrify.com/health/ping:
x509: certificate signed by unknown authority

 This can be further verified with the cURL command:

$ curl https://tenant.my.centrify.com
$ curl: (77) Problem with the SSL CA cert (path? access rights?)

Remediation

In this particular case, my tenant is on-premises Privilege Service, so I  can follow the instructions on this KB:

KB-7973: How to configure Linux machine trusted certificate chain to perform enrollment for Centrify...

The steps are very similar to the ones outlined above.  The strategy depends on the use case Enterprise, Public or Tenant trust is being used.

 

When trying to enroll, the output is very different:

Verbose: Platform detected: centos_6_6_standard
Verbose: Trying to connect to Centrify identity platform [https://tenant.my.centrify.com/] without a proxy...
Enrolling in Centrify identity platform https://bootcamp.my.centrify.com/ using registration code...

Starting Centrify agent...
Centrify agent started.
Verbose: Trying to connect to Centrify identity platform [https://tenant.my.centrify.com/] without a proxy...

Feature enabled: Application-to-Application Password Management
Feature enabled: Centrify Agent Authentication

Verbose: Restarting Centrify agent after enabled features...

You have successfully enrolled in Centrify identity platform: https://tenant.my.centrify.com/

You may need to restart other services that rely upon PAM and NSS or simply
reboot the computer for proper operations. Failure to do so may result in
login problems for cloud users.

 

Constant Improvement

At Centrify capabilities change to provide ease of use and supportability.  We hope this article can help you anticipate issues with your testing or setup.  Ultimately, at the enterprise level, PKI is a vital capability that has to be taken seriously and designed to balance the people-process-technology triad. 

Background

ServiceNow is a very popular IT Service Management solution that includes capabilities like workflow and approvals, asset management, discovery, orchestration and more.  In the previous article, I outlined the steps to set federation with ServiceNow using Multi-Provider SSO.  In subsequent posts we'll discuss how to add ServiceNow workflow and approvals to apps and shared accounts using the Centrify ServiceNow store apps.

 

We'll continue to use the Plan-Do (Implement)-Check (Test)-Adjust (Enhance) methodology:

 

What you'll need

  • A Centrify Identity Service Instance with some published apps
  • A ServiceNow Instance that allows you to install apps from the ServiceNow app store
  • Administrative accounts on both systems

 

Planning

During planning, discuss with your Infrastructure, Operations and Security teams about these topics:

  • What are the source directories for SN users?
    It's possible that there will be AD, LDAP or other directories involved, based on user populations this adds complexity.
  • Will role mapping be used?
    This feature allows the provisioning of the user's ServiceNow role in addition to account creation
  • Are the target Roles created in ServiceNow?
    ServiceNow has several canned groups, however it's possible that your organization needs custom roles for different entitlements.
  • Are the source groups created in the corresponding source Directories?
    Group management simplifies the provisioning on each target Directory.  For example, adding a user to an AD group can simplify the provisioning process.
  • Are the Centrify Roles created based on the information gathered?
    sn-cis-roles.PNG
  • Is the UserID field correctly identified for mapping?  Will any transformations be needed?
    In some implementations it's preferred to use the email address as the unique identifier.
  • What will be the provisioning behavior? Overwrite existing entries or leave as is?
    Sometimes this may or may not be desirable.
  • What will be the deprovisioning behavior? Disable or Delete the user?
    In instances in which important data is left behind on systems, it's better to disable the account instead of deleting it.
  • What will be the behavior when users are removed from a ServiceNow group?
    Users may change functions, therefore this behavior has to be defined beforehand.

 

Implementation

Overview

  • Download and Install the Identity Service App from the ServiceNow App Store
  • Update the State field in the ServiceNow User Role Table
  • Create a ServiceNow User and Assign it a special role
  • Configure Provisioning on the Centrify ServiceNow App

Download and Install the Identity Service App from the ServiceNow App Store

  1. Go to the ServiceNow app store and search for Centrify.
  2. Click the Centrify Identity Service app.
    sn-app.PNG
  3. Click Get to make the Centrify Identity Service app available for your ServiceNow instances.
  4. Go to the ServiceNow instance, select System Applications > Applications > Downloads to locate the app then click Install to install it.

Update the User Role table

  1. In the left pane, search for Tables and select System Definition > Tables
  2. In the tables lab, make sure the Go to picker says name, and search for sys_user_has_role
  3. In the User Role table, click the State field, scroll down to choices and press New.
  4. Add a new field with Label Inactive and Value inactive, then press Update.
    sn-state-inactive.PNG

Create a ServiceNow User and Assign Role

You need to create a service account that will be assigned one of the roles created by the Identity Service app.  This role contains all the entitlements needed for provisioining.

  1. In the left pane, go to System Security > Users and Groups > Users and press New. Then set:
    UserID: username
    Email: username@domain.com
    Active: checked
    Password: type a complex password
    Other fields: are optional
    Press Submit when complete.
  2. Click the user you just created in the list of users.
  3. Scroll down and click Edit in the Roles section.
  4. Search for x_cenr3_centrify_u.centrify_admin and select it.
  5. Click > to add it to the Roles list.
  6. Click Save.

Configure Provisioning on the Centrify ServiceNow App

  1. Log in to Identity Service with a user with at least the Application Management right
  2. Go to Apps > ServiceNow Web - SAML + Provisioning > Provisioning
  3. Check the "Enable provisioning for this application" box. Ideally you'll start with Preview Mode
  4. Configure the connection details:
    Account Name - type the ServiceNow instance ID
    Admin Name - type the name of the previously created SN user
    Admin Password - type the password for the previously created user
    sn-verify-prov.PNG

Other Provisioning Options

The following configuration items respond to the planning section. For example, in my test environment
I've decided to have 3 distinct Identity Service roles that mapped to different ServiceNow roles:
sn-role-mappings.PNG
I chose not to delete users when they are deprovisioned (just disable them) and to do sync overwrites:
sn-prov-options.PNG

Finally, for more complex scenarios, there is the possibility to use custom scripting for transformations and other options:
sn-transform.PNG

Verification

Centrify Identity Service provides several options to verify that provisioning will work as expected.  In the previous section you saw the Preview Mode option.  Using the Admin Portal > Settings > Users > Provisioning gives you the option trigger a sync on all or an individual app.  Once you trigger the sync, you have the option to see the activity.
In my example, I added an AD User (stewie.griffin) to ServiceNow Admins role, and these are the results.

sn-track-job.PNG

Once you have determined that all the provisioning actions are working as expected, you can enable live mode and verify the results in the ServiceNow side.

 

Enhancements

There are different ways to enhance this implementation with additional controls like Multi-factor authentication, controls to have ServiceNow only accessible from inside the corporate network, geo-fencing, etc. Explore Identity Service's policy features.

 

Centrify-ServiceNow Resources

There are multiple resources available in the documentation and tech blogs:

Background

ServiceNow is a very popular IT Service Management solution that includes capabilities like workflow and approvals, asset management, discovery, orchestration and more.  In this post we'll discuss how to use Centrify Identity Service to secure ServiceNow by using the Multi-provider SSO plugin.  In subsequent posts we'll discuss provisioning, protecting shared credentials, using the Centrify ServiceNow store apps.

 

Why secure ServiceNow with Federated SSO?

There are multiple security and operations-related reasons to implement federated identity and SSO for ServiceNow.  A key reason is related to the fact that SN is a SaaS platform, this means that the enterprise is extended and information is accesible outside the enterprise datacenter.  Using federated SSO, allows the use for on-premises identity and access control to secure assets outside the enterprise.  This provides the assurance that only authorized internal users can access those assets.  Another reason is usability with SSO there's no need to duplicate passwords; finally there is the gains in operational efficiency by using a process (like adding a user to an AD group to provision access) or simply disabling the AD user account will disable access to ServiceNow automatically.

 

We'll use the Plan-Do (Implement)-Check (Test)-Adjust (Enhance) methodology:

 

What you'll need

  • A Centrify Identity Service Instance
  • A ServiceNow Instance or a Developer Instance (Fuji, Geneva or Helsinki)
  • Administrative accounts on both systems

Planning

Here are some planning topics for your ServiceNow/Centrify Identity Service Integration

  • What are the user populations that will have access to ServiceNow?  (e.g. AD, LDAP, Google Directory, etc.)
  • What will be the uniquely-identifying field to be used with the SAML assertion?
  • What will be the name for the CIS Role?  (e.g. SN Users)
  • Is the Multi-provider SSO plugin activated in the instance?
  • Will you use the Centrify-provided x.509 certificate?
  • Will the assertion be encrypted?
  • Will provisioning be used?  Are the SN groups created?
  • Will the MPSSO with Centrify be set as default?  Will passwords be eliminated?
  • Will ServiceNow be accessible from inside or outside the enterprise?  Will time or geo-fencing mechanisms will be implemented
  • Should ServiceNow access be protected with multi-factor authentication?

 

Implementation

Overview
These are the high-level steps to configure Centrify Identity Service as a provider for SSO.

  • In Identity Service: Create a Centrify Role that will be assigned the Centrify App
  • In ServiceNow - Activate the "Integration - Multiple Provides Single Sign-On Installer" plugin.
  • In Identity Service - Onboard  the  "ServiceNow - SAML + Provisioning"  template
  • In ServiceNow - Import the x.509 Certificate for the SAML assertion
  • In ServiceNow - Set-up, configure and enable the Identity Provider
  • In Identity Service - Configure the ServiceNow App

Create a CIS role with the ServiceNow users

  1. Log in to the Centrify Identity Service Admin Portal with a user with at least role management rights.
  2. Go to Roles > Add Role; in the Description tab, give it a name.
    sn-role.png
  3. In the Members tab, select the users from the target directory or directories, then press Save

 

Activate the "Integration - Multiple Provides Single Sign-On Installer" plugin

  1. Log into your ServiceNow instance with an administrative user
  2. In the Application Navigator (left pane), use the search feature and type "Plugins", this filters System Definition and click Plugins.
  3. Now in the right pane, next to System Plugins, in Name type  "Integration - Multiple"
  4. Click on "Integration - Multiple Provides Single Sign-On Installer"  (should be set as inactive, if it's not, skip to the next section)
  5. Under Related Links, Click "Activate/Upgrade" and Click Activate
    sn-activate.png
  6. After activation, the "Multi-Provider SSO" Application will be activated in ServiceNow.  This app contains these sections:  Getting Started, Identity Providers, Federations and Administration.
    sn-mp-sso.png

 

Onboard the  "ServiceNow - SAML + Provisioning"  template

  1. Sign-in to Identity Service with a user that at least has the Application Management right.
  2. In the Ad0min Portal go to  Apps > Add Web App, then search for "ServiceNow SAML + Provisioning"
    sn-cis-apps.png
  3. Click the Add button, confirm your selection and close the Add Web Apps window.
  4. In Identity Service, you'll be placed on the Application Settings tab for the ServiceNow app template, scroll down and click on Download Signing certificate
    sn-down-cert.png
  5. Open a text editor in your platform (Notepad, TextEdit or Vi) and open the downloaded file.  Copy the contents to memory.
    (Note:  the contents should be a PEM-encoded certificate)

 

Import the Certificate to the Multi-Provider SSO via x.509 Admin Module

  1. In ServiceNow > Multi-Provider SSO > Administration > x509 certs
  2. New Cert > Give it a unique name
  3. Format > PEM
  4. PEM Certificate >  paste the contents of memory loaded in the previous section
    sn-x509.png
  5. Press Save.

 

Configure the Identity Provider

  1. In ServiceNow > Multi-Provider SSO > Identity Providers
  2. Select New > SAML2 Update 1 > and when the "Import Identity Provider Metadata" pop-up comes up, select Cancel.
  3. At this point, you can use the table on this page to configure the settings.  This is because it depends on your directory source and optional settings.  Here's the configuration for a now decommissioned demo environment:
    sn-config.png
    Notes: 
    - The look and feel of the multi-provider SSO plugin varies between SN versions Fuji, Geneva and Helsinki.
    - The identity provider has to be set to Active and default if you want Service-Provider initiated to be possible.
    - The "Failed Requirement Redirect" is set to the same value as the "Identity Provider AuthnRequest."
    - The location of the x.509 certificate options varies.  You may have to press save to see the option in some versions of ServiceNow.
    - The default field option for the Identity Provider is email.  Modify this setting based on your planning and identity source field mappings.
  4. Once finished, press Save

 

Enable Multi-Provider SSO

  1. In the Multi-Provider SSO app , select the Properties module
  2. Check the "Yes"  box under "Enable multiple provider SSO"
    sn-enable.png
  3. Press Save.  This completes the ServiceNow set-up for SSO.

 

Configure the ServiceNow App in Identity Service

  1. In Identity Service, go back to ServiceNow > Application Settings
  2. If you haven't, type in the instance ID under "Your ServiceNow instance name", then click on User Access
  3. Check the box next to the Centrify Role that was created in the planning phase.  Click on Account Mapping
  4. Because in this example, we're using Active Directory as the user source, we are going to use "samaccountname"
    Note:  that's is the "username" field in Active Directory, therefore, the user ID in ServiceNow must match for each user.
    This is one way to do it, there is flexibility here.  Other common deployments use the email field.
    sn-mappings.png
  5. Testing your work in the Advanced page
    Use the test button with some users in the target role to make sure that the assertion will be correct.
    sn-testing.png

 

Testing

For testing, all you need to do is create an Active Directory Identity Service user and match the User ID in ServiceNow with the user's AD login name (samaccountname) and set it to active. 
sn-lisa.png
Since this will be an SSO user, there's no need to give it a password.  At this point you are set to perform Identity-provider or Service-provider initiated tests.

  • Identity-provider initiated login
    Log in as your AD user, to the Identity Service User Portal.  You should see the user's assigned apps including ServiceNow
    lisa-portal.png
  • Service-provider initiated login
    Go to your instance URL and select external login.  When you type-in the username, you'll either be re-directed to your Identity Service portal for authentication, or if you have a current session (or Kerberos ticket and IWA enabled), you'll be placed in the app.
    sn-ext-login.png

    Note that this behavior can be modified if the SN multi-provider SSO is set as default.

 

Enhancing the Implementation

There are several areas for enhancement, but these come to mind:

  • Enable Provisioning (next blog post)
  • Enable multi-factor authentication
  • Protect shared accounts
  • Enable workflow and approvals

Centrify-ServiceNow Resources

There are multiple resources available in the documentation and tech blogs:

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:

 

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:

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.

 

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

 

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:

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

 

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

  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.

 

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

Community Control Panel