Partager via

Part II: Disabled Accounts and Users Still Being Able to Access via Outlook & OWA

  • Article

In Part I, I provided information regarding users’ mobile devices still being able to synchronize with Exchange (via ActiveSync) even after their AD Accounts have been disabled.  I included related best practices on how to stop devices from syncing as quickly as possible.

Here, in Part II, I’m going to discuss a similar issue with Outlook and OWA and the best practices on how to deal with them.  Be aware that in many places I will only mention “OWA”, this information is also applicable to all web-service related Exchange connectivity such as EWS (used by Outlook for Mac 2011, etc) and Outlook Anywhere.

To recap the issue I’m referring to:

Many companies simply disable the AD Account when an employee is terminated and assume that very quickly (e.g. within a couple of minutes) the user will no longer be able to access any Windows Authentication-based resources, including Exchange through any of its access methods, because the AD Account has been disabled.  Unfortunately, that is NOT correct.  For many hours after the AD Account has been disabled, users may be able to continue accessing Exchange and be able to send, receive, etc.  This happens for a number of reasons (which I’ll discuss below) and can become a huge issue, especially when dealing with terminated employees who have been “walked out the door”.

Why does this happen?

First and foremost, in order to scale and be efficient, a lot of caching goes on within IIS and Exchange.  IIS plays a major role here as the Exchange-based web services run under IIS.  Besides the caching in IIS, Exchange also does its own caching…more than just data caching in memory, but active connections to the store (Exchange 2007) or RPCClientAccess (Exchange 2010) are cached for up to 2 hours which effects the authentication of Outlook MAPI (RPC) connections. 

The main component/feature of IIS involved is User Token Caching in IIS.  The default is 15 minutes, and so if a connection is made within 15 minutes of the last connection the cached token information is reused instead of checking with AD.  You can adjust this value (see KB152526), but be aware that reducing this time will put additional load on the DCs and depending on open connections may still not go into effect quickly.  Also, be aware that while Internet Explorer (IE) will very strictly follow this, other browsers have been found to NOT do so and so this can mean other browsers may continue to provide access when IE no longer does.

Best Practices to Follow Regarding Disabling User Access

Here are the best practices related to Outlook and OWA:

  1. Before disabling the AD Account, you should do the following:
    1. Disable Web services for the mailbox:

For Exchange 2007:

Set-CASMailbox -Identity <user> -OwaEnabled $false

 For Exchange 2010:

Set-CASMailbox -Identity <user> -OwaEnabled $false

Set-CASMailbox -Identity <user> -EwsEnabled $false

Set-CASMailbox -Identity <user> -EwsEnabled $false

Set-CASMailbox -Identity <user> -EcpEnabled $false

    1. Disable MAPI services:

For Exchange 2007:

Set-CASMailbox -Identity <user> -MapiEnabled $false

Set-CASMailbox -Identity <user> -MapiBlockOutlookRpcHttp $true

For Exchange 2010:

Set-CASMailbox -Identity <user> -MapiEnabled $false

Set-CASMailbox -Identity <user> -MapiBlockOutlookRpcHttp $true

Set-CASMailbox -Identity <user> -EwsAllowMacOutlook $false

Set-CASMailbox -Identity <user> -EwsAllowOutlook $false

    1. Set Recipient Limits to 0

Set-Mailbox -Identity <user> -RecipientLimits 0

    1. Disable the mailbox (at least temporarily) - OPTIONAL

Note: It’s understood that some companies leave the mailboxes enabled to receive email so that OOF/automatic responses can be generated or so that no emails to the address are not blocked. If this is the case, it’s recommended that you disable the mailbox for approximately 30m-1h and then enable again. This will allow time for the change to go into effect and stop allowing clients to access. This solution is in lieu of disabling as outlined above.

  1. Disable the AD account

Just like I stated about the steps yesterday, implementing the above steps are NOT instantaneous!  It can take around 5-10 minutes for the disabling of the protocols and/or settings to go into effect, and that’s from the time that the change is replicated to all the DC/GCs used.  Obviously, if you make the changes against a DC/GC in another site and it has to replicate to the Internet-facing Exchange site(s) more time is needed.  The other settings can take up to 20 minutes to go into effect due to caching.

You may notice that while we recommend setting –RecipientLimits on the mailbox, we do NOT mention setting the Send and Receive Quota settings.  This is because the RecipientLimits changes go into effect very quickly whereas changing the Send and Receive Quota settings do not.  While you can change the Send and Receive quotas as well, as it relates to this issue it is not a recommended workaround and won’t help in the short-term.

One option I did not mention yesterday, which is a workaround that works for ALL the connection methods (ActiveSync, OWA and Outlook) is to MOVE the mailbox.  Not really a great option (especially if dealing with a very large mailbox and/or you have no place to move it to).  But if the mailbox gets moved it causes all the existing connections to be reset (Note: this doesn't happen until the 2nd phase of the Online Mailbox Move process in Exchange 2010…it happens immediately with Exchange 2007 as Exchange 2007 does NOT have Online Mailbox Moves).

I’d be remiss to not mention another option related to web-based services (including ActiveSync) which would remove the caching impact is to bounce the IIS service (e.g. IISRESET), which clears all caches and reset all connections due to service restart.  However, this would be required on ALL Exchange CAS servers possibly used and would impact many (if not all) users.  Obviously, not a good solution…but in an urgent situation could be used and would go into effect the quickest.

A follow-up question I received is also whether changing the password on the AD account would help.  The answer is, no.  You may notice that after a user’s password is changed both the old and new password may work for some time and/or the new password doesn’t start working right away.  This is because the old token, which was validated and gets cached (see above), is still considered valid and continues to work.

Comments

  • Anonymous
    January 01, 2003
    Nice Job documenting this!

  • Anonymous
    January 01, 2003
    Those are Exchange Management Shell commands.

  • Anonymous
    January 23, 2014
    Great post, nice to read how it al works in the background.

  • Anonymous
    February 10, 2014
    Can the techniques and PowerShell commands in this article be abstracted to work with Office 365 via connecting PowerShell to Exchange Online? We recently had a user terminate at one of our clients, we're all fairly new to Office 365 and as it turns out, he had access to his mailbox for up to 6 hours because of the default session timeout. Thanks!

  • Anonymous
    August 05, 2014
    Does the same thing hold true for Lync?

  • Anonymous
    September 29, 2014
    Does this method work for exchange online?

  • Anonymous
    October 14, 2014
    Excellent post. Thanks for the clear explanation.

  • Anonymous
    January 14, 2015
    Thanks for Sharing!!

  • Anonymous
    April 21, 2015
    For us novices, where do you run these commands?

  • Anonymous
    June 10, 2015
    Including a "Disabling Lync" section would be helpful for my environment.

  • Anonymous
    September 15, 2015
    Why isn't there a button or a wizard for this in Office365? I'm not against PowerShell at all, but every O365 customer shouldn't have to roll their own program just to let an employee go.