Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >
article

[HOWTO] Setup the Zone Provisioning Agent

25 June,19 at 09:34 PM

This blog is going to do a quick walk through of setting up the Zone Provisioning Agent.
By the end of this guide you will have a zone managed by ZPA and a list of users or groups being auto provisioned on a set interval. 

A few things to know before deciding to implement ZPA:
- Manual provisioning will be disabled for that specific zone. When you right click "Users" under the "Unix Data" section you will see "Add User to Zone..." is grayed out. 
- Manual edits to users already provisioned in the zone will not be modified after ZPA is enabled. Unless the user is not in the "Provisioning Group", the user will be de-provisioned. But more on this later!

Scenario 1) I do not have ZPA installed or configured, I don't even know what ZPA looks like.

The Zone Provisioning agent or ZPA is part of our Centrify Infrastructure Services download package. Navigate to the server where you installed 'Access Manager' and you might realize that you already have ZPA installed. 

User-added image

After install the agent, you can open the Centrify Zone Provisioning Agent Configuration Panel. Let's cover the basics and what each section means.

User-added image

 

The monitored containers and polling interval section:

User-added image

This is one of the trickier sections, but it's not hard. By default it monitors the entire forest, so out of the box you don't have to change this.

But if you want to control this, what this is looking at is the container where your "Zone OU" resides. If you deployed Access Manager and created our "best practice" OU structure then the screenshot below will look familiar.

Pretty much what we want to monitor is the container one level up from where your zones exist. You can see I have several zones under my "Zones" container, so my monitored container here would be the highlighted "Zones" container. (A picture really is worth a thousand words)

User-added image

Best practices would be to simply monitor the "Centrify" OU. But if you decided not to create one because you hate simplicity. Just be sure to monitor the OU or container one level above your zone container. 

Now your polling interval is pretty self explanatory. But it comes with a few "gotchas". This interval is how often ZPA is going to look at your provisioning group and check to see if it has anything to do (add or remove users/groups). The default is 60 minutes.

You can increase or decrease this value, but if you have a very large environment, don't think setting this to 1 minute is going to make things better. ZPA needs time to check the list of users/groups. Setting this interval to 1 minute might restart the process before it can complete. 

So give it enough breathing room to complete it's task :)

The rest of ZPA:

User-added image

Now let's quickly cover the other sections. 

- Event Log section, you control what you want written to Event Viewer. Simple.
-Troubleshooting section, when support needs you to collect logs, this is where you turn it on. 
-Service section, this contains the ZPA service account and shows the status of the agent. If you restart the service, you are simply manually restarting the Polling Interval. So this is a good way to provision users without waiting for the polling interval. 


You keep saying "provisioning group" and "service account", what are these and where do I get one?

A provisioning group is an AD group that will hold the list of users/groups you want to provision. For example, if you wanted to provision every single user in your domain to your zone, you could set the built-in AD group "Domain Users" as your provisioning group. That's an example, don't do that in production. Be more conservative with your provisioning group. But you get the idea. 

The service account running ZPA is a service account that has the rights to Add and Remove users/groups in the zone. So like any other service account it requires the "logon as a service" right.
To grant the Add/Remove rights in the zone follow these steps:
1) Open Access Manager
2) Right click the zone where ZPA will be enabled
3) Click "Delegate Zone Control"
4) Add your service account when prompted by the Delegation Wizard
5) Click Next
6) Check the following permissions
- Change zone properties
- Add users
- Add groups
- Remove users
- Remove groups
7) Click finish

Your service account is ready to rumble.


Okay, I know how this works now. Where do I go to set it up?

Right click the zone where you want to setup ZPA and click Properties. Here you will see a Provisioning tab, this is where we turn on ZPA. Yours will probably show both sections as unchecked, that's the default because ZPA is off. 

Go ahead and turn on, or check the "Enable auto-provisioning for user profiles" like I did below:
User-added image
When you do that, you will get this warning, which is expected. You're telling Access Manager that it is going to control the user provisioning on this zone, so we don't want anyone messing with this manually at the same time and throwing off our rhythm. 
User-added image

