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:

SCCPS1At 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.

SCCPS2Doh! 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.

SCCPS3To 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 🙂

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

  1. Sam says:

    Hi Vasil,
    I am trying to use ExchangeOnlineModule- 2.0.6P7 and I can able to create Connect-IPPSSession session and can able to list down all search. But When I am trying to run any new search I am getting below exception. I did all basic steps for App based authentication.

    Start-ComplianceSearch -Identity “Sam_PS_Search5”
    WriteError: Unable to execute the task. Reason: Compliance search initialization for “Sam_PS_Search5” failed with exception: Object reference not set to an instance of an object..

    Reply
    1. Vasil Michev says:

      Not sure whether this is a supported scenario, best open a support case.

      Reply
    2. Rudesome says:

      Hi Sam, am getting the same error, did you find a solution?
      When i run the same query within the EXO portal it works just fine

      Reply
      1. Samraj says:

        Hi Rudesome,
        Microsoft confirms that CBA don’t support few commandlets and this is one of the commandlet.

        Reply
  2. Kunal says:

    Hi,

    Is there a way to connect to the compliance center using Azure Functions ( azure function use the Powershell core 7.0 runtime stack)? If I am correct, connect-ippssession doesn’t support core. Is there a workaround? My objective is to get all the retention labels and their details from the compliance center. Any graph API endpoint would also help. Thanks.

    Reply
    1. Vasil Michev says:

      Not currently, but Microsoft should be releasing CBA support shortly. Keep an eye on the Message center (MC316448).

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.