Enabling Centrify Identity Service and Privilege Service for Smart Card Authentication

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 (CIS) or Centrify Privilege Service (CPS) 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 smart card (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_Policy.13.html
Centrify's support for Derived Credentials: 
- Blog: https://www.centrify.com/products/identity-service/emm/derived-credentials/
- Docs:  https://docs.centrify.com/en/centrify/adminref/index.html?version=141#page/cloudhelp%2FderivedCreds.html

This article was originally written as a Centrify Tech Blog.

[Labs] Using Identity Platform as a RADIUS Client to support MFA with OTP tokens (e.g. SecurID, etc)

Background

With the 16.8 monthly release of Centrify Identity Service and Privilege Service, Centrify is adding the ability for the Identity  Platform to act as a RADIUS client.  This will open the opportunity for CIS and CPS users to have authentication profiles for MFA products that support RADIUS (e.g. RSA, Symantec, CA, Vasco, etc).

This lab will allow you to set up a Linux server to act as your AD-integrated OTP+RADIUS server.  Then we'll configure CIS/CPS to act as a RADIUS client and support it as an additional MFA option.

Disclaimers

• This is a lab entry.  Production designs require planning for people, process and technology.
• RSA SecurID, Symantec VIP, Vasco, YubiKey, Google Authenticator, FreeRADIUS and CentOS are registered trademarks of their respective owners.

Lab Design
 The proposed lab looks as follows:

As you can see, we're using the following components:

• Identity Service or Privilege Service (can be the on-premises version of CPS too)
• Cloud connector:  enabled for AD Bridging and RADIUS client
• Centos 6.x System:  this system acts as
  • RADIUS Server > FreeRADIUS configured for PAM
  • Google Authenticator PAM Module > will provide OTP codes for enrolled users
  • Centrify DirectControl > Provides AD integration and NSS/PAM based identification/authentication
• Active Directory:  Provides infrastructure identity services (directory, authentication, policy)

Implementation
In this lab we will not cover the setup of an identity service instance and cloud connector.  Some resources:

• Getting Started with Centrify Identity Service (Microsite)
• Identity Service Support FAQ
• Centrify Support's YouTube Channel
• Identity Service Documentation

 What you'll need:

• A CentOS 6.x system configured in the same subnet as the Cloud Connector or with TCP 1812 connectivity.
• Working knowledge of Identity Service or Privilege Service
• Familiarity with Pluggable Authentication Modules (PAM)
• Basic DirectControl knowledge (install, join AD)
• An OATH OTP client (Google authenticator, Yubico authenticator, etc)

This lab starts assuming that you can log in to your Identity Service or Privilege Service instance with a user with the System Administrator right.


RADIUS+OTP Server Setup
Configuration Overview

1. Adding the EPEL repo to be able to install Google Authenticator
2. Install Google Authenticator
3. Install FreeRADIUS and related tools
4. Configure FreeRADIUS for PAM
5. Install Centrify DirectControl and join Active Directory
6. Enroll users for Google Authenticator OTP
7. Test your configuration with the command line
8. Configure Identity Service/Privilege Service as a RADIUS client

Adding the EPEL repo for Centos 6.x 

$ wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm
$ sudo yum install epel-release-latest-6.noarch.rpm -y
[truncated]
Installed:
  epel-release.noarch 0:6-8

 Installing Google Authenticator

$ sudo yum install google-authenticator -y
[truncated]
Installed:
  google-authenticator.x86_64 0:0-0.3.20110830.hgd525a9bab875.el6

 Install FreeRADIUS and Tools

$ sudo yum install freeradius freeradius-utils -y
[truncated]
Installed:
  freeradius.x86_64 0:2.2.6-6.el6_7   freeradius-utils.x86_64 0:2.2.6-6.el6_7

Dependency Installed:
  perl-DBI.x86_64 0:1.609-4.el6

Configuring FreeRADIUS for PAM
a) User and Group for the Radius Daemon
To  allow the radiusd daemon to traverse the filesystem to read the Google Authenticator config files on each user's home directory, you have to change the user/group in the configuration file.  This may be undesirable in a production environment.
Edit the  /etc/raddb/radiusd.conf and find:

user = radiusd
group = radiusd

Change to

user = root
group = root

and save the file.

b) Enable PAM for the Default Site
Edit the  /etc/raddb/sites-enabled/default  and find:

        #  Pluggable Authentication Modules.
#       pam

uncomment the PAM module and save.

        pam

c) Configure Users for PAM
Edit the  and find

#DEFAULT        Group == "disabled", Auth-Type := Reject
#               Reply-Message = "Your account has been disabled."

uncomment and add the line as follows:

DEFAULT Group == "disabled", Auth-Type := Reject
                Reply-Message = "Your account has been disabled."
DEFAULT Auth-Type := PAM

 Tip:  To check your work so far

1. In one session window, run the radius daemon in verbose mode
   

   $ sudo radiusd -X
   [truncated]
   Ready to process requests.

   If there are any issues with the current configuration, you can verify it with the output.
2. Open another session and create a new user
   

   $ sudo useradd testing
   $ sudo passwd testing
   New password:
   BAD PASSWORD: it is based on a dictionary word
   Retype new password:
   passwd: all authentication tokens updated successfully.
   

   Now you have a user to test your RADIUS server via PAM.
3. In that same session, use the radtest utility with the client set for the localhost client.
   

    radtest testing Mysecret123! localhost 0  testing123       Sending Access-Request of id 204 to 127.0.0.1 port 1812
           User-Name = "testing"
           User-Password = "Secret123!"
           NAS-IP-Address = 192.168.81.34
           NAS-Port = 0
           Message-Authenticator = 0x00000000000000000000000000000000
   rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=204, length=20
   

   On the first window, you'll see the verbose output somewhat like this:
   

   rad_recv: Access-Request packet from host 127.0.0.1 port 53367, id=204, length=77
           User-Name = "testing"
           User-Password = "Mysecret123!"
           NAS-IP-Address = 192.168.81.34
           NAS-Port = 0
           Message-Authenticator = 0x8c11ad4b5c1dbd597764716d95d3d9e3
   # Executing section authorize from file /etc/raddb/sites-enabled/default
   [truncated]
   Sending Access-Accept of id 204 to 127.0.0.1 port 53367
   

   This verifies that things are set up correctly so far.  Cancel radiusd debug (CTRL+C)

Install Centrify DirectControl and Join AD
We'll use the Centrify Repo and join AD in Workstation mode.

$ sudo yum install CentrifyDC -y
[truncated]
Installed:
  CentrifyDC.x86_64 0:5.3.1-398
$ sudo adjoin -w -u [user.name] domain.name
user.name@DOMAIN.NAME's password:
Using domain controller: dc.centrify.vms writable=true
Join to domain:centrify.vms, zone:Auto Zone successful

Centrify DirectControl started.

At this point, if you want another sanity check, you can repeat the same debugging but with an AD user credential.

Configure the Radius PAM directives for Google Authenticator
Edit the /etc/pam.d/radiusd perform two modifications.
Add  this line on the top of the file auth required pam_google_authenticator.so and comment the auth module.
Here what we'll achieve is to provide the Google Authenticator code as our one-time password via RADIUS.  Other combinations of PAM modules can achieve a Password+Code. 
The final result should look like this:

#%PAM-1.0
auth       required     pam_google_authenticator.so

#auth       include     password-auth
account    required     pam_nologin.so
account    include      password-auth
password   include      password-auth
session    include      password-auth

This configuration challenges for the OTP code only and ignores the password.

Enroll an AD user with Google Authenticator

1. Log in with a test AD user to your Linux system
2. Run the google authenticator setup (google-authenticator)
   

   Last login: Thu Aug  4 06:22:50 2016 from 192.168.81.11
   $ google-authenticator
   https://www.google.com/[truncated]  <= copy this URL and paste it on your browser
   Your new secret key is: ETIQLTKPBQV4TVLH
   Your verification code is 2647620
   Your emergency scratch codes are:
     08703664
   [truncated]
   

   Follow the prompts until you complete setup.
3. Paste the URL in a web browser and use your Authenticator QR Capture function to capture the code.
   Alternatively you can add the code manually.
4. Repeat this process for all your test users.

Verify RADIUS functionality with OTP

1. In a session, open Radiusd in verbose mode.  [sudo radiusd -X]
2. In another browser, test the authentication with the code from the OATH OTP authenticator.
   radtest [username] [oath otp code] localhost 0 [pharaphrase]
   In my environment it looks like this:
   

You have verified functionality.

Set up the Cloud Connector as a RADIUS Client
On the FreeRADIUS Server you have to set up the connector as a client.

1. If you haven't done so, close the radiusd debugger.
2. Edit the following file  /etc/raddb/clients.conf go to the end and add:
   

   client member2.centrify.vms {
           secret          = [Insert Complex String Here]
           shortname       = [Friendly Name]
   }
   

   Notes:
   - You can use the IP address or FQDN of your RADIUS-enabled connector
   - You must choose a decent complex string as your secret and save it for the next section.
3. Save the file.

Note:  In some Linux systems/versions you may need to set SELinux to permissive.  This is to allow radiusd to interact with PAM.

