Part I : Disabled Accounts and ActiveSync Devices Continuing to Sync

Part I : Disabled Accounts and ActiveSync Devices Continuing to Sync

  • Comments 4
  • Likes

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

  1. 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. 

 

Comments
  • Great article ! Thank you for sharing !

  • Hi Joe,

    If I set the logon hours in AD on the user account so that no logon hours are allowed, will that not block access to Exchange immediately ?

  • Link your second part of article here. It does simply help reader to reach at second part of article. Rather then search again.

  • 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

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment