Multiple password policies on a Windows 2003 Domain

Here's an article from Redmond that says you can have multiple policies with a third party application.
http://redmondmag.com/reviews/article.asp?editorialsid=538

It's probably not the definitive answer you want but...

From:
http://technet.microsoft.com/en-us/magazine/cc137749.aspx

The lawyer answer is that you can - but only one will apply ;)

...That said, many administrators believe it's possible to have multiple password policies for users in the same domain. They think you can create a GPO and link it to an Organizational Unit (OU). The idea is to move user accounts to the OU so that the GPO will affect the objects. Within the GPO, the Account Policies are modified to create a more secure Password Policy, perhaps by setting the maximum password length to 14 characters. But, for a several reasons, this configuration will never provide the desired outcome. First, the Password Policy settings are computer-based rather than user-based policies. With this foundation for the settings, they will never affect a user account. Second, the only way to modify the Account Policy settings for a domain user account is within a GPO linked to the domain. GPOs linked to the OU that are configured to alter the Account Policies settings will modify the local SAM of computers that reside in the OU, or are in sub-OUs of the linked OU.
A second misconception is that Account Policies settings established in the root domain (the initial domain of the Active Directory forest) will trickle down, or inherit down, through to the child domains in the forest. This, too, is not the case and you can't make the settings function in this manner. GPOs linked to the domain and OUs within one domain will not affect objects in another domain, even if the domain where the GPO is linked is the root domain. The only method for GPO settings to span objects in different domains is to link GPOs to Active Directory sites.

No references to third party tools please - assume standard Windows 2000 or 2003 domains (I know you can do it with 2008)

My argument is that
1. A password policy must be set at the domain to have any effect
2. While their is the option to set the password policy at the OU, doing this had no effect
3. You cannot filter or block inheritance of the password policy in any way

Correct - or am I losing it?

Correct.  Windows 2008 brings the ability to have multiple password policies.  Without 3rd party tools, any Windows 2003 password policy outside of the default domain policy is non-effective.

"My contention is that you cannot have multiple password policies in 2003 unless you have Multiple domains."

The ivory-tower answer is that you can have multiple password policies in 2003 with a single domain - but only one will be effective.  Technically, McKnife is correct, in practice you are...

Hi folks!
Paka, did you read the original thread entirely? If you say In practice, KCTS is correct, why do you suppose am I able to run different password policies no matter if applied at domain level or at OU level?

Sorry for the delay, I was helping someone with an Exchange dirty shutdown problem.   I didn't read the original thread and am finally getting around to it and setting up a VMware domain per your instructions.  I tried a multiple password policy setup a couple weeks ago and was unable to get it to work correctly but had modified the default domain policy and created a supplimental one on an OU.

Here is a very current link from MS on password policies.
http://technet2.microsoft.com/windowsserver2008/en/library/056a73ef-5c9e-44d7-acc1-4f0bade6cd751033.mspx?mfr=true

You can create hundreds of password policies in AD, but only one will be effective and that by default is the default domain policy.

And McKnife, you really need to check to see that those multiple password policies you say you are running are actually doing what they are supposed to do.  You will find that only one is in effect.  The rest may be present but will not do anything for you.

This has been true since the advent of AD with Windows 2000. Windows 2008 changes to allow what are called "fine-grained" password policies.  That is, more than one policy can be applied AND IS EFFECTIVE in a domain.

... whow...where are you at. To be precise about what I stated: I never said you could have different policies in effect for a single computer in 2k or 2003, I said, you could solve the scenario mtzsw is having in the original thread. This can be done by denying access to the main pw policy and setting up a separate pw policy just for that computer. As you all can read in https://www.experts-exchange.com/questions/22040173/Password-Complexity-Policy-not-applying.html, others could confirm this.

Next round of experiments.
Ran DCGPOFIX to reset default domain policy - 7 characters

Created two policies: 6char (bound against domain) and 5char (bound against OU)
Blocked inheritance on the 5char; ensured no override was not checked on the 5char
6char policy moved higher in priority against domain

Ran GPUPDATE /force on DC and member server
Ran GPRESULT on DC and verified 6char policy was applied
Ran GPRESULT on member server and verified 5char was applied
Ran RSOP.MSC on member server and verified 5char was the Source GPO

Hit control-alt-delete and c for change password.
Tried to enter a password of 12345
Received message indicated my password needed to be 6 characters long

