Active Directory Will Not Lockout Account

Hello Experts,

We have an Active Directory policy to lockout user accounts after 5 invalid attempts and for 60 minutes. However I can't for the life of me get an account to lockout. This use to work but at some point obviously stopped working.

I can confirm through rsop.msc and gpresult that the policy is in effect on the pc(s) but it is just not working.

Any thoughts on why this would have happened or how I can correct it?

Any help would be appreciated.

Thanks,
Ryan
LVL 1
Ryan RoodAsked:
Who is Participating?
 
McKnifeConnect With a Mentor Commented:
If you rsop at DC4 it shows the settings got applied to DC4?
Then users logging on to DC4 (%logonserver%=DC4) would have to be tested to see whether the policy is effective. Look for the variable %logonserver% and test one with DC4.
0
 
Brian PiercePhotographerCommented:
Without using fine grained password policies you can only have one password policy which is applied at the domain level. Password policies applied else ware have no effect.
0
 
Ryan RoodAuthor Commented:
I am using the domain level password policy ... it is located in the Default Domain Policy. I do not have any other password policies configured.
0
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

 
Paul MacDonaldDirector, Information SystemsCommented:
Any chance the accounts in question belong to Domain Admins?
0
 
Ryan RoodAuthor Commented:
All accounts - have not tried a Domain Admin user.
0
 
Brian PiercePhotographerCommented:
OK

Check
Lockout duration = 60
Lockout Threshold = 5
Reset After = 60

Run GPUPDATE/force on both server and clients

You may need to log off and back on again for the policy to apply
0
 
Ryan RoodAuthor Commented:
Policy was already in place prior - no changes made. I did run a gpudpate/force on all DCs and the clients and rebooted the clients. Still nothing.
0
 
McKnifeCommented:
You wrote, you did rsop on the clients... that shows you don't understand where the policy needs to be applied: at the DC, not at the clients. If applied to the clients, it restricts local accounts. If applied to the DCs, it restricts domain accounts.

So please run rsop at all DCs and report back.
0
 
Ryan RoodAuthor Commented:
gpupdate/force was run on the clients and the dc's. It shows the password policy and account lockout policy applied on the systems. Still nothing.

RSOP looks fine with the settings.
0
 
McKnifeCommented:
rsop (executed on each DC) shows the correct lockout policy is active on ALL DCs?
0
 
Ryan RoodAuthor Commented:
That is correct.
0
 
McKnifeCommented:
Ok... so if you can verify that not only one account (for reasons whatsoever) will not lock, but no account, then something in your active directory is badly broken. Please do another test: do any other password policy settings still apply (for example the minimum length requirement)?
0
 
Ryan RoodAuthor Commented:
People are still being forced to change their passwords ... so yes some things are still working.

The only thing that comes to mind is that recently Server 2012 and Exchange 2013 was added to the directory. There was no previous Exchange server.
0
 
McKnifeCommented:
That they are being forced to change it, does not necessarily mean the policy is being applied. It only means some policy is applied, not which. So to make sure, please do as I told you.
0
 
Ryan RoodAuthor Commented:
Password length and remember number of passwords is also not applying.
0
 
McKnifeCommented:
See? So the policy says it applies but does not. That's a serious error. You could only try to reset that policy (set all values of the password policy part to not configured) and setup another password policy and link it to the DCs OU, gpupdate all DCs and try again. If that still shows no effect, enforce that new policy and do a gpupdate and test.
0
 
Ryan RoodAuthor Commented:
Setting all policies related to not defined ... running gpupdate/force on all DCs ... making new group policy for password policy only. Will advise.
0
 
Ryan RoodAuthor Commented:
Ok - still having the same issue even doing the above. What are my options? Is there a tool to scan AD for errors? Should I introduce a new Server 2012 DC and start migrating out the existing ones?
0
 
McKnifeCommented:
I am not sure. What should definitely help is setting up a new domain and migrating the users, computers and policies (all but the pw policies) over. This can be done using ADMT.

I don't think there will be some way to repair this state as windows does not even know it has a problem.

Before performing such a big step, you should definitely contact Microsoft support.
0
 
Ryan RoodAuthor Commented:
McKnife: Thank you for your input and suggestions. I will wait a little longer to see if anybody else has any other ideas. Greatly appreciate your input and suggestions.
0
 
Ryan RoodAuthor Commented:
I am not sure if this helps with anything ... but here is a few more pieces of information:

PDC role is assigned to DC4
DC4 is being assigned the appropriate permissions through the GPO

RID role is assigned to DC2
DC2 is NOT being assigned the appropriate permissions through the GPO

Infrastructure role is assigned to DC6
DC4 is NOT being assigned the appropriate permissions through the GPO

When looking at all of the workstations the appropriate GPO objects are being applied to the computers.

When looking at the DCs it seems like the policy is updating ... just not the password policy sections of the object. Other scripts and such have updated with the changes made recently to remove older items after the problem started.

Does this help narrow down the issue?
0
 
Brian PiercePhotographerCommented:
Not really relevant to the question but why are your FSMO roles spread over multiple machines - this is not generally a good idea, it does nothing for redundancy and generally incurs unnecessary overheads.
0
 
Ryan RoodAuthor Commented:
No real reason - just the way it was setup. All are located on the same subnet so I am not overly concerned about the little bit of additional overhead.
0
 
McKnifeConnect With a Mentor Commented:
"When looking at the DCs it seems like the policy is updating ... just not the password policy sections of the object" - what exactly allows this assumption? Does that mean that you recently (test-)changed the policy and afterwards did rsop.msc at the DCs and all changes except the pw policy section got applied?
0
 
Ryan RoodAuthor Commented:
Correct - cleaned some old stuff. Changes have applied except for the two sections we have been discussing.

So DC4 is showing the proper policy but for whatever reason those two section changes are not replicating to the other DCs. Is it possible to force a DC to re-read the GPO from another DC?
0
 
Ryan RoodAuthor Commented:
Update:

Created a new GPO with identical settings. Policy is applying to the PDC DC. The other DCs do not showing this policy being applied. I did a lot of things so I am not sure what exactly fixed it ... but it is now working on the computers.

Is it normal for the other DCs to not show the password policy being applied just the PDC DC?
0
 
McKnifeCommented:
There is no PDC, sorry. The PDC was last seen at NT4 days.
You need to apply the policy to all DCs. If it does not replicate to the other three, then people using one of the other 3 as logon server will not be restricted by the pw policies when changing their password.
0
 
Ryan RoodAuthor Commented:
PDC role perhaps would be a more appropriate description. Using rsop it shows only the PDC role DC with the appropriate settings yet secpol.msc shoes the actual correct local settings on the other two DCs.

I think I need a refresher course on AD.
0
 
McKnifeCommented:
Please finalize it, this question is growing old :) Or at least tell us how you solved it (or how we should continue?).
0
 
Ryan RoodAuthor Commented:
I don't really know what solved this issue in the end but I am awarding the points to McKnife for the assistance along the way with different ideas to try and correct the issue.
0
 
McKnifeCommented:
But it WAS solved after all? Great!
0
 
Ryan RoodAuthor Commented:
Yes - unfortunately there was quite a few different things that changed at once so I can't narrow it done. Perhaps corrupt GPO? Maybe but I can't say for sure.
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.

All Courses

From novice to tech pro — start learning today.