Fixing Configuration Manager Azure Active Directory Authentication Error AADSTS50011

We recently had an issue where our Configuration Manger clients were unable to authenticate against Azure Active Directory.

Overview

The issue wasn’t immediately clear as the majority of the time, our devices are connected via LAN or VPN and use certificate-based authentication, but our internal SOC started reporting authentication failure alerts against the Azure EndpointManager-Client enterprise app registration. Checking the Azure Active Directory sign in logs, the issue quickly became apparent.

Test the cloud management gateway

One of the first things I checked was our cloud management gateway (CMG), as everything was working fine while the clients where on our corporate network.

You can tell your client to only use the CMG by changing the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\Security, ClientAlwaysOnInternet = 1

Once the registry key is set, you can see the connection type change to Always Internet in the client’s configuration manager properties window.

Launching Software Centre, I found no applications showing, and an authentication error popped up with the message: AADSTS50011: The redirect URI 'ms-appx-web://Microsoft.AAD.BrokerPlugin/RedirectURI' specified in the request does not match.

Check the logs

The next place to look is the CcmAad.log log file (previously ADALOperationProvider.log). This log contains information about client authentication token requests with Azure Active Directory Authentication Library (ADAL). Opening the log presented a sea of red.

Digging into the log file revealed the same error mentioned above:

WAM token request failed. Status 5, Details 'AADSTS50011: The redirect URI 'ms-appx-web://Microsoft.AAD.BrokerPlugin/<REDACTED>' specified in the request does not match the redirect URIs configured for the application '<GUID>'. Make sure the redirect URI sent in the request matches one added to your application in the Azure portal. Navigate to [https://aka.ms/redirectUriMismatchError](https://aka.ms/redirectUriMismatchError) to learn more about how to fix this.

Cause

The error message itself provides a URL to a Microsoft article which explains the issue and how you can resolve it.

When Configuration Manager tries to authenticate against Azure AD, it uses an Azure App Registration to do this.

The name of the app registration can be seen under the application column in the sign in logs failures, but you can also find the name from the GUID provided in the error message itself.

This issue occurs if the redirect URI being sent by the Configuration Manager client doesn’t match any of the redirect URIs that are specified within the Azure App Registration.

Resolution

To resolve this issue, we need to add the redirect URI value from the error message to the Enterprise App Registration used by Configuration Manager. In my case the Redirect URI was ms-appx-web://Microsoft.AAD.BrokerPlugin/REDACTED.

To navigate directly to authentication blade of the Enterprise Application used by Configuration Manger in the Azure portal, first copy the application GUID from the error message, then suffix it to the end of the following URL:

https://portal.azure.com/#blade/Microsoft_AAD_RegisteredApps/ApplicationMenuBlade/Authentication/appId/<GUID HERE>

Otherwise, you can just open the Azure AD portal and enter the GUID directly into the search bar and select the application that appears, then select the Authentication blade.

You will be taken to a page that looks like this:

Select the Add URI option at the bottom of the Redirect URIs list, then enter the Redirect URI value from the error message. Select Save to finish.

Outcome

That’s it! With the correct Redirect URI in place, the Configuration Manager client can now authenticate against Azure AD.

Checking the CcmAad.log file now shows the client successfully retrieving AAD (user) tokens.

And software center is now fully functionaly when running against the CMG.

The cause of this issue is still a mystery. There were absolutely zero issues with clients while they were on the corporate network or VPN. My hunch is AAD authentication never worked and an expired certificate on the CMG forced the client to fall back to Azure AD authentication rather than certificate based authentication, but that’s for another day.