Protecting Azure Infrastructure

In this series we discuss how the Centrify platform can secure infrastructure running in Microsoft Azure. For those who are not familiar with Centrify, here’s an overview of the Centrify Platform and capabilities:


In this first part, we’ll focus on securing access to the Azure Portal using Identity Service. 

There are two strategies that can be used:

  • Protecting shared credentials (like the original o365 or Azure subscription account)
  • Federated SSO and just-in-time provisioning (no need to deploy an ADFS infrastructure)

Both strategies can be enhanced with:

  • Workflow and Approvals
  • Policy and Multi-factor authentication (including risk-based)


Protecting Azure Portal Shared Credentials

Shared Credentials in Azure may be sourced from different directories, but the most common use case is the subscription account.  This is typically the e-mail address of the user started the account.  This account has all the access (typically a Subscription Manager).  If your organization is already using Office365, then this is the “” account. 

In this cases, you can use the Password Wallet capabilities of Identity Service to provide fast deployment, least access management, policy controls, strong authentication, accountability and documented approvals.  Here the features that enable all these benefits:


  1. Turnkey App template
  2. Role-based Access Control (leveraging Identity Service roles and Active Directory groups)
  3. Account Mapping flexibility
  4. Policy Engine and Multi-factor Authentication
    Centrify also provides Risk-based Access Control.
  5. Workflow and Approvals (Natively or via ServiceNow™)
    Centrify can do native or ServiceNow™ approvals.  For more informationa about ServiceNow integrations, visit the ServiceNow TechCenter.


Providing Federated Access and Just-in-time Provisioning for  Azure

Just like any other SaaS application, Azure provides federated access.  In this particular case, the same functionality used for Office365 federation, provisioning and license management.  The benefits of leveraging Identity Service is that there's no need for the additional complexities and overhead of native solutions like ADFS, plus, there's added capability like we've seen above.



Benefits of using Federation and Provisioning in Azure

Users come from AD as the identity source.  This means that any add/moves or changes will reflect in the user's ability to access the service or any entitlements.

AD Security groups provide 2 great benefits around entitlements and provisioning:

  • This is because direct assignment paths are not the recommended practice.
  • You can allow the provisioning of access and roles from a single AD group membership.  



Just-in-time Provisioning

Traditionally, Microsoft has positioned DirSync as the tool for O365 provisioning; along with ADFS these are mature and effective solutions, however, they promote fragmentation.  With Centrify, both federation, policy, workflow and provisioning settings can be managed with a single administrative experience.


License Management

This is another component of O365 and Azure.  Centrify allows the centralization of these efforts and the allocation based on different provisioning rules.


For more information about how to leverage Identity Service for Azure or O365 federation, provisioning or license management, visit the O365 TechCenter.



Centrify provides several dimensions to measure application access or to determine assigned or provisioned apps.

This allows security operations to obtain timely information about events, plus the ability to attest application assignment or provisioning.







Centrify Identity Service will allow you to meet or exceed the controls required to secure Azure portal access and to provide granular access werther you are leveraging the Azure's cloud directory or are federating with your existing on-premises Active Directory.


5-Minute Video


Resources and Related Links

This week we've made available our new version of Centrify Server Suite 2017 and like any new release it's packed with new capabilities, features and bug fixes.  This post will allow you to explore what's new in this release and what are the some key planning considerations for successful deployment.


What's new on Server Suite 2017


  • Kerberos Library Upgrade: In this release, Kerberos libraries have been upgraded to MIT  5-1.14.1.
  • Flexible Authentication Secure Tunneling (FAST):  Also known as Kerberos armoring, secures pre-authentication traffic and protects KDCs from error spoofing.
  • This upgrade allows support for Smart Cards using AES-256 encryption.  Centrify has tested with Oberthur ID One 128 v5.5 Dual SHA256 and G&D FIPS 201 SCE 3.2 SHA256 Cards.

Flexible open-source packaging

  • cdc-dep.pngCentrify DirectControl has leveraged OSS packages (OpenLDAP, cURL and OpenSSL); in versions prior to 2017 updating these packages required a re-spin of the whole suite (in all supported platforms)
  • Starting with CSS 2017 (DirectControl 5.4) the packages for cURL, OpenSSL and OpenLDAP are independent and can be separately updated, this will allow for faster response to any CVEs that apply to those components.


  • Implemented transaction control for LRPC2, this provides security improvements over heavy load.  Requires that both DirectControl and DirectAudit are upgraded.
  • MFA: Since Centrify Identity Service version 16.10 the IWA negotiations happen over SSL. This means that either Enterprise CA, Public CA or IWA root certificate trust must be established for Centrify Multi-factor Authentication to be successful.

