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.


Best practice for security questions

By Centrify Advisor III 3 weeks ago - last edited 2 weeks ago

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




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.

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.

custom login screen.png

Using a custom Centrify login URL offers a number of benefits, inlcuding branded login screen, Integrated Windows Authentication, and being able to log in using your short name or samAccountName. This article will walk you through configuring your custom login URL for your Centrify tenant.


1. Log into your Centrify Admin Portal.

2. In the left column, navigate to Settings > Customization > Tenant URLs, then click on the Add button.


3. Enter your preferred unique name that is not used by another Centrify customer, then press Save. For example

custom name.png


Once this is complete, you can log into the Centrify portal with your custom login URL.

Centrify User Portal:

Centrify Admin Portal:



By default, Centrify automatically populates the username field with the User Principal Name for SAML web logins. However some web logins use first name space last name (eg. John Smith) instead of the full UPN format (eg. 


To configure your web app in Centrify to autopopulate with the user's first name (space) last name:

1. Edit your web app and go to Account Mapping.

2. Select Use Account Mapping Script and enter the following into the script field:


LoginUser.Username = LoginUser.FirstName + " " + LoginUser.LastName;



3. Press Save.



Related articles:

How to configure Centrify to use short name or samAccountName for web application login

Signed and Sealed - "Why port 389?"

By Centrify Contributor II ‎09-11-2017 09:56 AM

"Why port 389?"


A customer recently emailed me asking a few questions about the Unix agent communication security with Active Directory


  1.  "Why does the Centrify Unix agent (adclient) communicate with Active Directory over port 389?
  2. How is this communucation secured?
  3. What are the implications to Active Directory? Specifically, how do we protect Active Directory against unsigned/unencrypted LDAP requests?"


Typically, this question tends to come from Security/Compliance and Unix teams. From their vantage, interacting with LDAP over 389 raises a flag, where traditionally communications over this port tend to be unencrypted.  If the question comes from the Active Directory team, they are usually looking for confirmation and assurance that our interactions with Active Directory align with best practices and their secrity expecations.


1) Why port 389: The short answer is that the Centrify Unix agent's approach/design is consistent with how Windows computers and services securely communicate with AD and other kerberos principals. Explained below…
2) Secure Active Directory communication: The Centrify Unix agent authenticates and encrypts all communications with Active Directory using Kerberos (GSSAPI). This is referred to as a "signed and sealed" connection. The agent encrypts its payload using a kerberos session-key before sending over the wire to Active Directory. We do not use LDAP over SSL/TLS. This approach depends on certificates (along with the certificate management headaches that come with).  
3) Rejecting unsigned/unencrypted LDAP requests: Microsoft advises we configure servers to reject Simple Authentication and Security Layer (SASL) binds that do not request signing or reject LDAP simple binds that are performed in the clear. This AD group policy configuration ensures that “non-kerberized” LDAP client requests communicate with AD over SSL/TLS (e.g. Port 636). The following Microsoft article explains further. 

Integrating Active Directory with the Centrify Identity Platform allows you log into the Centrify Admin Portal with domain credentails. This article will walk you through the integration and System Administrator role assignment.


1. Integrate Active Directory with the Centrify Identitly Platform

Install the Centrify Connector on a 64-bit Windows member server. See instructions. Once the Centrify Connector has been installed, all domain users will now be able to log into the Centrify User Portal with domain credentials. To grant permissions to log into the Admin Portal, you will need to add the domain user(s) or group(s) to the System Adminstrator role or any other role with administrative rights.


2. Add domain user(s) or group(s) to the System Adminstrator role

a) In the Centrify Admin Portal, go to the left column and navigate to Core Services > Roles.


b) Click on the System Administrator role. 

c) Select Members then click Add and search for your desired domain user(s) and/or group(s) that you want to grant administrative rights to the Centrify Admin Portal.


Now you can log in with your domain credentials to the Centrify Admin Portal.

Step 1. Use Apple Configurator 2 to create the desired WiFi setting, then export the profile.

1. Launch Apple Configurator and select File > New Profile.

2. Enter a display name for the profile in General. 

3. In the left column, select WiFi, click the Configure button, then enter your WiFi settings.

4. Once you have completed your configuration, go to File > Save.


Step 2. Upload the saved mobileconfig profile into your domain controller: \\yourdomain\SYSVOL\yourdomain\mobileconfig Create this directory if it does not exist.


Step 3. Specify the profile in one of the following GPO settings to apply the WiFi settings:

  • Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Custom Settings > Install MobileConfig Profiles or
  • User Configuration > Policies > Centrify Settings > Mac OS X Settings > Custom Settings > Install MobileConfig Profiles



