none
Disabled Account Can Still Access OWA

    Question

  • Hi all,

    We lost an employee today.  I disabled his account through the Active Directory Users and Computers snap-in and he was still able to login to his e-mail via OWA and send/receive messages. 
    When I was alerted to this, I also went ahead and changed his password and I tested logging in to his account; it wasn't accepting the new password.  I knew his old one though and was still able to log in to OWA with it.  We're talking a good hour after I initially disabled his account at this point. 

    It wasn't until I ran a GPUPDATE /FORCE on the CAS and a DC before OWA finally recognized that his account was disabled. 

    So, why is it that he was still able to log in an hour after I disabled his account?  Some sort of domain caching?  How can I prevent this in the future? 

    As an aside, as a company policy, user accounts are kept for 60 days and mailboxes are kept for an additional 30 days after that, so I can't disable a mailbox through Exchange, as it wouldn't fit with my retention needs.  We also just finished our migration from Exchange 2003 to 2010 a couple of weeks ago. 

    Thanks in advance!  :)

    Friday, February 25, 2011 8:50 PM

All replies

  • By design, need to bounce IIS on the CAS refer to articles below.

    Changing the Default Interval for User Tokens in IIS
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;152526

    XWEB: Mailbox Access via OWA Depends on IIS Token Cache
    http://support.microsoft.com/kb/173658



    James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com
    Friday, February 25, 2011 9:15 PM
  • Okay, that makes sense to a point, especially with the tokens...but this account had been disabled for over an hour.  The links you shared with me (thank you, BTW) say that the default amount of time that IIS caches the tokens is  only 15 minutes. 

    Is there something else here too? 

    Friday, February 25, 2011 9:23 PM
  • That's a common theme among users using IIS7. I'd like to know what MS is recommending as well.

    Practical case: FTP 7.0 credentials caching

    IIS 7.0 uses a credential caching system to avoid continuous creation of security tokens for performance reasons. This system is not always precise in the flushing of user tokens, when using only the Windows Registry value UserTokenTTL (as described in http://support.microsoft.com/default.aspx/kb/152526). When configured to a value of X seconds, the flushing (and logoff of the user session) can have a delay of up to 5 minutes. This is not acceptable, because after changing the permissions for a user (moving from one security group with specific permissions to another, more restricted group), this user still can log on with the old permissions until its credentials have been flushed and its user session logged off.

    The more accurate mechanism to flush credentials in IIS 7.0 and prevent this possible security hole is using the configuration elements present in the configuration store. Once identified the mechanism we have three options, on demand flush using a script, lowering the flush interval to a “safe” value and/or disabling completely the credentials cache.

     

    http://blogs.msdn.com/b/alvar/archive/2009/04/14/unleash-the-power-of-the-iis-7-0-configuration-store-ftp-7-0-credentials-caching.aspx


    James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com
    Friday, February 25, 2011 9:39 PM
  • Hmmm...interesting.  Annoying, but interesting.  Nice find, James; thank you. 

    Any idea what file one would try to edit for OWA?  The author of that article used the FTP schema as an example.  I looked at the web.config, but didn't find anything real helpful there to even consider editing. 

    I may just drop it to 5 minutes via the reghack, but I was really hoping to avoid that.  It would be nice if someone from Microsoft could give some additional insight (bug, oversight, can be changed, scheduled for fixing in the next rollup, etc). 

    If I do the reghack, will that cause users sessions to be logged off prematurely?  I'd like to think that when the token's cache is over, it would check to see if it was still in use or not, but hey, weirder things have happened.  ;) 

    Thanks again. 

    Friday, February 25, 2011 10:49 PM
  • I'm wondering the exact thing...if there's anyway IIS configuration store in the context of Exchange to change the flush interval rather than then using the registry. You're not the only one on the forums experiencing the delay in flushing the cache taking more than 15 minutes.


    James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com
    Saturday, February 26, 2011 1:19 AM
  • It's good to know I'm not alone...now if we could get some further clarification on the issue from Microsoft, I'd be happy.

    Thanks again, James!

    Saturday, February 26, 2011 6:42 PM
  • If the latency is longer than 15 min I would make sure everything is replicating fine through your AD with repadmin, dcdiag etc. especially if your PDC emulator server role is not in the same CAS' AD site
    Saturday, February 26, 2011 8:33 PM
  • If you chose to disable the mailbox, it can always be reconnected later. That would be the sure way to ensure all clients could not access the mailbox (Outlook, OWW, ActiveSync, BES etc...)

     

     

    Saturday, February 26, 2011 10:16 PM
  • If the latency is longer than 15 min I would make sure everything is replicating fine through your AD with repadmin, dcdiag etc. especially if your PDC emulator server role is not in the same CAS' AD site

    I haven't monitored the replication thus far, but I'd like to think it's not a big deal, as I only have one sight in AD (with two DCs).  Since I only have one sight, that is indeed where my Exchange servers live.  It does make sense to a point though, as it wasn't until I did a GPUPDATE on the DC and the CAS that his account was truly disabled, so I will give it a look-over. 

    As a note, I have the CAS and Hub installed on one server and the Mailbox installed on another. 

    If you chose to disable the mailbox, it can always be reconnected later. That would be the sure way to ensure all clients could not access the mailbox (Outlook, OWW, ActiveSync, BES etc...)

    That's not an option; I must keep accounts for at least 60 days (mailboxes for 90).  Deleting then reconnecting the account would just make additional work.  Plus I actually tried that (albeit inadvertently) when I found out about all of this; I "Disabled" the account through Exchange which marked it for deletion.  I reconnected it to the original account within a couple of minutes and I was still able to login with his old password. 
    Bizarre. 

    Monday, February 28, 2011 2:40 PM
  • If the latency is longer than 15 min I would make sure everything is replicating fine through your AD with repadmin, dcdiag etc. especially if your PDC emulator server role is not in the same CAS' AD site


    I must admit, I am not well-versed on the art of "Troubleshooting" domain controllers. 
    I went ahead and ran "repadmin.exe /latency <dc> /verbose" and "dcdiag /s:<dc> /test:replications" and both seemed to come back properly; no issues or failures that were readily noticed. 

    Is there anything else I should test?  Any additional tips/insight you can share as to what I should be looking for? 

    Thanks again! 

    Tuesday, March 01, 2011 3:56 PM
  • Alright, I was doing some testing (disabled a test account) and used replmon to view what was going on while I was doing this...

    It appears to be exlusive to the Exchange CAS; AD replication looks okay and when I tried to access other network resources (accessing file shares, visiting SharePoint, logging in to PCs, etc) I was denied, except for when it was related to Exchange.  Outlook and OWA, anyway; I wasn't able to test OMA. 

    IISReset does the trick...with OWA, anyway.  It looks like with Outlook they are still able to access their mailbox for as long as they are logged in to that Windows session.  As soon as you logout of Windows, you're done. 

    In my mind these are two large security issues.  I would hope that someone from Microsoft would be so kind as to comment on this thread and provide some insight.  I would be quite grateful for it! 

    • Edited by Paul Newell Tuesday, March 01, 2011 9:57 PM clarification
    Tuesday, March 01, 2011 9:14 PM
  • Hi,

    We also have the same issue with our Exchange server 2010 environment where the locked AD account users are able to login to OWA 2010.

    Can anyone help us in this regard.

     

    Monday, May 09, 2011 10:00 AM
  • In addition, if you do not want to disable the mailbox, just disable owa access for that mailbox
    Monday, May 09, 2011 10:39 AM
  • Our case is little strange where we do not want to disable the users mailbix. We have an AD account lockout policy,where the user account would be locked out after three invalid attempts. That policy is working where if any user types password wrongly, his account is getting locked. But the locked out user is able to login to OWA. We even waited for more than a hour but with vain.

    Any ideas?

    Monday, May 09, 2011 10:46 AM
  • Our case is little strange where we do not want to disable the users mailbix. We have an AD account lockout policy,where the user account would be locked out after three invalid attempts. That policy is working where if any user types password wrongly, his account is getting locked. But the locked out user is able to login to OWA. We even waited for more than a hour but with vain.

    Any ideas?


    Anytime I've had to disable an account and/or change a password I've been running IISRESET after altering the account.  It's definitely not optimal, but it does seem to work. 

    I haven't been able to try to alter the default IIS user token interval yet (finished my company's "Busy season" last month and had a host of other items to deal with first, as the IISRESET was working okay), but I will in the near-future and will post my findings. 

    Monday, May 09, 2011 1:09 PM
  • Alright, so I made the change that is outlined in the following two KBs:
    http://support.microsoft.com/kb/173658 
    http://support.microsoft.com/kb/152526/en-us 

    I created the DWORD and set it to 600 seconds (ten minutes).  It appears to hold to that time as long the user doesn't still have an established session.  For example, I log in to OWA, allow the mailbox view to load, then log out.  I then changed the password through AD Users and Computers.  If I close the window that had OWA open my token will expire in ten minutes; however, if I keep the window open (albeit logged out) it takes 15 minutes before the old password is unusable to login (as long as I don't login with the old password during that 15 minutes).  If I do login with the old password within 15 minutes of having it changed, the token seems to stay active for at least a half-hour, as I was logging in every five-ten minutes after changing the password with the old one, and it wasn't until 35 minutes after I changed the password that the old password ceased to allow logins. 

    To further complicate this, users with mobile devices may have their tokens last much longer than ten minutes.  iPhones seem to be particularly bad about this for some reason; I can change my password on my workstation but still be able to send/receive mail on my iPhone for a few hours before it finally says "Your password isn't correct; please update it" (paraphrase, of course). 

    I'm thinking that the IISRESET is a necessary evil for the time being.  So much for "Simpler Administration"...

    I still feel this is a pretty big deal and am hoping someone from Microsoft may be able to shed some light for us. 

    Wednesday, May 11, 2011 5:39 PM
  • Fantastic... 

    I had a user resign on Friday.  I reset her password and ran an IISREST on my CAS/Hub server.  This screwed up the w3wp.exe processes.  No one could access OWA over the weekend. 
    I tried to run a restart through the IIS Manager, but the program hung; I couldn't do anything with it. 

    I tried to run another IISRESET but that didn't help; the IISAdmin service stopped but didn't restart because the w3pw service was hung on "Stopping".  I couldn't kill them with Task Manager or taskkill.exe; I had to reboot the server. 

    Could someone from Microsoft please comment on this?  Having to run IISRESET everytime an employee leaves isn't optimal, especially if it can be potentially problematic. 

    Monday, May 23, 2011 3:58 PM
  • I just recently found this exact same behavior in my Exchange 2010 system. Unfortunatly, it was after an employee was terminated and he was sending nasty emails to my boss from his iPAD on his disabled user account. I was dumbfounded and terrified because I couldnt figure out how to stop him from doing it. Thank you Microsoft. I have multiple redundant CAS servers in NLB and the only way I can effect the revocation, within a few hours, of Exchange access via changing the user password or disabling the account is to reset IIS on all my CAS servers? Not to mention the impact to the other users of said Exchange services while I reset IIS.

     

    I dont understand why this isnt a high priority security hotfix for Exchange. Microsoft, you guys needs to do something about this. Employees are let go every day across the world and most arnt happy about it.


    -Jason
    Friday, July 15, 2011 3:59 PM
  • That's my concern specifically, Jason.  If someone was dismissed, and can then turn around and send a nasty e-mail to the CEO I'd be finding myself in the unemployment line with the person sending the nasty e-mails.  This is both a security issue, and for me, an issue of job security, lol! 

    I am lucky in that I only have one CAS to manage (and it looks like my delay is only upwards of 35-45 minutes), but the IISRESET looks like it isn't an optimal solution, not even factoring in that anyone who may be connected in some sort of remote capacity may be knocked-off. 

    Friday, July 15, 2011 4:24 PM
  • I've just run into the same problem, I disabled a user a few days ago but her manager said she's still sending emails. I changed the password on the account and tested it myself and sure enough I can still log into OWA on our Exchange 2010 server and send emails even though the account is still disabled in AD. Is Microsoft even working on a fix for this problem? Has anyone found a fix for it yet? Thanks.
    Monday, July 18, 2011 5:42 PM
  • Here it is September 15th, 2011 and I found this thread looking for the same answers to same questions and concerns raised here.  Has Microsoft responded?  What I find interesting is that Microsoft is endorsing the use of OWA from a legal and compliance perspective in that we can prevent the use of PST’s and satisfying the controlled legal discoverability issue.  In my opinion, upset terminated employees still sending and receiving emails is more of a legal liability and compliance problem.  Go figure.

    Thursday, September 15, 2011 5:23 PM
  • If you clear the mailnickname attribute for an account, they wont be able to logon via OWA. Maybe not the cleanest solution, but it works.

     

    Friday, September 16, 2011 3:23 PM
  • This is not acceptable. Removing a device from ActiveSync (as is our policy when someone is terminated) should remove the AS account. Emails, Contacts, Calendar,s Reminders, etc should be removed from that device. Instead the user has access to all of the emails on the device for some unknown period of time, as well as contacts, etc.

    I shouldn't have to reset IIS or remove account nicknames either. Disabled is disabled. If you don't mean it - rename it.

    Why is this not a priority to be fixed?

    Why are we, as users, forced to find workarounds ?

     

    Friday, September 16, 2011 4:54 PM
  • Go to Exchange management console and remove "NT Authority\SELF" from "Management Full Access Permission...", that will disable OWA access right away.
    Tuesday, October 18, 2011 7:22 PM
  • @chengwenming - Won't disabling activesynch in the "Mailbox Features" tab do the same thing?
    Friday, October 28, 2011 5:27 PM
  • check the history of this topic and you will know disabling activesync doesn't stop user from sending/receiving email on the phone.

    Thursday, November 03, 2011 4:23 PM
  • Though removing the NT Authority\SELF does not terminate an existing session, so if the user is already logged in, he/she can continue to access.

    Thanks,

    Karl

    Thursday, November 03, 2011 9:12 PM
  • Not true. Tested with OWA, remove NT Authority\SELF won't terminate existing session but it gives "Outlook Web Access could not connect to Microsoft Exchange. If the problem continues, contact technical support for your organization" message. Can't really display any message in fact.

    Regards,

    Cheng

     

    Monday, November 14, 2011 4:41 PM
  • I recently noticed this while testing the feasibility of a Bring Your Own Device
    policy. We want to be able to disabled sending and receiving from an Active
    Sync device before we decide to wipe the device clean. The idea was this would
    give a terminated employee time to make any personal phone calls before handing
    their personal device over to IT so we can remove the ActiveSync account. If
    they refused to hand it over we would wipe the device instead.

    I tired the various methods mentioned above and the best one I came across in the
    forums was setting the Allowed Recipients to 0

    Set-Mailbox -Identity "John Smith" -RecipientLimits 0

    Obviously this allows the user to still access OWA and ActiveSync but it stops them from
    sending any nasty emails after the fact through a corporate account. The only
    remaining concern would be that they still would have access to their corporate
    account and the GAL.

    I also tried setting the Storage Quota to 0 for sending messages but that didn’t seem
    to apply in a timely fashion (15 mins). Setting the recipient account was
    almost instantaneous and works during an OWA session

    I then tried to see if I could force a ISS Token refresh by changing the password
    of a disabled account and then logging in with the new password. While that
    worked, the old password worked as well. So both the old and new password
    worked in OWA for a disabled account.

    Another thing that seemed to work within a few minutes was disabling the OWA and AS

    Set-CASMailbox-Identity "John Smith" -OWAEnabled:$False
    Set-CASMailbox-Identity "John Smith" -ActiveSyncEnabled:$False

    Monday, February 20, 2012 8:24 PM
  • Nice find, Vox Medica.  That may just be what I'll have to when de-provisioning accounts in the future; set the attributes for the Exchange account then disabling the AD user. 

    Interestingly enough, I left the employer I had submitted this thread for, but am now working on upgrading the Exchange infrastructure from 2003 to 2010 at my new employer. 

    • Edited by Paul Newell Wednesday, August 01, 2012 9:25 PM fixed typos
    • Proposed as answer by MrBeach Thursday, September 13, 2012 5:38 PM
    • Unproposed as answer by MrBeach Thursday, September 13, 2012 5:38 PM
    Monday, February 20, 2012 8:42 PM
  • Next time just disable active sync within that persons mailbox properties instead of restarting all those services ( this is if you want to maintain his user account otherwise delete his account and that will stop it too :). This issue probably has to do with the authentication tickets more than bugs. I would look more in that direction.
    Wednesday, August 01, 2012 4:22 PM
  • Vox Medica suggested that previously, along with disabling OWA, as that is an issue, too.  I haven't gotten a chance to try it though as I am still in the midst of upgrading my new(er) employer's Exchange infrastructure. 
    Even still, I would have liked to think changing their password and/or disabling the account would work just as well.  Oh well, that's what I get for thinking.  ;)
    Wednesday, August 01, 2012 9:24 PM
  • Wow, good to know.

    I only found this through a search to see if this similar issue in windows 2003 was fix in windows 2008.

    http://support.microsoft.com/?id=906305


    jon

    Tuesday, October 16, 2012 7:34 AM