SSO refuses to work through the Web Application Proxy RRS feed

  • General discussion

  • Hello,

    We have the domain environment running under Windows Server 2012 R2 with configured ADFS 3.0. It consists of Web Application Server, Domain Controller Server, ADFS Server and Web Application Proxy.

    On attempt to complete a Single Sign-On procedure, SSO cookies are obtained successfully. But unfortunately it’s impossible to use cookies obtained on the local machine (when it’s located in the local network with the configured environment: ADFS and Web Application Servers) when it changes its’ network to an external one (for example, when laptop switches from internal WiFi to external cellular network). That means that cookies become inappropriate in a some way, when client’s machine begins to use Web Application Proxy.

    We tried to use both NTLM and NTLMv2 standards to perform an authentication with the same result with no luck: SSO cookies are not accepted by the Application when the external network begins to be exploited. From the client’s point of view it looks like as a redirect to the Sign-In Page with SSO cookies saved in the web browser.

    What information or descriptions about our environment should we provide to make it clearer for the investigation? Thank you.

    Friday, November 30, 2018 4:04 PM

All replies

  • Hello,

    When you access to WAP, the user has an a new cookie called "EdgeAccessCookie", so as far as I know you can't use your internal cookie.

    More details on :



    Sunday, December 2, 2018 11:52 PM
  • Unfortunately I can't log any EdgeAccessCookie during the handshake procedure - maybe due to my configuration or probably misconfiguration. Can you please clarify - will this cookie appear with "EdgeAccessCookie" as its' name or is it a part of encoded MSISAuth cookies? 

    I suggest that first of all a way to enable this cookie should be found in my system, then it's better to make an attempt for decoding of the cookies. At least it will make clearer if something goes wrong with one of possible reasons (from the reply here: 

    The resource identifier that the user attempted to access.
    The user’s identity as a user principal name (UPN).
    The expiry of the access grant approval; that is, the user is granted access for a limited period of time, after which they are required to authenticate again.
    Signature of the information in the edge token.
    Friday, December 7, 2018 12:22 PM