Background

This is the the third lab in the series around Strong Authentication.  In the previous lab we focused on StrongAuth for UNIX/Linux using PKI Smart Card or YubiKey.

We will be focusing on securing access to Internal web or SaaS apps, shared credentials and privileged sessions using Centrify Identity Service and Privilege Service.

 

If you're familiar with Identity Service and Privilege Service, they provide built-in MFA and step-up authentication like:

  • Centrify Mobile Authenticator
  • RADIUS Client (SecurID, Vasco, Symantec, etc)
  • 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 different flavors of Centrify MFA.png

 

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 multiple individual/non-cohesive solutions to secure servers, secure apps, provide multifactor and other services.  This promotes IT 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.

Opportunities

  • 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.
  • For SSO to work, the system browser needs to be configured accordingly.
    See this link to configure your browser

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

 

Scenario Description: 
Contractor Access

  • 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

 

Yubikey - SaaS&SAPM.png

 

Centrify Identity Service (or Privilege Service) Setup for Contractors

  1. 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.
  2. 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 - see other considerations at the bottom]
    OATH OTP Name:  [type a descriptive name]; I used "Google Authenticator or YubiKey"
    CIS - OATH OTP.png
    OATH OTP has been enabled, now it's time to enable it for an authentication profile.
  3. 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.
  4. Navigate to Settings > Authentication > Authentication Profiles and identify the profiles form Step 3.
    For each profile:
    Auth profile contractor.png
    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]"
    CIS- yubikey-onboard.jpg
  • Bulk (this is for larger deployments); from Cloud Manager > Settings > Authentication > Other > OATH Tokens
    CIS - OATH bulk.png
    Use the provided Excel template to perform a bulk import of OATH tokens.

Centrify Identity Service (or Privilege Service) Setup for Smart Card Employees

  1. You can reuse the smart card certificate provisioned to YubiKey in the announcement + lab setup post.
  2. In Cloud Manager, go to Settings > Authentication > Certificate Authorities
    pic-ca.png
    Give it a name, and select a method for extracting the username (SAN, RFC822 or Subject) and press Save.
  3. Enable the policy in  Policies > [policy that applies to employees] > User Security Polcies > Login Authentication
  4. Edit the "Other Settings" accordingly:
    CiS - policy pki.png
  5. Press Save
    When testing, use a browser that supports Cert-based auth and is configured correctly for your PKI infrastructure.

 

