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 Manager
Applying 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?
Background reading on Active Directory permissions
The answer to the above question, requires some understanding to how delegations are stored in Active Directory, and in particular how it relates to delegation on objects in a Centrify Zone.
Objects in Active Directory have an ntSecurityDescriptor attribute, which holds information on the owner, group, DACL and SACL of the object.
As mentioned in the introduction, permissions are stored in the DACL. An object's DACL can contain multiple Access Control Entries (ACEs), which each grant or deny permissions on the object, or its containing objects.
SACL stands for System Access Control List, and its entries help determine how access to, and modification of an object, gets audited on Active Directory domain controllers). SACLs will not be discussed in this particular blog article, but will be in a future article centred around auditing Zone Objects.
Generally, to visualize DACL contents in Active Directory, one of the following methods can be used:
- Active Directory Users and Computers MMC (dsa.msc)
- adsiedit.msc MMC
- PowerShell CMDlets (Get-Acl, Get-ADObject)
- Third party AD permission auditing/visualization tools
Of the above options, Active Directory Users and Computers generally only shows the most common type of permissions, and hides the less common type of permissions.
While adsiedit.msc shows all permissions, it is cumbersome to use, as each ACE has its own view containing all available permissions, where the applied ones show up as checked options. This takes a long time to navigate, and it is easy to overlook a checked box in the list of permissions.
In PowerShell, the Get-Acl or Get-ADObject commands provide the raw ACEs in the DACL, which contain objects that have raw GUIDs as value for ObjectType and InheritedObjectType attributes, and SIDs for built-in objects are shown as value for IdentityReference. Without parsing these ACE object values, it is hard to interpret the delegations in place on an Active Directory object.
An ACE in a DACL, as retrieved with either Get-Acl or Get-ADObject
For the above reasons, it is not uncommon to use third party tools to visualize Active Directory permissions.
Visualizing Centrify Zone Delegations
How does the above information on DACL and their ACEs, relate to validation of Centrify Zone delegations?
Centrify Zone data is stored using a variety of objects, including (but not restricted to): serviceConnectionPoint, msDs-AzAdminManager, msDs-AzOperation, msDs-AzTask, msDS-AzRole, msDS-AzApplicationData, msDS-AzScopeName and classStore objects.
These objects are stored inside the Centrify Zone structure, which contains at its base, a Centrify Zone container (or organizationalUnit !), which may hold the following objects:
- an msDS-AzAdminManager object named 'Authorizations'
containing a structure holding a variety of objects, that taken together, describe all the UNIX authorizations in place on the zone (including computer roles and their authorizations, as well as authoriaztions for managed computer zones)
- a container object named 'Computers'
containing serviceConnectionPoint objects that represent computer profiles, as well as container objects for each manage computer zone (that in turn contains its own Users, Group, LocalUsers and LocalGroups container, for profiles specific to a computer).
- a container object named 'Groups'
containing serviceConnectionPoint objects that represent UNIX group profiles
- a container object named 'LocalGroups'
containing serviceConnectionPoint objects that represent UNIX local group profiles
- a container object named 'LocalUsers'
containing serviceConnectionPoint objects that represent UNIX local user profiles
- a container object named 'NisMaps'
containing container objects for each NIS map, which in turn hold classStore objects that represent NIS map entries
- a container object named 'Users'
containing serviceConnectionPoint objects that represent UNIX user profiles
- a container or organizationalUnit object for each child zone of the Centrify Zone
a child zone in turn can contain any and all of the above objects
Zone contents as visible in ADUC
Zone delegations on the above Zone structure, are translated into specific DACL ACEs on one or more Active Directory objects inside this structure.
For example, to delegate creation of new UNIX user profiles:
An ACE is added to the DACL of the 'Users' container, that is a child of the Zone container. This ACE would contain a permission to allow a user or security group to create serviceConnectionPoint objects.
An exhaustive list of permissions for delegation of zone control can be found in the chapter "Active Directory permissions required for administrative tasks" of the Centrify Server Suite 'Planning and Deployment Guide' ('centrify-unix-deployment-guide.pdf').
Due to the nature of different objects in the zone structure receiving ACEs, depending on the task that is delegated, it is not easy to visualize them in a single view. For example, right-clicking a zone in the DirectManage Access Manager, and selecting the 'Permissions' button, will open a window similar to the standard DACL view of the zone container in Active Directory Users and Computers. If creation of user profiles has been delegated on the zone, no ACEs will be present in this view to visualize that delegation, as this delegation only results in an ACE on the Users child container object of the zone.
Zone Permissions window in Access Manager
Clearly, retrieving the delegations on all objects inside the zone structure, using Get-ADObject, Get-ACL or a third party tool, would be a better approach to determine the zone delegations in place on the specific Centrify zone.
However, using the above tools, would not separate the ACEs representing zone delegation tasks, from default permissions in Active Directory that don't impact Centrify zone tasks, and that are either applied on new objects, or inherited from parent object.
Additionally, mapping ACEs to actual zone delegation tasks would still be a manual process, requiring the information from the above-mentioned chapter in the Planning an Deployment Guide to interpret the results.
Retrieving delegations with Centrify.DirectControl.PowerShell
Instead of walking the route of manually interpreting the ACEs, Centrify provides the Get-CdmDelegation and Get-CdmEffectiveDelegation CMDlets to visualize the explicit and effective Zone delegations on a Centrify Zone.
Get-CdmDelegation retrieves all explicit delegations on a zone, and its output can be filtered for a specific user or security group, using the standard PowerShell pipeline filters such as Where-Object.
Output of Get-CdmDelegation for a specific AD user
However, we're usually more interested in what the effective delegations are, taking into account permissions inherited from objects higher up in the Active Directory structure, or through membership of groups that have zone delegations. The Get-CdmEffectiveDelegation CMDlet provides this information:
Effective Zone Delegations for user tetsu, retrieved with Get-CdmEffectiveDelegations
For example, in the above screenshot, the zone permissions for user 'tetsu' are visualized. The list of delegations is the result of the user having been granted 'full control' on the parent container of the 'Corporate Global' zone container.
Currently, only users can be specified as target of the Get-CdmEffectiveDelegation. This means when validating the delegation model as applied to security groups (RBAC !), we need to temporarily add a dummy user account to each of the security group whose zone delegations need to be validated.
When implementing and validating zone delegations, please also take the following information into account:
- The object owner (as specified in the object's ntSecurityDescriptor) has full control on the object. Make sure to clean up object ownership of any personnel that changes role within your organization, in order to take away the implicit object ownership permissions.
- A simple method to allow fixing object ownership, is to grant the 'Take Ownership' permission on all zone objects to members of a security group that already have full control over zone objects. 'Take Onwership' only allows changing object ownership to one self.
- Less importance poses object ownership by personnel whose Active Directory account has been deleted (e.g. after they have left the organization). In this scenario, object ownership will become orphaned, and will not have any consequences when a proper zone delegation model (RBAC) already is in place.
- The user performing zone delegations, needs to have permission to write DACL entries on the target object of the delegation.
- The ability to create zones implicitly covers many other zone delegations. Additionally, creation of a zone, provides full control over that zone to its creator. For this reason, only allow the Centrify solution owners to create new zones, or other teams that have equivalent permissions.
- Knowledge of the underlying Centrify zone structure, allows for custom zone delegations that are not in the list of predefined delegation tasks. For example, you can manually delegate the ability to modify one or more specific UNIX profiles, NIS maps, NIS map entries, etc.
Centrify stores its UNIX identity and authorization data in Active Directory. As a result, delegations to manage Centrify Zones are applied as Access Control Entries in DACLs of zone objects.
The Get-CdmEffectiveDelegation CMDlet, provided by Centrify as part of the Centrify.DirectControl.PowerShell module, can be used to take a snapshot of the effective zone delegations in place.
Centrify Professional Services can help customers design, validate and implement a Zone Delegation model, identify an existing zone delegation model (for example, as part of a Health Check), and help remedy any issues detected with a zone delegation model or residual ownership of zone objects by users no longer in charge of managing the Centrify solution.