There are a lot of configurations that can be done before importing systems and managing accounts for Privilege Management in our Infrastructure Service. 


Before you get started, you will need to choose a deployment option. Centrify offers two methods that you can choose from for your organization. You can choose to use our cloud based service or to manage your own systems with our on-premises customer-managed deployment option. 


If you are looking to try this out for the first time, then you can sign up for a trial here -


-If you are going with the cloud deployment option, then you will need a Centrify tenant with the Privilege Service enabled. Your organization may already have one, but if not then you will need to start a new trial using the link above.


-If you are going with the customer-managed deployment option, then you will need to download and install the Centrify Privilege Service. If you have not purchased this software, then you can sign up for a trial using the link above.


-You will want to have at least two Centrify Directory Service accounts in System Administrator Role. This is to ensure that you are not the sole owner of administrative credentials to the service, in case of emergency. Also, it is a good practice to have some backdoor accounts that are still accessible in case the Active Directory connection is unavailable.


 System Administrator Role Memebers.png












Adding Centrify Directory Users

Creating Centrify Platform Administrators

System Administrator Role Permissions


-You will want to have a customized login suffix. This will be a unique suffix that your users will type to login. The login suffix also tell the authentication engine which identity repository and tenant to log a user into.


 Login Suffix.png














Creating a login suffix

How to use login suffixes


-You will want to have a customized tenant URL configured. This URL should be easy for users at your company to remember. You can create it in your Admin Portal Settings > Customization > Login > Tenant URLs.


Tenant URLS.png














 Tenant URLs


-You will want to define user security policies for login authentication to the Centrify Admin and User Portals.  You will want to determine wether additional forms of authentication, besides their passwords, will be required when users log in to the Centrify Platform. Enabling login authentication in the user security policies will allow you to set what conditions users are required to present a second or third authentication mechanism, like if they are outside of the corporate network.


Login Authentication User Security Policy.png




























Setting authentication policy controls 

Creating authentication rules

Creating authentication profiles

Authentication mechanisms


-If you are requiring a second or third authentication mechanism for login, then you will want to make sure that your users will be able to satisfy any authentication challenges that they are required to approve. 


What you need for each authentication mechanism


  • For SMS/text challenges, then check that the mobile attribute, specifically is set for your users in Active Directory and Centrify Directory. 


  • For phone call challenges, then check that any phone number attribute is set for your users in Active Directory and Centrify Directory


  • For email authentication mechanisms, check that the mail attribute exists and has been set for your users in Active Directory and Centrify Directory.


  • For RADIUS as an authentication mechanism, add the RADIUS server information, enable your Connector(s) to work as RADIUS clients, and enable the RADIUS policy. Also, the Connector(s) that you enable as RADIUS clients will need to be added to your RADIUS server  as a RADIUS client.


Enable 3rd Party RADIUS Authentication.png



























How to configure Centrify Identity Services platform for RADIUS

Configuring Connector as a RADIUS client

Configuring the Centrify Connector for use as a RADIUS client

Configuring a RADIUS server


  • If using OATH for MFA, configure OATH policy


Allow OATH OTP Intergration.png


























How to configure OATH OTP 






Early adopters of shared account password management  (SAPM) solutions have discovered that a single strategy (e.g. password-driven) does not provide the assurance for modern IT infrastructure.  Despite the quick way some audit comments can be mitigated with a shared password solution, when you explore the modern enterprise, there are many issues and opportunities for improvement.  In this article, we'll discuss the challenges with vaults, and how with Centrify we can either compensate, enhance or consolidate security capabilities.

The idea is to explore each topic, and propose and demonstrate a scenario, provide recommendations and use an example with Centrify Infrastructure Services. 


You can also use this series to explore the capabilities of Centrify Privilege Service (a.k.a Centrify's vault)


The Traditional Password-Driven PIM Design and its Challenges


The illustration above provides a generic diagram for a password-driven PIM design; the whole premise of this design was that if you can control access to the password of a shared privileged account, provide secure access services (like terminal/desktop transport, auditing and recording) all via the vault and centralize access via a portal, then the issue could be resolved.  In time, many issues were observed:

  • "Productivity-driven" abuse:  when vault users suddenly "camp" (check out credentials for a long time), lobby for multi-checkouts, "try to go around" the vault when they can.
  • Deferment of identity or privilege consolidation:   very prevalent on the UNIX/Linux world, suddenly it was OK to continue with identity duplication in /etc/passwd, /etc/group accounts as well as managing and maintaining sudoers file configurations.  This was also influenced by the advent of DevOps solutions that make configuration management much easier.
  • Challenges for security practicioners:  Due to all the moving parts, it is hard to prove the effectiveness of these controls; there are many moving parts, and not enough compensating controls at each critical area.
  • Identity duplication:  The "vault" over time became another identity silo, especially if the design implied that all the local passwords for privileged accounts (e.g. root, administrator, etc) along with the user's "administrative, or -a" account was also living there.  This means that rather than eliminate the problem of "too many passwords" we decided to embrace it and get a tool to manage the issue.
  • Did not solve the issues faced by most enterprises:  Modern enterprises need flexibility and productivity, there are challenges with Filers, client-server applications, high-frequency transaction and other scenarios where this solution set does not provide a solution or simply does not scale well.  There are enterprises that have solved the problem of centralization, but simply chose the wrong infrastructure; and they want to come to Active Directory for more than just authentication.
  • Did not survive the test of time:  Although credential password management is one of the fundamental tools to mitigate security breaches, the goal is to achieve security assurance as threats evolve as well.  A key example is that this model does not solve issues like PTH in Windows or works well in multi-private/public cloud scenarios.
  • It's not really protecting the target systems:  This is perhaps the biggest flaw of this design.  All it's doing it's securing a privileged account password; if the system is compromised, there's no active software locally to provide assurance.



These articles will cover how Centrify Infrastructure Services addresses many of the issues outlined above, from identity consolidation to auditing and monitoring, across different platforms, however we'll do it maintaining our Identity Maturity model:

maturity model.png

 Series Content

  • Identity consolidation as a way to avoid vault-bypassing and to maintain assurance
    • Maintains productivity
    • Promotes centralized administration
    • Eliminates friction to adopt other identity-driven controls (like MFA or Risk-based access control)
    • Maintains flexibility for different types of enterprise challenges and apps
  • MFA across multiple contexts and use cases to provide identity assurance
    • At login (portal and system)
    • When using a shared account with secure access
    • When checking-ount a password 
    • When elevating privileges
    • When accessing a legacy platform
  • Securing the target systems with Centrify Zones
    • Using Centrify Local Account Management as a temporary phase
    • On the target system (UNIX, Linux or Windows)
    • Enforcing least access and least privilege
    • Embracing temporary access controls
  • Demonstrating the efectiveness of the controls
    • Monitoring (easy security operations integrations)
    • Attestation (portal, system)
    • Auditability and reportability (portal, systems)
  • Automation, DevOps and Operations
    • Components required
    • How processes are affected
    • Using an ITSM Solution to consolidate access requests

Combining Shared Accounts with Least Privilege


Article format

In each article, we'll try to define a challenge and illustrate the different ways Centrify can compenate or enhance the challenged caused by the Password-driven design.  We'll try to use existing articles when possible to reference past Tech Blogs.  As we add articles to this series, we'll list them below.



This tech blog explains how an Administrator can extend Active Directory to include Exchange server specific Active Directory Attributes, to use some additional Exchange specific features with Office 365, even though Exchange server is not/was not installed on premise.


Talking about our supported local clients for remote sessions, one of the quetions I often get back is, "What about PowerShell?".  In this post I will demonstrate how to launch PowerShell sessions from the Centrify cloud platform using PowerShell Web Access (PSWA).




Centrify for Google Chromebook Single Sign-On Configuration Guide


Google G Suite has become one of the most popular on-demand business software in the market and your organization took the plunge to migrate to Google G Suite. You need to assign licenses to your end users automatically, and give them single sign-on. You’re worried about Chrome Book device management and BYOD, and how to manage all that for on-premises apps and cloud apps, too. You’ve got a few questions, and are looking for answers. Without SSO user productivity is greatly affected, without Multi Factor Authentication the risk of exposing inappropriate access increases and without automated account provisioning / de-provisioning IT has to manage all accounts manually.


Fortunately, Centrify Identity Service (CIS) provides a solution. CIS for Google G Suite offers a complete, robust, and easy-to-use Active Directory (AD) or CIS Cloud Directory integration with Google G Suite, providing a seamless authentication experience for Google G Suite users and an easy to use intuitive Administrative interface for IT staff to automate the process of on- and off-boarding employees with day one productivity.

With CIS you can ensure that users have seamless access via single sign-on (SSO) and that their Google G Suite accounts are created, updated, and deactivated on an integrated cycle with the rest of the systems in IT.


Centrify Identity Service enables integration with any web application that also enables administrators to:

  • SSO via SAML or CIS form fill to all Google G Suite: Gmail, Docs, Sites, Calendar, Analytics, etc.
  • Provide secure SSO with Active Directory integration
  • Automatically provision/de-provision users & apps by Active Directory group
  • Demonstrate compliance through usage auditing
  • Increase application ROI with seat-utilization reporting

Secure Application Access via MFA from unauthorized systems or locations


Getting Kerberos Tickets For Your Second AD Account On Your Smart Card


Centrify for Google G Suite offers a complete, robust, and easy-to-use Active Directory (AD) or Centrify Cloud Directory integration with Google G Suite providing a seamless authentication experience for Google G Suite users and an easy to use intuitive Administrative interface for IT staff to automate the process of on- and off-boarding employees with day one productivity.


With Centrify you can ensure that users have seamless access via single sign-on (SSO) and that their Google G Suite accounts are created, updated, and deactivated on an integrated cycle with the rest of the systems in IT.

Secure access to Google G Suite from any device. Enforce and update mobile security settings, and remotely lock or wipe devices. Lock the Centrify Mobile App with a passcode or fingerprint, and prevent unauthorized users from accessing your Google data. No separate software required.


The Google G Suite Deployment Guide covers…


  • Preparing your Google G Suite and Google G Suite developer account
  • Limiting access to certain Google G Suite based on Security Group
  • Configuring automated account provisioning into Google G Suite
  • Enabling Single Sign On in Google G Suite
  • Provisioning new Users
  • Integration with Active Directory
  • Securing the Administrative Account for Google G Suite



So you're already managing user accounts in Active Directory - but what about those pesky system accounts you're still managing in /etc/passwd?  Wouldn't it be great to manage them with Centrify too?  In this article we'll demonstrate how to securely manage local accounts using a comination of Centrify Server Suite and Centrify Privilege Service.  



Configuring Centrify to use the Google Authenticator to satisfy MFA challenges is a good way to give users another authentication factor. The set up is easy for end users once all of the policies are configured from an Centrify Identity Platform Administrator.


If you are already using the Centrify Identity Service for single sign-on, then your users can easily configure automatic login for the websites that they frequent. This is very beneficial for users that are accustomed to saving credentials into their browsers, since they do not have to store the credential in the Credentials Manager or Keychain.


This article will show you how to secure the access to a web application by prompting for multi-factor authentication or denying access, 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


Other settings to consider:




This article will show you how to secure the access to a web application by only allowing access from a device that has been enrolled into Centrify's MDM or prompt for multi-factor authentication when accessing from a non-managed device. 


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, then click Add Rule.



Add policy.png 

3. When a new window appears, click Add Filter.

 add filter.png



4. Select Managed Device and desired condition, then click Add.


filter condition policy.png



5. Select a Authentication Profile such as - Not Allowed -  or a predefined authentication profile to perform multi-factor authentication to access the web application.


filter authentication profile.png 


6. Select a Default Profile to - Always Allow - or a predefined authentication profile to perform multi-factor authentication for Managed Device users.

7. Press Save when your configuration is complete.


Other settings to consider:

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


Centrify Identity Service and MFA for VMware Horizon View 7

By Centrify Contributor III on ‎10-13-2016 04:58 AM - last edited ‎10-14-2016 11:41 AM

Steps for configuring MFA with RADIUS in VMware Horizon View 7 and Centrify Identity Service



This series of articles will walk you through some real-life examples of how Centrify Role-Based Access Control (RBAC) can help get better control of your Identity Access and Privilege management.


This article is going through several exemples of Roles and Rights on UNIX and Linux systems and how they can answer various IT security rules in real life examples.


This series of articles will walk you through some real-life examples of how Centrify Role-Based Access Control (RBAC) can help get better control of your Identity Access and Privilege management.


First article is presenting few examples of the three possible scopes for Role Assignments.


Did you know that you can give Active Directory users the ability to do specific priveleges without giving them full local administrative rights? Well, you can with Centrify's Group Policies by mapping AD group membership to local groups on the Mac.


When joining a Mac to AD with Centrify, there are a few different options.  However, the option I would like to discuss is "Utilize Apple UID generation scheme".  What does this mean?  When do I use it?  What is it?


For reference, here is a screenshot of the aforementioned property:


Screen Shot 2016-05-20 at 3.01.26 PM.png


  • What is it?

This property uses the Apple UID generation method, Vs the Centrify method.  To fully understand why this is critical in your environment, let's roll back a few steps and get some background.


  • UID Generation

At a very basic level, a UID is a numeric string that is associated with a single user within Active Directory.  This string defines a user, and is used within OS X to define filesystem ownership.  When a user logs into an OS X system for the first time, a home folder is created for this user in the /Users directory.  Upon folder creation, the home folder is assigned user ownership by their UID.  Now, what kinds of UIDs can be spotted out in the wild?  Here are the three most common:


  1. ) Local UID - These are UIDs created by OS X when local users are created.  The first user is 501, second is 502, etc. 
  2. ) Apple AD UID - Created when users log into a machine bound by Apple's AD plug-in, or when explicitly configuring Centrify to use it.
  3. ) Centrify AD UID- Created when users log into a machine bound by Centrify's AD plug-in.