Centrify Report Services

  • New Operation Mode (zone mode):  The first release of report services works in "domain mode" this means that the "Replicating Directory Changes" delegation was required.  Now in this mode, only delegations at the zones container is needed, keeping the scope of the information sent to report services only to Centrify data.
    reports - modes.png
  • Report options:  include the ability not to generate charts as well as reports for local users.

Centrify-enhanced OpenSSH

  • SSHv1 is no longer supported.
  • AIX:  The LAM version of Centrify-enhanced OpenSSH is no longer shipped.  This is because supported versions of AIX ship with PAM enabled.

Introducing Centrify Licensing Service

  • Customers are asking to provide more efficient and proactive licence capacity and usage and many are asking for elastic licensing to support public cloud workloads.
  • Centrify Licensing Service (v1) targets perpetual licensing and provides mechanisms for streamlined capacity, inventory and notification.
    cls - main.png
  • CLS requires a highly-available Windows server that runs the licensing service (this does not have to be a dedicated server)

LDAP Proxy performance enhancements

  • The LDAP Proxy now implements new caching mechanisms (at the server auth and client) that can result in performance increases.

Centrify Agent for Windows

  • MFA:  Supported at login (console, RDP, screensaver unlock) in two modes:  zone mode and zoneless mode.  Zoneless mode requires a Centrify Identity Service device license.
  • Support for both MFA at login and with privilege elevation (desktop, applications) is exclusive to zone mode (requires Standard Edition license)
    mfa -zoned.png
  • Just like UNIX/Linux MFA, requires IWA over SSL, this means that Enterprise, Public or IWA root cert trust must be planned and implemented.
  • Application Manager:  This application can be assigned to a role to allow Add/remove of Windows programs
  • Feature Manager:  This application can be assigned to a role to allow for Windows feature management

DirectAudit Enhancements

  • Compiled with libaudit support (system call monitoring at the Kernel level) on RHEL and derivatives (more platforms coming in the next releases)
  • DirectAudit is now able to monitor file changes on /etc/, /var/centrifydc and /var/centrifyda
  • DirectAudit is now able to audit commands run inside scripts
  • DirectAudit is now able to monitor for specific command executions.


Platform Support

Platforms Added

  • Amazon Linux AMI
  • CentOS 6.8 (x86, x86_64)
  • CentOS 7.3 (x86_64)
  • Debian Linux 7.1, 8.5-8.7 (x86, x86_64)
  • Fedora 24, 25 (x86, x86_64)
  • Mac 10.12 (x86_64)
  • Oracle Linux 6.8 (x86, x86_64)
  • Oracle Linux 7.3 (x86_64)
  • Red Hat Enterprise Linux 6.8 (x86, x86_64)
  • Red Hat Enterprise Linux 7.1, 7.2, 7.3 (ppc64le)
  • Red Hat Enterprise Linux 7.2 (zLinux) on Standard Edition
  • Red Hat Enterprise Linux 7.3 (x86_64)
  • Red Hat Enterprise Linux 7.3 (ppc64)
  • SUSE 12 (ppc64le)
  • Ubuntu 16.10 (x86, x86_64)

 Platforms Removed

  • Fedora 21
  • Mac 10.9
  • OpenSUSE 13.1
  • SUSE Linux Enterprise 10.x
  • Ubuntu 15.04, 15.10

Component Version Upgrades

  • Centrify-enhanced OpenSSH is now based on OpenSSH 7.3p1
  • Centrify-enhanced sudo (dzdo) is now based on sudo 1.8.17p1
  • Centrify-curl is based on libcurl version  7.51.0
  • Centrify-openssl is upgraded to version  1.0.2j
  • Centrify PuTTY is upgraded to version  0.67


