Centrify 2017.3 - Windows: Self-Service and Win10 MDM Enrollment

This article is based on an entry I wrote for the Centrify Community.

Platform Capabilities
Self-Service Overview
The Centrify Identity Platform provides self-service capabilities that can be leveraged from the web portal  These capabilities include:

• Self-Service Password Reset for Centrify Directory and Active Directory users.
• Self-Service Account Unlock for Centrify Directory and Active Directory users.

Self-Service - How it works

• Policy-based implementation:  Self-service capabilities are implemented by policy.  This means that you can enable/disable these capabilities based on the scope of the policy and this is quite handy especially if you want to offer these capabilities only to a segment of the population.
•  Multi-factor Authentication:  MFA is the mechanism to establish identity assurance when performing self-service operations (password reset and unlock).  This allows for administrators to adjust Authentication Profiles based on the type and sensitivity of these operations in the target population.  For example, for a user that does not deal with sensitive data, step-up methods (like SMS, Phone Factor, e-mail or questions) may be acceptable; however, for an admin-type, you may require of them to use a physical (true) MFA method via Mobile Authenticator, RADIUS-legacy OTP, OATH OTP or even FIDO U2F device (like Yubikey) to facilitate.
• Automatic detection of locked accounts:  A locked CD or AD account is detected automatically and the corresponding activity workflow is triggered (e.g. walking the user through the unlock authentication profile).

Endpoint Management - Overview
Centrify was the first Identity as a Service (IDaaS) provider to include both endpoint (mobile device/container/application management) as a built-in capability (along with MFA).  This has given us a unique position in the market.  With Windows 10 supporting MDM operations we are embarked in a process of incrementally adding capabilities to the Centrify Agent for Windows(tm).


Endpoint Management - How it works

• Policy-based implementation:  Endpoint policies are implemented by policy.  This means that you can enable/disable these capabilities based on the scope of the policy and this is quite handy especially if you want to offer these capabilities only to a segment of the population (e.g. users with corporate-owned devices vs. personalized or BYO).
  The policy payload can be delivered using Centrify's policy engine or Active Directory Group Policy.
• Platform Diversity and frameworks:  Depending on the platform, Centrify can provide varying degrees of depth.  For example, iOS, Android and other mobile devices have their own frameworks (e.g. APNS for iOS), however with OS X, not only we support the existing framework, but we enhance application management via Munki-based services.  In the case of Windows, expect incremental capabilities to be delivered when Configuration Service Providers are implemented.

Self-Service Capabilities in Microsoft Windows
Password reset (and account unlock) are popular identity management capabilities, and Windows has had the framework for years.   The graphical identification and authentication (GINA) in earlier versions of Windows, and now with Windows 8  and above, the Credential Provider is the framework used to deliver these capabilities.

Since MFA was introduced on Windows a couple of years ago, weintroduced a Credential Provider that is now extended to provide self-service password reset (2017.3) and account unlock (2018).  These capabilities in this version apply to Active Directory accounts only.

User Flow
Precondition:  An Active Directory writable domain controller has to be reachable by means of the corporate network or VPN.

1. User presses ctrl+alt+delete to invoke the Windows credential provider.
2. User clicks the "Forgot Password" link and confirms and presses the arrow.
3. At this point, the Windows client talks to the Centrify connector that will verify if the user is allowed by policy to perform the operation.
4. Once verified, the user will be presented with the MFA or step-up methods defined for the SSPR authentication profile in the Centrify platform.
5. Provided the user types a password that is allowed by the Active Directory password policy rules, the user will successfully reset their password. 
6. An audit trail event will be logged in the application log of the Windows system and the Centrify platform event table will be updated.

Notes:  although account unlock is not officially released in 2017.3, the behavior is relatively similar, the biggest difference is that we will automatically detect the unlock state and trigger the proper identity assurance mechanism.

Controls

• Multi-factor authentication for identity assurance.
• Audit trail (application event log) to provide a mechanism for Security Operations solutions like Splunk, etc.
• CIP Events are also tracked in the platform's event table.

Audit Trail
Audit trails detail is especially important given that self-service metrics are usually captured to illustrate how these capabilities contribute to productivity.


Dashboards
Self-Service operations are tracked by the security dashboard in Centrify Identity Platform.
The dashboard allows administrators or security leads to focus on an operation (e.g. denied self-service) and offers the scoping of the date range, once selected, you can drill into the users, failure reason as well as an overlay of their geo-location (if the client is reporting it) as well as the factors being used.

