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 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,OATH OTP, RADIUS, E-Mail and User-defined security question); the key differentiators are the combination of Role-Based Access Control (RBAC) with step-up authentication and context awareness (time/access/privilege).
To complete this lab you need:
Familiarity with Centrify Server Suite consoles: Access Manager.
Familiarity with Centrify RBAC concepts: hierarchical zones, role definitions, role assignments.
Familiarity with Active Directory and tools: AD users, security groups, Active Directory Users and Comuters.
Familiarity with TCP/IP: ports, protocols.
You don't need to be familiar with Centrify Identity Service. We will outline the set-up steps for this configuration.
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 Centrify 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 Centrify Connector acting as an Active Directory bridge.
For step-up methods (user-defined security question can be used if none below are available): a) an iOS or Android device for token testing (optional) b) a mobile phone to test SMS c) an e-mail account d) a phone line for phone factor
Software as a Service (Centrify) - Quick Security/Assurance FAQ
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 Centrify connector will repudiate connections from any other source. c) the authentication negotiation between the connector and systems happens over HTTPS. The service and the Centrify 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) The cloud service provides hardware, datacenter, nearby datacenter and geographical datacenter redundancies. b) Centrify implements mechanisms that guarantee that upgrades don't cause downtime c) In the context of Server MFA, the tokens and SMS contain a code that can be used asynchronously d) In the context of Server MFA, roles with rescue rights are available; this allows the bypassing of MFA in case of a disaster. Note: You have to make sure Centrify Connectors are constantly monitored for health and that enough of them are deployed to provide redundancy.
Are the Centrify Connector public facing or in the DMZ? No. Centrify 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 Centrify 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 Centrify connector in a mutually authenticated, encrypted and configurable port, in turn the Centrify 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 Centrify Solutions? Certifications: SOCII, SafeHarbor, TrustE. Centrify is working on FedRAMP certification attainment.
Useful tools: Test Centrify Connection applet, adinfo --sysinfo cloud, /usr/share/centrifydc/bin/adcdiag
How MFA for Servers Works
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 Centrify connector in AD
Roles can have two MFA-relevant attributes: "require multifactor authentication" and "rescue rights"; if the first one is checked, users will be prompted to provide step-up authentication to access the system; if the second one is checked (just like with DirectAudit) all the additional security controls will be bypassed.
UNIX commands that have the "require multifactor authentication" this will prompt the user to provide their password and a step-up authentication method on privilege elevation.
Test AD users: The test AD users need to be UNIX-enabled and have populated attributes like email, telephone or mobile number if email, phone factor or SMS will be requested.
Centrify Server Suite
These are DirectControl agents 5.3+ joined to a hierarchical zone. These systems don't need outbound connectivity to the internet.
The AD computer objects need to be authorized to talk to the service (via role) and they should be allowed to communicate to the Centrify connector using HTTPS.
The UNIX/Linux systems have to trust the Centrify tenant's root cert, or the one provided by you (if using a custom certificate).
Centrify Identity Service
MFA Computers Role: This role contains the systems authorized to request MFA. This can be individual computers or AD groups that contain the AD computer objects. They must have the Server Login and Privilege elevation right.
Server Authentication and Privilege Elevation Authentication Profiles: You can define what step-up methods are available and even if there's additional mechanisms to be used.
Policy: A policy that applies to the MFA Computers role needs to be implemented. This method should allow for Integrated Windows Authentication via Kerberos (IWA over HTTPS) for machine-to-machine authentication.
This is a Windows system that runs the adproxy service. The Centrify connector only requires an outbound HTTPS connection to talk to the Centrify Identity Service tenant.
Web Service: The Centrify connector authenticates authorized agents using Integrated Windows Authentication (SPNEGO) over Secure web channels.
The illustration below provides an oversimplified set of steps:
Note that in case of AD connectivity failure, the centrify agent will use the AD methods (sites/services, offline cache) and it also caches the authorization data.
A Basic Lab Design
In my test environment I have:
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 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.
What you need
Step-up on Privilege Elevation
You need a UNIX command with the “Require MFA authentication” flag set.
Start with this test
Step-up on Server Access Elevation
You need a role with the “Require MFA Authentication” flag set.
If using SSH for testing, be mindful of SSH timeouts
Context-aware privilege elevation
You’ll need two roles: No MFA bus hours MFA bus hours
Variation No MFA on QA/Dev and MFA on Prod.
Privilege Elevation w/o AD
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 or SMS
In cases in which you can't receive other factors
You’ll need a role with the “Rescue Rights” checkbox set.
This should be familiar to DirectAudit testers
Download and Install the Centrify Suite 2016 bits
Download the Standard Edition 2016 (and up) 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).
I will recycle the pre-requisites video for the local account management since the steps are identical:
Part I: Obtain and Configure a Centrify Identity Service Tenant
Set up a Centrify Connector (Settings > Network > Centrify 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 Centrify connector doing. The Centrify connector service runs on Windows and provides AD bridging (among other services). a) The connector talks to the cloud service on behalf of your servers; uses PKI for trust and non-repudiation. b) The connector 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 connector needs to authenticate the systems (or group of systems) that will use step-up using IWA (spnego) over HTTPS Note that if your're working in an isolated lab, this port has to be open between your Linux systems and the connector. e) The connector 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 connector (like LDAP bridging and App gateway) to keep configuration to a minimum.
Configure Authentication Profiles (Admin Portal > 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 Privilege Elevation:
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 (Admin Portal > Settings > Authentication > Servers and Workstations) and set the profiles for Login 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. Make sure the group has the "Computer Login and Privilege Elevation" right.
Policy Applied to MFA Computer with IWA (Admin Portal > 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.
Part II: Set up PKI Trust between your *NIX system and Centrify Identity Platform
In Admin Portal > Settings > Network > Centrify Connectors > click the connector > IWA Service and click "Download your IWA root CA certificate"
Locate the file and try to open it with a text editor. If the text reads "--- begin certificate" you are dealing with a usable certificate.
Save the file and transfer it to your target system (e.g. IWACert.crt)
Append the certificate to the CA bundle
In the target system, concatenate the contents of the certificate file to the platform CA bundle. E.g.
Note: there are OS utilities like "update-ca-trust" that perform this step the correct way. This is for illustration only.
Re-run dzdo /usr/share/centrifydc/bin/adcdiag and verify the results.
As you can see, the steps above won't scale in a large environment. This is why the preferred method is to have enterprise trust in place. Other ways to distribute certificate settings include scripts, DevOps solutions like Chef or Puppet and in Microsoft PKI scenarios, you can use Group Policy.
Part III: Configure Access Manager for Centrify Identity PlatformTenant
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.
Verify that your Centrified Linux system is Centrify Connector-aware
You need to refresh the cache and restart the agent to reflect the AD group membership that will allow the system to interact with the Centrify connector.
Sign in to your system (with a user that can elevate)
Run adflush --force
Restart the CentrifyDC service (e.g. service centrifydc restart)
Run the 'adinfo --sysinfo cloud' command to verify cloud connector awareness. You're all set to start testing.