Moved the 6char policy to a lower priority than the default domain policy and repeated steps above.
Received message indicating it need to be 7 characters long, didn't meet complexity, etc

Just for grins, I removed all password policy requirements except character and complexity in the default domain policy and set them to 7 and enabled respectively.  I moved 6char up in priority (all of the rest of the settings were not defined).

I tried to change the password and the effective settings were 6 characters and complex password required - meaning that normal group policy inheritance rules applied at the domain level but were ignored at the OU level.

So are we saying that the password policy set at the domain level always applies ?

That is my understanding as well. I'm trying to understand McKnife's arguments but cannot see it.

Neither can I.  I 've worked with NT 3.5 to Windows 2008 (betas) and have never seen more than 1 EFFECTIVE password policy.  I have gone into companies as a consultant where they think they are running multiple password policies linked to OUs, but I quickly show them they are wrong.

Paka has done a great analysis for you.

I'll leave this open for a little while to see if any other opinion come to light. Thanks to all do far.

The dust hasn't settled yet.  The fact that you can have two domain security policies at the domain level probably means you can selectively filter them through a deny.  This would tip the scales in McKnife's favor.  I'm working on a test right now.

I vaugly remember attempting this previously and if I remember correctly filtering did not work, the last applied (highest priority) policy winning - Thanks for testing - I look forward to the resullts - whatever they are

Extending on the previous posts, I created a security group, added a user account into it, added the group to the 6char group policy ACL as a Deny Full Control and refreshed group policy.  Even though the explicit Deny's were in place, the effective group policy was 6char.  It looks like you can have multiple group policies linked at a domain level with the effective group policy following standard inheritance rules.  However, that policy cannot be filtered or denied.

That confirms the comment I made in post #21133525. Thank you.

Doah!  I need to rerun the experiment since this is a computer policy - not user!  Stand by...

Created security group, added member server to the group and used Deny Full Control ACL on the 6char Group Policy.  This had the same effect, both group policies defined at the domain level merged and became the effective policy.  The policy defined at the OU had no effect.

Thanks Paka this is been very useful.

McKnife, have you any further comment - I would like to clear this matter up

An other experts like to add any comment?

Folks, anyone who doubts that such a policy can be applied at OU-Level (while Domain level: unconfigured) please explain, why it works for me.
With gpresult.exe, I am able to see, what policies are applied. It's just the default dom. policy and the testpolicy which I applied to that OU. So if the default policy is unconfigured, have a guess where the pw settings are originating. And yes, of course I tested it, it rejects PWs shorter than ten.

End of discussion for me as I have better things to do.

I will test myself tommorrow when I can get to a virtual PC or two, just to be sure.

I just tried setting all the password policies in the Delfault Domain Password to "not Defined" and after running GPUPDATE /force was unable to create a user anywhere in the domain (even in an OU to which a sperate policy was linked), AD just kept telling me the password did not meet the minumum requirements.

That is a normal indication and again shows why only 1 password policy can be applied and that at the domain level.  The Account Policy part of AD is only defined at teh domain level.  So normal inheritance rules do not apply.  There are many technet articles on this practice from MS.  And teh rumor that multiple independent password policies can be applied at teh OU level has been hard to dispel.  

But only 1 "in effect" password policy is allowed in a discrete domain at any one time.  That is the botom line.

Its looking that way - I just want to make absolutely sure as Mc Knife seems as insistant that it works

When I have gone into a company and shown them their multiple OU based GPO password policies do not work, some of the existing IT staff insist I "broke" something.  Just takes a while and a rigorous testing environment to show that is not the case.  Paca did a good job in a short time.  It's pretty much how I set up the testing.

