Announcing a new series!!!

 

I recently got some YubiKeys from HQ (thanks @Peter) and since they provide all-in-one smart card (PIV) and OTP (OATH) capabilities plus they work great with Centrify products. 

 

Here are the series links:

Part 1: Securing Windows Server Access and Privilege Escalation with Centrify, Active Directory and ...

Part 2: Securing local and remote access to UNIX/Linux with Centrify, Active Directory and YubiKey

Part 3: Using SmartCard (or YubiKey) to secure Apps, Shared Secrets an Sessions with CIS and CPS

 

 

About the Series

This new series showcases our  MFA Everywhere initiative and we'll be posting a series of HOWTO labs to cover several scenarios:

Strong Authentication (PKI) Smart Card / Yubikey

  • 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:  http://community.centrify.com/t5/Community-Tech-Blog/LABS-Setting-up-the-MFA-for-Servers-feature-of-...

 

Strong Authentication (Smartcard/Yubikey) & OATH OTP access

  • IdP Portal Access
  • OnPrem or SaaS Application Access
  • Privilege Portal Access
  • Privilege Password Manager  (Shared Account Password Manager)
  • Privilege Session Manager (Jump Box)

 Here's a quick overview/demo

 

Lab - Base Setup

The base setup is the pre-requisite for all the Yubikey/SmartCard related labs.

 

What you'll need

  • Active Directory with Certificate Services
  • A domain joined member server with Centrify Server Suite 2016
    • .NET 3.x features enabled
    • Feature RSAT:  Active Directory, Group Policy Management and Certificate Services tools
  • One or two UNIX/Linux systems with Centrify Standard Edition 2016  (5.3+)  (if testing UNIX/Linux)
  • Access to Centrify Standard Edition installation files (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.

 

Create Test Users and AD Group

On the member server

  1. Open Active Directory Users and Computers and navigate to your desired OU
  2. Right click and select New > User  and follow the wizard until the user is created.
  3. Right click the newly-created user and select properties.  In the general tab, update the Email to match the user principal name.
    e.g. user@corp.contoso.com and press OK.
  4. Right click the OU and select New > Group and make it a Global/Security group.  Call it "Smart Card Users"
  5. Right click the Group, select properties, go to the Members tab, press Add and add the user created in step 2.
  6. On the member server, grant the group or user the ability to log on remotely. 
    Computer > Properties > Remote Settings > Remote Desktop > Select Users  > Add > [select user or group] press OK twice.

Certificate Services

Modify the Smart Card User template

  1. Open the Certification Authority console  (Start > Search > Certification Authority)
    If you get an error, retarget the console to the appropriate server (e.g. DC1)
  2. On the left pane, right click "Certificate Templates" and select Manage.  This will open the Certificate Templates console.
  3. In the template list, right-click the SmartCard User template and select "Duplicate Template"
  4. In the General tab, give the template a descriptive name.  I used "Smart card User V2"  (this is the display name, the actual template name is SmartcardUserV2)
  5. Click on the Security tab, press Add, select the newly-created Smart Card Users group, check the Enroll and Autoenroll boxes, then press OK and close the Certificate Templates console.

Publish the Newly-Created Template

  1. In the Certification Authorities console, on the left pane, right click "Certificate Templates" and select New > Certificate Template to Issue
  2. Select the newly-created version of the Smart Card User template  (e.g. Smart Card User v2) and press OK.

Provision the Smart Card User Certificate into your Yubikey

  1. Log on to your member system with the test user.
  2. Open the Yubikey PIV manager tool with the Test User  (shift+right click > run as different user)
  3. If you're using a VM, connect the Yubikey to your virtual machine.
    Note:  If you're using VMWare, you need to add the parameter below for the Yubikey to be available to your VM.
    usb.generic.allowHID = "TRUE"
    This step is performed by editing the .vmx file and editing it with your current text editor while the VM is off.
  4. Initialize the Yubikey if brand new.  Do not forget the PIN.
  5. In Yubikey PIV manager, press Certificates > Generate New Key and make sure you type the Certificate Template name (not the display name) and press OK.
  6. Type the PIN when challenged, and select your existing CA.  In my case I use the non HTTP link and press OK

  7. To test the smart card authentication, either lock your screen or logoff.  If you can unlock or login successfully, you should be ready for the next steps.

 

Lab Verification Video

Background

Step-up authentication can provide additional security controls to prevent unauthorized access to systems or controlled privileged elevation.  Server Suite 2016 uses the established step-up authentication methods of Centrify Identity Service (Token via Centrify Mobile Authenticator, SMS, Phone factor, E-Mail and User-defined security question); the key differentiators are the combination of Role-Based Access Control (RBAC) with step-up authentication and context awareness (time/access/privilege).

 

To complete this lab you need:

  • Familiarity with Centrify Server Suite consoles:  Access Manager
  • Familiarity with Centrify RBAC concepts:  hierarchical zones, role definitions, role assignments
  • Familiarity with Active Directory and tools:  AD users, security groups, Active Directory Users and Comuters
  • Familiarity with TCP/IP:  ports, protocols

You don't need to be familiar with Centrify Identity Service.  We will outline the set-up steps for this configuration.

 

Planning

Potential Stakeholders

  • Centrify SME:  These users are entitled to perform management of zone operations inside Active Directory.
  • Security Lead:  The security lead can answer questions like these:
    a) What servers require step-up authentication for login?
    b) What privileged actions require step-up authentication?
    c) What servers require step-up authentication based on day/time?
  • IT/AD Infrastructure lead:   This SME will help setting up a Windows Server to act as the cloud connector

