I've seen this issue discussed here and there, but I have yet to find a solution. I installed one Windows 7 machine and connected it to the domain (Server 2003)several weeks ago, and during my tests, my account got locked out several times. I figured it was afluke. Today, I upgraded my workstation to Windows 7, and same problem. My domain account keeps getting locked out. I think it has something to do with our Intranet site. We run IIS6 on Server 2003 and have Digest and Windows Authentication onlly enabled. When I stay off of that site, it does not appear to happen, but soon after I start using our Intranet site, the account locks. This is a huge deal, because developing for that site is my primary role. I am at my wits end and unless I get a solution quickly, will be downgrading back to Vista in the next hour, as I can't work right now.Here is what I have found, that was not helpful:http://social.technet.microsoft.com/Forums/en/w7itprosecurity/thread/45cddbc8-f5f7-4868-ba0a-042f12addb45http://social.technet.microsoft.com/Forums/en-US/w7itprosecurity/thread/ac159f92-4c3a-4de4-8412-ecddc33026e9

Scratch that. I have been off the Intranet site now since the last time I unlocked it, and it still locked me out. No idea what is causing this.

I am also seeing this problem. Not sure what is causing it either. Win2k3 Domain Exchange 2007 Office 2007 We are mapping 2 network drives at login, and one folder re-direction GPO. My account will randomly lockout though out the day with no connections that I can see. IAITGUY

Well, I could not find a solution. Downgraded back to Vista (sucks), and we will be there indefinitely, unless we can find a solution.

Going though my security log, I'm showing a LOT of "Audit Failure". I'll list most of the failures:DSA.msc (AD Users and Computers)svchost.exe (Filtering Platform Connection)svchost.exe (Filtering Platform Packet Drop)svchost.exe (Other Object Access Events)\Device\HarddiskVolume2\Windows\System32\l3codeca.acm (system integrity) (Single entry)These are all with my username, and are alongside "Audit Success" for the same process and job.You have anything similar?IAITGUY

On the local machine or the domain controller?

local, but now that you say that, I forgot to look at the DCs!IAITGUY

I don't remember seeing those in my local logs, and I checked, but as I said I re-formatted the drive and am going back to Vista. As soon as I can get an extra piece of hardware, I am going to try again with 7, but I have to work.On the DC, there are tons of these:Event Type:Failure AuditEvent Source:SecurityEvent Category:Account Logon Event ID:680Date:11/19/2009Time:10:35:18 AMUser:NT AUTHORITY\SYSTEMComputer:DC01Description:Logon attempt by:MICROSOFT_AUTHENTICATION_PACKAGE_V1_0Logon account:keithdavisSource Workstation:\\KDAVISError Code:0xC0000234 For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

What form of login ID are you using? Is it of the form "<domain>\<username>"? Does changing its form have any effect?

domain\username already went back to Vista. Will test the other once I get a 7 machine up for testing.

Try it without the "domain\" part. That's what solved my problem.

I thought you just mean to switch accounts, no, when I login I just put the username, no domain\. I can login fine too, but while I'm logged in, it locks me out.

