Security Kaizen - Part II:  System, Roles and Groups + Anomalies

Part I | Part III

In the previous article of this series, we discussed the application of continuous improvement process (CIP) to security practices in the context of access control and privilege management.


We defined that the  goal is to implement the least access and least privilege principles across the board and that we start by collecting metrics like the number of users with system access, privileges, etc.  The idea is to Identity-Plan-Implement and Review.  For example:  If after reviewing the roles assigned to a user, we realize that this was a one-time request that was implemented permanently, we can eliminate the role assignment and have a process to review (perhaps every 30 days);  an improvement over this could be an automatic email sent to the user to extend the access instead of removing it.


We also introduced the concept of dimensions.  In the past article we focused on the user view,  in this article we discuss other dimensions.


System View

Total Centrify-managed systems vs Domain-joined systems

To identify Centrify-managed systems, first you need to identify the existing zones in your environment.

Get-CdmZone | Select Name, Domain, DistinguishedName, Schema 

Once you have identified the zones, you can enumerate the number of systems under all active zones.  An improvement point is to ask: "Why are these zones in existence if no systems are currently being managed?"

Another point of concern is if a large number of classic zones are encountered.  Centrify best practices since 2010 favor hierarchical zones over classic zones. 


The goal in this measurement is to understand which systems are under Centrify management and aren't.  For example, you can use these commandlets:

Get-CdmManagedComputer -Zone (Get-CdmZone -Name Global) | Measure
Get-ADComputer -Filter *  | Measure

to count the Centrified systems and all AD-joined systems.  This will give you a ratio of the % of systems that are managed by Centrify.  For example, in my test system I have 12 total systems with 5 managed by Centrify.


This is important because you need an alternative strategy for assessing who has access and privileges on those systems OR you can ask "Why haven't these systems been set up under Centrify management?"


Computers that grant more access and computers subject to more assignments


These metrics allow you to identify the systems that have the less stringent access controls; in addition, you can identify the systems that are subject to more role assignments.   Reviewing the data classification of the apps on these systems is advisable since the more access exists, the more possibilities of users saving privileged data.


Logins by System

This system view complements the "logins by user" metric discussed in the previous article.  This one has an interesting twist.  Note that I said I have 5 Centrified systems, however, I seem to be only getting data for 2 systems.  This is an indication that perhaps there is a misconfiguration; in my case I only have the Splunk forwarder installed in two of my demo VMs.  Note that in the case of hybrid cloud, because systems are treated as cattle, you may not notice users logging in at all.




Computers subject to more privileges


This is the privilege view of systems.  Notice that my Ubuntu system grants more privileges than the rest; if this was a PCI or SOx system, you want to dig deeper to find out why.


Privileged Access with most computers in scope


This metric allows you to identify what rights are more prevalent in the computer population.  The more common the right is, the more prevalent it will be; expect login rights (e.g. ssh, sshd or login-all) to be more prevalent.  If you see something like "run as root"  or  "Administrative Desktop" as a prevalent command, this may be part of a sysadmin role.


Privilege Activities by Type

Often you may need to look at a system and find out exactly what the privileges activities are most common.  This complements the user view (e.g. most used privileged commands)



Group and Role views

Before moving into groups and roles, let's add some context.  In Centrify DirectAuthorize, the best practice is to assign roles to AD security groups;  however AD security groups constitute what are called "Computer Roles" - these are nothing more than "Teams of Servers";  these constructs allow a system to belong to different types (e.g. a web server and a database server) which may be subject to roles assigned to different populations (e.g. web admins and DBAs respectively).


Roles with Most Access

These are the roles that have the broadest scope in a Centrify deployment.  Note that design principles suggest that Zone-level and computer-level role assignments should be used sparingly.



AD Groups with Most Members

Depending on the deployment mode of Report Services (domain or zone) you can get information about all or only the zone-relevant groups.  In this case, this graph indicates the membership numbers of groups that grant privileges in a Centrify deployment.


AD Group Attestation - Access


The picture above provides information about an AD group that is used in a Centrify deployment.  Note that it also highlights if the group has any nested groups and includes a detail of the systems it grants access to.


AD Groups with Most Privileged Access

 The common practice is to provide both access and privileges within the same group; therefore this report should be very familiar to the access report;  however there are exceptions, especially when using selective auditing.



AD Group/Role Attestation

This report shows the relationship between the AD group, the systems in scope and the rights defined in the system.