For our purposes, let's focus on Apple and Centrify UID generation methods.  The biggest difference between these UID generation methods is how the UID is generated.  Apple UID is generated using the user's GUID.  Centrify on the other hand uses the user's SID.


  • Why does this matter?

To fully understand why this matters, let's take a closer look at Apple's generation method:


Apple translates the 128 bit GUID to a 32 bit UID.    However, they only use the first 32 bits in the translation.  This means that it's possible for more than one user to have the same UID on a Mac!  Backing up to our earlier discussion, this is supposed to be a unique value per-user that defines filesystem ownership. 


Bottom line?  Users could have the ability to "own" each other's files.  Now, granted- if you have a small AD, this is very unlikely.  But, the bigger your AD, the greater the chance.  Not really a chance I want to take, especially with network home folders.


So...How is Centrify different, and ultimately better and more secure?


Centrify uses the user's SID/RID to generate the user's UID.  The SID is guaranteed to be unique by AD, and the RID is guaranteed to be unique within the domain.  The RID is, by default, what Centrify DirectControl uses for UID/GID generation.  The domain portion of the SID is reduced to a configurable prefix. 


Bottom line?  This issue does not exist with Centrify's method of UID generation.   


  • When and WHY would I use Apple's method?


With the above knowledge, in what situation would you want to use Apple's UID method?  There's really only one scenario- when the machines were joined in the past (before Centrify) with the default Apple plug-in.  This will ensure compatibility for existing users, when they log into their newly Centrify-joined machine.


