Basics: Configuring the Centrify Zone Provisioning Service for Automatic Secondary UNIX group provisioning

Background

In a previous posting we discussed how to implement automatic provisioning of UNIX user identities using Centrify's Zone Provisioning Agent (ZPA).
As part of BP#2, one of the key requirements was to implement a provisioning model for secondary UNIX groups and to make it resemble the existing one for users.
This capability consists in the automatic creation of the secondary UNIX group as well as the lifecycle maintenance of members (add/moves/changes).

All the principles applied in the basic posing about ZPA apply here, but in the context of UNIX secondary groups.  Let's apply the Plan-Do-Check-Adjust methodology.

Planning for Secondary Group Provisioning

Is the secondary group needed
The first place to start is to ask "Why is this secondary group required?" -  remember that with Centrify there is no need to have these groups for Access or Privilege purposes, Zones and RBAC take care of all that. In these exercises, the typical answer "Because that's the way is done" is not a good answer so you may have dig deeper.

Naming Conventions
The same rules of UNIX systems apply here as well, but they are a bit more stringent;  the 8 character limit for users is platform-dependent;  the UNIX group case, it may be more of a hard requirement.

Active Directory
Basically the way UNIX Groups work in Centrify is as follows;  there is a security group in AD for each secondary group in UNIX;  the memberships are handled from AD (the process consolidator and time saver), however, governance and processes have to be taken into account.  Questions such as:

1. How are AD Security group are requested today?
2. How is the membership lifecyle managed (add/moves/changes)?
3. Are group memberships subject to any attestation process?

Need to be understood and agreed upon.  

Group Merging

Group Merging is the ability to mix members from other Name Server Switch groups (like /etc/group) with UNIX Enabled AD groups. For example, if an application requires the enumeration of all the members from the software group (UID 200) and the application uses local users (e.g. like the db2inst account) and AD users (like jessie.matthews), then this feature needs to be implemented as well.

Implementing (Do) Secondary Group Provisioning

The process is as follows:

1. Make sure the service account used for ZPA has the proper delegation to add/remove/modify group profiles.  This is done through the Delegation Wizard of the zone.
   
2. An Active Directory "Source" Group is created.
3. ZPA is configured to look at that group as the source group.  For consistency, this group is stored in the OU designated for provisioning 
4. The rules for GID are set, the options are:

• An unique value generated from the group's System ID (SID)
• The RFC 2307 attribute (has to be populated in the object manually or programatically)
• Using the defaults set in the zone (Group Defaults tab)
• Using Apple's scheme (this is new for version 2014)
  
5. The naming rules are set (truncation, character sets, prefixes, etc)
6. Once this is set, ZPA is ready to provision UNIX groups.

Verifying the Implementation (Check)

Verifying group creation:

1. Restart ZPA (so the new zone provisioning configuration is processed)
2. Create an AD Security group.
3. Nest the group (make it a member) of the source group in the previous step.
4. Wait the ZPA refresh cycle or restart the service.
5. Verify that the new group exists under Zone > UNIX Data > Groups.
6. Verify that the group exists in the adequate UNIX systems.  There are several ways:
   getent group | grep <unix name of group>
   adquery group | grep <unix name of group>
7. To verify the group's deletion, just remove the AD group from the source group and cycle ZPA;  the UNIX group will be removed from the zone.

Verifying Add/Moves or Changes

1. Add a user to the previously provisioned group
   Note:  this user needs to be at least listed in the system, otherwise he/she won't show. For example, if the user has a UNIX identity, but only has access to web servers, the user will not show in the Database Servers by virtue of the access rules enforced by Centrify.
2. Wait the ZPA refresh cycle or restart the service.
3. Verify that the user's UNIX name is in the list of users for that group.
   There are several ways:
   getent group | grep <unix name of group>
   adquery group | grep <unix name of group>
4. Remove the user from the AD group (go to step 2) and in step 3 verify that the user is gone.

Performing Adjustments

Adjustments may vary depending on the results.  They can be:

• Adjusting how the GID is generated (or reviewing the provisioning process)
• Adjusting how the UNIX name of the group is generated.
• Adjusting group merging options.