Archived from groups: microsoft.public.win2000.group_policy (
More info?)
Glad to be helpful! If you have any more questions you know where to reach
us!
Cary
"Ken B" <none@microsoft.com> wrote in message
news:e18$iVttEHA.3156@TK2MSFTNGP12.phx.gbl...
> Yup... all that makes sense now
>
> Thanks for clearing it up!
>
> Ken
> "Cary Shultz [A.D. MVP]" <cwshultz@mvps.org> wrote in message
> news:eMmu4DstEHA.2808@TK2MSFTNGP14.phx.gbl...
> > Ken,
> >
> > Each Domain would have its own Password Policy. Sorry, I should have
> > explicitly stated that in my first response so that we would not have
> > needed
> > the additional thread ( read: you would have had your answer much
> > sooner ).
> > So, the Password Policy that is set at corporation.local has no bearing
on
> > any other domain in the tree / forest. Same for
> > thisdomain.corporation.local and for thatdomain.corporation.local. I
> > would
> > suggest that you set up this Password Policy by using the Domain
Security
> > Policy.
> >
> > The Password Policy is often the reason for having multiple domains. If
> > one
> > 'department' or 'division' wants to have super complex passwords with a
> > shorter password age and many passwords remembered while another does
not
> > seem bothered by this the 'wanting' department or division will often
> > fight
> > for a separate domain within the tree.
> >
> > You can have only one password policy in each domain. And it must be
set
> > at
> > the domain level.
> >
> > I hesitate to mention this because it almost always leads to confusion -
> > so
> > take this with a grain of salt!
> >
> > You can set a password policy at the OU level. However, it has
absolutely
> > no bearing whatsoever on your domain user account objects. it does,
> > however, affect only those local user accounts on each workstation that
> > directly resides in the OU to which this Policy was linked. So, you can
> > use
> > your domain user account object and log on to one of these workstations
> > and
> > that Policy that is linked to that OU will not have any affect on your
> > domain user account object. Now, log on locally to that machine ( say,
> > with the local Administrator account ) and badda bing! badda bam! that
> > user
> > account is affected by that Policy that is linked to the OU. Makes
sense?
> >
> > HTH,
> >
> > Cary
> >
> > "Ken B" <none@microsoft.com> wrote in message
> > news:ObR9zyrtEHA.1272@TK2MSFTNGP12.phx.gbl...
> >> Right, Cary. But, corporation.local is a domain in and of itself, and
so
> > are
> >> "thisdomain.corporation.local" and "thatdomain.corporation.local".
Would
> >> thisdomain be able to have a separate password policy from thatdomain,
or
> >> would password policy only be configurable at the "corporation.local"
> > level?
> >>
> >> Ken
> >>
> >> "Cary Shultz [A.D. MVP]" <cwshultz@mvps.org> wrote in message
> >> news:%23zWScErtEHA.2000@TK2MSFTNGP14.phx.gbl...
> >> > Ken,
> >> >
> >> > As I stated, the Password Policy is set at the Domain level.
> >> >
> >> > HTH,
> >> >
> >> > Cary
> >> >
> >> > "Ken B" <none@microsoft.com> wrote in message
> >> > news:O60ccmqtEHA.156@TK2MSFTNGP10.phx.gbl...
> >> >> I'm wondering how the password policy is affected by a domain being
a
> >> > child
> >> >> domain. For instance, you have
> >> >>
> >> >> corporation.local
> >> >> / \
> >> >> / \
> >> >> thisdomain thatdomain
> >> >>
> >> >> Could "thisdomain(.corporation.local)" have a separate password
policy
> >> > from
> >> >> "thatdomain(.corporation.local)" which are both child domains of
> >> >> corporation.local? I left off the fqdn for the children for space
> >> >> constraints
> >> >>
> >> >> Ken
> >> >>
> >> >>
> >> >> "Cary Shultz [A.D. MVP]" <cwshultz@mvps.org> wrote in message
> >> >> news:%23Pcog%23gtEHA.1336@tk2msftngp13.phx.gbl...
> >> >> > Cherly,
> >> >> >
> >> >> > This is an extremely common question. It is asked a ton of times
in
> >> > this
> >> >> > ng
> >> >> > as well as in the AD ng.
> >> >> >
> >> >> > The Password Policy is set at the Domain level and applies to all
> >> >> > users.
> >> >> > Period! This is no way - short of creating another domain and
> >> >> > moving
> >> >> > those
> >> >> > users to that newly created domain - of having multiple password
> >> > policies.
> >> >> >
> >> >> > Any password policy set at the OU level will affect only those
local
> >> > user
> >> >> > accounts logging on ( naturally, locally ) to any computer account
> >> > objects
> >> >> > that reside directly in that OU. In other words, you can do this
> >> >> > but
> >> >> > it
> >> >> > has
> >> >> > absolutely no effect whatsoever on your domain user account
objects.
> >> >> >
> >> >> > You should create the Password Policy in the Default Domain
Security
> >> >> > policy.
> >> >> > I would be more interested in what shows up when you do a 'net
> >> >> > accounts'
> >> >> > at
> >> >> > the command prompt.
> >> >> >
> >> >> > Again, this password policy will affect everyone in the domain.
The
> >> >> > one
> >> >> > thing that you can kinda control is how long a password is valid.
> >> > Usually
> >> >> > you would set up the Password Policy to use passwords that contain
> >> >> > at
> >> >> > least
> >> >> > six characters ( or whatever ) and must meet the password
complexity
> >> >> > requirements and have a password maximum age of 30 days ( or
> > whatever )
> >> >> > and
> >> >> > a minimum age of seven days ( or whatever ) and the policy
remembers
> > 10
> >> >> > passwords ( or whatever ). So, the passwords would be changed
every
> > 30
> >> >> > days
> >> >> > and you would have to go through 10 passwords before you could use
> > the
> >> >> > 'old'
> >> >> > one again. Well, if you open up the Active Directory Users and
> >> >> > Computer
> >> >> > MMC
> >> >> > and open up a user account object you can click on the 'Password
> > never
> >> >> > Expires' check box. This creates a situation where - for that
> >> >> > specific
> >> >> > user account object - the 'age' parts of the Password Policy do
not
> >> > apply.
> >> >> > He/she still needs to have a password with at least six characters
> > and
> >> >> > must
> >> >> > meet the password complexity requirements. That will always
apply.
> >> >> > However, the 30 days and seven days and 10 passwords remembered do
> > not
> >> >> > apply.
> >> >> >
> >> >> > But, doing this - even for one user and especially for any
> >> > 'Administrator'
> >> >> > type account - compromises the entire security of your network (
> > well,
> >> >> > this
> >> >> > layer anyway! ). I would rethink this.
> >> >> >
> >> >> > HTH,
> >> >> >
> >> >> > Cary
> >> >> >
> >> >> > "Cheryl Mutschler" <cheryl.mutschler@bch-insurance.com> wrote in
> >> >> > message
> >> >> > news:eUkJyqgtEHA.412@TK2MSFTNGP14.phx.gbl...
> >> >> >> Server 2000
> >> >> >> I removed a password policy that was set at an OU level (I
> > know..bad)
> >> > and
> >> >> >> added a new one at the domain level. I have it only applying to
me
> > and
> >> >> >> not
> >> >> >> all authenticated users.. is that OK to do for testing? After
> > forcing
> >> > the
> >> >> >> refresh, the policy seems to have replicated but when I run net
> >> >> >> user
> >> > for
> >> >> >> myself on the domain, the 'Password expires' and 'Password
> > changeable'
> >> >> > dates
> >> >> >> aren't what I expect. It's almost as if it's holding on to the
> >> >> >> dates
> >> > from
> >> >> >> the previous policy (or something). I think the old policy on the
> >> >> >> OU
> >> >> >> is
> >> >> > gone
> >> >> >> (I checked out the policies in sysvol, the registry, used gpotool
> > ..).
> >> >> >> So,
> >> >> >> is it not working correctly because of how I'm applying it to
only
> >> >> >> myself,
> >> >> >> or the old policy is lingering, or what??
> >> >> >> Thank you for your help!
> >> >> >> Cheryl
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>