Call me old-fashioned, but I prefer to use my desktop PC whenever possible, to the point that even when I’m travelling I usually open up a remote session to it. Thus, I rarely have to login to any site on my laptop, and believe it or not, I don’t have my Office 365 password stored in Chrome 🙂
Every now and then though, I am forced to use the laptop as more than just a remote session client, and often times when I do that I run into some new or strange experiences. One such example is the “reduced” UI I was presented with when I logged in to check some of the settings in the Security in Compliance Center in Office 365. So why did this happen and how did it look like?
I was happily browsing the Microsoft Tech Community and answering questions, when a post provoked me to check the DLP settings in the SCC. Since my laptop is joined to Azure AD, logging in to any Office 365 resource, including the SCC, is as simple as clicking the account entry in the “Pick an account” dialog. At that point the Windows Account Manager takes over and completes the process, without me having to provide any password. Moreover, this type of login is actually considered multi-factor authentication, so even if you have conditional access policies configured to force MFA for unknown locations (which you really should!), it will bypass them. But more on that later.
As expected, the login attempt was successful, but to my surprise, when I navigated to the Data Loss Prevention section of the SCC, the Policy tab was missing. Then I started noticing other missing things – the Permissions tab was gone, and so was the Classifications tab. The other tabs were all present, but similarly to the DLP one, few had missing options. In other words I was presented with a “reduced” version of the SCC UI, as depicted below:
My initial though was that I messed up my permissions (not uncommon, considering I regularly use this account for testing), but a quick check on my desktop showed that all the SCC functionalities were available and working as expected. So the issue was not with the account itself.
I wasn’t going to give up that easily, so the next thing I did was to “proof up”, or in other words ensure that the authentication token I got contains the claim that signals different apps and services that I have logged in by performing a multi-factor authentication. Why? Because there are some functionalities that will only work when you are logged in by performing an MFA. Those of you that are familiar with the Attack Simulator tool might recall that its Launch attack button only gets enabled if you have performed an MFA. Using the recently announced Privileged Access Management functionality is another example.
Technically, the method I used to login in the first place, by means of the Primary Refresh Token (PRT), contains and will persist the MFA token, which is the reason why Conditional Access policies that require MFA are automatically passed. As this is a machine I rarely use and it doesn’t have Fiddler or any similar tool installed, I didn’t have any means to check whether the token indeed contains the MFA claims, however a quick check in the Azure AD logs shows that it did:
In the above excerpt from the Azure AD sign-in logs, you can see that the MFA requirement was skipped or satisfied in all cases, either due to the fact that the device is registered with Azure AD, the token contained the MFA claim or Conditional Access was skipped because the IP address was in the Trusted IPs list.
Yet, even though in some cases “MFA requirement satisfied by claim in the token” is all you need, there are situations that “real” MFA should be performed, as already mentioned above. A quick and easy way to “force” MFA is to navigate to the https://aka.ms/proofup page, which in turn is a redirect to the Additional Security Verification page in the Azure AD Access Panel. As this page contains very sensitive settings, one can only access it after passing the MFA challenge, and no form of MFA bypass works for it. In turn, passing the MFA challenge on that page supplements the auth token with the MFA claim, and now other apps can happily consume this information. Which means that a simple refresh in the SCC resulted in showing the “correct” UI.
Funnily enough, I haven’t been able to reproduce this issue since, so it might have been a temporary glitch. Or I simply have to wait for the cached MFA token to expire, as signing out is not really an option when the PRT is involved. In any case, if I do manage to reproduce this, I plan on capturing some Fiddler traces which should confirm my suspicion that some parts of the SCC are indeed enforcing a requirement for MFA. Regardless, the next time you run into a situation where some part of the SCC or any other “sensitive” or admin-level controls are missing in the UI, “proofing up” should be a quick way to solve the issue.