Xamarin MSAL Azure AD ADFS AcquireTokenInteractive error

Question

Hi I just seen this error in our app ,

ERROR

Web page not Available

The web page at https://adfs.srm.com/adfs/ls/wia?client-request-id=##########

Could not be loaded because : net::ERR_HTTP_RESPONSE_CODE_FAILURE

Normally the user enter their email account, then it gets taken to another "Taking you to your organisation's sign-in page" then screen to enter the password .

Since 2 weeks ago they get the error (1st image), after the "Taking you to your organisation's sign-in page" is loading . As far as I know this was working 2 or 3 weeks ago.

I cannot find any information regarding this error , any ideas ?

Authentication method

var builder = PublicClientApplicationBuilder.Create(AppConstants.AadClientId)
.WithIosKeychainSecurityGroup(AppConstants.AppId)
.WithRedirectUri(RedirectUri)
.WithLogging(Log, LogLevel.Verbose, enablePiiLogging: true, enableDefaultPlatformLogging: false)
.WithAuthority(AzureCloudInstance.AzurePublic , AppConstants.TenantId);

try
{
    var accounts = await _pca.GetAccountsAsync();
    var firstAccount = accounts.FirstOrDefault();
    var authResult = await _pca.AcquireTokenSilent(Scopes, firstAccount).ExecuteAsync();
	
	// Store the access token securely for later use.

}
catch (MsalUiRequiredException)
{
    try
    {
        // This means we need to login again through the MSAL window.

		//this is where it hangs and I don't see any error or response
        var authResult = await _pca.AcquireTokenInteractive(Scopes)
                                    .WithUseEmbeddedWebView(true)
                                    .ExecuteAsync();

        // Store the access token securely for later use.
        
    }

ADFS server is working fine for other browsers applications.

Answer 1

Hello @hernandoZ and thanks for sharing your solution. Since accepting and rating your own answer is not possible I'm reposting it here so you can accept and rate it so that others facing a similar issue can easily find a solution.

Problem solve it was an ADFS Serve configuration.

Answer 2

The issue is with the WIASupportedUserAgents ADFS property. Older version of ADFS included "Mozilla/5.0" which matches pretty much any Firefox or Chrome variant on any platform/OS. Upgrading ADFS from older versions does NOT update this property during the upgrade process!

From this article:

https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-browser-wia

Microsoft suggests updating this property with the following (as of September 2024) for ADFS 2016 and later:

Set-AdfsProperties -WIASupportedUserAgents @("MSIE 6.0", "MSIE 7.0; Windows NT", "MSIE 8.0", "MSIE 9.0", "MSIE 10.0; Windows NT 6", "Windows NT 6.3; Trident/7.0", "Windows NT 6.3; Win64; x64; Trident/7.0", "Windows NT 6.3; WOW64; Trident/7.0", "Windows NT 6.2; Trident/7.0", "Windows NT 6.2; Win64; x64; Trident/7.0", "Windows NT 6.2; WOW64; Trident/7.0", "Windows NT 6.1; Trident/7.0", "Windows NT 6.1; Win64; x64; Trident/7.0", "Windows NT 6.1; WOW64; Trident/7.0","Windows NT 10.0; WOW64; Trident/7.0", "MSIPC", "Windows Rights Management Client", "=~Windows\s*NT.*Edg.*")

Another article I found suggested adding the following 2 entries as well to continue allowing WIA for Chrome/Firefox on Mac/Windows (although I don't know why Mac... not sure that it supports WIA):

• Mozilla/5.0 (Macintosh
• Mozilla/5.0 (Windows