Technical Requirements

Active Directory and Centrify

  • A licensed or evaluation copy of Centrify Suite 2016
  • An Active Directory test or production environment with Centrify a Centrify Hierarchical zone
  • A UNIX/Linux system with Centrify DirectControl 5.3+
  • A Centrify Identity Service tenant with at least one Cloud Connector acting as an Active Directory bridge
  • For step-up methods (user-defined security question can be used if none below are available):
    a) an iOS or Android device for token testing (optional)
    b) a mobile phone to test SMS
    c) an e-mail account
    d) a phone line for phone factor

Software as a Service (Cloud) - Quick Security/Assurance FAQ

  1. What is Centrify Identity Service (CIS)?
    CIS is an Identity as a Service (IDaaS) that provides Identity, Single Sign-On, Mobility Management, Policy and Multifactor Authentication among other capabilities. The service is "connector-based";  this means that there's a server running on premises that communicates with the service.  This is a very common architecture used by solutions like ServiceNOW or Office365.
  2. Why is a SaaS solution required to provide multi-factor authentication?
    The answer boils down to time-to-production, cost and efficiencies of a software as a service solution versus the overhead of an on-premises alternative.  Centrify is re-using their existing Identity Platform and extending it to Server Suite.
  3. What are the mechanisms that Centrify implements to provide assurance for confidentiality?
    Each tenant gets their own key and PKI Certificate Authority, this provides the assurance that:
    a) only the tenant owner can decrypt traffic that has been encrypted at rest or in transit
    b) the cloud connector will repudiate connections from any other source
    c) an additional layer of encryption is provided in addition to SSL
    The cloud service and the cloud connector must be authorized by two parties:  the tenant admin and an AD admin.
  4. What are the mechanisms that Centrify implements to provide high-availability?
    a) CIS runs on top of Microsoft Azure.  Azure provides hardware, datacenter, nearby datacenter and geographical datacenter redundancies.
    b) Centrify implements mechanisms that guarantee that upgrades don't cause downtime
    c) Cloud Connectors are constantly monitored for health and failover is automatic
    d) In the context of Server MFA, the tokens and SMS contain a code that can be used asynchronously
    e) In the context of Server MFA, roles with rescue rights are available;  this allows the bypassing of MFA in case of a disaster.
  5. Are the Cloud Connector public facing or in the DMZ?
    No.  Cloud connectors aren't required to be public facing or in your DMZ; they can be inside your private network and even can work behind a proxy server.  The cloud connectors will establish an outbound HTTPS connection.  The documentation explains target sources and destinations.
  6. Is outbound Internet access required for systems that use the MFA for servers feature?
    No.  The systems only need to talk to the on-premise cloud connector in a mutually authenticated, encrypted and configurable port, in turn the cloud connector validates if the systems are authorized for MFA and acts as a broker with our Identity Platform.
  7. What other assurance mechanisms are provided by Centrify for their Cloud Solutions?
    Certifications:  SOCII, SafeHarbor, TrustE.  Centrify is working on FedRAMP certification attainment.
  8. Where can I find more information?
    For more information:  http://www.centrify.com/support/centrify-trust/trust/