This is a great report to generate if you need to answer these questions:

  • What privileges does the "Apache Web Admin" group provides?
  • What role(s) are associated with it?
  • What is the scope of the role assignment?
  • What is the definition of the role (commands) that it provides?



Ideally anomalies are subject to security operation actions, however, as part of your overview of the access model, it's not uncommon to collect metrics of the kinds below, some of them are self-explanatory;  the others we'll provide some color.


Failed Logins by reason


Users with Multiple Login Failures


Failed Logins over Time


Any spike on failed logins could indicate attemps at lateral movement, or a service account with an outdated password.


 Denied Privileged Activities over Time


A spike on these could indicate a compromised account with attempts to perform privilege elevation.  MFA can help mitigate this risk.


Centrify Software Operations

Because a system that is not under management is easier to compromise, there are several operational activities that we should track:

Leave Activities


When a system is not in AD, you lose access control and the Centrify audit trail log.


DirectAudit Agent Service Stoppages


Privileged users can stop the session-capture client (DirectAudit), not without audit trail recording it.  Since most systems subject to this capability most likely are highly-sensitive, all anomalies should be investigated to make sure there's no collusion.



Security Kaizen - Part I

Part II | Part III

To be an effective security analyst, one must employ techniques like the continuous (or constant) improvement process (CIP);  this concept is commonly applied in manufacturing, but it has been extended to many disciplines.  The idea is to optimize the elements (people-process-technology) of a product, process or service to make it better.


In the security discipline, this requires partnership with stakeholders (infrastructure, application and business leads) to makes sure the process is not about "pointing out what's wrong" but about minimizing risk and working together to constantly align with the best security practices.  This means that your stakeholders need to be part of the optimization process.  This is not a top/down or policy-based approach;  the idea is that everyone understands the risk factors around databreaches and can volunteer information to optimize the current security posture of the organization.


In this article I discuss the metrics provided by Centrify and integrations with third parties to aid in this constant improvement process. 


We'll start with the information produced by our Centrify Server Suite (CSS).  For those who don't know, CSS provides:

  • Centralized administration for UNIX, Linux and OS X leveraging Active Directory
  • Streamlined authentication leveraging Microsoft Kerberos
  • Strong Authentication (smart card) and MFA for UNIX, Linux, OS X and Windows systems.
  • Privilege Management leveraging RBAC for UNIX, LInux, and Windows systems.
  • Session capture + replay and access/privilege tracking for UNIX, LInux, and Windows systems.


Centrify Zones - A powerful ally

Centrify Server Suite has been successful due to the introduction of Centrify Zones.  This exclusive capability is implemented as a set of AD objects that allow the following capabilities:

  • Cross-platform groupings of systems based on a governance model (zones, child-zones, computer roles)
  • Access Control enforcement (least access) - only users that are UNIX identified or authorized can access a system
  • UNIX identity management - consolidated AD and Local account (user/group) management
  • Role-based access control - enforcement of how (what protocol or method) and what (commands, apps, desktops) can be run with privilege: without exposing a password.

This means that we have in Active Directory the definitions for access and privileges, plus the corresponding clients always send the information to the correct place (event log, syslog); making CSS a rich source of information for any security professional.


The Goal:  Least Access & Least Privilege Management

Before you can embark in the journey to operational efficiency, you must understand what are the goals and establish baselines; each goal can be an independent program or project; after all, "you can't manage what you can't measure."

The universal goal of privilege identity management (PIM) is to implement least access and least privilege principles.  This means that users only can access the systems they require to perform their functions and their privileges don't exceed what's required for them to do their assigned duties.  Shared accounts or powerful roles must have limited use, only with approval in a temporary basis.

With that established we can look at access and privileges using 4 dimensions:  Users, Groups, Roles and Systems.  The reasoning behind this model is simple: in mature environments, access and privileges are not assigned to the individual, but to groups (e.g. AD security groups) and these may be applied in the context of a system. Let's review some user-based metrics that can be gathered using Centrify Report Services (a tool included with CSS Standard Edition) and our integration with Splunk.



User View Metrics


Who are the users with most access on systems?
This is a basic metric because it defines your universe.  It allows you to start a conversation about attestation and use the challenge "do you really need access to all these systems?"; another conversation starter is identifying non-IT or business users that have access to systems and why;  if the answer is "It takes too long for me to get access"  then the optimization is at the process-granting level.


