Introduction

This article is an attempt to provide the background information, tools and mechanisms to spot and correct Public Key Infrastructure-related issues for those who are setting-up Centrify Multi-factor Authentication or trying to enroll Identity Broker clients.

 

Background

Public Key Infrastructure is at the heart of how many Internet and corporate infrastructure services are secured today and Centrify has always provided ways to make PKI simpler for organizations.  A big example is adcert, this tool provides support for enterprise trust and auto-enrollment for Microsoft Certification Authority for UNIX, Linux and Mac. 

 

After the introduction of Identity Service and Privilege Service and the advent of high-profile data breaches and industry guidance like PCI 3.2 Data Security Standard (Requirement 8, Sections 3, 10, 11 & 12), many organizations are rushing to implement Multi-factor Authentication.   Another big milestone is the popularity of hybrid clouds;  Centrify has introduced a new capability called Identity Broker, this new Linux Agent allows organizations to "enroll" in Centrify Privilege Service and to "bridge" multi-source enterprise directories like Active Directory, LDAP, Google Directory and Centrify directory.

 

All these scenarios make use of Public Key Infrastructure to establish the assurance that clients are talking to the right entity (non-repudiation) and encryption in transit is enforced.  An important point to understand about every Centrify SaaS or on premises tenant is that it has an internal certification authority that is used for multiple uses including encryption, non-repudiation, mobile management and authentication.

 

PKI Trust and Multi-factor Authentication

With Centrify Identity Service and Privilege Service, it's possible for current users of Centrify Express or Centrify Standard Edition to implement MFA in a very quick and effective way; supporting both modern and legacy-based (RADIUS) solutions.  In the platform's 16.10 release, Centrify proactively deprecated Integrated Windows Authentication (SPNEGO) over HTTP to exclusively use HTTPS.  

Before release 16.10, Centrify announced the deprecation of IWA over HTTPBefore release 16.10, Centrify announced the deprecation of IWA over HTTP

The implication for users is that any interaction that used IWA (SPNEGO) required PKI trust in the authentication framework for MFA negotiation.

 

This means that framework after 16.10 looks like this:

mfa model.png

As you can see from the framework above, there are 3 ways you can make sure the PKI requirements are satisfied:

  • Enterprise Trust:  This is the preferred method. Ideally, an organization has a properly-implemented PKI trust capability. Unfortunately, this is relatively obscure especially in the mid-market.  A great benefit to organizations using Microsoft PKI is that Centrify DirectControl agents will take care of the enterprise trust automatically by bundling the Root and Intermediate CAs into the proper UNIX or Linux bundle.
  • Public Trust:  This was a bit expensive a while back, but the easiest way to make sure that PKI trust works out of the box is to use certificates issued by a public vendor like Verisign or GoDaddy.
  • Tenant Trust:  Each Centrify tenant will automatically create IWA certificates for all the Centrify connectors in the deployment.  This means that customers can either manually, with DevOps or with Microsoft GPOs can set up a trust chain.  This can be automated but requires a bit of work.
    The tentant will give you the option to download the IWA root certificate or the connector's host certificateThe tentant will give you the option to download the IWA root certificate or the connector's host certificate

How to determine if your UNIX/Linux system is ready for MFA

Centrify provides a tool (adcdiag) that will allow users to spot issues with the MFA configuration.   For example, in a Centrified system with an AD environment with Microsoft PKI, the root CA certificate is automatically downloaded to the /var/centrify/net/certs folder and appended to the bundle corresponding to the platform.  

Here's a sample output from a Centrified system with Enterprise Trust:

adcdiag-explained.png

This output is favorable because DirectControl (adclient) is making sure a lot of the moving parts are in place including making sure that any root or intermediate CA certificates are in the trust chain.  The reason why this "just works" is because a few seconds after joining AD, and if the system is allowed to certificate auto-enrollment, the client will make sure all the proper certs are provisioned to the system and the CA bundle is updated.  This makes this process work like plug and play. 

 

