Domino Policy Precedence Explained

Overview

Domino policies provide a powerful way for an administrator to manage their

enterprise. But when multiple policies apply to a given user, it can be confusing to
understand how the effective policy is determined. This article will explain in detail
the factors that determines how policy precedence works.

First there are hierarchies for organizations and groups. There are three levels of
policies: explicit, group (dynamic), and organizational. There are also the
Inherit/Enforce settings which come into play. Lastly, there are the precedence
settings for group policies. We will examine each of these factors in turn. But first, a
qualification. Precedence does not mean that one policy completely overrides
another. Precedence applies on a per field basis. So a setting in a policy with lower
precedence can still make into the effective policy if the policy with a higher
precedence does not have a value for that setting.

Hierarchies

Before explaining about the three levels of policies, the first thing that we need to
understand is hierarchies. Organizational policies and dynamic polices (because of
the group name, "Executives/IBM") can be hierarchical. When hierarchies are
present, they are resolved first before precedence is applied.
Take for example the organizational policy "*/Europe/IBM", it is a hierarchical name.
If there is also a root organizational policy, "*/IBM" then it would have to be taken
into account. So resolving these two policies would result in the following table with
some settings/values from the Mail settings for illustrative purposes:
Required Change Assigned Warning Allowed Grace
Interval vault Period Period
Organizational: Don't Set N/A 14 days 90 days
*/Europe/IBM
Organizational: */IBM 90 days N/A 21 days N/A

Note: Don't Set in the above example and the rest of this document refers to the How
To Apply feature of policies that exists on a per setting basis:

That feature will be discussed in another Wiki since it is

has a different dynamic in the policy space. For this discussion, having Don't Set for
a value means that checkbox is selected. N/A simply means that the value does not
matter.

As will we discuss in more detail in a moment, the more specific a policy is it takes
precedence. So in the case of the two organizational policies above, the settings in the
 more specific policy */Europe/IBM will always take precedence over the more
general settings of */IBM which results in an organizational effective policy of:
Effective policy 90 days N/A 14 days 90 days

So after any organizational and group hierarchies are resolved, the precedence among
the levels can now be determined.

The Three Levels

The precedence of the three levels is defined by there specificity. The more specific
or narrowly defined the scope of a policy's assignment, the higher precedence it has.
The least specific policy level is the organizational policy, i.e. "*/IBM". This policy
applies to everyone that was registered by that organizations certifier and so has a
wide scope. If you think of scope as a room full of people at conference, it would be
like telling everyone to sit down. A more specific policy is the dynamic group policy,
i.e. "Executives", where the user gets the policy because they are a member of a
group. This will in general have a much smaller scope therefore it has higher
precedence. Going back to the audience analog, it would be the same as telling
everyone in the front row to stand up. The most specific policy is the explicit policy,
i.e. "Relaxed Logins" that a user gets by either having the policy set in their person
document. This kind of policy has the highest precedence. Using the audience
analogy, it would be like telling Bob Smith to present the people in the first row who
are standing an award certificate. So in decreasing order of precedence it is:
Explicit
Dynamic
Organizational

In order to continue the discussion, it will be useful to have some example policies.
So for each of the three levels, here is a sample policy that contains only a few
settings. Assume that these are the only settings that have been set. In red are the
items that have precedence and are thus included in the effective policy:
Required Change Assigned vault Warning Allowed Grace
Interval Period Period
Explicit: "Relaxed 120 days Don't Set Don't Set 120 days
Logins"
Dynamic: Don't Set /ExecutivesVault Don't Set Don't Set
"Executives"
Organizational: 90 days N/A 14 days 90 days
*/Europe/IBM

So if a user had all of these policies assigned to them, the resultant effective policy
would be:
Required Change Assigned vault Warning Allowed Grace
Interval Period Period
Effective 120 days /ExecutivesVault 14 days 120 days
policy

How Enforce and Inherit change the rules

For every setting that is specified you can also choose whether to Enforce the setting
in a child policy or Inherit that setting from a parent policy. Whereas precedence is
based on specificity, the Enforce and Inherit settings are based on scope which is the
opposite of specificity. When either of those options are used, the policy with the
greater scope wins. Therefore the three levels as listed before has decreasing
specificity but increasing scope. Taking the sample above but this time with one
setting being enforced and another setting being inherited:
Required Change Assigned vault Warning Allowed Grace
Interval Period Period
Explicit: "Relaxed 120 days Don't Set Don't Set 120 days,
Logins" INHERIT
Dynamic: N/A /ExecutivesVault Don't Set Don't Set
"Executives"
Organizational: 90 days, N/A 14 days 90 days
*/Europe/IBM ENFORCE

