Options
Disabled Users Can Still Send Mail
it2b
Member Posts: 117
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!
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!
Comments
-
Options
undomiel
Member Posts: 2,818
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.Jumping on the IT blogging band wagon -- http://www.jefferyland.com/ -
Options
cyberguypr
Mod Posts: 6,928 Mod
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. -
Options
bigdogz
Member Posts: 881 ■■■■■■■■□□
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. -
Optionsit2b
Member Posts: 117
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. -
Options
Chivalry1
Member Posts: 569
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."The recipe for perpetual ignorance is: be satisfied with your opinions and
content with your knowledge. " Elbert Hubbard (1856 - 1915) -
Options
blargoe
Member Posts: 4,174 ■■■■■■■■■□
When I was managing Exchange, I disabled send and receive on the mailbox from anyone but Postmaster, and turned off access protocols.IT guy since 12/00
Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
Working on: RHCE/Ansible
Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands...
