Centrify Access Model Best Practices

Proper definition of global/child zone structure.

A proper Centrify deployment should have a Global Zone with an appropriate number of Child Zones and Computer Roles to drive access across groups of systems.  The general recommendation for defining profiles, roles and rights is:


  • UNIX enable all users at the Global Zone level
  • In addition, UNIX enable users at the child zone level, if attributes need to be different for users on the systems in the child zones (ie.different primary group)
  • UNIX enable groups at the Child Zone vs. the Global Zone unless the groups need to be visible across all servers
  • Always enable ZPA to automate UNIX profile provisioning across all Zones that will have user/group UNIX profiles
  • Define Roles and Rights in the Global zone and assign roles at computer roles or zones if appropriate


A common mistake made is the use of too many Child Zones or use Child Zones incorrectly.  Limit child zone sprawl. Child zones should be used for specific purposes like:

    Segregating systems in different business units

    Segregate the management of groups of systems to different administrative groups

    Override the UNIX profiles of users and groups across groups of systems.

Another common mistake is managing roles and rights definition throughout the zone hierarchy which makes it difficult to find roles and rights when updates are needed. 


Another mistake is using Zones to define access.  Instead, use Computer roles to prevent lateral movement, drive an automated access model and to take advantage of performance benefits.  Leverage Computer Roles and AD groups to manage system types by likeness of access and create AD user groups in a similar manner. This promotes automation because user access can be granted access/privileges by simply adding users to the right AD groups. Similarly, systems can be provisioned to the right AD group of computers. Computer roles can be defined by application types. For example, “App 1 DEV” App1 PROD”, etc. The goal is to not have to use the access manager UI for provisioning access.