Hi laurin1, first of all, I'd like to inform you that the error 0xc0000234 refers to:STATUS_ACCOUNT_LOCKED_OUT The user account has been automatically locked because too many invalid logon attempts or password change attempts have been requested. We can run the LockoutStatus.exe on domain controller to identify and investigate the account lockout issue. Troubleshooting tools: By using this tool, we can gather and displays information about the specified user account including the domain admin's account from all the domain controllers in the domain. In addition, the tool displays the user's badPwdCount value on each domain controller. The domain controllers that have a badPwdCount value that reflects the bad password threshold setting for the domain are the domain controllers that are involved in the lockout. These domain controllers always include the PDC emulator operations master. You may download the tool from the link DownloadAccount Lockout Status (LockoutStatus.exe)http://www.microsoft.com/downloads/details.aspx?Family-cd55-4829-a189-99515b0e90f7&DisplayLang=en Once we confirm the problematic computer, we can perform further research to locate the root cause. Actually, there are many possible causes for bad password, such as cached password, schedule task, mapped drives, services, etc. Please remove the previous password cache which may be used by some applications and therefore cause the account lockout problem. Troubleshooting steps: 1. Click Start, click Run, type "control userpasswords2" (without the quotation marks), and then click OK. 2. Click the Advanced tab. 3. Click the "Manage Password" button. 4. Check to see if these domain account's passwords are cached. If so, remove them. 5. Check if the problem has been resolved now. Please download the Account Lockout and Management Tools: Account Lockout and Management Tools http://www.microsoft.com/downloads/details.aspx?familyid=7af2e69c-91f3-4e63-8629-b999adde0b9e&displaylang=en Please Note: Aloinfo.exe included in the above package helps display all local services and the account used to start them. Please logon the problematic client computer as the Local Administrator and run the following command: Aloinfo.exe /stored >C:\CachedAcc.txt Then check the C:\CachedAcc.txt file. If there is any application or service is running as the problematic user account, please disable it and then check whether the problem occurs. For your convenience, I'd like tolist the common troubleshooting steps and resolutions for account lockouts as the following: Common Causes for Account Lockouts To avoid false lockouts, please check each computer on which a lockout occurred for the following behaviors: Programs: Many programs cache credentials or keep active threads that retain the credentials after a user changes their password. Service accounts: Service account passwords are cached by the service control manager on member computers that use the account as well as domain controllers. If you reset the password for a service account and you do not reset the password in the service control manager, account lockouts for the service account occur. This is because the computers that use this account typically retry logon authentication by using the previous password. To determine whether this is occurring, look for a pattern in the Netlogon log files and in the event log files on member computers. You can then configure the service control manager to use the new password and avoid future account lockouts. Bad Password Threshold is set too low: This is one of the most common misconfiguration issues. Many companies set the Bad Password Threshold registry value to a value lower than the default value of 10. If you set this value too low, false lockouts occur when programs automatically retry passwords that are not valid. Microsoft recommends that you leave this value at its default value of 10. For more information, see "Choosing Account Lockout Settings for Your Deployment" in this document. User logging on to multiple computers: A user may log onto multiple computers at one time. Programs that are running on those computers may access network resources with the user credentials of that user who is currently logged on. If the user changes their password on one of the computers, programs that are running on the other computers may continue to use the original password. Because those programs authenticate when they request access to network resources, the old password continues to be used and the users account becomes locked out. To ensure that this behavior does not occur, users should log off of all computers, change the password from a single location, and then log off and back on. Stored user names and passwords retain redundant credentials: If any of the saved credentials are the same as the logon credential, you should delete those credentials. The credentials are redundant because Windows tries the logon credentials when explicit credentials are not found. To delete logon credentials, use the Stored User Names and Passwords tool. For more information about Stored User Names and Passwords, see online help in Windows XP and the Windows Server 2003 family. Scheduled tasks: Scheduled processes may be configured to using credentials that have expired. Persistent drive mappings: Persistent drives may have been established with credentials that subsequently expired. If the user types explicit credentials when they try to connect to a share, the credential is not persistent unless it is explicitly saved by Stored User Names and Passwords. Every time that the user logs off the network, logs on to the network, or restarts the computer, the authentication attempt fails when Windows attempts to restore the connection because there are no stored credentials. To avoid this behavior, configure net use so that is does not make persistent connections. To do this, at a command prompt, please type net use /persistent:no. Alternately, to ensure current credentials are used for persistent drives, disconnect and reconnect the persistent drive. Active Directory replication: User properties must replicate between domain controllers to ensure that account lockout information is processed properly. You should verify that proper Active Directory replication is occurring. Disconnected Terminal Server sessions: Disconnected Terminal Server sessions may be running a process that accesses network resources with outdated authentication information. A disconnected session can have the same effect as a user with multiple interactive logons and cause account lockout by using the outdated credentials. The only difference between a disconnected session and a user who is logged onto multiple computers is that the source of the lockout comes from a single computer that is running Terminal Services. Service accounts: By default, most computer services are configured to start in the security context of the Local System account. However, you can manually configure a service to use a specific user account and password. If you configure a service to start with a specific user account and that accounts password is changed, the service logon property must be updated with the new password or that service may lock out the account. Internet Information Services: By default, IIS uses a token-caching mechanism that locally caches user account authentication information. If lockouts are limited to users who try to gain access to Exchange mailboxes through Outlook Web Access and IIS, you can resolve the lockout by resetting the IIS token cache. For more information, see "Mailbox Access via OWA Depends on IIS Token Cache" in the Microsoft Knowledge Base. MSN Messenger and Microsoft Outlook: If a user changes their domain password through Microsoft Outlook and the computer is running MSN Messenger, the client may become locked out. To resolve this behavior, see "MSN Messenger May Cause Domain Account Lockout After a Password Change" in the Microsoft Knowledge Base. For more information, please refer to the following link: Troubleshooting Account Lockout http://technet.microsoft.com/en-us/library/cc773155.aspx Account Passwords and Policies in Windows Server 2003 http://technet.microsoft.com/en-us/library/cc783860.aspx Hope this helps!Sean Zhu - MSFT

