Centrify Agent for Windows™ Deployment Options - Introduction

By Centrify Guru I on ‎02-17-2018 10:06 AM - last edited 3 weeks ago

The Centrify Agent for Windows provides organizations with the ability to secure Windows systems.  This article's goal is to introduce the basic information (pre-requisites, communications), deployment scenarios and tools available for each deployment option.  The next articles in the series focus on specialized topics or use cases.


This is the second article on a series around Centrify's role to participate or enhance the Microsoft Enhanced Security Administrative environment.

The first article on the series covered MS ESAE in FAQ form and introduces 10 Principles derived from this environment.

In this article, we provide information about how centrify can enable the implementation of the general principles and recommendations. 


Plesase read the original article (link below) to get the full context of the information:



Security questions are like a second password prompt. Just like passwords, users tend to create weak or easy to guess answers. Unlike passwords, security questions usually do not have policies to enforce complexity, uniqueness and guessability.


Here are some tips to help make your security question answers stronger:

1. Use a non-corresponding answer.

Using an answer that does not correspond to the question will make it harder for unauthorized users to guess or find your answer. For example, if the question is your first car model, answer with "blankcowblueYogurt". If the question is your mother's maiden name, don't use your mother's maiden name as the answer. Your mother's maiden name might be easily acquired through social media, social engineering, stolen records, public records, malware, easily guessed or many other methods.


2. Avoid answers that are vulnerable to social engineering.

Even if you use a non-corresponding answer to a security question, unauthorized users may still randomly attempt to use information that could be acquired through social media or social engineering such as the name of your child, pet, school, or company.


3. Follow password complexity rules for your answers.

Security questions are just like a second password. Hackers may use brute force or dictionary attacks on a security question. Following password complexity rules can help to make your security question answers more secure.


An easy to remember and yet complex answer is to use four random words like "blankcowblueYogurt".


Source: https://www.xkcd.com/936/


4. Use spaces if possible.

Older generation brute force and dictionary attacks don't account for spaces. For modern tools, it can make it longer and harder to crack if there are spaces. Add a space in your answer if allowed. "blank cow blue Yogurt"  


Centrify MFA can use security questions for:

  • AD password reset / account unlock
  • Computer login (Windows / Linux / Unix)
  • Privilege elevation (Windows / Linux / Unix)
  • Remote access through Centrify's password vault.
  • Password checkout for shared privileged accounts.
  • AWS Workspaces
  • Horizon View
  • Accessing a web application
  • Accessing the Centrify User and Admin Portals. 
  • VPN access

Centrify users can set up their security question(s) through the Account tab in the Centrify User portal.

I've been asked from potential customers, Does our Centrify Cloud Platform integrate with Apple's OpenDirectory LDAP server?  Or more specifically, can I authenticate users from my OpenDirectory Server into the Centrify Cloud Portal and assign those users to roles, apps, MFA, etc.


Answer: Yes you can !


What does this all mean then ?  Well, you can execute self-service password resets for your user accounts, portal password changes, MFA for user and application SSO access; in short, all the benefits you might get from an Active Directory integration.  You lose nothing by integrating with a directory like Apple's OpenDirectory, and that's the beauty of our Centrify Identity Platform.  


To be able to authenticate and utilize users from your OpenDirectory server into the Centrify Cloud Platform is the purpose of this guide.


A little history first...

OpenDirectory has been around since MacOS 10.2.  It was introduced as part of Apple's attempt to provide it's Enterprise customers with a network-visible NetInfo directory domain with a corresponding authentication manager service for storing passwords outside of the directory.  To sum that technical sentence up, It's basically an OpenLDAP-based LDAPv3 (lightweight directory access protocol) server. Which is more common than you think in many corporate environments.  Many Law offices and Educational institutions are OpenDirectory shops, since lawyers and students are very common Mac customers and users.  


To start, a very convenient tool to use for this process is a tool that runs on Windows called Softerra LDAP Browser.  You can download a free browser version from Softerra's website here: http://www.ldapadministrator.com/download.htm .  Not the administration software, but the browser.


We will use this tool to do look-ups of the common name of our server baseDN, and some of it's corresponding user object attributes.  It just makes our lives easier, and I'll be using it in some of the pictures for the setup and configuration.


This guide assumes that you have setup an OpenDirectory Server already


