This blog post is an attempt to capture and share a variety of information that is not well-documented by Microsoft, spanning the two topics in the subject line.
I feel these topics are pretty critical to understanding the fundamentals of modern Azure AD and Windows security, and invaluable for troubleshooting. I do not consider myself an expert on these topics, and certainly not on the protocols via which one might get a token. But I’ve run into these topics enough to recognize there is a big gap in understanding and documentation, so this is my attempt to fill that gap.
First, here’s a table I created for a presentation in April 2018 for the Microsoft Technology community of practice at the UW.
1 Revocation is a complex topic; don’t rely on this too much w/o a deeper understanding.
These are the different types of Azure AD tokens that Microsoft has described in a variety of sources, along with a brief description of what they are good for, and the restrictions associated with each. Some references for this table are:
Some key things to understand:
- Most users are now familiar with the “Keep Me Signed In” (KMSI) setting. The KMSI dialog only governs the browser cookie, in other words, when you choose no, that means the cookie is browser session bound. And when you choose yes, that cookie persists across browser sessions. I’m saying browser cookie, but as you see in the table that is synonymous with SSO token. And yes, Microsoft sprinkles use of both when talking about its tokens. So KMSI only governs the SSO token or browser cookie.
- Many of the AAD tokens have long lifetimes. You can read more about that at the first URL reference above.
- Browsers are not the only software managing your Azure AD tokens, e.g.
- if on iOS, the app you are using might manage the token, unless you’ve installed MS Authenticator, in which case, it manages AAD tokens
- if on Windows, it depends on the OS & Office version. And yes, this is one of the places where Microsoft has down a really poor job documenting or explaining. I might be able to share a few more details here, but it is complicated and I have incomplete details, so I fear that won’t be useful.
- if your AAD tokens are federated, then you’ve got upstream tokens. For example, at the UW, we federate our AAD to ADFS, which in turn is federated to Shibboleth. So there are multiple upstream tokens, and each of those tokens may be managed by something other than the browser, and may affect my AAD tokens.
- Getting rid of a cached AAD token is a problem. You need to know the specific client details & the recipe for that specific scenario. This is deeply entwined with #3.
- At the UW, in early 2018, we moved from ADFS 2 to ADFS 4. During that, we had a broad “Outlook” incident, where there were quite a few instances of corrupt cached AAD tokens that had to be manually deleted to enable users to use Outlook to connect to Exchange Online. In most cases, getting rid of those cached tokens was accomplished via the Windows credential manager.
- Apps have to actually enforce token lifetime. And many do not. So don’t necessarily trust the lifetimes to be solid.
- How token binding works is complicated. I don’t know how it works on non-Windows platforms. But this Twitter thread has some good details on the Windows platform token binding. Some key takeaways from that thread:
- The obvious: with token binding, you can’t do lateral movement–the token is only good on the computer it is on.
- You can further protect the token with Windows 10’s Key Guard, a hypervisor key isolation service
- Edge, IE, and the HTTP stack on Windows 10 all support token binding
- There are downsides to token binding: No 0-RTT, you can’t share tokens :), and proxies might break/strip your access.
- In the near-future, you can add FIDO as an additional layer of protection, which gives you a portable hardware token you can bind your AAD token to, in addition to the client computer binding.
- AAD token revocation is complicated.
- The ability to revoke is limited to specific AAD roles and you must use one of two PowerShell cmdlets to do it.
- Disabling the AAD user is usually a good idea in combination with revocation. If you don’t want the user to remain disabled, then have some process where the user must call into your service desk to get out of that state. You’ll need to design your approach based on the common use cases behind why you need to revoke.
- Revocation will be ineffective in some scenarios–in particular when a PRT is in play–and a PRT can only be in play if you have Azure AD domain joined devices. To make a PRT unusable, you have to disable or delete the AAD device. No amount of revocations will affect it. Of course, you could just disable the AAD account and then that PRT can’t be used to get new tokens.
- Conditional access is another way to prevent an issued token from being useful. It might be used in situations where you want to block access to some/most apps, but still need to allow access to a few.