For a while now I have had issues with gathering permissions that are required to run cmdlets in the Security and Compliance Center. Basically any query that is made ends up with a Watson error. However, I may have found a workaround. It is convoluted as it requires another connection to another PowerShell module in Office 365 (in my test case, Exchange Online). Here is my test methodology.
Connection to the SCC
Once we have a PowerShell session connected to the Security and Compliance Center, we can attempt to get permissions using this method:
[sourcecode language=”powershell”]
Get-ManagementRole -Cmdlet <name of cmdlet to check>
[/sourcecode]
Some sample test values (error messages received):
[sourcecode language=”powershell”]
Get-ManagementRole -Cmdlet Add-ComplianceCaseMember
[/sourcecode]
Try one more cmdlet:
[sourcecode language=”powershell”]
Get-ManagementRole -Cmdlet Remove-ComplianceSecurityFilter
[/sourcecode]
And:
What is the fix or workaround? Logging into Exchange Online PowerShell …
Once connected, we can query the permissions. One note is that this is not 100% full proof. For example, the Remove-ComplianceSecurityFilter cmdlet, when queried, shows no Role Group Members.
We should validate that the cmdlets are still of the correct module as we now have a second module in place and we want to validate that the cmdlets referenced are from the SCC PowerShell and not ExO? We would query a list of Security and Compliance Center cmdlets via the ‘Source’ of the cmdlet. What is the source? It is the module a cmdlet is a part of. For example. When we connect to Exchange Online or the Security and Compliance Center, we see a module name listed:
Exchange Online Example:
Security and Compliance Center Example:
Keep in mind that this name will change every time you connect to any workload in Office 365 via PowerShell. In order to validate we have the right cmdlet, let’s get a list of all SCC cmdlets:
[sourcecode language=”powershell”]
$Commands = Get-command | Where {$_.Source -eq 'tmp_bo0pq1tq.yyj'}
[/sourcecode]
This will pull all those cmdlets and store them in the $Commands variable. We can then loop through that and check each cmdlet for permissions:
[sourcecode language=”powershell”]
Foreach ($Command in $Commands) {
$Name = $Command.Name
Write-Host $Name -ForegroundColor Magenta
Get-Manag,br.ementRole -Cmdlet $Name;Write-Host ''
}
[/sourcecode]
Now we get output like this:
Notice that this is still not ideal. We are not getting permissions for all cmdlets. You should be able to verify this in your tenant. I have been able to reproduce this in two different production tenants. Now, if we want a good reference test, we can look to perform the same actions for Exchange cmdlets.
[sourcecode language=”powershell”]
$Module = 'tmp_5irlwytv.yab'
$Commands = Get-command | Where {$_.Source -eq $Module}
Foreach ($Command in $Commands) {
$Name = $Command.Name
Write-Host $Name -ForegroundColor Magenta
Get-ManagementRole -Cmdlet $Name;Write-Host ''
}
[/sourcecode]
What do we see? [HINT: Better results!]:
So what does this mean? PowerShell RBAC must be having issues in the SCC. If you can, test this in your tenant and post your results here. Would like some more live data on this.
