How to investigate windows network lockouts related to Outlook Exchange Server authentication?

Question

I am an end-user, not an IT professional. Unfortunately my corporate resources cannot solve this problem. I am looking for some advice to give them.

I've been account locked on our corporate network an average of 2-3 times a day over the past four months. I've gone days without problems and been locked out 7 times in a single day. In the preceding 8 years I'd been locked out twice.

Each lockout requires a call to our corporate help desk to get my account unlocked. The lockouts occur because our security system "thinks" I'm trying to authenticate repeatedly with invalid credentials (wrong password).

The full details of the extremely tedious debugging process to date are in a blog post of mine: http://tech.kateva.org/2009/05/debugging-network-account-lockouts.html.

About a week ago I hacked away at Outlook 2007 and my lockouts went away. The cost was that I had to manually authenticate (domain/usermane and password) the first time each "day" that my Outlook client connected to Exchange server. Annoying, but I could live with that.

Since I began this process my laptop has been refreshed. I have new hardware with a pristine corporate standard disk image and I'm back to Outlook 2003. I'm also back to being locked out!

So I don't think the problem is on my laptop.

On further investigation I discovered that if I sent Outlook 2003 to always request credentials that I was NOT locked out.

So I need to understand how the authentication process differs when I

a. Outlook connects to Exchange and automatically authenticates (standard behavior) using the credentials associated with my user account (NTLM network domain/un and pw).

b. Outlook connects to Exchange and I have to manually enter my network un and pw.

Somehow 'b' works correctly. I think, however, that with process 'a' Exchange Server (our Outlook?) is sending the wrong credentials to Active Directory causing me to be locked out.

I suspect a misconfiguration of my Active Directory account and/or my Exchange Server mailbox.

I need to provide our help desk and security desk with a good list of things they can investigate on Active Directory or Exchange Server. If I cannot do this I will need to get a new Corporate ID and give up on my existing user ID.

I think if I can point them in the right direction, and give them pretty precise guidance, that they can fix this problem.

Any advice would be of help. I may simply have to research how NTLM (AD) authentication works with Exchange Server requests.

Answer 1

We had issues with account lockouts in a large org I worked for in the past.

What I did (as a member of the IT org) was to build a script which sat on the PDC (now PDC emulator). Whenever an account is locked out, this domain controller registers an Event ID # 644 (4740 on Windows Server 2008) in the Security log. The event also includes the name of the client machine which attempted the last logon with improper password. So my script polled the Security Log every 5 minutes and posted this data to a web page which was accessible to the Help Desk.

Once we had this, it was a trivial matter to change Help Desk's workflow to check that page whenever they got an account lockout issue, then help the user discover what it was on that machine which had caused the lockout. As you note in your blog article, the culprit is usually some second machine where the user had forgotten that they were logged on when they changed their password from their primary machine. Usually that second machine would be running Outlook, or have a drive mapped via the user's (now out of date) credentials.

And when Help Desk had lulls in their day, they could proactively check this web page and resolve issues for people who didn't yet know they'd been victims of account lockout.

If there is interest in this script, I could dig it out, dust it off, and post it here.

Answer 2

I am making an assumption that the username, password and domain that you use for Exchange is identical to the credentials you log onto your computer with.

If the problem has reoccured after re-installation of the corporate SOE, and it only happens to you... do you have a roaming profile, or your settings in any other way pushed to a network location? If so that would explain why the problem followed you over a workstation refresh. Your blog post says you "restored data" onto your new SOE. Are you certain you didn't restore the offending application?

Uninstall any plugins you may have added to Outlook 2003, and any other non-standard (as in, not something your IT department installs for you) customization you have put on the new SOE since you received it.

Most times I see this it is been because someone has left their old credentials in a scheduled task, or in a locked remote desktop session. You could try using a combination of Wireshark and Sysinternals tools to identify the offending process on your machine that is causing the lockouts (assuming it is from your machine).

UPDATE

This link from Microsoft may help you and/or your IT team with the issue.

