Scoping an AppReg to Guest Only User Administration
Anatoly Mironov
Guest Users are crucial in many companies. Usually, External Identities get invited using Microsoft’s B2B Collaboration. While invitations don’t require hefty permissions, the update and delete operations demand User.ReadWrite.All which is a high risk. In this post I will guide you through how you can scope User Administration rights to just Guests.
While thinking about how to scope this, I googled a lot I didn’t find that much. What I found though, was a blog post on rakhesh.com:
The blog post seems to be a memory dump of all trials and errors, without wrap-up or summary in the end. I ended up doing trials and errors by myself. Here is my end result.
Of course, scoping can work to any subset of users, it doesn’t have to be just Guest Users, and also it is not limited to User Administration, I will stick to my original use case anyway, though.
Administrative Unit for Guest Users
To scope permissions, you need to have an administrative unit, you cannot use Security Groups. For Guest Users I created a new Administrative Unit, called it “Guest Users”, changed it to have dynamic membership and added a Dynamic Rule: (user.userType -eq "Guest").
App Registration
I created a new app registration, no platform, no permissions. test-app-au
Role Assignment
Now to the core task. This is simple when you know how to do it, but tricky the first time, hence I am thankful to rhakesh, without him I would have given up.
For the “Guest Users” Administrative Unit (it’s a name I chose, not something built-in), I clicked on “Roles and Administrators”, I then opened “User Administrator”.
In the assignments, I clicked on “Add Assignments”.
The scope was the current Administrative Unit. All I had to do was to search for my app registration and add it.
Verification
Now it’s time to see it in action. I am satisfied if:
- ✅ My app can read a guest user information
- ✅ My app cannot read an ordinary user information
- ✅ My app cannot get a list of all users
These are enough for my first verification. For the sake of simplicity, I will assume that all other CRUD (create, read, update, delete) operations will work as well.
I am using Microsoft Graph PowerShell Module. Nevermind me using a client secret and having it in plain text. I want to focus on the actual topic here.
All my verification steps were successful, here is one screenshot, showing the step 1 and 3.
Lessons Learned
Some obvious and less obvious lessons learned I obtained during my trial and error process.
- Creating Custom Role Assignment – is not needed
- Only AppRegs/Enterprise Apps can be assigned, not Managed Identities
- Service Principals can only have active role assignments, which makes sense, since there is no interactivity
- To find out: Will the administrative unit’s dynamic rule introduce a delay in the accesses for new guest users?
- Role Assignments are not possible on the groups, only on Administrative Units
- App Reg does not require any permissions at all
Wrap-up and a drawing
In order to scope access for an app to Guest Users, we need an administrative unit with a dynamic membership rule, and the User Administrator role assignment scoped to that Administrative Unit. With that your app can only update the scoped users (Guest Users in my case) but no one else. Pretty simple when you know it. And way more secure than User.ReadWrite.All.
