Changes in how customers connect to Security and Compliance Center PowerShell via basic authentication cause some confusion

A post over at Experts Exchange alerted me to a possible issue with Remote PowerShell connectivity to the Security and Compliance Center endpoint, when using basic authentication. A quick test on my end seemed to confirm the behavior, but only at first glance. A more thorough investigation revealed some changes in how Microsoft is handling such requests, and some implications that might affect tenants near you.

First things first, Microsoft is not actually blocking basic auth for the SCC endpoint. Not yet. Although they have clearly and repeatedly stated their intentions of blocking basic authentication across the board, this is not yet in effect. Which of course doesn’t mean you should wait for the last possible moment to switch to using Modern authentication. While Microsoft has not yet provided support for certificate-based authentication for the SCC endpoint, and thus some tenants might have an excuse to stick with basic auth, we do have the option to switch to using the Connect-IPPSSession cmdlet. Said cmdlet will use Modern authentication even when you invoke the –Credentials parameter to provide username and password, allowing for at least some automation scenarios to work. If MFA is enforced, you will have to run the cmdlet interactively though.

Back to the topic at hand. To test the behavior, I used the same set of credentials to establish a session to both Exchange Online and SCC PowerShell, on the same machine, both using basic authentication (as in creating the session directly via New-PSSession/Import-PSSession). The ExO session proceeded to connect, whereas the SCC errored out:

At the same time, connecting via the Connect-IPPSSession cmdlet worked just fine, on the same machine, but again, this one is actually using Modern authentication. So at first glance, it did look like Microsoft is now blocking the basic auth endpoint, so I proceeded to ask around, just in case I’ve missed the news on this. By the time I sent that email and people started replying, an interesting thing has happened.

Doh! So I quickly went to the Azure Identity Protection blade to check on what’s going on, and sure enough, my own account was flagged with High risk. Unfamiliar sign-in properties, Atypical travel alerts – all things you don’t want to see for a GA account. That’s what you get for using basic auth!

Few things caught my attention on the Risk Sign-in Details pane. First, this was most certainly not my IP address, so the risk detection was justified. A quick whois lookup luckily confirmed that the IP range in question belongs to Microsoft, so I could start breathing easier. The Status code/Failure reason were interesting as well, and so was the application generating the sign-in event: Exchange Filtering Service, with appID 597cf567-d52d-4c00-aca6-b2126beb3fa1.

To get even more insight, I proceeded to check the Azure AD Sign-in logs directly, performing a search for all events corresponding to said appID over the past month. There were none, and interestingly enough the results didn’t include any events corresponding to my use of the Connect-IPPSSession cmdlet earlier today. At the same time, looking at one of the returned events, it was clear that the request were issued at the time I was trying to establish the SCC connection, so nobody has hacked my account or anything like that. In fact, the request was blocked by my “block legacy auth” Conditional access policies, which is expected.

So, it looked like the mystery was being revealed. It wasn’t Microsoft that’s blocking those request, but the CA policies I have put in place. By that time other have confirmed that the SCC basic auth method works fine for them, and so did a quick test I run against one of my demo tenants, where no policies blocking basic auth were configured. Just to be on the safe side, I had also run the “basic auth diagnostics” within the Microsoft 365 Admin Center (https://aka.ms/PillarEXOBasicAuth), which also confirmed that this is not something Microsoft has blocked on the tenant level.

A “solution” to this would then be to allow Microsoft’s own IP ranges in your CA policies. The problem here is that you have no way of knowing which exact IP the request will be coming from, nor why it is routed that way to begin with. To me, this behavior does look similar to the way Exchange Online “proxied” auth requests to on-premises AD FS servers back in the day, but I have no recollection of ever seeing something similar for the SCC endpoint. A quick search on the net showed that the corresponding app has been in use at least since 2019, so this can hardly be counted as recent change. I suppose I never noticed it as I usually stick to using the modern authentication methods (Connect-IPPSession) for my SCC-related needs. And so should you.

A better way to handle this would be to exclude such sign-in attempts “server-side”, but that’s something only Microsoft can do. The application in question is one of the many “hidden” apps Microsoft uses across different services and endpoints, and you cannot target it via CA policies. Similarly, Microsoft should also exclude it from any Risk detection too, as currently any attempt to connect will likely result in few false-positives. Then again, you have a quick and easy way to be alerted upon detecting any basic auth login attempt  against the SCC endpoint, which might be a good thing 🙂