So if a user had all of these policies assigned to them, the resultant effective policy
would be:
Required Change Assigned vault Warning Allowed Grace
Interval Period Period
Effective 90 days /ExecutivesVault 14 days 90 days
policy

The effect of using the Enforce option on a setting is pushing it up to the top the
precedence hierarchy. The effect of using the Inherit option on a seting is to pull up a
setting from a lower level. In the case of the Allowed Grace Period setting, if there
had been no value in the organizational policy, then the setting of 120 days would
used. So it will only inherit a value if it is present. It would not inherit an empty
value.

Group Precedence

A user can only have one explicit policy or one organizational policy, but they since
they can be in several groups they could have multiple dynamic policies. In that case
the group precedence is used. The precedence is defined in the Domino Directory
under People -> Policies -> Dynamic Policies:
It can also be seen but not modified in the Policy Precedence tab of a policy document
itself:

Like how precedence works with the three levels of policies, precedence only comes
into play when more than one policy has a value for a particular setting. Otherwise,
the setting is just merged into the effective policy. Therefore if you do have two
dynamic policies with the same setting, the one with the greatest precedence (the
lowest numerical value) will win. When an effective policy is being created for a
user, all of the dynamic group settings will be resolved before the precedence with
explicit and organizational policies are resolved.

When a new dynamic policy is created, it will automatically be given the lowest
precedence value. Using the screenshot example above, a new dynamic policy would
be assigned a precedence value of 6. Then the actions buttons in the Domino
Directory -> People -> Policies -> Dynamic Policies view can be used to increase or
decrease precedence for a selected policy. This will move the policy up/down the list
as appropriate and changing the precedence values relative to the other policies. If the
policy with the highest precedence is deleted (3 in the example above) then the next
lowest value ( 4 in the example above) becomes the highest precedence. Note the
precedence values are not rebased in that case. So over time, the precedence values
will drift higher.

Putting it all together

The table below shows all of the policies that effect a hypothetical user, Bob Smith.
He has 5 policies, 1 explicit, 2 dynamic group, and 2 organization policy. There is 1
setting with Enforce enable and 1 setting with Inherit enabled. The first 4 settings are
from the Mail settings and the last one is from the Traveler settings document.
Required Assigned vault Warning Allowed Low Battery
Change Period Grace Threshold
Interval Period
Explicit: "Relaxed 120 days Don't Set Don't Set 120 days, Don't Set
Logins" INHERIT
Dynamic: N/A /ExecutivesVault Don't Set Don't Set 20%
"Executives",
Precedence 2
Dynamic: "Mobil", N/A N/A Don't Set Don't Set 10 %
Precedence 3
Organizational: N/A N/A 14 days 90 days N/A
*/Europe/IBM
Organizational: 90 days, N/A 21 days N/A N/A
*/IBM ENFORCE

The first step in determining the effective policy is to resolve the hierarchies of which
there is only one in this example. */IBM and */Europe/IBM. Resolving that results
in the next table:
Required Assigned vault Warning Allowed Low Battery
Change Period Grace Threshold
Interval Period
Explicit: "Relaxed 120 days Don't Set Don't Set 120 days, Don't Set
Logins" INHERIT
Dynamic: N/A /ExecutivesVault Don't Set Don't Set 20%
"Executives",
Precedence 2
Dynamic: "Mobil", N/A N/A Don't Set Don't Set 10 %
Precedence 3
Organizational 90 days, N/A 14 days 90 days N/A
ENFORCE

In the above table, the "Enforce Password Expiration" is kept because of the Enforce
setting. The Warning Period setting is kept because the "*/Europe/IBM" policy has
higher precedence than "*/IBM".

The second step is to resolve the group precedence between the "Executives" and
"Mobil" group. This results in the next table:
Required Assigned vault Warning Allowed Low Battery
Change Period Grace Period Threshold
Interval
Explicit: 120 days Don't Set Don't Set 120 days, Don't Set
"Relaxed INHERIT
Logins"
Dynamic N/A /ExecutivesVault Don't Set Don't Set 20%
Organizational 90 days, N/A 14 days 90 days N/A
ENFORCE
In the above table, the "Low Battery Threshold" is kept because the "Executives"
group has higher precedence than "Mobil".

Lastly, the precedence among the three levels needs to be resolved:

Required Assigned vault Warning Allowed Low Battery
Change Period Grace Threshold
Interval Period
Bob Smith's 90 days /ExecutivesVault 14 days 90 days 20%
effective policy

Conclusion:
Hopefully, this article has been helpful in explaining how the different policies and
the factors that effect them combine to form the effective policy for a user. In the
future, look for other articles that take a different approach, namely, how to put
together a combination of policies to solve different administrative scenarios. Also, in
this article the How To Apply feature was not discussed. That is because it is
somewhat different from precedence. Look for an article on that in the future.