In cases when there is no trust, then the ca-bundle has to be updated with the IWA trust certificate from the tenant.  When you run the adcdiag, several checks will fail including this one:

cntrcfg.png

 If you inspect the file referenced by adcdiag, there will be the following information in this section: 

"Error setting certificate verify locations" and this will point to the CA bundle for the platform (e.g. /etc/pki/tls/certs/ca-bundle.crt).  There are several ways to solve this issue:

  • Enterprise:  Appending the root CA certificate in PEM format to the CA bundle file
  • Public:  Making sure the CA bundle is up-to date
  • Tenant:  Appending the IWA root ca in PEM format to the CA bundle file.

 

Fixing MFA CA Trust issues in UNIX/Linux platforms

You'll need to know:

  1. How to get the certificate in question
  2. The encoding of the certificate you're receiving
  3. The location of the bundle for the operating system in question
  4. For large production deployments, you'll need to use a viable distribution method

 

Scenario

adcdiag failed in a CentOS 6 system.  The issue is with the /etc/pki/tls/certs/ca-bundle.crt.  I am working with a SaaS instance of Identity Service.

Locate the IWA Cert and Determine the Encoding

  1. In Admin Portal > Settings > Network > Centrify Connectors > click the connector > IWA Service  and click "Download your IWA root CA certificate"
    iwa.png
  2. Locate the file and try to open it with a text editor.  If the text reads "--- begin certificate"  you are dealing with a usable certificate.
  3. Save the file and transfer it to your target system (e.g. IWACert.crt)

Append the certificate to the CA bundle

  1. In the target system, concatenate the contents of the certificate file to the platform CA bundle.  E.g.
    $ sudo cat /home/user/IWACert.crt >> /etc/pki/tls/certs/ca-bundle.crt
    Note:  there are OS utilities like "update-ca-trust" that perform this step the correct way.  This is for illustration only.
  2. Re-run adcdiag and verify the results.

Enterprise Environments

As you can see, the steps above won't scale in a large environment.  This is why the preferred method is to have enterprise trust in place.  Other ways to distribute certificate settings include scripts, DevOps solutions like Chef or Puppet and in Microsoft PKI scenarios, you can use Group Policy.

 

How to determine if your Windows system is ready for MFA

Windows systems may be easier to work with when it comes to Enterprise Trust but  you have to be skillful to troubleshoot as well. 

 

Windows Tools

  • Certificates MMC snap-in:  This allows you to review all certificate store.
    Note that you have to be a local administrator to view the computer certificate store and that Centrify will add certificates in the local store of systems running the Connector.
    Make sure you review the Enterprise Trust certs in that scenario.Make sure you review the Enterprise Trust certs in that scenario.
  • Certutil:  This is one of the most powerful tools around "certutil -viewstore root" will display the trusted root CAs.

 

Centrify Access Manager

This Microsoft management console provides the capability to perform an end-to-end testing in scenarios where DirectAuthorize Roles are being used for MFA.  You'll need to be at least on version 2016.
am-test.png

This option is under right-click Direct Manage Access Manager > Test Centrify Cloud Connection.

 

Centrify Logger Service

This component is installed with Centrify Server suite.  You can add it to the Centrify Agent for Windows(tm) for advanced troubleshooting capabilities.
dzwin-logger.png

 

Identifying Issues

The Centrify Agent for Windows will provide you visual feedback when there's a PKI-related issue (see below) but internally it's checking the Certificates directory under \ProgramData\Centrify\DirectAuthorize for the binary blob that represents the tenant's certificate.

dzwin-error.png

 In this case, the same solutiona applies, but in this case, we're placing the certificate in the trust store for Windows.

cert-import.png

Like we discussed before, in large Enterprises, ideally Enterprise or Public trust is set up with automation tools or Group Policy.