Windows 10 MDM Enrollment
MDM enrollment with the "connect to work or school"  facility.  Based on their own website:
" Windows 10 provides an enterprise management solution to help IT pros manage company security policies and business applications, while avoiding compromise of the users’ privacy on their personal devices. A built-in management component can communicate with the management server.

There are two parts to the Windows 10 management component:

• The enrollment client, which enrolls and configures the device to communicate with the enterprise management server.
• The management client, which periodically synchronizes with the management server to check for updates and apply the latest policies set by IT.

Third-party MDM servers can manage Windows 10 by using the MDM protocol."

With the Centrify Agent for Windows™ included with Infrastructure Services  2017.3, we now support automatic Windows 10 MDM enrollment as corporate-owned systems, with the optional capability for personalization.  In this release we provide:

• Administrative (bulk) enrollment (corporate-owned)
• Enrollment personalization (personal)
• Zero sign-on for to Centrify Apps Service from Windows (Internet Explorer or Edge) and Google Chrome browsers.

 This opens the possibility for future capabilities, including the configuration service providers.


Videos - Self-Service
Centrify Identity Platform - Self-Service Features Overview
 
Self-Service Password Reset using the Windows Credential Provider
 

Bulk Deployment - Corporate Owned Devices

Enrollment Personalization and Zero Sign-On

Using AWS CloudWatch to monitor Centrify Audit Trail events in EC2 Windows instances

Background

As more and more organizations run infrastructure in IaaS platforms like Amazon AWS, there's an increased need to enhance security operations and prove effective implementation of security controls.  AWS provides a solution set that includes CloudWatch.  

About CloudWatch

As defined by Amazon "CloudWatch monitors your Amazon Web Services (AWS) resources and the applications you run on AWS in real time. You can use CloudWatch to collect and track metrics, which are variables you can measure for your resources and applications." 

For more information, check out the Getting Started guide for CloudWatch:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html

The goal of this article, is to provide some initial guidance to leverage AWS CloudWatch to collect, track and measure Centrify Audit Trail events in Windows systems running in AWS.

For a companion article that covers UNIX/Linux instances, click here: http://centrifying.blogspot.com/2017/04/using-aws-cloudwatch-to-monitor.html 

About Centrify Audit Events

Centrify Audit Events (CentrifyAuditTrail) is the cross-platform framework used by Centrify Server Suite to document and provide access, privilege and audit trail event data. When a Centrify-enabled service is invoked, an audit trail event is written to UNIX syslog or Windows event log.  These events are documented in the  Audit Events Administrator's Guide for the current version of Server Suite.  The types or content of the events vary depending on the edition (Standard or Enterprise)

For more information, check out the current guide for Server Suite 2017: https://docs.centrify.com/en/css/suite2017/centrify-audit-events-guide.pdf

Pre-Requisites

For this lab, you'll need:

• An AWS Account with the proper VPC setup, privileges in CloudWatch and IAM
• Active Directory (run by you or managed by Amazon) and the proper VPC name resolution and communications
• A Centrify zone, sample users and access/privilege setup
• At least one Windows system joined to Active Directory and the Centrify zone
• The Windows system should have some Centrify data (e.g. access, privilege elevations) present in the application event log.

Centrify AWS Lab:  You'll need to be at Standard Edition level to follow this lab, more info here:

http://community.centrify.com/t5/TechBlog/Labs-Setting-up-an-AWS-Test-Lab-for-Centrify/ba-p/27771

Implementation Overview