Resources

How MFA for Servers Works

Components:

Active Directory

  • Centrify Zones contain:
    - Identity data in the form of UNIX RFC2307 fields for provisioned users and groups
    - Authorization (DirectAuthorize) information:  definitions of roles and attributes, rights (commands) and role assignments.
    - Information about the Centrify Identity Service tenant if there's a registered cloud connector in AD
  • Roles can have two MFA-relevant attributes:  "require multifactor authentication" and "rescue rights";  if the first one is checked, users will be prompted to provide step-up authentication to access the system;  if the second one is checked (just like with DirectAudit) all the additional security controls will be bypassed.
  • UNIX commands that have the "require multifactor authentication"  this will prompt the user to provide their password and a step-up authentication method on privilege elevation.
  • Test AD users:  The test AD users need to be UNIX-enabled and have populated attributes like email, telephone or mobile number if email, phone factor or SMS will be requested.

Centrify Server Suite

  • These are DirectControl agents 5.3+ joined to a hierarchical zone.  These systems don't need outbound connectivity to the internet.
  • The AD computer objects need to be authorized to talk to the cloud service (via role) and they should be allowed to communicate to the cloud connector using HTTPS in the web service port (8080 is the default). 

Centrify Identity Service

  • MFA Computers Role:  This role contains the systems authorized to request MFA.  This can be individual computers or AD groups that contain the AD computer objects.  They must have the Server Login and Privilege elevation right.
  • Server Authentication and Privilege Elevation Authentication Profiles:  You can define what step-up methods are available and even if there's additional mechanisms to be used.
  • Policy:  A policy that applies to the MFA Computers role needs to be implemented.  This method should allow for Integrated Windows Authentication via Kerberos for machine-to-machine authentication

Cloud Connector

  • This is a Windows system that runs the adproxy service.  The cloud connector only requires an outbound HTTPS connection to talk to the Centrify Identity Service tenant. 
  • Web Service: The cloud connector authenticates authorized agents using Integrated Windows Authentication (SPNEGO)

 The illustration below provides an oversimplified set of steps:

Note that in case of AD connectivity failure, the centrify agent will use the AD methods (sites/services, offline cache) and it also caches the authorization data.

 

A Basic Lab Design

In my test environment I have:

Description

  1. A Centrify Identity Service tenant App Edition (or 30-day trial)
  2. An Active Directory domain (centrify.vms) with a single domain controller (dc.centrify.vms)
  3. A domain-joined server called "member" that has Access Manager installed (Suite 2016 commercial or evaluation)
    Member will also be running the Centrify Cloud Connectors
  4. A Centrify zone called global with 2 computer roles:  App Servers and Web Servers
  5. Two Linux servers.  The names may be slightly different given that I have labs in different stages.
  6. A mobile device with a phone line running iOS or Android.

 

Test Cases

Test Name

What you need

Comments

Step-up on Privilege Elevation

You need a UNIX command with the “Require 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

Disaster Scenario

You’ll need a role with the “Rescue Rights” checkbox set.

This should be familiar to DirectAudit testers

 

Implementation

Download and Install the Centrify Suite 2016 bits

  1. Download the Standard Edition 2016 Consoles
  2. Download the Centrify client bits for your platform
  3. Install Access Manager
  4. Install or upgrade your agents  (e.g. install.sh, rpm or yum, apt or dpkg, etc)
  5. Join a zone (use adjoin)

I will recycle the pre-requisites video for the local account management since the steps are identical:

 