Microsoft provides a great article on the topic:  https://technet.microsoft.com/en-us/library/cc772491(v=ws.11).aspx

 

 Bottom-line:  When attempting to configure MFA, don't forget this checklist:

  • Is there a PKI trust between the system and the Centrify service?
  • Can the system authenticate via Kerberos?  (is it joined to the domain natively (Windows) or via Centrify (UNIX/Linux))
  • Is the machine added to a Centrify role that allows for Computer Login?
  • Are all the ports required for communication cleared  (8443 or custom)?

 

PKI Trust and Identity Broker

Identity Broker is Centrify's newest capability that allows for multi-directory authentication in private or public clouds.

IB also requires trust for operations like enrollment. 

 

Identifying issues with cdebug

Depending on the state of the Linux system (if the ca-bundle is non-existent, modified or outdated) the enrollment operation will fail.  Let's look at a failed enrollment log using two PuTTY windows.

 

Window 1:  /usr/share/centrifycc/bin/cdebug on
Window 1:  tail /var/centrify/centrifycc.log -f

Window 2: cenroll -t tenant.my.centrify.com -c [code] -F all -l Identity-Broker-Users
Window 2: Failed to initialize connection to Centrify identity platform: Failed to connect to Centrify identity platform
Window 1:
Dec 17 18:16:07 engcen6 cenroll[9201]: DEBUG <centrify/cloud.post> Failed
to post HTTP request: Post https://tenant.my.centrify.com/health/ping:
x509: certificate signed by unknown authority

 This can be further verified with the cURL command:

$ curl https://tenant.my.centrify.com
$ curl: (77) Problem with the SSL CA cert (path? access rights?)

Remediation

In this particular case, my tenant is on-premises Privilege Service, so I  can follow the instructions on this KB:

KB-7973: How to configure Linux machine trusted certificate chain to perform enrollment for Centrify...

The steps are very similar to the ones outlined above.  The strategy depends on the use case Enterprise, Public or Tenant trust is being used.

 

When trying to enroll, the output is very different:

