wfresh parameter causing ADFS login to fail

Question

I am using ADFS to do federated logins with a number of different RPs, including our own custom web app, Office 365 and some other third-party services. I have run into a problem where logins silently fail when the wfresh=0 is specified in the URL. It just keeps asking for my password over and over again. When I click the "Login" button, it doesn't log you in and redirect you to back to the RP, nor does it fail and give you an error message. Instead, it redirects you back to the STS login page, so it looks to the user like it's silently failing.

I found this question: wfresh not working with WS-Federation via ADFS, which seems to be on the right track. However, while I am definitely seeing issues with integrated logins, I am getting similar issues with Forms logins as well. The outward symptoms are different, but the behavior seems to be the same: If you specify wfresh=0, it sends you directly to /adfs/ls.

Is there any way to configure ADFS to treat wfresh correctly, or at least to ignore it?

Update: Cross-posted to MSDN Geneva Forums: http://social.msdn.microsoft.com/Forums/vstudio/en-US/7acbbd11-cd69-466b-8faa-f129f24fe1fe/wfresh-parameter-causing-adfs-login-to-fail

Answer 1

Update: Microsoft today released their hotfix for this: http://support.microsoft.com/kb/2896713. It is not a public hotfix, so you will need to contact Microsoft support to get the update.

Previous: I spoke with an Escalation Engineer in Global Escalation Services for Microsoft. The EE said they are aware of this issue, tracking impacted customers, and working on a solution. Anyone who is experiencing this same problem should contact Microsoft support and open a support case so they are notified when the solution is available. Microsoft support is tracking this issue internally under solution id number 2879919.

Answer 2

I am seeing the same thing as of lately. We have connections with some RPs and also use Office 365. If I leave my machine logged into portal.microsoftonline.com it will eventually show "page cannot be displayed" with the URL showing the long string and "wfresh=0" at the end.

Externally, if i leave my browser logged into the portal it will take me back to the form but never accept my new credentials. If I change the value of "wfresh=0" to "1" it allows me back in external and internal. I'm trying to review event logs to see anything but have not found any clues. still looking.

Answer 3

Would it be a good or bad solution (if possible) to use MS IIS URL rewrite to replace or remove wfresh=0 from the URL when hitting the IIS?

Best would of course be if the default installation of ADFS worked with wfresh=0 in the first place :-)

IIS URL Rewrite1

---

Update:

My problem was that only internal clients experienced the error while external clients (using the ADFS proxy servers) did not.

With URL rewrite on the internal ADFS 2.1 servers and the following URL rewrite rule in /adfs/ls/web.config works:

    <rule name="wfresh0to1" enabled="true" stopProcessing="true">
     <match url="(.*)" />
      <conditions>
       <add input="{QUERY_STRING}" pattern="(.*)wfresh=0(.*)" />
      </conditions>
      <action type="Rewrite" url="{R:0}?{C:1}wfresh=1{C:2}" appendQueryString="false" />
    </rule>