Skip to main content link. Accesskey S
  • HCL Logo
  • HCL Notes and Domino wiki
  • THIS WIKI IS READ-ONLY. Individual names altered for privacy purposes.
  • HCL Forums and Blogs
  • Home
  • Product Documentation
  • Community Articles
  • Learning Center
  • API Documentation
Search
Community Articles > Lotus Domino > Domino policies > Domino Policy Precedence Explained
  • Share Show Menu▼
  • Subscribe Show Menu▼

Recent articles by this author

Notes URLs

Notes URLs The launching of Notes URLs is the mechanism the client uses to create bookmarks and launch components. This document describes various configurations of that URL and the results of launching them. Format: notes:serverdbviewdocument?Commandparamsvalues Server Examples: NPD1, ...

IBM's phase 1 deployment of the Notes ID vault

IBM has begun its internal deployment of the Notes ID vault, the new Notes ID file recovery and management feature in Lotus Notes and Domino 8.5. This article provides a window on phase 1 of our ID vault deployment during which we deployed the ID vault in one of the domains used by the Lotus ...

Security Assertion Markup Language (SAML) Notes Federated Login

This article will cover the following topics for Security Assertion Markup Language (SAML) Notes Federated Login: Notes Federated Login Overview, Notes Federated Login Deployment Overview, Debug Tips. This content was provided by Na Pei of the IBM Notes Development team

Adding an ID vault password reset authority from a different organization

If a password reset authority is in an organization different from the organization assigned to your vault, you may need to take additional steps in order for the password reset authority to be able to reset passwords successfully. If not already created, you will need to create crosscertificates ...

Upgrading from Notes client single logon to Notes shared login

Lotus Notes 8.5 supports both Notes client single logon (introduced in an earlier release) and Notes shared login (new in 8.5). Notes single logon is not a supported configuration if you use the ID vault. Therefore, if you use the ID vault, use Notes shared login instead, which is designed to work ...
Community articleDomino Policy Precedence Explained
Added by Michael Stewart on September 16, 2020 | Version 1
  • Actions Show Menu▼
expanded Abstract
collapsed Abstract
No abstract provided.
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 Interval
Assigned vault
Warning Period
Allowed Grace Period
Organizational: */Europe/IBM
Don't Set
N/A
14 days
90 days
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 Interval
Assigned vault
Warning Period
Allowed Grace Period
Explicit: "Relaxed Logins"
120 days
Don't Set
Don't Set
120 days
Dynamic: "Executives"
Don't Set
/ExecutivesVault
Don't Set
Don't Set
Organizational: */Europe/IBM
90 days
N/A
14 days
90 days




So if a user had all of these policies assigned to them, the resultant effective policy would be:

Required Change Interval
Assigned vault
Warning Period
Allowed Grace Period
Effective policy
120 days
/ExecutivesVault
14 days
120 days




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 Interval
Assigned vault
Warning Period
Allowed Grace Period
Explicit: "Relaxed Logins"
120 days
Don't Set
Don't Set
120 days, INHERIT
Dynamic: "Executives"
N/A
/ExecutivesVault
Don't Set
Don't Set
Organizational: */Europe/IBM
90 days, ENFORCE
N/A
14 days
90 days




So if a user had all of these policies assigned to them, the resultant effective policy would be:

Required Change Interval
Assigned vault
Warning Period
Allowed Grace Period
Effective policy
90 days
/ExecutivesVault
14 days
90 days




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 organizational policies. 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 Change Interval
Assigned vault
Warning Period
Allowed Grace Period
Low Battery Threshold
Explicit: "Relaxed Logins"
120 days
Don't Set
Don't Set
120 days, INHERIT
Don't Set
Dynamic: "Executives", Precedence 2
N/A
/ExecutivesVault
Don't Set
Don't Set
20%
Dynamic: "Mobil", Precedence 3
N/A
N/A
Don't Set
Don't Set
10 %
Organizational: */Europe/IBM
N/A
N/A
14 days
90 days
N/A
Organizational: */IBM
90 days, ENFORCE
N/A
21 days
N/A
N/A




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 Change Interval
Assigned vault
Warning Period
Allowed Grace Period
Low Battery Threshold
Explicit: "Relaxed Logins"
120 days
Don't Set
Don't Set
120 days, INHERIT
Don't Set
Dynamic: "Executives", Precedence 2
N/A
/ExecutivesVault
Don't Set
Don't Set
20%
Dynamic: "Mobil", Precedence 3
N/A
N/A
Don't Set
Don't Set
10 %
Organizational
90 days, ENFORCE
N/A
14 days
90 days
N/A




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 Change Interval
Assigned vault
Warning Period
Allowed Grace Period
Low Battery Threshold
Explicit: "Relaxed Logins"
120 days
Don't Set
Don't Set
120 days, INHERIT
Don't Set
Dynamic
N/A
/ExecutivesVault
Don't Set
Don't Set
20%
Organizational
90 days, ENFORCE
N/A
14 days
90 days
N/A




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 Change Interval
Assigned vault
Warning Period
Allowed Grace Period
Low Battery Threshold
Bob Smith's effective policy
90 days
/ExecutivesVault
14 days
90 days
20%




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.

  • Actions Show Menu▼


expanded Attachments (0)
collapsed Attachments (0)
Edit the article to add or modify attachments.
expanded Versions (1)
collapsed Versions (1)
Version Comparison     
VersionDateChanged by              Summary of changes
This version (1)Sep 16, 2020, 5:58:02 PMMichael Stewart  
expanded Comments (0)
collapsed Comments (0)
Copy and paste this wiki markup to link to this article from another article in this wiki.
Go ElsewhereStay ConnectedAbout
  • HCL Software
  • HCL Digital Solutions community
  • HCL Software support
  • BlogsDigital Solutions blog
  • Community LinkHCL Software forums and blogs
  • About HCL Software
  • Privacy
  • Accessibility