Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >

[Labs] Using Centrify+AD+YubiKey to secure UNIX/Linux access with Strong Authentication

11 April,19 at 11:51 AM


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.



  • 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.


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)
    Access Manager - role Strong Auth.png
  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.
    Access Manager - role command.png
  3. Add the rights to the role.  Right click the "UNIX WebAdmin - StrongAuth"  role and select "Add Right"
    Access Manager - role command.png
  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.
    Access Manager - assigned.png
    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
      CentrifyDC.x86_64 0:5.3.0-213   CentrifyDC-openssh.x86_64 0:7.1p1-
  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.
  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
    No old reverse records deleted because no host records found for centos67.centrify.vms on
  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
        Effective rights:
            Non password login
            Allow normal shell
        Centrify Cloud Authentication:
            Not Required
        Audit level:
        Always permit login:
    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
    WARNING: This is a PRIVATE system exclusively for Centrify demos
    Your actions will be monitored and recorded.
    Using keyboard-interactive authentication.
    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
    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
    Yubikey UnIX - success.png


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.