[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
?
Solved

Massive Account Lockouts

Posted on 2004-11-29
26
Medium Priority
?
1,538 Views
Last Modified: 2008-03-10
I have read the other posts pertaining to account lockouts, and have not been able to resolve my current problem in my network. It's a fairly small network- 6 Servers(2003 server and 2000 server) (2 DCs) and 20 workstations(2000 and XP). We recently migrated our secondary WINS server to another server and stop and disabled the service on the previous secondary server. I made the necessary adjustments on the Primary WINS server to point to the new Secondary WINS server and visa versa. Everything seems to be fine with replication between partners, and I can see the the netbios names it resolves. Ever since I migrated the secondary WINS server to the new server, we have been getting account lockouts all over the place.

I will go into AD USers and Computers and see that evry single account is locked account (yes- even the administrator account) and then I have to unlock all of them. A few minutes later, I see that they are ALL locked out again. A user brought it to my attention when it happened and I went to their computer and saw a box pop up asking for a Login name, password, and domain name. They had Outlook open while this happened as well. Then on another user's computer (while their account was locked out, but the user was currently logged in), when they tried to open up Outlook, it asked them for Login name, password and domain name. The accounts keep locking out- and there is NO policy making them do this. The only policy is to unlock after 3 failed attempts, and then to reset after 30 mins. We did not have this problem before the migration.

Recently I configured all workstations to static IP's and configured them properly in DNS (this was requested by my supervisor). The lockout problems occured before I set the static IP's on the workstations. Do I still need WINS if I am going static and their host files are set to their static IP and Comp name? Thanks, and please help!!
0
Comment
Question by:Trihimbulus
  • 12
  • 7
  • 5
  • +2
26 Comments
 
LVL 11

Expert Comment

by:cfairley
ID: 12699635
You should not need WINS unless you have clients prior to 2000 (98, 95).  Or if you have a program that needs it, or clustering.  Examine the security logs on the domain controllers for failure audits.  Inside the failure audit, it will tell you the user account and the computer the lockouts are comming from, it may be a problem with a specific server.
0
 

Author Comment

by:Trihimbulus
ID: 12700132
Checked the DC Security Logs and saw NO failures. Where do I go from here? They are still locking out, even the Administrator account which is not too good...
0
 
LVL 6

Expert Comment

by:Casca1
ID: 12700197
Here's whats happening. THe secondary WINS server isn't delegated to update DNS records. It's probably using the machine account. You will probably have to add permissions for the machine to the DNS records, or add it to a group that has perms.
Good Luck!
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
LVL 11

Expert Comment

by:cfairley
ID: 12700263
It seems that you are having user accounts locked out instead of computer accounts right?

Whenever a user is locked out, and event # 644 is logged on the DC that locked it out.  Unless you have auditing of logons turned off, you should see the events in the security log of one of the DCs.  You will have to check all of them.  Just want to make sure of this step before going to the next.
0
 

Author Comment

by:Trihimbulus
ID: 12700346
Correct the Active Directory domain user accounts are being locked out.
0
 
LVL 11

Expert Comment

by:cfairley
ID: 12700366
Inside the 644 error should be the name of the server that locking out the account.
0
 

Author Comment

by:Trihimbulus
ID: 12700649
Ok sit tight, and I will tel you what the Audits yield tommorow morning.
0
 
LVL 51

Expert Comment

by:Netman66
ID: 12701665
Sounds very much like virus or spyware behaviour.  If your machines are infected there are some viruses and/or spyware that attempt to access all the shares it can find on the network using whatever credentials it has - thereby locking out the account.

0
 
LVL 2

Expert Comment

by:chumps007
ID: 12701757
The Microsoft paper, Account Lockout Best Practices, is a great read for getting your head around account lockouts, best practice, how to troubleshoot and how to resolve issues.  This paper recommends the LockoutStatus.exe tool to help in situations such as yours where you don't know how or where the account lockouts are occurring.

The LockoutStatus.exe Tool

The LockoutStatus.exe displays information about a locked out account. It does this by gathering account lockout-specific information from Active Directory. The following list describes the different information that is displayed by the tool:
•      DC Name: Displays all domain controllers that are in the domain.
•      Site: Displays the sites in which the domain controllers reside.
•      User State: Displays the status of the user and whether that user is locked out of their account.
•      Bad Pwd Count: Displays the number of bad logon attempts on each domain controller. This value confirms the .domain controllers that were involved in the account lockout.
•      Last Bad Pwd: Displays the time of the last logon attempt that used a bad password.
•      Pwd Last Set: Displays the value of the last good password or when the computer was last unlocked.
•      Lockout Time: Displays the time when the account was locked out.
•      Orig Lock: Displays the domain controller that locked the account (the domain controller that made the originating write to the LockoutTime attribute for that user).

LockoutStatus.exe is included with the ALTools.exe package that is available at "Account Lockout and Management Tools" on the Microsoft Web site|http://go.microsoft.com/fwlink/?LinkId=16174.

If that doesn't help, then you might try ALockout.dll, which should give you more granular information from each client.  Alternatively, and after a KNOWN GOOD BACKUP, install ALockout.dll on your old and new WINS servers to see whether they are the culprits, since the timing does seem to indicate their involvement.

The ALockout.dll Tool

ALockout.dll is a logging tool that may help you determine the program or process that is sending the incorrect credentials in an account lockout scenario. The tool attaches itself to a variety of function calls that a process might use for authentication. The tool then saves information about the program or process that is making those calls into the Systemroot\Debug\Alockout.txt file. The events are time stamped so that you can match them to the events that are logged in either the Netlogon log files or the Security event log files.

You can use Appinit.reg to initialize the .dll file. This file provides no other functionality.
Note   Microsoft does not recommend that you use this tool on servers that host network programs or services. You should not enable ALockout.dll on Exchange servers because the ALockout.dll tool may prevent the Exchange store from starting.

In most account lockout scenarios, you should install ALockout.dll on client computers. Use the information that is stored in both the Netlogon log file and the Security event log to determine the computers from which the incorrect credentials are being sent that are locking out the user's account. When you install the ALockout.dll tool on the client computer that is sending the incorrect credentials, the tool logs the process that is sending the incorrect credentials.

Where to Obtain the ALockout.dll Tool
ALockout.dll is included with the ALTools.exe package that is available at "Account Lockout and Management Tools" on the Microsoft Web site|http://go.microsoft.com/fwlink/?LinkId=16174.

Hopefully this helps identify what is locking our your accounts and from there you can either reolve the issue, or repost with more information.

Cheers,
Katherine
0
 

Author Comment

by:Trihimbulus
ID: 12705185
Ok I found that the Primary Domain controller is locking them out. I used the account lock out tool as listed above and saw that there were 3 bad password attempts. I know for a fact that these users are not responsible, as ALL accounts locked out at the same time.
0
 
LVL 11

Expert Comment

by:cfairley
ID: 12705297
Is the DC running any special program, SQL, Exchange, etc.  They may have a connection to the DC somehow.  You can go to computer management on the DC, go to shared folders, then sessions.
0
 

Author Comment

by:Trihimbulus
ID: 12705490
Yes Primary DC (which is 2003) is running Exchange 2003.
0
 
LVL 11

Expert Comment

by:cfairley
ID: 12705956
Still looking into this.  Sorry, I have to go to a meeting for now, I'm sure we will get to the bottom of this.
0
 

Author Comment

by:Trihimbulus
ID: 12706352
In reference to what Casca said:

Here's whats happening. THe secondary WINS server isn't delegated to update DNS records. It's probably using the machine account. You will probably have to add permissions for the machine to the DNS records, or add it to a group that has perms.
Good Luck!

Does this need to be done? How?
Do you think this is a factor? Yet users accounts that are primarily used for OWA (who dont even have machines here) are getting locked out...
0
 
LVL 6

Expert Comment

by:Casca1
ID: 12706724
Nope; I'm sorry, kinda embarrased. 8-)
I read accounts, and assumed machine accounts.
It wouldn't hurt to check, but contrary to what I said, this isn't it... That setting comes from DHCP, and has to do with dynamic updates to DNS. My apologies, but I tried to send you the wrong way.

WINS is not needed, unless you have an old app that uses WINS for name resolution. You might try disabling WINS and see if that fixes your issue, but I doubt it.

It sounds as if you have had an abortive authoritative restore; Since that's pretty simple to answer, did you?
Your problem seems to be an AD replication problem. Which server is the PDC FSMO roleholder?
It might not be getting the updates properly, or Exchange isn't communicating properly.
0
 

Author Comment

by:Trihimbulus
ID: 12707282
The PDC is our 2003 Server which has Exchange 2003 on it as well. Here is a brief setup:

Server A: (Server 2003)
Exchange 2003
Primary Domain Controller
Global Catalog
PDC Emulator
RID Master
Schema Master
Domain Naming Master
Primary DNS

Server B: (Server 2000)
Domain Controller
Infrastructure Master
Secondary DNS
Primary WINS
File Server

Server C: (Server 2003)
Print Server
Secondary WINS
0
 
LVL 6

Expert Comment

by:Casca1
ID: 12710514
Do you have to support any legacy apps?
If not, disable the WINS and test it out. While I cannot think of any reason why WINS would interact with the user accounts, the evidence seems to suggest it. Another problem I have seen is when authentication of accounts wasn't occuring properly because DNS was misconfigured, but that was killing accounts on a onesy-twosy basis, not en-masse.
Whatever the issue, it IS name resolution related, but...
Here's the problem; MS is attempting to cut all ties to netbios and the lan-manager days. But in the process of building the original "New Technology" that was NT, they incorporated the support right into the code. Now, stuff like DNS works, but it sorta talks to the kernel with the help of the LM and NB as interpreters. You can make it stop using it, but there is a LONG list of tweaks that have to be applied to make it all work.
AD, however, relies on DNS as it's name resolution, and 2003 valiantly tries to ignore LM requests, so it seems your downlevel primary can't communicate with the secondary. If WINS support is turned on in DNS this could be the culprit, but it still shouldn't do more than lock the machine accounts.

In short, follow the old rules, KISS; You shouldn't need two name resolution schemes, and you have no choice about DNS while using Active Directory. Dump the WINS, unless you have no choice. If you have no choice, reverse the roles of server b and server c; Make the primary the 2003 server and see if it doesn't straighten out the problem. Note this will probably cause replication issues, if the problem is related to downlevel OS and an inability to process coms.
0
 

Author Comment

by:Trihimbulus
ID: 12710818
So kill WINS since I have static IPs on everything?
0
 
LVL 6

Expert Comment

by:Casca1
ID: 12710888
Well, you shouldn't need it either way. AD relies on DNS, and so do your clients, if their 2000/XP.
If 95/98, you have issues, anyway. 98 can use DNS for name resolution, and "Sort of" work in an AD network. There is just things you can't do properly. 95 is even more problematical. Those, and the rest of the downlevel clients, like NT and (Shudder) W3.11 relied on WINS for it. If you aren't using 95 and below, yes, turn it off and test it without.
BTW, what ARE your client OS'?
0
 
LVL 6

Expert Comment

by:Casca1
ID: 12710917
Oh, and you can convert back to dynamic IP's, and for simplicity's sake, I would. You can keep track of 206 IP's, but that will change rapidly. Another 10 boxes, spread out over two months, and you'll regret not using DHCP. 8-)
Also, since I saw all 2000/XP, turn off WINS and test it out. 8-)
0
 