Verbose: Platform detected: centos_6_6_standard
Verbose: Trying to connect to Centrify identity platform [https://tenant.my.centrify.com/] without a proxy...
Enrolling in Centrify identity platform https://bootcamp.my.centrify.com/ using registration code...

Starting Centrify agent...
Centrify agent started.
Verbose: Trying to connect to Centrify identity platform [https://tenant.my.centrify.com/] without a proxy...

Feature enabled: Application-to-Application Password Management
Feature enabled: Centrify Agent Authentication

Verbose: Restarting Centrify agent after enabled features...

You have successfully enrolled in Centrify identity platform: https://tenant.my.centrify.com/

You may need to restart other services that rely upon PAM and NSS or simply
reboot the computer for proper operations. Failure to do so may result in
login problems for cloud users.

 

Constant Improvement

At Centrify capabilities change to provide ease of use and supportability.  We hope this article can help you anticipate issues with your testing or setup.  Ultimately, at the enterprise level, PKI is a vital capability that has to be taken seriously and designed to balance the people-process-technology triad. 

Leveraging Centrify to provide Active Directory authentication and privelege data access roles for the IBM DB2 application, we have seen this seamless integration across the AIX landscape.  Centrify-ing your DB2 environment removes the need to provision and manage your DB2 users and their  respective DB2 groups at the OS level.  In addition, administrative efficiencies are gained by leveraging existing Active Directory user/group provisioning work flows.

 

Our Community forums are full of great articles and discussions on how to leverage Centrify Server Suite for IBM DB2 authentication and DB2 Roles for different types of entitlements to the data within.  Just in case you happen to pull this article up first, I'm going to quickly link those other DB2 forum threads for you for quick access.

 

Robertson's Discussion on Overcoming IBM DB2 Identity and Access Challenges with Centrify and AD

 

Robertson's HOWTO: Configure IBM DB2 SSO Module for Kerberos/GSSAPI SSO

 

Robertson's HOWTO: Install, configure and test the Centrify IBM DB2 SSO Module

 

Alternatively,  Felderi's Discussion on DB2 LUW Transparent LDAP; DB2AUTH=OSAUTHDB

 

Starting with DB2 v9.7FP1, IBM DB2 implemented transparent LDAP support.  In a nutshell, this allows the DB2 database manager to authenticate users defined in an LDAP directory,  removing the requirement that DB2 users and groups be defined at the operating system level. 

 

If you are a DB2 shop running DB2 on AIX, the above articles will help you integrate your AIX DB2 environment with Centrify.  If you are a Linux shop, or using a unix variant that leverages the PAM stack, you might want to bookmark this article for future use.

 

Buried in the discussions above is the key configuration parameters to leverage IBM DB2's native LDAP support.  Here is the link:

 

https://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.admin.sec.doc/doc/c0050519....

 

Additionally, your Unix server must have the CentrifyDC agent installed and joined to your Active Directory environment.  If you are running a unix variant that has configurable PAM stack, you will have to configure the db2 PAM stack to include the calls to Centrify PAM library.

 

For example, RedHat Linux DB2 PAM stack:

 

/etc/pam.d/db2

***************
# lines needed by Centrify Direct Control { CentrifyDC 5.3.0-213 }
auth sufficient pam_centrifydc.so
auth requisite pam_centrifydc.so deny
account sufficient pam_centrifydc.so
account requisite pam_centrifydc.so deny
#session required pam_centrifydc.so homedir
password sufficient pam_centrifydc.so try_first_pass
password requisite pam_centrifydc.so deny

 

# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so

 

account required pam_access.so nodefgroup accessfile=/etc/security/access.conf
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so

 

#password requisite pam_cracklib.so try_first_pass retry=3 type=
password requisite pam_cracklib.so try_first_pass retry=3 minlen=9 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=0 difok=3
#password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok remember=5
password required pam_deny.so

 

session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
***************

 

After the DB2 PAM stack has been edited, you will need to restart the DB2 service.

 

Keep in mind, USERS that need access to the DB2 data need to be Zone Enabled.  This will also allow you to migrate your DB2 shared accounts used by multiple client connections to Active Directory.

 

Finally, the unix groups that are used to setup DB2 database entitlements can now be migrated and managed through Active Directory.

 

 

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.

This is a continuation of our previous article, in which we discussed how to eliminate the poor practice of sharing the root, administrator (or any other privileged account) across UNIX, Linux and Windows platforms using Centrify Standard Edition.

 

We build on this knowledge to tackle a bigger challenge:  privileged execution of individual apps tied to session capture and replay.

 

Why implement granular Role-Based Access?

Prospects and customers come to us because of one or more of these issues:

 

In UNIX & Linux systems:

  • They use sudo, but realize that there are challenges related to the administration and reporting of privileges based on that model.
  • Privileged users end up doing this  "sudo su -" or "dzdo su -"  this makes it hard to truly detect who performed what actions in critical systems.

In Windows

  • There are poorly written but critical apps that require Administrator privileges to run, this means that a large population of users have admin rights in their PCs.
  • There are too many members in privileged groups in AD just to be able to perform simple tasks.
  • You are using Windows 2012 or Windows 8 and the "quick and easy" privileged elevation provided by Centrify's DirectAuthorize for Windows (New Desktop) is not available in these platforms.

 

Across all platforms

Organizations may have adopted a control (such as a password vault), and although now they have a better handle of who has access to a privileged account (and can approve/deny access) and the passwords are rotated, they realized that:

  • They can't pass tougher audits that require the implementation of a strict Role Based Access Control
  • Certain actions can't still be accounted for (some folks bypass the vault system and connect directly)
  • Costs for added capabilities and users are growing exponentially
  • The approvals process is too lax due to the fact that a lot of users need privileged actions as part of their job (even for simple operational tasks)
  • Due to costs, the vault system is not replicated in Dev, QA environments and production processes are not uniform across the board.

Although there's been a significant investment in the capability of log aggregation, it is very hard to be able to reproduce the actions performed by privileged users or to assess suspicious activity.

Read more...

Showing results for 
Search instead for 
Do you mean 
Labels
Leaderboard

Community Control Panel