Office 365 Single Sign Out with ISA or TMG as the ADFS Proxy

Over the last year I’ve spent a decent chunk of my time shaping and delivering Identity and Access Management workshops for Office 365 projects at Content and Code. This is generally underpinned by Active Directory Federation Services v2.0 (ADFS). In fact I don’t think we’ve done a single Office 365 project without it. Along the way I’ve become acquainted with many of the nuances of the sign on and sign out experiences as they differ across Office 365 services, client applications and different (valid) network perimeter technologies. In this post I will mainly focus on the security implications of publishing ADFS through ISA or TMG Reverse Proxies in the place of ADFS Proxy servers. In the majority of our engagements we’ve considered this option (potentially allowing our clients to consolidate infrastructure) since ISA, TMG or similar Reverse Proxies are commonly deployed. Yet we need to evaluate with full awareness of how ADFS operates without a Claims-aware Reverse Proxy such as the ADFS Proxy. This gets pretty technical, so I’m assuming some high-level familiarity with ADFS, Reverse Proxies and Office 365.


Office 365 Identity Service Description

First, let’s have a look at what the Office 365 Service Description for Identity has to say about the Sign In experience. Note: this is current as of May 2012, but is entirely subject to change. These descriptions are regularly updated.

The sign-in experience changes depending on the type of Office 365 identity in use: Cloud Identity or Federated Identity. Table 1 details the changes for different combinations of applications and operating systems.

Table 1: Sign-in experience with Office 365

Cloud Identity Federated Identity
Microsoft Outlook® 2010 on Windows® 7 Sign in each session1 Sign in each session2
Outlook 2007 on Windows 7 Sign in each session1 Sign in each session3
Outlook 2010 or Outlook 2007 on
Windows Vista® or Windows XP
Sign in each session1 Sign in each session1
Exchange ActiveSync® Sign in each session1 Sign in each session1
POP, IMAP, Microsoft Outlook for Mac 2011 Sign in each session1 Sign in each session1
Web Experiences: Office 365 Portal / Outlook Web App / SharePoint Online / Office Web Apps Sign in each browser session Sign in each session4
Office 2010 or Office 2007 using SharePoint Online Sign in each SharePoint Online session5 Sign in each SharePoint Online Session
Lync Online Sign in each session1 No prompt
Outlook for Mac 2011 Sign in each session1 Sign in each session1
1 When first prompted, you can save your password for future use. You will not receive another prompt until you change the password.
2 You enter your corporate credentials. You can save your password and will not be prompted again until your password changes.
3 Outlook 2007 will be updated after Office 365 has been made generally available to have the same experience as Outlook 2010 on Windows 7.
4 All apps require you to enter your username or click to sign in. You are not prompted for your password if your computer is joined to the domain.
5 If you click on “Keep me signed in” you will not be prompted again until you sign out.

