Go Premium for a chance to win a PS4. Enter to Win

x
?
Solved

Active Directory Will Not Lockout Account

Posted on 2013-11-08
33
Medium Priority
?
470 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
  • 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
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
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 57

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 57

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 57

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 57

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 57

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 57

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 57

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 57

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 57

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 57

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 57

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

WatchGuard Case Study: NCR

With business operations for thousands of customers largely depending on the internal systems they support, NCR can’t afford to waste time or money on security products that are anything less than exceptional. That’s why they chose WatchGuard.

Question has a verified solution.

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

Had a business requirement to store the mobile number in an environmental variable. This is just a quick article on how this was done.
For anyone that has accidentally used newSID with Server 2008 R2 (like I did) and hasn't been able to get the server running again because you were unlucky (as I was) and had no backups - I was able to get things working by doing a Registry Hive rec…
This tutorial will walk an individual through configuring a drive on a Windows Server 2008 to perform shadow copies in order to quickly recover deleted files and folders. Click on Start and then select Computer to view the available drives on the se…
This video shows how to use Hyena, from SystemTools Software, to update 100 user accounts from an external text file. View in 1080p for best video quality.

927 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