For more details on computer configuration or user configuration.


Other settings to consider:



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.


Your Centrify Privilege Service (CPS) deployment could go a lot smoother with this checklist. This checklist is a high overview of the necesarry tasks to prepare, deploy, configure, and validate a CPS environment.


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




We heard from some customers that would like to use AD credentials to authenticate to IBM Sterling Connect:Direct. IBM Sterling Connect:Direct provides security-rich, point-to-point file transfers to lessen dependency on unreliable File Transfer Protocol (FTP) transfers.


Continue reading...


This Cheat Sheet should be used with Centrify Mac Agent version 5.2.4 and higher.


The Centrify Mac Diagnostic Tool location:
/Library/Application Support/Centrify/



Centrify Agent


To join the domain in Auto Zone:
sudo /usr/local/sbin/adjoin --user domain_admin_username --workstation


To join the domain in Zone mode:
sudo /usr/local/sbin/adjoin --user domain_admin_username --zone zonename


To leave the domain and disable the computer object:
sudo /usr/local/sbin/adleave --user domain_admin_username 


To leave the domain and remove the computer object:
sudo /usr/local/sbin/adleave --user domain_admin_username --remove


To leave the domain and leave the computer object untouched in Active Directory:
sudo /usr/local/sbin/adleave --user domain_admin_username --remove


To print information for the domain:


To print network diagnostic information for the domain:
sudo /usr/local/bin/adinfo --diag


To view licensing mode:



To enable licensed features:

sudo /usr/local/sbin/adlicense --licensed


To look up an Active Directory user's information:

/usr/local/bin/adquery user -A username


To look up an Active Directory computer's information:

/usr/local/bin/adquery user -A computername$


To look up an Active Directory computer's Manager (managedBy attribute used with FileVault policy):


/usr/local/bin/adquery user -b managedBy computername$


To look up an Active Directory group's information:

/usr/local/bin/adquery group -A groupname


To change the currently logged in user's Active Directory password:



To change an Active Directory user's password:

/usr/local/bin/adpasswd --adminuser domain_admin_username


To flush the Mac agent cache (Active Directory users will need to login again to cache their credentials after this is ran):

sudo /usr/local/sbin/adflush


The location of the Centrify configuration file:


The location of Centrify Kerberos tools:


To restart the Mac agent:
sudo /usr/local/share/centrifydc/bin/centrifydc restart 


To turn on logging:
sudo/usr/local/share/centrifydc/bin/cdcdebug on


To turn off logging:
sudo/usr/local/share/centrifydc/bin/cdcdebug off 


To clear out the current log file:

sudo/usr/local/share/centrifydc/bin/addebug clear

Log file location:


To uninstall the Mac agent:
sudo /usr/local/share/centrifydc/bin/


To uninstall silently:
sudo /usr/local/share/centrifydc/bin/ --std-suite



Group Policy


To force group policy updates for both user and machine policies:


To update group policy for user policies only:
/usr/local/bin/adgpupdate --target User


To update group policy for machine policies only:
/usr/local/bin/adgpupdate --target Computer


To view the curent set group policies:



To view the curent set user group policies:

/usr/local/bin/adgpresult --user username


To view the curent set machine group policies:

/usr/local/bin/adgpresult --machine


The location of computer group policy reports:


The location of the user group policy reports:


The location of login scripts:



To retrieve machine certificates:
sudo /usr/local/share/centrifydc/sbin/adcert --machine --keychain


To retrieve user certificates:
/usr/local/share/centrifydc/sbin/adcert --user --keychain


The location of machine certificates:


The location of user certificates:




Directory Services


To see if the machine is joined to the domain using the Apple plugin:
/usr/sbin/dsconfigad –show


To unbind from the domain using the Apple plugin:

sudo /usr/sbin/dsconfigad –remove -username domain_admin_username


To list all of the users in the Directory Service and in Active Directory for the zone:
/usr/bin/dscl /Search -list /Users


To list only the Active Directory users enabled for the zone:
/usr/bin/dscl /CentrifyDC -list /Users


To display detailed information about the specified Active Directory user:
/usr/bin/dscl /CentrifyDC -read /Users/username


To list all of the groups in the DirectoryService and in Active Directory for the zone:
/usr/bin/dscl /Search -list /Groups


To list only the Active Directory groups enabled for the zone:
/usr/bin/dscl /CentrifyDC -list /Groups


Command to display detailed informationa bout the specified Active Directory group name:
/usr/bin/dscl /CentrifyDC -read /Groups/groupname





