Using Windows Integrated Authentication through ADFS Proxy RRS feed

  • Question

  • Good afternoon!

    I'm currently working on a project that uses ADFS to authenticate domain users to a third-party cloud proxy.  Our organization has an internal ADFS server that is used for ADFS authentication inside our network and we have an ADFS Proxy that is used for authentication from outside of our network (we use split-brained DNS).  

    Here's how we expect things to work for a domain-joined system (and how it works when inside the network):  A User opens a browser and goes to an external website.  Traffic goes to the external proxy (which is an authenticated service).  The Proxy checks the traffic, sees that the user isn't authenticated, and redirects them to ADFS.  ADFS uses Integrated Windows Authentication to pass credentials and automatically authenticate the user.  ADFS passes the user automatically back to the proxy which authenticates and passes them to the external webpage they were going to.  The entire process is completely automated, no need for user interaction.

    However, when a user is outside the network, going through the ADFS proxy, we notice something different.  User opens a browser, goes to a webpage, proxy sees that the user isn't authenticated and passes to ADFS.  ADFS then presents the user with Form-Based authentication.  And this is the issue.

    The user can type in their credentials manually and authenticate through just fine, however we'd rather this authentication be completely automated (using Integrated Windows Authentication).  I've been scouring articles trying to find information on why this might be happening, but I couldn't seem to find much on this.  Can anyone give me a clue as to why this isn't working?  My guess is something to do with Kerberos, but I'm not really sure where to start looking with that.

    Any help would be greatly appreciated.  Thanks!

    Tuesday, July 26, 2016 6:37 PM

All replies

  • This is by design.

    Users in the extranet are not domain joined and hence cannot use IWA becuase they have no Kerberos ticket.

    So they have to use FBA.

    Tuesday, July 26, 2016 7:11 PM
  • Thanks for the reply, that does make sense.

    But what if the systems *are* domain joined?  Many of our users have Laptops that are joined to our domain and log in to their laptops using domain credentials even when not on our local network.  Is it *possible* to do IWA from the outside?

    ~Jeeves Murphy

    Tuesday, July 26, 2016 7:17 PM
  • I don't think it would work


    "– The reason why we stick to form based authentication when going via the proxy is because it just requires the SSL port 443 to be exposed. We cannot do Windows Integrated Authentication over the internet, because the ports and services required for it cannot be exposed to the internet."

    in case IWA in the back end is Kerberos Authentication, do you really want to extend your internal domain authentication to internet, seeing Kerberos authentication over the wire, will give your security admins quite a nightmare.

    Tuesday, August 2, 2016 1:47 PM
  • This is unfortunate. Over the internet you can still fall back to NTLM and no additional ports need to be open.

    Also, consider the following scenario:

    1. You have multiple Kerberized LOB applications
    2. You want to make them use ADFS - because SSO cookies for clients that support NTLM, but don't handle Kerberos well or are on the internal network, but not domain joined, so fall back to NTLM. Think BYOD.
    3. You add WAP to your intranet and publish these non-claims-aware applications

    The result is that even though you still restrict access to internal network, your users are considered external, only because they go through an "authentication proxy". It would be nice if we could define Extranet as clients from outside an IP range (+ specific hosts, like other proxies).

    Wednesday, August 3, 2016 1:06 PM