Forum Thread

(Solved) WIndows 2008 AD domain administrator locked out

teetee1 1,973 918 January 26, 2012 at 08:31 AM
Our office has a 2008 active directory managed by two domain controllers and several domain group policies.

I can't remember when this problem started to happen but I don't remember it ever happened before we switched 2003 servers with 2008 servers.

The built-in domain administrator account gets locked out with 5 incorrect password tries. The problem still persists even after I set the account lockout threshold to 0 (the account will not locked out) in both "Default domain policy" and "Default domain controller policy" and issued the command "gpupdate /force" on both domain controllers.

There is only one GPO linked to the built-in "Domain Controllers" OU which is "Default domain controller policy" and I've set "block inheritance" on the OU in GPO editor.

I don't know if there is any lockout settings applies to user account (ex. administrator account) or if I have to reboot the domain controller computers to make it work. Any suggestions are appreciated.

5 Comments

1

Sign up for a Slickdeals account to remove this ad.

Joined Jun 2005
Let Sleeping Dogs Lie
5,844 Posts
2,388 Reputation
Pro
#2
You should run rsop.msc or gpresult while logged in with your admin account to verify that you are not getting any account lockout policy. You should also try the Account Lockout and Management Tools to check where your account is logging in from or what possible services/apps could be causing this lockout to happen.

Download Account Lockout and Management Tools
http://www.microsoft.com/download...laylang=en

Regards,
Reply Helpful Comment? 0 0
Joined Dec 2007
L10: Grand Master
7,631 Posts
1,489 Reputation
#3
Have you looked to see if the Domain Administrators group has a lockout threshold or if the built-in domain administrators group is part of an OU that has a lockout threshold? Or is the domain administrators group apart of an Enterprise Administrators group which may have a lockout threshold? Something encompassing that account is overriding the more local settings by the read of it.
Reply Helpful Comment? 0 0
Joined Sep 2006
L6: Expert
1,973 Posts
918 Reputation
Original Poster
#4
Thanks. After some more research, it seems the account lockout threshold only applies to computer accounts rather than users/groups. I guess it makes sense since without logging in (due to incorrect password), the system would not know which user group policy it can use to apply.

To understand which group policies were used on the computers, I did a group policy result check by using the command:
gpresult /S <machinename> /V

on both domain controllers. With the group policy inheritance blocked and not linked to any group policies (not even the default domain controller policy), the two domain controllers from the "domain controllers" OU showed no group policies were applied on them (expected). However the administrator account still gets locked out after 5 unsuccessful tries locally.

It almost indicates that this lockout thing is from something other than the domain group policy. I checked the local security policy on one of the controllers and it does have the lockout threshold of 5 tries. After I changed it to 0 (no lockout), the problem was solved (on both controllers).

Now my understanding on the local and domain group policy design is that once the machine becomes part of the domain, it filters out the local group policy settings so only the domain group policy applied has the effect. The fact that changing the local security group policy altered the machine behavior indicates it overrules the domain group policy. Also it might indicate this "local" security policy is shared among at least domain controllers since changing it on one controller makes both servers lockout behavior(problem) disappear.

My lesson from this: The group policy design is good but the implementation is questionable.
Reply Helpful Comment? 0 0
Last edited by teetee1 January 27, 2012 at 08:00 AM
#5
If your admin account mapped a drive on one of the workstations, or did some other task that required credentials to be input, and then after a time the mandatory Active Directory password change went into effect and the password was changed for that admin, the workstation will cause the admin to be locked out trying to access the mapped drive or task with the old password that was input for that admin account.

I would guess this is your problem and it has nothing to do with the number of attempts you have set before a lockout is done.

You WANT a number of attempts to sign in to lockout the user -- whether an admin or a normal user. Don't set it to 0. Leave it at 3 or 5 or whatever your regs say it needs to be. Find the reason for the lockout -- which I am betting is the above cause.

Mapping and tasks that require credentials should be done with the one or two admin accounts you have that have passwords that never expire.

There is a way to find the root of this issue through the event log. I will have to look it up to find it and will get back with you.
Reply Helpful Comment? 0 0
Last edited by callpocket January 27, 2012 at 09:06 PM
R.I.P Tyson the avatar dog December 16, 2013. nod
Joined Sep 2006
L6: Expert
1,973 Posts
918 Reputation
Original Poster
#6
Quote from callpocket View Post :
If your admin account mapped a drive on one of the workstations, or did some other task that required credentials to be input, and then after a time the mandatory Active Directory password change went into effect and the password was changed for that admin, the workstation will cause the admin to be locked out trying to access the mapped drive or task with the old password that was input for that admin account.

I would guess this is your problem and it has nothing to do with the number of attempts you have set before a lockout is done.

You WANT a number of attempts to sign in to lockout the user -- whether an admin or a normal user. Don't set it to 0. Leave it at 3 or 5 or whatever your regs say it needs to be. Find the reason for the lockout -- which I am betting is the above cause.

Mapping and tasks that require credentials should be done with the one or two admin accounts you have that have passwords that never expire.

There is a way to find the root of this issue through the event log. I will have to look it up to find it and will get back with you.
Thanks. The login failure can be found by filtering the security event log with "Audit Failure" event. Also while I was doing the research, a tool called ALTools was useful:
http://www.microsoft.com/download...n&id=18465

I did have the account lockout policy on default domain policy, which is applied to all the computers in the AD except the domain controllers. The domain admin's password was never changed (I know it's not a good idea).

A suggested practice seems to be separate domain account just for all network services, a read admin user (not the built-in administrator) for admin business, and the decoy administrator account.
Reply Helpful Comment? 0 0
Page 1 of 1
1
Join the Conversation
Add a Comment
 
Copyright 1999 - 2016. Slickdeals, LLC. All Rights Reserved. Copyright / Infringement Policy  •  Privacy Policy  •  Terms of Service  •  Acceptable Use Policy (Rules)  •  Interest-Based Ads
Link Copied to Clipboard