When it comes to permissions and PowerShell, one item that is sometimes overlooked is permissions required to run PowerShell cmdlets. Why is this important? There are times where a role assignment might be too restrictive or maybe not restrictive or not. How would we be able to tell? Exchange, Exchange Online, Security and Compliance Center, and other PowerShell modules tend to use RBAC to handle how permissions are governed. RBAC does not tell the whole story as most don’t dig deeper into the cmdlets to determine what an RBAC role actually gives the permissioned user access too.
Method 1 (Microsoft) – Preferred
https://docs.microsoft.com/en-us/powershell/exchange/exchange-server/find-exchange-cmdlet-permissions?view=exchange-ps
When you research how to find these permissions, this is the recommended method and the most popular search result. Let’s quickly run through this method:
First, we need to grab information on the PowerShell cmdlet in question:
[sourcecode language=”powershell”]
$Perms = Get-ManagementRole -Cmdlet Set-OrganizationConfig
[/sourcecode]
Next, we can cycle through each Management role to see the role as well as who has this assigned:
[sourcecode language=”powershell”]
$Perms | Foreach {Get-ManagementRoleAssignment -Role $_.Name -Delegating $false | Format-Table -Auto Role,RoleAssigneeType,RoleAssigneeName}
[/sourcecode]
If we run the two cmdlets, we can see who has access to this cmdlet:
This is useful if you are unsure what roles have access to a particular cmdlet. If there are any roles that are not assigned to say the Exchange Admin and a cmdlet fails, this could help identify what group needs to be in place to allow access to the PowerShell cmdlet.
The same method can also dig down into particular parameters within the cmdlet if need be to see if there maybe a hidden or restricted parameter.
Method 2 (Reverse Logic)
First, let’s review a list of Management Roles in Exchange. Then we will sample one of these roles to see what PowerShell cmdlets can be run.
Let’s to choose from. However, we only need one to pull an example. Thus we will pick the ‘Mail Tips’ role.
[sourcecode language=”powershell”]
Get-ManagementRole 'Mail Tips' | fl
[/sourcecode]
[sourcecode language=”powershell”]
$RoleEntries = (Get-ManagementRole 'Mail Tips').RoleEntries Foreach ($RoleEntry in $RoleEntries) { $RoleEntry}
[/sourcecode]
As we can see, the Mail Tips role has access to 10+ PowerShell cmdlets. We also see that there is asset of Parameters of those cmdlets that the said role has access to. This same method can be used on any of the cmdlets in Exchange. This method is useful if you need to audit what a user has access to in PowerShell while knowing what roles they have assigned.
You should be able to do this in any Exchange workload (office 365 – Exchange Online, Azure, etc.) as well as any Microsoft product that uses PowerShell and RBAC – Exchange on-premises, SharePoint, Active Directory, etc.