The key thing about this table is that it describes the user experience and the number of password prompts a user might see. For the Windows scenarios, these experiential differences are generally accounted for with the Keep Me Signed In tick box at the Microsoft Federation Gateway ( and the Windows Credential Manager. This is all reasonably straight-forward once you get your head around the differences above, but for federated users, this all changes if your organisation’s Reverse Proxy isn’t Claims-aware.

Update (26-7-2013): I’m not sure at what point something changed, or if the “Keep Me Signed In” tick box ever worked with the Windows Credential Manager (as I originally detailed above), but this is now implemented with cookies. It’s beyond the scope the scope of this post to get in to those details, but for now assume that what’s written below assumes this box has not been ticked.

Claims-Unaware Reverse Proxies

Typically we would consider the use of Claims-unaware Reverse Proxies to publish ADFS externally when we want to take advantage of existing infrastructure investments and/or when an organisation wants a significant period of Exchange co-existence. We’ve been dealing with a number of clients who are using ISA Server 2006 or Forefront TMG already (for instance, to publish Outlook Web Access or SharePoint), so we can potentially do away with the ADFS Proxies and eliminate two servers for our clients with this topology. We’ve also had a client with a very limited pool of remaining public IP addresses, which is another good reason this topology might be compelling.

While this may seem like quite a niche consideration, in most of our Office 365 engagements to-date it’s been valuable to step through this detail. Reducing on-premises infrastructure tends to be one of the key propositions that drive IT-lead cloud migrations. With new ADFS deployments we’re typically adding four on-premises servers (with the ADFS Proxies included), so we should really consider this opportunity to consolidate with existing infrastructure when it’s viable.

In principle this topology works fine, although there is an important nuance that comes in to play with one of the cookies that ADFS issues. MSISSignOut tracks all of the tokens that have been issued by ADFS (in this session) so a sign out request can invalidate all Relying Party sessions that ADFS has authenticated, rather than just signing out of the application where the request was initiated. This is what’s known as Single Sign Out or Single Logout. However, ISA/TMG haven’t been designed with SAML Claims in mind, so they can’t respond appropriately when the sign out process is initiated. It’s this variance in the Sign Out experience that warrants a closer look below.

Three further comments before moving on:

  1. For clarity, we typically avoid the No Authentication ISA/TMG configuration, instead following the Access Onion’s TMG Pre-Authentication model (a fantastic blog, by the way, and one which this post in particular is indebted to).
  2. Keep in mind that I’m only talking about browser-based access here since the session for the Outlook and Lync client is so tightly bound to the Windows session. Additionally, the full Outlook client or Lync’s use of the Microsoft Online Services Sign-On Assistant both rely on different types of federation to the passive federation we see here. All told, the risk profile, UX and underlying technologies are all different enough that they would warrant a separate discussion, but there really isn’t much to discuss when it comes to Sign Out from the full clients (as will hopefully become clear in due course).
  3. This is all a description of what happens when a user presses the “Sign Out” button. If instead, a user closes the browser that also destroys the session, achieving sign out of everything that was just closed. Obviously the same isn’t true if some browser sessions are left open.

With all this said, let’s dive in.

Outlook Web App Sign Out Experience

For starters, I’ve sketched a high-level overview of this process, with more detail/explanation in text below.

Outlook Web App Sign Out Process

Hopefully you can read my writing!

Inside the Network

First, let’s review what the sign out experience looks like for users inside the network. This is our baseline experience, cited here to show how the process is intended to work:

  1. A user presses “Sign Out” in the Outlook Web App.
  2. The user is signed out of the Outlook Web App.
  3. The user is redirected to an ADFS Sign Out page. This occurs without traversing the Reverse Proxy since passive federation works with 302 redirects and internal name resolution should be configured to point at the ADFS servers directly since we should be in an environment with split DNS.
    1. At the ADFS Sign Out page the user will be signed out of ADFS, then redirected to the Microsoft Federation Gateway (MFG). The user’s tokens for all Office 365 web applications have been invalidated.

Outside the Network, Through ADFS Proxies

If a user is outside the network and we’re using ADFS Proxies, the user’s sign out experience appears to be the same since the ADFS Proxies handle the MSISSignOut cookie appropriately (by default). This allows the request to pass through the proxy without authentication, completing the sign out process at ADFS, redirecting to the MFG when complete, as above.

Outside the Network, Through an Active Claims-Unaware Reverse Proxy Session

Next, let’s review what the sign out experience looks like for a user outside the network if we use a Claims-unaware Reverse Proxy and the Reverse Proxy session hasn’t timed out when the user signs out of the Outlook Web App:

  • The off-premises user will be signed out of ADFS, then redirected to the MFG in the same way it works for on-premises users above. In this case the user is successfully signed out of all Office 365 applications but this user has an active session at the Reverse Proxy. Within the lifetime of the Reverse Proxy’s session a user can re-authenticate to ADFS without getting prompted for credentials, since the proxy passes the already-collected credentials on to ADFS for the duration of the session. This doesn’t really have anything to do with ADFS or Office 365 per se. This is how the session at the Reverse Proxy has been configured. This is a strong reason to restrict the Reverse Proxy session lifetime for this listener. I typically recommend a one minute lifetime for these sessions, which is the minimum value. If we provisionally assume that this is a sensible recommendation then we’re typically going to see one of the scenarios below in reality because the Reverse Proxy session should expire before sign out is initiated from the Outlook Web App.

Outside the Network, Through an Expired Claims-Unaware Reverse Proxy Session

Now let’s review what the sign out experience looks like for a user outside the network if we use a Claims-unaware Reverse Proxy and the Reverse Proxy session has timed out when the user signs out of the Outlook Web App:

  • The sign out process will successfully log the user out of the Outlook Web App and the user will be redirected to ADFS, but the user will be prompted for authentication at the Reverse Proxy before arriving at ADFS since the previous Reverse Proxy session has timed out. Keep in mind that in this case the user is being prompted for authentication so they can sign out, which is fairly unintuitive. I’ve dubbed this scenario, “Sign-In-to-Sign-Out”. One of two things will happen here:
    • If the user re-authenticates at the Reverse Proxy they will be signed out of ADFS and the user will be redirected to the MFG, completing the Single Sign Out process. In this case the user is successfully signed out of all Office 365 applications. However, they will have a new active session at the Reverse Proxy since the user just signed in again. It will be valid for the normal lifetime of a session even though the user thinks they just signed out. Keep in mind, this new session lifetime is probably just one minute if we’ve chosen to configure the Reverse Proxy as I suggest above.
      • Note: I think it’s unlikely that many users would step through this entire Sign-In-to-Sign-Out process with any regularity. But if they do, we need to understand that they may be walking away from their machine assuming they have done the best thing they can do as a security-conscious worker, yet they will have just renewed their session at the Reverse Proxy. In this scenario Single Sign Out succeeds but only because the user just signed in to the Reverse Proxy again. Hopefully this reinforces the benefits of having a one minute Reverse Proxy session lifetime.
    • Alternately, if the user does nothing when the Reverse Proxy prompts for authentication, they are still successfully signed out of the Outlook Web App. The catch is that any other active sessions in the browser with other Office 365 applications will remain active. These other sessions will still be available if a user presses “back” enough times to reach them or navigates through history to access them. In this scenario Sign Out succeeds but Single Sign Out fails. Put another way, Single Sign Out has been disrupted because our Reverse Proxy isn’t Claims-aware.

Outlook Web App Risk Assessment

In both of these cases the experience is kind of undesirable, but the magnitude of the risks will depend on how Office 365 is being used. If the Reverse Proxy session lifetime is reduced to one minute, most of these risks are minimised a great deal. The one lingering issue is the lack of a completed Single Sign Out if the user doesn’t Sign-In-to-Sign-Out, but this is simply not an issue for organisations that only use one Office 365 web application. Organisations that use more than one Office 365 web application may decide that the lack of reliable Single Sign Out is acceptable since most organisations will have been living without it up until now. Alternately, they may want to consider using ADFS Proxies or another Reverse Proxy. As I’ve indicated above, the only real drawbacks to using ADFS Proxies are the added infrastructure and the extra holes in the perimeter, but this is precisely the trade-off that needs to be sized up, between this security context and the opportunity to consolidate infrastructure. There are also other factors that I’ll throw in to the mix towards the bottom of this post.

Now let’s look at how this varies (marginally, but importantly) with the other Office 365 services.

Sign Out from Other Office 365 Web Applications

SharePoint Online Sign Out Experience

There are some further nuances with how SharePoint Online handles sign out slightly differently to the Outlook Web App:

  • SharePoint Online prompts to close the browser after sign out is complete. This helps drive good practice (especially in this context) since closing the browser closes all open sessions.
    • This prompt only pops up after a user Signs-In-to-Sign-Out (if there’s a Claims-unaware Reverse Proxy in the mix).
      • If the user doesn’t complete the sign out process they will be signed out of SharePoint Online but Single Sign Out does not complete.
    • If a user choses “Sign in as different user” in SharePoint Online it effectively triggers a Sign Out (see above), but note that:
      • If the user is outside the network and…
        • if the session at the Claims-unaware Reverse Proxy has not yet timed out, then the user will be signed in as the same user again via proxy.
        • if the session at the Claims-unaware Reverse Proxy has timed out, then the user can re-authenticate as a different user.
      • If the user is inside the network, they will be signed on automatically via Integrated Windows Authentication, assuming they are using IE and the site is trusted – otherwise they will be prompted for credentials at the ADFS server and then they can sign in as whoever they like.
        • Because we would almost always recommend adding the ADFS site to Trusted Sites or Local Intranet Sites for automatic sign on, we would see this option most frequently in another browser. Note: this behaviour can be useful for testing.
  • If SharePoint Online lists are taken offline in the full Outlook client or in SharePoint Workspace, the user will be prompted to sign in with a Microsoft Federation Gateway logon web page in order to sign on to ADFS. This follows the passive federation pattern of web applications rather than Outlook’s active federation. This is worth mentioning briefly, since it’s a common way to interact with SharePoint data, but the sign out considerations are in line with the full Outlook client rather than the browser-initiated sign on process, since sign out would typically occur when a user closes Outlook or logs out of the Windows session.

Lync Online Web Scheduler Sign Out Experience

The Lync Online Web Scheduler is a little-known web application that enables users to create meetings from diverse devices:

Microsoft Lync Online Web Scheduler is a web-based meeting scheduling and management tool for users who don’t have access to Microsoft Outlook, or are on an operating system not based on Windows. With Lync Online Web Scheduler, you can create new meetings, modify your existing meetings, and send invitations using your favorite email program.

Although I haven’t tested as rigorously as with the web applications above, I believe the Lync Online Web Scheduler sign out experience is the same as for the Outlook Web App.

Office 365 Portal Sign Out Experience

The Office 365 Portal will probably be used primarily by administrators but this may vary by organisation. Normal users may update their profile data, download Office clients or they may use the site for shortcuts to the Office 365 web applications.

What’s unusual about the portal is that the “Sign Out” button only works if the user Signs-In-to-Sign-Out at the Claims-unaware Reverse Proxy (completing Single Sign Out). If the user does not re-authenticate at the Claims-unaware Reverse Proxy they will be able to press “back” and the user will be able to take action in the Office 365 portal. Unlike the web applications above, Sign Out fails unless Single Sign Out succeeds. It’s worth mentioning again, that this is a non-issue with ADFS Proxies, as they are Claims-aware.

So… that’s the behaviour. Now let’s have a look under the hood.

One Minute Reverse Proxy Session Lifetime

I suspect my suggestion to reduce the Reverse Proxy session lifetime to one minute may raise a few eyebrows. What might not be clear is that this doesn’t dictate the web application session lifetime with the Outlook Web App, etc. because there are four tiers where cookies get issued when federating with Office 365:

  1. ADFS
  2. The Reverse Proxy
  3. The Microsoft Federation Gateway (MFG)
  4. The Office 365 web application that a user requests

So far we’ve been talking about the second of these tiers, which has a token lifetime that we can reduce to one minute since we don’t need to go back to ADFS for a while after we first authenticate (within a browser session). That should be straight-forward enough, but it raises the question of how long an Office 365 web application session remains valid. It goes something like this:

  1. ADFS has a default value for the WebSSO Timeout. This value is 480 minutes unless it’s set to something else. All Relying Party Trusts created in ADFS will respect this value unless they are specified otherwise when the trust is created (or later updated).
    1. For Office 365 we create a trust between ADFS and the MFG. The Office 365 services don’t care about ADFS. They trust the MFG, which in turn trusts ADFS. The lifetime of the trust between ADFS and the MFG does not directly determine the Office 365 web application session lifetime in this configuration.
  2. The Claims-unaware Reverse Proxy token lifetime can be set to a low value, since that lifetime doesn’t influence the length of an Office 365 user’s session. This token lifetime matters when:
    1. An Office 365 user’s session has expired with the requested web application (see point 4 below) and they need to re-authenticate with ADFS, or…
    2. Sign Out is initiated, as described above.
  3. The MFG accepts the authentication token from ADFS and acts as a Federation Hub for the Office 365 services. The MFG issues the client a token that the client can use to authenticate to the Office 365 web applications.
  4. The actual session lifetime that will matter most to a user is the lifetime of the session with the web application, which is controlled by the requested web application itself.
    1. The session lifetime for SharePoint Online is not configurable and is set to last for eight hours. It is valid only within a browser session.
    2. The default session lifetime for the Outlook Web App is the same as for SharePoint Online, although it can be modified with the Set-OrganizationConfig PowerShell command’s ActivityBasedAuthenticationTimeoutInterval switch. Note: I’ve not tried this command myself but it was pointed out to me when I queried these lifetimes with a trusted technical resource at Microsoft.

How to Reduce Session Lifetime in Forefront TMG

If you are interested in reducing the session lifetime in TMG go to the Advanced Form Options for the listener, then the Client Security Settings should be toggled to “Treat as maximum session duration” and the “Timeout for public computers” should be set to one minute, or whatever is acceptable for your organisation, given the descriptions above.

Mitigations for Perceived Security Risks

For most of our clients what I’ve outlined here has been acceptable at face value (if complicated). However, a few clients were still worried about security – particularly when users might log on to the Outlook Web App or SharePoint Online from an internet kiosk. In this section I’ll briefly outline some considerations that help establish a fuller context for evaluating those concerns.

Rich Clients Have a Different Risk Profile

As described above, we’re only really talking about browser-based access if we’re focusing on the sign out process, because it simply isn’t common for users to sign on to a full Outlook or Lync client from another user’s machine, and even when they do, it’s not clear what risk that presents.

Closing the Browser at the End of a Session “Just Works”

Everything that I’ve discussed above is irrelevant if a user closes a browser at the end of a session. In this case their session tokens will be destroyed; they will be logged out of all Office 365 web applications and will be prompted for authentication when a new session starts. This entire post has focused on the behaviour of the “Sign Out” button, for those users who press it.

The ADFS Proxy “Just Works”

You can always use the ADFS Proxy. Everything I’m talking about here is geared towards validating an alternative topology that may reduce the on-premises infrastructure requirements of federation with Microsoft for Office 365. Once we move beyond Office 365 to consider publishing SharePoint on-premises with SAML Claims, etc. this all becomes a lot more complicated, but if we’re only interested in publishing ADFS then the ADFS Proxy is an excellent default proposition.

Single Sign Out Assumes More Than One Service Is In Use

When an organisation is only using one of the Office 365 web applications, there is no need to have Single Sign Out, since sign out still works. In short, we see these risks when users access two or more of the Office 365 web applications in a single browser session. For the purposes of this comment, I’ve not focused on the Office 365 Portal or the Lync Online Web Scheduler. They should still be considered, but the risks that they present are probably going to be seen to be less significant.

Keystroke Logging is the Real Internet Kiosk Concern

If an organisation is focusing on the internet kiosk scenario then I think they need to pay equally-close attention to the risks that keystroke logging presents. In many ways, keystroke logging is a greater threat than a disrupted Single Sign Out experience. I would caution against focusing on the Single Sign Out scenarios I describe here to the exclusion of these risks at public kiosks and access points. I will also point out that most keystroke logging risks are equally prominent with remote access to on-premises applications.

In order to provide an ADFS solution for these keystroke logging risks we would typically look to Multiple-Factor Authentication (MFA) solutions, often implemented through a Reverse Proxy logon page customisation. Some third-party products already exist for ADFS, although a deeper consideration of this approach to enhancing ADFS security is beyond the scope of this post; the Office 365 Identity Service Description presents a high-level overview.

ADFS Client Access Policy Support is this Nut’s Sledgehammer

Lastly, external access can be restricted by configuring the ADFS Rollup Package’s Client Access Policy Support. However, this may have broader impacts like restricting device access and Lync. There’s a lot to consider here and it certainly stretches beyond the scope of this post. I would recommend reading the Limiting Access to Office 365 Services Based on the Location of the Client TechNet article and the Access Onion blog’s deeper dive if this is of interest. The AD DS team also published some recent information regarding the second Rollup Package, which builds on these options.

Using this Information

With a Claims-unaware Reverse Proxy such as ISA or TMG we introduce a tier in between ADFS and the MFG which doesn’t precisely fit. To this end, we need to bend its shape to our needs (assuming it’s acceptable for it to be there). For some organisations it still won’t be the right fit, but for other organisations it may be a perfectly acceptable place to consolidate infrastructure, which after all is one of the primary reasons why organisations adopt Office 365 services. In my experience there is no single best practice recommendation. The Reverse Proxy design needs to fit specific requirements and they should stretch beyond security to include business continuity plans, power consumption, usability, cost and more. With that entire picture in mind, the specific scenarios above can be evaluated clearly.

None of this should be taken as gospel. The documentation for these technologies doesn’t speak to this scenario because it’s an interjection of a mismatched technology in the middle of the sign out flow. From my reading of the community there is some take-up of this approach, but keep in mind that we are all still gaining experience with ADFS and Office 365, so all of this should be tested thoroughly against specific requirements before moving on to production.

16 thoughts on “Office 365 Single Sign Out with ISA or TMG as the ADFS Proxy”

  1. This is has also been my preferred solution for any costumer that I consult.
    TMG actlually ties it all together quite nicely, not just for the Claims space but also for other services.
    And for once I can get universal SSO for every klient, even when roaming on the Internet (availability more important than security).

    Imagine my surprise that MS is retiring TMG…that I did not see coming. For my existing customers there is still support a long ways, but now I have to find something other that ties all these things together again. That I think will be a difficult task.

  2. No mention of UAG here which is a bit surprising. I am weighing up the same choice with a few customers using SaaS services where they already have invested heavily in resillient UAG. UAG supported ADFS 2.0 from SP1 onwards.
    UAG development is still continuing with Service Pack 3 released today. Many people are expecting UAG “2013” too.

    1. Hi Simon,

      Yeah, I work with a number of clients who use UAG, and we use it ourselves, but the point of this post is to focus on the special considerations that obtain when plonking ISA/TMG or some other claims-unaware Reverse Proxy down in the middle of the pipeline between ADFS and the MFG. UAG comes with its own issues, but these specific SSOut issues don’t apply to UAG in the same way so I haven’t spoken to it here. As it happens, most of the Office 365 clients that we’ve worked with tend to have ISA/TMG and the support story has been obscure for that scenario, so I thought I’d speak to what it actually means from a security perspective. I don’t intend to write off UAG in any way. I was just trying to stay focused on what was already a huge topic.



    1. Hi Eric,

      I saw your article a while back and I’d be interested in chatting about what options you see here. We work with a lot of client who have F5 investments, so these options are certainly worth understanding. What the best way for me to get in touch?



  3. Would any of these solutions (ISA/TMG or UAG) address the fact that ADFS does not allow the “Change password at next login” flag? We have TMG and a working ADFS but are not able to implement anything because we require all of our students to change password at first login. some students never touch a domain joined computer. I have also tried to do this with NetScaler and a aaa server but still nothing.

    1. Hi Joe,

      As it stands today I think you would need to have a separate solution, like ISA/TMG/UAG (noting that UAG can act as a reverse proxy for ADFS as well, with some limitations). Keep your eyes peeled for something new in Windows Server 2012 R2 though, as it looks like the new version of ADFS and the Web Application Proxy may have a portal for this sort of thing (not clear to me yet, and I haven’t got it working in the five minutes I looked at it so far).



  4. Thanks! Your article just explained to me why in testing my newly deployed Office 365 environment I am signing out as one user (me) and signing in as another staff member to test some permissions and getting the initial screen appear as if it’s still logged in as me, that is until i forcefully refresh the page. My ADFS (In this case ADFS 3.0 on Server 2012 R2) is reverse proxied by TMG and I’m now hedging my bets that this is causing the problem.

  5. Adding to this solely for the purpose of a good place for a discussion since the post is so comprehensive – when using Outlook Rich client and ADFS (so active profile where Outlook sends the password hash to Exchange Online and then Exchange Online authenticates against corporate ADFS on behalf of the client) – apparently there is a 24h caching period of successful authentication, translating into any subsequent requests being allowed (even if the password was changed or user disabled – at least from the same source IP)
    Microsoft support confirmed this and are saying it is not configurable – I am personally shocked at how loose this is in security terms – on the one hand all of the effort of a PDC emulator propagating locked account state immediately to all other DCs, a 300 second limit on clock sync in Kerberos – yet on the other an entire DAY being used as buffer to fail any O365 auth (cause you know, users should be let through no matter what – anything you want as auth admin will be done at the speed of light – a mere 24h later)

    Hopefully one of the smart fellas reading this will know how to disable the ‘feature’ – otherwise we’ll have to reconsider the entire O365 adoption plan due to a fundamental lack of proper/reliable authentication.

  6. Hi Petar. Sorry about the slow reply here, things have been quite hectic. What I would say about this is that since having written this article, I would suggest that trying to reverse engineer an understanding of Office 365 internals is often difficult/misleading. I have found a few of my assumptions have been wrong. One thing I can say it that I know there are disabled account/license enforcement checks in place in at least some parts of Office 365 which would have an effect on revocation but not password change, so it’s important we don’t think of them as the same thing. I have also seen misunderstandings of these topics at Microsoft support, so it’s worth testing to confirm these things. I can’t recall right now how the Active flow does/doesn’t support revocation through these mechanisms, but I would expect that between license removal or disabling an account that you would see a more immediate invalidation of that 24 hour cache. I believe that is the case, but am not in a position that i can test his right now. I would also say that it is worth adding this concern to user voice if you find that it isn’t working as you expect Sorry again this has taken me so long to respond. I hope this helps.

Leave a Reply

Your email address will not be published.