I am back in...
Although I really lost faith in this discussion, I kept on reading and...
After reading what oBdA said, I finally have to admit my simple fault: The local group policy editor shows what pw policy is applied to ->local<- accounts and nothing more.
The tests were done either with local accounts or with domain accounts and that is the crucial point, they once worked even with a domain account although that, as oBdA correctly states, can only be influenced by one pw policy (if you don't have 2008 server): that one applied to the dc.
The reason for that has to be that while testing (where I changed settings in the password section of the default domain policy) maybe the delay between modifying a policy and the point in time when it becomes effective led me to thinking the changes I made to the extra pw policy influences domain accounts as well.
So I am really very sorry for the confusion I created by stubbornly saying "well, it works for me :)" but that was really what I thought I was observing.

So again: to local accounts on different domain computers (and that can of course be an objective, too) you can apply different password policies (even at OU level) but not for domain accounts unless a 2008 dc is ruling.
Thanks oBdA!

Now I will go and spread it in the original thread, the one that started the thread has been quite calm during the discussion, oooops....

To complicate things a bit - the statement:
"There can be only a single password policy for each account database. An Active Directory domain is considered a single account database, as is the local account database on stand-alone computers."

isn't quite correct.  You can have multiple policies for each account database!  To prove it:

Create a policy named 6char that defines the following settings:
0 password history
0 max password age
0 min password age
6 char requirement for password length
uncheck password complexity
undefined reversible encryption

Leave the default domain policy in place
24 password history
42 max password age
1 min password age
7 char requirement for password length
Enabled password complexity
undefined reversible encryption

Give 6char a higher priority than the default domain policy
run gpupdate /force

*At this point if the single password policy per domain is "law" the password policy would be the 6char policy.  However, if you run RSOP.MSC you will see that it is:
0 password history (from 6char)
0 max password age (from 6char)
0 min password age (from 6char)
6 char requirement for password length (from 6char)
CHECKED password complexity (from Default Domain Policy)
undefined reversible encryption (from Default Domain Policy)

To validate this - if you try to change your password to "passwo" you will be challenged with the Password doesn't meet minimum complexity requirements dialog box.  If you change your password to: "P@55wo" you will be successful.  This means that two password policies were merged and are currently in effect.

In practice, since you can't filter or block these policies through ACLs - these two policies are, in effect, a single policy.  But you can have multiple password policies applied on a 2003 domain!

Paka,
Microsoft's statement above is correct.
What you're describing is linking several *Group* *Policy* *Objects* with different *policy* *settings* to the domain root.
"Password policy" in the article above refers to the password policy that is actually implemented in your domain, that is, the RSOP for the DCs. You're mixing/confusing this password policy with GPOs. You will *always* have one *single* RSOP applying to a computer object, there is nothing special about this being the password policy, the DCs, or not being able to block/filter them (not to mention that you actually *are* able to block/filter these GPOs, but it just doesn't give you any possibility to have more than one password policy).
As before: the point here is that you have *one* account database, stored on the DC, and you have *one* RSOP applying to this DC, so you can not have more than one resulting password policy.

Point taken oBdA.  Here's one for you though - since the Administrator account is exeempt from lockout does that mean there are two domain password RSOPs?

Nope; why should it? Oh, and don't forget the other password options like "Password never expires" or "User can't change password" in the user properties; these override the password policy as well ...

Thats what I thought when I started the thread - McKnife was so insistant that he was correct, even calling me a liar at one point, that I wanted to make absoluely sure.

Well, to McKnifes defense, this is a very common mistake.  Local and domain, wait for propagation/replication and so forth amkes it easy to mistake the application of multiple domain Pw policies are possible.

But there is no excuse for verbal abuse.  This is a forum for support, not blind adherence to a position when clearly that person is wrong.

There is something I have to point out... KCTS, you said here "McKnife was so insistant that he was correct, even calling me a liar at one point" - that's simply not true. Anyone who thinks I could be that dumb and aggressive, please have a look at the original thread. KCTS, be so fair and correct that because others believe that without reading, as it has already happened.
What I said was "I don't believe it. Are you calling me a liar? -not to be taken seroius- ;)"
So come on? What else should I have done to point out it is not to be taken serious? In your answer however you took it serious and said "I'm not calling you a liar..." - so this got mixed up, we should say, right?
Never mind :) (<- attention, this was another smiley)

Ok McKnife, explanation accepted - I did not read your original comment like that please accept my apologies on that

I think the case is closed - ONE PASSWORD policy per domain - NO EXCEPTIONS (unless its 2008)

I wish I could give more points on this - some Paka especially went out of his way to prove the answer testing various options

KCTS et. al. awesome thread!
Good read and thank you!

Philip

DAM!! lol

I trying to use radius to authenticate devices, but some need to authenticate using there macaddress as username and password. Unfortuntaly this does not meet our password requirments, so looks like i need to find another way to authenticate them!!

Great thread though and cant say i have seen more of a clear answer than that tells me I can't do it this way...

Cheers