Planning tips for Server Suite 2017

  1. As recommended, read the release notes and upgrade guide.
  2. Even if you don't plan to update your clients right away, you can upgrade your consoles and group policy templates. 
  3. This is a major release and all components must be upgraded: DirectControl, DirectAudit (agents/collectors/database), this is because:
    • Kerberos upgrade
    • New LRPC2 transaction protocol
    • New Open-source packaging
    • OpenSSL upgrade
  4. Plan for Centrify Licensing Service - have the service installed on one or two highly-available windows servers.  Have your technical and procurement leads in the notification lists and designate a thresold to get proactively sent deployment reports.
  5. Due to the new DirectControl packaging, plan to update your DevOps recipes/cookbooks (Chef, Puppet, Ansible, etc)
    Tip:  adjoin has a new option “-F/--forceDeleteObj” to clean up the existing computer object and extension object in Active Directory before performing the adjoin operation.
  6. If you're using Centrify-enhanced OpenSSH on AIX platforms, plan phase out unsupported versions or to migrate and test existing PAM support; this is because we no longer ship a LAM version.
  7. SmartCard: RC4 and DES are no longer supported;  this means you have to plan to upgrade to AES-128 or AES-256 to ensure compatibility.
  8. Leverage the Centrify Repo for quick updates on RPM, APT or Zypper-compatible distributions.
  9. The new capabilities of DirectAudit (config file monitoring, monitored execution, etc) are not turned on by default.  You have to turn on the event.execution.monitor and event.monitor.commands parameters in the /etc/centrifyda/centrifyda.conf file.  Make sure you do a baseline analysis first.
  10. Hybrid-cloud support:  remember that you can use Server Suite in your AWS, Azure or GCP deployments and that Centrify provides unique support for complex AD scenarior like one-way trusts, RODC and now Kerberos Armoring.


Conclusion - It's all about value

  • With each release of Server Suite, Centrify adds more new capabilities that ensure alighment with security practices and regulations and operational efficiency.
  • You have to learn to spot issues with your current deployment like:
    • Challenging management due to a large number of zones:   this may mean that your implementation is following outdated practices.  Back in 2010 Centrify introduced Hierarchical zones, this allows for better administration, privilege management and a reduced number of zones.
    • Not leveraging privilege management:  Authentication was the problem 10 years ago. Now you're faced with multi-platform attestation, conformance with MFA requirements, etc.  These are all parts of the product that you own.
    • Not getting the proper "insight":  Centrify Report Services and the integrations with Splunk, ARCSight and QRadar are the best ways to understand what's happenning in your Centrify deployment today.
      Check out this article series to see the insights you should be getting:
    • Cognitive gaps:  If you or your team feel that have inherited a Centrify deployment and don't have the proper training, let your reps know and they'll take care of that.
  • For an article discussing what do if you inherited a Centrify infrastructure, go here:

Expect some in-depth articles on some of the newest features of this release.



For customers that already use Symantec VIP for MFA and want to layer on the Symantec VIP MFA solution to the features that Centrify Server Suite provides, you can use this guide to add Symantec VIP MFA through PAM chaining. This allows you to leverage your existing investment in Symantec VIP until a time when you are ready to explore Centrify's fully integrated MFA Everywhere capability. 


Security Kaizen - Part III: Web Apps, Mobile/Mac and MFA

Part I | Part II | Part III | Part IV

In the first two articles of this series we have discussed some metrics that can help security analysts in the evaluation of their access and privilege management models in a Centrify deployment using Server Suite.


The whole premise is to treat the process of limiting access/privileges as a subject of a continuous improvement cycle where we apply root-cause analysis and implement improvements to the security posture of the organization. 


In this third iterationid-service.PNG we're going to shift gears to other areas of the Centrify world and we'll focus on web applications.  In this entry we'll focus on Centrify Identity Service.  CIS  is a best-of-breed Identity as a Service solution that provides simple federated SSO, self-service, mobile device/application/container management and much more. What you'll see below is included with the product in the form of reports and dashboards;  in addition to these capabilities, we have released an analytics engine that is a companion to CIS.  Read all about it here.


With CIS, we're going to discuss these dimensions:  Apps, Users (including admin users), Roles, MFA and Mobile.


Application Dimension

When dealing with Applications, one of the most common goals in the context of access management is to consolidate application authentication patterns.  The principle is to move away from local user/password repositories because this is one less point of risk and compliance enforcement.  For each user/password app, security analysts must worry about alignment with policy, roles/rights, mitigation for advanced threats, attestation, etc.  

If an application is using a modern approach (like federation) is easier to provide the assurance of compliance and this also makes the application much more portable.


Total Deployed Apps

The first place to start is to identify your application real-estate.  Understanding how many applications are deployed in your environment is the first place.

select count (*) from application; 

Apps not in use

Another great piece of information is to find out what applications are not in use.  If an app is published and has no audience, perhaps this needs to be reconsidered.  This can be found under Reports > Applications > Unused Web Apps

usused apps.png 

% of Apps using Federation

As stated above, the goal is to eliminate user/password applications.  You can create a ratio of total apps that support federation / total apps; this will give you a good target percentage; since some apps are kept due to legacy and political reasons, each app move to modern patters may be a project or a program in itself.

As an example, you can modify one of the built-in reports to obtain the SAML-capable apps from the existing installation:

select ID AS _ID, DisplayName, WebAppType, Category, Description 
from Application
where WebAppType='Saml'
order by AppTypeDisplayName, Category, DisplayName


