Working with Microsoft Azure Active Directory Applications – Part 2

Welcome to Part 2 of my series on setting up and managing applications in a Microsoft 365 tenant. In Part 1, I focused on how Azure AD applications can be used to provide secure access control to data and services. I demonstrated how to create an Azure AD application in the home tenant and the importance of integrating with Azure AD for centralized app registration, management, and security measures.

In this article, I will dive deeper into the topic and exploring how to use and manage a multitenant app in foreign M365 tenants. So, let's get started!

Allow Another M365 Tenant to Access the Application

Let´s assume I cooperating with other subcontractors or partners, and we want to make the resource – our web app – available for other partners in other M365 tenants as well. The partner users shall be able to use their own work account of their own M365 tenant with single sign-on (SSO) to use the application.

In part 1, I demonstrated that users from another tenant do not get access to the application. So, I need to make this application available for other M365 tenants. I can do that in the application properties.

In the Azure portal, in Azure AD of our home tenant, I'll locate and open the MyISVApp. In the Overview, I'll click on the Supported account types link (or on the Redirect URI link) as shown in Figure 1.

In the supported account types section, I'll choose the option to switch from the single tenant option to the multitenant option, as in Figure 2.

When done, I'll click Save. This updates the app settings of the MyISVApp in the Supported account section to type “Multiple organizations.” If I don´t use additional app features, I do not need to add more settings that are available in the menu Token configuration, API permisisons, or Expose an API.

It´s important for multitenant apps to check the following information provided by Microsoft on the app Authentication page: “Starting November 9th, 2020, end users will no longer be able to grant consent to newly registered multitenant apps without verified publishers.” So, when I want end users to be able to use the app, I need to be a Microsoft partner and add a validated Microsoft Partner Center (MPN) Id to the application in real-world scenarios.

Note: When I added the application to a web app, in my tests, I needed to remove the app first and then add it again to the web app to work properly. This procedure is also my recommendation if you modify the single/multitenant app settings. This workaround is not needed if the app is set to multitenant from the beginning.

I am done with the app settings; switch to multitenant in the home tenant.

Create the App in Another M365 Tenant

To use the application in another tenant, the application must exist in the partner tenant. Otherwise, users get an error like “Selected user account does not exist in tenant '<home-tenant>' and cannot access the application '<appid>' in that tenant.” You'll remember from part 1 of this article that you saw a similar message before when I tried with a user outside of the home tenant.

In the partner tenant, every user can add a new application, or only the administrator can do so, depending on the M365 tenant organizational settings. This behavior can be controlled by the Administrator in the Users | Users settings in the Azure portal, as in Figure 3.

Typically, the setting is set to the first (Do not allow user content) or to the second option (Allow user consent for apps from verified publishers…) in most production environments. Microsoft´s recommendation is to use the second setting, “Allow user consent for apps from verified publishers, for selected permissions (Recommended)”. An administrator must set this in their tenant as desired.

Access from Another M365 Tenant

In the partner tenant, the administrator simply opens the web app URL; in this demo the URL is https://myisvweb.azurewebsites.net. 

The first time the administrator opens the URL, they see the required permissions request from our MyISVApp. The administrator can select the “Consent on behalf of your organization” check box to allow all users to use this app. However, the administrator needs to accept the dialog with all required permissions (as mentioned before, all or nothing), as in Figure 4.

In the partner tenant, after the login screen, I see the request. The app asks for permission to “Read all users' full profiles” in the M365 tenant – remember that I added that permission when creating the app. After the administrator grants consent, the web app login follows. The web app opens, as in Figure 5.

What happened in the background? Well, the multitenant app has been registered in the partner tenant as a copy.

Enterprise App Management in the Partner Tenant

Third-party apps are apps that are not created by us in our own M365 tenant. Apps such as the MyISVApp are managed as enterprise applications in Azure AD. After the app is registered, the administrator can check all registered applications in the Enterprise applications page in the Azure portal.

The App Id is the same as in the home tenant, but it's a copy of the original application. Administrators are responsible for the applications in their own tenant. Figure 6 shows the app on the Enterprise applications page.

Administrators can modify the application settings for their users, but not the application properties (otherwise the app would eventually no longer work). They can also remove the whole application from their tenant if needed on the Properties page (the delete method is also hidden here), as shown in Figure 7.

Application Access of Other Users in the Partner Tenant

Now let me try to open the web app at https://myisvweb.azurewebsites.net/ in another In-Private browser as user AlexW@tpoe5 from the partner tenant: This user is no guest user in our home tenant, and not associated with the home tenant in any way. I'll sign in as AlexW from another M365 tenant to the website, as shown in Figure 8.

