Password complexity requirements disabled....

I disabled the password complexity requirements for the domain, but I cannot enter in any password that I desire for some reason.

I followed the Microsoft example and also checked the group policy for the users.

I made sure I disabled password complexity requirements and set the password length to 0...

Anybody have problems with this?

Thanks in advance

Find more posts tagged with

Comments

dynamik

I just tried, and I had to do a gpupdate /force at the command line before it would take effect. You could just reboot too (I don't know if logging off/on would update it).

Also, you can change this option in various places, but you need to do it in the domain security policy if you want it to apply to domain users.

[edit]
Logging on/off doesn't update the policy

MS Technet wrote:

By default, computer Group Policy is updated in the background every 90 minutes, with a random offset of 0 to 30 minutes. In addition to background updates, Group Policy for the computer is always updated when the system starts.

Group Policy Refresh Interval

Goldmember

I forgot to mention I updated the policy using gpupdate /force from the command line as well...

I'm still not able to enter any password. I get an error message.
I double checked and the password complexity is disabled and the password length is 0.

I didn't have a chance to reboot the server...

dynamik

I just want to make sure where you're at.

You're connected to a domain controller, and you updated the "domain security policy", not the "domain controller security policy" or the machine's local policy, correct?

And when you tried adding a new user or changing a user's password in Active Directory Users and Computers, it says that the password does not meet complexity requirements?

I loaded up a VM, and made the changes. It didn't work initially, but a gpudate /force fixed it right away.

Goldmember

All of the above, except when I try to edit the users password it says...

Error, the password cannot be changed.
Either the password doesn't meet the complexity requirements, the password length is invalid, or the password history is not correct.

It gives me those 3 reasons as why the password doesn't work, but I tried all of them.

I'm pretty sure I went through all the correct steps.

I basically did everything step by step in this link
http://www.petri.co.il/disable_password_requirement_in_win2003_domain.htm

Thanks for your help

dynamik

Those directions are correct. That's all I had to do on my machine. This has me a bit stumped. I may not be thinking clearly because I'm (supposed to be) studying for a test I have in a couple of hours. I'll keep it on the back burner though.

Just out of curiosity, do you have any errors in your event viewer? In the application section of event viewer, I get an entry that's an "Information" type and "SceCli" is the source whenever I do a gpupdate /force. The details say that, "Security policy in the Group policy objects has been applied successfully." You should check that out and see if there is something wrong with the way your machine is applying the policy.

Sie

Make sure your machine is connected to the domain otherwise it wont pick up the GPO's.

Have you attempted to change this within the local security policy and test just to see if its Domain / Machine based error?

Is it only on the one machine or multiple?

dynamik

Sie wrote:

Make sure your machine is connected to the domain otherwise it wont pick up the GPO's.

Have you attempted to change this within the local security policy and test just to see if its Domain / Machine based error?

Is it only on the one machine or multiple?

My assumption was that he was working directly on the domain controller in his lab, but those are good questions.

However, if he is working on a domain controller, you couldn't test this with local policies since domain controllers do not have local user accounts.

shednik

Is the user possibly in an OU where a different policy has been applied?

Did you try an force rep just incase?

dynamik

shednik wrote:

Is the user possibly in an OU where a different policy has been applied?

Did you try an force rep just incase?

You can only set the password policy in the domain security policy. If he's working with users in Active Directory Users and Computers, this is the only place he can make that change.

The only quasi-exception to this is if you assign a password policy to an OU, then that will affect the local accounts of the computers (password policies are computer settings) in the OU. This might be used if you have some computers that contain sensitive data, and you need a more secure password setting for local accounts on those machines. If you need another wide-reaching password policy, you need to create another domain.

I agree with the previous posters though. Not knowing your specific setup does make things harder to diagnose.

shednik

What I meant is and I may be wrong as I'm not expert in AD and GPOs but can't you specify a policy to a specific OU that will override the default domain policy?

For example at my company we have many OUs for our remote customers and such...for the local users we have something named "MoonTwp" and there is a policy applied to it for just those users and computers. any computers used by this location is in an OU inside of MoonTwp. Couldn't the password policy be set there to override the default domain policy?

dynamik

MS Technet wrote:

Second, the only way to modify the Account Policy settings for a domain user account is within a GPO linked to the domain. GPOs linked to the OU that are configured to alter the Account Policies settings will modify the local SAM of computers that reside in the OU, or are in sub-OUs of the linked OU.

This is talking about how things are changing with Server 2008, but if you scroll down to the "What you can't do with current password policies," it goes into more detail regarding this topic: http://www.microsoft.com/technet/technetmag/issues/2007/12/SecurityWatch/default.aspx

You would be right if it was another policy. The order that GPOs are applied is: local, site, domain, and finally OU. This just isn't how the password policy works for domain users.

sprkymrk

shednik wrote:

What I meant is and I may be wrong as I'm not expert in AD and GPOs but can't you specify a policy to a specific OU that will override the default domain policy?

For example at my company we have many OUs for our remote customers and such...for the local users we have something named "MoonTwp" and there is a policy applied to it for just those users and computers. any computers used by this location is in an OU inside of MoonTwp. Couldn't the password policy be set there to override the default domain policy?

No, as stated earlier if you set a password policy at an OU or computer it will only apply to local accounts on those computers. There can only be ONE password policy for the domain, and that is set at the Domain level. Downlevel policies do not over ride this policy. Looks like that will change in 2008 though:

http://www.microsoft.com/technet/technetmag/issues/2007/12/SecurityWatch/?loc=en

A number of misconceptions about password controls surround the current implementation of Active Directory (in Windows Server 2003), despite years of rigorous testing and no evidence that ever proved those misconceptions to be true. It is clear, or should be, that policy will not work in ways other than as designed.

That said, many administrators believe it's possible to have multiple password policies for users in the same domain. They think you can create a GPO and link it to an Organizational Unit (OU). The idea is to move user accounts to the OU so that the GPO will affect the objects. Within the GPO, the Account Policies are modified to create a more secure Password Policy, perhaps by setting the maximum password length to 14 characters. But, for a several reasons, this configuration will never provide the desired outcome. First, the Password Policy settings are computer-based rather than user-based policies. With this foundation for the settings, they will never affect a user account. Second, the only way to modify the Account Policy settings for a domain user account is within a GPO linked to the domain. GPOs linked to the OU that are configured to alter the Account Policies settings will modify the local SAM of computers that reside in the OU, or are in sub-OUs of the linked OU.

Within Windows Server 2008, you won't be establishing Account Policies with the Default Domain Policy. In fact, you won't be using GPOs for creating Account Policies for domain user accounts at all. In Windows Server 2008, you will be directed into the Active Directory database to make your modifications. Specifically, you will use a tool like ADSIEdit to modify the Active Directory object and its associated attributes.

sprkymrk

Doh! Good one dynamik! You beat me again, that's twice this week isn't it?

Goldmember

We are running this server as DC on a small domain.

We are going to redo the whole thing, as of now, the DC services basically services only one user.

Win2003R2 is what we are running.

I think maybe our AD is corrupt because the error message said it was an AD error.

What is a good solution to repair AD? I wouldl like to try this for the sake of knowledge.

Thank you

Goldmember

dynamik

sprkymrk wrote:

Doh! Good one dynamik! You beat me again, that's twice this week isn't it?

Yea, that's funny. The other one was only a few minutes apart, but this one was well over an hour. Did you just leave it up and go to lunch?

Goldmember: What is the error message? Did it occur as a result of the gpupdate /force?

Goldmember

We have decided, at my place of work, to repair the AD, since this is a small production DC running 2003.

What is the best way to repair AD on Win2003?

In Response to Dynamik..
I will let you know soon enough..

Goldmember

Goldmember

I found the solution! and it was simple!

After searching all internet sources, and there were tons of stumped techies in forums asking the same question, I found no correct answers...

So I turned to GPMC and it was the simplest fix...

Using Group Policy Management Console
1)Navigate to the domain you want to configure and double click the domain name
2)Under the Linked Group Policy Objects tab make sure you see Default Domain Policy under the GPO Column, this is the GPO that controls the password complexity for the domain
3)There should be a column that says Enforced. Make sure the Default Domain Policy has the Enforced column value of 'YES'. If not, right click the value and check 'YES'.
4) That should do it. Simple as pie. I did a gpupdate /force at the command line for good measure.

The whole problem was the Default Domain policy was never enforced!!! Even after disabling the password complexity, changing the length to 0, and issuing gpupdate /force at the command line.

It makes sense. You can't update a policy that is never enforced to begin with. So go change your complexity password issues in peace.

Goldmember
Hero for the day