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 II, we'll discuss some options on how to source data into Centrify zones using multiple toolsets.

Link: https://community.centrify.com/t5/TechBlog/Basics-Centrify-Zone-schemas-UNIX-identity-data-sourcing-...

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.




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.


With the end of extended support for Windows Server 2003, many organizations are exercising due diligence and upgrading Windows Active Directory systems to newer OS versions. Although this requires thorough planning by your organization, many of our prospects and customers often ask about their current AD changes and wonder about how that impacts systems running Centrify Server Suite for UNIX/Linux or Identity Service Mac Edition clients.  This article is a quick primer on what changes when the Domain Functional Level changes.  We are focusing on the jump from 2003 to 2012 as an example.


Showing results for 
Search instead for 
Do you mean 

Community Control Panel