locked
WebDav and Web Application Proxy (WAP) RRS feed

  • Question

  • User-738597541 posted

    Hey everyone!

    So I have built out a WebDav architecture that is proven out and working with the following config:

    Client (WebDav client) --> IIS --> File Server

    I have a proven ADFS and WAP architecture that works as follows:

    Client (Web Browser) --> WAP --> IIS --> File Server

    The above config only works when hosting content or allowing directory browsing but authentication is definitely working from start to finish on that.

    Where it breaks is if I do:

    Client (WebDav client) --> WAP --> IIS --> File Server

    I have read over and over again about SNI but I must be missing something. The client is a Windows 10 Pro machine and all servers above are Server 2016.

    I have done some network captures and noticed that the client is sending the server_name extension in the Client Hello so I'm a bit thrown off with the SNI part. From what I read, I thought the WebDav client wasn't SNI-capable.  Am I missing something there?

    I have already configured a fallback wildcard certificate on 0.0.0.0:443 for either the Federation AppID or the WAP AppID and neither fixed the issue. I've also configured the ADFS server the wildcard certificate for failback on 0.0.0.0:443 because some articles mentioned it needed to be done on all ADFS and WAP servers.

    EIther way, I'm not seeing the TCP reset after the Client Hello as discussed here (https://blogs.technet.microsoft.com/applicationproxyblog/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2/). 

    Am I missing something somewhere? I'd assume this would be a pretty straightforward config once authentication is proven out from start to finish.

    Wednesday, December 14, 2016 4:46 PM

All replies

  • User-663891294 posted

    Hello, what does "break" refer to in this case? A TCP Reset being sent from one side? How far does the SSL Handshake get during the TCP handshake? Also, which client is being used to access WebDAV, Windows Mini Redirector?

    Wednesday, December 14, 2016 9:18 PM
  • User-738597541 posted

    Hey milope! Thanks for your help again.

    In this case, "break" is just referring to the WebDAV client connecting successfully when pointed directly to IIS. When the WebDAV client is pointed to the WAP, it "breaks" by not completing the connection. Instead, it comes back with Error 224 ("Access Denied. Before opening files in this location, you must first add the web site to your trusted sites list, browse to the web site, and select the option to login automatically.")

    As for the TCP and SSL parts. I'm not seeing a reset on either side. Also, To me, it looks like SSL is fully established but I could be wrong. It does look like it happens twice but that might be part of an auth challenge response?

    Here's the client's view:

    Here's the server's view:

    And for the client, it is the Windows Mini-Redirector. Version 10.0.14393 to be specific.

    Wednesday, December 14, 2016 10:00 PM
  • User-738597541 posted

    And here are the details of the server_name extension in both the Client Hello and Server Hello messages.

    Client Hello:

    Server Hello:

    EDIT: The value for ServerName in the Client Hello is correct too. It's the external FQDN (ex: mywebsite.contoso.com).

    EDIT #2: The server is responding with the correct cert (ex: mywebsite.contoso.com) as opposed to the wildcard cert configured for fall back (0.0.0.0:443) which tells me SNI is actually happening, right? Also, I was able to verify that there are two connections on purpose. As soon as you click "Connect" the client establishes the first connection, then you are prompted for credentials, when you click OK in the credential box, it creates the second connection.

    Wednesday, December 14, 2016 10:08 PM
  • User-663891294 posted

    Which server is the server trace from, WAP or IIS? I'm assuming IIS == WebDAV in this scenario, btw.

    Wednesday, December 14, 2016 10:45 PM
  • User-738597541 posted
    My apologies. That is from the WAP server and you are correct, IIS==WebDAV. That IIS box is hosting the WebDAV site.
    Wednesday, December 14, 2016 11:13 PM
  • User-663891294 posted
    To rule out SSL, unless the last hop is not SSL, I would get a network trace of that last hop. Otherwise everything looks good from one side. It'd be also worth getting a Failed Request Trace along with running a procmon on the final hop to see what account is used for WebDAV and rule out possible permission issues.
    Thursday, December 15, 2016 4:21 AM
  • User-738597541 posted

    Alrighty... I did a network trace on all endpoints in this scenario (except for a DC). I had a capture on the client, WAP, ADFS, IIS, and CIFS servers. I never see communication beyond the WAP when using the Mini-Redirector. If I use a browser, I see the auth request go to the ADFS server, it authenticates the client, and then it looks like it hands back to the WAP who then proxies the connection back to IIS where it is accepted. The two look totally different. 

    I'm wondering if this is something to do with WAP/ADFS doing forms based auth. When running Fiddler on the client, I can see a 403 error with "X-Forms_Based_Auth_Required" and a "X-Forms_Based_Auth_Return_Url" that is "https://mywebsite.contoso.local/?context=MSOFBA".

    Thursday, December 15, 2016 3:09 PM
  • User-738597541 posted

    Okay... so if I disable ADFS for pre-auth and just do pass-through, it works. In a bit of research, I've been seeing that the WebDAV mini-redirector doesn't handle MSOFBA? Is this still the case? Doesn't the mini-redirector work with SharePoint Online which uses forms-based authentication right? I really wanted the auth to happen at the WAP.

    Thursday, December 15, 2016 3:31 PM
  • User-738597541 posted

    So I got it all to work using HTTP Basic pre-auth instead of "Web and MSOFBA" pre-auth and I enabled Basic authentication on the IIS/WebDAV server. It's working. Pre-auth happens at the WAP w/ ADFS so that makes me happy. I'm not happy about it being Basic. It is HTTPS all the way through (Client -> WAP -> IIS) but Basic auth always makes me uneasy.

    I'll have to do some more digging though. It looks like it's Basic from the client to the WAP to the IIS box. I was hoping the WAP would have done Kerberos back to the IIS box after it used basic authentication with the WebDAV client.

    Thursday, December 15, 2016 4:15 PM