Around a year ago we implemented our policy whereby all contractor accounts must have an expiry date. We had a large number of contractors in the organisation, and while our “leavers” process was working reasonably well for permanent employees its wasn’t so great for contractors. In the third quarter of last year the first of these started expiring. This caused some unexpected problems.

Firstly, Windows / Active directory did not warn the users or any administrators about the pending expiry of the accounts. Unlike password expiry, account expiry just happens. We implemented a script to send an email warning to all users who have accounts that are going to expire so that if their contract has been extended they can get the expiry shifted out ahead of the expiry date and prevent a deluge of calls to the service desk all on the same day. Robert Martin has a nice writeup on this on his blog with sample script code to do this on a regular basis and send summary mails of all accounts about the expire.

Secondly, expired accounts still have some “rights”. What? Some users were still able to perform functions after their accounts expired. If they logged into their laptop while connected to the network it would give an account expired error and prevent login, but, disconnecting the workstation from the network allowed a local login.  Once logged in, connecting to the network would allow email to be sent and received through exchange for a period (anything up to 48 hours or beyond). Further, they could still replicate mail to their iPads via ActiveSync, and continue to use their Blackberries as per normal. This was somewhat of a surprise and needs further investigation.

Searching around on-line found some partial explanations but they did not cover the scenario entirely. These were mostly talking about Outlook Web Access and the period for which IIS caches tokens (being 15m by default), and how this results in a user whose account has expired or been disabled being able to log in during this windows and send and receive mail. Some were horrified by this situation, and one even quoted a scenario (unconfirmed) of a network admin being disciplined when a senior company official who had been dismissed was able to log in after the account was disabled and send undesirable mail to all staff at the company.

XWEB: Mailbox Access via OWA Depends on IIS Token Cache (KB 173658) :

SYMPTOMS : After you remove the Log on Locally right for a user on a computer running Microsoft Internet Information Server (IIS), the user may still be able to log on to his or her Microsoft Exchange Server mailbox via Microsoft Outlook Web Access. This behavior is temporary and depends on the length of time that user tokens are cached on the server.

CAUSE : For performance reasons, user tokens are cached by IIS and updated at 15- minute intervals. The first time a user logs on via a Web browser, the user’s user token is created. If the Log on Locally right is subsequently revoked, the user can still access the mailbox for approximately 15 minutes.

To work around this problem, do one of the following:

• Restart all the IIS services (Gopher, FTP, and WWW). This will refresh the token cache on the IIS computer. For performance reasons, this is the preferred method if updates are infrequent. -or-
• Change the default interval for the token cache by editing the Microsoft Windows NT registry. (Explained more in KB152156)

There are some further discussions over on social.technet.microsoft.com which explore this a bit further.

The above doesn’t really provide real solutions. The 15m period is set like that because of performance reasons and reducing it will reduce performance. Restarting all the IIS services will disrupt the webmail service and in a large organisation this may not go down well. In an extreme situation, such as having just fired an exec, it may well be justified. However, this “process” will then have to be written into the standard operating procedures so that at the time of the dismissal it is not overlooked.

Paul Beckford over on Quantum of Geek, in an article from 2010, describes a situation where an hour after being terminated (and disabled) a terminated user was still sending mails out to the organisation. This aligns a little closer to the scenario we were experiencing. Paul also provides another option to more immediately disable mail in the event of termination.  He suggests moving the mailbox to another server or to a different mail store. Paul rightly indicates that in these scenarios one would not necessarily want to block incoming mails as these may still be required for ongoing investigation. Would moving the mailbox to another store in any way be considered tampering with evidence in a subsequent forensic investigation? I am not sure on that one, so you may need be careful there too.

None of this however explains the situation we found happening to a satisfactory level. Our outlook client installations do have OWA configured, so it is entirely possible that when the users were able to send and receive mail it was happening through OWA and not directly on Exchange. What is strange is how erratic the position was and how it took a few days before access was completely blocked.  What still needs to be done is to examine the config of the OWA and ISA/TMG to see if either of these is causing the token to be cached for a period longer than the 15m.

More to follow, if the true explanation is ever found. In the meantime, a process is in place to disabled expired accounts shortly after expiry, and being aware of the recommendations of Paul means if finding ourselves in that situation we can be better prepared.

 

Tags: Account, Exchange, Exchange 2010, Expired, Outlook

Categories: Security

---