[Labs] Centrify+AD+Yubikey - Implement Strong Authentication for Windows Server Access and Privilege Elevation

Background
This is the first lab in the series around Strong Authentication.  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 and Certificate Services.

Note:  This lab covers topics related to Public Key Infrastructure.  As previously advised, PKI should be implemented with strong adherence to Security policy, and a well balanced People-Process-Technology triad.

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 local 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 Access Manager and Centrify PowerShell
• 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.

Scenario Description: 
We will provision the proper certificate to a test user (lisa) on her Yubikey.  In Active Directory we'll require smart card authentication for the user.  (This can be done at a group of systems level using OUs and GPOs).
We will grant the test user a Centrify DirectAuthorize role that allows her to:

• Run Disk Management as administrator and requires strong authentication
• Use an administrative desktop  (as local administrator) and requires strong authentication

Optional: We will record her actions using DirectAudit.


Lab Setup
Create Test Users and AD Group

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 (or Smart Card logon) 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).  The subject will match the credential that you launched the Yubikey PIV Manager (e.g. your test user).
6. Type the PIN when challenged, and select your existing CA.  In my case I use the non HTTP link.
   
   
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 Pre-check Video


Centrify Setup
To Create the Zone, Role, Rights and Assignments 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 Active Directory Users and Computers, 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 smart card PIN - Expected result:  Access Granted

 Video Playlist

Using Centrify+Microsoft PKI+Yubikeys to enforce Strong Authentication for UNIX/Linux/Windows Elevation and more....

Announcing a new series!!!

I'll be focusing on Strong Authentication using Smart Card.  Recently got a hold of some Yubikeys. Yubikeys make the process of implementing strong authentication much easier.

Historically Centrify has supported PKI authentication for years and you'll be able to see how easy this is to set up.

The first scenario focuses on Servers:


Strong Authentication (PKI)

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


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
Stay tuned!

A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory - Part 5

Background
This is the fifth and final article in the series titled "A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory" in the previous post we discussed how to integrate your Linux and Windows systems to Centrify zones in AWS Active Directory for the purposes of authentication and privilege management.

In this article we'll discuss how to use Centrify Privilege Service to provide shared account password management, privilege session management and recording and strong access controls.  Here are the detailed goals:

• To provide a redundant secure point of access for AWS-hosted systems
• To provide password lifecycle services:  request-approve-check-out-check-in-rotate-auto/rotate
• To provide temporary access (sessions and password checkouts)
• To provide application to application password management capabilities
• To provide advanced jumpbox access to SSH and RDP systems in AWS
• To be able to proctor in real time
• To be able to review session transcription and provide session replay
• To provide advanced access controls like strong authentication, time-fencing, geo-fencing and more
• To continue to leverage Active Directory or use other identity schemes(LDAP, Google Directory, Social Identity, Centrify Cloud Directory or even a SAML IdP as the identity source)
• Minimize exposure by eliminating the need for elastic IPs (publicly facing)

Centrify Privilege Service Architecture
I've written about CPS in the community before, for some features and demos review this article:  http://centrifying.blogspot.com/2015/08/in-depth-centrify-privilege-service.html

In summary, it is a SaaS-based Password Manager and Jump Box (in Gartner speak, provides SAPM, PSM and AAPM), however it uses the assets of identity service:  Federation, Workflow, AD-Bridge, Multifactor Authentication and more.  CPS has a connector-based architecture like this:


This means that there are several ways to use Privilege Service in IaaS scenarios.  However, I will focus on this type of design:

The benefit oft his design is that it allows flexibility. Here are some highlights:

• The single source of identity continues to be the on-premises Active Directory.  AD Principals (like groups) can be used to control entitlements like who can access the management portal, check out passwords, modify resources, etc.
• Allows for connected or disconnected AWS connectivity.  Cloud Connectors in AWS act as jumpboxes, regardless of the EC2 scheme (domain-joined or not) the connectivity is centralized.
• Advanced Controls like
  • Step-up authentication:  Centrify MFA, OATH OTP, Phone factor, SMS, Email, PKI/Smartcard
  • Allow access only from corporate network: Users must be on-premises to access AWS assets
  • Geo-fencing:  access can be limited to only corporate locations.
  • Workflow:  Resource and password check-outs can use an access request system (Centrify or ServiceNOW)
  • Temporary access control.
• Time-to-Market:  Password and session access can be deployed in minutes by launching an instance and deploying a cloud connector.  The same goes for internal datacenters.

We'll discuss some planning and provide some implementation/verification videos:

Planning
Stakeholders:   Infrastructure Lead, Directory Services Lead, Security lead, AWS SME, UNIX/Linux or Windows image lead, Database (SQL Server) SME etc.

Discussion topics:

• What are the systems that need to be accessed?
  The answer to this question has implications for AWS security groups.  For example, the security group where Cloud Connectors will be residing must be able to establish connections over port 22 (SSH) and 3389 (RDP).
• What are the user populations that need access to AWS systems?
  This determines the identity stores.  User populations can be full-time employees, contractors, vendors, etc.  Depending on the existing strategy, maybe not all users have AD accounts, this is where identity flexibility of CPS becomes handy.  Some examples:
  - Temporary contractors may be provisioned in the Centrify Cloud Directory instead of AD.
  - Perhaps ADFS has been implemented or partners need access, in that case CPS can be the service provider in a federation relationship.
• What are the groups that should manage the system?  what are their entitlements?
  The answer to this question has directory service and functional implications.
• What are the security controls to be put in place?  (strong auth, geo-fencing, time-based controls, workflow/approvals)
  The data classification of the systems determines the controls that should be in place.  The most basic could be that all AWS access must be generated from the corporate IP range, and access to the portal requires strong authentication.
• Password Management lifecycle questions:
  Should approvals be required for password checkouts?  Should multiple password check-outs allowed? should passwords be rotated in a specific interval?  Should password health be monitored? should password be allowed from mobile devices? Should passwords for temporary systems be managed?  Should active directory account passwords be managed?
• Password Storage
  Should the Centrify Secure Storage be used or is a physical or hardware HSM (Safenet SecureKey) available?
• Will AAPM or self-registration be needed?
  The answer to this question has implications for AWS images or DevOps.  Centrify provides a Linux package (CLI toolkit); this allows for automation and automatic system registration.
• Monitoring and Reporting
  What events should be sent to log aggregation (SIEM) platforms?  What reports should be generated and who are the consumers of these reports?
• Attestation
  What is the process of validating that certain privileged users should have (or continue to have) access to certain resources?
• Session Recording
  What is the data retention policy for audited sessions?  How many concurrent sessions (SSH/RDP) can be expected?
  These topics are covered in depth in Chapter 2 of the DirectAudit Administrator's guide. 

Implementation
In this example, I will use an AWS environment with Active Directory to:

• Add a cloud connector for privilege service session management
• Manually register some EC2 Linux and Windows systems for jumpbox accesss
• Manually manage the password of a local Linux, Windows and Active Directory domain account.
• Use two AD groups:  AWS-CPS-Full Access and AWS-CPS-Read-only access. Members of the 2nd group must request access for password checkouts or proxied sessions.
• Enforce Strong Authentication.
• Using the CLI toolkit for CLI password checkouts and manual and automatic.

Moderation note:  Due to the blog's 20K character limitation, videos will be used.

Requirements for this Lab

• An AWS instance with Active Directory (managed by you or hosted by Amazon)
  • Two AD groups:  AWS-CPS-FullControl & AWS-CPS-Limited
  • A Domain Administrator to authorize the cloud connector
  • Outbound Internet connectivity via single-attached Elastic IP or Internet gateway (preferred)
• From Centrify you'll need:
  • A Centrify Privilege Service evaluation or production tenant with sysadmin-like credentials.
  • The Installation bits for Centrify DirectAudit
• A domain-joined system for:
  a) Centrify Cloud Connector (although not recommended, this can be the DC if running a simple lab).  Cloud connectors require outbound HTTPS connectivity and to act as jumpboxes for Linux and Windows systems, they should have connectivity over TCP ports 22 and 3389  (or your custom ports if changed).
  b) DirectAudit components:  this will be the not recommended all-in one scenario (Database/Collector/Agent). 
• Test Linux and Windows EC2 instances.
• Optional:  An Android/iOS mobile device for Touch/OTP MFA or a Yubikey 4 or NEO for OATH OTP

Requirements Verification

Installing a Cloud Connector

Installing DirectAudit

Configuring Roles for CPS Access


Configuring Workflow and Approvals

Using the CLI Tookit (AAPM)


Managing Active Directory Domain Account Passwords

Session Management, Proctoring, Capture and Replay

Dashboards and Reports

Advanced Controls (Policies, Authentication Profiles, Strong Authentication)


Adjustments
Some of the adjustments that can be made include:

1. Password storage:  HSM or Secure Centrify Storage
2. Different directory sources for different user populations
3. Smart Card Authentication
4. Bulk import of systems
5. CLI tookit baked into master AWS EC2 Linux instance.
6. Use of PowerShell to automatically register Windows accounts
7. Limited visibility of resources using the Privilege Portal login right.

End of Series - Conclusion
This ends the series on AWS and hopefully you've seen how the Centrify product lines:  Server Suite, Privilege Service and Identity Service work together to secure your AWS environments while balancing operational efficiency and productivity.