Test Matrix

  1. Contractor can self-service enroll their OATH OTP using the user portal
  2. Access the Centrify Identity Service (or Privilege Service portal) requires OATH OTP, then password (to protect the user's Password).
    Yubico - Auth.png
  3. Access a designated application (e.g. Amazon AWS) requires OATH OTP.

Testing for Employees

  1. Authenticate using your Smart Card or YubiKey
  2. Attempt to access Centrify Privilege Service or Identity service URL or SP-initiated connection.
  3. Select the Certificate in the picker.
  4. Type the PIN for your smart card or YubiKey
    Smart Card - CIS.PNG
  5. 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.
    CIS - OATH qr policy.png

Background

This is the the second lab in the series around Strong Authentication.  In the previous lab we focused on StrongAuth for Windows access and privilege elevation with YubiKey.

We will be focusing on UNIX/Linux system access leveraging strong authentication to Windows (or Mac) systems via smart card or YubiKey.  Centrify Server suite allows definitions of roles that only allow non-password authentication to be enforced.   YubiKeys are full-fledged personal identity verification (PIV) cards that work very well with AD and Certificate Services.

 

Challenges

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

Opportunities

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

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

Lab Goals

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

What you'll need

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

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

 

Scenario Description: 

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

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

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

 

Centrify Setup

In this instance we are setting up a Web Admin role that contains the pre-defined "login-all" PAM right.  We are not breaking down the rights to prove that we can stop the user from logging in via console or via SSH with a password. 

The privileged user assigned the role must have authenticated with her YubiKey or SmartCard to obtain a Kerberos TGT from Active Directory, subsequently, Centrify DirectAuthorize will be in charge of denying access to the user if they don't use SSO for access (via Kerberos or GSSAPI).  All we're going to need is a zone and a role. 

 

To set up using PowerShell

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

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

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

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

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

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

To perform the steps for the script above manually

Create, Configure and Assign the Demo role

 In Access Manager > Open they Yubikey-Demo zone > Authorization > Right Click Role Definitions > Select Add Role

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

    Note: This is a permanent direct assignment to a user principal at the zone level.  This is not the best practice, typically you grant role assignments temporarily (for attestation), in a subset of systems and to AD groups for better administration.

 Install DirectControl and join the system to the Centrify Zone

  1. Use your preferred software distribution method to copy the Centrify software
    In my case I already have a local repo for RHEL and derivatives.  (Read how to set up here)
  2. Log in to your UNIX/Linux system and use your favorite package manager to install Centrify DirectControl and Centrify-enhanced OpenSSH
    $ sudo yum install CentrifyDC CentrifyDC-openssh
    [truncated]
    Installed:
      CentrifyDC.x86_64 0:5.3.0-213   CentrifyDC-openssh.x86_64 0:7.1p1-5.3.0.208
    Complete!
  3. Now Join the Centrify zone and you'll be ready for testing.  Use the adjoin command and an authorized user:
    $ sudo adjoin -z Yubikey-Demo -c "ou=servers,ou=unix" -u dwirth centrify.vms
    [sudo] password for centrifying:
    dwirth@CENTRIFY.VMS's password:
    Using domain controller: dc.centrify.vms writable=true
    Join to domain:centrify.vms, zone:Yubikey-Demo successful
    
    Centrify DirectControl started.
    [truncated]
    
  4. If your system was not resolvable by Windows DNS, you can use the addns command to register automatically with dynamic updates (if your DNS zone allows):
    $ sudo /usr/sbin/addns --update --machine
    Updating both HOST and PTR record for: centos67.centrify.vms
    Deleting old reverse lookup records for centos67.centrify.vms on 192.168.81.10.
    No old reverse records deleted because no host records found for centos67.centrify.vms on 192.168.81.10.
    
  5. Verify that your users are correctly UNIX-enabled and with the expected rights (use adquery user and dzinfo)
    $ adquery user maggie.simpson
    maggie.simpson:x:1040191002:1040191002:Maggie Simpson:/home/maggie.simpson:/bin/bash
    
    $ sudo  dzinfo maggie.simpson --roles
    User: maggie.simpson
    Forced into restricted environment: No
    Centrify Cloud Authentication: Supported
    
      Role Name        Avail Restricted Env
      ---------------  ----- --------------
      UNIX Webadmin -  Yes   None
      StrongAuth/Yubi
      key-Demo
    
        Effective rights:
            Non password login
            Allow normal shell
            Visible
    
        Centrify Cloud Authentication:
            Not Required
    
        Audit level:
            AuditIfPossible
    
        Always permit login:
            false
    
    All set on the Centrify side.

Configure your Test user for Smart Card Authentication

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

 

Test Plan:

  1. Try to access the system with any other AD user than test user - expected result:  Access Denied
    This is because users need to be explicitly be granted access a UNIX identity and a Centrify role in the zone for the computer.
    login as: dwirth
    -----------------------------------------------------------------
    CENTRIFY DEMO -
    -----------------------------------------------------------------
    WARNING: This is a PRIVATE system exclusively for Centrify demos
    Your actions will be monitored and recorded.
    -----------------------------------------------------------------
    Using keyboard-interactive authentication.
    Password:
    Access denied
    Using keyboard-interactive authentication.

  2. Try to access the system with your test user (Maggie) with her password (Console or SSH) - expected result:  Access Denied
    This is because the test user was defined with "Smart card required for interactive logon"
    login as: maggie.simpson
    -----------------------------------------------------------------
    CENTRIFY DEMO -
    -----------------------------------------------------------------
    WARNING: This is a PRIVATE system exclusively for Centrify demos
    Your actions will be monitored and recorded.
    -----------------------------------------------------------------
    Using keyboard-interactive authentication.
    Demo Password:
    Using keyboard-interactive authentication.
    Account cannot be accessed at this time.
    Please contact your system administrator.
    
  3. Log in to Windows system (you are forced to smartcard login) - Launch PuTTY (configured for SSO)
    Expected result:  Access Granted

 Video

Other considerations:

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

Background

This is the first lab in the series around Strong Authentication (series link).  We will be focusing on Windows systems and providing strong authentication for privileged users using Yubikeys.   Yubikeys are full-fledged personal identity verification (PIV) cards that work very well with Active Directory Certificate Services and Centrify software for UNIX, Linux and Windows.

 

The challenges

  • The Windows security model lends itself for organizations to grant additional privileges to users by way of the local Administrators group.  In Active Directory environments organizations struggle with excessive memberships on privileged groups like Domain Admins.
  • In Active Directory, a common mitigation strategy is to provision each privileged user an "administrative" account (e.g. joe/joe-a).  This strategy can be supplemented by having the "-a" account password stored securely.
  • Unfortunately, advanced attacks like password mining, pass-the-hash and others have become more ubiquitous, this makes a member of a privileged group ("-a" or not) more susceptible to exposure.
  • The "dual account" model is often paired with PSM (jumpbox) to provide session brokering and recording.  Unfortunately, this model can be circumvented by bypassing the jumpbox, and since the "-a" account is very powerful, that means that the privileged user can go anywhere.

The opportunity

Although Centrify can accommodate the "dual account" model using Centrify Privilege Service, ideally organizations would implement the least privilege model:

  • Users shall only access the systems they need to based on business need-to-know with strong authentication
  • Users shall be limited to the minimum privileges required for their functions:  this is accomplished by providing users roles with the rights that they need.
  • Rights shall be assigned in the context of applications, desktops and network rights.  Strong authentication shall be required when using privilege elevation.
  • In sensitive systems, access and privilege elevation shall be supplemented with session capture and replay.

Lab Goals

  • Limit privileged users to a subset of Windows systems based on their needs (AD and Centrify Zones enable this)
  • Require strong authentication for console or remote (RDP) access  (this is supported natively by Windows)
  • Require strong authentication on Privilege Elevation (applications/desktops)  (DirectAuthorize is Smart Card ready)
  • Reproduce privileged sessions (session capture, transcription, replay).

What you'll need

  • Active Directory with Certificate Services
  • A domain joined member server with Centrify Server Suite 2016
  • Access to Centrify Standard Edition (evaluation or licensed)
  • Yubikey PIV Manager  (download link)
  • Yubikey 4, NANO or NEO
  • You need working knowledge of Active Directory and Centrify Zones

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

 

Scenario Description: 

We'll use the smart card user certificate provisioned to your test user's Yubikey.  In Active Directory we'll require smart card authentication for the user (this also be implemented in a subset of systems using Group Policy).

We will grant the test user a Centrify DirectAuthorize role that allows her to:

  • Run Disk Management as the local administrator and will require strong authentication to be launched
  • Use an administrative desktop  (as local administrator) and requires strong authentication to be launched

 

Complete the Base Lab Setup

The base lab set up is in the announcement post:

http://community.centrify.com/t5/Community-Tech-Blog/Labs-New-Series-Strong-Authentication-using-Cen...

 

Centrify Setup for Windows Access and Privilege Elevation

To set up using PowerShell

Import-Module ActiveDirectory
Import-Module Centrify.DirectControl.PowerShell
$user = Get-ADUser -Identity Lisa.Simpson # substitute for your user
$cont = "cn=zones,ou=unix,dc=centrify,dc=vms" # substitute for your container DN
$zone = New-CdmZone -Name "Yubikey-Demo" -Container $cont

$criteria1 = New-CdmMatchCriteria -Description "Disk Management - Direct" -FileType "msc" -FileName "diskmgmt.msc" -Argument " "   -Path "C:\Windows\System32\"
$criteria2 = New-CdmMatchCriteria -Description "Disk Management - MMC" -FileType "exe" -FileName "mmc.exe" -Argument "C:\Windows\system32\diskmgmt.msc"  -Path "C:\Windows\System32\"
$cmd1 = New-CdmApplicationRight -Zone $zone -Name "Disk Management Combo" -MatchCriteria @($criteria1, $criteria2) -RunasSelfGroups "Builtin\Administrators" -RequirePassword $true
$desktop1 = New-CdmDesktopRight -Zone $zone -Name "Admin Desktop" -RunasSelfGroups "Builtin\Administrators" -RequirePassword $true

$role = New-CdmRole -Zone $zone -Name "Demo Role" -WinSysRights remote
Add-CdmApplicationRight -Right $cmd1 -Role $role
Add-CdmDesktopRight -Right $desktop1 -Role $role

New-CdmRoleAssignment -Zone $zone -Role $role -TrusteeType ADUser -ADTrustee $user | Out-Null

To perform the steps for the script above manually

Create the Zone

  1. Open Access Manager and right-click Zones > Create New Zone
    Name:  Yubikey-Demo
    Container:  Browse to your container.
  2. Press Next and Finish

Create the Disk Management Application

  1. Launch Disk Management (e.g. Start > Run > diskmgmt.msc)
  2. Open Access Manager > Open they Yubikey-Demo zone > Authorization > Windows Right Definitions > Right Click Applications > New Windows Application
    Name: Disk Management ComboMatch Criteria:  Press Add > Import Process and Select Disk Management and Press OK

    Press Add > Import File > Browse to c:\Windows\System32 and select diskmgmt.msc, press OK.
    This will add another way to launch the application.
    RunAs:  Self with added group privileges > Press Add Builtin Groups > Select Administrators, press OK and check the box for Authentication Required and press OK.

Create the Admin Desktop Right

  1. In Access Manager > Open they Yubikey-Demo zone > Authorization > Windows Right Definitions > Right Click Desktops > New Windows Desktop
    Name: Admin Desktop
    Runas:  Press Add Builtin Groups > Select Administrators, press OK and check the box for Authentication Required and press OK.

Create, Configure and Assign the Demo role

 In Access Manager > Open they Yubikey-Demo zone > Authorization > Right Click Role Definitions > Select Add Role

  1. Name:  Demo Role
    System Rights:  "Remote Login is allowed"  <  this will allow the user only to access via RDP
  2. Press OK and right-click the newly created role and select "Add Right"
  3. The role is ready to be assigned.  Now press OK and right-click the Authorization > Role Assignments > Select Assign Role
  4. Press the Add AD account > type the name of your test user, select it and press OK.

    Note: This is a permanent direct assignment to a user principal at the zone level.  This is not the best practice, typically you grant role assignments temporarily (for attestation), in a subset of systems and to AD groups for better administration.

 Install DirectAuthorize for Windows and join the system to the Centrify Zone

  1. In your domain-joined test systems, browse to the path for the Centrify Standard Edition software.
  2. Go to  Agent > and Run "Centrify Windows Agent.exe"
  3. Follow the Wizard, you will select the "Access" components.  If you have DirectAudit, also select Audit.
  4. When the installation ends, you need to configure the client to join your desired zone.
  5. The system will ask to reboot when complete.

Important Notes:

  • When a Windows system is added to the Centrify Zone, the security model changes.
  • In order to access a Centrified Windows system, users must be explicitly granted logon rights.  This means that even Domain Admins won't be able to access those sytsems.
  • The type of access is based on the Windows setup (Remote/Log on Locally) and the Centrify Role definition (Console/Remote)
  • When adding your first system to a zone, you will have an opportunity to explicitly add Domain Admins, otherwise you may completely lock the system

Configure your Test user for Smart Card Authentication

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

 

Test Plan:

  1. Try to access the system with any other AD user than test user - expected result:  Access Denied
    This is because users need to be explicitly be granted access using a Centrify role.

  2. Try to access the system with Lisa with her password - expected result:  Access Denied
    This is because the test user was defined with "Smart card required for interactive logon"
  3. Try to access the system via the console with Smart Card - expected result:  Access Denied
    This is because the role created in Centrify does not grant console login.
  4. Try to access the system via RDP with smart card PIN - expected result:  Access Granted
  5. Try to run application "disk management" normally - expected result:  Error: "You don't have access rights to logical Disk Manager on [Server]"

    This is because when the user launches the app, they are doing so without any privileges.
  6. Launching App or Privileged Desktop:
    Right click App > Run with Privilege >  Challenge with Password - Expected result:  Access Denied

    Right click App > Run with Privilege >  Challenge with smart card PIN- Expected result:  Access Granted

 Video Playlist

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

Showing results for 
Search instead for 
Do you mean 
Labels
Leaderboard

Community Control Panel