Disabled Users Can Still Send Mail

Our company terminated an executive recently. We disabled her account and learned through a third party she was still sending mail from her corparate email.

Long story short we found this to be a known issue with IIS caching and resolved by resetting IIS. As long as the user has an active session in OWA or Outlook Anywhere they can continue sending mail until the cached credentials are flushed.

I opened a ticket with Microsoft. The response was that this "perceived" vulnerability is "by design" because OWA is a large app and IIS needs to cache everything or the the perfromance is slow.

The Exchange team has tried to raise this as an issue in the past with the IIS team, but the IIS group does not think it is a problem. And they claim this has been an issue going back several versions of Exchange.

Microsoft gave me some other "work arounds" such as moving the mailbox to another database while simultaneously making a resgistry change on the CAS servers.

My questions to all my fellow Exchange admins:
1. Is this a widely known fact? I work with several people with years of Exchange experience who did not know this.

2. What are your termination procedures? I doubt large companies are resetting IIS or bouncing their CAS servers every time someone leave the company!

The refusal of Microsoft to acknowledge this as a probelm has really irked me, so you may see this same thread on other forums as I feel more people need to know about this!

Find more posts tagged with

Comments

undomiel

It's a somewhat well known issue, you'll see a lot of threads on it if you start google searching around. Depending upon how critical it is that the user be cut off immediately determines whether I do an iisreset /noforce /timeout:120 or not. Usually I'll just disable mail access protocols on the account then disable the account.

cyberguypr

I also have seen the issue on other boards. The quickest/less disruptive solution I found to be effective without messing with IISreset was removing NT Authority\SELF from 'Manage Full Access Permission'. Even though it didn't kill the OWA connection it basically killed all functionality. Still allowed me to comply with my account retention and archiving policies.

bigdogz

it2b wrote: »

I opened a ticket with Microsoft. The response was that this "perceived" vulnerability is "by design" because OWA is a large app and IIS needs to cache everything or the the perfromance is slow.

The refusal of Microsoft to acknowledge this as a probelm has really irked me, so you may see this same thread on other forums as I feel more people need to know about this!

undomiel and cyberguypr are right.
Vulnerability by design by Microsoft issues are "features". Believe it or not Microsoft used do be worse. They are getting better but there are times when they revert back to their old mentalities.

it2b

bigdogz wrote: »

undomiel and cyberguypr are right.
Vulnerability by design by Microsoft issues are "features".

They were trying to tell me that cached credentials are a "feature" accross all Microsoft platforms. Drive Mappings, terminal services, Active Directory. Pretty eye opening stuff.

Chivalry1

Yes this has been a known issue with Microsoft. Especially if you are using Microsoft Forefront Threat Management Gateway or ISA servers. This is the security control I put in place:

Disabled Users were moved to a DISABLED OU in Active Directory.
A daily automated Exchange Powershell script ran against that particular OU that:

1.) Disabled All Mailbox Feature options: ActiveSync, OWA, POP, IMAP, MAPI
2.) Set the "Maximum message size" to 1kb. (Effectively disabled sending any real emails)
3.) Hide user from Address Book

Im sure I could have done more things with the script. But this was very effective and the script was easy to write.

blargoe

When I was managing Exchange, I disabled send and receive on the mailbox from anyone but Postmaster, and turned off access protocols.