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.
User presses ctrl+alt+delete to invoke the Windows credential provider.
User clicks the "Forgot Password" link and confirms and presses the arrow.
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.
Once
verified, the user will be presented with the MFA or step-up methods
defined for the SSPR authentication profile in the Centrify platform.
Provided
the user types a password that is allowed by the Active Directory
password policy rules, the user will successfully reset their password.
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:
In this article, we'll discuss Centrify's support for Container Linux by CoreOS introduced with 2017.3 (5.4.3). This is based on an article I wrote for the Centrify Community.
About Container Linux by CoreOS "Container
Linux by CoreOS (formerly CoreOS Linux) is an open-source lightweight
operating system based on the Linux kernel and designed for providing
infrastructure to clustered deployments, while focusing on automation,
ease of application deployment, security, reliability and scalability.
As an operating system, Container Linux provides only the minimal
functionality required for deploying applications inside software
containers, together with built-in mechanisms for service discovery and
configuration sharing." - Source: Wikipedia.
Engineering Challenges
We had to overcome some challenges based on how Container Linux is architected.
No package manager (required to deploy our solutions).
Read-only /usr filesystem (Centrify usually installs under /usr/share/centrifydc and audit under /usr/share/centrifyda).
No Perl (required by group policy and other utilities).
Kernel not compiled with auditd support (required for file/monitoring).
Needless
to say, our Engineering team was up to the task and was able to provide
a solution that enabled our capabilities and maintained the ease-of-use
that is common with Centrify solutions.
Solution
Centrify provides an installation tarball with the 2017.3 agent bundle that includes Access and Audit components.
A special version of the install.sh utility will allow for interactive or automatic installations.
Centrify software is installed in the /opt/centrify folder.
Limitations: Express mode, deployment manager installation and monitoring service are not available.
Features Host-Based Security
Increased accountability
- Container Linux users can sign-in with their Active Directory
account. We provide identity assurance with Multi-Factor
Authentication. In AWS deployments, organizations don't need to rely on the shared SSH Key-based credential called "core"
Centralized administration
- Organizations don't have to duplicate effort and continue to leverage
Active Directory as the directory of record. No modifications
required.
Identity Management - Leverage Centrify zones to maintain a consistent UNIX namespace. You can leverage AD groups to control the memberships in the docker secondary UNIX group.
Role-based Access Control - Use Centrify zones to control who can access a system, and what commands can be run with privilege. For example:
You can create a role that defines who can elevate to root or the core accounts.
You can use Active Directory group membership to define who is a member of the docker(233) secondary group.
You can define very granular docker commands that can be granted to minimize risk or enforce separation of duties.
Attestation and Security Operations - Leverage Centrify Reports to facilitate attestation and Centrify Audit Trail to enrich security operations.
Advanced Auditing - Enjoy audit trail events as well as session capture and replay.
Extend host-based security to Linux Containers (LXC) - Centrify "bridges" capabilities to Linux Containers to enjoy the same level of accountability at the container level.
Vault-Based Security
Shared Account Password Management
- if you need to use shared credentials, use the Centrify Privilege
Service vault and enjoy the deployment flexibility and traditional
password-related controls.
Secure Access
- privilege Service connector infrastructure allows for Web, Native or
SSH jumpbox client access regardless of on-premises or IaaS
deployments.
Session Proctoring, termination and recording - Enjoy the benefits of session control as well as auditing without the need to add local capabilities.
Videos - Centrify + Container Linux in action
What's different in Container Linux Host-based Access Control, Identity Assurance and Role-Based Privilege Management Vault-based Access Control, Shared Accounts and Secure Access Using Role-based Access Control to manage and establish accountability for Docker operations
Background
Regulatory frameworks have evolved to require documented evidence of
approval for development or infrastructure-related change control.
These activities usually require the exercise of elevated privileges.
Some examples of these requirements and guidelines can be found on PCI
DSS, SANS Critical Security controls, ISO 27001 and others:
Centrify DirectAuthorize and DirectAudit provide end-to-end,
role-based access controls for UNIX, Linux and Windows, in addition it
provides mechanisms for validation and tracking of changes via ticketing
or request systems.
Requirements
We've had customers that have two categories of requirements:
Tracking activities related to a particular change control or approved request For example: We want to track all privileged activities related to a change control in my security operations dashboard. We covered this on this on the original dzdo validator article. When privileges are elevated, entries in both syslog or DirectAuthorize get created automatically. Using Centrify-enhanced sudo:
$ dzdo tail /var/log/messages
Enter the change control ticket number:1255
syslog:
Nov 7 15:04:39 engcen6 dzcheck.sample[35173]: User "dwirth@centrify.vms" will run "/usr/bin/tail /var/log/messages" as "root" with ticket number "1255"
DA Console:
Implementing controls to prevent unauthorized changes For example: We want to make sure that any privilege elevation is only allowed with an approved request. This lab covers a basic lab setup to implement this requirement.
Lab Diagram
What you'll need:
Centrify Standard Edition and a Centrify Zone with some UNIX roles defined
An AD-joined UNIX or Linux system in the Centrify zone The system should be able to reach the ServiceNow instance directly, via proxy or via ServiceNow MIDServer.
A DirectAuthorize role for UNIX
A ServiceNow instance (Fuji release minimum) and a shared credential or token to query existing requests Make sure that the credential only has the minimal rights (e.g. read-only) for your requests.
Optional: Centrify Privilege Service (Saas or On-Prem) to vault the SN user's credential.
Use Case
Privileged user obtains a change control manager approval via ServiceNow workflow request. The request has a change control window. (date/time range)
During the request validity timeframe, the privileged user needs to
perform activities (using Centrify-ehnanced sudo) and when the commands
are issued, the SN request number has to be provided.
The dzdo.validator script uses the ServiceNow Perl API to validate if the request is approved or not. Additional validations can be added like user, time-range, etc; these won't be covered for blog brevity.
If the request is a approved, the Centrify-enhanced sudo command is allowed to execute. If not, the user is notified.
Implementation Overview
Install the ServiceNow Perl API
Test ServiceNow Instance connectivity
Optional: Protect the shared credential using Privilege Service
Modify one of the sample scripts to work with ServiceNow Requests
Modify the dzdo.validator script to call the ServiceNow Perl API script
Make sure you have the appropriate Perl plugins (e.g. CentOS 6.x): SOAP::Lite (e.g. yum install perl-SOAP-Lite) Crypt::SSLeay (e.g. yum install perl-Crypt-SSLeay) IO::Socket::SSL ( e.g. yum install perl-IO-Socket-SSL) File::Basename MIME::Types (e.g. yum install perl-MIME-Types) MIME::Type MIME::Base64
Download the Servicenow Perl API (link to 1.01 version) to your UNIX/Linux system
Unzip the file in a new folder and run the following commands:
## create a new folder, download and unzip
$ mkdir SN
$ cd SN
$ wget http://wiki.servicenow.com/images/e/e5/ServiceNow-Perl-API.zip
$ unzip ServiceNoW-Perl-API.zip
## compile the files
$ perl Makefile.PL
$ make
$ make test
$ make install
Follow the prompts, once you have all the ServiceNow Perl API libraries installed to use with your scripts.
Testing Connectivity with your ServiceNow Instance (Sample Script)
Create a new file with these contents
# This script retrieves all the requests from your servicenow instance
# it is used to test connectivity.
#!/usr/bin/perl -w
use ServiceNow;
use ServiceNow::Configuration;
# This example uses Centrify Privilege Service's AAPM capability# by checking-out the password from the vault at runtime, we eliminate# the need to use a cleartext password in this script.
# uses cgetaccount to check out the password for your-SN-user for 3 mins.
# Alternatively you can enable OAuth and use Tokens (recommended)
$SN_PASSWD = `cgetaccount -s -t 3 your-SN-user`;
my $CONFIG = ServiceNow::Configuration->new();
$CONFIG->setSoapEndPoint("https://your-instance.service-now.com/");
$CONFIG->setUserName("your-SN-user");
$CONFIG->setUserPassword($SN_PASSWD);
my $SN = ServiceNow->new($CONFIG);
my @requests = $SN->queryRequestedItem();
my $count = scalar(@requests);
print "Number of requests=" . $count . "\n";
foreach my $request (@requests) {
print "Request number: $request->{'number'}\n";
print "Requested by: $request->{'sys_created_by'}\n";
print "Date Created: $request->{'sys_created_on'}\n";
print "Approval Status: $request->{'approval'}\n";
print "\n"
2. To test the script, add the execution flag and run it
$ chmod +x checksn.sh
$ ./inc2.sh
Number of requests=34
Request number: RITM0000002
Requested by: fred.luddy
Date Created: 2016-05-02 18:15:39
Approval Status: requested
Request number: RITM0000004
Requested by: fred.luddy
Date Created: 2016-09-03 17:15:39
Approval Status: requested
Request number: RITM0000005
Requested by: fred.luddy
Date Created: 2016-05-22 19:15:43
Approval Status: requested
[output truncated]
Modify the Sample Script to work with Individual Ticket Numbers
To do this, you need to change the script to require arguments and check for usage. The modified lines would look like this:
#!/usr/bin/perl -w
# You're checking for arguments here. If there are no arguments
# show the usage and exit. E.g. checksn RTM00005
if (@ARGV) {
# The previous program can go here. Make sure you modify this line
# to look like this:
my @requests = $SN->queryRequestedItem({'number'=> $1})
} else {
print "USAGE: checksn [ServiceNow Request ID]\n"
}
Note that there's no error logic for requests that are not found. We're going to have to add this later.
Modify the dzdo.validator script to to use the ServiceNow Perl API script
Centrify provides a sample dzdo validator script called dzcheck.sample. This script exists under /usr/share/centrifydc/bin.
With the author's limited scripting knowledge we were able to modify it to work this way:
Initialize the proper libraries and variables
Retrieve the password for the ServiceNow user (your-user) and store it in SN_PASSWD
Connect to ServiceNow instance
Prompt the user for a Change Control number
If the number is not found, log to syslog and the user will not be allowed to run the command
If the number is found but the status is not approved, log to syslog and the user will not be allowed to run the command
If the number is found and approved, log to syslog and allow the end user to run the command.
Note that additional error logic and checks can be added.
#!/bin/sh /usr/share/centrifydc/perl/run
# A modified demo for Centrify-enhanced sudo (dzdo) validator
# Modified to work with ServiceNow Requests
use strict;
use lib "../perl";
use lib '/usr/share/centrifydc/perl';
use CentrifyDC::Logger;
use ServiceNow;
use ServiceNow::Configuration;
# Use privilege service to retrieve SN shared account password
# Alternatively, you can modify the script to use an OAuth token
my $SN_PASSWD = `cgetaccount -s -t 3 your-user`;
my $dzdo_user=$ENV{DZDO_USER};
my $dzdo_command=$ENV{DZDO_COMMAND};
my $dzdo_runasuser=$ENV{DZDO_RUNASUSER};
my $CONFIG = ServiceNow::Configuration->new();
$CONFIG->setSoapEndPoint("https://your-instance.service-now.com/");
$CONFIG->setUserName("your-user");
$CONFIG->setUserPassword($SN_PASSWD);
my $SN = ServiceNow->new($CONFIG);
my $logger = CentrifyDC::Logger->new('dzcheck');
printf STDERR "Enter the change control ticket number: ";
my $user_input=<>;
my @requests = $SN->queryRequestedItem({'number' => $user_input});
# Check if request(s) exist, if not, exit (1)
if (scalar(@requests)==0)
{
system "adsendaudittrailevent", "-t", "tkt_id", "-i", "$user_input";
$logger->log('INFO', "Change control ticket number: %s", $user_input);
$logger->log('INFO', "User \"%s\" will not be allowed to run \"%s\" as \"%s\" with ticket number (REASON:not found) \"%s\"", $dzdo_user, $dzdo_command, $dzdo_runasuser, $user_input);
exit 1;
}
foreach my $request (@requests) {
my $req_status = $request->{'approval'};
# Exit if request is not in approved status
if ($req_status ne "approved")
{
system "adsendaudittrailevent", "-t", "tkt_id", "-i", "$user_input";
$logger->log('INFO', "Change control ticket number: %s", $user_input);
$logger->log('INFO', "User \"%s\" will not be allowed to run \"%s\" as \"%s\" with ticket number (REASON:not approved) \"%s\"", $dzdo_user, $dzdo_command, $dzdo_runasuser, $user_input,$req_status);
exit 2;
}
}
# Run command and log if request is approved
system "adsendaudittrailevent", "-t", "tkt_id", "-i", "$user_input";
my $logger = CentrifyDC::Logger->new('dzcheck');
$logger->log('INFO', "Change control ticket number: %s", $user_input);
$logger->log('INFO', "User \"%s\" will run \"%s\" as \"%s\" with ticket number \"%s\"", $dzdo_user, $dzdo_command, $dzdo_runasuser, $user_input);
exit 0;
I've saved this script as dzcheck.snow in the same location.
Configure Centrify-enhanced sudo (dzdo) to use the ServiceNow Requests validator
Open the /etc/centrifydc/centrifydc.conf file for editing
Uncomment the dzdo.validator and set it to our scripts
Testing
We'll use a modified version of the sample script to check the requests for validity first, then we'll try to flush the cache using dzdo.
Ticket does not exist (ABC123)
Request verification
$ ./sncheck ABC123
Request not found.
$ dzdo adflush
Enter the change control ticket number: ABC123
Sorry, user dwirth is not allowed to execute '/usr/sbin/adflush' as root on engcen6.centrify.vms.
# syslog contents
Sep 20 18:00:52 engcen6 dzcheck.snow[35963]: Change control ticket number: ABC123
Sep 20 18:00:52 engcen6 dzcheck.snow[35963]: User "dwirth@centrify.vms" will not be allowed to run "/usr/sbin/adflush" as "root" with ticket number (REASON:not found) "ABC123#012"
Sep 20 18:00:52 engcen6 adclient[1526]: INFO AUDIT_TRAIL|Centrify Suite|dzdo|1.0|1|dzdo denied|5|user=dwirth(type:ad,dwirth@CENTRIFY.VMS) pid=35961 utc=1474412452436 centrifyEventID=30001 status=DENIED service=dzdo command=/usr/sbin/adflush runas=root reason=Dzdo Validator checks failed. Do not permit to continue the privileged command.
Ticket is not approved (RITM0010022)
Request verification:
$ ./sncheck RITM0010022
number of requests=1
Request number: RITM0010022
Requested by: robertson.pimentel@centrify.com
Date Created: 2016-09-16 16:55:06
Approval Status: requested
$ dzdo adflush
Enter the change control ticket number: RITM0010022
Sorry, user dwirth is not allowed to execute '/usr/sbin/adflush' as root on engcen6.centrify.vms.
# syslog content
Sep 20 18:03:04 engcen6 dzcheck.snow[36011]: Change control ticket number: RITM0010022
Sep 20 18:03:04 engcen6 dzcheck.snow[36011]: User "dwirth@centrify.vms" will not be allowed to run "/usr/sbin/adflush" as "root" with ticket number (REASON:not approved) "RITM0010022#012"
Sep 20 18:03:04 engcen6 adclient[1526]: INFO AUDIT_TRAIL|Centrify Suite|dzdo|1.0|1|dzdo denied|5|user=dwirth(type:ad,dwirth@CENTRIFY.VMS) pid=36009 utc=1474412584884 centrifyEventID=30001 status=DENIED service=dzdo command=/usr/sbin/adflush runas=root reason=Dzdo Validator checks failed. Do not permit to continue the privileged command
Ticket is approved (RITM001003)
$ ./sncheck RITM0010003
number of requests=1
Request number: RITM0010003
Requested by: diego.jimenez@centrify.com
Date Created: 2016-09-11 14:57:57
Approval Status: approved
$ dzdo adflush
Enter the change control ticket number: RITM0010003
Demo Password:
DNS cache flushed successfully.
Authorization cache store flushed successfully.
GC and DC caches expired successfully.
The auditing service's name cache has been successfully flushed.
The DirectAudit installation information cache has been successfully flushed.
# syslog content
Sep 20 18:06:22 engcen6 dzcheck.snow[36108]: Change control ticket number: RITM0010003
Sep 20 18:06:22 engcen6 dzcheck.snow[36108]: User "dwirth@centrify.vms" will run "/usr/sbin/adflush" as "root" with ticket number "RITM0010003#012"
Sep 20 18:06:22 engcen6 adclient[1526]: INFO AUDIT_TRAIL|Centrify Suite|dzdo|1.0|0|dzdo granted|5|user=dwirth(type:ad,dwirth@CENTRIFY.VMS) pid=36106 utc=1474412782119 centrifyEventID=30000 status=GRANTED service=dzdo command=/usr/sbin/adflush runas=root role=UNIX Sysadmin/Global env=(none)
Benefits if you're using DirectAudit
If you have Enterprise Edition, DirectAudit's events will contain information about the Change Control and you can now search for all activity related to an individual change control number.
Benefits if you're using the Centrify Splunk App
The Splunk App will display reports on the reasons why the privilege elevation failed. You can also add alerts based on this to identify any privileged user trying to fish.
Improvements
This is a lab blog post, therefore this is just a simple concept, but here are the improvements I'd make:
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:
In Cloud Manager, navigate to Settings > Network > Cloud Connectors
Click the "Add Cloud Cloud Connector"
Download the bits and run setup. All you need is the cloud connector componetn.
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:
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]
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.
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.
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.
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.
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.
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
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.
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.
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.
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
Upload your PKI trust chain to your tenant using Centrify Support
Log
in to Cloud Manager and go to Policies > [policy that applies to
employees] > User Security Polcies > Login Authentication
Edit the "Other Settings" accordingly:
Press Save
Test Matrix
Contractor can self-service enroll their OATH OTP using the user portal
Access
the Centrify Identity Service (or Privilege Service portal) requires
OATH OTP, then password (to protect the user's Password).
Access a designated application (e.g. Amazon AWS) requires OATH OTP.
Testing for Employees
Authenticate using your Smart Card or YubiKey
Attempt to access Centrify Privilege Service or Identity service URL or SP-initiated connection.
Select the Certificate in the picker.
Type the PIN for your smart card or YubiKey
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.
I'll be focusing on Strong Authentication using Smart Card. Recently got a hold of some Yubikeys. Yubikeys make the process of implementing strong authentication much easier.
Historically Centrify has supported PKI authentication for years and you'll be able to see how easy this is to set up.
The first scenario focuses on Servers:
Strong Authentication (PKI)
Leverage what you have: Active Directory, Microsoft CA, Group Policies
Enforcing Smart Card access to UNIX/Linux/Mac systems (Windows systems support this natively)
Use DirectAuthorize roles to limit access to strongly authenticated sessions
Strong Authentication for Windows Privilege Elevation
Applications
Desktops
We already covered Access and Privilege Elevation For UNIX/Linux using Centrify MFA here:
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
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
In Active Directory Users and Computers, navigate to an OU for a CIS bridged-domain.
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.
In Cloud Manager, navigate to Role and Click Add Role
Description: AWS Root
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.
In Cloud Manager, navigate to Role and Click Add Role
Description: AWS Root Approvers
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
In Cloud Manager, navigate to Apps > Add Web App
In the Search Box, type AWS
and press Enter, on the results, pick the "Amazon Web Services AWS
User/Password" template and click Add.
When ask to confirm if you want to add the app, click Yes. This will open the app template for configuration.
Description - in this step you will change the name to something descriptive to your environment.
User Access - check the box next to the role you created for this purpose (in our example AWS Root)
Policy - we'll revisit this in the "Adjustments" section.
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.
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.
Sign-in to the Centrify Identity Service User Portal with a user from the AWS Root Role
You should see the AWS As Root App. Click on it.
This should launch a new
browser tab and provide you with assisted injection of the credentials
using the Centrify Browser Extension.
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.
Precondition: An Active Directory writable domain controller has to be reachable by means of the corporate network or VPN.