Thanks. I've actually checked most of that already. I am 90% sure the problem is somehow caused by accessing the NAS we use (Thecus N5200.) With Vista, until SP2, the NAS would only recognize the user's Primary Group (POSIX), and so we've had AD problems before with it and in my tests, my account would lock as soon as I would navigate to it, is when the account appeared to lock. We've decided to get rid of the NAS (other problems), and as soon as I get a 7 machine online, I will test and post the results. Thanks for your input.

That was not the problem. We've taken that NAS offline, and my account still locks.

We're having the same problem. Seems to be limited to certain accounts on certain OS. Mine gets locked out most often. I'm on Windows 7 64-bit. In fact, I can make this happen. When I lock my screen it will lock my account. When I log on to another machine I it happens too. Some of the users who are also on Windows 7 don't have this problem.

Well, on the one test machine that we just built, the problem appears to have gone away. We have done nothing to fix it, but my account is no longer locking out using that machine or any other. When I get back from my honeymoon, I am going to do a real test with my machine and I'lll report back.

i think your machine may have been infected by virus (conficker). run a fullscan on your machine to identify it. and also try out these two KBhttp://support.microsoft.com/kb/962007http://support.microsoft.com/kb/890830also check any old saved/cache credential in your machine or any of the machine you found have problem.

I think it has something to do with our Intranet site. We run IIS6 on Server 2003 and have Digest and Windows Authentication onlly enabled. When I stay off of that site, it does not appear to happen, but soon after I start using our Intranet site, the account locks. as you mentioned above, please check whether you have any save credential in your IE and clear all the saved credentials which may have expired!i think that is the cause. hope that help.

What sort of applications and systems are on the domain which is using Single Sign On properites?Is there anything using clustering services?What do the logs look like, as far as user log ons and permissions? If you increase the secruity thresholds for log ins, what changes?

Hopefully, lauren1 you wouldn't have set an autocomplete to save the account/login info (especially with the Digest Windows Auth setting). ls01c may have a point worth checking as I've seen people do that kind of stuff with our proxy that allows you to try again with a logon if the auto-digest doesn't work.Another setting you may have likely already checked:Intrenet Options -> Ensure your intranet server is in the "Local Intranet" sites listSecurity for the "Local intranet" zone is set to allow "automatic logon only in Intranet zone"

What sort of applications and systems are on the domain which is using Single Sign On properites?Is there anything using clustering services?What do the logs look like, as far as user log ons and permissions? If you increase the secruity thresholds for log ins, what changes? Single-sign on?No clustering. Right now, it's working for me, but I have a peer that is getting lockedout and he's not even using a Windows 7 machine.

Hopefully, lauren1 you wouldn't have set an autocomplete to save the account/login info (especially with the Digest Windows Auth setting). ls01c may have a point worth checking as I've seen people do that kind of stuff with our proxy that allows you to try again with a logon if the auto-digest doesn't work.Another setting you may have likely already checked:Intrenet Options -> Ensure your intranet server is in the "Local Intranet" sites listSecurity for the "Local intranet" zone is set to allow "automatic logon only in Intranet zone" I checked that and yes, it's in the Intranet zone.

