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

Background
This is the third article in the series titled "A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory" in the previous post we discussed how to secure the Amazon Root account.
In this article we'll discuss how Centrify can secure Amazon Identity and Access Management by leveraging Active Directory or any other supported Identity Source. 

About Amazon AWS Identity and Access Management (IAM)
For those who aren't familiar with Amazon IAM, it provides capabilities that allow organizations to centrally manage Users, Roles, Rights and Policies efficiently for all services (compute, storage, database, application) provided by the platform. 

Another Identity Silo
Each time a new infrastructure or application is introduced, it has the potential to create another identity silo, Amazon AWS is not the exception.  Large organizations often find themselves duplicating effort by managing their own enterprise directory (like AD) and also having to manage the directory out in the IaaS or SaaS provider.
Many of our customers and prospects due to timing of adoption or while developing cognitive knowledge, find themselves manually managing Amazon IAM.  The typical tasks include user creation, credential/password/key management, password resets, group/entitlement management and attestation. The basic IAM best practices are outlined when you log in to the IAM dashboard:



Once we adopt this "dual-management" we are promoting IT fragmentation, the potential consequences are complexity, limited productivity and possible security expose.  Finally, depending on the data classification or risk profile of the assets in AWS, this identity silo is subject to the corporate security policy (password policies, user attestation reporting, least access management, etc.)

In the past few years, Amazon has recognized this challenge and provides vast extensibility to IAM, via APIs and using standards like SAML and OpenID Connect. 

This article provides a practical example that not only meets but exceeds the best practices around Amazon AIM, eliminates dual-administration and aligns administration with internal policies.

Using Centrify CIS & Active Directory to Secure Amazon's IAM
In this post I describe a framework to leverage Centrify Identity Service  to meet and exceed the Identity Management requirements for Amazon AIM while maintaining the corporate directory (AD) as the single-source of truth. 

The example used in this blog post focuses on Active Directory, however, those who are familiar with Centrify know that the user sources can be or any other internal LDAP source, Google Directory, Federated Partner or even Social Identity providers.
The solution outlined below establishes a SAML federation agreement between Centrify Identity Service (CIS) acting as the Identity Provider (IdP) and Amazon AWS IAM acting as as the Service Provider (SP);  Since CIS will be using Active Directory principals as an identity source, AD continues to be the single-source of truth for the enterprise and AD group memberships, AWS IAM Roles and CIS roles can be used to manage entitlements.

Enhanced Objectives

• Eliminate duplicated administration efforts and align Amazon IAM users with corporate policy
• Leverage AD Group membership (or CIS Roles) for Amazon IAM provisioning (add/moves/changes/deletions)
• Leverage AD Group membership (or CIS Roles) and IAM Groups for Entitlement Management
• Provide SSO to Amazon AWS with minimal federation infrastructure required
• Enforce Advanced Policies: Require Multi-factor Authentication or Enforce Access from the Corporate Network
• Limit access to IAM credentials to those with business need-to-know

Planning
Stakeholders

• Identity and Access lead:  Organizes and coordinates the effort.
• Security SME: Outlines the security requirements based on policy or risk profile
• Infrastructure SMEs: Execute the implementation of the tasks

Planning Discussions
Below are planning discussions that can be had around IAM:

1. What are the services being used in AWS? Will there be a process defined when new services are used?
2. Are there any AWS IAM Groups that provide separation of duties (e.g. EC2 Management vs. IAM Management)?
3. Will Active Directory Groups be mapped to AWS IAM Groups? or Will Centrify Roles be used?
4. Will contextual policy be needed?  E.g. restrict access to corporate sites, geo-fencing or time-fencing?
5. What will be the attestation process for AWS users?  (e.g. AD Group Management or CIS Roles/Reports)
6. Will Multi-factor authentication be required for IAM users?  What factors (Centrify MFA, Amazon Virtual Token (OATH), SMS, Phonefactor or Email?
7. Will approvals be required for IAM access?  (Request/Approval)
8. Will just-in-time provisioning be used (E.g. AD group addition triggers an AWS IAM provisioning)?
9. Will SAML, OpenID Connect or Amazon's API be used to establish AWS integration? 
10. Will users be allowed to log in with their AWS password or just with SSO?
11. How will users be uniquely identified in AWS? (should shortname, email, UPN or another field be used?)

 Our Example

• The organization uses Amazon EC2 to hosts servers in the cloud
• There are two types EC2 of users:  Users with Full Access and ReadOnly Users.
• Users with full access will be managed via AD Security group Membership (AWS-EC2-FullAccess)
• Users with read-ony access will be requested on-demand (must be approved) via a CIS Role;
• Another group (AWS-IAM-Managers) can manage IAM in AWS and will approve requests.
• All users must provide step-up authentication via Token, Email, SMS or Phone to access AWS
• The implementation will use the Centrify-provided SAML template
• The Centrify-Provided PKI Certificate will be used for the SAML Assertion
• Users will be identified in AWS with their Shortname.

 Technical Requirements

• Active Directory with security groups created and populated
• Centrify Identity Service Tenant
• A Member Server running the Centrify Cloud Connector with the AD Proxy capability enabled and connected
• An Amazon AWS Account and a user with IAM rights to create an Identity Provider and Roles

Implementation
This process implies a partial configuration in CIS, followed by the configuration in AWS, finishing-up in CIS again.

Initial Configuration in Centrify Identity Service
Add and Configure the Amazon Web Services (AWS) Console: SAML+Provisioning

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 Console SAML+Provisioning" 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. In Application Settings:
   - Type your AWS Account ID (if you don't know it, go to "My Account" in AWS)
   - Click the "Download SAML provider metadata document"  link, this will save the XML file in your downloads folder
   
5. In Description, give the application a descriptive name (e.g. AWS Role-Based SSO)
6. Skip User Access and Policy (we'll revisit)
7. In Account Mapping , use the "Use Account Mapping Script" option and type the following:

   LoginUser.Username = LoginUser.Shortname

   This option will send the user's shortname as the identifier.  If there are duplicates, you can switch to mail or UPN.
8. Press Save, you'll have to return here for adjustments.

Configuration in AWS
Create the Centrify SAML IDP

1. Sign-in to AWS and navigate to Security and Identity > Identity and Access Management
2. On the left pane, click Identity Providers and press the Create Provider button on the right
3. Select SAML in provider type
4. In provider name type a descriptive name like "Centrify" or "CentrifySAML"
5. In Metadata Document, browse to the downloads location where the XML file from step 4 above was saved, press Next Step and press Create.

Configure the AWS IAM Roles for the Centrify SAML IdP

1. On the Amazon AWS IAM Dashboard, Click Roles > Create New Role
   The names of the roles about to be created must match the role names in Centrify Identity Service.
2. Example: EC2 Administrators - this role grants the ability to manage all aspects of EC2 instances, therefore a policy that matches that entitlement has to be tied to the role.
   Name: AmazonEC2Admins
   Role Type:  Role for Identity Provider Access > Grant Single Sign-On (WebSSO) access to SAML providers [Select]
   Establish Trust:  SAML Provider > Select Centrify > Press Next Step
   Verify RoleTrust: Press Next Step
   Attach Policy: type "AmazonEC2FullAccess" and Check the box
   This corresponds to the administrative role for EC2 instances
   Review:  Press Create Role
3. Repeat the process for the rest of the roles.  Make Sure that you are writing down the names of the Roles.

Finishing the Configuration in Centrify Identity Service
Create and Populate the Centrify Identity Service Roles

1. In Cloud Manager, navigate to Roles > Add New Role
2. Name: AmazonEC2Admins  (must match the name of the corresponding role in AWS)
3. Members: Populate based on your requirements.  For AmazonEC2Admins I'm leveraging AD membership
   
4. Press Save.
   Repeat with any other roles created in AWS

Complete the User Access Section of the AWS Role-Based SSO App

1. In Cloud Manager, navigate to Apps > Click your AWS SAML App
2. Go to User Access and check the box on the roles you've created.
   
3. Press Save, you are ready to verify.

Verification
At this point you can verify access.  If using Active Directory, simply add a user to any of the AD Security groups that grant access and the user will get the App automatically.  Upon clicking on it they'll be able pick the role (or roles, in case of multiple entitlements) and simply press sign-in.

They should only be entitled to the activities allowed by the policies associated with the role.  For example, in the case above the user will only be able to manage EC2 instances and details, no more than that.


Adjustments
Adding Multifactor Authentication , Limiting Access from the Corporate Network and Workflow and Approvals

• 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.  These include and are not limited to:  Centrify's Mobile Authenticator, Phone call, SMS, Security Question, Email or OATH Based OTP (Duo, Google Authenticator, Amazon Virtual OTP)
• To limit access based on the corporate IP range, all you need to do is populate the NAT addresses for the organization and check the appropriate box.
• To establish a workflow and approvals scheme, a role needs to be designated as the approver, see the video playlist below or the one included in part two to view the particulars.

Provisioning of IAM Users
There are instances in which it is desirable to have a provisioned user inside AWS IAM.  What needs to be reconciled is if users will know their IAM passwords, in that case they can go directly to the sign-in page and bypass the controls outlined above.  We can extend the SAML template to provide provisioning capabilities as well.

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

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

In Depth: Centrify Privilege Service (August 2015)

What's Centrify's Privilege Service (CPS)? 

CPS is Centrify's complement to the existing Privilege Management capabilities offered by Server Suite.  The focus is on Shared Account Password Management (SAPM), Privilege Session Management (PSM) and more.

Platform shared capabilities

• Active Directory Integration:  CPS uses Centrify's leading AD Bridging capabilites to provide organizations AD integration to the solution.  It leverages the assets of Centrify Identity Service (formerly known as user suite).
• Single Sign-on (SSO): When users have an authenticated Windows session, if configured by the administrator and with a supported browser, the privileged users will get SSO to the portal or apps.
• Password Wallet:  Users and Administrators can use the built-in password wallet for Web Apps that 
• Multi-factor Authentication:  The platform uses several mechanisms for MFA (Centrify Mobile Authenticator from the registered device's Centrify app, one-time-passwords using SMS, E-mail link, or voice call placed to the user's business or mobile phone.
• Geo-Fencing: Identity platform leverages geo-location for several purposes: access policy, smart MFA, reporting and analytics.
• Multiple Identity Stores:  CIS today supports users from connected or disconnected (no trust-relationship) Active Directory forests, but also users form the Centrify Cloud Directory or LDAP; (the list of sources grows as I type).
• Per-App VPN (reverse-proxy):  Allows the elimination of persistent VPN connections and provide remote access just to the individual application.
• Role-based Access Control:  System access, and system rights are all based on roles that can be assigned to users from any source.
• Federated Identity Support:  Enable user access to applications or resources from your partners with a few simple steps.
• User Access Request (Workflow and Approvals):  Access to apps, login sessions to servers, password checkouts and more can be tied to requests and approvals built-in to the platform.
• Enterprise Mobility Management:  In the modern enterprise, with apps being accessed from anywhere, mobile phones/tablets being used as secondary factors of authentication, providing MDM, MCM and MAM is very important and this has been a key capability for iOS, MacOS, Android and other platforms.
• Self-Service Capabilities:
• App portal for a consolidated view of the user's apps and servers
• Device portal to allow the user to enroll and manage their devices
• Activity portal to self-review activities
• AD or Cloud user self-service password reset
• Self-Service from Mobile App
• Management Portal:  Wizards, Dashboards, Apps, Policies, Roles, Reports, Settings, etc.
• Simple architecture:  On-premise capabilities like AD Bridge, App Gateway (reverse-proxy), support for LDAP are available by installing components that sit behind the corporate firewall (even behind the Proxy).
• Datacenter and geographical redundancy plus multi-language:  The Identity platform is distributed across Microsoft's Azure infrastructure and it has been translated to over 15 languages.
• PKI - Certificate Services:  An independent built-in Certificate Authority for each tenant to provide additional encryption services, mutual trust and authentication using PKI certs in the context of data at rest and in transit, federation assertions, end-point certificates, etc.
• Bottom-line:  CIS is a full-fledged Identity as a Service (IDaaS) solution that eliminates the need for complex federation infrastructure and can be used for multipurpose scenarios of over 3,000 apps.  

Privilege Service capabilities

• Privilege Session Access:  CPS provides the ability to access system resources from a central set of servers (jumpbox).  The CPS infrastructure components can be deployed in a few minutes anywhere the organization has IT footprint.
• Privilege Session Proctoring and Session Abort:  Allows a supervisor to view remote sessions in real time, as well as triggering remote disconnections.
• Shared Account Password Management lifecycle management:  CPS provides the ability to request access to, check out, check-in and rotate passwords in Windows, UNIX, Linux and a variety of network devices.
• Mobile First:  Remote access and Password operations are available from the Centrify mobile app with PIN or bio-metric compatibility.
• Self-Service Workspace:  Provides the privileged user with a consolidated view that includes status of their password checkouts, sessions, recent and favorite resources.
• Privilege Session Recording:  Leverages Centrify's DirectAudit to provide proxy-based auditing or end-to-end auditing if Centrify Server Suite Enterprise is deployed.
• Flexible Storage of Secrets:  Organizations have the flexibility to store secrets with the built-in Secure Storage (secured with their individual CA key) or they can use their own Hardware Secure Module.  Centrify has partnered with Safenet to deliver integration with KeySecure devices.

Explore:  The Platform from the End User Perspective

Explore:  The Platform from the Administrator's Perspective

Explore:  CPS User Experience

Explore:  CPS Privilege Session Brokering and Proctoring and Termination

Explore:  CPS Shared Account Password Management

Explore:  Privileged Session Auditing

Explore:  Worklfow and Approvals (User Access Request)

Explore:  Flexible Storage

Centrify Identity Platform - Making Strides and Taking Names

Centrify Identity Platform consists of two products:  Identity Service and Privileged Service

Centrify Identity Service (formerly User Suite) has continued its meteoric rise and I want to congratulate many of my coworkers on their hard work and dedication.

In the past two weeks, to major publications have continued to highlight its critical acclaim:

• 2015 Gartner Magic Quadrant for Identity and Access Management as a Service
• Positions Centrify as a visionary, proving and validating the completeness of the vision that combines On-Prem/SaaS SSO with Enterprise Mobility Management plus robust policy, Multi-factor Authentication and VPN-less Access.
• Ranks #3 among the solutions in a year that saw Salesforce, IBM and Microsoft enter the market and continues to beat the leader in execution and completeness of vision (#2 in pure play).  It's only a matter of time given Centrify's leadership.
• This is all looking at data from last year!!!!  This is before App Gateway, Privileged Service, ServiceNOW integration and others were ready to go.
  Get the report here.
• Network World Names Centrify Identity Service the best SSO tool for 2015
• Calls out the integration of SSO+EMM+MFA+Management interface.  Everyone else left to eat the dust.

Centrify Privileged Service (CPS) is a new entry (announcement) to the hybrid family of products that has a pure play in two areas (and growing):  Shared Account Password Management (SAPM) and Secure Remote Access, but it builds on the existing capabilities of the Identity Service to deliver complementary capabilities to Server Suite.

RBAC continues to be the preferred method for Privileged Account Management (PAM), however, for emergency, one offs and change control, using a shared privileged account can be useful.  Here's a video that illustrates the differences between the approaches:

Capabilities of CPS

Shared Account Password Management

Use your AD account and Multi-factor authentication to check out UNIX, Linux or Windows accounts, enforce policy, access anywhere (centrally or via mobile app).  Upon check-out, the password is rotated for you.

Secure Remote Access

Leverage the existing cloud connector infrastructure to deliver secure remote access to resources regardless of their location (on premises or in the cloud IaaS).  

Apps, UNIX, Linux and Windows sessions can be presented to users in a cohesive way

Much more to come, and many synergies with Server Suite

Very exciting time to be at Centrify and especially to help out prospects and existing customers.