Group Policy

[Tiger Shark]

AFAIK the latter is correct.

Well does it? If the policy propagation goes _Site_ - Domain - OU - Nested OU is it possible, (though probably no-one ever though much about it because most people, myself included, all tend to see the heirarchy as Domain - Site - OU etc.), that it could be set at the site level which would over-ride the Domain?

Just throwing it out there... I'm not going to try it on my production network....

[SawPer]

Just throwing it out there... I'm not going to try it on my production network....

Maaan Tiger... ! You are forcing me to try it on my network! :P
I can't just let this go now.. heh!!

Oh well... I'm too busy right now to test it, but if nobody else does it, I will... ! HAVE to know now.. hehe!!

Just makes no sense to have it available at all, if it can only be used on the Domain level, to have it available on the OU level.. !
Or MS was just too lazy... easier to just leave it the same everywhere, even though it has no functionality.. ?!

[Tiger Shark]

Actually, don't bother.... Logically, since the heirarchy is Site - Domain - OU the domain policy would overwrite the Site policy anyway when it runs. The fact that the OU can't override the domain policy with regard to account policies makes no difference i don't think. I have a suspicion from my digging that it has something to do with the domain encryption keys at this point but haven't found anything concrete yet to back that up.

[SawPer]

well... I had a pretty calm morning, so I had to go ahead and test it out.. heh!

These are my findings:

1. Domain GP (Account Policy) - OU GP (A.P.) = Domain GP wins
2. Domain GP with A.P. set to 0 tries lockout threshold (never lock out) - OU GP (A.P.) = Domain GP wins
3. No Domain GP (A.P.) - OU GP (A.P.) = BUG!? The last set Domain GP wins.. lol!

With other words, the Account Policy GP settings are only effective on the Domain GP level, it doesn't matter at all if you try to apply A.P. settings on the OU level.

However, I found a bug, where if you completely disable/uncheck the A.P. settings on the Domain, it won't disable the A.P. ! It will use what ever the policy was set to last.. heh!!

Maaan what a mess those Account Policies are.. !

[Tiger Shark]

It will use what ever the policy was set to last.. heh!!

That's because the policy item is set in the registry of the client and thus if it isn't ovrwritten by another policy then it won't be changed.

[zENGER]

Try adding a freshly installed machine to the domain when the domain policy no longer exists and see what happens.

[SawPer]

Originally posted here by Tiger Shark
That's because the policy item is set in the registry of the client and thus if it isn't ovrwritten by another policy then it won't be changed.

Oh.. I see... well.. I would still consider that a bug though, other GP's do get disabled when you disable them. Not sure which are set in the registry or not though...

Do you happen to know where in the registry this is set? It would give me one more additional test, if I could go in to the registry and completely disable it on the Domain level...!


Thanks!

[SawPer]

Originally posted here by zENGER
Try adding a freshly installed machine to the domain when the domain policy no longer exists and see what happens.

Hehe!! Good thought!

Now that is time consuming though.. I probably won't have that time today...
Hmm... in best case, the Domain policy won't be there, but the OU policy still has no functionality... so I guess it won't really matter... unless an OU A.P. policy isn't getting written in the registry, and the registry is currently overriding the OU policy.. heh?

[Tiger Shark]

Let me try to predict the outcome:

1. Client: Clean install never joined to a domain. Domain has no particular policy set. OU has no particular policy set, (default policies at the local level, OU level and domain level are all the same IIRC). Client is joined to the domain:-

Result: Client maintains the default local policy as set at install, (though it has been set by the domain - if the domain policy was altered from the default this would have been reflected at the client).

2. Client: Clean install joined to a domain. Domain has no particular policy set. OU has policy changed to a custom policy, client policy refreshed:-

Result: Client maintains the default local policy as set at install, (Domain policy is still in effect).

3. Client: Clean install joined to a domain. Domain has custom policy, (different from OU), set. OU has policy maintains a custom policy, client policy refreshed:-

Result: Client adopts the custom domain policy.

However.... While looking to see _exactly_ why there can only be a single "Account Policy" in a domain I found, in the "time honored tradition" of Microsoft, this clearly contradictory information....

By default, Account Policies (Password, Lockout, and Kerberos settings) are all defined in the Default Domain GPO. Since Domain Controllers are responsible for enforcing these domain-wide policies, Domain Controllers always receive these settings from the Default Domain GPO. Furthermore, since Password and Lockout Policies are defined in the Default Domain GPO, all Windows 2000 machines in that domain obtain the same password and lockout policies for their local Security Accounts Manager (SAM) database even though they have their own default local account policies defined. This happens because domain-level policies have precedence over local policies. Note that it is possible to specify a different local password policy on workstations or servers by including those workstations or servers in an OU which has its own account policy settings. This is because an OU policy has precedence over a domain policy.

Source

Which is the way it _should_ be.... But I thought we have ascertained that the domain account policy is not able to be overridden....

I also found this that might be important in the testing methodology:-

Also, do not confuse domain accounts and local accounts. If a workstation is in a domain and a user logs on with a LOCAL account only, any domain user account configuration GPO settings are not processed because the account is local. Also, if you log on to a domain member that is disconnected from the network with a CACHED DOMAIN ID, you will not get your UPDATED user configuration settings. You will log on with the CACHED credentials ONLY.

To demonstrate the contradictory nature of M$:-

When you set account policies (including password policies, account lockout policies, and Kerberos policies) in Active Directory, there can only be one domain account policy throughout all servers, workstations, and domain controllers in the domain. The policy is the account policy that is applied at the root domain of a domain tree. Although account policies affect user accounts, the policies are defined on computers.

Source

Hmmm.... Technet doesn't agree with resources..... But it seems that in real life technet is more accurate... The answer to the question "Why?" is still unanswered.... and I still lean towards it being the kerberos settings which are unavailable in the local policy and I believe must be the same domain wide but no-one ever seems to have deemed fit to write about why to confirm or deny my theory.....

I remain "seeking enlightenment"....