Attempting to use a Chrome or Edge browser to access an Windows Server 2019 ADFS server with DUO MFA displays the message: “Request to the server has been blocked by an extension.”

Problem

You’ve deployed a new Active Directory Federation Services (ADFS) farm on Windows Server 2019 and integrated DUO MFA with the portal so users logging onto Office 365 would be redirected to the ADFS portal protected by DUO 2FA but notice that using a Chrome or Edge browser fails to display the DUO authentication prompt and presents the following error:

Request to the server has been blocked by an extension.

Internet Explorer 11 does not exhibit this issue.

Performing a Google search for the error reveals that this is a known issue as described in the following DUO KB:

How do I resolve the error “Request to server has been blocked by extension” when logging in to Duo-protected AD FS on Server 2019?
https://help.duo.com/s/article/4832?language=en_US

In Windows Server 2019, Microsoft introduced a new security feature to allow for custom HTTP headers to be sent by AD FS. As a result there are more restrictive policies around displaying the Duo Prompt.

You proceed to implement the suggested additional configuration frame-src api-xxxxxx.duosecurity.com to the Content Security Policy (CSP) to the ADFS response headers as suggested but continue to receive the error.

Solution

————————————————————————————————————————–

Update: April 26, 2020

It appears the article:

How do I resolve the error “Request to server has been blocked by extension” when logging in to Duo-protected AD FS on Server 2019?
https://help.duo.com/s/article/4832?language=en_US

… was not clear that you are supposed to replace the hostname api-xxxxxx.duosecurity.com in both of the supplied options with the Duo hostname. To correct this issue, you can log onto the Duo administrator portal and retrieve the specific hostname for the application it is protection:

Or you can proceed to use a wildcard URL as I outlined below.

————————————————————————————————————————–

I’m not completely sure what date the article was written as I could not find any reference but I’ve come across a similar issue a while ago as outlined in the following post:

Configuring Content-Security-Policy HTTP Response Header on Citrix ADC for Citrix Apps and Desktops with DUO integration
https://blog.terenceluk.com/2020/02/configuring-content-security-policy.html

I had not seen the DUO knowledge base article during the troubleshooting in my blog post but the extra frame-src api-xxxxxx.duosecurity.com made sense as it explicitly specifies the URL to begin with api- followed by 5 characters and finally .duosecurity.com. However, as implementing the following cmdlet didn’t work:

Set-AdfsResponseHeaders -SetHeaderName “Content-Security-Policy” -SetHeaderValue “default-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’; img-src ‘self’; frame-src api-xxxxxx.duosecurity.com “

I took another look at the second cmdlet that is suggested if the CSP has already been configured and noticed that the API hostname string had only 5 X, rather than 6 in the cmdlet above:

$apihostname = “api-XXXXX.duosecurity.com”

$CSP = ((Get-AdfsResponseHeaders | Select -ExpandProperty ResponseHeaders).’Content-Security-Policy’)

$CSP = $CSP + “; frame-src ” + $apihostname

Set-AdfsResponseHeaders -SetHeaderName “Content-Security-Policy” -SetHeaderValue $CSP

I tried modifying the CSP to include only 5 X but that did not correct the issue.

Troubleshooting at a deeper level with the developer tools revealed that frame was trying to load the following URL: https://api-8fe1dff4.duosecurity.com/

Refused to frame ‘https://api-8fe1dff4.duosecurity.com/’ because it violates the following Content Security Policy directive: “frame-src api-xxxxxx.duosecurity.com”.

This did not match the allowed string so I followed the same configuration I used in my previous blog post and simply allowed all subdomains for duosecurity.com as such:

Set-AdfsResponseHeaders -SetHeaderName “Content-Security-Policy” -SetHeaderValue “default-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’; img-src ‘self’; frame-src *.duosecurity.com “

**Note that the ResponseHeaders value gets truncated and will not display the full configuration unless you change the $FormatEnumerationLimit value to -1 by executing: $FormatEnumerationLimit=-1

The page began to load properly on Edge and Chrome once the above configuration was made.

I’m always open to corrections to my posts so please feel free to leave a comment if there is a better way of handling this.