To see if FileVault is enabled:

/usr/bin/fdesetup status


To list FileVault enabled users:

/usr/bin/fdesetup list


To disable FileVault:

sudo /usr/bin/fdesetup disable


To add a local or mobile account to the FileVault user list:

sudo /usr/bin/fdesetup add -usertoadd username



Smart Card


To see if smart card support is enabled: 
/usr/local/bin/sctool --status


To enable smart card support: 
/usr/local/bin/sctool --enable


To disable smart card support: 
/usr/local/bin/sctool --disable


To dump out all the certificates and Active Directory information present on the smart card:

/usr/local/bin/sctool --dump


To get a new kerberos ticket: 

/usr/local/bin/sctool --pkinit


Related Articles:


A Centrify Server Suite Cheat Sheet

Centrify provides an account migration tool that simplifies the process of converting a local account's home directory into the Active Directory account. Migrating the account helps to save the user's files, application settings, and browser bookmarks.


Using local MacOS administrator accounts can lead to security and compliance issues such as unauthorized sharing of the administrator password with non-administrators or remote access by a former employee. The secure approach is to grant Active Directory users Mac administrator rights to minimize risk and meet regulatory compliance. This article will show you how to grant Mac administrator rights to Active Directory users through Centrify's Active Directory group policy settings.


 1. In Group Policy Management, create a GPO and enable: Computer Settings > Policies > Centrify Settings > Mac OS X Settings > Accounts > Map zone groups to local admin group




   a) Click on the Add... button. A new window will appear.




   b) Click on the Browse button. A new window will appear. You can enter manually enter a group name in this window but it is better to browse and select the group to ensure the proper group name is entered.



Selecting Group.png


   c) Enter a keyword into the Name field for the Active Directory group that you want to add, then click on Find Now. Make sure you add IT/helpdesk team and any user that needs admin rights on the Mac.


type group name.png


   d) Select the desired group name and click OK.


Select desired group.png


The setting will apply when the user logs out and logs back in.


If your Mac is using Zone mode, use the following article:



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


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


Validating Centrify Zone Delegations

By Centrify Contributor II on ‎01-06-2017 07:06 AM

One of the major strengths of Centrify Server Suite, is that all UNIX identity and authorization data is stored as Active Directory objects in Centrify Zones. As a consequence, delegation tasks of zone management, are stored in Discretionary Access Control Lists (DACLs) on Centrify Zone objects in Active Directory.


The Zone delegations can be implemented using PowerShell (for example, using the Set-CdmDelegation PowerShell CMDlet, which is included with the Centrify.DirectControl.PowerShell module), or by using the 'Delegate Zone Control' context menu option in the Centrify DirectManage Access Manager console. Either method will provide you with the ability to chose from a list of a granular zone delegation tasks, that can be delegated to an Active Directory user or security group.



List of zone delegations in Access ManagerList of zone delegations in Access Manager

Applying zone delegations using the Centrify PowerShell CMDletApplying zone delegations using the Centrify PowerShell CMDlet 

As part of an engagement, Centrify Professional Services can aid you to conceive a delegation model using a RACI matrix, and implement the resultant zone delegations. This allows for implementing least privilege, where (for example) the service account for the zone provisioning agent can only add/remove UNIX profiles to/from a zone, but nothing more than that. If the ZPA service account gets compromised, it cannot be (ab)used to modify UNIX authorizations.


A returning question from customers during these engagements is: How can we validate that the delegations that have been implemented, are actually in place?




This article details the methods available to implement zone delegations, and how zone delegations can be validated.


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.


Centrify's cloud platform, the Identity Service, can be configured to allow users to unlock their Active Directory accounts from the User Portal. The user is able to unlock their account without any administrator interaction, thus relieving the tasks that your system administrators and helpdesk team performs.


Si su empresa tiene contemplado migrar su correo a Office 365 o si es un cliente actual de Office 365 y está sufriendo con los problemas de sincronización de usuarios, este artículo es para usted.


Centrify's Mac agent has an installation script that can be used to fully automate not only the install, but also the AD bind process. This can be helpful for automating Centrify agent deployments in imaging processes or other third-party deployment tools. 


[Mac] Logon banners for SSH

By Centrify Contributor II ‎09-12-2016 11:50 AM

Have you ever wondered if you can enable SSH logon banners for Macs, just as you can for UNIX/Linux?  With Centrify you can!  


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.


A common category of questions we get from Centrify prospects and customers is around UNIX identity storage and options for sourcing.  The most frequent is:  How do we get UNIX identity data to your solution?

