Group Association of Policy Packages

This entry won the Reader's Choice Award, the grand prize of the ZENworks Tip Contest in 1999. This entry was also awarded 2nd-prize by the judges in a very close race. Patrice is an Escalation Engineer in the Novell European Support Center. To see all the winners, check out this article.

Applies to any version of ZENworks (including ZENworks 2).

In ZENworks, a policy package can be associated directly to the object itself (user or workstation object), to a container object, and to a group object (user group or workstation group).

A previous Cool Solutions article described how ZENworks was determining which policy is effectively used when several policies coming from different packages are associated directly or indirectly to an object. However, this article didn't cover an odd behavior of ZENworks related to group associations: which policy will be effectively used by ZENworks when a user (or a workstation) is member of several groups and those groups are associated to different policy packages?

To better understand what's happening in such a case, let's take an example. Let's say that user Joe is a member of two different groups: UserGroup and AdminGroup. In addition to that, we have two different User Policy Packages: Restricted_Package and Unrestricted_Package. The Restricted_Package implements a Dynamic Local User Policy where the user is only a member of the NT User Group. The Unrestricted_Package implements a Dynamic Local User Policy where the user is not only a member of the NT User Group but also a member of the NT Administrator Group. The Restricted_Package has been associated to the UserGroup and the Unrestricted_Package has been associated to the AdminGroup. Since user Joe is a member of both groups, both Dynamic Local User policies are indirectly associated to him. However, the Dynamic Local User policy is a singular policy, meaning that only one such policy can be effectively applied to the user. Now, the question is: which policy will be effectively applied to user Joe?

Well, sadly enough, the answer is: it depends! Indeed, we first have to remember that the main rule regarding effective policies is: the first (singular) policy found is the one that will be effectively applied. In our case, to find out which Dynamic Local User Policy will be effectively applied we have to remember that the group membership list of a user will be read in an "historical" manner. Meaning that the first group read will be the first group the user was made a member of, the second group read will be the second group the user was made a member of, and so on. So if the user Joe was first made a member of the UserGroup, we will get the DLU policy from the Restricted_Package. On the other hand, if he was first made a member of the AdminGroup, we will get the DLU policy from the Unrestricted_Package!

So, the important factor here is the order in which the user was made member of the different groups. This has very bad consequences for the administrator:

The group order is user related. Two users who are members of the same two groups might end up with different effective policies if they were made members of those groups in a different order.

The group order cannot be easily seen. Going into the group membership section of the user object with NWAdmin doesn't help because the groups are listed alphabetically, not historically.

Removing a user from a group and putting him back will change the group order and, therefore, can change his effective policies! Even though he is still a member of exactly the same groups.

Practically, all this means that effective policies can very quickly become unmanageable when associating Policy Packages to groups. Here are a few tips to help you alleviate this problem (sorted from the most effective tip to the least effective tip):

Activate a Search Policy through the Container Package and remove the group objects from the Search Order section. This way, you are sure that policies associated to groups will not be taken into account.

Don't associate Policy Packages to groups. Associate them to the containers or to the objects themselves.

If you have to associate Policy Packages to groups, make sure that the different Policy Packages have different policies activated. For example, one package would have the DLU policy and another package would have the Printer policy. This way, it doesn't matter in which order those policies are applied.

Do not make a user a member of groups associated to conflicting Policy Packages (like the UserGroup and AdminGroup in our example).

In the worst case scenario (Policy Packages with conflicting policies), use DSView or DS Snoop (can be downloaded from the Novell Consulting Web Site) to find out in which order the user was made a member of the various groups