If the machine was joined in the past using Apple's plug-in, the user's home folder will be stamped with a UID generated via Apple's method.  If a user were to log into the machine that's joined with Centrify and NOT using Apple's method, there will be a UID mismatch.  The user will be able to log into their account, but will not be able to access any of their files due to the fact that they technically do not own them, because their UID is now different when generated with Centrify.


  • What if I want to convert all previously joined machines to Centrify's method?


This is actually an easy process.  All you need to do is:

  1. Log into the machine as local admin
  2. Join the machine to AD with Centrify DirectControl
  3. Run the change ownership command, to allow the new UID to be applied to the home folder:
    1. sudo chown -R /Users/homefoldername 
      1. In the above command, replace "" with the user's AD login name, and "homefoldername" with the home folder's actual name.  (For example: sudo chown -R john.doe /Users/john.doe)
  4. If you want to verify that the change took place, you can compare the output of ls -ln /Users and adquery user -u 
    1. Again, replace "" with the user's AD login name.
  5. Take a look at the screenshot below to see these commands in action, and comparison after the change. 

 Screen Shot 2016-05-20 at 5.10.54 PM.png


As you can see- before the chown command, the UID on the home folder and the UID associated with the AD user is different.

After the chown command, the UID on the home folder, matches the UID associated with the AD user, which signifies a successful change ownership operation took place.  


Hopefully this helps make sense of a subtle, yet important piece of OS X and AD Join.


As usual, feel free to post any comments or questions below.



Did you know that you can MFA into your Centrify User Portal and assigned SaaS apps by using an Apple Watch? As long as your paired iOS device is enrolled into the Centrify Cloud and you have the Centrify mobile app installed on both the iOS device and the Apple Watch, then you can use this right now!


Su Información Es Muy Importante! No De Papaya!

By Centrify on ‎12-21-2015 02:57 PM - last edited ‎12-21-2015 03:06 PM

Proteger la información de su compañia ante un ataque o robo de datos puede lograrse fácilmente con un poco de malicia y algunas herramientas. Usted debe estar preparado!


Showing results for 
Search instead for 
Do you mean 

Community Control Panel