• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 453
  • Last Modified:

Password Policy for Windows 2003

I am running a windows 2003 domain and I implemented the following password policy:

Policy                                     Setting
Enforce password history      24 passwords remembered
Maximum password age      182 days
Minimum password age      2 days
Minimum password length      5 characters

I changed these settings in the default domain controller policy. I have verified that no other policies at any level Site, Domain, OU have any other policy settings. The problem is users are still being asked to change their passwords about every 40 days. Any ideas on what is causing this?
0
heco
Asked:
heco
  • 7
  • 6
  • 5
2 Solutions
 
rutten-dCommented:
you should set this policy in the default domain policy instead of the domaincontroller policy.
0
 
hecoAuthor Commented:
Thanks for the quick response. Any specific reason for setting it there instead of the domaincontroller policy?
0
 
Netman66Commented:
The Default Domain Controller policy only governs logons on the DC.  For Domain-wide policies, use the Default Domain Policy.

0
Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
hecoAuthor Commented:
I agree. I know there can only be one password policy for the domain users so I edited the default domain controllers policy to add the password policy. So if I wanted to add a different password policy for a computers local accounts I could add another password policy on that OU. I'm just wondering why it is being suggested to put it into the default domain policy.
0
 
Netman66Commented:
No, that's not true.

There can only be one Account Policy in the Domain.  It cannot be blocked or overridden.  Setting it on the Default Domain Controller Policy does not apply it to the domain, but rather the local logon to the servers (local accounts) - which, depending on the account, may be AD accounts too (like Administrator).

Adding different Account Policies to different OUs only succeeds in controlling local account logons - not domain account logons.

In order to make your policy apply to the domain it MUST be in the Default Domain Policy.

I hope this clears it up a bit.
0
 
rutten-dCommented:
there can be more than one passwordpolicy per domain , if you use filtering by security groups.
Passwordpolicies can only be applied on the domain level.
0
 
Netman66Commented:
rutten-d - there can only be one account policy per domain that affects domain accounts.  You cannot have more than one per domain.  It cannot be blocked or overridden.

http://support.microsoft.com/kb/255550/en-us



0
 
rutten-dCommented:
hi netman66


this is a statement made by an MCT who I got my mcse2003 upgrade from.
since the article you refer to applies to win2000 , I'm testing it at this moment in  a virtual lab on 2003 - if it does'n't work I'm going to whip some MCT booty... :-)
0
 
rutten-dCommented:
I did some tests:

setup AD-domain with default settings ,
removed password policy settings from the Default Domain Policy ,
created two new policies - one requiring passwordlength of 10 chars , one requiring 14 chars
made policy 1 apply to computer 1 and policy 2 to computer 2

As Netman66 stated , it doesn't appear to work - although gpresult shows that the settings are applied ...
Actually - in the setup described above I was completely unable to reset my own password as an ordinary user ,
so it appears that some mechanism only accepts password policy settings from the default domain policy .

There are more things I could have tested , like deleting the defdomainpolicy , but that wouldn't be realsitic in real life.

Credits to you , Netman66
0
 
Netman66Commented:
I was also an MCT for 4 years, and never heard of the technique you mentioned here.  In theory, you made an interesting point, but the reality is that Account Policies only come from the Default Domain Policy and nowhere else.

It made me think about it, and finding an article to back my statement wasn't the least bit easy.  I think it's in the Active Directory course material I used to deliver and therefore not searchable online.

At any rate, one Account Policy governs the Domain logons - any number of lower level policies can be used to govern local logons though.  However, in a domain environment, local logons aren't tremendously useful.

Regards,
NM
0
 
rutten-dCommented:
well heco ,

i hope you got your answer...  :-)
0
 
hecoAuthor Commented:
Thank you Netman66 and rutten-d.