Hi Sean (or anyone else reading this) - I have been searching the net for potential solutions to my lockout problem. Environment: Windows 2003 Native mode.Clients (XP and Win7)This problem is currently affecting a single account.The account in question (userid1) used to have domain admin rights. It used to login to the domain controllers to do what ever work needed to be done. Several months ago these accounts were removed from domain admins, and dedicated admin accounts were created to be used to login to the DC's for work required on the DC's.Event log from domain controller 1 (MOBDC) is indicating that 127.0.0.1 (itself) is the workstation which is causing the lockout.The hex is c00003234 (auto lockout happening)Fast forward to present.The other evening I manually changed the password for userid1 as it was coming up for expiration.Shortly thereafter, one specific domain controller (not the one which authenticates my login credentials by the way) is constantly (every hour I believe) causing the account to become locked.I have used Lockout Status and I have confirmed this to be the case. Only this domain controller and the PDC emulator are registering Bad Passwords.I have gone through the services and confirmed that this account does not show up as the run under account.I have checked TASKS (c:\windows\tasks) and show no tasks scheduled or otherwise which use this account.I had temporarily granted this account domain admin privledges (last night) so I could again login to the DC with it. Once logged in, I made sure there were no mapped drives.I then ran the command 'rundll32.exe keymgr.dll' to clear cached passwords. I ran this on the domain controller causing the lockout, and on the PDC emulator, and on my own client (just to be safe).I also ran control userpasswords2 to see if there were any cached passwords. There were none.I then removed the user id from the domain admins group and waited.On schedule, the account got locked again (I was monitoring the lockoutstatus using my real domain admin account from a second machine).I then logged my primary workstation off and shut it down.The account got locked out again.I logged back into the domain controller with my admin account, and deleted the profile for my old admin user id.Still locks out.This time I shut my iphone down (thinking that maybe it's login to exchange is causing the problem).Same issue. And no, we're not running any exchange or exchange related activities on the domain controller. It's a pure domain controller, no applications running on it.I tried resetting the password back to what it originally was (I had tried this first with no success, but I figured what the ____) before this all started, and the password is still locking out.I scanned the drives on the domain controller looking for any occurence of my old user id - checking file contents to see if it is stored somewhere. No find. No luck.I scanned the registry to see if the id was stored in there. No find. No luck.I am about at wits end. I do not have any ideas left of where to look or what to try.* I have also configured acctinfo.dll to capture the running processes at the time of a lockout. I've reviewed the log and compared the time stamp in the security log to when the first instance of a bad password occured - but unfortunately, I don't see any processes that were installed with my userid. Unless I am missing something else.Do you, or anyone else reading this?Maybe?I hope...ThxJoejoseph.glim@jmfamily.com

Maybe something to do with proxy authentication? Have a look at this - http://blog.danovich.com.au/2010/01/06/windows-7-locks-out-domain-account/

I checked it out, but I don't think it's applicable. I powered down both my XP machine, my Win7 machine and my iPhone (just to be safe). I left them all powered down for several hours. The account got locked out just as it always was. The strange part (or another strange part) is that the lockout occurs exactly hourly - so what kind of service makes hourly queries? Maybe that's something to think about.

We're also having this problem on a Windows 7 machine. We have checked everything we could think of, and run all the tools recommended. There's nothing stored in credential manager. IE has been wiped back to default. VM services (which we thought were the problem) have all been removed. Almost none of the services use the problematic id, so that doesn't appear to be the problem. We've wiped her smartphone to insure the stored password there isn't causing the problem. Mapped drives have been removed. Everything suggested here has been tried.The machine is running Windows 7 64 bit. None of our 32bit clients seem to have the problem. We're at a complete loss and may wind up formatting the machine. Any other suggestions?

Yeap...I'm in the same situation. Many accounts in the company are getting locked out and all of them run Windows 7. Doesn't matter if I delete all stored password, reset the IE settings, close the mapped network drivers, etc....the accounts get locked out. It's happening for both Windows 7 32 and 64 bits. It's being a nightmare.

I want to note that the lockout problem started happening for our Win 7 box around Christmas time. Prior to that, the machine had no problems with lockout. Win 7 had been installed in November (about a month previously). I'm beginning to wonder if it might have been an OS update/patch that caused the issue...

I followed the procedure that Sean mentioned above ( Aloinfo.exe /stored >C:\CachedAcc.txt ) and I found the GoogleUpdateTaskUser running under Task Scheduler. In my case, the user installed Google Chrome and it creates two Update Process under Task Acheduler. It was using a domain account to update every one hour. Thx

I read this thread and it all make sense now. http://social.technet.microsoft.com/Forums/en/w7itprosecurity/thread/d63261ff-9a18-460d-aa9b-e379b16a6d53 Check if you have any domain printer installed on your computer which is not part of the domain. I removed the printer and problem solved. I think this is a bug in win7 and need to be fixed in next updates.

I have a similar situation - Windows 7 Pro (x64) laptop in a Windows Server 2003 domain, frequently locks, none of the usual causes apply. I've gone through the recommendations in this thread (and here - Account Lockout Tools ) but nothing has turned up the process responsible for the bad credentials. I know which machine is causing the lock, and alockout.dll would be perfect, but it doesn't seem to work on Windows 7 x64. Is there an equivalent tool for Windows 7? dcsln

All above symptoms apply to me. Additionally, my account in question is a service account used for SiteScope monitoring and SCCM 2007 R2. we have two domains maindomain and dmzdomain and service accounts are maindomain\svcacct and dmzdomain\svcacct. Both service accounts are being configured in SiteScope monitoring and SCCM. account that frequently lockingout is maindomain\svcacct Below are the netlogon errors in PDC: 10/06 20:41:46 [CRITICAL] maindomain: NlpUserValidate: dmzdomain\svcacct: Can't find trusted forest 'dmzdomain' 10/06 20:41:46 [CRITICAL] maindomain: NlpUserValidate: dmzdomain\svcacct: Can't find trusted forest 'dmzdomain' 10/06 20:41:47 [CRITICAL] maindomain: NlpUserValidate: dmzdomain\svcacct: Can't find trusted forest 'dmzdomain' 10/06 20:41:48 [CRITICAL] maindomain: NlpUserValidate: dmzdomain\svcacct: Can't find trusted forest 'dmzdomain' 10/06 20:41:48 [CRITICAL] maindomain: NlpUserValidate: dmzdomain\svcacct: Can't find trusted forest 'dmzdomain' 10/06 20:41:51 [CRITICAL] maindomain: NlpUserValidate: dmzdomain\svcacct: Can't find trusted forest 'dmzdomain' 10/06 20:41:52 [CRITICAL] maindomain: NlpUserValidate: dmzdomain\svcacct: Can't find trusted forest 'dmzdomain' 10/06 20:41:53 [CRITICAL] maindomain: NlpUserValidate: dmzdomain\svcacct: Can't find trusted forest 'dmzdomain' 10/06 20:41:58 [CRITICAL] maindomain: NlpUserValidate: dmzdomain\svcacct: Can't find trusted forest 'dmzdomain' 10/06 20:42:07 [CRITICAL] maindomain: NlpUserValidate: dmzdomain\svcacct: Can't find trusted forest 'dmzdomain' 10/06 20:42:08 [CRITICAL] maindomain: NlpUserValidate: dmzdomain\svcacct: Can't find trusted forest 'dmzdomain' 10/06 20:42:09 [CRITICAL] maindomain: NlpUserValidate: dmzdomain\svcacct: Can't find trusted forest 'dmzdomain' 10/06 20:42:14 [CRITICAL] maindomain: NlpUserValidate: dmzdomain\svcacct: Can't find trusted forest 'dmzdomain' 10/06 20:42:20 [CRITICAL] maindomain: NlpUserValidate: dmzdomain\svcacct: Can't find trusted forest 'dmzdomain' Below are the netlogon errors during account lockout in site's DC: 09/06 16:03:28 [LOGON] maindomain: SamLogon: Transitive Network logon of dmzdomain\svcacct from sitedc1002 (via client38) Entered 09/06 16:03:28 [LOGON] maindomain: NlPickDomainWithAccount: dmzdomain\svcacct: Algorithm entered. UPN:0 Sam:1 Exp:0 Cross: 0 Root:1 DC:0 09/06 16:03:28 [LOGON] maindomain: NlPickDomainWithAccount: Username dmzdomain\svcacct is in forest dmzdomain (found via LsaMatch) 09/06 16:03:28 [CRITICAL] maindomain: NlpUserValidate: dmzdomain\svcacct: Can't find trusted forest 'dmzdomain' 09/06 16:03:28 [LOGON] maindomain: SamLogon: Transitive Network logon of dmzdomain\svcacct from sitedc1002 (via client38) Returns 0xC0000064 Nowhere I could found events for maindomain\svcacct lockout which is the account locksout repeatedly. Any help much appreciated.

This problem is really driving me crazy, i have tried all sort of solutions, spent days on it, we have about 40 Windows 7 in domain, this has been happening randomly to number of Windows 7 machines over last monthes, no pattern, only thing in common is, "it only happens to Windows 7", vista xp are all okay. every computer are setup the same way, i don't understand why it only happens to some, not the others. I have "fixed" some machines by different actions, either by taking off third party software, or by rejoin computer to domain, even though i don't know how exactly i fixed them, because it appears very randomly, and keeps coming back after a while!! I am now have problem again with one that happend three times before, and I "fixed" 3 times, now happening again. Everytime i press ctrl alt delete, and I can then see in LockStatus.exe, wrong password was tried 5 times then locks the account up, this is happending BEFORE I log on at all!!! and doesn't matter where I am, as soon as I press Ctrl Alt Delete, I gets locked out! and it doesn't matter which user account logs in to that computer, as soon as you press ctrl alt delete, it locks user Account A out, even i log in as user B or C, as soon as i press ctrl alt delete, it locks out user A!!! I hope I am not the only one having this problem!! Any help much appreciated!!!

I have been having the exact same problem with this. I found one solution and maybe this will help you guys out. When a user is logged onto a machine and locks their machine and someone walks up to that machine to switch users it does not close the profile of the locked user. It keeps that profile running in the background. This only occurs with windows 7. When the password expires or changes the profile that is running in the background keeps trying to verify againsts the AD controller and locking the account out. THe AD controllers do not record any events associated with this. So currently I have no clue how to locate the offending machine on the network. I lucked out and the user had only been using computers in one area. If you log in as a different user and look at the task manager you should see services running as the locked profile.

What happens when you rename the user account? Does the account continue to lock? Gary gwinn7

Thanks Gary, this makes sense. So far I couldn't try this (rename acct) as it will require to manually update in couple of places. I'll give a try later, and will post the result. Thanks again.

Hello All, I've been facing this issue since 26th Oct 2010. Since that time every few hours my AD account will be locked out even I am not at my machine or even if my machine is not in action (Started). I've the following: Windows version: Win 7 Enterprise Verion 6.1 (Build 7600) Internet Explorer Verision: 8.0.7600 Outlook Version: 2007 Communicator: Microsoft Office Communicator 2007 R2 Version - 3.5.6907.83 PDA: Nokia E72 Exchange Mailbox currently disabled due to frequent lockouts. Since the time this issue started my IT Support have tried lots of stuff to help me and had no luck (combing, event monitoring, etc). They thought that it could be possibly my OS that is ginving me a tough luck and re-imaged my machine, however had no luck. They now changed my Laptop and gave me a brand new Laptop, however I am still living with this problem and have no permanent fix. Please help me. Thanks and Regards Syed Hussaini. Analyst (Technology Specialist)

As mentionated in previous post : "Windows 7 laptop in own workgroup connects to a company network running a Domain. User keeps machine in workgroup but uses the company domain for shares and printers by clicking on the shares under available network resources and logs into domain to use them. The user changes their password for their domain account using their normal office desktop. Next time the user connects their windows 7 laptop it attempts to re establish the existing domain connection shares or printers using the old password ,constantly until it trips the the domain password policy incorrect log in setting and locks the user out of the domain Werealise the users can reset the stored password by right clicking and changing when the option is available. It still involves a domain admin unlocking the domain user accounts. Windows 7 doesnot give or ask user do they want to reattach to the domain and locks the user out by repeated background log in attemptswithout break. If user is a admin then they cannot log in or attempt to effect the change locally since everytime they unlock the account the windows 7 machine relocks it by repeat log in attempts before the user is given a chance to change the locally stored password on the Windows 7 machine. Suggest a prompt to the user about any stored domain log ins that their machine may not be a regular member." http://social.technet.microsoft.com/Forums/en/w7itprosecurity/thread/d63261ff-9a18-460d-aa9b-e379b16a6d53

This solved my problem and agree, this is a bug that needs to be fixed. I have a Xerox 6125 connected to my router which during some problems printing a while back I ran the printer troubleshooter from Microsoft which suggested that I enable sharing for the printer. As soon as I unchecked that and restarted my computer log on problems went away.

Hello, In our case this was related to an iphone with incorrect settings (cached credentials) Best check on your ISA to what the connections are being made. In our case this was towards the exchange server > activesync. So best check the IIS logs on the CASHUB servers. > in our case we could see failed attempts, which caused the AD account to lockout.

I have this exact same problem with Windows 7 Professional workstations causing my domain admin account to lock on the Windows 2003 AD Domain. I did find this Article 814511 dated October 6, 2011. It states that Microsoft has a hot fix for this problem. http://support.microsoft.com/kb/814511An Event ID: 644 message similar to one of the following may appear in the security log, even though no user accounts have been locked out because of bad logon attempts: Event ID: 644. Audit Success. Event User: NT AUTHORITY\ANONYMOUS LOGON. Event Source: Security. Event Detail: User Account Locked Out: -or- Event ID: 644. Audit Success. Event User: NT AUTHORITY\SYSTEM. Event Source: Security. Event Detail: User Account Locked Out: Target Account ID: SYSTEM The Event ID: 644 - User Account Locked Out security event is generated at the primary domain controller (PDC) to indicate that the user account was automatically locked out because of bad logon attempts. The security event is generated if the audit policy for the domain enables the Success for the User and Group Management audit category. However, this message may incorrectly appear in the security log, and it may not indicate that an account has been locked out because of bad logon attempts. A supported fix is now available from Microsoft, but it is only intended to correct the problem that is described in this article. Apply it only to computers that are experiencing this specific problem. To resolve this problem, contact Microsoft Product Support Services to obtain the fix. For a complete list of Microsoft Product Support Services phone numbers and information about support costs, visit the following Microsoft Web site: http://support.microsoft.com/default.aspx?scid=fh;EN-US;CNTACTMS (http://support.microsoft.com/default.aspx?scid=fh;EN-US;CNTACTMS) NOTE: In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem. The usual support costs will apply to additional support questions and issues that do not qualify for the specific update in question. The English version of this fix has the file attributes (or later) that are listed in the following table. The dates and times for these files are listed in coordinated universal time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time tool in Control Panel. Date Time Version Size File name ------------------------------------------------------ 01-Mar-2002 21:22 4.0.1381.7114 155,920 Lsasrv.dll 01-Mar-2002 21:22 4.0.1381.7138 174,864 Samsrv.dll These dates don't look right to me.

Not trying to Hyjack this thread BUT my issue below "MIGHT" be related I work the helpdesk for a very LARGE company. We have XP pro. (32-bit) OS on the desktops. We are slowly introducing Windows 7 Pro 64-bit loaded on HP desktops. We are seeing an increase of what we are calling Windows 7 lockout!!! User working on his Windows 7 PC locks his desktop before leaving for lunch. Upon returning for lunch user unable to unlock workstation. Gets invalid user ID & password. Opening the lockout status from my desk (user is on the phone) I see that the domain account is NOT locked. I ask user to enter the WRONG password & I see the bad password count increment to 1 I ask user to enter correct password and users PC responds with invalid userID or password & at the same time I see the bad password count revert back to 0 !!!! Workaround; Reboot PC & user can log back in OR Have user disconnect LAN cable & log-in. (PC uses cached credentials) Once logged back into LAN user re-connects LAN cable and all "appears" normal. Now, we are seeing the same issue with people trying to RDP to a Windows 7 desktop from home! Unable to determine what's causing this problem and it appears to be getting worse! Ideas, suggestions

Hi I have been busy with IT projects hence late reply. Catching up on all the updates I suggest you 1. Launce Procmon on the domain hosting the accounts and leave it to run, then dump the results when the lockup occurs. 2. You will definitely need to do an out of hours/weekend investigation on the domain controller and restart it completely. 3. Possibly create the user another account similar to the other one then migrate all his Data etc to the newly created profile/user share, then delete or disable the other account 4. Ensure that the domain god account has accessibility for any possible sub lockouts lower down the AD hierarchy http://www.lepide.com/