locked
KB4493473 and ADFS v2016 - Ws-Fed wsignoutcleanup not sent RRS feed

  • Question

  • My organization runs an AD FS farm on Windows Server 2016 1607, fully patched.

    Recently, we noticed that a specific automated web test suddenly started failing to properly sign out users it previously signed into a web app using WS-Federation.

    Specifically, the test

    • loads a page requiring authentication on the web app
    • gets redirected to ADFS (WS-Federation wsignin)
    • test authenticates a test user via the web form

    The authenticated page loads into the browser, and the test performs a series of asserts.

    Then the test signs out the current user. It does so by loading up the IdP Initiated Signin page on ADFS, choosing to sign out from all applications.

    The expected result is for ADFS to issue a wsignoutcleanup request to all web apps it authenticated (i.e. the single web app being tested). However, the wsignoutcleanup request is not made. This in turn results in the test user retaining a session in the the web app, and the test fails.

    We investigated, and determined that removing patch KB4493473, which had been installed the night before the test started failing, resolved the issue. With the patch uninstalled, wsignoutcleanup is sent as expected, and reinstalling the patch reintroduces the problem. However, reading the patch notes does seem to indicate any changes directly related to AD FS.

    Has anyone else seen this or similar issues after installing KB4493473?

    Monday, May 6, 2019 1:32 PM

Answers

  • Update: there is fix for people who are running on ADFS 2019 and have the Set-AdfsResponseHeaders command available:

    Set-AdfsResponseHeaders -SetHeaderName "Set-Cookie" -SetHeaderValue "MSISSignoutProtocol=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/adfs; HttpOnly; Secure"

    This will issue a set-cookie command on every request to instruct the browser to delete the MSISSignoutProtocol cookie. Works for me but I'd like to get input of a MSFT engineer to know if they will issue a better fix. 


    Friday, August 23, 2019 1:52 PM

All replies

  • Yes, we have observed the same issue on our side in that ADFS is not sending a wsignoutcleanup request to the relying party during the single logout process.

    In our case, uninstalling KB4494440 on our ADFS 2016 instance resolved the issue. Have you raised a support ticket yet with Microsoft yet and gotten any sort of response?

    Thursday, May 30, 2019 4:52 PM
  • Not yet, but that is probably next step for us. In the mean time we have found out that while uninstalling and blocking/hiding KB4493473 resolved the issue initially, the issue has since resurfaced on the same set of Windows Server 2016 servers.

    Our servers currently have the following updates installed:

    KB3192137
    KB4049065
    KB4093137
    KB4132216
    KB4465659
    KB4091664
    KB4485447
    KB4498947
    KB4499177

    Note that KB4494440 is not installed, so it does not seem to be the cause here.

    Friday, May 31, 2019 8:25 AM
  • Do you folks mind sharing a Fiddler trace of a repro?

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Friday, May 31, 2019 8:15 PM
  • I have shared a Fiddler trace here:
    https://www.dropbox.com/s/svnzo18czpqgbpu/wsignoutcleanup_not_sent_repro.saz?dl=0

    However, when analyzing it, I noticed that while the wsignoutcleanup1.0 request is not sent by the browser (just retested both Chrome and Edge incognito sessions), it is indeed generated by ADFS. Specifically, request 67 renders it out as an invisible iframe:

    <iframe style="visibility: hidden; width: 1px; height: 1px;" src="https://devtest-www-delegation.vfltest.dk/?wa=wsignoutcleanup1.0" id="signoutFrame" class="signoutFrame"></iframe>

    I do not know if a recent patch altered the output of the wsignoutcleanup1.0 message (iirc ADFS v2008 R2 use 1x1 px images, not iframes), but it was definitely working before our automated UI tests started detecting the issue 25/4/2019.

    Short guide to the Fiddler trace:
    Request 13 -> Web app front page requiring authentication hit, redirects to ADFS for Wsfed authentication
    Request 16-28 -> Authentication performed using web form
    Request 28 -> Token generated and auto-POSTed as wsignin1.0 message
    Request 29 -> Token received and validated by web app, session cookie set
    Request 30-48 -> Web app front page loads
    (in another tab)
    Request 57 -> ADFS Idp initiated signon page loads
    Request 66 -> Sign out everyone clicked, page posts back
    Request 67 -> wsignout1.0 message. Renders a wsignoutcleanup1.0 as

          <iframe style="visibility: hidden; width: 1px; height: 1px;" src="https://devtest-www-delegation.vfltest.dk/?wa=wsignoutcleanup1.0" id="signoutFrame" class="signoutFrame"></iframe>

    But the request is never sent by the browser, so the session is not cleaned up.

    Request 69 -> Reload Web app front page and confirm session still lives

       
    Monday, June 3, 2019 3:12 PM
  • I'm having a similar issue on ADFS 2019. Sometimes federated logout using the /adfs/oauth2/logout works, sometimes it doesn't. Turns out that the contents of the logout page do not always contain the hidden iframe.

    The magic iframe is 

    <iframe style="visibility: hidden; width: 1px; height: 1px;" src="https://adfs.domain.tld/adfs/ls/?wa=wsignout1.0" id="signoutFrame" class="signoutFrame"></iframe>

    This frame sometimes is present on the oauth2/logout page, sometimes it is not (all else remaining equal). I suspect the fix added in kb4038801 is either not a complete fix or it is not applicable to 2019. 

    Friday, August 23, 2019 1:34 PM
  • Update: this issue seems to be caused by the MSISSignoutProtocol cookie, which is set after the first successful logout. 

    if this cookie is present, the federated logout fails (since the signoutFrame is not added to the logout page). If it is not present, everything works as expected. 

    Since the first successful logout sets that cookie, the following logouts will not be successful. This is therefore related to the issue mentioned here:  https://social.technet.microsoft.com/Forums/en-US/1bf203f4-c71c-4d50-8d54-8f4e1982ccae/saml-logout-problem?forum=ADFS

    Friday, August 23, 2019 1:42 PM
  • Update: there is fix for people who are running on ADFS 2019 and have the Set-AdfsResponseHeaders command available:

    Set-AdfsResponseHeaders -SetHeaderName "Set-Cookie" -SetHeaderValue "MSISSignoutProtocol=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/adfs; HttpOnly; Secure"

    This will issue a set-cookie command on every request to instruct the browser to delete the MSISSignoutProtocol cookie. Works for me but I'd like to get input of a MSFT engineer to know if they will issue a better fix. 


    Friday, August 23, 2019 1:52 PM
  • The OAuth2 logout issue might be related, but the solution listed below (Set-AdfsResponseHeaders on MSISSignoutProtocol) have no effect on the WS-Fed signout issue. We have upgraded our farm to ADFS v2019 (for other reasons), and the WS-Fed signout issue is still present.

    Thursday, September 5, 2019 8:35 AM
  • A followup, as I managed to identify the problem:

    To allow select systems to host the ADFS pages in iframes, we had previously added a Content-Security-Policy frame-ancestors header, whitelisting specific urls. This header is newer, and overrides X-Frame-Options:deny emitted by default by ADFS in browser which support it.

    However, when SLO is initiated by a SAML-P SP, the WS-Fed signout page is rendered in an iframe (see my previous comment), and that iframe was being blocked by frame-ancestors, as the ADFS domain was not listed. This was the cause of the ?wa=wsignoutcleanup1.0 links not being requested - the frame that should request them was being blocked by the browser. ADFS apparently has some built-in logic around this, as X-Frame-Options: deny is not sent for the signout page.

    We fixed this by adding the ADFS url to frame-ancestors, which resolved the issues we were seeing with SLO.

    Tuesday, October 29, 2019 10:27 PM