Re: Password policy, no override



I feel I must chime in here to clear up any confusion.
DCs will ignore any password policies you set at the domain controller
container.
password policies, account policies, kerberos policies, (and a couple other
individual settings) must be configured in a GPO that is linked to the
domain container.
This is because MS does not want to assume you will keep your DCs in the
default DC container, and MS must guarantee consistent security policies
across all DCs in a domain. The only way to achieve this guarantee is to
force certain settings to be linked to the domain container for DCs to read
and apply them.

Also, like Cary indicated, if you are interested in controlling the
passoword policies for local accounts on workstations and servers, then you
must setup an OU for those systems and configure and link a GPO with those
settings to the OU.


--
Glenn LeCheminant
CCNA, MCSE 2000/2003 + Security

"Cary Shultz [A.D. MVP]" <cwshultz@xxxxxxxx> wrote in message
news:OZs9%23fFbFHA.464@xxxxxxxxxxxxxxxxxxxxxxx
> The AD Designer,
>
> Again, I would disagree with setting the password policy on the Default
> Domain Controller Policy. It should be set in the Domain Security Policy.
>
> And setting a password policy at the domain level ( which is what we are
> doing with the Domain Security Policy ) will not affect users logging in
> locally on the machines ( assuming that they are using a local user
> account and not the Domain user account object ). The only way to set a
> password policy to affect the local user accounts is to create a GPO at
> the OU level, linking it to the OU that contains the computer account
> objects. Doing so will not affect users logging on with the Domain user
> account object but will affect users logging on with local user accounts.
>
> Sorry, I am just not sure from where you have your information?
>
> --
> Cary W. Shultz
> Roanoke, VA 24012
> Microsoft Active Directory MVP
>
> http://www.activedirectory-win2000.com
> http://www.grouppolicy-win2000.com
>
>
>
> "The AD Designer" <TheADDesigner@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
> message news:F4B2EC41-2925-4784-8BCA-9B096C8C76B7@xxxxxxxxxxxxxxxx
>> Hi bill
>>
>> It will have more than just one even if you only have a domain policy
>> set.
>> Policies in general follow the following order. and each is inherited
>> from
>> above. if i set a policy on site, then change the same setting on domain
>> the
>> domain policy is in effect(thus over written).
>>
>> local
>> site
>> domain
>> ou
>>
>> I just finnished two huge projects (one have 500,000 nodes and another
>> 18,000)where the password policies were set on the domain controllers
>> policy
>> and it worked as on the tin. setting a policy domin wide would impact
>> users
>> who have computers in a domain but log in locally to a pc. Remember
>> password
>> policy is on the computer object not the user. set the password policy on
>> the
>> domain controllers policy this ensures all AD user objects are effected
>> by
>> the policy.
>>
>>
>>
>>
>> "Bill" wrote:
>>
>>> gpresult tells me my user account is receiving settings from the default
>>> domain policy, but it doesn't tell me why my default domain policy,
>>> directly
>>> beneath the domain OU, is being overwritten.
>>>
>>>
>>>
>>> "The AD Designer" wrote:
>>>
>>> > I dont think that there is a "domain securiy policy" available..
>>> >
>>> > As for where the policy is coming from you will need to run gpresult.
>>> >
>>> >
>>> > "Cary Shultz [A.D. MVP]" wrote:
>>> >
>>> > > The AD Designer,
>>> > >
>>> > > Not sure that I agree with this. I have always set Password
>>> > > Policies in the
>>> > > 'Domain Security Policy'.
>>> > >
>>> > > --
>>> > > Cary W. Shultz
>>> > > Roanoke, VA 24012
>>> > > Microsoft Active Directory MVP
>>> > >
>>> > > http://www.activedirectory-win2000.com
>>> > > http://www.grouppolicy-win2000.com
>>> > >
>>> > >
>>> > >
>>> > > "The AD Designer" <TheADDesigner@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
>>> > > message
>>> > > news:3C807252-34DF-425D-AB17-5B0CC0A1A9CA@xxxxxxxxxxxxxxxx
>>> > > > Bill
>>> > > >
>>> > > > password policy should only be set on your default domain
>>> > > > controllers
>>> > > > policy
>>> > > > not you default domain policy.
>>> > > >
>>> > > > Regards
>>> > > >
>>> > > > "Bill" wrote:
>>> > > >
>>> > > >> My default domain policy's computer settings, (min password
>>> > > >> length,
>>> > > >> lockout
>>> > > >> duration, etc.) kept being set back to their old settings a few
>>> > > >> minutes
>>> > > >> after modifying them. It wasn't until I checked the enforced
>>> > > >> checkbox on
>>> > > >> the
>>> > > >> gpo that the default domain policy computer settings remained
>>> > > >> changed
>>> > > >> permanently. Strangely enough, the computer portion of the GPO
>>> > > >> remained
>>> > > >> unchanged, the login banner. I don't understand why checking the
>>> > > >> enforced,
>>> > > >> no override, box fixed the problem, or why it was a problem to
>>> > > >> begin
>>> > > >> with. I
>>> > > >> also recently experienced the same problem, and solution, at a
>>> > > >> bottom
>>> > > >> level
>>> > > >> OU policy in the computer settings of a GPO.
>>> > > >>
>>> > > >> thank you,
>>> > > >> Bill
>>> > > >>
>>> > >
>>> > >
>>> > >
>
>


.



Relevant Pages

  • Re: Security Breach in AD! Help!
    ... > about 5 minutes the user was removed from the built in admin group. ... > changed the default domain policy, the default domain controller policy, ... >> auditing of account logon for success and failure and account management ... >> success and failure in Domain Controller Security Policy. ...
    (microsoft.public.win2000.security)
  • Re: Re-occuring error message SceClient 1202 Application Log error
    ... rights assignments. ... IUSER_EEHQ-f001 is not my account, but probably> some system created account. ... >>> SeNetworkLogonRight must be assigned to Enterprise Controllers account for>>> policy propagation and replication to succeed. ... Looks like the default>> domain controller GPO. ...
    (microsoft.public.windows.server.migration)
  • Re: Domain users unable to change password
    ... are not configured to not allow user to change password in account ... I can't think of a Group Policy setting offhand but if you have a Windows ... 2003 domain controller try running the Resultant Set of Policy mmc snapin in ... connectivity, replication, and secure channel/computer account integrity. ...
    (microsoft.public.windows.group_policy)
  • Re: Simple question on Group Policy, Password policy and blocking inheritance
    ... My point was that you can use fine-grained password policies to specify multiple password policies and apply different password restrictions and account lockout policies to different sets of users within a single domain, ... > trying to enforce a password policy for the entire company. ... create a policy and make sure that is linked at domain level. ... > restoring their 'Default Domain Policy' and 'Default Domain Controller ...
    (microsoft.public.windows.server.active_directory)
  • Re: Cannot edit "Log on as a service" and "Allow log on locally" policies on W2K3 server.
    ... I am installing a new version of a program on my W2K3 SP1 server and one of the requirements is to create a "local" user account and grant this account ... However when I go into the Local Security Policy editor/Security settings/Local Policies/User Rights Assignment, I do not get the option to add or edit. ... These two policies both have different icons showing so I'm not sure what that indicates but am sure it has to do with why I cannot make any changes there. ... drill down to those settings and it'll tell you which policy is applying to those settings. ...
    (microsoft.public.windows.server.general)