Netman66 - My understanding of the way the password policy works is that the domain controller is holding the account database for the domain so you can apply a password policy on the domain controllers ou for the domain users accounts and the built in accounts. It is recommended to put the password policy in the default domain policy but you can create a policy and link it to the domain controller OU as long as you don't have another password policy set anywhere else. Please check out this article, it is where I am getting my information from:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/stepbystep/strngpw.mspx#EBAA

The two sections of intereset are Storing Password Policy Information and Implementing Password Policy Settings
0
 
Netman66Commented:
Please cut and paste the sentences you believe state that password policies can be set on the Default Domain Controller policy or that OU - I don't see them.

The article specifically states that there can only be one password policy per domain and it must be linked at the root container.  They mention a Default Domain Controller policy only in the context that it is created along with the Default Domain Policy by default when AD is installed.  I see nothing there that states your password policies can and should be set there.

If you think about Group Policy Objects they are linked at certain levels (domain, site or OU) and affect everything in the container they are linked to and their children (by inheritance).  If you link a password policy on the Domain Controlllers OU then it only affects the DC directly and thus only a local logon to those DCs (which don't exist).

I'm not trying to be argumentative, I'm simply attempting to explain this a little better.

That is a good article though - and it backs up my statement about one Account policy per domain much better than the article I linked to earlier.



0
 
hecoAuthor Commented:
I greatly appreciate your help netman66. Under the paragraph Storing Password Policy Information there is a sentence that starts out saying "An Active Directory domain is considered a single account database." My understanding of all this is if you apply a password policy to a domain controller ou it will (it's working on my other domains) still work. The policy doesn't apply only to a local DCs accounts (which don't exist) but instead affecfs the AD user database.

Also under Storing Password Policy Information is this paragraph which talks about being able to apply it directly to an OU and not at the root:

It is a best practice to avoid modifying these built-in GPOs. If you need to apply password policy settings that diverge from the default settings, you should create a new GPO instead and link it to the root container for the domain, or to the Domain Controllers OU and assign it a higher priority than the built-in GPO. If two GPOs that have conflicting settings are linked to the same container, the one with higher priority takes precedence.

When I set this up I wanted the password policy to only affect domain users accounts and not the local accounts on the workstations. I removed the password policy setting from the default domain policy and set them in the default domain controller's policy. It is working fine on my other domains but not this one. The users aren't required to change their password  for 182 days but it is expiring around every 30.

I know your not being argumentative, you are very knowledgeable and helpful.
 
0
 
Netman66Commented:
This Security setting actually applies to Domain accounts - both the Computer Account and the User Account - so applying it at the domain level should have no effect for local logons at all.

Applying it to the DC OU doesn't affect either the domain-connected computers or the users that logon with a domain account since neither object exists inside or under the DC OU.  Why it's working on the other domains is anyone's guess.  I suspect it is still picking up settings from the Default Domain Policy or one linked at the domain level.

The second paragraph simply states that it isn't best practice to modify the Default GPOs - either the Default Domain Policy or Default Domain Controller Policy - but rather create new policies and link them appropriately with a higher priority.  In reality, I only use Default Domain Policy for Account Policies and Audit settings.  Anything else I require will go into a new GPO linked where it's needed.  I have never yet had to change a setting in Default Domain Controller Policy for anyone I've done business with.  You *rarely* need to touch that policy - and even then, under very specific circumstances (like SMB signing for downlevel clients).

You should run up GPMC.msc on those other domains and do a RSoP for a user and workstation under the domain - this will tell you exactly where the password policies are coming from.



0
 
hecoAuthor Commented:
I went ahead and took out the policy for the default domain controller's policy and moved it to the default domain policy. I am keeping an eye out to see if the problem still occurs.
0
 
Netman66Commented:
Ok.  I think you should see what you expect to see now.
0
 
hecoAuthor Commented:
I appreciate both of your inputs. The problem seems to be fixed. Thanks!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Certified Penetration Testing

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

  • 7
  • 6
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now