Centrify Identity Service or Privilege Service Setup
Overview

1. Configure the RADIUS Server
2. Configure Connector for RADIUS
3. Enable RADIUS in your Policy
4. Enable 3rd Party RADIUS in your Authentication Profile(s)
5. Verify Functionality
6. Modify RADIUS service startup

To configure the RADIUS Server
Go to Cloud Manager > Settings > Authentication > Radius Connections > Servers Tab and press Add
Name: A descriptive name (e.g. SecurID PIN+Code)
Description: Optional
Server IP Address:  The IP address of your server
Port:  Change if not default (1812)
Server Secret:  Must match the secret you set up in the previous step.


Configuring a Connector for RADIUS
You need at least one connector enabled for RADIUS that can reach the RADIUS server.
Go to Cloud Manager > Settings > Network > Cloud Connectors > [connector] > RADIUS > and Check
"Enable connections to external RADIUS servers" 

Also make sure that the RADIUS Client service is enabled.

Enable RADIUS in your User Authentication Policy
Go to Cloud Manager > Policies > [click on the policy that applies to the user(s)] > Expand User Security Policies and Click RADIUS.  Set "Allow 3rd Party RADIUS" to Yes and Save.


Enable 3rd Party RADIUS in any corresponding Authentication Profiles
Cloud Manager > Settings> Authentication Profiles > [click profile that you want to enable] and check
"3rd Party RADIUS Authentication" and press OK.  Repeat with other profiles if needed.


Verify Functionality

1. Launch radiusd in debug mode (sudo radiusd -X) on your Linux system.
2. Trigger a Step-up protected event in CIS/CPS  (private login, secure access, password checkout)
   
   Monitor the debug log for any errors.  If everything goes as expected, keep testing with other users.

Tidy-up:  Set up the Radius Service for Automatic Startup

$ sudo chkconfig radiusd on
$ sudo service radiusd start

Quick Video

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

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. 

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.

Enhancements

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

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

Video Playlist

Centrify Identity Service named in the leaders for 2016 IDaaS MQ

This is a testament to a lot of hard work from Product and Engineering teams.  Tip of  my hat!

Gartner MQ:  https://t.co/8bMQDFFoHG  (must have a Gartner account)
Centrify Blog by Corey:  http://goo.gl/w14ZmM

[Labs] Centrify+AD+Yubikey - Securing Apps, Shared Secrets and Sessions via OATH OTP (Contractors) or Smart Card (Employees)

Background
This is the the third lab in the series around Strong Authentication.  In the previous lab we focused on StrongAuth for UNIX/Linux using PKI Smart Card or YubiKey.
We will be focusing on securing access to Internal web or SaaS apps, shared credentials and privileged sessions using Centrify Identity Service and Privilege Service.

If you're familiar with Identity Service and Privilege Service, they provide built-in step-up authentication like:

• Centrify Mobile Authenticator
• SMS
• Phonefactor
• E-mail
• Security Question

We are going to cover

• YubiKey (Smart Card) for PKI-based auth to Apps secured by CIS and secrets and sessions secured by CPS
• OATH OTP (TOTP/HOTP) using YubiKey or other OATH compatible Authenticator (e.g. Google Authenticator)

Centrify uses Authentication Profiles to control what authentication mechanisms are used in different contexts:
a) Securing access to applications or the Centrify Portal (IDP initiated)
b) Securing access to UNIX & Linux systems
c) Step-up (privilege elevation) for UNIX, Linux and Windows systems
c) Provide RADIUS-based challenges for Cisco, Juniper and other VPN scenarios
d) Securing access to reverse-proxied on-prem applications made available via Privilege Service
e) Secure applications that implement Centrify APIs (e.g. Web, Mobile SDKs)



The challenges

• Web Apps (on Prem or SaaS) need to be protected with strong mechanisms
• Systems that provide access to secrets (like password managers) and secure session brokers also require strong authentication.
• The proliferation of "best of breed" solutions promotes IT fragmentation and limits organizational flexibility. There's no need to have a solution to secure servers, secure apps, provide multifactor and other services.  This promotes complexity.
• Regulatory frameworks (like the upcoming PCI DSS 3.2) stress the use of Multifactor Authentication in sensitive systems.
• Organizations may have already standardized on OATH or PKI authentication and it may be undesirable for them to adopt new mechanisms or train users.

The opportunity

• Both CIS and CPS support Certificate-based authentication (Smart card) and OATH OTP
• YubiKey simplifies the adoption of both mechanisms in a single form factor.

Lab Goals

• Limit application users (on-prem web or SaaS) to strong authentication via Smart Card (YubiKey) or OATH OTP
• Limit privileged users (of shared passwords and secure sessions) to strong authentication via Smart Card or OATH OTP

What you'll need

For All

• Centrify Identity Service or Privilege Service Tenant  (start a trial here) with basic knowledge an account with system administrator's rights

For the Contractor Scenario

• A test user (can be from any source:  AD, LDAP, Cloud Directory, Federated or Social Identity)
• A YubiKey4, NANO or NEO and Yubico Authenticator
  (alternatively, any OATH-compatible authenticator like Google Authenticator will do fine)

For the Employee Scenario

• Active Directory with Certificate Services
• A Certificate provisioned for the user's smart card or YubiKey
  To see instructions on how to set this up, check out the Announcement Post that contains the base lab instructions.
• For SSO to work, the system browser needs to be configured accordingly.
  See this link to configure your browser

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

Scenario Description:
Contractor Access

• Define an authentication profile for login that requires Smart Card or OATH OTP for login to the Centrify Portal
  This will cover any portal-based access (IDP initiated) or unauthenticated service-provider initiated connections
• Request OATH OTP multifactor authentication to access to an application.

Employees with SmartCards

• Define an authentication profile that considers users authenticated with Smart Card as strongly authenticated

Centrify Identity Service (or Privilege Service) Setup for Contractors

1. Sign-in to Centrify Identity Service (or privilege Service) and go to Cloud Manager > Policies.
   At this point you can either create a new policy or work with a new one tied to an specific role.  I am using a Contractors role and tying it to that role.
2. Navigate to Policies > Your Policy > User Security Policies > OATH OTP >
   Allow OATH OTP Integration:  YES
   Show QR code for self service:  [Select your appropriate setting]
   OATH OTP Name:  [type a descriptive name]; I used Google Authenticator or YubiKey
   
   OATH OTP has been enabled, now it's time to enable it for an authentication profile.
3. Navigate to User Security Policies > Login Authentication
   - To configure the policy for login - capture the name of the effective rule (e.g. GlobalAuth High)
   - To configure the profile for secure app access - capture the name of the effective policy.
   Save the policy.
4. Navigate to Settings > Authentication > Authentication Profiles and identify the profiles form Step 3.
   For each profile:
   
   In my example, I'm using a single profile that allows for phone call and OATH OTP client, then Password.

Onboarding OATH OTP tokens for Contractors
This step can be performed in two ways:

• Self-service from  User Portal > Account > Actions > Set up "[OATH OTP name]"
  
• Bulk (this is for larger deployments); from Cloud Manager > Settings > Authentication > Other > OATH Tokens
  
  Use the provided Excel template to perform a bulk import of OATH tokens.

Centrify Identity Service (or Privilege Service) Setup for Smart Card Employees

1. You can reuse the smart card certificate provisioned to YubiKey in the announcement + lab setup post.
2. Upload your PKI trust chain to your tenant using Centrify Support
3. Log in to Cloud Manager and go to Policies > [policy that applies to employees] > User Security Polcies > Login Authentication
4. Edit the "Other Settings" accordingly:
   
5. Press Save

Test Matrix

1. Contractor can self-service enroll their OATH OTP using the user portal
2. Access the Centrify Identity Service (or Privilege Service portal) requires OATH OTP, then password (to protect the user's Password).
   
3. Access a designated application (e.g. Amazon AWS) requires OATH OTP.

Testing for Employees

1. Authenticate using your Smart Card or YubiKey
2. Attempt to access Centrify Privilege Service or Identity service URL or SP-initiated connection.
3. Select the Certificate in the picker.
4. Type the PIN for your smart card or YubiKey
   
5. Depending on how you set up your policy, Smart Card sessions can be set up to bypass additional controls.

Video: Contractor Setup



Other considerations:

• When using self-service onboarding for OATH OTP tokens, allow for a secondary step-up (like phone call) so the user can enroll their OATH token.
• When using self-service onboarding for OATH OTP tokens, be careful about allowing access to QR codes.  Users have to be educated that it is a sensitive operation.   Centrify provides a policy to allow this capability.
  

A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory - Part 2

Background
In a previous entry, I wrote an article titled "A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory" and I described the use of Centrify Identity Platform and Active Directory  to implement enhanced security controls to protect AWS deployments.

In this first part, we'll address how to secure the AWS Root Account.  Amazon suggests protecting the root account with Multi-Factor Authentication, however, in this article I'm describing a strategy to not only meet but exceed the requirements to protect this account.



Enhanced Objectives

• Eliminate sharing of the Amazon AWS root account
• Protect the password by not exposing it to any users
• Limit access only from the corporate network
• Limit access to the AWS account to those with business need-to-know
• Activate MFA with Centrify Step-Up Methods (Mobile Authenticator, Phone factor, SMS, Email, Security Question)
• Activate MFA with Amazon's OATH-based virtual MFA

The Value of Centrify Identity Service
Centrify Identity Service provides a powerful policy engine that allows for the implementation of these controls, not only for the Amazon AWS app, but for any web application that has a user/password authentication pattern and uses a shared account.

As customary, we'll use the Plan-Do-Check-Adjust methodology.

Planning
Role-Based Access Control
- Should the application always be accessible by a limited group of users?
   - Should application access be governed by AD group membership or Centrify Role?
Should the application be accessible to nobody and only requested on demand?
   - Who will approve the application access request?

Additional Controls

• Should the application be accessible only from the corporate network?
• Should the application be accessible at certain times?
• Should the application require step-up authentication.
• What should be the step-up mechanisms? (Centrify MFA, OATH OTP, Phone factor, Email, SMS, Amazon Virtual OTP,  etc)

An example
Access Control will be controlled by AD group membership (e.g. AWS-Root-Users); ad-hoc access will be controlled via workflow. The app will be accessible with a step-up mechanism. The approvers will be an AD group called AWS-Root-Approvers.

Implementation
This implementation steps assume you have a Centrify cloud connector set up providing bridging for an AD domain.

Access Control Building-Blocks
Create the AD Groups

1. In Active Directory Users and Computers, navigate to an OU for a CIS bridged-domain.
2. Create Two AD groups:

- AWS-Root-Users: add the permanently authorized users.
- AWS-Root-App-Approvers: add a set of users that will approve access requests (ideally not the same as above to enforce separation of duties)

Create the AWS Root Role
Members of this role will have permanent access to the AWS Console as root. This is controlled by AD group membership.

1. In Cloud Manager, navigate to Role and Click Add Role
2. Description: AWS Root
3. Members: Go to the Members section and click the Add button and browse for the "AWS-Root-Users" AD group.

 
Create the AWS Root Approvers Role
Members of this role will be able to approve who gets to access this app. This is controlled by AD group membership.

1. In Cloud Manager, navigate to Role and Click Add Role
2. Description: AWS Root Approvers
3. Members: Go to the Members section and click the Add button and browse for the "AWS-Root-Users" AD group.

Configuration in Identity Service
Add and Configure the AWS User/Password App

1. In Cloud Manager, navigate to Apps > Add Web App
2. In the Search Box, type AWS and press Enter, on the results, pick the "Amazon Web Services AWS User/Password" template and click Add.
   
   
   
3. When ask to confirm if you want to add the app, click Yes. This will open the app template for configuration.
4. Description - in this step you will change the name to something descriptive to your environment. 
   
5. User Access - check the box next to the role you created for this purpose (in our example AWS Root)
   
6. Policy - we'll revisit this in the "Adjustments" section.
7. Account Mapping - This is where you'll securely store the AWS credentials. Select
   a) Select "Everybody shares a single username"
   b) Populate the username with the AWS root account email address and the password with the current password.
   
8. Press Save, you're ready for initial testing.

Verification
At this point you can sign-in to Centrify Identity Service with any user in the AWS Root CIS role or an access request can be triggered via the "Add Apps" menu of the User portal.

1. Sign-in to the Centrify Identity Service User Portal with a user from the AWS Root Role
2. You should see the AWS As Root App.  Click on it.
3. This should launch a new browser tab and provide you with assisted injection of the credentials using the Centrify Browser Extension.
4. You can also test the Access Request/Workflow capability by logging in with a user that is not entitled to the application, then click "Add App" and search for the newly-created app. 

Adjustments
Limiting Access only from the Corporate Network
This is desirable if you want to make sure users can only access the AWS console from the on-premises corporate network. The planning steps imply the addition of corporate subnets to the Centrify Identity Service Settings and using the Policy tab of the AWS Root App to enforce these controls.

Adding Multifactor Authentication or Other Controls
MFA is built-in to Centrify Identity Service.  All you need to do is check the box, and provided there's an authentication profile that will support the step-up methods you will be set.

Enhancements of CIS 2016.2
Amazon AWS provides an virtual MFA capability that leverages OATH.  As of February 2016, Centrify allows you to use any OATH based OTP mechanisms, this means that you can leverage those mechanisms as well.

Video Playlist

[LABS] Testing MFA for Servers (Step-up Authentication) feature of Centrify Suite 2016

Background

Step-up authentication can provide additional security controls to prevent unauthorized access to systems or controlled privileged elevation.  Server Suite 2016 uses the established step-up authentication methods of Centrify Identity Service (Token via Centrify Mobile Authenticator, SMS, Phone factor, E-Mail and User-defined security question); the key differentiators are the combination of Role-Based Access Control (RBAC) with step-up authentication and context awareness (time/access/privilege).

To complete this lab you need:

• Familiarity with Centrify Server Suite consoles:  Access Manager
• Familiarity with Centrify RBAC concepts:  hierarchical zones, role definitions, role assignments
• Familiarity with Active Directory and tools:  AD users, security groups, Active Directory Users and Comuters
• Familiarity with TCP/IP:  ports, protocols

You don't need to be familiar with Centrify Identity Service.  We will outline the set-up steps for this configuration.

Planning

Potential Stakeholders

• Centrify SME:  These users are entitled to perform management of zone operations inside Active Directory.
• Security Lead:  The security lead can answer questions like these:
  a) What servers require step-up authentication for login?
  b) What privileged actions require step-up authentication?
  c) What servers require step-up authentication based on day/time?
• IT/AD Infrastructure lead:   This SME will help setting up a Windows Server to act as the cloud connector

Technical Requirements
Active Directory and Centrify

• A licensed or evaluation copy of Centrify Suite 2016
• An Active Directory test or production environment with Centrify a Centrify Hierarchical zone
• A UNIX/Linux system with Centrify DirectControl 5.3+
• A Centrify Identity Service tenant with at least one Cloud Connector acting as an Active Directory bridge
• For step-up methods (user-defined security question can be used if none below are available):
  a) an iOS or Android device for token testing (optional)
  b) a mobile phone to test SMS
  c) an e-mail account
  d) a phone line for phone factor

Software as a Service (Cloud) - Quick Security/Assurance FAQ

1. What is Centrify Identity Service (CIS)?
   CIS is an Identity as a Service (IDaaS) that provides Identity, Single Sign-On, Mobility Management, Policy and Multifactor Authentication among other capabilities. The service is "connector-based";  this means that there's a server running on premises that communicates with the service.  This is a very common architecture used by solutions like ServiceNOW or Office365.
2. Why is a SaaS solution required to provide multi-factor authentication?
   The answer boils down to time-to-production, cost and efficiencies of a software as a service solution versus the overhead of an on-premises alternative.  Centrify is re-using their existing Identity Platform and extending it to Server Suite.
3. What are the mechanisms that Centrify implements to provide assurance for confidentiality?
   Each tenant gets their own key and PKI Certificate Authority, this provides the assurance that:
   a) only the tenant owner can decrypt traffic that has been encrypted at rest or in transit
   b) the cloud connector will repudiate connections from any other source
   c) an additional layer of encryption is provided in addition to SSL
   The cloud service and the cloud connector must be authorized by two parties:  the tenant admin and an AD admin.
4. What are the mechanisms that Centrify implements to provide high-availability?
   a) CIS runs on top of Microsoft Azure.  Azure provides hardware, datacenter, nearby datacenter and geographical datacenter redundancies.
   b) Centrify implements mechanisms that guarantee that upgrades don't cause downtime
   c) Cloud Connectors are constantly monitored for health and failover is automatic
   d) In the context of Server MFA, the tokens and SMS contain a code that can be used asynchronously
   e) In the context of Server MFA, roles with rescue rights are available;  this allows the bypassing of MFA in case of a disaster.
5. Are the Cloud Connector public facing or in the DMZ?
   No.  Cloud connectors aren't required to be public facing or in your DMZ; they can be inside your private network and even can work behind a proxy server.  The cloud connectors will establish an outbound HTTPS connection.  The documentation explains target sources and destinations.
6. Is outbound Internet access required for systems that use the MFA for servers feature?
   No.  The systems only need to talk to the on-premise cloud connector in a mutually authenticated, encrypted and configurable port, in turn the cloud connector validates if the systems are authorized for MFA and acts as a broker with our Identity Platform.
7. What other assurance mechanisms are provided by Centrify for their Cloud Solutions?
   Certifications:  SOCII, SafeHarbor, TrustE.  Centrify is working on FedRAMP certification attainment.
8. Where can I find more information?
   For more information:  http://www.centrify.com/support/centrify-trust/trust/

Resources

• Centrify Administrator's Guide for Linux and UNIX
• Centrify Identity Service Documentation
• Centrify Identity Service Getting Started Guide
• Useful tools:  Test Centrify Connection applet, adinfo --sysinfo cloud

How MFA for Servers Works

Components:
Active Directory

• Centrify Zones contain:
  - Identity data in the form of UNIX RFC2307 fields for provisioned users and groups
  - Authorization (DirectAuthorize) information:  definitions of roles and attributes, rights (commands) and role assignments.
  - Information about the Centrify Identity Service tenant if there's a registered cloud connector in AD
• Roles can have two MFA-relevant attributes:  "require multifactor authentication" and "rescue rights";  if the first one is checked, users will be prompted to provide step-up authentication to access the system;  if the second one is checked (just like with DirectAudit) all the additional security controls will be bypassed.
• UNIX commands that have the "require multifactor authentication"  this will prompt the user to provide their password and a step-up authentication method on privilege elevation.
• Test AD users:  The test AD users need to be UNIX-enabled and have populated attributes like email, telephone or mobile number if email, phone factor or SMS will be requested.

Centrify Server Suite

• These are DirectControl agents 5.3+ joined to a hierarchical zone.  These systems don't need outbound connectivity to the internet.
• The AD computer objects need to be authorized to talk to the cloud service (via role) and they should be allowed to communicate to the cloud connector using HTTPS in the web service port (8080 is the default). 

Centrify Identity Service

• MFA Computers Role:  This role contains the systems authorized to request MFA.  This can be individual computers or AD groups that contain the AD computer objects.  They must have the Server Login and Privilege elevation right.
• Server Authentication and Privilege Elevation Authentication Profiles:  You can define what step-up methods are available and even if there's additional mechanisms to be used.
• Policy:  A policy that applies to the MFA Computers role needs to be implemented.  This method should allow for Integrated Windows Authentication via Kerberos for machine-to-machine authentication

Cloud Connector

• This is a Windows system that runs the adproxy service.  The cloud connector only requires an outbound HTTPS connection to talk to the Centrify Identity Service tenant. 
• Web Service: The cloud connector authenticates authorized agents using Integrated Windows Authentication (SPNEGO)

 The illustration below provides an oversimplified set of steps:

Note that in case of AD connectivity failure, the centrify agent will use the AD methods (sites/services, offline cache) and it also caches the authorization data.

A Basic Lab Design

In my test environment I have:

Description

1. A Centrify Identity Service tenant App Edition (or 30-day trial)
2. An Active Directory domain (centrify.vms) with a single domain controller (dc.centrify.vms)
3. A domain-joined server called "member" that has Access Manager installed (Suite 2016 commercial or evaluation)
   Member will also be running the Centrify Cloud Connectors
4. A Centrify zone called global with 2 computer roles:  App Servers and Web Servers
5. Two Linux servers.  The names may be slightly different given that I have labs in different stages.
6. A mobile device with a phone line running iOS or Android.

Test Cases

Test Name	What you need	Comments
Step-up on Privilege Elevation	You need a UNIX command with the “Require Multi-factor authentication” flag set.	Ideally you will start with privilege elevation, that way you can do troubleshooting if needed.  Test with two users with the same role, one with password, the other one with password and MFA required.
Step-up on Server Access Elevation	You need a role with the “Require Multifactor Authentication” flag set.	If using SSH for testing, be mindful of SSH timeouts.  You can extend timeouts for your testing or enroll a device so you have push MFA.
Time Context-aware privilege elevation	You’ll need two roles, one without MFA time-bound for business hours, the other one with MFA for after hours	This is an excellent use case because reflects a real-world scenario.  A variation of this test case can be No MFA on QA/Dev and MFA on Prod systems.  You can leverage Computer roles for this.
Privilege Elevation without AD connectivity	This test relies in the agent’s caching capabilities.	This is a disaster recovery use case.
Privilege Elevation with out-of-band method	You need an enrolled mobile device to access the mobile authenticator (or you can type the code delivered with an SMS)	In cases in which you can’t receive a phone call or SMS, you need the code to provide step-up auth (e.g. like token based solutions)
Disaster Scenario.  There are no cloud connectors, the CCs can’t talk to the Centrify Service or MS Azure/Centrify Service is down	You’ll need a role with the “Rescue Rights” checkbox set.	This should be familiar to DirectAudit testers;  Rescue rights are granted to overcome an issue with the Centrify functionality (Audit or MFA)

Implementation

Download and Install the Centrify Suite 2016 bits

1. Download the Standard Edition 2016 Consoles
2. Download the Centrify client bits for your platform
3. Install Access Manager
4. Install or upgrade your agents  (e.g. install.sh, rpm or yum, apt or dpkg, etc)
5. Join a zone (use adjoin)

I will recycle the pre-requisites video for the local account management since the steps are identical:

Obtain and Configure a Centrify Identity Service Tenant

1. To obtain your Tenant
   Follow the steps here:  http://www.centrify.com/free-trial/identity-service-form/
   Follow the steps until you activate your tenant and log in with the cloud admin account for the tenant.  You have to secure those credentials.
2. Set up a Cloud Connector (Settings > Cloud Connectors)
   You can see steps here (download-install-configure-authorize).  Other than the "next-next" steps here what needs to be understood is what is the Cloud Connector doing.  The Centrify cloud connector service runs on Windows and provides AD bridging.
   a) The CC talks to the cloud service on behalf of your servers; uses PKI for trust and non-repudiation.
   b) The CC makes outbound connections  over HTTPS that are double-encrypted (SSL + tenant key)
   c) it has to be authorized to read objects from the AD domain by a privileged AD administrator
   d) The CC needs to authenticate the systems (or group of systems) that will use step-up using SPNEGO over 8080 (default)
   Note that if your're working in an isolated lab, this port has to be open between your Linux systems and the CC.
   e) The CC will provide information to the cloud service about email, phone numbers, etc so the user can get the step-up challenge
   f) For MFA testing, you can disable all other capabilities of the CC (like LDAP bridging and App gateway) to keep configuration to a minimum.
   
3. Configure Authentication Profiles (Cloud Manager > Settings > Authentication Profiles)
   You need to set up authentication profiles for both Server Access and Privilege elevation.  For this go to .  Here's what I set up for Server Access:
   
   What to use for Step-up:  You'll need to use your security savvy here.  The goal is to provide an additional control in case of password compromise.  You would not use email in this case because in an Exchange scenario, the password is the same for the AD user so if a threat agent compromised the user's password, they likely have access to his email.  The best course of action is something the user has like a token or his phone.  That's why I only checked those options.
4. Set the Server Suite Authentication Profiles (Cloud Manager > Settings > Server Suite Authentication)
   Set the APs for Server Access and Privilege Elevation
   
5. Create a Role that Contains your Linux Systems (Cloud Manager > Roles)
   In my case, I created an "MFA Computers" cloud role and as members I added an "MFA Computers" AD group that in turn contains my Linux systems.  This simplifies administration because if I want more Linux systems enforcing MFA, all I need to do is upgrade them to 5.3 and add them to that AD group.
   
6. Policy Applied to MFA Computer with IWA  (Cloud Manager > Policies)
   We need to verify that Integrated Windows Authentication is allowed for the User Policy that applies to this role.  This will allow the servers to use Kerberos to authenticate to the web service on the cloud connector.  This is under Policy (e.g. Default Policy) > User Security Policies > Login Authentication
   
   Ideally, to isolate MFA testing, you will create a new Policy that applies just to the MFA computers role and you stack it higher than your deny-all policy.
   

Configure Access Manager for Centrify Identity Service Tenant

1. Open Access Manager and open your Zone. 
2. Right-click the zone and select properties, click on the Cloud tab and click Browse
   There is now a selectable cloud instance.  This is because of the cloud connector registration.
3. Select and press OK twice.  Now you can test end-to-end connectivity using the Test Cloud Connection tool
   
   You have to right-click the "DirectManage Access Manager" node to expose the tool.

Verify that your Centrified Linux system is Cloud Connector-aware
You need to refresh the cache and restart the agent to reflect the AD group membership that will allow the system to interact with the cloud connector.

1. Sign in to your system (with a user that can elevate)
2. Run adflush --force
3. Restart the CentrifyDC service (service centrifydc restart)
4. Run the 'adinfo --sysinfo' cloud command to verify cloud connector awareness.

$ adflush --force

DNS cache flushed successfully.

Authorization cache store flushed successfully.

GC and DC caches flushed successfully.

$ service centrifydc restart

Stopping Centrify DirectControl:                           [  OK  ]

Starting Centrify DirectControl:                           [  OK  ]

adclient state is: connected

$ adinfo --sysinfo cloud

System Diagnostic

==============Cloud/Connectors info============

Cloud instances:

   Cloud in connection: https://aaj0736.my.centrify.com:443/

   Cloud: https://aaj0736.my.centrify.com:443/

Cloud connectors:

   Current used connector: member.centrify.vms

   Cloud connectors in current site:

      Cloud connector: member.centrify.vms

        Cloud URL: https://aaj0736.my.centrify.com:443/

        Connector Site: Demo-Network

        Proxy FQDN: member.centrify.vms

        Tenant ID: AAJ0736

        Connector port: 8080

        Connector IWA HTTP port: 80

        Connector IWA HTTPS port: -

   Cloud connectors in other site:

   Cloud connectors discarded:

   Cloud connectors in current site and unused:

   Cloud connectors in other site and unused:

   Cloud connectors invalid:

==============Cloud auth token info============

CloudAuth tokens maximum: 10

Current count: 0

Current timestamp: 1454536466

Occupied tokens:

You're all set and ready to test.

Video Playlist