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

Many governmental and commercial organizations have implemented smart cards as their preferred method for Multi-factor Authentication.  This post explains how to configure Centrify Identity Service or Centrify Privilege Service to provide authentication using Smart Cards.  This article provides the configuration steps to enable Smartcard (certificate)-based authentication for CIS or CPS.

 

How it works

Generally, cryptographic credentials (user certificates) are stored in the smartcard (PIV or CAC card) and the system has a dedicated reader.   Upon successful authentication (credentials verified and PIN submitted) the operating system or application will use a standard protocol (like Kerberos) or a one-time-code to grant access to the system or application.

 

For example, Centrify Server Suite allows the user of Kerberos for SSO to applications like Secure Shell (SSH).  Our DirectAuthorize can enforce if the user is allowed to log in with a password or with Kerberos/GSSAPI only.

 

In the case of Identity Service and Privilege Service, we use a Centrify capability called Zero Sign-on (SZO).  SZO provides a one-time token to use for authentication if the Authentication Profile that applies to the user is configured for Certificate-based Authentication.  All the user needs to do is navigate to the CIS/CPS site, select the smart card certificate and PIN.

This setup provides strong authentication to access Apps or for Privileged Identity Management scenarios.

 

What you'll need:

  1. An instance of Centrify Identity Service App+ or Privilege Service  (CPS can be SaaS or On-Prem)
  2. Public Key Infrastructure Infrastructure  (Enterprise CA, Revocation Infrastructure, well-configured PKI clients) and understanding of how the subject name is being provisioned.
  3. A copy of the Certificate Chain (or Root CA) for your PKI infrastructure.
  4. A SmartCard or Yubikey configured for authentication into your environment.
    This post contains instructions to set up a lab. See "Lab - Base Setup"

Strong Disclaimer:  This is a PKI-related topic.  You should always be workign with your PKI SME with anything related to certificates, trust chains, revocations, etc.

 

Configuration Overview
The configuration depends on the deployment option of the service.

 

  1. Configuring the Root CA in Identity Service App+ or Privilege Service
  2. Configuring a Policy that allows for Integrated Windows Authentication
  3. Testing the configuration
  4. Appendix:  Configure Privilege Service On-Premises CNAME and Zero Sign-on SSL Certificate

 

Configuring the Root CA in Identity Service App+ or Privilege Service (SaaS)

  1. Sign-in to Cloud Manager
  2. Go to Settings > Authentication > Certificate Authorities
    Note:  If you can't see the Certificate Authorities option, you're not running the App+ edition or in the case of Privilege Service on-premises, you have to perform the activation steps (see below).
  3. Press Add and complete the follwing information:

    Name:  descriptive name of the CA
    Extract login name from:  The options are
    a) Principal Name from Subject Alternate Name
    b) E-mail address field from Subject Alternate Name
    c) Username from Subject
  4. Click Browse and select the location of the root ca certificate.
  5. If you are confident that you have a highly-distributed (Internal & Internet facing) Certificate revocation infrastructure, check the "Enable Client Certificate Revocation Check" if you are not sure un-check the box for now.
    Note:  If you don't know what PKI certificate revocation is, it's time to find your in-house PKI expert and get him or her involved.  This is a serious topic.
  6. Press Save

Configuring a Policy that allows for Integrated Windows Authentication

  1. Sign-in to Cloud Manager
  2. Go to Policies > [Select your Test Policy] > Expand User Security Policies > Login Authentication
  3. Set the "Enable authentication policy controls" setting to Yes, if not selected.
  4. Scroll down to "Other Settings" and make sure that the "Allow IWA connections..." is checked.  Then note the following:
    Note: Certificate-based authentication bypasses the login authentication rules set up for that profile.  The key settings are:

    The first setting "Use certificates for authentication..." is the main switch.  If you un-check this box, the users in scope for this policy won't be able to use smart cards for authentication.  This bypasses any controls set under "Login Authentication" in the preceding section.
    The second setting  "Set identity cookie..."  controls whether the cookie is set for the browser.   I would not set this flag if you expect users to access via non-managed systems.
    The third setting "Accept connections using certificate..." defines whether if users logging in with smart cards or certs are treated as "strongly-authenticated"

    Make your selections based on your desired security posture.
  5. Press Save.

 

Testing your configuration

  1.  Navigate to your Identity Service or Privilege Service URL
  2. Depending if your browser is configured correctly, you'll see any of the following pop-ups will come up:
  3. After selecting the Certificate on the Smart Card, you'll be prompted for the PIN:
  4. Once you type-in the PIN, you'll be redirected to the appropriate portal (User | Cloud Manager | Privilege Manager).

 

Quick Setup Video

 

 

Appendix 1:  Enabling Certificate Authorities for Centrify Privilege Service (On-Premises)

Background:  Centrify Privilege Service can be deployed on premises on a Windows Server 2012 R2 system.  You need a CNAME record for the Zero Sign-On website and a x.509 certificate with that DNS name.

 

Pre-requisite tasks:

a) Set-up a DNS CNAME record to with the name hostname[zso].domain.name pointing to the hostname.domain.name.  E.g. if your system name is app1.corp.contoso.com, create a CNAME record to app1zso.corp.contoso.com and point it to the original host name.

b) You need an SSL Certificate with the DNSname for the SZO special host. 

 

  1. Log in to the server hosting Centrify Privilege Service
  2. Open an Administrative PowerShell and navigate to %Programfiles%\Centrify\Centrify Identity Platform\Scripts
  3. Run the setup_certauth.ps1 script.   The program will ask if the pre-requisites have been met.
  4. Confirm and you'll be prompted to provide the x.509 (SSL) cert for the SZO site.
  5. Once completed, you can return to Cloud Manager and perform the steps outlined above in the:  "Configuring the Root CA in Identity Service App+ or Privilege Service (SaaS)" section.

 

Other Resources and Related Topics

Documentation:  https://stage-docs.centrify.com/en/centrify/adminref/index.html?version=141#page/cloudhelp%2FCloud_Po...

Centrify's support for Derived Credentials: 
- Blog: https://www.centrify.com/products/identity-service/emm/derived-credentials/

- Docs:  https://stage-docs.centrify.com/en/centrify/adminref/index.html?version=141#page/cloudhelp%2Fderived...

Showing results for 
Search instead for 
Do you mean 
Labels
Leaderboard

Community Control Panel