Trihimbulus
asked on
Massive Account Lockouts
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!!
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!!
cfairley
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.
ASKER
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...
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!
Good Luck!
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.
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.
ASKER
Correct the Active Directory domain user accounts are being locked out.
Inside the 644 error should be the name of the server that locking out the account.
ASKER
Ok sit tight, and I will tel you what the Audits yield tommorow morning.
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.
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.
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
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.
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
ASKER
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.
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.
ASKER
Yes Primary DC (which is 2003) is running Exchange 2003.
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.
ASKER
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...
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...
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.
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.
ASKER
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
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
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.
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.
ASKER
So kill WINS since I have static IPs on everything?
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'?
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'?
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-)
Also, since I saw all 2000/XP, turn off WINS and test it out. 8-)
ASKER
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?
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.
You might have to have something like an LMhosts file, but that should fix you right up.
ASKER
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
ASKER
Yes Deltek is a Legacy App so I need to keep WINS on. BTW- all clients are XP and 2000.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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?
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?