Endpoint Agent fails to authenticate to a single-tenant MIP application in Azure
Article ID: 246519
Updated On:
Products
Issue/Introduction
The documentation of the DLP-MIP integration process used in DLP 15.8 and 16.0 contains the following requirement:
https://techdocs.broadcom.com/us/en/symantec-security-software/information-security/data-loss-prevention/15-8/working-with-general-settings-vont_0235-d297e6924/Working-with-Microsoft-Information-Protection/Authorizing-MIP-Insight-for-Data-Loss-Prevention-on-the-Azure-portal.html
However, there may be environments who prefer to use single-tenant Azure applications and would like to use that for the DLP-MIP integration.
When a single-tenant application is used with Endpoint Prevent, what will happen during an inspection attempt of a MIP-encrypted file is that:
a) The Agent will display a "Sign-in required" block popup first, but then will not follow it up with a MIP authentication popup window
b) When DebugView capture is run in the background during an attempt to inspect a MIP-encrypted file, it will capture the following error during the authentication attempt:
"Authenticator:MsalException - AADSTS50194: Application '<Application_ID>'(Application_Name) is not configured as a multi-tenant application. Usage of the /common endpoint is not supported for such applications created after '10/15/2018'. Use a tenant-specific endpoint or configure the application to be multi-tenant. "
Cause
The reason is a limitation on the MS/Azure side wherein single-tenant applications will not allow the use of the /common endpoint authentication URL. For single-tenant apps, a tenant-specific URL has to be used instead, with the tenant name inserted into the URL instead of 'common'.
However, changing the RedirectURI parameter in the Azure application configuration will not help because the authentication URL used depends fully on the application - here, the Endpoint Agent - and what it was coded to use.
Resolution
At the moment, a 15.8 and 16.0 Agent does not have the capability to authenticate to a single-tenant Azure application. This is why configuring the Azure application for DLP to be multi-tenant is a requirement.
What is important for customers to remember is that using a multi-tenant application in Azure is not a security risk. Even when a specific Azure tenant is configured to be a multi-tenant, what happens when an end user authenticates to any other tenant is: that user will not be directly accessing the Azure API to access any other tenant's resources. What that means is that there is no possibility for a user that is authenticating to another tenant to access another tenant as well. The only way to access a specific Azure tenant and its data is to log in using an account from that tenant.
When it comes to the EDPA-MIP integration, the Azure API here is not accessed by the end user but by the authenticator process, which in itself is short-lived and only runs when the end user needs to authenticate to MIP. Once the authentication is completed, the authenticator process stops functioning and the authenticated user will only have access to the resources of the tenant to which he has logged in.
The only possible risk here would be if an external user would somehow obtain possession of authentication credentials of a member of a specific Azure tenant. That obviously would be a problem outside of the scope of both DLP and Azure's security and it's similar to a situation where a malicious outsider obtains domain passwords of internal users - which is why the best way to avoid a possible risk here is to ensure that the Azure tenant credentials are not shared by their owners with anyone from outside of the company.
The reason behind the design of EDPA is that with multi-tenant apps, we can use an authentication URL which is not tenant-specific. If we would want to use a tenant-specific URL, then DLP would need to have a way to pass over the value of the Azure tenant ID to the authentication process and form the authentication URL using that ID. Given that from the security standpoint there is no substantial gain of using a single-tenant Azure application vs a multi-tenant app, we have decided to choose the multi-tenant \common URL for the authentication which will work in all setups for all customers, regardless of what is their Azure tenant ID.
Additional Information
You can also go through the below KB article from Microsoft for more details about multitenancy:
https://docs.microsoft.com/en-us/azure/architecture/multitenant-identity/
Feedback
