The past few weeks I was setting up a new cloud project for one of our customers. I prefer to follow the least-privilege-principle, which means that I refuse any administrator rights I don’t need. This usually comes down to Application Administrator activated through PIM and Owner rights on the subscriptions specific for the project. This allows me to set up service principals for deployment, after which I could even remove my own Owner rights.
The problem
I usually create all service principals (IaC and code deployments, per environment) with Azure CLI using the following command:
az ad sp create-for-rbac --name sp-xyz
You could assign the RBAC roles through CLI as well, but I typically do this in the portal with an extra visual check. However, this time I ran into following message when trying to pick members for the role.
Since I created both security groups and all the service principals, I knew their names (and object ID). For user groups, using the right name still finds the group, however for service principals the list stays empty.
Where to find this setting?
We can find the setting under Entra ID > User Settings. In the past I advised my customers to use the second option, which currently is still the default for tenants.
Now you can also limit the rights even further, which is a good aspect from governance perspective. We can read this in the documentation:
When guest access is restricted, guests can view only their own user profile. Permission to view other users isn’t allowed even if the guest is searching by User Principal Name or objectId. Restricted access also restricts guest users from seeing the membership of groups they’re in.
The solution
Run the following command to be able to assign roles (if you have sufficient rights on the subscription to do so). Note that you need to use the principal object id as the name is also blocked in Azure CLI.
az role assignment create --assignee <prinicpal id> --role Owner --scope /subscriptions/<subscription id>
With this one set, we can assign all other roles through IaC.
Conclusion
Moving forward, I’ll certainly suggest using this setting to further limit what a guest user can see in the tenant. But it is also important to know that it is partial security through obscurity rather than a full block.