Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17

x
?
Solved

Active Directory Will Not Lockout Account

Posted on 2013-11-08
33
Medium Priority
?
464 Views
Last Modified: 2014-02-21
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
0
Comment
Question by:Ryan Rood
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 17
  • 11
  • 3
  • +1
33 Comments
 
LVL 70

Expert Comment

by:KCTS
ID: 39634336
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
 
LVL 1

Author Comment

by:Ryan Rood
ID: 39634342
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
 
LVL 34

Expert Comment

by:Paul MacDonald
ID: 39634764
Any chance the accounts in question belong to Domain Admins?
0
Free Backup Tool for VMware and Hyper-V

Restore full virtual machine or individual guest files from 19 common file systems directly from the backup file. Schedule VM backups with PowerShell scripts. Set desired time, lean back and let the script to notify you via email upon completion.  

 
LVL 1

Author Comment

by:Ryan Rood
ID: 39634796
All accounts - have not tried a Domain Admin user.
0
 
LVL 70

Expert Comment

by:KCTS
ID: 39634959
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
 
LVL 1

Author Comment

by:Ryan Rood
ID: 39635916
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
 
LVL 56

Expert Comment

by:McKnife
ID: 39638195
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
 
LVL 1

Author Comment

by:Ryan Rood
ID: 39651102
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
 
LVL 56

Expert Comment

by:McKnife
ID: 39653085
rsop (executed on each DC) shows the correct lockout policy is active on ALL DCs?
0
 
LVL 1

Author Comment

by:Ryan Rood
ID: 39653280
That is correct.
0
 
LVL 56

Expert Comment

by:McKnife
ID: 39655051
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
 
LVL 1

Author Comment

by:Ryan Rood
ID: 39655450
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
 
LVL 56

Expert Comment

by:McKnife
ID: 39655655
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
 
LVL 1

Author Comment

by:Ryan Rood
ID: 39656316
Password length and remember number of passwords is also not applying.
0
 
LVL 56

Expert Comment

by:McKnife
ID: 39656390
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
 
LVL 1

Author Comment

by:Ryan Rood
ID: 39656421
Setting all policies related to not defined ... running gpupdate/force on all DCs ... making new group policy for password policy only. Will advise.
0
 
LVL 1

Author Comment

by:Ryan Rood
ID: 39663148
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
 
LVL 56

Expert Comment

by:McKnife
ID: 39663815
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
 
LVL 1

Author Comment

by:Ryan Rood
ID: 39665658
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
 
LVL 1

Author Comment

by:Ryan Rood
ID: 39666337
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
 
LVL 70

Expert Comment

by:KCTS
ID: 39666459
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
 
LVL 1

Author Comment

by:Ryan Rood
ID: 39666468
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
 
LVL 56

Assisted Solution

by:McKnife
McKnife earned 2000 total points
ID: 39666476
"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
 
LVL 1

Author Comment

by:Ryan Rood
ID: 39666486
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
 
LVL 56

Accepted Solution

by:
McKnife earned 2000 total points
ID: 39666638
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
 
LVL 1

Author Comment

by:Ryan Rood
ID: 39682102
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
 
LVL 56

Expert Comment

by:McKnife
ID: 39682344
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
 
LVL 1

Author Comment

by:Ryan Rood
ID: 39682367
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
 
LVL 56

Expert Comment

by:McKnife
ID: 39877774
Please finalize it, this question is growing old :) Or at least tell us how you solved it (or how we should continue?).
0
 
LVL 1

Author Closing Comment

by:Ryan Rood
ID: 39877798
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
 
LVL 56

Expert Comment

by:McKnife
ID: 39877810
But it WAS solved after all? Great!
0
 
LVL 1

Author Comment

by:Ryan Rood
ID: 39877855
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

Featured Post

Are You Ready for GDPR?

With the GDPR deadline set for May 25, 2018, many organizations are ill-prepared due to uncertainty about the criteria for compliance. According to a recent WatchGuard survey, a staggering 37% of respondents don't even know if their organization needs to comply with GDPR. Do you?

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Auditing domain password hashes is a commonly overlooked but critical requirement to ensuring secure passwords practices are followed. Methods exist to extract hashes directly for a live domain however this article describes a process to extract u…
A hard and fast method for reducing Active Directory Administrators members.
This Micro Tutorial hows how you can integrate  Mac OSX to a Windows Active Directory Domain. Apple has made it easy to allow users to bind their macs to a windows domain with relative ease. The following video show how to bind OSX Mavericks to …
Microsoft Active Directory, the widely used IT infrastructure, is known for its high risk of credential theft. The best way to test your Active Directory’s vulnerabilities to pass-the-ticket, pass-the-hash, privilege escalation, and malware attacks …

721 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question