1. Set-up your AWS Windows Instances for CloudWatch Logs (use AWS's docs)
2. Verify Centrify Audit Trail events in the CloudWatch log group
3. Identify Access and Privilege-related Metrics provided by Centrify
4. Create the Filters and Assign a Metric
5. Create a Dashboard
6. Create an Alarm

Set-up your AWS Linux Instances for CloudWatch Logs

For information on this topic, please review AWS's documentation:
http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/UsingConfig_WinAMI.html#send_logs_to_cwl

Note that Centrify Audit Trail resides in the Windows Application log.  To gather the proper event data, make sure you are capturing information and warning messages, this is configured by modifying the AWS.EC2.Windows.CloudWatch.json file in the proper location based on your deployment (stand alone or using SSN service) and under teh ApplicationEventLog stanza, setting the Levels to 7 as illustrated below:

{
    "Id": "ApplicationEventLog",
    "FullName": "AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,AWS.EC2.Windows.CloudWatch",
    "Parameters": {
        "LogName": "Application",
        "Levels": "7"
    }
},

Once you have the Windows logs logs for your instances in the corresponding Log Group, please proceed to the next section.

Verify Centrify Audit Trail events in the CloudWatch log group

1. Go to your CloudWatch console: https://console.aws.amazon.com/cloudwatch/home
2. Click on Logs > Click on the log group for your Windows instances (e.g. "Default-Log-Group"  or the group you are using for your Windows event logs)
3. Click on Search log group and in filter events, type "AUDIT_TRAIL"
4. Verify the results.
    
   If you have a Windows system that was joined to the Centrify zone, there will be event data about access, privileges and other activities.

Now you have verified that your systems are streaming syslog data with Centrify Audit Trail information.

Identify Access and Privilege-related Metrics provided by Centrify

The Centrify Agent for Windows™ provides access control,multi-factor authentication and role-based privileged elevation; this component is called DirectAuthorize.  DirectAuthorize controls how users access the system and what commands they can run. The implementation of privilege elevation leverages roles defined in Active Directory and the DirectAuthorize client for Windows.

Example 

The metrics that you'll track will depend in your objectives and in your maturity level.  For illustration purposes, let's track successful and unsuccessful access and privilege elevation in my Windows EC2 instances. After reviewing the Centrify Audit events guide, I identify the following events:

Access Control

Windows Remote Login Success:  These events are recorded when an authorized user from the Centrify zone is succesfully granted access to the Windows system;  the Centrify Event Id is 6003.

You can leverage the Audit Trail admin guide for a full catalog.

Windows Remote Login Failure:  The opposite of the event above, it's a warning stating that the user was not authorized to log in from the current station.  This may denote an attempt at lateral movement. The Event Id is 6011.
 

Privilege Elevation

Run with Privilege Success:  Indicates successful privilege elevation the Centrify Agent for Windows; this may be a privileged desktop or an application; the event ID is 6012.
  

Run with Privilege Success:  Indicates an unsuccessful attempt at privilege elevation the Centrify Agent for Windows; this may be a privileged desktop or an application and could be user error or an abuse attempt; the event ID is 6018.

Create the Filters and Assign a Metric

1. Go to your CloudWatch console: https://console.aws.amazon.com/cloudwatch/home
2. Click on Logs and select the radio buttion next to your log group (e.g. Default-Log-Group)
3. Click Create Metric Filter
   • In filter pattern, type: centrifyEventID=6003
   • Press "Assign Metric" 
4. In Filter Name, type a unique name for the filter
5. In Metric details, create a new namespace (e.g. CentrifyAuditTrail) or browse for it if you already have it.
6. In Metric name, give it a descriptive metric.
   
7. Press Assign Metric.
8. Repeat the process for all the metrics you've identified.

Create a Dashboard

Before creating a dashboard, you may want to plan how to visualize the data.  In some instances it's useful to see the aggregate data (# of events), in others it's useful to see a trend (graphs overlapped with time).

Once you have thought of how to visualize the data, it's time to get started with your Dashboard. 

1. Go to your CloudWatch console: https://console.aws.amazon.com/cloudwatch/home
2. Click on Dashboards > Create Dashboard and give it a name, then press Create Dashboard
3. To add aggregated information, select the Number widget
4. Select your Namespace, Dimension and check the metric(s) to be measured
5. Go to the graphed metrics tab, and select the proper statistic and period  (e.g. sum and 1 day) and press Update Widget.
6. Once you have the Widget in the dashboard, adjust the size and label.

Repeat the process with the trend using with a line or stacked area.

Below is a simple dashboard that includes the metrics above.

 

Create an Alarm

A meaningful alarm could be based on a pattern outside expected behavior, an availability issue or another event (or aggregation of events) based on the risk that wants to be corrected.  This example is for illustration purposes only.

Example:  The threshold for attempted abouse of privilege elevation feature of the Centrify Agent for Windows for  3 or more attempts within a 5 minute period, when this happens, an email should be triggered to the members of the Security Operations distribution list.

1. Go to your CloudWatch console: https://console.aws.amazon.com/cloudwatch/home
2. Click Browse Metrics and next to Centrify-dzdo-Denied, click the alarm icon.
3. In create alarm:
   Name: Alarm-DZWin-Privilege-Abuse
   Whenever: is equal or greater than 3 for 1 consecutive period
   Period: 5 minutes
   Statistic: Sum
4. Actions
   Whenever this alarm state is Alarm
   Create a new list (secops@your-domain.com)

Trigger the alarm

1. Sign-in to your Windows instance with your administrator
2. For any application in your desktop, right click and select "Run with Privilege" 
3. You should get this message:
   
4. Repeat 3 more times.  This should trigger the alarm.
   
5. Review the Dashboard.  After a few minutes, the alarm will return to normal and you'll be notified
   

Conclusion

We have only scratched the surface of the capabilities provided by AWS CloudWatch, however in the context of Identity and Access Management, the enrichment of security operations via logs, alerts and dashboards should be done via standard tools; otherwise if each tool duplicates these capabilities, then security operations won't know where to go first.  Centrify provides native plugins for Splunk, IBM QRadar and HP ArcSight.  These tools provide both operational data as well as like the following privilege command pie chart.

Related Articles

CloudWatch and Centrify EC2 Linux:  http://centrifying.blogspot.com/2017/04/using-aws-cloudwatch-to-monitor.html

HOWTO - Implement a cross-platform mixed DBA Role (Oracle+SQL Server) using Centrify Server Suite

What you'll need

• Active Directory and a Centrify Zone
• Centrify Access Manager and access to perform the configuration
• A UNIX or Linux System and the Centrify Enterprise Edition Agent (DirectControl/DZ & DirectAudit)
• A Windows System and the Centrify Enterprise Edition Windows Agent (DZWin/DAWin)
• Two Active Directory Groups and a test user.

Planning

Privileges Based on Roles
In the previous entry, you saw how we conquered the issue of limiting access to systems based on business need-to-know and how we can create a SuperUser-like role across platforms.  Now it's time to implement a true Role Based governance model.  Just like with any capability (security included) you must achieve balance on the people-process-technology triad, in the context of Roles, its key is to understand how people use privileges in their job functions, implement a process around it and leverage the technology to implement it.  Here's an oversimplified example for DBAs in a mixed Oracle and SQL Server shop.

How DBAs access systems:   SSH and Toad on Linux and RDP on Windows
Typical tasks needed for operations:  In Linux, DBAs need to run the sqplus command as the Oracle account and switch user to oracle.  In Windows, DBAs need to run SQL Server Manager and to manipulate the SQL Server Service.
Typical tasks needed for change-control:  DBAs need to elevate to Root during upgrades and installations.

In my fictitious company, I will allow the SSH PAM access role and the commands to run sqlplus and switch to oracle.  The Sysadmin role (that allows to elevate to root) will only be granted with a change-control number and duration.

This process needs to be adjusted because of two things:

• Resistance to change
  I guarantee you that users will initially think that you're making their jobs harder and will try to find ways to resist.
• Nuances around how people perform their jobs
  For example, a Windows DBA may also need access to SQL Server Configuration tools; or a UNIX DBA may like to switch user without profile  (su oracle, instead of su - oracle).

So be ready to have a review of roles and rights with certain cadence, to add/remove commands or apps; as well a to make usability adjustments.  Make it part of your attestation process.

In our example, we'll use the Centrify-Model-Mixed-Role-DBAs group to provision this role.

Access Based on Roles
The concept continues to be the same as the previous post, but now you are further breaking down your access governance model based on your needs.  For example:  you may have a DEV-QA-PROD train for an application and you can grant access just to that set of systems, and you can classify systems based on that model;  This is where your investment in Centrify Professional Services can pay the most.   In my example, I'll just use a Computer Role called Mixed Database Servers, based on an AD group called Centrify-Model-Mixed-CR-Database Servers.

Security Operations Requirements
In the previous example we leveraged both the UNIX Syslog and the Windows Event log to augment log collection capabilities.  Since DirectAudit data is contained inside a SQL server database, this is another repository that can be tapped by log aggregators.  Since DirectAudit provides session data, information gathered from security operations can be further investigated by looking at session data.

Provisioning
Here the principles continue to be the same as the previous entry. Granting or revoking the role or making a system part of the collective is performed via AD Group Membership (Manually with ADUC, Programmatically with PowerShell or Scripting and controlled via any Workflow engine)

Planning for Platforms
Same exceptions apply:  IBM AIX with LAM enabled don't allow the breakdown of PAM access rights.

Implementation
Just like the previous entry, remember that these steps can be automated via Centrify adedit on UNIX/Linux or Centrify Access Module for PowerShell as well as the DirectManage SDK.

Recap: Rights go into Roles, Roles are configured and Assigned to AD Principals in a Given Scope (zone, child zone, computer role or individual computer)

Step 1:  Create the AD Groups for the Computer Role and to assign the Roles

1. Manually you can open Active Directory Users and Computers (ADUC)
2. Navigate to your designated OU, right click > New > Group.
3. Select the appropriate scope and give it a name.  In our case we repeat this for both Centrify-Model-Mixed-CR-Database Servers and Centrify-Model-Mixed-Role-DBAs

Step 2:  Create the Mixed Database Systems Computer Role

1. Open Access Manager and right-click your Zone > Authorization > Computer Roles and Select Create New Computer Role.
2. In the New Computer Role window, give it a name (Mixed Database Systems), description and browse for the Centrify-Model-Mixed-CR-Database Servers group.  Then Press OK.

Step 3:  Create the DBA commands to be used in UNIX and Linux platforms

SQL Plus as Oracle
Creating this command requires a bit of research. Information about the diversity of platforms, versions and their differences are relevant. For example, in my environment, I’m using Oracle Express 11G running on Linux.

Another important detail has to do with the environment variables. I want to conserve them in this case so sqlplus has all it needs to launch correctly:

Switching to the Oracle account
Some DBAs may need to do a simple (no profile) elevation, or they would want the opposite, Centrify offers the flexibility of Regular or Global expressions.

Service Control for the Oracle Service
More research required. In my environment, the service is oracle-xe and I will limit the directives available for service.


Step 4:  Create the DBA commands to be used in Windows platforms

SQL Server Management Studio
Windows application rights provide a lot of flexibility. Some key highlights

• You can consolidate several applications in a single command
• Applications can be defined manually, by looking at local or remote processes or by browsing directly to the file.
  
• Application arguments can be evaluated with or without case sensitivity
• Application types can be further broken down (e.g. exe, bat, cmd, vbs, ps1, etc.)
• Additional criteria can be added based on the file metadata (e.g. version, company, etc)
• Application rights can be executed in 3 different contexts
  • As a service account: the user in the role does not need to know the credentials.
  • As a member of an AD group without persistent membership
  • As a member of a Windows built-in group (like Power Users, etc.)
    

In the case of the SQL Server Management studio, I have a Windows native deployment with a SQL management account. I can easily use an AD group, but since I have this privilege elevation mechanism, I don’t need to fall into the bad habit sharing that account - there are many other ways to accomplish the same objective.

Stop, start and query the SQL Server Service command
I'm choosing to use the service control command line utility (sc.exe) in the context of the local administrator account to provide the DBA with the ability to control the SQL server service.  The alternative today is to grant the DBA administrator rights, which they can use to stop other services (like the AV or firewall).


Step 5: Creating, configuring, assigning the role and provisioning a user
This process follows exactly the same steps of the previous post. Keep in mind that the Windows rights will be for remote (RDP or Citrix) and to add the UNIX and Windows rights after the role is created.

The role assignment will be performed at the Computer Role level, so it only applies to computers provisioned into that group. Finally you can add your test user to the group that gets the role assigned.

Part of our process dictates that if they do need higher privileges, they can request it based on a change control approval.


Step 6: Verifying and the rights on the UNIX/Linux system
To view the role attributes and definition, use the dzinfo command

$ dzinfo
User: thomasf
Forced into restricted environment: No

  Role Name        Avail Restricted Env
  ---------------  ----- --------------
  Mixed            Yes   None
  DBA/Global

    Effective rights:
        Password login
        Non password login
        Allow normal shell

    Audit level:
        AuditIfPossible

    Always permit login:
        false


  PAM Application  Avail Source Roles
  ---------------  ----- --------------------


Privileged commands:
  Name             Avail Command               Source Roles
  ---------------  ----- --------------------  --------------------
  DBA Oracle -     Yes   service oracle-xe     Mixed DBA/Global
  oracle-xe              start|stop|status|re
  service                start
  control/Global
  DBA Oracle -     Yes   su oracle             Mixed DBA/Global
  switch to
  oracle
  no-profile/Glob
  al
  DBA Oracle -     Yes   sqlplus *             Mixed DBA/Global
  sqlplus as
  oracle/Global
  DBA Oracle -     Yes   su - oracle           Mixed DBA/Global
  switch to
  oracle with
  profile/Global

To view the command definitions, use the dzdo –l command

$ dzdo -l
AD Password:
User thomasf may run the following commands on this host:
    (root) service oracle-xe start|stop|status|restart
    (oracle) sqlplus *
    (root) su oracle
    (root) su - oracle

To use your privileges via privilege elevation use dzdo

$ dzdo service oracle-xe restart
Shutting down Oracle Database 11g Express Edition instance.
Stopping Oracle Net Listener.

Starting Oracle Net Listener.
Starting Oracle Database 11g Express Edition instance.

Finally, and for the benefit of security operations, all privilege elevation continues to be written to syslog:

Dec 27 15:15:53 engcen6 dzdo:  thomasf : TTY=pts/3 ; PWD=/home/thomasf ; 
USER=root ; COMMAND=/sbin/service oracle-xe restart

Step 7: Verifying and the rights on the Windows system

In Windows, to view the role definition, you can open the Authorization Center in the System Tray, the role definitions tab shows the applications defined for the role, double clicking provides a deeper dive.
 
To use your privileges, in the GUI you can use the Run as role shell extension, pick the role and the application will be launched as defined. Finally, just like with UNIX, privileged elevation will be logged in the Windows Event Log.
 

Step 8: Session Capture and Replay with Audit Analyzer
Audit analyzer provides a very neat view of what's going on with your audited systems;   in the left pane you have queries and categories, on the right side you can see the sessions.  The columns include the AD user, the client and server systems, the status of the session, etc.


If you drill down into a session, you can see an index of the commands or events that happened during the session.


Looking at a replay, provides you with the event data +  a video of the terminal or Windows session.


Reconstructing what happened (especially on Windows platforms) is as simple as just watching and controlling like a DVR.


Finally, let's look at this scenario and do some testing:

This article is a repost of  a two-part series I wrote for the Centrify Community.

[Labs] Centrify+AD+Yubikey - Implement Strong Authentication for UNIX/Linux using Smart Card

Background
This is the the second lab in the series around Strong Authentication.  In the previous lab we focused on StrongAuth for Windows access and privilege elevation with YubiKey.
We will be focusing on UNIX/Linux system access leveraging strong authentication to Windows (or Mac) systems via smart card or YubiKey.  Centrify Server suite allows definitions of roles that only allow non-password authentication to be enforced.   YubiKeys are full-fledged personal identity verification (PIV) cards that work very well with AD and Certificate Services.

The challenges

• Recent advanced threats leverage the collection of passwords and poor security practices to exploit systems.
• The variability (heterogeneity) of systems (Windows, UNIX, Linux, Macs) poses a big challenge for organizations
• The proliferation of "best of breed" solutions promotes IT fragmentation and limits organizational flexibility.
• The "jumpbox" or proxy approach combined with additional controls like workflow can help as long as connections are centralized, however many organizations are getting audit comments due to circunvention of these mechanisms.
• Although there are different multifactor providers in the market and most of them provide Pluggable Authentication Modules for their solutions, the implementation requires a high-degree of expertise and translating the capability to hundreds or thousands of servers with heterogeneous OSs can be quite complex.

The opportunity
Although Centrify can accommodate the "jump box and shared account" model using Centrify Privilege Service, organizations should complement their security strategy with the least access model:

• Users shall only access the systems they need to based on business need-to-know with strong authentication
• Users shall be limited to the minimum privileges required for their functions:  this is accomplished by providing users roles with the rights that they need.
• Rights shall be assigned and limited to the business function with a privilege elevation mechanism (e.g. sudo) that has the flexibility to provide strong authentication.
• In sensitive systems, access and privilege elevation shall be supplemented with session capture and replay.
• Active Directory and Centrify provide a stack that can secure systems and eliminates complexity across the different UNIX/Linux platforms

Lab Goals

• Limit privileged users to a subset of UNIX/Linux systems based on their needs (AD and Centrify Zones enable this)
• Require strong authentication for local or remote (SSH) access  (this is enabled by Centrify DirectAuthorize)
• Require strong authentication on privilege elevation if needed (OTP, SMS, E-mail, phonefactor, etc)
• Reproduce privileged sessions (session capture, transcription, replay).

What you'll need

• Active Directory with Certificate Services
• A domain joined member server with Centrify Server Suite 2016 (DirectControl) a
• One or two UNIX/Linux systems with Centrify DirectControl and Centrify-Enhanced OpenSSH
  Because we will be relying on SSO, Centrify OpenSSH comes compiled with Centrify methods that simplify the process in simple and complex AD environments.
• For SSO to work, the system has to be resolvable by name (shortname or FQDN) by the Kerberized clients.
• SSH client that supports SSO; e.g. stock PuTTY (GSSAPI) or Centrify-enhanced (Kerberos)
• Access to Centrify Standard Edition (evaluation or licensed)
• Yubikey PIV Manager  (download link)
• Yubikey 4, NANO or NEO
• You need working knowledge of Active Directory and Centrify Zones

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

Scenario Description: 
We will use the Yubikey/Smart Card with the Certificate provisioned to the user in the base lab.  With Centrify Access Manager, we will create a role that allows her to access a system (locally and via SSH) and we will prove:

• That the user can only log in to her Windows station with her Smart Card
• That the user cannot sign-in to UNIX/Linux system locally or remotely (via SSH) with a password
• That the user is only allowed to log in remotely via SSH to UNIX/Linux systems  via SSO (Kerberos or GSSAPI)
• That these rights can be assigned to groups of systems, or groups of users in a temporary or permanent basis
• Minimal to zero configuration at the system level.  Once the system is joined to AD, the security measures should just work.

Note:  We will not focus on privilege elevation.  We have covered this exhaustively, including with MFA/2FA in previous labs.


Centrify Setup
In this instance we are setting up a Web Admin role that contains the pre-defined "login-all" PAM right.  We are not breaking down the rights to prove that we can stop the user from logging in via console or via SSH with a password.
The privileged user assigned the role must have authenticated with her YubiKey or SmartCard to obtain a Kerberos TGT from Active Directory, subsequently, Centrify DirectAuthorize will be in charge of denying access to the user if they don't use SSO for access (via Kerberos or GSSAPI).  All we're going to need is a zone and a role.

To set up using PowerShell

Import-Module ActiveDirectory
Import-Module Centrify.DirectControl.PowerShell

$user = Get-ADUser -Identity Maggie.Simpson  # substitute for your test user
$cont = "cn=zones,ou=unix,dc=centrify,dc=vms"  # substitute for your container DN
$zone = New-CdmZone -Name "Yubikey-Demo" -Container $cont

$cmd1 = New-CdmCommandRight -Zone $zone -Name "Edit http config file" -Pattern "vi /etc/httpd/conf/httpd.conf" -Authentication none
$cmd2 = New-CdmCommandRight -Zone $zone -Name "Httpd service control" -Pattern "service httpd*" 
$cmd3 = Get-CdmPamRight -Zone $zone -Name "login-all"

$role = New-CdmRole -Zone $zone -Name "UNIX Webadmin - StrongAuth" -UnixSysRights ssologin, nondzsh, visible

Add-CdmCommandRight -Right $cmd1 –Role $role 
Add-CdmCommandRight -Right $cmd2 –Role $role 
Add-CdmPamRight  -Right $cmd3 –Role $role 

New-CdmUserProfile -Zone $zone –User $user –login $user.SamAccountName -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"
New-CdmRoleAssignment -Zone $zone -Role $role -TrusteeType ADUser -ADTrustee $user | Out-Null

To perform the steps for the script above manually
Create, Configure and Assign the Demo role
 In Access Manager > Open they Yubikey-Demo zone > Authorization > Right Click Role Definitions > Select Add Role

1. Name:  UNIX WebAdmin - StrongAuth
   System Rights:
   - Non-password (SSO) login is allowed  (checked)
   - Login with non-Restricted shell (checked)
   
2. Create two UNIX commands.  
   Since this will be our "Web Admin" we'll allow the role to manipulate the httpd daemon and edit the config file for the Apache server.  The commands are:
   Glob expression vi /etc/httpd/conf/httpd.conf from the standard user path /usr/bin no reauthentication required.
   Glob expression service httpd* from the standard user system path /usr/sbin no reauthentication required.
   
3. Add the rights to the role.  Right click the "UNIX WebAdmin - StrongAuth"  role and select "Add Right"
   
4. The role is ready to be assigned.  Now press OK and right-click the Authorization > Role Assignments > Select Assign Role
5. Press the Add AD account > type the name of your test user, select it and press OK.
   
   Note: This is a permanent direct assignment to a user principal at the zone level.  This is not the best practice, typically you grant role assignments temporarily (for attestation), in a subset of systems and to AD groups for better administration.

 Install DirectControl and join the system to the Centrify Zone

1. Use your preferred software distribution method to copy the Centrify software
   In my case I already have a local repo for RHEL and derivatives.  (Read how to set up here)
2. Log in to your UNIX/Linux system and use your favorite package manager to install Centrify DirectControl and Centrify-enhanced OpenSSH
   
   

   $ sudo yum install CentrifyDC CentrifyDC-openssh
   [truncated]
   Installed:
     CentrifyDC.x86_64 0:5.3.0-213   CentrifyDC-openssh.x86_64 0:7.1p1-5.3.0.208
   Complete!
   
   

3. Now Join the Centrify zone and you'll be ready for testing.  Use the adjoin command and an authorized user:
   
   

   $ sudo adjoin -z Yubikey-Demo -c "ou=servers,ou=unix" -u dwirth centrify.vms
   [sudo] password for centrifying:
   dwirth@CENTRIFY.VMS's password:
   Using domain controller: dc.centrify.vms writable=true
   Join to domain:centrify.vms, zone:Yubikey-Demo successful
   
   Centrify DirectControl started.
   [truncated]
   
   

4. If your system was not resolvable by Windows DNS, you can use the addns command to register automatically with dynamic updates (if your DNS zone allows):
   

   $ sudo /usr/sbin/addns --update --machine
   Updating both HOST and PTR record for: centos67.centrify.vms
   Deleting old reverse lookup records for centos67.centrify.vms on 192.168.81.10.
   No old reverse records deleted because no host records found for centos67.centrify.vms on 192.168.81.10.
   
   

5. Verify that your users are correctly UNIX-enabled and with the expected rights (use adquery user and dzinfo)
   

   $ adquery user maggie.simpson
   maggie.simpson:x:1040191002:1040191002:Maggie Simpson:/home/maggie.simpson:/bin/bash
   
   $ sudo  dzinfo maggie.simpson --roles
   User: maggie.simpson
   Forced into restricted environment: No
   Centrify Cloud Authentication: Supported
   
     Role Name        Avail Restricted Env
     ---------------  ----- --------------
     UNIX Webadmin -  Yes   None
     StrongAuth/Yubi
     key-Demo
   
       Effective rights:
           Non password login
           Allow normal shell
           Visible
   
       Centrify Cloud Authentication:
           Not Required
   
       Audit level:
           AuditIfPossible
   
       Always permit login:
           false
   

   
   All set on the Centrify side.

Configure your Test user for Smart Card Authentication

1. In ADUC, find and double-click the test user.
2. Account Tab > Account Options > Check the box for "Smart Card is required for interactive logon"
   
3. Press OK. You are ready to start testing.

Test Plan:

1. Try to access the system with any other AD user than test user - expected result:  Access Denied
   This is because users need to be explicitly be granted access a UNIX identity and a Centrify role in the zone for the computer.

   login as: dwirth
   -----------------------------------------------------------------
   CENTRIFY DEMO -
   -----------------------------------------------------------------
   WARNING: This is a PRIVATE system exclusively for Centrify demos
   Your actions will be monitored and recorded.
   -----------------------------------------------------------------
   Using keyboard-interactive authentication.
   Password:
   Access denied
   Using keyboard-interactive authentication.

   
   
2. Try to access the system with your test user (Maggie) with her password (Console or SSH) - expected result:  Access Denied
   This is because the test user was defined with "Smart card required for interactive logon"

   login as: maggie.simpson
   -----------------------------------------------------------------
   CENTRIFY DEMO -
   -----------------------------------------------------------------
   WARNING: This is a PRIVATE system exclusively for Centrify demos
   Your actions will be monitored and recorded.
   -----------------------------------------------------------------
   Using keyboard-interactive authentication.
   Demo Password:
   Using keyboard-interactive authentication.
   Account cannot be accessed at this time.
   Please contact your system administrator.
   
   

3. Log in to Windows system (you are forced to smartcard login) - Launch PuTTY (configured for SSO)
   Expected result:  Access Granted
   

 Video

Other Considerations:

• When forcing strong authentication, you must have a plan for other shared non-human accounts.  This is where Centrify Privilege Service shines.
• Don't underestimate the need for good process around the lifecycle of PKI and smart cards.  PKI is serious business.