Knowledge Base

• DDP = Default Domain Password Policy
• FGPP = Fine Grained Password Policy
• SPP = Specops Password Policy

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

Following this somewhat simplified chart yield some important information:

1. The Password Filters are called in serial order, where each one need to approve 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, thus if the settings in the DDP aren’t fulfilled SPP will never even get a shot at testing the password.
4. If there is a FGPP configured, the settings in this policy will cancel out the settings configured in DDP but only for users affected by the FGPP.

Armed with this knowledge, let’s look at a scenario where the DDP is complex and what happens when a user also is affected by an even more tightly configured SPP policy. Below two screenshots are displayed, one that displays a DDP and one that displays a SPP policy, both affecting the same user.

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 and Unicode) and SPP (3 of 4 – upper, lower, digit and special)

The reason for the last two DDP settings being active is that “Password must meet complexity requirements” includes those two settings, settings that are more granular can be configured separately in SPP.

So, let’s imagine that we have a user that tries to change his/her password and what will happen in different scenarios (all other rules will be ignored 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.

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, so the result is the same as in the previous example.

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, numbers and Unicode, but SPP will reject it as the SPP policy was configured not to include Unicode as a character group for complexity. Remember that SPP allows for exact selections regarding character groups in comparison to DDP, where it is always 3 of the hard coded 5. And the result here is that end user will be informed that he needs to use 3 out of the 4 other groups. So simply adding a single uppercase character would for example let this password pass 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 given password from now on.

Best practice

Best practice is to have a very simple DDP and use SPP polices for all users, both for end user experience and for better granular control of security. Some customers however use SPP for only a part of their AD and use DDP for the rest, this scenario where both policies with more advanced settings will be in play is also common.

What about Fine Grained Password Policy (FGPP)?

Some of you might wonder what happened if FGPP is used as well, will this be another Password Filter in the list? FGPP is actually managed by the same Password Filter as DDP, the available settings are the same for DDP and FGPP, it is only the way it is targeted that differs and thus a user can be affected by 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.

Let Specops Password Policy bypass the DDP with the help of an FGPP

Some customers use a FGPP to cancel out the DDP, it basically means that they have configured a FGPP without any settings at all and applied this FGPP to the same Active Directory group they are using to filter the Specops Password Policy. This makes it possible to have i.e. 180 days password expiry in SPP while still having i.e. 90 days expiry in DDP.

Because all password filters are called in serial order (DDP, FGPP, SPP) the strictest setting from all policies will be the ones that takes precedence. Sometimes it is a good idea to create a FGPP to override and cancel out the settings in DDP so that SPP can be configured exactly as the customer wants regardless of how DDP is configured. A great use-case for this is when using the feature “Length based Password Aging” in Specops Password Policy, enabling the users to get rewarded with more days before expiration for choosing a longer password.

More details about “Length based Password Aging” settings can be read here:

https://specopssoft.com/knowledge-base/specops-password-policy/what-is-length-based-aging-and-how-is-it-used-and-implemented/

How to create a FGPP bypass policy:

https://specopssoft.com/knowledge-base/specops-password-policy/how-to-create-a-bypass-policy-using-a-fine-grained-password-policy/