Author Comment

by:Trihimbulus
ID: 12711721
Ok I will turn WINS off tommorow morning- man I hope we get this figured out. You guys are a great help! btw - We use Deltek, which is an older program, do you think this is WINS dependent?
0
 
LVL 6

Expert Comment

by:Casca1
ID: 12711746
How old, and what does it do? Hmmm googled and it seems to be an SAP-like program. Headache city.
You might have to have something like an LMhosts file, but that should fix you right up.
0
 

Author Comment

by:Trihimbulus
ID: 12711788
It is primarily for accounting purposes- its a DOS-like program and all workstation clients are connected to the server database. Lmhosts file to what? Since all workstations are now (recently static)- they all have an updated host file and pointer record in DNS. Man this whole deal is a headache lol
0
 

Author Comment

by:Trihimbulus
ID: 12715071
Yes Deltek is a Legacy App so I need to keep WINS on. BTW- all clients are XP and 2000.
0
 
LVL 6

Accepted Solution

by:
Casca1 earned 1500 total points
ID: 12716849
Actually, WINS is the solution to the LMhosts file.
You either need one or the other in a netbios world for name resolution.
You can still test if WINS is the issue, tho. Build an LMHosts fiel for each machine, with the correct name mapping in place. Then, disable WINS, say over the weekend, and logon with several accounts and see if everything works.
THEN! make the penny-pinching bean counters by a better bean sorter! 8-) THere's probably an update for the program available, but not free.
Good luck!
0
 

Author Comment

by:Trihimbulus
ID: 12719500
Ok I found something- but no clue if it has anything to do with our account lockouts:

As I told you, they had migrated the Secondary WINS server from the old server to a new. During the configuration of the static IP address (in the WINS Primary and Secondary config on the NIC card) it's primary WINS server was set to itself and the Primary Wins server was set as its Secondary Wins server- if I have lost you at this point sorry. I just made the appropriate corrections, and am waiting for recurrence. What do you guys think?
0

Featured Post

What is SQL Server and how does it work?

The purpose of this paper is to provide you background on SQL Server. It’s your self-study guide for learning fundamentals. It includes both the history of SQL and its technical basics. Concepts and definitions will form the solid foundation of your future DBA expertise.

Question has a verified solution.

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

So you have two Windows Servers and you have a directory/folder/files on one that you'd like to mirror to the other?  You don't really want to deal with DFS or a 3rd party solution like Doubletake. You can use Robocopy from the Windows Server 200…
Recently, I had the need to build a standalone system to run a point-of-sale system. I’m running this on a low-voltage Atom processor, so I wanted a light-weight operating system, but still needed Windows. I chose to use Microsoft Windows Server 200…
This lesson discusses how to use a Mainform + Subforms in Microsoft Access to find and enter data for payments on orders. The sample data comes from a custom shop that builds and sells movable storage structures that are delivered to your property. …
Look below the covers at a subform control , and the form that is inside it. Explore properties and see how easy it is to aggregate, get statistics, and synchronize results for your data. A Microsoft Access subform is used to show relevant calcul…

830 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