Let's check to see if this worked....

My ZPA_User_Provisioning Group has two users:
User-added image

So what does my zone show now after a quick restart of the service? Exactly what I want it to show. 
User-added image

Where did the users get those UID and Primary Group values from?

From the provisioning tab you control what ZPA is going to populate the users UID and Primary Group with. By default ZPA generates the UID from the user SID. This is great because the user SID never changes so if a user is deprovisioned and re-provisioned the UID won't change. We'll cover customizing these values in an Advanced Section down below.


Scenario 2) I already have some provisioned users in my zone but want to have ZPA do that from now on, can this be done? 

Yes, the first step is review the first scenario so you understand how ZPA works. 

Secondly, add all of the users that are already provisioned in the zone to your "Provisioning Group" so that they do not get removed when ZPA is enabled. As long as the users are in the Provisioning Group they will not get touched....and yes nested groups work for ZPA. So that should make your life easier. 


Scenario 3) I have this setup for my users already, but I want my groups to also be provisioned automatically. Is there anything different that needs to be done?

No. That is why we give the service accounts rights to remove both users and groups. Just specify your "Provisioning Group" that contains 'Groups' in the Group section of the provisioning tab and you're good to go. Again, nested groups work here also. 


Advanced Section

Now you might have additional questions that we didn't cover in the section above. 
-I want to change the UID ZPA is creating, how do I do that?
-I have a one way trust, now what?

How to customize the attributes in a UNIX profile:

The most common request is to change the UID of the Unix profile, there are several options (the default being 'Generate from user SID')
 -RFC 2307
 -Use auto incremented UID
 -Use Custom ID
User-added image

Using the default will make your life easier, the reason being that the User SID will not change so the UID will always be the same. So if this is important to you, whether a user gets deprovisioned and then reprovisioned this is a great method to use. Same goes for RFC 2307 and Custom ID. 

The one I would not recommend is "Use auto incremented UID". If a user gets removed by accident, when they get provisioned again, they will have a new UID since it's just going to increase the count by one.


Using Custom ID

If you want to use a Custom ID like an employeeId or uidNumber this is the option for you. These fields get pulled from the AD user attributes field.
User-added image

In my environment I do not have these fields populated in AD so this would fail miserably for me:

User-added image
 

I want all of my users to have the same Primary Group, how do I do that?

This one is simple but we're going to have to jump to two different tabs. The "User Defaults" tab and the "Provisioning" tab. 

First we need to set the "User Default" to set the Primary Group to one of the groups that is provisioned in this zone. So really the first step is to provision the primary group in the zone:
User-added image

In this example, I want all of my users to have "TexasFamilia" as the primary group. So I first need to create the group profile in the zone so a GID is populated. 

Now we set the User Default "Primary Group" to be "TexasFamilia"
User-added image
User-added image

Go back to the provisioning tab and set it to use the 'Zone Default' which you just created. 
User-added image

Now when ZPA goes to provision users you will see all of the users have the same primary group. 
User-added image

Go ahead and create a test zone and play around with ZPA to set it up how you want. Don't worry a test zone can be deleted and it won't affect your production at all. 


My users are coming from a one-way trust and I want to use ZPA, what do I need to do?

Read the first section of this blog so you understand how ZPA works. For a one-way trust we just need to make sure the service account has the necessary read permissions depending on where it is:

Example setup:
1) Users and ZPA Service account live in Domain A
2) ZPA is setup in Domain B
3) The service account is granted 'Logon As a Service' in Domain B via group policy or local policy
4) By default the service account will have read permissions in Domain A where it is coming from
5) Delegate Zone Control for the service account to Add/Remove Users and Groups in Domain B Zone in Access Manager
 
Note: If the service account lives in Domain B, it will need to be granted read permissions on Domain A to retrieve those users.

And that's it! If you run into any issues there is this knowledge article you can reference for troubleshooting steps: https://centrify.force.com/support/Article/KB-3317-Troubleshooting-steps-for-when-the-ZPA-isn-t-working-properly
 

Still have questions? Click here to log a technical support case, or collaborate with your peers in Centrify's Online Community.