Multiple Password Policies in 1 domain

[RichardBateman]

On this page:

http://www.gpanswers.com/faq/

the following appears:

"Can I set different password policies for different OUs?

Unfortunately, no. You can only have one password policy for the entire domain. If you need separate password policies, you�will have to�create separate domains."

However, this is not strictly true. Multiple password policies can be linked to a single domain and through the use of security filtering different sets of users (groups, not OUs) can have different password policies.

[jdobiash]

You've tried this and it worked?

[RichardBateman]

I use this approach at all of my customer's who require that administrators to have "tighter" security than regular users.

The misapprehension that most people have is that there can only be a single policy that affects the “Account Policies� section at the domain level. This is an inaccurate perception. In fact, multiple policies can be created, all with different settings, as long as they are linked at the domain level (we are working under the assumption here that we are talking about issues related to domain accounts and domain authentication, not local accounts). When multiple policies are linked to a single container, conflicts are “won� by the policy highest in the list. To avoid conflicts, make sure that each policy affects a specific, non-overlapping set of users.

For example, if I want tighter security for my admin accounts as opposed to non-admins I would create two policies. Let’s call them (creatively enough) “Admin Logon� and “User Logon�. I can either rely on the order in which the two policies are listed (scenario 1) or I can use explicit denial (scenario 2) to control the application of these two policies. In both scenarios below it is assumed that more strict settings will be configured in the Admin Logon GPO.

Scenario 1 (order dependent)

Create both policies with default permissions at the domain level. Move the Admin Logon GPO above the User Logon GPO. Modify the permissions on Admin Logon by removing the Authenticated Users group entirely and adding the allow AGP permission to Domain Admins. Regular users will only evaluate the User Logon GPO and use the lower level settings it contains. Domain Admins will evaluate BOTH polices, but the Admin Logon GPO will be applied last and “win�, requiring more stringent password handling.

Scenario 2 (order independent)

Exactly the same as scenarion 1, except the order of the policies is irrelevant and on the User Logon policy, configure Domain Admins with the deny AGP permission.

As a Microsoft Certified Trainer, this is the example I use when I am teaching my students an example of using security filtering to apply different sets of settings to users in the same scope of management.

[jdobiash]

Huh, everything I've read on Microsoft website and in all of the newsgroups say an emphatic "no" when someone asks about Mutliple polices. The reason I've read is that those polices are not actually applied to the users, but only to the Domain Controllers (for Domain Accounts anyway, the other computers would be for their local accounts). As it is, they are "Computer Policies" to start with so assigning them to different user groups shouldn't make any difference, the only policy that would apply would be the one that the Domain Controllers end up getting.

They do say that the new "Longhorn" version will include the ability to have mutliple password policies.

[JerryC]

I am also VERY suprised. My understanding is that the affect of the "last" Account Policy settings GPO to apply (or be read) by the Domain Controllers is for the DC's to perform an Active Directory domain root object 'stamp' of the appropriate Account Policies.

For example, when a Domain user changes his password, their device reads the 'stamped' settings and behaves accordingly. There should only be '1' set of account policy settings available because there's only '1' set of 'stamped' settings per domain root object.

Again.. you have 'verified" this behavior for multiple 'domain-side only' accounts?

==============================
That would NOT be the case for the effects upon local device accounts where the GPO-based settings from other GPOs could apply. At that point, the accounts are using the local security database settings as the control entity.
==============================

I would be curious to see what the domain root object information is on your domain root...maybe not a direct copy, but if you could simply tells us whether there is still just one set of account property stamps.

Here's how to look up the domain root object properties:

1. Launch the LDP Windows Support tool.

2. In the LDP console window, choose Connection | Connect… and make sure that the Server field is empty, the port is 389, and that the connectionless and SSL checkboxes are not checked, then click on the OK button.

3. In the LDP console window, choose Connection | Bind… and make sure that the fields noted are blank. [Note: Some versions of the LDP tool have a slightly different GUI. The gist is to force LDP to use your current credentials (see second example).] Click on the OK button.

4. Choose View | Tree from the main menu. Enter the LDAP path to the domain being checked in the Tree View dialog box, then click on the OK button.

Example: If your domain is howdy.there.mycopmpany.com, the LDAP path would be: C=howdy,DC=there,DC=mycompany,DC=com

5. For convenience, clear the display in the right hand pane using the Connection | New menu option and then double-click on the domain name in the left-hand pane. Scroll up in the right-hand pane and look for information like that shown below:

(All values replaced with the 'x' character.) I only have one set of these settings on the domain root object. Does your domain have more than one?
[code:1]1> forceLogoff: X;
1> lockoutDuration: XXX;
1> lockOutObservationWindow: XXX;
1> lockoutThreshold: X;
1> maxPwdAge: XXXXXXXX;
1> minPwdAge: X;
1> minPwdLength: X;
1> modifiedCountAtLastProm: X;
1> nextRid: XXXX;
1> pwdProperties: X;
1> pwdHistoryLength: X;[/code]

[HanzelMan]

Greetings:

I know this is an older post, but did anyone ever find out if applying the security filtering RichardBatemen referred too actually worked?

Thanks,

HanzelMan