This guide will not go into the setup and creation of the OpenDirectory Server.  It's assumed that you know the hostname of your server, that if it's a public facing directory, that all the relevant host records have been created and are currently working.  This also assumes that you have a valid host certificate from the OpenDirectory domain and that you can communicate over secure LDAP.  A server certificate is not required for the setup, but it will make the connection between your cloud and OpenDirectory server secure.


  1. Let's open up the Centrify Administrator Console, login with an administrator for your Centrify Cloud Platform
  2. Navigate to Settings > Users > Directory Services.  You should see this:

    Admin Console - Settings > Users > Directory ServicesAdmin Console - Settings > Users > Directory Services
  3. Click on Add LDAP Directory, and you should see this dialogue:

     Add LDAP Directory ServerAdd LDAP Directory Server
  4. Let's give it a name like "Apple OpenDirectory Server"
  5. Let's give it a description, "Apple's OpenDirectory for the Law Office.."
  6. Add the hostname of your OpenDirectory server, in the case of my OpenDirectory server, it was macserver.test, but this will be whatever you have setup in your OpenDirectory hostname, as seen here:

              Mac Server hostnameMac Server hostname
  7. Let's get the baseDN from the server. This is where having an LDAP Browser comes in real handy.  I will be using this tool to show you how to get this value
    1. Open up your LDAP Directory Browser Tool (you don't need this if you're savvy enough to get this from the Directory Utility in MacOS Server, or another way)
    2. Add the Server connection to your LDAP Browser
    3. Navigate to the root of your Mac OpenDirectory Server as seen here:

      baseDN from LDAP browserbaseDN from LDAP browser
  8. Type in your baseDN in the baseDN field, in my case "DC=macserver, DC=test"
  9. Type in your hostname for the suffix for the users that will be provisioned under, in my case "macserver.test"
  10. For the bindDN, you will need the administrator account you setup initially when you created your OpenDirectory user.  THIS IS NOT the local admin user on the Mac OpenDirectory Server.  It's the user that you created when you setup the OpenDirectory. It's normally called "diradmin" or whatever you might have chosen. You can find it by using your LDAP browser and selecting users, here you will see a list of LDAP users that are part of OpenDirectory.  Make sure you note the DN for the user and enter it here.  
    1. For example, it might be diradmin, in this case the Common Name would be "uid=diradmin,cn=users,dc=macserver,dc=test" . This tells our platform the UID, and the location of the user.  here is a picture from the LDAP browser (right click on the user object in the navigation tree and select properties):

       Common nameCommon name
  11. Type in the password for the user in the form
  12. UN-CLICK the Verify Server Certificate selector.  We will go back and test secure communication later on, but for now, you can just test the connection.
  13. If all went well, you should have a Connection Successful and a Green Check-mark:

  14. If not, go back and check the data entries and make sure you follow exactly what was written down here and that the cloud can see the Mac OpenDirectory Server.  Again, it's assumed that you can see the server either privately inside your Corporate subnet, or publicly.  
  15. If the name cannot be resolved, try to enter the name in the hosts table or use the IP address of the machine.
  16. If the latter, you will likely need to un-check Verify Server Certificate on the Add LDAP Directory page.
  17. If the server is NOT listening on port 636, append the port to the DNS hostname; for example: <dns hostname>:3269 Note: We only support LDAP over SSL.
  18. We do not support clear LDAP.  If we can communicate over this port and can resolve the hostname, we will be able to verify the server certificate. 
  19. One last piece is to choose a connector that the OpenDirectory Server can talk to and has communciation with.  Click on the Connectors menu item in the "add LDAP directory" dialogue: 

  20. Make sure you select a connector that your OpenDirectory server will and can talk to on an ongoing basis and retest your connection.
  21. Once you've integrated the OpenDirectory Server, there are a few oddities that need to be discussed.
  22. OpenDirectory does not natively support Phone Number, Mobile Phone, and other attributes that are crucial to the Centrify Platform and MFA.  Without these attributes, it will be impossible to authenticate the OpenDirectory Users using MFA.  If you're only using passwords, then this will be easy, but most organizations do not rely on passwords alone, and it's not a good security principle.
  23. To fix this problem, we can add attributes to the user accounts via Apple's Directory Utility. 
  24. To do this, go back to your Apple Server with OpenDirectory and open up the Directory Utility, which can be opened and found via Spotlight.
  25. Once open, click on Directory Editor
  26. Select the correct Directory to edit from the drop-down, usually /LDAPv3/ for example, this will be your main directory.  It might not be, but make sure when you select the proper node that a list of users is presented when you select the users drop-down in the editor, like this:

    Directory UtilityDirectory Utility
  27. Authenticate as the diradmin by clicking the lock icon at the top
  28. Once authenticated, you can begin to admen the user objects and add important attributes to the user object.
  29. There are ways you can have these added by default, but this guide is not designed to show you how to amend your LDAP directory structure.  However, it is possible to do this, such that phone numbers, mobile numbers, and other Centrify Cloud platform attributes are default inside the user objects
  30. Click the "+" sign and search for MobileNumber or PhoneNumber and then enter in the value you want reflected in the field
  31. Once you add these attributes, they will automagically show up in the user object in the Centrify Platform after you reload the user object.  You can refresh the user object in the Centrify Portal by select the user in the admin portal, and then from the action menu selecting "reload" and the user object will populate with the data you added in the directory utility on the MacOS server: 

            Reload a User ObjectReload a User Object
  32. Keep in mind, we can use our LDAP browser to connect to an Active Directory domain and view the various user attributes in AD that are stored for the user and add those same attributes to the users in OpenDirectory. It's not a hard process, the trick is to configure OpenDirectory to have those fields in the user creation process, which can be difficult to do.  That said, the attributes are all common to all LDAP directories, as such, you can add these to the Mac OpenDirectory Server user object and have them reflected in the user object in the cloud.

This concludes the OpenDirectory Integration guide for the Centrify Identity Platform.  We try to make our solution open to all sources of truth, and many companies use OpenDirectory as their directory of choice. Good luck and thanks for reading.

The Centrify IWA root CA certificate is required for silent authentication into the Centrify User Portal or Admin Portal, and for computer MFA login. This article will walk through the steps for downloading the IWA root CA certificate for deployment.


Prerequisite: Install the Centrify Connector on a 64-bit system or VM inside your network.


1. Log into the Centrify Admin Portal. On the left column, navigate to Settings  > Network > Centrify Connectors.



2. Click on the name of any Centrify Connector listed in the right pane. The Centrify Connector Configuration window will popup. 



3. In the Centrify Connector Configuration window, click on IWA Service, then click on Download your IWA root CA certificate

download IWA root certificate.png


Make sure you select the link "Download your IWA root CA certificate" and not the Download button above the link.



 Next: Deploy the Centrify IWA root CA certificate using group policies


Here is a video on how to do it

Related article: [Howto] Spotting and Remediating issues with PKI Trust on MFA (UNIX/Linux/Windows) or Enrollment

[HOW TO] Setup a Centrify Identity Services for AWS tenant

By Centrify on ‎12-29-2017 01:56 PM - last edited ‎01-19-2018 10:42 AM



This visual step by step blog post to cover the setup of a new AWS tenant.  







Step 1) login into AWS Marketplace and search for Centrify. 


Screen Shot 2017-12-14 at 2.00.39 PM.png


Step 2) In the Centrify page select continue. Please note the pricing details as these may be different.


Screen Shot 2017-12-14 at 2.00.54 PM.png


Step 3) On the next page select using the Subscribe button.  


Screen Shot 2017-12-14 at 2.25.34 PM.png 


Step 4) Congratulations. Click the Setup your account. 


Screen Shot 2017-12-14 at 2.25.45 PM.png

Step 5) You will receive an email with your Administrator account information.


Screen Shot 2017-12-29 at 2.44.38 PM.png

Step 6) Click the link in your email and use your login information form the email.


Screen Shot 2017-12-29 at 2.05.51 PM.png


Step 7) Login and change your password.


Step 8) Enjoy.















AD Bridging & Kerberos vs PuTTY-CAC


Employee on-boarding, transitions and departures often require manual and time consuming user administration tasks performed between HR and IT. Generally, identity originates in the HRIS system when the candidate becomes an employee. Coordinate between HR to IT is done such that, IT can create accounts for the new hire in Active Directory and every application required for their job. Similarly, during a transitin or departure, HR coordinates with IT to modify or disable access in Active Directory and every application. 


With an integration to Centrify, Workday can serve as the master employee database within the enterprise. New hires, transitions and departures are managed by HR within the HR system while Centrify automatically provisions or de-provisions accounts into Active Directory and downstream productivity applications. Specific benefits include: 


  • Automatic provisioning of new hires in Workday to Active Directory.
  • Randomly generated Active Directory password automatically emailed to new hire.
  • Automatic account updates (e.g. promotions, department changes) of employees in Workday to Active Directory.
  • Automatic disablement of users in Active Directory when terminated in Workday.

Here is a demo video of how the integration can help streamline user administration in your enterprise: 



See this work within your environment by registering for a free 30 day trial here.

After Preparing for your Privilege Management Deployment with the Centrify Infrastructure Service - Part 1, you will want to configure your Active Directory connection and start considering your network environment.



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 - https://www.centrify.com/free-trial/


-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. Go here to set conditions for logging into the Centrify User or Admin Portal. The conditions to require mult-factor authentication or block access 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  ad.user.name /Users/homefoldername 
      1. In the above command, replace "ad.user.name" 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 ad.user.name 
    1. Again, replace "ad.user.name" 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!


Showing results for 
Search instead for 
Do you mean 

Community Control Panel