[gptalk] Re: Password Policy Creation

  • From: Thorbjörn Sjövold <thorbjorn.sjovold@xxxxxxxxxxxxxxx>
  • To: <gptalk@xxxxxxxxxxxxx>
  • Date: Wed, 2 May 2007 19:51:08 +0200

Bart, great description of the oddities of domain Password Policy setting, a 
problem as old as Group Policy itself, but I would like to add that it is 
actually not possible to link a GPO to the Domain Controllers OU, or any other 
OU for that matter, we did some serious investigation of the Password Policy  
behavior when we designed our Specops Password Policy product and I have for a 
long time intended to summarize and share our findings with the community since 
this one of the most magical parts of Group Policy and when I read this post, 
which is like the ten thousand time I have heard about the problem :), I 
decided that it was the time to do it... Feel free to send me feedback on it 
since I am intending to put together a white paper, article or something around 
the issue, especially now that Longhorn is in the horizon adding even more 
options and complexity to the mix.



General rule for Password Policy settings:

You can set the Password Policy in any GPO and link it anywhere, but only GPOs 
linked to the Domain will be used for domain accounts. GPOs linked to an OU 
will only be used to configure the Password Policy settings for the local SAM 
to the computers where the GPO apply, i.e. the users local to a workstation or 
member server. Any GPO linked to the domain will of course also apply to the 
local accounts, but contrary to the domain Password Policy settings these 
adhere to the normal GP processing order and can be overridden. This behavior 
is by designs and built into the Security GP Client Side Extension (CSE) that 
manages the Password Policy settings, read on and you'll find out why.

You can have only one Password policy setting per domain.

Computer vs. User part of the GPO

Although it is obvious when editing the GPO that the setting is on the computer 
part, many tend to forget this when it is time to link the GPO. Again the 
Password Policy settings is on the computer part of the GPO, so even if it was 
possible to set the built-in Password Policy for the domain on any OU it would 
still not work for OUs with users... The main reason for being a computer part 
is simply how Group Policy is processed, i.e. it is a technical reason, but 
when you think about it, but it is really a user setting compared to other GP 
settings, so it is not really that strange when people trip on this.

Default Domain Policy

It is not necessary to use the Default Domain Policy to configure Password 
Policy, there are even some people recommending not to do it, any GPO linked to 
the domain will work, if there are more than one GPO configured with Password 
Policy settings on the domain level (which makes little sense normally), then 
normal GP link order will kick in and be used to find the winner. 

Block inheritance

Although that it is not possible to override the Password Policy settings on 
the OU level, it is possible to block the domain linked GPOs on a OU, for 
example if blocking is set on the Domain Controller OU, where the DCs normally 
reside, then the GPOs from the domain level will not be applied, i.e. no 
Password Policy settings will be set, but the old ones will still be in effect. 
The reason that this GP configuration option actually works is also technical, 
all GP CSE are being fed with the GPOs to apply from Winlogon (the GP Service 
in Vista), and because of this the Security CSE will not receive the list of 
GPOs, having written several GP CSEs myself, my guess is that it works this way 
more "by accident" than "by design" :)

Tattooing and 'Not Defined'

A phrase that is often used in the GPO world is Tattooing, that basically means 
that it is possible to restore the setting that was in effect before the GPO 
setting was applied. The interesting thing about this is that this is really 
something that every GP Extension CSE has to manage by itself and nothing 
automagically related to Group Policy, and it is really the Registry CSE, that 
is of course extremely central in the GP world, from where this originated. But 
the Security CSE is not really the best extension when it comes to this so when 
the option Not Defined is used this will not revert to the previous value, but 
rather leave the old value there in effect. Actually when the Not Defined 
setting is used, then other GPOs linked to the domain with a lower precedence 
that have that settings defined will be applied for that value. Still multiple 
GPOs for this is not really the best design, but that is how it works.

Other settings that are affected and the main reason behind the problem:

This "problem" is normally discussed when it comes to the Password Policy 
settings, but there are actually some other settings that behaves the same way, 
besides the obvious settings under "Account Policies", e.g. Password Policies, 
Kerberos settings etc, and that is the settings to change the Administrator and 
Guest account names. So what is the reason all these settings can only be set 
on the domain level and only on the computer part of the GPO although most of 
them are really User settings that should be applied to OUs with users in them? 
Basically there are three reasons that combined gives the answer.

