AD FS 2.0: "Script is disabled. Click Submit to continue."

Symptoms

When accessing an AD FS-protected resource using a web browser (passive requestor), the AD FS server presents a page similar to the following:

"Script is disabled. Click Submit to continue."

Once the user clicks the "Submit" button, access to the application is granted.

Cause

SAML assertions are sent from AD FS to Relying Party applications and Relying Party STS's using a HTTP POST binding, the assertions are put into a hidden form which needs to be POSTed to the Relying Party assertion consumer endpoint.

This has to happen via manual user interaction or via a script that the user allows to run in the browser. Since manual interaction is undesirable, AD FS uses JavaScript to perform the HTTP POST to the Relying Party.

If Active Scripting is disabled for the IE Zone where the AD FS STS lives, then the JavaScript cannot run and the manual interaction page is displayed.

This can also cause issues for web-based clients which do not have a browser interface to prompt the user. AD RMS is a good example of this type of client. AD RMS generates a WS-Federation request to the AD FS STS, and, when AD FS tries to POST the assertion back, the IE settings are used which can block the JavaScript from running. Since there is no interface to prompt the user to allow the POST, we fail silently.

Fiddler tracing will show you this problem when a browser isn't in use. You will see a frame similar to the following:

/adfs/ls/{insert_your_auth_method_here} - The result of the frame is an HTTP 302 (Redirect) which is indicative of the problem. The response header of this frame should be HTTP 200 (OK) followed by another frame which contains a request header HTTP POST.

Resolution

Enable Active Scripting for the IE Zone where the AD FS STS resides or add the AD FS STS to an IE Zone which has Active Scripting enabled.

Note: Watch for IE settings coming from Group Policy which may overwrite your changes at the next refresh.