Disabling Azure Active Directory Service Principal Might Block Power Platform Self-Service Purchases

Lack of Control Over Self-Service Purchases Makes Office 365 Tenants Unhappy

Microsoft Power Platform

Update: In an update to the self-service purchase FAQ posted on October 31, Microsoft announced that based on customer feedback, they will provide Office 365 tenants with a PowerShell-based method to turn off self-service purchasing on a per-product basis. They also said that the launch date for self-service purchases has been pushed out to January 14, 2020.

The unfavorable customer reaction to Microsoft’s decision to allow Office 365 users make self-service purchases for Power Platform licenses (starting November 19 – Figure 1) hasn’t calmed down. Multiple people have weighed in on the subject in the Microsoft Technical Community, and none seem too pleased. Comments like “an underhanded money grab by Microsoft,” “unacceptable practice,” and “flipping unbelievable” are representative of the feedback seen there, Twitter, Facebook, and other fora. A user voice on the topic has clocked up many votes since the announcement.

Microsoft announces self-service purchases for Power Platform apps
Figure 1: Microsoft announces self-service purchases for Power Platform apps

Anyone with an Azure Active Directory account in an Office 365 commercial tenant will be able to buy through self-service. It’s an oddity of the program that self-service purchases won’t be available to users in government, non-profit, or education sector tenants, possibly because Microsoft could run into difficulties if government users (in particular) started to buy their own software.

The biggest issue is the lack of control for tenant administrators. Simply put, introducing a feature to allow employees of a company buy their own licenses for tools that might be unapproved by the organization is unacceptable, especially when the organization has no way of blocking these purchases. In one way, it’s like Microsoft is endorsing shadow IT on one hand while advocating the use of tools like Cloud App Security to discover and suppress shadow IT on the other.

An Unhelpful Self-Service Purchases FAQ

Microsoft’s FAQ about self-service purchases published on October 25 isn’t really much help. It smells like a hastily-put together document that tries to put lipstick on a pig. Bland marketing assertions like “The intent of the self-service purchase option is to enable users to develop their own solutions to unlock productivity and drive business impact, while respecting organizations’ data governance and compliance” don’t address tenant concerns. No evidence is offered to prove the existence of “increased demand from both users and organizations to enable users to buy subscriptions on their own.”

Blather, Fud, and Incoherence

Buried in the FAQ is an incoherent statement saying: ”We’re being responsive to our customers who have requested this capability while allowing admins to maintain control over the services and respecting data governance and compliance. To learn more about managing Azure AD service principals, see Set-MsolServicePrincipal.

An extract from the FAQ about Self-Service Purchases for Power Platform apps
Figure 2: An extract from the FAQ about Self-Service Purchases for Power Platform apps

First, apart from allowing admins to see when self-service purchases are made, there’s no evidence that Microsoft is giving admins control over the services. The comment about respecting data governance and compliance is surely nonsensical in the light of poor organization oversight and no ability to block these purchases. Allowing self-service purchases drives a coach and horses through the governance that a tenant is entitled to exert if it says that its policy is that all software purchases must go corporate procurement. Just what compliance happens in that case?

A Buried Hint?

The comment about Azure Active Directory Service Principals hangs out there its own and doesn’t appear to have anything to do with self-service purchases. Unless someone put the sentence into the FAQ to mean that self-service purchases might depend on a service principal that a tenant can disable to block purchases. Service principals exist to allow apps and services to access Azure services in a controlled manner. If you look in your tenant, you might find that more service principals exist than you expect or know about.

I looked in my tenant and used a PowerShell script (below) to discover the set of service principals holding Azure Active Directory roles within the tenant.

# Report Service Principals holding Azure AD admin roles
$Roles = Get-MSolRole
Foreach ($Role in $Roles) {
     $RoleMembers = $Null
     $RoleMembers = (Get-MsolRoleMember -RoleObjectId $Role.ObjectId)
     If ($RoleMembers) {
     ForEach ($RoleMember in $RoleMembers) {
       If ($RoleMember.RoleMemberType -eq "ServicePrincipal") {Write-Host $Role.Name "service principal:" $RoleMember.DisplayName }}
Company Administrator service principal: Microsoft Rights Management Services
Directory Readers service principal: Power BI Service
Directory Readers service principal: Office 365 Yammer
Directory Readers service principal: Cogmotive Reports
Directory Readers service principal: O365SecureScore
Directory Readers service principal: MS-PIM
Directory Readers service principal: MicrosoftAzureActiveAuthn
Directory Writers service principal: O365trustportal
Directory Writers service principal: O365 Secure Score

If you prefer to use the Azure AD cmdlets, the code is:

# Report Service Principals holding Azure AD admin roles
$Roles = Get-AzureADDirectoryRole
Foreach ($Role in $Roles) {
     $RoleMembers = $Null
     $RoleMembers = (Get-AzureADDirectoryRoleMember -ObjectId $Role.ObjectId)
     If ($RoleMembers) {
     ForEach ($RoleMember in $RoleMembers) {
       If ($RoleMember.ObjectType -eq "ServicePrincipal") {Write-Host $Role.DisplayName "service principal:" $RoleMember.DisplayName }}

Some of the role assignments seem duplications (like the two for Office 365 Secure Score. All except one hold the Directory Readers role, which means that they can read Azure Active Directory for information. The exception is Rights Management, which has full administrative rights.

A Route to the Solution?

The point is this: it may be the case that self-service purchases depend on a service principal that reads Azure Active Directory to confirm that someone belongs to a tenant. If so, disabling that service principal by removing its role assigning to the Directory Readers role should be enough to knock self-service purchases on the head.

Wouldn’t it be delicious if a hint dropped in the FAQ turned out to be the way to the block that administrators want, and Microsoft is curiously reluctant to deliver? I’ve created a To Do task to remind myself to check this out on November 19.

Keeping track of Office 365 Administration is tough enough without Microsoft making it hard through some odd decisions. We do our best to help by chasing things down and explaining what’s important in the Office 365 for IT Pros eBook. If you have anything to do with Office 365 administration, you should be a subscriber!

2 Replies to “Disabling Azure Active Directory Service Principal Might Block Power Platform Self-Service Purchases”

  1. Looks like Microsoft have heard the complaints and are backtracking: https://docs.microsoft.com/en-us/microsoft-365/commerce/subscriptions/self-service-purchase-faq

    UPDATE as of October 31, 2019: Over the past week, we’ve been listening to customer feedback regarding the rollout of our self-service purchase capabilities for Power Platform products. Based on the feedback, we’re making the following changes to our plan:

    On November 19th, we will provide IT admins a way to turn off self-service purchasing on a per product basis via PowerShell. More details will be forthcoming.

    To provide more time to prepare for this change, we are updating the launch for self-service purchase capabilities for Power Platform products to start with Power BI on January 14th for all commercial cloud customers.

Leave a Reply

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