locked
Connecting to Web Services Over VPN RRS feed

  • Question

  • One of our apps uses a wide variety of authentication methods to call web services, and Enterprise Authentication is enabled, but when users connect via the same connections when on over a VPN connection (for example) the connections will always fail authentication.

    For example is a service URL is a SharePoint web service, using Basic authentication, it's fine via the Web and via our app, but if you connect via VPN it will always fail via the app, but Web is still fine. We have a hunch is may need Digest authentication in this scenario (not 100% sure, but likely) but it seems as though the WinRT namespaces have AllowImpersonationLevel REMOVED for HttpDigest. This is available in the full .NET Framework.

    So the question is a) Is it correct to assume that we need to try via Digest when tunneling through VPN, and if so, HOW do we tell the proxy/client to dynamically use Digest in code? The error is always:

    The impersonation level 'Identification' was specified, yet HTTP Digest authentication can only support 'Impersonation' level when used with an explicit credential.

    This setting can be change for ClientCredentials.Windows, but NOT on ClientCredentials.HttpDigest.

    Thoughts? Again, ALL we need to do is figure out HOW and WHAT changes when tunneling through a VPN. The headers via Fiddler look exactly the same.


    Scott J. Peterson, MCSD, MCPSB, MCT

    Saturday, October 5, 2013 12:38 PM

Answers

  • This ended up being an issue with the VPN Client itself and not related directly to our app. The VPN Client Provider had another product that worked correctly with Windows Store apps. All good, and all my efforts were in the wrong direction. Existing code worked flawlessly when VPN Client was changed. Thanks!

    Scott J. Peterson, MCSD, MCPSB, MCT

    • Marked as answer by Scott Peterson Tuesday, October 8, 2013 12:50 PM
    Tuesday, October 8, 2013 12:50 PM

All replies

  • Are you confident that the requests are reaching the server?
    If you needed digest authentication, then the webserver would be configured for it, and you would get a 401.2 response code because you're not passing the correct authentication scheme to the webserver in the web request.

    My belief is that you're not taking the same path to the webserver because of the VPN configuration.  That path is doing something very different.  You would need to capture network traces on the server and the client to between a good request and a failing request and compare the two.  This is not trivial work and I recommend that you open a support case for this issue.


    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    If my reply answers your question, please mark this post as answered.

    NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

    Monday, October 7, 2013 1:32 PM
    Moderator
  • This ended up being an issue with the VPN Client itself and not related directly to our app. The VPN Client Provider had another product that worked correctly with Windows Store apps. All good, and all my efforts were in the wrong direction. Existing code worked flawlessly when VPN Client was changed. Thanks!

    Scott J. Peterson, MCSD, MCPSB, MCT

    • Marked as answer by Scott Peterson Tuesday, October 8, 2013 12:50 PM
    Tuesday, October 8, 2013 12:50 PM