After the successful login, the app opens as you can see in Figure 9.

Note: If the admin had NOT given the app consent for features that require the approval of an administrator, Azure AD informs the user about this requirement, as shown in Figure 10.

If the user clicks on the “Return to the application without granting consent” link, the app cannot be used. The browser then shows the message, “You do not have permission to view this directory or page.”

In my sample, a Global Admin (or another administrator with the app privileges) has to give the consent for this application before their users can start working with the app.

So far, so good. Other users can use an application if it was added to their own M365 tenant. They can use their own SSO to authenticate, and administrators can control who can use the application.

Add More Permissions to the Multitenant App in the Home Tenant

Let´s assume the development department adds new features to the web app. The developers inform the administrator that another permission is required for a new feature. In the home tenant, I will open the MyISVApp API permissions, and add another Graph permission as shown in Figure 11.

In this demo, I will select Microsoft Graph, and Delegated permissions, and add the Groups.Read.All permission. This allows the app to read all groups from the M365 tenant in addition to the existing permissions. I'll assume that the web app needs these permissions to show all groups within the app as visualized in Figure 12.

I'll click Add permissions. Then, the administrator grants access for the new permissions in the home tenant as seen in Figure 13.

In the home tenant, there is no change for the users. The (updated) app works and now has access to read all users and groups in the Azure AD of the home tenant.

What Happens in Other Tenants

Nothing. The multitenant app is a copy that was registered before. There is no connection between the Azure AD tenants. You can still see the existing permissions in the Enterprise application in the partner tenant, as shown in Figure 14.

To make it clear: If the application permissions are changed in the original Azure AD, those changes will not be automatically reflected in other tenants where the application is already installed or has been granted permissions.

In other tenants, the original application permissions remain where it has already been granted permissions. This means that the application will continue to have the ability to read all users in those other tenants, but – in our case – no permission to read all groups.

In order to ensure that the permissions granted to the application are consistent across all tenants, you would need to manually update the permissions in each tenant where the application is installed or has been granted permissions. Another option is that the application itself checks the missing permissions and asks to grant them.

Add Consent to an Application in a Partner Tenant

To update the multitenant app permissions, an administrator will then need to re-grant consent to the application in each tenant where it has been installed. In the next few paragraphs, I'll describe the process for how this can be done:

The vendor should provide a link to the partner that asks for the consent of the application. Here is the pattern:

https://login.microsoftonline.com/common/adminconsent?client_id=<your-appid>

This URL will ask for a sign-in (with the common endpoint, so this works for any M365 tenant) and for the consent of the application.

This small PowerShell script can be adapted and handed over to the partner:

Connect-AzureAD -Tenant "<your-tenant>.onmicrosoft.com"
$appId="<your-appid>"
Start-Process "https://login.microsoftonline.com/common/adminconsent?client_id=$appId"

In the partner tenant, the administrator can run the commands shown in Figure 15.

With Start-Process, the browser opens with the generated URL and asks for a sign-in. Then, the administrator needs to grant the consent to the application. In the sample this looks like Figure 16.

You can see that at this time, the newly added "Read All Groups" permission is also required to use the application MyISVApp. That's exactly what I wanted to achieve.

If the administrator clicks Accept, the login flow continues, redirecting to the application, as you can see in Figure 17.

I could add a custom URL as well, with the parameter &redirect_uri=https://... with a custom web page if needed.

When the administrator checks the newly granted permissions on the Enterprise application page, they see the new permissions. I can now use the app with the Group.Read.All permissions in the partner tenant as you can see in Figure 18.

Another method could be implemented in the application. The app could try to access the new feature, get an authorization denied error, usually HTTP 403 Forbidden, and automatically asks for the permissions with a redirect to the consent link.

So, I have shown you various methods to ensure that the application obtains the necessary permissions. One such method is to provide the app consent link to our partners, enabling them to add required permissions if necessary.

Summary

Using Azure AD applications in a multitenant environment is an effective method to expand your application's capabilities and streamline access management for users across various organizations. This approach offers centralized app registration and management, making it easier to manage access control and permissions. By following the steps outlined in this article, you can set up and manage Azure AD applications in your own environment with confidence. Whether you are a developer, IT professional or business owner, understanding Azure AD secured applications is essential in today's digital landscape.

I hope this real-world experience article provides useful insights and guidance on using and managing Azure AD applications in your environment.