Background
In a previous posts we discussed what's in a UNIX profile, we have also discussed the concepts behind Centrify Zones, how Active Directory users can be UNIX-enabled using Centrify and what are some of the considerations and strategies for UNIX identities; the problem has been that our labs have been focused in manual Identity manipulation.
The reason for this is simple: understanding the basics is establishes the best foundation to address complex issues; but since we have gone over man manual scenarios, in this posting we will discuss automatic provisioning with the Zone Provisioning Agent (ZPA) utility. The rest of the labs will use ZPA with a rationalized namespace.
Why Exceptions are Bad
In IT infrastructure, Security as well as in Identity and Access Management, designers need to strive for standardization and simplicity; sadly the reality is that organizations are complex today because problems are addressed in a reactive matter and rarely the root cause of issues are addressed, instead, organizations throw technology and resources at the problem.
Getting to a standard Identity Provisioning process is hard and the most challenging part is the ability to make the process standard and repeatable enough that exceptions are almost eliminated. Exceptions introduce overhead and unnecessary risk; any system administrator with a certain degree of experience knows this and the sad thing is that some of them have figured out that complexity keeps them employed and enjoying the status quo.
Exceptions = More complexity = More stress = More work = More cost = Lower Satisfaction
In addition, to be completely fair, not all organizations can afford to completely aim and then shoot. This is why solutions need to allow a certain degree of flexibility.
Centrify Zone Provisioning Agent
The Zone Provisioning Agent (or ZPA) is a utility included with Centrify Standard Edition that allows the automatic provisioning of UNIX identities leveraging Active Directory Security groups.
Yes, we get to reuse the same process again.
ZPA waits a preset number of minutes and searches in Active Directory for provisioning groups, and based on the zone defaults, will automatically UNIX-enable a user.
ZPA is implemented as a Windows Service or it can be run as a command utility called zoneupdate.exe.
Zoneupdate provides an interface to work with scripting or Identity Management solutions.
Like any other solution, ZPA has to subscribe to the Plan-Do-Check-Model.
Planning for ZPA
- Understand the impact of ZPA - once a zone has been enabled for automatic provisioning, AD users can't be UNIX-enabled manually, overrides are still possible at the zone, child zone and system levels. The unavailability of manual provisioning, stresses that the process has to be clean of major exceptions.
- Determine how you're handling the Unix Name (RFC 2307 uid attribute). This is important because some UNIXes need to be enabled for long name support and you may have naming conventions to consider.
- ZPA allows to handle any exceptions on the settings for the UNIX name.
- ZPA can use any attribute stored in the user object as the RFC2307 uid field, therefore if you have any scripts, IdM solution, etc that make transformations and write them into this field, they can be leveraged by zpa. The default is the AD username: ${u:sAMAccountName}
- ZPA requires a master provisioning AD security group per zone; this means that we need to create and populate an AD Security group with the users that require provisioning.
Sample Design (Nested Groups):
You can leverage Active Directory group nesting to kill two birds with one stone. For example: Jeremy is a member of the UNIX Database Servers Users group; since this group grants the role in the appropriate number of systems, we can safely assume that he requires a UNIX profile, so if we have a Provisioning group called UNIX All Users, all we need to do is nest the role-granting AD group in to the provisioning group.
This design simplifies operations because either manually, programmatically or by virtue of using an Identity Management tool, adding or removing the user to the role-granting group, has the effect of provisioning or deprovisioning access. - ZPA high-availability: All services need to be planned with HA in mind. Running multiple ZPAs is not uncommon.
- Planning for Exceptions: In this model, Centrify allows for identity overrides at the child or system levels.
- Planning for Migrations from existing Manual to ZPA zones: In this case, the brief moment in which the accounts won't be available has to be accounted for.
All users will lose their UNIX identities until the next polling interval kicks-in. If well planned, this should be negligible in a medium to small environment.
Implementing ZPA (Do)
To Implement ZPA, at a high level:
- Create the Provisioning group and populate it with the appropriate users and/or groups.
If using the model outlined above, nest the role-granting groups into the provisioning group. - Request an Active Directory service account to run ZPA.
- Delegate the proper permissions for Users (or Groups) for ZPA to be able to perform the functions desired.
- Install ZPA in a highly-available system.
Note: If it hasn't been done, your existing Access Manager consoles have to be extended with ZPA setup to have the Provisioning tab enabled.
- In Access Manager Configure the zone for automatic provisioning (if this zone had users, the UNIX-identities will be deleted)
- Configure the account and the polling interval for ZPA
(You may need to make sure that the service account has the proper log on locally rights) - When the service starts, all identities will be provisioned.
Verifying the Implementation (Check)
- In Access Manager, verify that all UNIX Identities are accounted for.
- In the UNIX systems, make sure that after an adflush all users for the corresponding system are accounted for.
- Add a user to one of the role-granting groups. Trigger a polling interval. Verify that the user has a UNIX identity.
- Remove the user from the role-granting group. Trigger a polling interval. Verify that the user has lost his UNIX identity.
Adjusting the ZPA Implementation
There are multiple reasons to adjust a ZPA implementation, but the most common are:
- Provisioning SLAs: Provisioning is composed of multiple parts: from user creation or provisioning, to workflow/approvals, AD-replication, cache-flush intervals and now ZPA. The polling interval may need to be adjusted for Service Level Agreements.
- Performance: Network, domain controller availability, etc.
- Availability: Redundancy, etc.
Videos on setup here: http://centrifying.blogspot.com/2014/01/labs-centrify-zone-provisioning-agent.html
Zoneupdate Help
Usage: ZONEUPDATE [options] zone1 [zone2 zone3...] Options
/z|SourceZone:Path
Copy user attributes from the source zone (specified in canonical name format, for classic zone only).
Copy user attributes from the source zone (specified in canonical name format, for classic zone only).
/d|Domain:DomainName
The FQDN of the target domain.
The FQDN of the target domain.
/dc|DomainController:DomainControllerNameThe target domain controller to connect to.
/u|UserSource:ADGroup[@domain]
The AD group used to populate the users in the zone.
/g|GroupSource:ADGroup[@domain]The AD group used to populate the groups inthe zone.
/uu|UserUid:<Option>
The method to generate the UID for a user profile. Option can be one of the following values. Auto is the default if this option is not specified.
The method to generate the UID for a user profile. Option can be one of the following values. Auto is the default if this option is not specified.
/us|UserShell:<Option>
The method to generate the UNIX shell for a user profile.
Option can be one of the following values.
/uh|UserHomeDirectory:<Option>
The method to generate the home directory for a user profile.
Option can be one of the following values.
/uc|UserGecos:<Option> (For hierarchical zone only)
The method to generate the Gecos in a user profile.
/gg|GroupGid:<Option>
The method to generate the GID for a group profile.
/gn|GroupName:<Option>
The method to generate the UNIX name for a group profile.
Option can be one of the following values. SamAccountName
is the default if this option is not specified.
Methods:
SamAccountName is the default if this option is not specified (for login, UID, GID).
Auto is the default if this option is not specified.
Auto - Auto-generate from the AD group's SID.
RFC2307 - Group's AD RFC 2307 gidNumber attribute.
ZoneDefault - The GID of this group in the default value zone for the target zone. Use the next GID of the target zone if the default value zone is not available.
SourceZone - The GID of this group in the source zone.
(for classic zone only)
<Empty> - Leave empty option for undefined GID.
(for hierarchical zone only)
/v|Verbose Verbose output messages.
/p|Preview Preview only. No provisioning changes will be made.
/l|Log:<Level>
Turn on the log file. The log file will be created in'C:\Documents and Settings\<CurrentUser>\Application Data\Centrify\Zone Provisioning Agent\Log'
Log level can be Error, Warning, Information or Verbose.
Example:
zoneupdate /u:"Domain Users" /g:"Domain Users" /d:centrify.dev zone1 zone2
No comments:
Post a Comment