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


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.

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 3 weeks ago By Community Manager Community Manager

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. 

[HowTo] Configuring MFA for Windows Login

By Centrify on ‎12-16-2016 11:41 AM - last edited 10m ago

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. 


If you want to use the Centrify Mobile Authenticator without enabling the Mobile Device Management, you can configure this in the Policy section of your tenant.

Users will be able to use the Centrify application on their mobile device for application access and two factor authentication. 




Center for Internet Security (CIS) Security Benchmarks are consensus-based security configuration guides both developed and accepted by government, business, industry, and academia. The CIS Apple OSX 10.11 Benchmark, provides prescriptive guidance for establishing a secure configuration posture for Apple OSX 10.11. Centrify enables the ability to manage these security settings on the Mac through Active Directory Group Policies


Note: Be sure to test and review the settings before deploying into production. Some settings may interfere with normal operations.


1.2 Enable Auto Update

See instructions 


1.3 Enable app update installs

See instructions


1.4 Enable system data files and security update install

See instructions


1.5 Enable OS X update installs

See instructions


2.2.1 Enable "Set time and date automatically"

Centrify will automatically configure the Mac to use your domain controller for the NTP service when the Mac is bound to AD through the Centrify agent.


2.3.1 Set an inactivity interval of 20 minutes or less for the screen saver

See instructions


2.3.3 Verify Display Sleep is set to a value larger than the Screen Saver

See instructions


2.4.1 Disable Remote Apple Events

See instructions


2.4.2 Disable Internet Sharing

See instructions


2.4.4 Disable Printer Sharing

See instructions


2.4.5 Disable Remote Login

See instructions


2.4.8 Disable File Sharing

See instructions


2.4.9 Disable Remote Management

See instructions


2.5.1 Disable "Wake for network access"

See instructions


2.5.2 Disable sleeping the computer when connected to power

See instructions


2.6.1 Enable FileVault

See instructions


2.6.2 Enable Gatekeeper

See instructions


2.6.3 Enable Firewall

See instructions


2.6.4 Enable Firewall Stealth Mode

See instructions


2.7.1 iCloud configuration

See instructions


2.7.2 iCloud keychain

See instructions


2.7.3 iCloud Drive

See instructions


4.3 Create network specific locations

See instructions


4.4 Ensure http server is not running

See instructions


4.5 Ensure ftp server is not running

See instructions


5.2.1 Configure account lockout threshold

The domain account lockout threshold policy will apply when the Mac is bound to Active Directory.


5.2.2 Set a minimum password length

Domain password policies will apply when the Mac is bound to Active Directory.


5.2.3 Complex passwords must contain an Alphabetic Character

Domain password policies will apply when the Mac is bound to Active Directory. 


5.2.4 Complex passwords must contain a Numeric Character

Domain password policies will apply when the Mac is bound to Active Directory.


5.2.5 Complex passwords must contain a Special Character

Domain password policies will apply when the Mac is bound to Active Directory.


5.2.6 Complex passwords must uppercase and lowercase letters

Domain password policies will apply when the Mac is bound to Active Directory.


5.2.7 Password Age

Domain password policies will apply when the Mac is bound to Active Directory.


5.2.8 Password History

Domain password policies will apply when the Mac is bound to Active Directory.


5.6 Enable OCSP and CRL certificate checking

See instructions


5.8 Disable automatic login

See instructions


5.9 Require a password to wake the computer from sleep or screen saver

See instructions


5.10 Require an administrator password to access system-wide preferences

See instructions


5.12 Create a custom message for the Login Screen

See instructions


5.13 Create a Login window banner

See instructions


5.14 Do not enter a password-related hint

See instructions


5.15 Disable Fast User Switching

Fast User Switching is disabled by default, but the setting can be managed by Centrify through group policy. To learn more see instructions.


5.16 Secure individual keychains and items

See instructions


5.19 Install an approved TokenD for smartcard authentication

A TokenD module is automatically installed with the Centrify Mac Agent. See instructions for configuring smart card authentication.


6.1.1 Display login window as name and password

See instructions


6.1.2 Disable "Show password hints"

See instructions

A security researcher from Segment has discovered a vulnerability in Microsoft Remote Desktop for Mac that allows a remote attacker to execute arbitrary code on the target machine. The advisory indicates the affected versions are 8.0.36 and "probably prior". Until Microsoft provides a patch, a suggested mitigation is to temporarily disable Microsoft Remote Desktop Client for Mac. 


Using Centrify, enable the following group policy settings to block Microsoft Remote Desktop from being launched on the Mac.


Step 1. Enable: Computer Configuration > Policies > Administrative templates > System > Group Policy > Configure User Group Policy loopback processing mode.




Set the policy to Enabled and the mode to Merge.




Step 2. Enable: User Configuration > Policies > Centrify Settings > Mac OS X Settings > Application Access Settings > Permit/prohibit access to applications. For Access mode, select User can open all Applications except these.


Prohibit applications.png



Step 3. Enable: User Configuration > Policies > Centrify Settings > Mac OS X Settings > Application Access Settings > Permit/prohibit access to the user-specific applications.


User-specific applications.png


Click Add and enter


The policy will apply the next time the user logs out and logs back in. When the user attempts to launch Microsoft Remote Desktop the following dialog boxes wll appear.


RDP restricted.png 


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 third article in the series.  We have covered  ServiceNow federation using Multi-provider SSO, setting-up automatic provisioning with the Centrify Identity Service App and in this post we'll discuss the steps to set up Centrify App Access ServiceNow to add workflow and approvals to Centrify Identity Service applications.


Centrify's Access Request vs. ServiceNow Workflow

We often get questions about what to use.  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 general purpose.


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 Centrify Identity Service Instance with some published apps
  • A ServiceNow Instance that allows you to install apps
  • 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 application?
    Depending on the application(s) in question you may have a single group or multiple groups approve.  Or have approval groups per app as well.
  • How will the workflow be designed?
    This topic is very organization-dependent.  Some organizations may chose to have automatic approvals for simple apps and human approvals when the apps require a license or will add access to sensitive data.
  • Have you identified a Default Approval Group in ServiceNow?
    If you chose to have a single group approve access to all apps.
  • Have you mapped all Apps to ServiceNow groups for the purposes of approval?
    E.g. the "twitter" app is approved by the Social Media group;  the "O365"  app is approved by the manager and then the security department.
  • 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 "Role Management" and "Application Management" rights, 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
  • Create an Identity Service role with the minimum rights
  • Create an Identity Service Policy to allow user/password login
  • Download and Install Centrify App Access from the ServiceNow App Store
  • Configure Centrify App Access

Create an Identity Service user

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 two rights:  Application Management and Role Management.   This is to be able to modify role membership and application attributes.


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 an Identity Service role with the minimum rights

When you create the role, grant the two rights illustrated below and add the previously-created user to this role.



Create an Identity Service Policy to allow user/password login