I typically tend to answer:  Where does your UNIX identity data resides?
The answer to this question varies.  I've heard all kinds of responses, including silence or arguments between team members.  Ultimately it boils down to two categories:


Rationalized(*) Not Rationalized
  • There is a naming convention established and the convention is enforced
  • A directory may or may not be in place  (e.g. LDAP, NIS, etc)
  • Every user has a unique login, UID and Primary Group
  • Every UNIX group is defined with the same unix-name and GID, has the same meaning and group members
  • There is typically a unified strategy for multi-protocol filers
  • There is a unified (or centralized) sudoers files
  • The naming convention is spotty or non-existent
  • A directory may or may not be in place  (e.g. LDAP, NIS, etc), but there are pockets of "other stuff"
  • Users may have different naming for login or different UIDs  (e.g. jdoe (501:501) vs john.doe (10001:1)
  • Groups may have different unix-names, different GID numbers, members or meaning.
  • Centralized sudoers files may or may not exist or contain outdated information.

(*)Note: "Fully-rationalized" is typically an aspiration.  Organizations may have historical or legacy reasons as of why they may keep older systems that do not conform to the standards (and yes, Centrify has you covered).


Other questions that follow are:  Will you be using the SFU or RFC2307 fields? What are these zones that you speak of and what are the AD implications?  Can you make use of my existing UNIX information?  How painful (or painless) will the process be?


The answer to the last question varies between organizations.  Some organizations believe the process will be cumbersome and choose to continue with the status-quo (after all, their problems are well documented); others make the painful decision to not get help or training (a decision that really baffles me).


This article explores the different schemas used by Centrify Zones and provides an overview of sourcing options. The topic is very relevant due to the following facts:

Having a solution that provides flexibility, especially in such an important capability that is the foundation to secure critical systems is key for large enterprises.  Let's get started.



  • UNIX identity data consists of login, UID, GID, Home Directory, Shell and GECOS.
  • Centrify Zones leverage Active Directory to provide Identity Management for UNIX, Linux and Macs and Role-Based Access Control + Privilege Management for UNIX, Linux and Windows.

UNIX identity may reside on:

  • Local /etc/passwd and /etc/group files on each individual system (could be the same for /etc/sudoers)
  • Network-based passwd and group files on LDAP or legacy NIS directories (same for /etc/sudoers)
  • In Active Directory in the msSFU30 fields (pre-Windows 2003R2) or the RFC2307bis (after Windows 2003R2) and are attributes of the posixAccount class.
  • In other LDAP-like directories that rely on synchronization (e.g. Oracle, Red Hat, Apple or other third party software, etc)


Centrify Data Storage: Zones
Identity data is inside the Centrify Zone.  A Zone is a set of AD objects that consolidate identity and privilege information.  Centrify identity data is stored on a serviceConnectionPoint linked to the user or group object.  This chalk-talk covers this information in detail.


  • Provides the ability to limit the visibility (and access) of users/groups in different contexts.
  • A user (or group) may have different identities in different contexts (especially useful in M&A activities or consolidations)
  • Provides the capability to group systems (teams of servers) using different options
  • Its structure is hierarchical, provides inheritance and object reuse
  • Aligns organizations with the principle of separation of duties
  • Multi-platform (allows the grouping of UNIX, Linux, Windows and Mac systems)
  • Highly-scalable (overcomes the limitations of other schemes like Auto Zone)
  • Provides support for different schemas (SFU, RFC2307) and UID/GID Schemes


Types of Zones and Schemas
Zones can be Classic or Hierarchical.  Because Classic zones are no longer the best practice, they exist for backwards compatibility.  In the rest of this article, a Centrify Zone is always considered to be a hierarchical zone.


Centrify Standard Schema: UNIX attributes are stored in the keywords multi-valued attribute of the user or group's serviceConnectionPoint

standard zone.png

The standard schema was very useful, especially in old Windows 2000 deployments.

Here's how to create a Standard zone using Centrify DirectManage PowerShell:

$cont = "cn=zones,ou=UNIX,dc=centrify,dc=vms"  #substitute with your container DN
New-CdmZone -Name Standard -Container $cont -Schema standard -Type hierarchical

SFU Schema: UNIX attributes are stored with the user or group object and the msSFU30NisDomain is populated based on the zone's NIS domain setting.

sfu zone.png

Using the SFU schema allows the automatic sourcing for all users that have the RFC2307 UNIX fields populated along with the the msSFU30NISDomain attribute.  The drawback is that you must have rationalized your environment and overrides won't be possible (more about overrides below).



$cont = "cn=zones,ou=UNIX,dc=centrify,dc=vms" # substitute for your container DN
New-CdmZone -Name SFU30 -Container $cont -Schema sfu -NisDomain SFUX -SfuDomain centrify.vms -Type hierarchical

When planning to use SFU as a schema, you are bound by the limitations of having the data with the AD object, most notably UNIX names.  You cannot have identity overrides (for example, changing the UNIX name of a group).  This is illustrated below:


RFC2307-compatible schema:  UNIX attributes are stored with the serviceConnectionPoint that defines the user or group.
rfc zone.png



$cont = "cn=zones,ou=UNIX,dc=centrify,dc=vms" # substitute for your container DN
New-CdmZone -Name RFC -Container $cont -Schema rfc -Type hierarchical


Tips on Discovering UNIX Data

Due to the fragmented nature of heterogeneous environments (and the fact that they've been around for a long time), information seems to be all-over the place, but here are many tips.


  • UNIX Identity data in files (/etc/passwd or /etc/group) may have different inconsistencies like:
    • unix users with more than one UID
    • unix users with more than one GID
    • unix users with multiple unix names
    • unix users with different shell or home directories  (e.g. /home/user vs. /exports/home/user)
    • unix groups with more than one GID
    • GIDs with different group names
    • unix groups with different group memberships
    • sudoers files with non-existing groups, aliases or unix names

Identifying this information can help with the identity rationalization process.


  • UNIX Identity data in Active Directory
    • Different schemas (SFU vs RFC2307)
    • Multi-domain forrests with inconsistent NIS domain data
    • AD data that is no longer relevant

PowerShell Discovery Query (RFC2307)

Get-ADUser -Filter * -Properties * | Where-Object {$_.uidnumber -ne $null} | Select-Object  UserPrincipalName, SamAccountName, name, uidNumber, gidNumber, unixHomeDirectory, loginShell | Format-Table 


Conclusion for Part I:

Part of the reason why Centrify has been successful is the flexibility of our toolset, the experience of our Professional Services organization, our willingness to listen to our customers and the consistent investment on the product. 


The benefits of having a unified namespace while using a common infrastructure are critical for security, functionality and productivity.  In the field we still see many organizations struggling with this core concept.  With Centrify enterprises are covered not only on a family of Linux systems, but in critical UNIX systems that run AIX, HP-UX, Solaris, OS X and other commercial Linux distributions.


In part 2, we'll discuss some options on how to source data into Centrify zones using multiple toolsets.

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.




This is the third article in the series titled "A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory" in the previous post we discussed how to secure the Amazon Root account.

In this article we'll discuss how Centrify can secure Amazon Identity and Access Management by leveraging Active Directory or any other supported Identity Source. 


About Amazon AWS Identity and Access Management (IAM)

For those who aren't familiar with Amazon IAM, it provides capabilities that allow organizations to centrally manage Users, Roles, Rights and Policies efficiently for all services (compute, storage, database, application) provided by the platform. 


Another Identity Silo
Each time a new infrastructure or application is introduced, it has the potential to create another identity silo, Amazon AWS is not the exception.  Large organizations often find themselves duplicating effort by managing their own enterprise directory (like AD) and also having to manage the directory out in the IaaS or SaaS provider.
Many of our customers and prospects due to timing of adoption or while developing cognitive knowledge, find themselves manually managing Amazon IAM.  The typical tasks include user creation, credential/password/key management, password resets, group/entitlement management and attestation. The basic IAM best practices are outlined when you log in to the IAM dashboard:




Once we adopt this "dual-management" we are promoting IT fragmentation, the potential consequences are complexity, limited productivity and possible security expose.  Finally, depending on the data classification or risk profile of the assets in AWS, this identity silo is subject to the corporate security policy (password policies, user attestation reporting, least access management, etc.)

In the past few years, Amazon has recognized this challenge and provides vast extensibility to IAM, via APIs and using standards like SAML and OpenID Connect. 


This article provides a practical example that not only meets but exceeds the best practices around Amazon AIM, eliminates dual-administration and aligns administration with internal policies.


During the process of coaching prospects, customers and new employees with Centrify Server Suite there's a lot of information in different places, including the documentation and the man pages. Our pubs team does a great job maintaining those documents.


Just recently, with the release of Suite 2016 Centrify published all the documents in a single zip file, that includes all the man pages for Centrify commands.  Over the years I've maintained my own cheat-sheet and I figured that many community users can benefit from it.  This was asked by one of our posters not so long ago.


Enjoy and I'll try to keep it relevant.


Showing results for 
Search instead for 
Do you mean 

Community Control Panel