Users with more access roles
This metric allows you to identify users with aggregated roles that grant access.  In organizations that have not embraced temporary access control, the reports associated with this metric allows us to identify instances of granting too many access rights.  This is also a great opportunity to identify redundancies and problems with the role/privilege design.
Example:  note the report above.  Diana is already a powerful user, but she has a role-assignment override in the Ubuntu system named engubu14.  This is unnecessary because she's already a zone-level cross-platform sysadmin.


Local UNIX Accounts Managed by Centrify


If you are leveraging Centrify Zones to manage local user accounts in your UNIX-like systems, understanding how these fit in the access model is important.  The question to be asked is how are the passwords for these local accounts being managed.  You can leverage Centrify Privilege Service or your existing SAPM solution.


Who are the users with most privileges?  Do they require those privileges?


This is another baseline metric.  Now the focus is on privileges and understanding the population of users that have privileges and its context is important.  If temporary access control is not being used, then attestation exercises should focus on why the privileges are needed.  If the answer is that "app X breaks all the time and I need to reboot from home" then target the root of the problem (the App).


Privileged vs. Access Users


Now we're using the information in Centrify Zones about access and privileges to understand the landscape and profiles of users.


Who are the most active privileged users?

This metric can be used to find out who are really using their privileges.  Watch out for users that haven't been active in a 30-day period.


How frequently are the privileged users changing their passwords?


This is a classic identity management metric.  Not only this allows to identify poor practices (like account without expiration) but also compliance to policy.   Frequent password changes (e.g. within a 2-3 minute threshold) if group policy allows, should also be subject to a security operations alarm.

The report above can be generated with this PowerShell one-liner:

Get-ADUser -Filter * -Properties passwordlastset, passwordneverexpires 
| sort-object name | select-object Name, passwordlastset,
passwordneverexpires | Export-csv -Path c:\reports\passwd.csv


User Overview - Attestation Report

Obtaining consolidated attestation reports is a challenge for all organzations.  With Server Suite report services, you can get reports that show the user's access across platforms like Windows and UNIX systems;  what granted access (role assignment) and the rights contained within those roles.


Logins by User - Organization View


Identifying our most active users (leveraging access rights) will allow us to correlate activity vs. our universe.  Make a habit of running this with a 30-day threshold to find out what users fall out of the access report - those are great candidates for temporary access.


User Overview - Most Privileged User Commands (cross-platform)



These types of reports can be generated using different criteria (time period, user, system, etc);  These could allow us to identify what are the user's biases and preferences. For example, looks like my sysadmin performs edits of files most of the time.


Making the most of your Centrify Investment

Most organizations have a journey that may or may not have been completed, perhaps it was all about authentication at one time, however Centrify has invested heavily to shift to the needs to control privileges the right way, by promoting  the least access and least privilege principles across client/server platforms.  Today we continue to innovate by providing multi-factor authentication;  as we go to hybrid clouds, you can rest assured that we'll continue to innovate and provide the valuable insight needed to make the right decisions.  In the next entry, we'll discuss the other dimensions.




ServiceNow is a very popular IT Service Management solution that includes capabilities like workflow and approvals, asset management, discovery, orchestration and more.  This is the fourth article in the series.  We have covered  ServiceNow federation using Multi-provider SSO, setting-up automatic provisioning with the Centrify Identity Service App and setting-up and configuring Centrify App Request;  in this post we'll discuss the steps to set up Centrify Privilege Access Request to leverage the Service Catalog to request login or password checkout of resource accounts in Centrify Privilege Service.


About Centrify Privilege Service (CPS)

CPS is a privileged identity management solution that focuses on shared secrets on UNIX, Linux, Windows, Network devices, AD domains, Oracle or SQL databases and more.  The approach is different than Server Suite that is focused on the principle of least privilege.  Privilege Service provides a built-in access request system with single and multi-level approvals.



Privilege Service's Workflow  vs.  ServiceNow Self-Service

We often get questions about what solution to use for self-service and approvals for application or privilege requests.  The answer is quite simple:  if you already have all your requests in ServiceNow, you should continue to do so, this helps standardization and a unified user experience.  The Centrify workflow engine is designed to meet the basic needs for Centrify products and ServiceNow is a full-fledged Service Management solution.


We'll continue to use the Plan-Do (Implement)-Check (Test)-Adjust (Enhance) methodology and assumes you have working knowledge of Identity Service and ServiceNow.


