Came across this article wich shed's some light on why users can keep on sending and receiving email when their password is expired or the whole useraccount is disabled.
This means that when a user leaves your company, disabeling the useraccount just doesn't cut it.
Recently, an issue that has been around for some time started generating a lot of renewed interest. The issue I'm referring to is regarding Exchange users still having access for several hours after their AD Account has been disabled. This post is Part I of II, discussing why this happens and best practices to properly deal with/cut off access to users as quickly as possible relating to ActiveSync. In Part II, I will discuss this issue as it relates to Outlook and OWA and the best practices on how to deal with them
The main issue of concern is that if a user is terminated and just their AD account is disabled (which is a fairly standard process for many companies), that once their AD account is disabled it’s believed that the user is now stopped from being able to access anything using Windows Authentication, such as Exchange). However, that may not necessarily be true…especially with ActiveSync. If we’re talking about a terminated employee who was “walked out the door” and you want to IMMEDIATELY stop them from being able to send/receive emails via an ActiveSync device and all you've done is disable their AD account, they may still be able to sync for some time and send emails that you don't want sent. This can then open a whole slew of headaches.
Why Does This Happen?
The ability for ActiveSync to continue to work even though the user's AD Account has been disabled is because of several reasons. One of the main reasons is due to the way ActiveSync keeps a connection open to the server to watch for new messages. That connection has already authenticated and has been validated…so while the AD count may be disabled, all Exchange knows is that the user HAD rights to the mailbox and is continuing to use that connection. Eventually, the “life” of that authentication expires and the user has to re-authenticate (which is all done transparent to the user) and if the account was disabled, the re-authentication will fail and the user will no longer be able to sync. ActiveSync devices with their long heartbeat intervals and token cache can
still allow access up to 24 hours after an AD account has been disabled. This is also related to caching done by IIS and Exchange, which I will talk about more in Part II. But, in summary, just disabling a user's AD account will likely not stop them from accessing Exchange for at least a couple of hours if not more.
Best Practices to Follow Regarding Disabling User Access
- Before disabling the AD Account, you should do the following:
a. Trigger a remote wipe of the device - OPTIONAL
This may or may not be something you want to do depending on your company’s policies, if it’s a personal device, etc. However, once the sync is stopped through other means the device cannot come in and get the Wipe Request, so this is one of the first things that should be done if your company deems it necessary.
b. In addition, implement a block of all their devices (if you didn't issue a remote wipe and/or their device doesn't support remote wipe, etc):
If using Exchange 2010/Office365:
Get information about the user and devices
Get-CASMailbox <user> | Select ActiveSyncAllowedDeviceIDs, ActiveSyncBlockedDeviceIDs
Get-ActiveSyncDeviceStatistics –Mailbox <user> | fl DeviceID
Block all Devices for a user
Set-CASMailbox -Identity <user> -ActiveSyncBlockedDeviceIDs "<DeviceID_1>,<DeviceID_2>"
If using Exchange 2007:
Get information about the user and devices
Get-CASMailbox <user> | Select ActiveSyncAllowedDeviceIDs
Get-ActiveSyncDeviceStatistics –Mailbox <user> | fl DeviceID
Block all Devices for a user
Set-CASMailbox -Identity <user> -ActiveSyncAllowedDeviceIDs "BLOCKED"
(Note: The use of the string “BLOCKED” is to enter a string that does NOT match any device they may be using as setting this value will ONLY allow a device with that Device ID string to sync [which no real device would have the Device ID of “BLOCKED”] and all others to NOT be allowed to sync)
c. Disable ActiveSync:
Set-CASMailbox -Identity <user> -ActiveSyncEnabled $false
d. 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 ActiveSync to access. This solution is in lieu of ActiveSync disabling as outlined above.
2. Disable the AD account.
Do note, the above changes are
NOT instantaneous! It can take around 5-10 minutes for the ActiveSync device blocking 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 ask why we recommend using –ActiveSyncBlockedDeviceIDs
AND –ActiveSyncEnabled? It’s because the check for ActiveSyncBlockedDeviceIDs is checked almost continuously, since that part of Exchange is designed around the premise that devices are added or removed regularly. However, ActiveSyncEnabled’s setting is cached for up to 20 minutes and then may only be rechecked if IIS Token Caching has expired.
Best Practices to Follow Regarding Disabling User Access
Here are the best practices related to Outlook and OWA:
- Before disabling the AD Account, you should do the following:
- 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
- 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
- Set Recipient Limits to 0
Set-Mailbox -Identity <user> -RecipientLimits 0
- 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.
- Disable the AD account
Source:
Part 1
Part 2