One thing I’ve always tried to solve properly is how to simplify access to customer resources in Microsoft Azure, Office 365, Intune and other online services that Microsoft provides. This while still trying to achive a high level of security in regards to having MFA in place, auditing and avoiding having non-personal accounts and still trying to follow Microsoft best-pratices and limiting the amount of user accounts that you can have.
Now providing access within Azure Active Directory or Azure Resource Manager requires that you have an Azure AD user. That user is then given permission either to a specific role within Azure Active Directory or to role within Azure Resource Manager. These permissions gives “Bob” permissions to do certain actions either within Azure AD Space (which might be Office 365) or do to actions within Microsoft Azure.
Now this is the simplest form of access, where you have a single user contained within the same domain where it is operating. Here we can full audit within Azure AD (As long as you have proper licenses) and also we can benefit from the other Azure AD features such as PIM (Privileged Identity Management) or IP (Identity Protection). We can also use Conditional Access to have zero-trust based access to the different resources.
Within Azure we can also use RBAC based upon Azure AD groups to provide access to only certain aspects of an Azure organization topology
So what about partners or ISV’s that require access to a customer tenant? In the “old days” we had Active Directory based trust to manage access to resources within another domain or forest, in Azure AD we have some other options.
There are some options on how you as a partner can operate or be given access to a customer Azure AD or Azure subscription and ill go a bit more in-depth on the differences between them and the benefit which each of them.
- Azure Delegated Resource Management (aka lighthouse)
- Azure AD B2B
- Personal Account within customer Azure AD tenant
Azure Delegated Access
This is a new feature which was introduced a couple of weeks ago, which I’ve already written about here –> https://msandbu.org/getting-started-with-azure-lighthouse/ this provides delegated access to Azure only services. Meaning that this cannot be used to provide access to management capabilities of Intune, Office 365 or other aspects of Azure AD. For ISV’s that are only providing support for a LOB or an App running within a customer Azure Subscription this is the easier approach. Delegated Access provides for “single-pane of glass” access to all resources.
Delegated Access can also easily setup and supports automatic updates. If we have a group that has been given access to a certain set of resources within a customer tenant such as a resource group or subscription. If we update the group with a new set of users, they users will automatically be given access to the resources within the portal.
It should be noted that Delegated Access cannot be done on a Management Group level and the highest tier it can be assigned to is to Subscription level. Secondly, the highest level of permissions it can delegate is Contributer, which of course gives you full access to Azure resources, but not delegate more permissions.
As it is now, the service is not supported for all Azure features and therefore in some cases will not be sufficient for certain operations. On the up side this provides a simple view of all resources residing in multiple Azure Subscriptions, and based upon info from the PM there is more coming soon
Azure AD B2B
Azure AD B2B is similar to Domain Trust in Active Directory, basically adding a user from a resource domain access to another domain.
Now when the user is invited to Contoso Azure Active Directory it behaves like a regular Azure AD and can therefore be given access to resources within Azure or Office 365 or other services like any other user. Now the downside here is that we cannot provide an Azure AD Group based B2B so we can only add users and not groups. This makes it difficult for life cycle management of the group based access.
Also since you appear as a guest in another directory you get the organizations MFA policies applied, so if you don’t have MFA in the directory that you are sourced from but the inviting org has MFA in place you will need to configure MFA for your user.
On the up side, Microsoft has made some license changes for B2B users. With Azure Active Directory (Azure AD) business-to-business (B2B) collaboration, you can invite External Users (or “guest users”) to use your paid Azure AD services. For each paid Azure AD license that you assign to a user, you can invite up to five guest users under the External User Allowance.
Now with Azure AD B2B you can also apply Conditional Access to the users like regular Azure AD Users. However there are a few things that you need to be aware of.
- Risk-based sign-in policies cannot be applied to B2B users because the risk evaluation is performed at the B2B user’s home organization.
- Conditional Access app protection policies cannot be applied to B2B users because the inviting organization has no visibility into the B2B user’s home organization.
- Device Policies – device-based Conditional Access policies for their corporate data, access is prevented from devices that are not managed by the inviting organization and not compliant with the invitee device policies.
And also most services now support Azure AD and therefore support Azure AD B2B accounts, there is only certain cases where a service does not support Azure B2B and that is for instance the Exchange Admin console.
Also you should also define a custom Azure B2B policy to ensure that only allowed domains are allowed to get invited to the tenant, and restrict who can invite.
Personal account within the customer Azure AD tenant
Now as a partner you might work with multiple customers, so having a personal account for each customer might not be feasible, since it also would require multiple MFA accounts configured and multiple passwords that you need to remember for each tenant.
However there are certain settings which require having a native access. Also having multiple accounts makes it difficult for an end-user perspective to remember and these accounts should only be used as a “break-the-glass” account if something doesn’t work or certain admin operations that require access to this account.
So how to use it together?
- I recommend using Delegated Resource Access (Lighthouse) for Service Desk access such as Read-Only to customer based subscriptions, for Azure based resources. This provides them with a easy access to all customer resources across tenants and also gives access to Azure Monitor and also Security Center within a single view.
- I recommend using Azure AD B2B for 2 or 3 line access to customer environments if they also require access to Intune, Office 365 or other security products such as Windows Defender ATP and others. Azure AD B2B. Just important that you remember that you need have a way to update memberships within customer tenants either using Azure Automation or some form of IAM tool that can handle the user/group provisioning within customer tenants.
- Lastly personal accounts should also be in place for certain scenarioes or as an cloud only based “break-the-glass”. These type of Break the glass account should have notifcation triggers on them, so when someone actually uses them it notifies someone that they are being used.
Break the glass accounts
Microsoft recommends that you have atleast two emergency accounts and that they do not have MFA enabled (In case MFA is down, or something else that might happen such as Conditional Access rules that changed or so on. The most important thing is that these accounts are monitored when people use them. Also these accounts should also be only cloud based and not synced users. In order to monitor and alert based upon sign-in from these accounts you need to have Azure AD integrated with Log Analytics.
SigninLogs | where UserPrincipalName contains"adminaccountprefix" | where OperationName == "Sign-in activity"