1)      The implementation is of technical nature - The user part of the GPOs 
only apply where the user are actually logged on and since the settings are 
being enforced on Domain Controllers, by password filters etc, the most 
straight forward and easy to implement solution is to apply the settings to the 
domain controllers with the computer part that applies to the DCs and store it 
there and using the stored settings when needed, although it is technically 
possible to implement it as an user side setting and then apply the GPOs to 
OUs, filtered by security groups etc, it takes a lot more work to write that 
type of implementation since each component would have to evaluate the GPOs on 
the fly. But there are APIs for this and for example the Remote Installation 
Services extension works pretty much like this. Also there would be some 
settings left that would not fit into this equation, for example certain 
Kerberos settings would not really fit into the equation, for example the 
maximum difference between computer clocks when looking at Kerberos tickets, 
but of course this setting is more of Computer part setting anyway and could 
have stayed there.

2)      Domain Controllers can be moved to other OUs than the Domain 
Controllers OU- Most likely the number one reason for the need to always link 
to the domain since all DCs need to get the settings. Moving DCs to other 
places in AD is not really something I would recommend, but it is possible and 
that is the problem in this case, since that would mean that different DCs 
could get different settings, ouch...

3)      AD multi master replication - Even if it would be possible for DCs to 
get different settings, the multi master replication would really make a mess 
of this, since every time a DC gets a domain wide setting it would replicate 
this to the others DCs, so basically the DC that gets the last Password Policy 
would replicate its setting the other DCs since the value is stored in AD.


For those of you that have read all the way down here, hope you enjoyed reading 
this rather long post  ;) 


Thorbjörn Sjövold

Special Operations Software

www.specopssoft.com <http://www.specopssoft.com> 

thorbjorn.sjovold a t specopssoft.com


Download our free tool for remote Gpupdate with graphical reporting, 


From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On 
Behalf Of bart.schillebeeks@xxxxxxxxxx
Sent: den 2 maj 2007 15:40
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Password Policy Creation


Hoy Hugo, 


The password policy that is defined in the root, or at the domain controllers 
OU is domain wide, and will affect your AD accounts. 


If you set a password policy for a special machine OU for example , it will set 
the settings for that/those Local machines and local user accounts only !!


Only Local accounts of those machines are subject to this policy, NOT domain 



Settings in "machine settings" always apply to the machines (HKLM) and need te 
be applied to machine OU's . 

 Settings in "user settings" always apply to the users (HKCU) and need te be 
applied to User OU's . 


To make administration easyer i would suggest you don't mix the machine/user 
part of gpo's , and create one machine gpo, and one user gpo. 

Vriendelijke groeten,
Kind Regards, 
Schillebeeks Bart
Active Directory Security Consultant
Small and Departmental Systems - NT Systems Fortis Bank
AD Internet Consulting BVBA

Any views expressed in this message are those of the individual sender, except 
where the message states otherwise and the sender is authorised to state them 
to be the views of any such entity.This Message is in no way legally binding 
and has to be viewed as a personal opinion of the sender. This message reflects 
in no way the views of FORTIS BANK and its associates and AD internet 
Consulting BVBA and its associates. Unless otherwise stated, any pricing 
information given in this message is indicative only, is subject to change and 
does not constitute an offer to deal at any price quoted. Any reference to the 
terms of executed transactions should be treated as preliminary only and 
subject to our formal written confirmation.

AD Internet Consulting BVBA, Hezemeer 7, 2430 Eindhout-Laakdal ON:0470419019 
www.adinternet.com mailto:Sales@xxxxxxxxxxxxxx





From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On 
Behalf Of Martin Hugo
Sent: Wednesday, May 02, 2007 3:21 PM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Password Policy Creation


I have always been led to believe that Password Policy (password life, 
complexity, etc.) is a domain-wide setting.  Yet, I can create Gp Policies with 
password settings in them and apply them at the OU level below the root.  Would 
this not result in different password requirements by OU?

If so, do I apply the policy to a user OU or a Machine OU (since the setting is 
in the machine setings)?

Thanks very much.

Martin T. Hugo
Network Administrator
Hilliard City Schools
Tel: 614-921-7102

Other related posts: