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.


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

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

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

1. Log into the Centrify Admin Portal.

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


Policy left.png 


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


add rule button.png


   a) Click on the Add Rule button.


add rule too.png


   b) Select the desired filter and condition


condition list.png 


   c) Click on the Add button.


selected condition.png


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


selected condition action.png


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

 default condition profile.png


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

See instructions.




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


Enroll your device into Centrify MDM


Configure your web application

1. Log into the Centrify Admin Portal.

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


Restrict to managed devices.png


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


use script policy.png


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


script sample.png


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


 edit policy script.png


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


default profile.png


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

See instructions.

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:



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



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