This step may require you to create an Authentication profile that only asks for password (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 Identity Service 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 Identity Service App from the ServiceNow App Store

  1. Go to the ServiceNow app store and search for Centrify.
  2. Click on Centrify App Access
  3. Click "Get" to make the Centrify Identity Service 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 Centrify App Access

There are three configuration tasks required.  Properties, API Sync and Applications.  The third category is only needed if you are using individual groups as approvers for each app.
  1. In the application pane (left) navigate to Centrify App Access > Properties.  Populate these three fields
    Centrify Cloud Tenant URL:  the URL for your identity service tenant.  (e.g. https:
    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 application 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 App Access > 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 CIS Apps and Roles available with ServiceNow.

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 "Amazon as root" app will be approved by the Software 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 (Stewie) will request the app and this request has to be approved by ITIL user.



Once the request is approved (and the underlying task) the app will perform the provisioning of the role that grants access to the application and the icon will show up automatically.


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 App Access approvals section.




ServiceNow is a very popular IT Service Management solution that includes capabilities like workflow and approvals, asset management, discovery, orchestration and more.  In the previous article, I outlined the steps to set federation with ServiceNow using Multi-Provider SSO.  In subsequent posts we'll discuss how to add ServiceNow workflow and approvals to apps and shared accounts using the Centrify ServiceNow store apps.


We'll continue to use the Plan-Do (Implement)-Check (Test)-Adjust (Enhance) methodology:


What you'll need

  • A Centrify Identity Service Instance with some published apps
  • A ServiceNow Instance that allows you to install apps from the ServiceNow app store
  • Administrative accounts on both systems



During planning, discuss with your Infrastructure, Operations and Security teams about these topics:

  • What are the source directories for SN users?
    It's possible that there will be AD, LDAP or other directories involved, based on user populations this adds complexity.
  • Will role mapping be used?
    This feature allows the provisioning of the user's ServiceNow role in addition to account creation
  • Are the target Roles created in ServiceNow?
    ServiceNow has several canned groups, however it's possible that your organization needs custom roles for different entitlements.
  • Are the source groups created in the corresponding source Directories?
    Group management simplifies the provisioning on each target Directory.  For example, adding a user to an AD group can simplify the provisioning process.
  • Are the Centrify Roles created based on the information gathered?
  • Is the UserID field correctly identified for mapping?  Will any transformations be needed?
    In some implementations it's preferred to use the email address as the unique identifier.
  • What will be the provisioning behavior? Overwrite existing entries or leave as is?
    Sometimes this may or may not be desirable.
  • What will be the deprovisioning behavior? Disable or Delete the user?
    In instances in which important data is left behind on systems, it's better to disable the account instead of deleting it.
  • What will be the behavior when users are removed from a ServiceNow group?
    Users may change functions, therefore this behavior has to be defined beforehand.




  • Download and Install the Identity Service App from the ServiceNow App Store
  • Update the State field in the ServiceNow User Role Table
  • Create a ServiceNow User and Assign it a special role
  • Configure Provisioning on the Centrify ServiceNow App

Download and Install the Identity Service App from the ServiceNow App Store

  1. Go to the ServiceNow app store and search for Centrify.
  2. Click the Centrify Identity Service app.
  3. Click Get to make the Centrify Identity Service 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.

Update the User Role table

  1. In the left pane, search for Tables and select System Definition > Tables
  2. In the tables lab, make sure the Go to picker says name, and search for sys_user_has_role
  3. In the User Role table, click the State field, scroll down to choices and press New.
  4. Add a new field with Label Inactive and Value inactive, then press Update.

Create a ServiceNow User and Assign Role

You need to create a service account that will be assigned one of the roles created by the Identity Service app.  This role contains all the entitlements needed for provisioining.

  1. In the left pane, go to System Security > Users and Groups > Users and press New. Then set:
    UserID: username
    Active: checked
    Password: type a complex password
    Other fields: are optional
    Press Submit when complete.
  2. Click the user you just created in the list of users.
  3. Scroll down and click Edit in the Roles section.
  4. Search for x_cenr3_centrify_u.centrify_admin and select it.
  5. Click > to add it to the Roles list.
  6. Click Save.

Configure Provisioning on the Centrify ServiceNow App

  1. Log in to Identity Service with a user with at least the Application Management right
  2. Go to Apps > ServiceNow Web - SAML + Provisioning > Provisioning
  3. Check the "Enable provisioning for this application" box. Ideally you'll start with Preview Mode
  4. Configure the connection details:
    Account Name - type the ServiceNow instance ID
    Admin Name - type the name of the previously created SN user
    Admin Password - type the password for the previously created user

Other Provisioning Options

The following configuration items respond to the planning section. For example, in my test environment
I've decided to have 3 distinct Identity Service roles that mapped to different ServiceNow roles:
I chose not to delete users when they are deprovisioned (just disable them) and to do sync overwrites:

Finally, for more complex scenarios, there is the possibility to use custom scripting for transformations and other options:


Centrify Identity Service provides several options to verify that provisioning will work as expected.  In the previous section you saw the Preview Mode option.  Using the Admin Portal > Settings > Users > Provisioning gives you the option trigger a sync on all or an individual app.  Once you trigger the sync, you have the option to see the activity.
In my example, I added an AD User (stewie.griffin) to ServiceNow Admins role, and these are the results.


Once you have determined that all the provisioning actions are working as expected, you can enable live mode and verify the results in the ServiceNow side.



There are different ways to enhance this implementation with additional controls like Multi-factor authentication, controls to have ServiceNow only accessible from inside the corporate network, geo-fencing, etc. Explore Identity Service's policy features.


Centrify-ServiceNow Resources

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


ServiceNow is a very popular IT Service Management solution that includes capabilities like workflow and approvals, asset management, discovery, orchestration and more.  In this post we'll discuss how to use Centrify Identity Service to secure ServiceNow by using the Multi-provider SSO plugin.  In subsequent posts we'll discuss provisioning, protecting shared credentials, using the Centrify ServiceNow store apps.


Why secure ServiceNow with Federated SSO?

There are multiple security and operations-related reasons to implement federated identity and SSO for ServiceNow.  A key reason is related to the fact that SN is a SaaS platform, this means that the enterprise is extended and information is accesible outside the enterprise datacenter.  Using federated SSO, allows the use for on-premises identity and access control to secure assets outside the enterprise.  This provides the assurance that only authorized internal users can access those assets.  Another reason is usability with SSO there's no need to duplicate passwords; finally there is the gains in operational efficiency by using a process (like adding a user to an AD group to provision access) or simply disabling the AD user account will disable access to ServiceNow automatically.


We'll use the Plan-Do (Implement)-Check (Test)-Adjust (Enhance) methodology:


What you'll need

  • A Centrify Identity Service Instance
  • A ServiceNow Instance or a Developer Instance (Fuji, Geneva or Helsinki)
  • Administrative accounts on both systems


Here are some planning topics for your ServiceNow/Centrify Identity Service Integration

  • What are the user populations that will have access to ServiceNow?  (e.g. AD, LDAP, Google Directory, etc.)
  • What will be the uniquely-identifying field to be used with the SAML assertion?
  • What will be the name for the CIS Role?  (e.g. SN Users)
  • Is the Multi-provider SSO plugin activated in the instance?
  • Will you use the Centrify-provided x.509 certificate?
  • Will the assertion be encrypted?
  • Will provisioning be used?  Are the SN groups created?
  • Will the MPSSO with Centrify be set as default?  Will passwords be eliminated?
  • Will ServiceNow be accessible from inside or outside the enterprise?  Will time or geo-fencing mechanisms will be implemented
  • Should ServiceNow access be protected with multi-factor authentication?



These are the high-level steps to configure Centrify Identity Service as a provider for SSO.

  • In Identity Service: Create a Centrify Role that will be assigned the Centrify App
  • In ServiceNow - Activate the "Integration - Multiple Provides Single Sign-On Installer" plugin.
  • In Identity Service - Onboard  the  "ServiceNow - SAML + Provisioning"  template
  • In ServiceNow - Import the x.509 Certificate for the SAML assertion
  • In ServiceNow - Set-up, configure and enable the Identity Provider
  • In Identity Service - Configure the ServiceNow App

Create a CIS role with the ServiceNow users

  1. Log in to the Centrify Identity Service Admin Portal with a user with at least role management rights.
  2. Go to Roles > Add Role; in the Description tab, give it a name.
  3. In the Members tab, select the users from the target directory or directories, then press Save


Activate the "Integration - Multiple Provides Single Sign-On Installer" plugin

  1. Log into your ServiceNow instance with an administrative user
  2. In the Application Navigator (left pane), use the search feature and type "Plugins", this filters System Definition and click Plugins.
  3. Now in the right pane, next to System Plugins, in Name type  "Integration - Multiple"
  4. Click on "Integration - Multiple Provides Single Sign-On Installer"  (should be set as inactive, if it's not, skip to the next section)
  5. Under Related Links, Click "Activate/Upgrade" and Click Activate
  6. After activation, the "Multi-Provider SSO" Application will be activated in ServiceNow.  This app contains these sections:  Getting Started, Identity Providers, Federations and Administration.


Onboard the  "ServiceNow - SAML + Provisioning"  template

  1. Sign-in to Identity Service with a user that at least has the Application Management right.
  2. In the Ad0min Portal go to  Apps > Add Web App, then search for "ServiceNow SAML + Provisioning"
  3. Click the Add button, confirm your selection and close the Add Web Apps window.
  4. In Identity Service, you'll be placed on the Application Settings tab for the ServiceNow app template, scroll down and click on Download Signing certificate
  5. Open a text editor in your platform (Notepad, TextEdit or Vi) and open the downloaded file.  Copy the contents to memory.
    (Note:  the contents should be a PEM-encoded certificate)


Import the Certificate to the Multi-Provider SSO via x.509 Admin Module

  1. In ServiceNow > Multi-Provider SSO > Administration > x509 certs
  2. New Cert > Give it a unique name
  3. Format > PEM
  4. PEM Certificate >  paste the contents of memory loaded in the previous section
  5. Press Save.


Configure the Identity Provider

  1. In ServiceNow > Multi-Provider SSO > Identity Providers
  2. Select New > SAML2 Update 1 > and when the "Import Identity Provider Metadata" pop-up comes up, select Cancel.
  3. At this point, you can use the table on this page to configure the settings.  This is because it depends on your directory source and optional settings.  Here's the configuration for a now decommissioned demo environment:
    - The look and feel of the multi-provider SSO plugin varies between SN versions Fuji, Geneva and Helsinki.
    - The identity provider has to be set to Active and default if you want Service-Provider initiated to be possible.
    - The "Failed Requirement Redirect" is set to the same value as the "Identity Provider AuthnRequest."
    - The location of the x.509 certificate options varies.  You may have to press save to see the option in some versions of ServiceNow.
    - The default field option for the Identity Provider is email.  Modify this setting based on your planning and identity source field mappings.
  4. Once finished, press Save


Enable Multi-Provider SSO

  1. In the Multi-Provider SSO app , select the Properties module
  2. Check the "Yes"  box under "Enable multiple provider SSO"
  3. Press Save.  This completes the ServiceNow set-up for SSO.


Configure the ServiceNow App in Identity Service

  1. In Identity Service, go back to ServiceNow > Application Settings
  2. If you haven't, type in the instance ID under "Your ServiceNow instance name", then click on User Access
  3. Check the box next to the Centrify Role that was created in the planning phase.  Click on Account Mapping
  4. Because in this example, we're using Active Directory as the user source, we are going to use "samaccountname"
    Note:  that's is the "username" field in Active Directory, therefore, the user ID in ServiceNow must match for each user.
    This is one way to do it, there is flexibility here.  Other common deployments use the email field.
  5. Testing your work in the Advanced page
    Use the test button with some users in the target role to make sure that the assertion will be correct.



For testing, all you need to do is create an Active Directory Identity Service user and match the User ID in ServiceNow with the user's AD login name (samaccountname) and set it to active. 
Since this will be an SSO user, there's no need to give it a password.  At this point you are set to perform Identity-provider or Service-provider initiated tests.

  • Identity-provider initiated login
    Log in as your AD user, to the Identity Service User Portal.  You should see the user's assigned apps including ServiceNow
  • Service-provider initiated login
    Go to your instance URL and select external login.  When you type-in the username, you'll either be re-directed to your Identity Service portal for authentication, or if you have a current session (or Kerberos ticket and IWA enabled), you'll be placed in the app.

    Note that this behavior can be modified if the SN multi-provider SSO is set as default.


Enhancing the Implementation

There are several areas for enhancement, but these come to mind:

  • Enable Provisioning (next blog post)
  • Enable multi-factor authentication
  • Protect shared accounts
  • Enable workflow and approvals

Centrify-ServiceNow Resources

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

Restricting access to the USB port can help protect Macs against some USB attacks and help prevent data from being copied to external USB drives. Centrify enables the ability to manage this setting on the Mac through Active Directory Group Policies. 


Step 1. Enable: Computer Configuration > Policies > Administrative templates > System > Group Policy > Configure User Group Policy loopback processing mode.




Set the policy to Enabled and the mode to Merge.




Step 2. Enable: User Configuration > Policies > Centrify Settings > Mac OS X Settings > Media Access Settings > Permit/prohibit access: External Disks and select the desired access setting.


USB port policy.png


For more details regarding this setting and other media access settings, see documentation on Media Access Settings.

Find out how to recover administrator access to an existing DirectAudit Installation by granting an AD User administrator privileges at the Database level. 


Many customers have Duo MFA already installed in their environment. Here's how you can integrate with Centrify Identity service using RADIUS.


Oracle has supported authenticating internal users against Active Directory for several years now, but it does require a fundamental comprehension of Kerberos in order to configure it properly. Of course, this is much easier to accomplish on Windows than Unix and Linux, but luckily, we have the Centrify DirectControl agent to extend the Kerberos environment and help us achieve secure, Active Directory-based authentication without remembering passwords.



Amazon AWS is at the heart of many of our customers workloads.  Last year I started a series of tech blogs to discuss how to leverage Centrify's product portfolio to secure your AWS assets.


This year, I've had the opportunity to review the AWS Security Best Practices document and in this new series we'll provide guidance on how to implement controls to meet or exceed the Shared Responsibility Model.  


About the Shared Responsibility Model

The concept is very straightforward.  Amazon AWS will implement controls to provide assurance for confidentiality (e.g. encryption at rest and in transit), integrity (transaction trust), availability (redundancy of hardware, power, etc), however, depending on your business requirements, you may need to add additional controls to increase your security posture or to provide assurances to your customers beyond what's offered by AWS.

Amazon AWS Defines a "Shared Responsibility" model that has the following scope

  • Infrastructure Services: Controls that apply to IaaS services like EC2, VPCs and Block Storage.
  • Container Services: Controls that apply to PaaS servides like RDS Database, EMR MapReduce or Elastic Beanstalk
  • Abstracted Services: Controls that apply to Services like S3 Storage, SES SMTP, etc.

 In this article we'll focus on how to use Centrify Privilege Service to secure access to Windows AMIs.


The Challenge:  Extend Existing Enterprise Identity and Access Management in Public Clouds

In a previous entry of this series, we discussed the additional controls that can be implemented on top of Amazon's IAM and cryptography-based controls.  However, organizations may already have capabilities for Centralized Identity which is at the heart of strong access controls.  This may mean that organizations need to find ways to extend this infrastructure out to public clouds like Amazon.  This may imply:

  • Re-creation of infrastructure (e.g. standing-up Active Directory or LDAP-like infrastructure)
  • Network extension (e.g. treating the public cloud like a branch by implementing site-to-site VPNs)
  • Capability duplication (e.g. implementing software and services in AWS)

In this article we'll discuss how organizations can leverage Centrify Privilege Service and the new Linux Agent (Identity Broker) to secure Linux instances and extend Enterprise Identity out to public clouds without the need of the additional overhead.


Centrify Privilege Service


Privilege Service is Centrify's answer to the traditional "password-driven" use cases (the industry refers as Shared Account Password Management, Privilege Session Management, etc);  however unlike other solutions, there are several capabilities areas that set it apart from the traditional "Password Vault"

  • Flexible deployment:  Both as SaaS and On Premises  (in fact, it was designed as a SaaS solution first)
  • Identity Sourcing and Federation built-in (includes Identity Service, this means support for AD, LDAP, Google and others  plus simplified SAML-based federation and 3K+ ready web and mobile apps)
  • Policy, Workflow and MFA Engine:  Policies for time and geo-location, RBAC, step-up authentication and Multi-factor including Smartcard, plus a built-in access request system (+ServiceNow integration)
  • Infrastructure Extensibility:  Privilege Service can be extended to any network using a Windows-based Centrify Connector via web protocols.


New Linux Agent

The new Linux agent takes advantage of a capability called "Identity Broker" this allows the bridging of identities known to Centrify Privilege Service;  this is done via the Centrify connector.  This means that the overhead of duplicating enterprise identity infrastructure or extending the enterprise to the public network can be avoided in this particular use case;  all that is required is to deploy a Centrify connector wherever you want to extend Password-related services and Linux authentication.  Let's show an illustration.


Company X needs to provide identity-based reporting and attestation of who has access to their public cloud EC2 instances in AWS;  their primary identity source is AD.  They could have used any model (independent forest, one-way trust + site2site VPN or RODC) to extend AD to AWS  or they could have deployed Amazon IAM roles and used SSH keys; but any of these models implied additional overhead.  With CPS and Identity Broker, all they did is this:


With this model, CompanyX not only can accomodate their corporate IT users, but external entities as well.  And as we discussed before, password, session and additional services are consolidated as well, both on premises and on any public cloud.  Plus

  • No need to deploy "jumpboxes" to the private clouds (limits exposure)
  • Shared account passwords for local accounts (Linux, Windows) or databases (like Amazon RDS) can be controlled
  • Access Request provides the assurance of "documented approvals" to sensitive systems
  • Deploy MFA or access only from the OnPrem network as additional controls.

This topic was covered in this post.


Agent Architecture

The client architecture is using UNIX frameworks like Name Service Switch (Identity) and Pluggable Authentication Modules (Auth).  It also supports offline login as well as direct or proxy-based user/password or OAUTH-based enrollment codes (very useful for automation). This client implements the CLI tookit for setting, retrieving or deleting credentials under management.


Supported Platforms


UNIX Identity

Following on the legacy of Server Suite, the new agent generates identity like DirectControl in workstation mode.

Login - user's short name (must use the fully-qualified name the first time)

UID - auto-generated based on the GUID

Primary group - auto-private (same as UID)

GECOS - the display name in Centrify Identity Service

Home/Shell - configurable in the Settings tab.


Since most public clouds don't need legacy identity (for services like NFS), this makes the client very lightweight.



There's an implied expectation of DevOps "friendliness" when a private or public cloud solution is implemented.  The new Linux agent leverages enrollment codes for this capability.


Centrify provides a sample AWS script that can be used with enrollment codes in the User Data field or with any other framework like OpsWorks (see attachment)


Identity Broker

Privilege Service can accomodate several identities, including:


Note that it can accommodate identities from Active Directories without any trust relationships.

These identities can be aggregated using Identity Service Roles:


 Roles, in turn can be assigned the AgentAuth privilege on a Linux Resource:

IB-aws resource.png

As you can see the model works like this:

Users or groups from Identity Sources are added to CIS Roles that are granted the AgentAuth right in CPS.


Basic Commands

Agent Operation

  • cinfo – obtain information about the agent
  • cenroll – enroll the identity platform and enable features
  • cunenroll – leave the platform and optionally delete resource and any managed accounts
  • cflush – flush the local cache

IB login.PNG



  • csetaccount – add a managed account for the resource
  • cgetaccount – obtain a managed account’s password
  • cdelaccount - delete a managed account's password


To test-drive the new Linux agent and to see how it can secure your public-cloud Linux instances, request a CPS trial today:


Related Articles

AWS Shared Responsibility - Securing the Amazon Account

AWS Shared Responsibility - Securing Windows AMIs with Centrify Windows MFA

AWS Shared Responsibility - Securing Amazon RDS Instances

Showing results for 
Search instead for 
Do you mean 

Community Control Panel