Last week Centrify made available the mid-year release (2016.1) that comes packed with new capabilities.
Given that the PCI DSS 3.2 focuses stresses multi-factor authentication Centrify is gearing-up to help organizations that are looking to align with it this fall both with their legacy solutions (e.g. RSA SecurID) and modern methods.
Multi-factor Authentication Extended
Centrify MFA with DirectAuthorize is now extended to HP-UX, AIX and Solaris (this completes the UNIX/Linux ecosystem).
DirectAuthorize for Windows introduces MFA on Windows privilege elevation
Updated whitepaper RSA SecurID MFA integration that includes now server access and privilege elevation (instead of just PAM stacking). QA'd with RSA 7.1 on AIX (5.3, 6.1, 7.1), HP-UX 11i v2/v3, RHEL (4.8, 5.8, 6.2), SUSE 11SP2, Solaris 11 & 10. Note that this is for non-GUI login and Centrify-enhanced sudo (dzdo)
OATH OTP (e.g. Google Authenticator, Yubico Authenticator, FreeOTP, Duo, etc.) is now usable via Centrify MFA with Identity Service.
Parameter-based MFA controls for supporting Centrify Auto Zone and Classic Zones.
The adcdiag command line tool was introduced to provide pre-flight checks for MFA setup.
Enhancements to PowerShell commands for provisioning of MFA fields.
OATH OTP support opens more possibilities with Google Authenticator or YubiKey
adcdiag should provide the same value to MFA implementations as adcheck does for AD joins.
Centrify auto zone other legacy modes get multi-factor at login and can be configured via GPOs
Microsoft AD, Kerberos, Certificates and Smart Card
AD Cross-forest authentication with alternate UPN is now supported
Certificate Management and auto-enrollment now supports Elliptic Curve Algorithms.
Centrify Hierarchical Zones now support the sourcing of UNIX identity from pre-existing RFC2307 attributes. This can simplify provisioning for organizations that use those fields.
UNIX/Linux Client and Utilities Enhancements
The NIS Proxy (adnisd) now has it's own watchdog process.
Enhanced argument checking for dzdo (Centrify-enhanced sudo)
New Events documented when MFA challenges fail or succeed
Centrify-enhanced OpenSSH is now based on OpenSSH 7.2p2
OpenSSL is based on 1.0.2g
Centrify LDAP Proxy now supports TLS 1.2
libcurl is based on 7.44.0
PuTTY is upgraded to version 0.64
A new command "adcdiag" has been added to troubleshoot MFA
A new command "adobjectrefresh" has been added to only refresh specific users or groups instead of the whole cache.
Parameter and utility enhancements to support Hortonworks Hadoop Ambari 2.1.2
adobjectrefresh will be a great addition for Centrify administrators
Added Platforms
AIX 7.2
Latest version of Amazon Linux AMI (x86, x86_64)
CentOS 7.2 (x86_64)
Debian Linux 7.10, 8.3, 8.4 (x86, x86_64)
Oracle Enterprise Linux 7.2 (x86_64)
Scientific Linux 7.2 (x86_64)
openSUSE 42.1 (x86_64)
SUSE 12 SP1 (x86_64)
Scientific Linux 7.2 (x86_64)
Ubuntu 16.04 LTS (x86, x86_64)
Windows 10 (App and network rights)
Removed Platforms
Debian Linux 6
Fedora 20
HPUX 11.11, 11.23
Oracle Solaris 9
Ubuntu 14.10
OS X 10.9
Windows Client Enhancements
MFA Challenge on Applications or Desktop launches
Audit Trail Events for MFA Challenges
Mac Platform Enhancements
Simplified setup There's no need to download DirectManage components. Centrify has released a new "Mac Console" that contains the Centrify ADUC extension, GPOE and License Manager in a small (100 MB) bundle (contrast with 1.6GB for DirectManage).
If you're familiar with Identity Service and Privilege Service, they provide built-in step-up authentication like:
Centrify Mobile Authenticator
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 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 a
solution to secure servers, secure apps, provide multifactor and other
services. This promotes 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.
The opportunity
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.
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
Centrify Identity Service (or Privilege Service) Setup for Contractors
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.
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] OATH OTP Name: [type a descriptive name]; I used Google Authenticator or YubiKey OATH OTP has been enabled, now it's time to enable it for an authentication profile.
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.
Navigate to Settings > Authentication > Authentication Profiles and identify the profiles form Step 3. For each profile: 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]"
Bulk (this is for larger deployments); from Cloud Manager > Settings > Authentication > Other > OATH Tokens Use the provided Excel template to perform a bulk import of OATH tokens.
Centrify Identity Service (or Privilege Service) Setup for Smart Card Employees
Upload your PKI trust chain to your tenant using Centrify Support
Log
in to Cloud Manager and go to Policies > [policy that applies to
employees] > User Security Polcies > Login Authentication
Edit the "Other Settings" accordingly:
Press Save
Test Matrix
Contractor can self-service enroll their OATH OTP using the user portal
Access
the Centrify Identity Service (or Privilege Service portal) requires
OATH OTP, then password (to protect the user's Password).
Access a designated application (e.g. Amazon AWS) requires OATH OTP.
Testing for Employees
Authenticate using your Smart Card or YubiKey
Attempt to access Centrify Privilege Service or Identity service URL or SP-initiated connection.
Select the Certificate in the picker.
Type the PIN for your smart card or YubiKey
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.
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.
The 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.
The opportunity
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)
A domain joined member server with Centrify Server Suite 2016 (DirectControl) a
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)
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
That the user cannotsign-in to UNIX/Linux system locally or remotely (via SSH) with a password
That the user is onlyallowed 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.
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-ModuleActiveDirectoryImport-ModuleCentrify.DirectControl.PowerShell$user = Get-ADUser-IdentityMaggie.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"-Authenticationnone$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"-UnixSysRightsssologin, nondzsh, visibleAdd-CdmCommandRight-Right$cmd1–Role$roleAdd-CdmCommandRight-Right$cmd2–Role$roleAdd-CdmPamRight-Right$cmd3–Role$roleNew-CdmUserProfile-Zone$zone–User$user–login$user.SamAccountName-UseAutoUid-AutoPrivateGroup –HomeDir"%{home}/%{user}"–Gecos"%{u:displayName}"–Shell"%{shell}"New-CdmRoleAssignment-Zone$zone-Role$role-TrusteeTypeADUser-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
Name: UNIX WebAdmin - StrongAuth System Rights: - Non-password (SSO) login is allowed (checked) - Login with non-Restricted shell (checked)
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 user system path /usr/sbin no reauthentication required.
Add the rights to the role. Right click the "UNIX WebAdmin - StrongAuth" role and select "Add Right"
The role is ready to be assigned. Now press OK and right-click the Authorization > Role Assignments > Select Assign Role
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
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)
Log in to your UNIX/Linux system and use your favorite package manager to install Centrify DirectControl and Centrify-enhanced OpenSSH
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]
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.
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
In ADUC, find and double-click the test user.
Account Tab > Account Options > Check the box for "Smart Card is required for interactive logon"
Press OK. You are ready to start testing.
Test Plan:
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.
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.
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 strong 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. 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)
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
Open Active Directory Users and Computers and navigate to your desired OU
Right click and select New > User and follow the wizard until the user is created.
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.
Right click the OU and select New > Group and make it a Global/Security group. Call it "Smart Card Users"
Right click the Group, select properties, go to the Members tab, press Add and add the user created in step 2.
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
Open the Certification Authority console (Start > Search > Certification Authority) If you get an error, retarget the console to the appropriate server (e.g. DC1)
On the left pane, right click "Certificate Templates" and select Manage. This will open the Certificate Templates console.
In the template list, right-click the SmartCard User template and select "Duplicate Template"
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)
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
In
the Certification Authorities console, on the left pane, right click
"Certificate Templates" and select New > Certificate Template to
Issue
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
Log on to your member system with the test user.
Open the Yubikey PIV manager tool with the Test User (shift+right click > run as different user)
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.
Initialize the Yubikey if brand new. Do not forget the PIN.
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).
Type the PIN when challenged, and select your existing CA. In my case I use the non HTTP link.
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:
To perform the steps for the script above manually Create the Zone
Open Access Manager and right-click Zones > Create New Zone Name: Yubikey-Demo Container: Browse to your container.
Press Next and Finish
Create the Disk Management Application
Launch Disk Management (e.g. Start > Run > diskmgmt.msc)
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
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
Name: Demo Role System Rights: "Remote Login is allowed" < this will allow the user only to access via RDP
Press OK and right-click the newly created role and select "Add Right"
The role is ready to be assigned. Now press OK and right-click the Authorization > Role Assignments > Select Assign Role
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
In your domain-joined test systems, browse to the path for the Centrify Standard Edition software.
Go to Agent > and Run "Centrify Windows Agent.exe"
Follow the Wizard, you will select the "Access" components. If you have DirectAudit, also select Audit.
When the installation ends, you need to configure the client to join your desired zone.
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
In Active Directory Users and Computers, find and double-click the test user.
Account Tab > Account Options > Check the box for "Smart Card is required for interactive logon"
Press OK
You are ready to start testing.
Test Plan:
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.
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"
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.
Try to access the system via RDP with smart card PIN - expected result: Access Granted
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.
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
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:
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 SAMLIdP 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.
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, AWSSME, 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 (SafenetSecureKey) 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 jumpboxaccesss
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 CentrifyDirectAudit
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
Adjustments Some of the adjustments that can be made include:
Password storage: HSM or Secure Centrify Storage
Different directory sources for different user populations
Smart Card Authentication
Bulk import of systems
CLItookit baked into master AWSEC2 Linux instance.
Use of PowerShell to automatically register Windows accounts
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.