What you'll need

  • A SaaS instance of Centrify Privilege Service with UNIX, Linux, Windows or Network Devices configured.
    Note:  You can use an on-premises instance as well, provided that the network (e.g. publicly-facing) and name resolution (publicly-resolvable) aspects of the design are taken care of.
  • A ServiceNow Instance that allows you to install apps  (non-developer) with federated access to your Privilege Service instance.  For details on how to set up SAML federation with the Multi-provider SSO, click here or review the links below.
  • Administrative accounts on both systems



During planning, discuss with your infrastructure, operations and security teams about these topics:

  • Will you have a single approval or multiple approval groups per resource?
    Depending on the resource(s) in question you may have a single group or multiple groups approve.  You may also use a default approval group. 
  • How will the workflow be designed?
    This topic is very organization-dependent.  Some organizations may chose to have automatic approvals for certain systems and human approvals when the systems host sensitive data or are subject to strong security policy or regulations like SOx, PCI, HIPAA and others.
  • Have you identified a Default Approval Group in ServiceNow?
    If you chose to have a single group approve all privileged requests.
  • Have you created a CIS role and policy set for the servicenow service account?
    The servicenow account in Identity Service requires at a minimum the "Privilege Management" right, in addition, a policy that allows for username/password is required since the REST calls used by the app can't answer multi-factor authentication requests.
  • Will you have SLAs tied to your application requests?
    Although not in the scope of this post, SN offers a lot of flexibility when designing workflows including expiring worfkow requests when they are not approved within a defined duration.




  • Create an Identity Service user (the service account that SN will use to authenticate and perform actions)
  • Create an Identity Service role with the minimum rights (the role that will be assigned to the service account)
  • Create an Identity Service Policy to allow user/password login
  • Download and Install Centrify Privilege Access Request app from the ServiceNow App Store
  • Configure the Centrify Privilege Access Request app

Create a Service Account

For this integration, you'll need a service account (you should know how to create users to follow this article).  To practice least privilege, this account needs to belong to a role with the Privilege Management right.   This is to be able grant login or password checkout rights on the accounts on each system.  Centrify Directory users are created under Admin Portal > Users


When creating the user, be mindful of options that can cause an outage (like password expiration), and practice proper rotation and complexity based on your internal policy.


Create a Role with the minimum rights

To create a role, you have to go to the Admin Portal > Roles and Press Add role.  In the  members tab, add the newly-created account and in the Administrative rights tab, select the privilege management right.



Once completed, press the save button.


Create Policy to allow user/password login

This step may require you to create an Authentication profile that only asks for password (Admin Portal > Settings > Authentication > Authentication profiles).   The reason being is that Identity Service will (by default) ask for a step-up method for any unknown connections. 


  1. Log on to the Admin Portal with an administrative account
  2. Go to Policies > New Policy
  3. In Policy Settings, scroll down and select the "Specified roles" radio button
  4. Press Add and browse for the role created in the previous step.
  5. On the left pane expand User Security Policies > Login Authentication and select Yes to enable.
  6. Under default profile (used if no conditions matched) select your Auth profile that only challenges for password.
  7. Press Save
  8. In an incognito window for your browser, try to log in to the service with the newly-created account.  You should only be prompted for username and then password.


Important:  Make sure that the policy only applies to the members of the role created for this integration.


Download and Install the Privilege Access Request App from the ServiceNow Store

  1. Go to the ServiceNow app store and search for Centrify.
  2. Click on the Centrify Privileged Request App
  3. Click "Get" to make the Centrify Privileged Request app available for your ServiceNow instances.
  4. Go to the ServiceNow instance, select System Applications > Applications > Downloads to locate the app then click Install to install it.

Configure the Centrify Privileged Access Request app

There are three configuration tasks required.  Properties, API Sync and Accounts.  The third category is only needed if you are using individual groups as approvers for each resource's account.
  1. In the application pane (left) navigate to Centrify Privilege Request > Properties.  Populate these three fields
    Centrify Cloud Tenant URL:  the URL for your identity service tenant.  (e.g.
    Centrify Cloud Service Account: the account you created in previous steps
    Centrify Cloud Service Account Password:  the strong password you created for the user
  2. Default Approval Group (Optional):  now you have a decision to make based on the planning above.  Populate the "Default Approval Group" if you decided to use a single ServiceNow group to approve all privilege requests.  You have to find the group in ServiceNow (System Security > Groups; find the group, right-click it and "Copy sys_id" and paste it on the Default Approval Group.  If you are planning to have approval groups per App, then you leave the field empty and press Save.

API Sync

  1. Go to Centrify Privilege Request > Customize API Sync
  2. Set the Active checkbox
  3. Select an appropriate interval based on your SLAs (e.g. 1 hour)
  4. Press Save and then Execute Now.
    This process will synchronize the Resources (systems) and accounts available in Privilege Service

If you set up a "Default Approval Group" you can skip this part.  At this point you have to have a list of all the apps and the corresponding approval groups.  For example, the root account in the CentOS system called engcen7 will be approved by the Team Development Code Reviewers group included with the sample data of the ServiceNow instance and the canned workflow for software.



To verify the functionality of the app, you'll have to run through the workflow of the apps (or independent apps) based on the approval group defined.  For example, in my scenario I chose to have independent approval groups.  My requester wants to checkout the "api-key" resource under the azure-rh1 resource and the self-service request is automatically approved based on existing ServiceNow rules.



Once the request is approved the app will provide the requester access to the type of request (login for SSH or RDP access) or checkout (for password reveal or clipboard copy).  In order to get access to the system or retrieve the password, the requester must switch over to privilege manager and find the system in the resources list or in their favorites.  For login they can use the PuTTY or web client and to check-out the password, they can use the system resource on privilege manager or the mobile app.


Documented Approvals

Security analysts and auditors may require reports of who has been requesting and approving apps, this is easily accessible using the service catalog requests or under the Centrify Privilege Request Access approvals or the Dashboard section.




Since this app focuses on ServiceNow approvals, the enhancements are around workflow design.  For example, you can have multi-approval groups, you can set timers for SLAs, etc.   However, there are other things that you can customize including the Dashboards and the appearance and location of the Centrify items in the Service Catalog.


Centrify & ServiceNow Resources

There are multiple resources available in the documentation and tech blogs:


We've had requests from many customers to document how Centrify can protect RDWeb access with MFA or two-factor authentication. It turns out it's a simple WS-Federation with Centirfy Identity Service, where you enable MFA for your users.


Please continue reading for instructions on how to set it up.


This article will show you how to deny or allow access to a web application, when certain conditions are met. The conditions include:

1. Log into the Centrify Admin Portal.

2. Edit your web application and select Policy from the left column.


Policy left.png 


3. In the right pane, click on the Add Rule button. A new window will appear.


add rule button.png


   a) Click on the Add Rule button.


add rule too.png


   b) Select the desired filter and condition


condition list.png 


   c) Click on the Add button.


selected condition.png


   d) Choose an Authentication Profile to allow, deny or require multi-factor authentication. Click OK.


selected condition action.png


4. Select a Default Profile to allow, deny or require multi-factor authentication. Click Save.

 default condition profile.png


If you want to restrict web application access to only devices that has been enrolled into Centrify's MDM:

See instructions.




This article will show you how to only allow access to a web application from a device that has been enrolled into Centrify's MDM. Please note these instructions may change in the future.


Enroll your device into Centrify MDM


Configure your web application

1. Log into the Centrify Admin Portal.

2. Edit your web application and select Policy from the left column.


Restrict to managed devices.png


3. In the right pane, select the checkbox to "Use script to specify login authentication rules (configured rules are ignored)"then click on the Load Sample button. A new window will appear.


use script policy.png


4. Select the option "require strong auth for unmanaged devices.js"then click on the Load button.


script sample.png


5. In the policy script, change the value for policy.RequiredLevel  to 0. This will deny access from devices that are not managed by Centrify.


 edit policy script.png


6. Select a Default Profile to Always Allow or a predefined authentication profile to perform multi-factor authentication to access the web application. This determins if the user is logging in from a managed device. Press Save when your configuration is complete.


default profile.png


To restrict web application access based on time, location, or other device conditions:

See instructions.

Using local MacOS administrator accounts can lead to security and compliance issues such as unauthorized sharing of the administrator password with non-administrators or remote access by a former employee. The secure approach is to grant Active Directory users Mac administrator rights to minimize risk and meet regulatory compliance. This article will show you how to grant Mac administrator rights to Active Directory users through Centrify's Active Directory group policy settings.


 1. In Group Policy Management, create a GPO and enable: Computer Settings > Policies > Centrify Settings > Mac OS X Settings > Accounts > Map zone groups to local admin group




   a) Click on the Add... button. A new window will appear.




   b) Click on the Browse button. A new window will appear. You can enter manually enter a group name in this window but it is better to browse and select the group to ensure the proper group name is entered.



Selecting Group.png


   c) Enter a keyword into the Name field for the Active Directory group that you want to add, then click on Find Now. Make sure you add IT/helpdesk team and any user that needs admin rights on the Mac.


