Is my AD broke or is it me?

I am a new Sys Admin at a company where all the IT support has either been fried, quit, or disappeared, and I’ve been having problems with my AD since the beginning.

Currently we have two Win2k3 SP2 servers running as DC’s. The domain functional level is Windows Server 2003. All of my test clients are Windows XP SP3.

On my Desktop I run XP SP3, I have installed both W2k3 Admintools SP2 and The GPMC SP1. This is where I have been doing my policy editing.

Current default domain policy:
Computer Config> Win Settings> Account Policies> Password Policy

Enforce password history – Not defined
Maximum password age – Not defined
Minimum password age – Not defined
Minimum Password Length – 6 Char
Complexity Requirements – not defined
Reversible Encryption – not defined

So I added a new employee to the domain the other day and told him to change his password. He could not because he received this error:

"Your password must be at least 6 characters, cannot repeat any of your previous 3 passwords and must be at least 1 days old.”

I thought this was odd, but I had other things to do so I just changed it in the ADUC (Active Directory Users and Computers).

So I was trying to enable the complexity requirement on the Default Domain Policy and I continued to get the same error.

"Your password must be at least 6 characters, cannot repeat any of your previous 3 passwords and must be at least 1 days old.”

The password I was testing was Password123! Which I would think should meet complexity requirements.

I go back change the things around, change the min and max age, the char length, I still get the same error. I refresh the policy from the MSC console, same error, I run gpupdate /force on both dc’s AND the client, same error.

I do some reading on the net which said to try change the passwords complexity requirements from *not defined* to disabled because sometimes that causes a problem.

Refresh, gpupdate /force on all machines, nothing.

I put the test user in his own OU, BLOCK all policy inheritance.

Refresh, gpupdate /force on all machines, nothing.

I DISABLE the entire default domain policy.

Refresh, gpupdate /force on all machines, nothing.

I goto the GPMC> forest> domains> domain> Group Policy Objects and I DISABLE every GPO in the bunch.

Refresh, gpupdate /force on all machines, nothing.

Is it me, am I missing something, or is there something wrong here? I mean if the entire default domain policy is disabled and I do a gpupdate /force than I should be free to put anything in I like right?

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

dynamik

Where are you defining the password policy? You need to do it at the domain. If you do it anywhere else, it only applies to passwords of local accounts.

Also, if you want to check your AD health, run dcdiag from the support tools.

bertieb

I agree with dynamik, use some of the tools to check AD. Have you tried an rsop type query to see what settings the user *should* be coming out with? I recently had an interesting issue with similar symptoms you are seeing where FRS wasn't working correctly and the GPO's were not correctly being sync'd between a particular domain controller.

HeroPsycho

Bear in mind also that complexity requirements can be specially altered. They may have done that and didn't set the error message properly.

I would never disable the default domain policy or default domain controller policy.

If anything, create a new GPO with the settings you want, and make sure it takes precedence in the link order.

And yes, use dcdiag /c /v >dcdiag.log with the support tools on each DC and search for "fail" in them to verify if your AD is healthy.

RTmarc

HeroPsycho wrote: »

I would never disable the default domain policy or default domain controller policy.

I actually disable the default domain and domain controllers policy and replace it with another one. I leave the default policies pristine.

pwjohnston

dynamik wrote: »

Where are you defining the password policy? You need to do it at the domain. If you do it anywhere else, it only applies to passwords of local accounts.

I was doing it on the DC’s themselves, RDPing in, but I set up with the support tools and gpmc to administer the domain from my client machine.

HeroPsycho wrote: »

If anything, create a new GPO with the settings you want, and make sure it takes precedence in the link order.

This is as opposed to just creating an OU and blocking the inheritance. I see how that might work.

HeroPsycho wrote: »

And yes, use dcdiag /c /v >dcdiag.log with the support tools on each DC and search for "fail" in them to verify if your AD is healthy.

This is what I was looking for. I’m going to try this. Thanks.

pwjohnston

RTmarc wrote: »

I actually disable the default domain and domain controllers policy and replace it with another one. I leave the default policies pristine.

That's actually a good idea.

sprkymrk

HeroPsycho wrote: »

If anything, create a new GPO with the settings you want, and make sure it takes precedence in the link order.

That won't work with password policies, which can only be defined in one place for the domain user accounts, and that is in the default domain policy itself. If you define it anywhere else, it applies only to local accounts on computers.

sprkymrk

bertieb wrote: »

where FRS wasn't working correctly and the GPO's were not correctly being sync'd between a particular domain controller.

+1 to this.

pwjohnston wrote:

I put the test user in his own OU, BLOCK all policy inheritance.

Password polices are configured in the Computer Configuration settings, so a user account in an OU with password policies set via GPO will not apply.

Also, any clues in your event logs?

loxleynew

bertieb wrote: »

I agree with dynamik, use some of the tools to check AD. Have you tried an rsop type query to see what settings the user *should* be coming out with? I recently had an interesting issue with similar symptoms you are seeing where FRS wasn't working correctly and the GPO's were not correctly being sync'd between a particular domain controller.

This happened to my DC actually where the FRS was turned off before I got here. Nothing would replicate and therefor adding anything new to the GPO never worked. Had to fix the FRS before it worked.

EDIT: You can also try the gpresult /v on your client computer and see if it's being disabled. Not sure if you made a new GP or just used the default policy.

HeroPsycho

sprkymrk wrote: »

That won't work with password policies, which can only be defined in one place for the domain user accounts, and that is in the default domain policy itself. If you define it anywhere else, it applies only to local accounts on computers.

Correct, I should have been more clear.

Everyone should read this...

Applying Selected Domain and Domain Controller Policy Settings

pwjohnston

sprkymrk wrote: »

Password polices are configured in the Computer Configuration settings, so a user account in an OU with password policies set via GPO will not apply.

All changes were made either to the Default domain policy or in the Test OU Password policy where all inheritance was blocked. All changes were made to Computer Config> Win Settings> Account Policies> Password Policy

sprkymrk wrote: »

Also, any clues in your event logs?

I ran the dcdiag /c /f:logfile.txt and everything passed except for some dns forwarders. I donno what the deal is.

sprkymrk

pwjohnston wrote: »

All changes were made either to the Default domain policy or in the Test OU Password policy where all inheritance was blocked. All changes were made to Computer Config> Win Settings> Account Policies> Password Policy

What I was pointing out is that configurations set in the Computer Configuration area of a GPO will only apply to computers, not users. You made a GPO with changes to the Computer Configuration and then then placed a USER in the Test OU. So there are two things I gather about your test, the way you described it:

1. Unless you placed a COMPUTER (not a USER) in your test OU, nothing would happen.

2. Even if you did place a computer in the test OU, unless you tested the settings with a local user account on that computer (not a domain user) nothing would happen. *

It seems counter-intuitive that a password policy that affects users would be located in the Computer Configuration area of a GPO, but it's because that policy affects the domain controllers, which then controls the password policy for domain user accounts. Similarily, when applied to a site/OU from a GPO it affects only local accounts on computers in those sites/OU's. The concept is a bit difficult to grasp I admit.

Note:
*I don't think block inheritance would work against the password policy since the domain controller is not located in this OU.

pwjohnston

I figured it out.

First of all thanks to everyone who replied on this. If you have not tried this tool I would HIGHLY recommend it!!!

How to use the Microsoft Group Policy Diagnostic Best Practice Analyzer (GPDBPA) tool to collect and to analyze data

http://support.microsoft.com/kb/940122

Now sadly I must hang my head between my legs because I am having a total Sling Blade moment. “Ain’t got no gas in it, ummmmhum!”

I kept processing it, in my head, as a user policy and not a computer policy. I didn’t think to realize that the computer account for the machine I’m using for testing actually was NOT in the AD U&C? Did I check this? NO! Should I have? Yes! Especially considering we have about 100 machines here both servers and clients and there are about 15 in the AD U&C, WTF? I don’t know why I wouldn't have thought that considering how messed up the AD at this place is to begin with.

sprkymrk was totally right. Anyway, thanks again.

sprkymrk

Thanks for the update and the plug for the GPDBPA tool, which I have heard of, but never used. Glad you got it worked out.

blargoe

sprkymrk wrote: »

That won't work with password policies, which can only be defined in one place for the domain user accounts, and that is in the default domain policy itself. If you define it anywhere else, it applies only to local accounts on computers.

This isn't exactly true. You can get it to work if you define it in another policy that is scoped to the domain object, but Microsoft won't really support it and it can cause issues. Or so the engineer that came to our house from Microsoft told us. The AD I took over had it in a policy named something else but scoped to the domain.

JBrown

Offtopic but related to AD.

I would highly recommend to go over DNS and make sure that its set up correctly. Make sure that DCs are able to ping each other by IP/name/ SVR and _msdcs records. Healthy DNS solves 25% of AD problems.

HeroPsycho

JBrown wrote: »

Offtopic but related to AD.

I would highly recommend to go over DNS and make sure that its set up correctly. Make sure that DCs are able to ping each other by IP/name/ SVR and _msdcs records. Healthy DNS solves 25% of AD problems.

That's what dcdiag is for.

JBrown

HeroPsycho wrote: »

That's what dcdiag is for.

Yes, dcdiag is for DC health indeed. But not DNS in general. That is why I said "offtopic"

I have seen networks where dcdiag would pass tests with out any problems but user workstations could not resolve each other or a file server in another site/branch.

HeroPsycho

JBrown wrote: »

Offtopic but related to AD.

I would highly recommend to go over DNS and make sure that its set up correctly. Make sure that DCs are able to ping each other by IP/name/ SVR and _msdcs records. Healthy DNS solves 25% of AD problems.

THAT is what DCDiag is for. I don't see where you or anyone else here mentioned troubleshooting workstations not being able to resolve file servers. You seem to imply you needed to ping manually every A, PTR, and SRV record associated to each DC in order to validate DNS from an AD perspective.

Use DCDiag instead to preserve free time and sanity.

Edit: you can use NetDiag for that kind of DNS troubleshooting....