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 security hole has really irked me, so you may see this same thread on other forums as I feel more people need to know about this!

Hi IT2B, To answer your questions: 1. I was aware of this, and have had similar circumstances in the past where we needed to immediately prevent someone from sending/receiving messages. 2. Our work around has been to modify the mailbox properties, and to set the "Message Size Restrictions" (both sending and receiving) to 0 kb. Doing this will take affect immediately, and will prevent even an active OWA/Outlook session from sending/receiving messages. -Matt

1. Yes its by design IIS token caching. Exchange does alot of caching even diabling mapi, owa, activesync etc does not take affect right away as well. An old password still works after you change it in Outlook Web Access http://support.microsoft.com/kb/267568 XWEB: Mailbox Access via OWA Depends on IIS Token Cache http://support.microsoft.com/kb/173658 2. I can likely tell you most people don't anything in addition to just diabling the acct and changing pw. You can always disconnect the mailbox. James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

I can likely tell you most people don't anything in addition to just diabling the acct and changing pw. You can always disconnect the mailbox. James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com My guess is because it is not a widely publicized fact. You don't see this information in any Exchange training anywhere. Is it not a risk that a terminated employee still has access to company resources?

It can be but it's not that long as long as HR is following protocol to terminate the employee, taking issued resources, paperwork blah blah, I would think the time would have elapsed by then. It is full proof no not 100% of course. James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

In our situation we later learned she was still accessing mail until 10pm that evening via an Outlook Anywhere or OWA connection from a home computer before I learned about the credential caching and reset IIS. So there were no issued resources other than allowing employees to use OWA or Outlook Anywhere in the first place.

You can review the original thread, there are other options and yes other people have reported longer than 15mins up to hours. The only secure way is to disconnect the mailbox. http://social.technet.microsoft.com/Forums/en-US/exchangesvrclients/thread/3da53460-ef76-4f01-94c9-f7b96fdaf99d/James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

or you can disable mapi acess or move the mailbox to another db, maybe create a temp db for such use.Sukh

1. Yes I've seen that, though to be fair the issue with login caching causing a delay before disabling takes effect isn't limited to Exchange / IIS. 2. The method I use that seems to do the trick is to adjust the permissions within Manage Full Access Permission, and remove "AUTHORITY\SELF", which then removes the users permission to access their own mailbox. In my case we mainly use it as we sometimes have situations where we need to disable the mailbox but not the user, since the user's login is associated with other things not being cancelled. I haven't tested it extensively, but when I tried it on my own mailbox I immediately lost access to my mailbox by every method I tried.

I dont think disabling mapi access works right away as well since the protocolsettings are are cached by MBI.James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

See this for MSFT best practise, moving users will probably be the best option. http://blogs.technet.com/b/messaging_with_communications/archive/2012/06/27/part-ii-outlook-amp-owa-disabled-accounts-and-users-still-being-able-to-access.aspx Sukh

See this for MSFT best practise, moving users will probably be the best option. http://blogs.technet.com/b/messaging_with_communications/archive/2012/06/27/part-ii-outlook-amp-owa-disabled-accounts-and-users-still-being-able-to-access.aspx Sukh Microsoft told me that there is still a chance that the user can still log in even after moving the mail box if they continually try to log in while the mailbox is being moved. They recommend adding the following registry keys: HKLM\System\CurrentControlSet\Services\InetInfo\Parameters\UserTokenTTL Default is 900 seconds Can be decreased to 480 seconds This registry key controls the length of time that IIS caches a user token before IIS releases the cache and re-creates it. There is also a scavenger timer that basically Do not set this to " 0" as this will actually turn off UserTokenTTL,. Meaning tokens will never expire. To force the token cache to be flushed immediately, then set this registry to 1, and then back to 0. HKLM\System\CurrentControlSet\Services\InetInfo\Parameters\FlushTokenCache (REG_DWORD) Can be set to 1 If you set this registry key value to 1, the Token cache module registers for a change notification. A value of 1 flushes the token cache. This will have the tokens flushed without a full recycle of the application pool or IISReset.

Hi thanks for share. As far as I know, most of admin set Set Recipient\send Limits on staff who has left enterprise.Terence Yu TechNet Community Support

See this for MSFT best practise, moving users will probably be the best option. http://blogs.technet.com/b/messaging_with_communications/archive/2012/06/27/part-ii-outlook-amp-owa-disabled-accounts-and-users-still-being-able-to-access.aspx Sukh Microsoft told me that there is still a chance that the user can still log in even after moving the mail box if they continually try to log in while the mailbox is being moved. They recommend adding the following registry keys: HKLM\System\CurrentControlSet\Services\InetInfo\Parameters\UserTokenTTL Default is 900 seconds Can be decreased to 480 seconds This registry key controls the length of time that IIS caches a user token before IIS releases the cache and re-creates it. There is also a scavenger timer that basically Do not set this to " 0" as this will actually turn off UserTokenTTL,. Meaning tokens will never expire. To force the token cache to be flushed immediately, then set this registry to 1, and then back to 0. HKLM\System\CurrentControlSet\Services\InetInfo\Parameters\FlushTokenCache (REG_DWORD) Can be set to 1 If you set this registry key value to 1, the Token cache module registers for a change notification. A value of 1 flushes the token cache. This will have the tokens flushed without a full recycle of the application pool or IISReset. That's what it says in the kb I posted, there a recommendation for those keys but there's a possible perfmonance issue, I suggest you read that too before setting the keys and consider the other options too. Sukh

Hi Do you have anything update ?Terence Yu TechNet Community Support

Our final solution is to move the mailbox to a new database (even though Microsoft says this is not a fail proof solution.) From the comments above we will also remove the permissions from the mailbox. The answer seems to be that there are manual steps on the Exchange side that need to be done in addition to disabling an account. I was really curious to see if this was a widely known issue since we were taken by surprise by it. I also wanted to see what the common practice was and I think we are pretty in line with what others do now. I am still surprised that the IIS team doesn't find this to be a security issue. An I would love to know what Microsoft's internal IT does when people leave the company.

I prefer disabling the mailbox as soon as the remote wipe is confirmed. You can always reconnect the mailbox later to a dummy account to retrieve the data.

Hi You have communicated with MS support about this issue. You can tell your opinion to them. If this issue is reported many times, high level manager and engineer will pay attention to it.Terence Yu TechNet Community Support

Hi You have communicated with MS support about this issue. You can tell your opinion to them. If this issue is reported many times, high level manager and engineer will pay attention to it. Terence Yu TechNet Community Support Trust me, our opinion has been communicated. Our TAM did a great job of escalating up the Exchange team. Unfortunately, the process to really press the issue with the IIS team would really chew through premier support hours with no gaurantee that they will do anything about it in the end.

and this is really an issue that has existed for years and years. In the 2003 days, one trick was to start a mailbox move, then cancel it and leave the dialog box up asking to confirm the cancel. That effectively killed any client sessions to the mailbox.

A few points: Just because the issue has existed for years and because it is deemed a behavior by design - Should not lessen the fact that this is a Major Security flaw!! Hopefully more people see this thread and comment

A few points: Just because the issue has existed for years and because it is deemed a behavior by design - Should not lessen the fact that this is a Major Security flaw!! Hopefully more people see this thread and comment I never said I agreed with it or thought it was ok.