Cloud Solution Providers and Guest and Member Users

This post is part of a mini-series that explains how Microsoft Customers, Azure AD Tenants, Azure Subscriptions and Cloud Solution Providers all work together.

It is aimed at anyone who wishes to purchase Azure resources from a Cloud Solution Provider (CSP) such as NewOrbit, as well as Microsoft Partners who wish to understand the relationship between CSPs and Customers better.

This is an immensely confusing topic that often stumps people who have spent years working with Azure - even as Partners.

I focus on explaining the concepts rather than being 100% technically correct. This means some of the detail is glossed over or simplified. This series focuses on Partners providing Azure to Customers, but the Microsoft 365 side is inherently linked to this so there will be some straying into that area as well.

• Azure - Tenants vs Subscriptions demystified
• Cloud Solution Providers
• What does this mean for me as a Customer
• Foreign Principal Access
• Granular Delegated Access Privileges - GDAP
• Lighthouse
• Guest and Member Users
• As a Partner, how do I work with other Partners on the same Customer?

When a Cloud Solution Provider needs to access a Customer's Azure resources, the default method should be Lighthouse. However, there are some things Lighthouse cannot be used for, because it does not give access to the the Customer's Azure AD Tenant.

Foreign Principal access can be used for certain things, but due to the lack of security granularity, it should not be used by default (and there are things it can't do anyway).

For everything that remains, there are "Guest" Users and "Member" Users, which we will discuss in this post.

Member user

A "Member" user is your everyday, normal user in your Tenant. All your employees probably have a Member account and they use that to access their email, Sharepoint, Teams and so on.

It is possible for a Customer to create a "Member" user in their Tenant for the Partner to use. This may seem easy and logical: After all, the Partner needs access to do things in your Tenant, so why not create them as a user? This is not recommended. There are several drawbacks to this approach:

• The Partner user will have to manage a separate set of credentials and security controls.
• If the Partner user leave's the Partner's organization, they will still have access to your Azure Subscription unless you remember to remove them.
• Certain things in M365 defaults to giving all "Member" users access to your data, including SharePoint and Teams. This means that the Partner user may have access to your SharePoint and Teams data.

To date, we have only come across one scenario where a Partner would need a Member user in the Customer's Tenant, but there are potentially others. Our known scenarios is when the Customer wants the Partner to create an Azure DevOps organization. This can only be done by a Member user. At NewOrbit, instead of creating a temporary "Member" user, we prefer just to do a screen share with the Customer and create the Azure DevOps organization together.

Guest User

While Lighthouse is useful for occasional access and support, there are several things it cannot do. If a Partner carries out significant configuration work on a Customer's Azure or develops and deploys systems for the Customer, it is often a good idea to create one or more Guest Users for the Partner.

A "Guest" User is a bit different to a "Member" User. The Guest User is also created in the Customer's Tenant but it is almost a "shadow" account, if you like. It exists, it has an object ID in the Customer's Tenant and it can be referenced in much the same way as any other user in the Customer's Tenant. However, it is linked to a Member user in the Partner's Tenant. When the the Guest User logs in to the Customer's Tenant, they are actually logging in to the Partner's Tenant. It is, effectively, Single Sign On.

There are several benefits to Guest Users:

• The Partner user logs in with their existing credentials.
• If the Partner user leaves the Partner's organization, they lose access to the Customer's Azure Subscription immediately.
• A Guest User can be given access to manage Azure Devops organizations after they have been created. Just go to Organization Settings -> Policies and switch on "External guest access" first.
• A Guest User can be given the "Application Developer" role in the Tenant, allowing them to create and manage Service Principals.
• A Guest User will usually have the "Directory Reader" role by default (or can be given it). This allows them to manage permissions on Azure resources they manage for you.
• In the Azure Portal and in the CLI, it is easy for a Guest User to switch between their own Tenant and the Customer's Tenant.
• A Guest User can safely create resources in the Customer's Tenant without having to worry about weird edge cases where the resource ends up being owned by the Partner's Tenant.

The main downside to Guest Users is that the Customer has to create and manage them (GDAP can partly mitigate that, temporarily). This makes it a lot less flexible than Lighthouse, which the Partner can manage more autonomously (as long as it is set up correctly).

Note that a Guest User may appear to be superficially similar to a Foreign Principal or Lighthouse. It is not. Foreign Principal and Lighthouse access directly gives the Partner user's "Member" User in the Partner's Tenant access to the Customer's Azure resources. With a Guest User, a Guest User object exists in the Customer's Tenant and it is this Guest User object that is given access, not the Partner's Member User.

Conclusion

While we continue to recommend Lighthouse for day-to-day access, Guest Users are a useful tool for more permanent access to a Customer's Azure resources. They are particularly useful for deploying resources, managing Azure DevOps organizations and creating Service Principals.

You should (almost) never create a Member user for anyone outside your organization - including your Azure Cloud Solution Provider.

If you would like to talk this through with us, please get in touch.