Connect to the Security and Compliance Center PowerShell via Certificate-based authentication

After a long, long wait, and few teases over the past few months, Microsoft has finally released support for establishing a Remote PowerShell session to the Security and Compliance Center via certificate-based authentication. This is enabled as part of the freshly released 2.0.6-Preview5 version of the ExchangeOnlineManagement PowerShell module, and it works pretty much in the same way as CBA connectivity to the Exchange Online endpoint. The accompanying documentation has also been updated, so I will not dig into all the details (plus, I covered CBA connectivity via the ExchangeOnlineManagement  module extensively in the past here and here.)

Without further ado, to connect to SCC PowerShell via the new CBA-based method, you need to use the Connect-IPPSSession cmdlet with the –CertificateThumbprint parameter. Of course, make sure all the prerequisites are met, as per the articles linked above (have an app registration with sufficient permissions created, add a certificate credential to it, assign admin roles, download the latest preview version of the module). For example:

Connect-IPPSSession -CertificateThumbprint "AAE56AE4E5DDF0DDA86874AF39254F49FEE623BC" -AppId "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" -Organization tenant.onmicrosoft.com

With the most permissive role assigned, a total of 372 cmdlets are exposed when connecting via CBA. This is in fact a significant increase over the 328 cmdlets exposed when connecting via other methods, and at this point it’s not clear as to why some of those cmdlets are not available when connecting in a user context. Examples include: Cancel-DlpEdmSession, Create-FilePlanFirstRunLabels, Enable-ComplianceFeature, Start-DlpSensitiveInformationScan and more. Likely some RBAC magic is happening here, but it’s hard to tell due to the limited set of RBAC cmdlets supported for the SCC endpoint.

Other than that, the cmdlets I’ve tested all seem to work as expected, and return the same output as their “user-context” counterparts. I haven’t bothered with all 300+ of course, for obvious reasons. Keep in mind that the module is marked as preview one though, so the occasional issue is to be expected.

This entry was posted in Exchange Online, Microsoft 365, Office 365, PowerShell. Bookmark the permalink.

Leave a Reply

Your email address will not be published.

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