Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When a user changes his account password for whatever reason (read: expired), and the old password is stored in his mobile device connected through EAS. This will cause his account to lockout almost immediately - as it should according to the lockout policy defined in the AD. It was easy to figure out that part. The hard part is keeping it from happening. I looked everywhere. Nothing. Basically there are four parts to the puzzle: the EAS device, the TMG (ISA) server, the EAS protocol and finally the AD. None of them have a way to stop the EAS device from failing to authenticate. So I figured I'll have to come up with a clever workaround. And the only thing I could come up with is to create a group for all EAS users and exclude them from the lockout policy, which obviously defeats the whole purpose of the policy, or to educate the users to update their devices with the new passwords, which is impossible.

The question: Can you think of any other way to prevent EAS from locking out the accounts?

Environment: Mostly iOS devices all through EAS. TMG 2010. Exchange 2007. AD 2008 R2.

share|improve this question
great question, seriously. – SpacemanSpiff Mar 17 '12 at 12:11
Lockout policy should be between 10 and 50 according to Microsoft Security Compliance Manager. What's yours set to? – TristanK Mar 18 '12 at 23:08
Good question, I'm curious if there will be a worthy solution. – TheCleaner Jul 6 '12 at 13:13
You could be uber-clever and implement a forward proxy that shapes the authentication attempts.. AFAIK EAS is HTTPS based.… – Grizly Aug 9 '12 at 23:48

Normally what we tell users is to put the device in "flight" or "airplane" mode, cutting off network access when they are ready to change password, once they change the password on Desktop/Laptop, then they can enter the new password in device and connect back to network.

Of course we also send the expiry notification so that they are well prepared for the password expiry.

share|improve this answer
That's a good idea but from my experience, depending on the users to solve a problem will create more problems. We already have a procedure in place on how to change the password without getting locked out but nobody follows it. – Abdullah Mar 19 '12 at 4:45
I forgot to add, the users will have some time to update their passwords without getting locked out as the authentication happens every 15 mins. – Abdullah Mar 19 '12 at 4:55
this is "people" problem and trying to solve using technology will reduce security of environment as there is no way to achieve the ideal scenario. If this was BlackBerry this would not have been problem :) – KAPes Mar 20 '12 at 17:23

TMG SP2 has now the Account Lockout Feature to prevent this issue. See: Here, here and here.

share|improve this answer
Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference. – Scott Pack Oct 10 '12 at 16:26
While the TMG Account Lockout feature might come handy for many use cases, it only covers form-based authentication. ActiveSync seems not to use form-based auth, so it looks like it would not work out in the original poster's scenario. – the-wabbit Jan 14 '13 at 8:34

I've been challenged by this question as well. As a serious option I'm considering certificate based ActiveSync authentication. Together with the EAS policy to demand a password code for unlocking the mobile device this should count as two-factor authentication (something you have: certificate on your mobile device, something you know: password code for your mobile device). This way there is no issue when the password expires. Hope this helps.

share|improve this answer

Its up to the device to tell the user that authentication failed. I think a better answer is to use something like Good messaging for enterprise on the ios devices which I believe provides enterprise EAS support.

share|improve this answer
iOS does show a popup message to update the password but by then the account already been locked out. Good messaging seems like an overkill, I think. – Abdullah Mar 19 '12 at 4:47

This is a good question. Unfortunately, I haven't come across a way for preventing the device from trying to authenticate until the password has been updated. The only thing you can do is exclude the user from the password policy or document how to change the password on their device and remind them every time their password expires and they need their account unlocked.

You could also use a script or a program to email people that their passwords are going to expire in x number of days and include a reminder that they need to change the password on their phone.

I was expecting to have this issue at my current employer since I implemented a password policy in November, but so far, my mobile users seem savvy enough to change their passwords without being reminded.

share|improve this answer
Excluding the users seems like the only solution but not a very good one, though. Our users already get a notification before their password expires with complete steps on how to update their password properly to avoid the lock but nobody reads. I'd suggest you test your policy maybe it's not even working unless you're working for NASA and even then I doubt it. – Abdullah Mar 18 '12 at 5:24

You may want to test how the device(s) authentication attempts behave when not using the "Always Up To Date" functionality. If a device is configured to poll every five minutes instead of using Always Up To Date, and that does not incur the rate of authentication failures that triggers account lockout, this may be a viable workaround.

share|improve this answer
I tried that, the TMG server is configured to ask for authentication every 15 mins. The users will have time to update their passwords before the next authentication occurs but we cannot depend on the users. I also tried to find out how many times iOS tries to authenticate before giving up but could not, neither by testing nor looking into Apple's useless documentation. – Abdullah Mar 19 '12 at 4:53
Seems like it would be fairly straightforward to determine the number of authentication attempts by examining the IIS logs. – Greg Askew Mar 19 '12 at 12:57
Yep, after posting my comment yesterday I realized I could examine the log for the info, so I did just that. I didn't find what I was looking for but I'll keep looking. – Abdullah Mar 20 '12 at 4:54

This seems to be a device problem with the iPhone trying too often using the old, meanwhile incorrect, password. Apple posted a technote on this problem promising better experience with devices on iOS7:

share|improve this answer

Block out the originating IP address on the firewall in front of the Exchange server

share|improve this answer
We are talking about legitimate users who are in the process of changing a current password mate, not blocking malicious users. – Grizly Aug 9 '12 at 23:44

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.