[Troubleshooting Account Lockout](http://technet.microsoft.com/en-us/library/cc773155(WS.10).aspx "Microsoft Technet")

Answer 3

Another answer, again from the IT point of view, would be to rethink the account lockout policy.

It's not uncommon to see the lockout policy set such that 10 bad login attempts within 10 minutes causes complete lockout until an admin resets the account. Not only that, such a low limit makes you vulnerable to a simple Denial of Service (DoS) attack: a BadGuy(TM) needs only to use 10 bad passwords and now he has locked out the account. Imagine this happening to 500 accounts! I've seen it: it's no fun. Worse, imagine it being done to all of your admin accounts!

It's my contention that this limit can be eased greatly at only minimal increase in security risk.

Bruteforce password hacking, if the password is even minimally complex, requires thousands or millions of attempts before it has any decent chance of success. So why not consider a password policy that allows 50 logon tries in 5 minutes, and then resets automatically after 5 minutes? At this rate (50 tries every 5 minutes), most bruteforce scripts would simply give up, but most cursory DoS attempts would not reach the limit. Those bruteforce scripts which did understand that the account unlocks after 5 minutes, allowing another 50 tries, would be limited to 7200 tries per day. You can fiddle the limits around to whatever you like, of course.

Answer 4

I'm going to answer my own question. I've not been locked out for over a week even after turning re-enabling Outlook pass-through authentication, so even though there was no definitive cure I can report where I left things.

As a reminder, the last time I was locked out I'd just received a brand new laptop with a fresh corporate image.

The very last two things I did were:

1. I found the brand new corporate image included two drive mappings. Sigh. (Sound of head hitting wall.) I'd removed them from my old laptop long ago, but they were back. I removed them again. It wasn't the only problem in the corporate image.
2. I experimented with switching Outlook 2003 authentication between "automatic" (default), Kerberos only (modern) and NTLM only (legacy). Switching to Kerberos only seemed to resolve problems, but I think that was a red herring. Switching back to the default didn't restore the lockout problem.
3. I use Retrospect Professional for Windows to backup my workstation to an external drive. (Corporate backup isn't bad, but restore takes about a week.) That software has an autolaunch feature. I'd set it to auto-launch using the logged-in credentials rather than the treacherous feature of providing credentials. I wonder though about an intersection between the mapped drives and the auto-launch. I turned off Retrospect Pro auto-launch for now.

I very much appreciate the link Neobyte provided to Microsoft's revised troubleshooting page:

http://technet.microsoft.com/en-us/library/cc773155%28WS.10).aspx

I'm left with some psychic scars. Given the astounding variety of problems associated with Microsoft's authentication services and their pile of legacy hacks, and the intersection with distributed authentication and post-hoc security features like authentication lockouts, I'm now deeply conservative about my use of any new or novel corporate network or "cloud" initiatives. They need to be built on a far more robust infrastructure than what Microsoft provides, and they require both IT funding and IT reorganization to implement.

Answer 5

One thing that is niggling at me is the possibility of a time-sync problem on the DC's and possibly your workstation that's getting in the way of Kerberos. Bad time can lead to failed logins, which count against lockout. The command "w32tm" can help you diagnose if your workstation is drifting time from the DC's or your Exchange servers (or from each other). You don't need any special privs to do checking for that command I believe.

It is my guess that the manual Outlook login is starting a brand new login session, rather than attempting to reuse the token you got when you logged in your desktop session. For whatever reason, this isn't getting stale the way the desktop login was.

The next thing I'd look for would be suspicious Event Log entries, but I presume that's already been done. Unfortunately, I can't describe what 'suspicious' would look like. I'd compare a normal pass-through login to Exchange versus your failed login and start googling the differences if it wasn't obvious. :}

Answer 6

We had a problem not long ago with a user's account repeatedly locking out. Turned out he had tried to set up his email account via an IMAP client (iPhone in this case) and as our password policy requires a password change every 30 days, when he changed his password but did not update it on the iPhone his account kept locking out due to the incorrect password being used.

Worth checking at least.