Obtain and Configure a Centrify Identity Service Tenant

  1. To obtain your Tenant
    Follow the steps here:  http://www.centrify.com/free-trial/identity-service-form/
    Follow the steps until you activate your tenant and log in with the cloud admin account for the tenant.  You have to secure those credentials.
  2. Set up a Cloud Connector (Settings > Cloud Connectors)
    You can see steps here (download-install-configure-authorize).  Other than the "next-next" steps here what needs to be understood is what is the Cloud Connector doing.  The Centrify cloud connector service runs on Windows and provides AD bridging.
    a) The CC talks to the cloud service on behalf of your servers; uses PKI for trust and non-repudiation.
    b) The CC makes outbound connections  over HTTPS that are double-encrypted (SSL + tenant key)
    c) it has to be authorized to read objects from the AD domain by a privileged AD administrator
    d) The CC needs to authenticate the systems (or group of systems) that will use step-up using SPNEGO over 8080 (default)
    Note that if your're working in an isolated lab, this port has to be open between your Linux systems and the CC.
    e) The CC will provide information to the cloud service about email, phone numbers, etc so the user can get the step-up challenge
    f) For MFA testing, you can disable all other capabilities of the CC (like LDAP bridging and App gateway) to keep configuration to a minimum.
  3. Configure Authentication Profiles (Cloud Manager > Settings > Authentication Profiles)
    You need to set up authentication profiles for both Server Access and Privilege elevation.  For this go to .  Here's what I set up for Server Access:

    What to use for Step-up:  You'll need to use your security savvy here.  The goal is to provide an additional control in case of password compromise.  You would not use email in this case because in an Exchange scenario, the password is the same for the AD user so if a threat agent compromised the user's password, they likely have access to his email.  The best course of action is something the user has like a token or his phone.  That's why I only checked those options.
  4. Set the Server Suite Authentication Profiles (Cloud Manager > Settings > Server Suite Authentication)
    Set the APs for Server Access and Privilege Elevation
  5. Create a Role that Contains your Linux Systems (Cloud Manager > Roles)
    In my case, I created an "MFA Computers" cloud role and as members I added an "MFA Computers" AD group that in turn contains my Linux systems.  This simplifies administration because if I want more Linux systems enforcing MFA, all I need to do is upgrade them to 5.3 and add them to that AD group.
  6. Policy Applied to MFA Computer with IWA  (Cloud Manager > Policies)
    We need to verify that Integrated Windows Authentication is allowed for the User Policy that applies to this role.  This will allow the servers to use Kerberos to authenticate to the web service on the cloud connector.  This is under Policy (e.g. Default Policy) > User Security Policies > Login Authentication

    Ideally, to isolate MFA testing, you will create a new Policy that applies just to the MFA computers role and you stack it higher than your deny-all policy.

Configure Access Manager for Centrify Identity Service Tenant

  1. Open Access Manager and open your Zone. 
  2. Right-click the zone and select properties, click on the Cloud tab and click Browse
    There is now a selectable cloud instance.  This is because of the cloud connector registration.
  3. Select and press OK twice.  Now you can test end-to-end connectivity using the Test Cloud Connection tool

    You have to right-click the "DirectManage Access Manager" node to expose the tool.

Verify that your Centrified Linux system is Cloud Connector-aware

You need to refresh the cache and restart the agent to reflect the AD group membership that will allow the system to interact with the cloud connector.

  1. Sign in to your system (with a user that can elevate)
  2. Run adflush --force
  3. Restart the CentrifyDC service (service centrifydc restart)
  4. Run the 'adinfo --sysinfo' cloud command to verify cloud connector awareness.
    You're all set.

 

Video Playlist

This article describes the steps to install, configure and test the local UNIX user and group management feature included with Centrify Suite 2016.  You will find this article useful if you're looking to accomplish the following goals:

  • Control local UNIX user accounts (provision, disable, visibility or removal from /etc/passwd)
  • Control local UNIX primary or secondary groups (provision, control membership, or removal from /etc/group)
  • Use a single management framework (DirectManage GUI, PowerShell, UNIX adedit)
  • Leverage Centrify Zones, Child Zones or Computer Roles stored in Active Directory
  • Perform actions upon user creation/deletion, e.g. home directories, environment variables, password management/lifecycle.

Disclaimer:  This post is not a best practice, it's simply to aid you to study and test the feature before your consider it for production scenarios.

Read more...

In the original article about orchestration basics, we set up a basic implementation of YellowDog Updater Modified (YUM) for RHEL and derivatives (CentOS, Scientific, Oracle Linux, etc) in different architectures

(Intel, Power, zLinux).

 

In this second article of the series we discuss how we can use a simple (non-idempotent) Chef recipe to deploy, and join a node to Active Directory with Centrify DirectControl.

Read more...

Showing results for 
Search instead for 
Do you mean 
Labels
Leaderboard

Community Control Panel