Most customers have accepted at least one, if not multiple invitations from Microsoft partners to provide licensing or support services. What they often dont know is that by default this allows the partner to assign full administrative access to any of it’s staff, to perform tasks in the customers 365 / Azure tenant. It’s an ‘all or nothing’ configuration which is, and should be of concern to many customers who read the fine print of the invitation they are accepting.
The recent hack on a large distributor highlights how dangerous leaving this ‘as is’ can be:
Mega-distie SYNNEX attacked and Microsoft cloud accounts it tends tampered • The Register
Microsoft are developing the Lighthouse solution to allow us to use more detailed permissions for support. But it’s not there yet, so I started testing another solution to ths problem.
Turns out you can do most things using B2B guest access and client targeted URLs (appending the clients custom domain to the admin URL) as below:
Helpdesk staff use:
Azure AD – https://aad.portal.azure.com/customer.com
Exchange – https://outlook.office365.com/ecp/@customer.onmicrosoft.com
Admin staff use:
Azure – https://portal.azure.com/customer.com
Exchange – https://outlook.office365.com/ecp/@customer.onmicrosoft.com
SharePoint – https://customer-admin.sharepoint.com
Intune – https://endpoint.microsoft.com/customer.com
Security Center – https://securitycenter.windows.com/?tid=customer_tenant_id
Unfortunately this doesn’t seem to apply for the 365 Admin Center (please comment if you found a way to do it!), which is where you would want Helpdesk staff to be performing User / Exchange tasks, rather than jumping between Azure AD and Exchange portals. But, at least it works, and achieves the goal for security conscious customers who are hesitant to accept the partner invitation.
Here is the process:
1. Customer accepts MSP invitation
2. Customer removes the admin / helpdesk agent privileges from the partners area of the customers portal (this keeps the association and you can still procure licensing for them, but removes the default partner permissions)
3. Create two or more groups in customers Azure AD; one for your Helpdesk and one for Admins (with assign roles to group enabled)
4. Assign the roles to the Helpdesk group (change to fit your needs or use custom roles):
User Administrator
Exchange Recipient Administrator
5. Assign roles to the Admin group as required (you can use more admin groups to assign roles to different support groups if required):
Intune Administrator
Authentication Administrator
Exchange Administrator
User Administrator
Guest Inviter
Application Administrator
Compliance Administrator
Global Reader
Conditional Access Administrator
Cloud App Security Administrator
License Administrator
Azure AD Joined Device Local Administrator
Groups Administrator
SharePoint Administrator
Privileged Role Administrator
Azure Information Protection Administrator
Security Administrator
6. Assign Azure subscription roles to the Admin groups as required:
Contributor
7. You can also use these groups to assign permissions to certain Azure objects, using the IAM blade under the resource
8. Use ‘Bulk Invite’ in customers Azure AD users blade to invite all your support staff to the customer tenant as guests
9. Add the invited guest accounts to the groups you created as required
After a support staff member accepts the invitation, they can open the URLs mentioned above using their standard user account to perform tasks in a customer tenant.
Not perfect, but it does work and avoids using generic credentials to perform tasks in a customer tenant.
