Block MSOnline PowerShell access for your tenant

One of the recent additions to the AzureAD (Preview) PowerShell module and the corresponding Graph API endpoints is the ability to configure “policy” objects within the tenant. In all fairness, “policies” aren’t something new, as they have been used for years to control things such as token lifetimes, or group creation if you will. Now, Microsoft is starting to reorganize some of those resources and plans to expose them via a unified endpoint in the future.

Enter the /policies endpoint. As you can see from the documentation, there are a total of 7 policies currently exposed, some of them quite interesting ones. But for the purposes of this article, we only care about the authorizationPolicy object, which exposes a toggle for enabling/disabling access to the MSOnline PowerShell cmdlets, among other things. The example below shows how you can query the endpoint and get the current policy settings (make sure the application has Policy.ReadWrite.Authorization permissions granted):

$tenantID = "tenant.onmicrosoft.com" #your tenantID or tenant root domain
$appID = "12345678-1234-1234-1234-1234567890AB" #the GUID of your app. For best result, use app with Sites.ReadWrite.All scope granted.
$client_secret = "XXXXXXXXXXXXXXXxxxx" #client secret for the app

$body = @{
client_id     = $AppId
scope         = "https://graph.microsoft.com/.default"
client_secret = $client_secret
grant_type    = "client_credentials"
}

$authenticationResult = Invoke-WebRequest -Method Post -Uri "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token" -ContentType "application/x-www-form-urlencoded" -Body $body -ErrorAction Stop
$token = ($authenticationResult.Content | ConvertFrom-Json).access_token
$authHeader = @{'Authorization'="Bearer $token"}

$res = Invoke-WebRequest -Headers $AuthHeader -Uri "https://graph.microsoft.com/beta/policies/authorizationPolicy/authorizationPolicy"
$result = ($res.Content | ConvertFrom-Json)
$result

@odata.context                                    : https://graph.microsoft.com/beta/$metadata#policies/authorizationPolicy/$entity
id                                                : authorizationPolicy
blockMsolPowerShell                               : null
displayName                                       : Authorization Policy
description                                       : Used to manage authorization related settings across the company.
enabledPreviewFeatures                            : {}
guestUserRoleId                                   : 10dae51f-b6af-4016-8d66-8c2a99b929b3
permissionGrantPolicyIdsAssignedToDefaultUserRole : {}

As one might expect, the value of the blockMsolPowerShell setting is null (undefined), which corresponds to the default behavior of every user in the tenant being able to access MSOnline PowerShell. In order to change the value, we need to issue a PATCH request, as follows:

$body = (@{"blockMsolPowerShell"="true"} | ConvertTo-Json)
$authHeader = @{'Authorization'=$authenticationResult.Result.CreateAuthorizationHeader();"Content-Type" = "application/json"}
$res = Invoke-WebRequest -Headers $AuthHeader -Uri "https://graph.microsoft.com/beta/policies/authorizationPolicy/authorizationPolicy" -Method Patch -Body $body

Then, we can rerun the GET request to confirm that the change has been applied successfully. Or better yet, we can go ahead and test directly via the MSOnline PowerShell module. While the Connect-MsolService cmdlet will still allow you to authenticate and connect to the service, every other cmdlet from the module will fail as shown below:

Moreover, this will apply to both end users and admins alike! In the example shown above, I’m actually logged in as the Global admin for that tenant, yet I cannot even run simple Get-* cmdlets against the MSOnline module. Thus, we know the setting is now in effect. And, compared to the previous method we had at our disposal, namely toggling the UsersPermissionToReadOtherUsersEnabled flag, which only applied to the Get-MsolUser cmdlet and users with no admin roles, the new method is much more restrictive. Make sure you know what you are doing before toggling this!

One last thing, if the process detailed above seems way too complicated to you, you can simply use the Set-AzureADMSAuthorizationPolicy cmdlet from the latest version of the AzureADPreview module.