Unique application launches and App launch events


Although these are operational metrics, they are correlated with user activity and roles (see below);  For example in the pics above I've drilled on App launches related to the Amazon root account and the IAM federated app.  This is because those apps are use by very high-privileged users.


Most Commonly Used Apps

This can be generated as a report;  commonly used apps may indicate heavy line-of-business apps and is an indicator of potentially-sensitive information.

Look at the Top apps in this example:  Salesforce (sales/customer data); Office 365 (all kinds of data), Workday (employee data).


There are multiple areas to focus on apps (including mobile) but let's focus on the CIS user view.


User Dimension

Users in Identity Service can have assigned applications, provisioned applications and roles.  Roles may be used for application access (RBAC) and for privileges in the platform.   


Assigned Apps (user)


The goal continues to be the least access principle and we want to make sure that users only have access to the apps that they need. 


Provisioned Apps (user)


Provisioned apps allow for just-in-time provisioning (or de-provisioning) of users and if supported, role assignments.

Notice how you can also identify anomalies.


Roles Assigned (and Entitlements)


Note how a role also provides the user with privileges in the platform.


User Logins vs. User Failed Logins



It's always important to review this type of activity, however Identity Service provides an additional dimension - geo-location;  this provides better intelligence for security operation decision.


Any failure attempts in geographies that the enterprise does not have a presence should be flagged or subject to additional scrutiny.


Administrative User


Application Changes

Administrative users may change apps, roles and settings in the overall platform.  Typically, when apps are being deployed, there are many changes being logged, but once an application is stable, it should be "locked"  and the changes should only be under approval by change control committee unless there's emergency changes needed.


app changes.png


Role Changes

Activities in this area depend on the RBAC model implemented.  If administrators make membership changes directly on the Identity Service roles, then activity will reflect natural business operations;however, if using the target groups (e.g. AD security groups), then the changes to roles should be minimal.



Challenges and  Multi-factor Authentication


MFA is a key part of Identity service and the metrics around this capability can be very useful to understand user behavior and potential threats.  Identity Service supports different types of authentication profiles that may include Smart Card/YubiKey/OATH as MFA methods and SMS, phone factor, and e-mail as step-up methods; it can also support RADIUS challenges to accommodate for legacy tokens like RSA SecurID, Vasco or Symantec.


Successful and Failed Challenges


A challenge happens when MfA is invoked, therefore a failed challenge is a causal factor behind failed logins.


Challenges and Authentication Events


Pay special attention to failed challenges;  these are instances in which an MFA  (or step-up) mechanism has been invoked but it hasn't been satisfied.  Repeated attempts are subject to security alarms.


Authentication Events - Pattern


Authentication patterns are relatively predictable in some organizations (this depends on their timezone footprint), this means that you should understand a normal ratio (e.g. failed challenges/total challenges) over certain periods of time (after all, users miss challenges), but any spike, especially outside normal hours should be a subject of additional investigation.  Notice the change on the wave pattern once we hit Saturday (18).




Stats around mobile could be geared towards maintaining device conformance to a standard (e.g. minimum version for iOS shall be v10), understanding the make-up of the devices and making sure that capabilities that are compensating controls for data protection or leakage are deployed.


Enrolled Device Compliance


In this metric it's important to understand what are the key components of device alignment with policy.   As new mobile devices and OSs are deployed, capabilities may evolve or can be superseded for better ones.  User intervention is also a challenge when it comes to mobile devices, however, organizations can have stronger policy in corporate-owned devices vs. devices brought by the end-user (BYOD).


Device Status



A large percentage of unreachable devices may mean that if you're using self-service enrollment, you may be allowing too many of them.   For example, a limit of 2 devices is preferable than 5 (default).


Device Real Estate


This pie chart provides the answer to a key question - how many devices are out there and what's the make-up. 


Identity service provides a set of policies that provide the assurance that users can't enroll older devices that may not be subject to manufacturer updates that are vulnerable to risks. 



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

Part I | Part II | Part III | Part IV

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:  Privileged User

Part I | Part II | Part III | Part IV

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.



[HOWTO] Setting-up the ServiceNow Centrify Privilege Access Request App

By Centrify Guru I on ‎02-13-2017 09:54 PM - last edited 2 weeks ago


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.


Restrict web application access based on time, location, or device

By Centrify Advisor II on ‎02-08-2017 01:09 PM - last edited 3 weeks ago

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:



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. 


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 III on ‎01-20-2017 09:09 AM - last edited ‎01-23-2017 10:26 AM

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





Showing results for 
Search instead for 
Do you mean 

Community Control Panel