[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,
http://www.specopssoft.com/products/specopsgpupdate/
<http://www.specopssoft.com/products/specopsgpupdate/>
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
accounts.
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,
Cordialement,
Kind Regards,
Schillebeeks Bart
Active Directory Security Consultant
Small and Departmental Systems - NT Systems Fortis Bank
Bart.schillebeeks@xxxxxxxxxxxxxx
AD Internet Consulting BVBA
Disclaimer:
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
Hello,
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
Martin_Hugo@xxxxxxxx
Other related posts:
