Knowledge Base

Our dedicated Product Specialist team is always ready to help you when you need it the most. Contact Support

How things work: Default Domain Policy and Specops Password Policy Precedence

I recently received a support question about the rules displayed during a password change in Specops Password Reset (SPR), versus Specops uReset. The scenario was fairly complex – advanced password rules configured for both the built-in Default Domain Policy (DDP) and Specops Password Policy (SPP),  where the “Must contain at least 1 Unicode character” was only displayed in uReset compared to SPR in the same environment. I realized that it would be appropriate to take one-step back and spread some insight in the way passwords are evaluated in Active Directory Domain Controllers when SPP is installed, in addition to addressing the actual question.

Password Changes in Active Directory with Multiple Password Filters

This is how SPP works in combination with the AD built in password policy.

All passwords changes in Active Directory pass through one or more Password Filters on the Domain Controllers (Specops Password Policy Sentinel is basically a Password Filter). All of these Password Filters need to approve the new password before the change is accepted, like the following flowchart shows.

Password Change Flow Chart

Following this somewhat simplified chart yields some important information:

  1. The Password Filters are called in serial order, where each one needs to approve of the new password for a successful change to take place.
  2. As soon as one Password Filter rejects a new password, the process is ended and the password is not changed.
  3. The DDP is always first. If the settings in the DDP are not fulfilled, SPP will never even get a shot at testing the password.
  4. The end user experience regarding feedback on a failed password change depends on the Password Filter, DDP or SPP, that rejects the password.


Armed with this knowledge, let us look at a scenario where the DDP is fairly complex and the user is also affected by an even more tightly configured SPP policy. The below screenshots display the DDP and SPP policy, both affecting the same user.

DDP Policy

SPP Policy

Take note of the following settings:

  • Minimum password length – DDP (10) and SPP (14)
  • Character group requirements – DDP (3 of 5 – upper, lower, digit, special, Unicode) and SPP (3 of 4 – upper, lower, digit, special)

The reason for the last two DDP character group requirements being active is that “Password must meet complexity requirements” includes those two settings. In SPP, these settings are more granular.

So let us imagine that we have a user that tries to change his/her password and what will happen in different scenarios (we will ignore all other rules for the sake of the discussion here).

New password: P@ssw0rd

  • DDP Minimum password length – Not OK
  • DDP Character group requirements – OK
  • SPP Minimum password length – Not OK
  • SPP Character group requirements – OK

Following the flowchart shows that DDP will prevent this password due to it being shorter than 10 characters and SPP will never be consulted. The user will see the generic message stating that new password is not complex enough, without saying why, most likely resulting in an expensive Helpdesk call.

New password: P@ssw0rd123

  • DDP Minimum password length – OK
  • DDP Character group requirements – OK
  • SPP Minimum password length – Not OK
  • SPP Character group requirements – OK

This time DDP will return OK, but instead SPP will prevent the change as the policy states at least 14 characters in minimum length. The result is the same as in the previous example, except that the end user will be told that the password is too short and needs to be at least 14 characters long. No expensive Helpdesk call!

New password: myn4m31smrh4rjਸਿੰਘ

  • DDP Minimum password length –OK
  • DDP Character group requirements – OK
  • SPP Minimum password length – OK
  • SPP Character group requirements – Not OK

This password is long enough, contains 3 different character groups (lower, number, and Unicode) but SPP will reject it as the SPP policy was configured to not count Unicode as a character group for complexity. Remember that SPP allows for exact selections in regards to character groups in comparison to DDP, where it is always 3 of the hard coded 5. The result here is that end user will be informed that it need to be 3 out of the 4 other groups. So simply adding a single uppercase character would let this password through both DDP and SPP.

Given the examples and the flowchart, you should most likely be able to figure out both what the end user experience will be, as well as how the different Password Filters will react to any give password from now on.

Best practice is to have a very simple DDP and use SPP polices for all users, both for the end user experience, and for better granular control of security.

What about Fine Grained Password Policy (FGPP)?

Some of you might wonder what happened if FGPP is used as well. The same Password Filter as DDP manages FGPP, the available settings are the same, it is only the way it is targeted that differs. Thus, a user can have a FGPP instead of the DDP, but it is the same Password Filter. So any place in this text where it says DDP, it can be read FGPP if the user is affected by a FGPP instead of the DDP.

What about that “Unicode” difference between SPR and uReset this started out with?

Now that you know how Password Filters are processed, it might first be a good idea to think about how SPR and Specops uReset display rules to end users during a password change (this information is not to be confused with the information displayed when a password change fails).

The DDP and SPP policy above would for example present the following list of rules to the end user in uReset:

Rules displayed to endusers

Looking at the list of bullets it actually looks a lot like the settings in the SPP policy above, and not much of the DDP settings at all, although we just learned that both are being tested. In reality, a very advanced merge calculation is performed by SPR or uReset. The two polices are analyzed on a per-setting bases and the combined, or most restrictive setting, depending on what is looked at, is shown in the final result.

This becomes interesting when looking at the “Must contain at least 1 Unicode character” in the list above, as this setting is actually a result of the DDP and not the SPP policy, as the SPP policy explicitly stated that Unicode is not needed. It becomes even more interesting if you change the number of required character groups in the SPP policy to “All” instead of 3. Because then the Must contain at least 1 Unicode character magically disappears from the list. Why? Because the advanced merge algorithm realizes that if the required 4 groups is enforced by SPP, then any accepted password would not need a Unicode character.

So how does this relate to SPR and uReset showing a minor difference for the Unicode requirement (in SPR it is not shown for the DDP and SPP policies above). The answer is simple. The merge algorithm has matured even further in the uReset code to include more extreme combinations. This is only a UI annoyance, the actual password check is always the exact match of both policies and that is what matters at the end of the day.

May 29, 2017

Was this article helpful?

Related Articles