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
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
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
- 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. - 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. - 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. - 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. - 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. - 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. - What other assurance mechanisms are provided by Centrify for their Cloud Solutions?
Certifications: SOCII, SafeHarbor, TrustE. Centrify is working on FedRAMP certification attainment. - Where can I find more information?
For more information: http://www.centrify.com/support/centrify-trust/trust/
- 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.
- 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).
- 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
- 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)
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
- A Centrify Identity Service tenant App Edition (or 30-day trial)
- An Active Directory domain (centrify.vms) with a single domain controller (dc.centrify.vms)
- 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 - A Centrify zone called global with 2 computer roles: App Servers and Web Servers
- Two Linux servers. The names may be slightly different given that I have labs in different stages.
- 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- Download the Standard Edition 2016 Consoles
- Download the Centrify client bits for your platform
- Install Access Manager
- Install or upgrade your agents (e.g. install.sh, rpm or yum, apt or dpkg, etc)
- Join a zone (use adjoin)
Obtain and Configure a Centrify Identity Service Tenant
- 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. - 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. - 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. - Set the Server Suite Authentication Profiles (Cloud Manager > Settings > Server Suite Authentication)
Set the APs for Server Access and Privilege Elevation - 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. - 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.
- Open Access Manager and open your Zone.
- 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. - 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.
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.
- Sign in to your system (with a user that can elevate)
- Run adflush --force
- Restart the CentrifyDC service (service centrifydc restart)
- Run the 'adinfo --sysinfo' cloud command to verify cloud connector awareness.
Video Playlist