type group name.png


   d) Select the desired group name and click OK.


Select desired group.png


The setting will apply when the user logs out and logs back in.


If your Mac is using Zone mode, use the following article:



Testing and Troubleshooting Centrify's DB2 plugin

By Centrify Contributor I 2 weeks ago - last edited 2 weeks ago

In part 1 of this series, we described how to configure DB2 Express-C on Linux and how to configure the Centrify DB2 Plugin.  In this article we will focus on testing the installation and an example of how to troubleshoot if things aren't working as expected.



Prevent unauthorized access and minimize risk by restricting MacOS login access to specific Active Directory users or groups. 


[MAC] Then comes marriage / divorce, then comes name change

By Centrify Advisor I on ‎01-20-2017 04:24 PM - last edited 2 weeks ago

How to retaining the user's Mac home directory, when a user wants to change their name after marriage or divorce.


[How To] Basic Windows MFA with Centrify Identity Service Guide

By Centrify Contributor II on ‎01-20-2017 09:09 AM - last edited a month ago By Community Manager Community Manager

Thank you for choosing Centrify!


Centrify would like to share another feature: multi-factor authentication on Windows workstation login. With the Centrify Identity Service solution, you can enforce multi-factor authentication to users attempting to access Windows workstations, with 2-factor options such as telephone call, email and Centrify's mobile authenticator (TOTP) utility. The solution works in both an online and offline mode, so workstations disconnected from the internet are also able to authenticate with multi-factor authentication to their machine. 


This guide is a basic demonstration of how to setup multi-factor authentication for the following use cases. 


   - MFA at interative login

   - MFA on RDP access

   - MFA on screen saver unlock

   - MFA in offline mode


Configuration time ~ 1 hour



1) Centrify Identity Service license

2) Domain joined Windows machine


Lets get started!


1) Logged in as administrator to your Centrify Identity Service console, start by creating a Centrify role. This role will contain the Windows workstations you want to enforce multi-factor authentication on.


1 - create centrify role.png


2) Add the workstations you want to enforce multi-factor authentication on by searching for the resource and clicking 'Add'. 


2 - adding desktop.png


3) Under 'Administrative Rights', assign the Centrify role the "Computer Login and Privilege Elevation" right. This allows the service to deliver a multi-factor authentication profile (created in the next step), to the workstations you've added to the role.  


3 - administrative right.png


4) Next, create an 'Authentication Profiles' that contains the available factors that are appropriate for users to authenticate with. 


3.1 - authentication profile.png


5) Assign the 'Authentication Profile' to the 'Login Authentication Profile' and 'Privilege Elevation Authentication Profile' fields. 



3.1 - authentication enforcement.png


6) Next, download the Centrify agent from the 'Downloads' dropdown within the Centrify Administrator's portal. 


4 - downloads.png


7) Download the 'Centrify Agent for Windows' .msi file. 


5 - download agent.png


8) Install the Centrify agent on each workstation you would like to enforce multi-factor authentication on. Note: The workstation must exist within a Centrify role for the Centrify Identity Service solution to deliver the multi-factor authentication profile to the machine (refer to step 2). 


6 - install 1.png


9) Review and accept the Centrify End-User License Agreement.


7 - install 2 eula.png


10) The Centrify agent can be enabled with 'Audit'; a feature that allows for recording of sessions for future playback. If you have purchased the audit feature, you can enable this feature in addition to the default 'Access' option. If you do not have the audit feature, keep the default settings and click 'Next'. 


8 - install 3.png


11) Once the installation is completed in step 10, click 'Next' to continue setup of the agent on the workstation/server. 


9 - install 4.png


12) The following step is applicable if you are using Centrify Server Suite, designed for securing privileges and requiring multi-factor authentication at server logins or privilege elevation. If you are a Server Suite user, the following post will guide you through configurations at this step


For purposes of this guide, keep the default settings by leaving the 'Join to a Zone' unchecked and click 'Next' to continue.  


10 - install 5.png


13) Ensure that the 'Enable multi-factor authentication on Windows login' is selected. You also have the option of enforcing multi-factor authentication for all active directory users or selectd active directory users logging into the machine. Click 'Next' to continue. 


11 - install 6.png


14) Click 'Finish' to complete the installation and setup. 


12 - install 7.png


15) A restart is required to complete installation and setup of the service. 


13 - install 8.png


16) Upon restart, login to the workstation. During login, you will now see a drop down with the multi-factor authentication options required for login. Login to the machine with one of the factors. 


Note: The user must have the available attributes in their user profile for the option to be available to them during login. For example, if a user does not have a telephone number in their active directory profile, and the telephone number is selected as one of the available factors, the telephone option will not be displayed to the user in the drop down. 


14 - login MFA.png


17) After logging into the workstation, 'Setup Centrify Offline Passcode' will display. This allows a user to successfully authenticate, with multi-factor authentication, to the workstation when the machine is offline. Click on the 'Click here to create your offline passcode'. 



15 - offline mode.png


18) Click 'Next' to setup offline mode. 


16 - offline mode setup.png


19) The Centrify mobile application can be leveraged for the creation of a passcode for offline mode. More generally, you can use utilities that supports OATH to also setup your passcode using existing utilities of preference in your organization. Examples of such utilities are the Centrify mobile app and Google Authenticator. 


17 - offline code setup.png


20) Click 'Finish' to complete the offline passcode setup. 


18 - offline code finish.png


21) Test the offline mode by taking the workstation offline and using the offline passcode to log back into the machine. 


19 - offline mode login.png


The following guide is intended to demonstrate the steps required for enforcing multi-factor authentication on Windows workstations using the Centrify Identity Service solution. Centrify strongly encourages deployment and administrative guides along with testing the solution prior to enterprise deployments.


We hope this guide was helpful and welcome questions you may have in this thread. 




Validating Centrify Zone Delegations

By Centrify Contributor II on ‎01-06-2017 07:06 AM

One of the major strengths of Centrify Server Suite, is that all UNIX identity and authorization data is stored as Active Directory objects in Centrify Zones. As a consequence, delegation tasks of zone management, are stored in Discretionary Access Control Lists (DACLs) on Centrify Zone objects in Active Directory.


The Zone delegations can be implemented using PowerShell (for example, using the Set-CdmDelegation PowerShell CMDlet, which is included with the Centrify.DirectControl.PowerShell module), or by using the 'Delegate Zone Control' context menu option in the Centrify DirectManage Access Manager console. Either method will provide you with the ability to chose from a list of a granular zone delegation tasks, that can be delegated to an Active Directory user or security group.



List of zone delegations in Access ManagerList of zone delegations in Access Manager

Applying zone delegations using the Centrify PowerShell CMDletApplying zone delegations using the Centrify PowerShell CMDlet 

As part of an engagement, Centrify Professional Services can aid you to conceive a delegation model using a RACI matrix, and implement the resultant zone delegations. This allows for implementing least privilege, where (for example) the service account for the zone provisioning agent can only add/remove UNIX profiles to/from a zone, but nothing more than that. If the ZPA service account gets compromised, it cannot be (ab)used to modify UNIX authorizations.


A returning question from customers during these engagements is: How can we validate that the delegations that have been implemented, are actually in place?




This article details the methods available to implement zone delegations, and how zone delegations can be validated.


Customer are seeing great value from Centrify's Server Suite DirectAudit's session capture and replay capabilities.  We hear the benefits from customers all the time.  Examples of how DirectAudit allowed them to quickly uncover what malicious users did or mistakes honest users made that caused systems and applications to go down.  Like in the human world, having a security camera at the system level, with the ability to search and replay is the best way to determine what is happening or has occurred.  


The Problem:


Customers who implement DirectAudit should implement a rentention policy and purge audited sessions after a period of time.  Doing so allows the Audit Store(s) to remain small which delivers better performance.  Their are multiple ways to implement a data retention policy for DirectAudit, including rotating databases every so often as described on page 9 of the Database Management guide.  Another option not as well know, and the focus of this article, is that data can be purged after a certain amount of time.  For example, delete sessions older than 90 days.  


The Solution:


Centrify provides a tool called PurgeSessions documented in Knowledge Base article KB-3394.  PurgeSessions can be scheduled to run using the Windows scheduler every 2 weeks to delete sessions older than the retention policy.  


This article will help you configure single sign-on from Centrify Identity Service to Splunk Cloud.


Want to configure wireless settings for your users without having to manually touch each device? With the Centrify Identity Service, WiFi settings can be pushed to Mac, iOS, and Android mobile devices using policy.


Além de capturar os dados de sessões com o DirectAudit, muitas empresas necessitam que os meta-dados das sessões sejam enviados a uma base de dados centralizada para que os eventos possam ser correlacionados com outras fontes de dados como aplicações, sistemas operacionais, bases de dados, etc., para que por exemplo, possa se ter o rapidamente a informação que determinada aplicação parou de funcionar exatamente quando um usuário executou uma ação específica numa sessão auditada pelo Centrify.


With the release of Centrify Server Suite 2016 came a new feature for providing zone-based provisioning of local users and groups on UNIX and Linux. Prior to this release, the automatic provisioning of local service accounts and their associated groups was a manual process, usually outside of the scope of Centrify deployments.


This article describes an approach to integrating Centrify Server Suite for UNIX with a third-party MFA solution. We'll focus on PingID MFA from Ping Identity as our example. This approach is unique in that it does not rely on Centrify Identity Service as the third-party MFA integration point. Rather  the target UNIX operating system serves as the integration point. The integration is enabled through a combination of the Centrify Server Suite Unix agent the PingID MFA Unix PAM library. The key points this article conveys are:

  1. The recommended approach  to implement a third-party MFA with Centrify Server Suite is through Centrify Identity Service. Whenever a CSS MFA policy is triggered, CSS UNIX agent calls into CIS which in turn brokers the request to the third-party MFA;
  2. For customers that don’t want to implement CIS to enable third-party MFA for their Unix systems, it is technically possible to configure a third-party MFA PAM module with the CSS UNIX agent without relying on Centrify Identity Service. However, there are several technical dependencies need to consider. Section 4 addresses some of the risks and issues with this approach.

Quick Mac Troubleshooting Tip/Tool

By Centrify Contributor III on ‎12-23-2016 12:23 PM

A Little Mac Testing Help


When I am testing new group policy configurations for the Mac, I like to have the Centrify Mac Diagnostic tool at the ready. Here are the steps that I use to put the Diagnostic tool on the Dock. The MacDiagnosticTool allows the tester to quickly see via a graphical interface the following:


  • AD Connectivity and Network Information for the Machine
  • Group Policy Settings that are being applied to the machine
  • User Information such as their UID, AD Group Membership etc.
  • Centrify Debug Information
  • And contact information for Centrify Support.





This is an end-to-end guide for integrating Yubikeys with the Centrify Identity Service platform using the OATH-HOT.


HOTP works just like TOTP, except that an authentication counter is used instead of a timestamp. The advantage of this is that HOTP devices requires no clock.


The attached script can be used with the Deployment Manager to unbind a Mac that is bound to Active Directory via the Apple Directory Services plugin. This will allow mass deployments of the Centrify agent with binding to Active Directory using the Centrify Directory Services plugin.


Here is a quick primer on the security risks associated stale Window Service Account Passwords and how Centrify’s new "multiplex account” feature helps…  Towards the end is an embedded YouTube video demo showing the feature in action. 







By Centrify on ‎12-21-2016 05:20 AM

Step-By-Step guide with screen shots that will help you achieve SAML2.0 SSO into SAP java.


How to Demo Centrify and ServiceNow integration.

By Centrify on ‎12-20-2016 12:56 PM - last edited ‎01-03-2017 01:07 PM

Service Now :  Use Cases with Centrify integration

Currently we have the following modules integrated into Service Now


  1. Application Access request  
  2. Privilege access 
    1. login
    2. checkout





This article is a multipart series. The first part explains what MFA is and the benefits of implementing MFA, especially with a service like Centrify Identity Service. Follow on articles will go through the process of setting up MFA through the Centrify Identity Service.


Customers with NetApp ONTAP filers are looking to provide consistent level of access across multi-protocol CIFS and NFS shares.  To do this, the filers need to obtain Active Directory users and the UNIX identity of those users to provide the unified level of access required.  Customers with Centrify deployed can very easily accomplish this.  The following guide will show you how to integrate NetApp onTap filers with Centrify.  



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.



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:


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:


 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



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

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.


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.


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


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:


 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 -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/> Failed
to post HTTP request: Post
x509: certificate signed by unknown authority

 This can be further verified with the cURL command:

$ curl
$ curl: (77) Problem with the SSL CA cert (path? access rights?)


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 [] without a proxy...
Enrolling in Centrify identity platform using registration code...

Starting Centrify agent...
Centrify agent started.
Verbose: Trying to connect to Centrify identity platform [] 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:

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. 

If you're an existing Centrify customer, you may have seen recent news about the capability to support Multifactor Authentication at Windows Login. This article explains how to set this feature up in your Centrify Server Suite and Centrify Identity Service environment. 


Showing results for 
Search instead for 
Do you mean 

Community Control Panel