If you have been doing systems administration for any length of time, you have probably dealt with the disgruntled employee “termination” situation. Typically, you, your boss, or the Help Desk gets a call from HR (probably outside of normal account termination/offboarding processes), requesting all access for a specific account to be disabled immediately. Sometimes, the request specifies disabling the account at a very specific time or perhaps warning you to be ready to do so.
Our Help Desk recently received one such call and were requested to promptly disable an account of a remote user. However, approximately an hour later, our management contacted me because the terminated and disabled user was “still sending email!” Now, I have no idea regarding the content of the emails the user was sending, perhaps some vitriol regarding the company to our customers or perhaps sending new contact information to their new position at our competitor (I didn’t delve into content as that is not and should not be the job of IT unless directed to do so in conjunction with HR and Legal), what did concern me however, was that we could not stop her from sending (and receiving) email… short of some extreme measures.
Looking into this further by recreating the situation, I found what I believe to be a security loophole in the normal account termination procedure in most Active Directory/Exchange based IT companies. The scenario simply involves the user being logged into Outlook and connecting to the Exchange server via RPC or RPC/HTTP(S) “prior” to the account becoming disabled. Although the account, and thus the mailbox, is disabled, the user may continue to send and receive email until they restart Outlook or are forced to reconnect (possibly due to a dropped connection). When I tested this scenario, I continued sending and receiving email despite my test account being disabled. In fact, nothing I did to account settings (restrictions, permissions, expiration, etc), short of resetting the Exchange server, restarting IIS, removing “Exchange Attributes” or moving the mailbox to another store (or other action to disrupt Outlook connectivity to the mailbox) disabled my ability to send/receive email from the mailbox of the “Disabled” AD account.
In this specific situation, it seems to me the only course of action to ensure a remote user account is truly disabled and cannot send or receive emails is disrupt connectivity. I believe the least disruptive (to other users) is to move the mailbox to another Exchange server or storage group. If that fails (if the mailbox fails to move for whatever reason) then a restart of IIS on the OWA server through which RPC/HTTP(S) is hosted, or a restart (or cluster failover) of the Exchange services on the mailbox server may be necessary. It may also be possible to simply remove the account’s Exchange attributes. However, that is sometimes not a viable option as the business may still want to capture email sent to that user, or archive the mail so that another employee may take over their job functions such as dealing with customers.
I’m sure there are other ways (block the source IP via the firewall, etc) but a mailbox move and/or a restart of IIS should do the trick in a pinch. Perhaps your SOP for account terminations should account for multiple potential termination scenarios and procedures to act accordingly or perhaps simply moving newly disabled user’s mailboxes to a “disabled users” mail store will do the trick.
Paul Beckford is an IT professional based in Denver, Colorado. Over the last dozen years, Paul has worked “hands-on” in an IT Operations role deploying and supporting a multitude of technologies, such as Network Infrastructure, Windows and Linux servers, most Microsoft Back Office & Infrastructure applications, Virtual Computing, Mobile Computing and Information Security.
I have to say that for the past couple of hours i have been hooked by the amazing articles on this site. Keep up the great work.
We also have experienced this, however it is not limited to Outlook, but any device they are using to connect to the Exchange server i.e iPhone etc. Resetting the password and disabling the account will not have any affect if they have already established a connection. This seems to be a “Feature” of Exchange where the AD token of an account is not checked. To overcome this we have resorted to changing the “Message Size Restrictions” and limiting the send/receive size to 1kb.
We have a lot of iOS users and the remove sync function does not remove the account nor remove the contact or calendar entries. restarting IIS does indeed cause email not to flow anymore, but the existing emails are still there for them to see.
This is just unacceptable.
I found this blog after encountering the exact same scenario. What we’ve seen is resetting the user’s password prompts them in Outlook to authenticate no matter how they’re accessing Outlook, which forces the disconnect.
That’s a good point. Its seems to me I would have tried a password reset but I guess I had not thought of it. This would be better than moving the mailbox, easier to script as well if you have an automated account de-provisioning process.
Amazing that this hole exists! Thanks alot for pointing out your discoveries, it has been helpful to me in resolving the same issue.