locked
Windows Application Proxy WWW-Authenticate bug RRS feed

  • Question

  • I have a Web Application Proxy that publishes multiple kerberized non-claims-aware applications with ADFS preauthentication to have SSO. I've set the ADFSUrl endpoint on the proxy to /adfs/ls/wia to direct the users to windows integrated, so that Kerberos is used where it can be (BYOD excluded). In this scenario, Windows Application Proxy does everything OK except for joining the "WWW-Authenticate: NTLM" and "WWW-Authenticate: Negotiate" headers into a single "WWW-Authenticate: Negotiate,NTLM" header, which should be technically correct according to RFC, but the browsers choose to ignore it (tested on a simple custom aspx page that yields only a 401 with "WWW-Authenticate: Negotiate,NTLM" - the login prompt does not pop up).

    Is there a way to disable NTLM on ADFS, so that only Negotiate is sent? That would be OK, because Negotiate itself has an NTLM fallback in it.

    If not, is it possible that Microsoft would fix that?

    My scenario consists of non-claims-aware applications, so all traffic must go through the proxy, but some clients are domain-joined inside internal network, so they can use Kerberos. BYOD clients are also on the internal network, but not domain joined, so NTLM fallback would be nice. This doesn't include extranet, as a separate proxy server with standard forms auth will be used for that.

    Friday, August 12, 2016 2:18 PM

Answers

  • I was assuming that the devices were domain joined since you wanted to perform SSO using Windows Integrated Authentication.

    Non Domain Joined machines do not have SSO in the first place, so there is no challenge brought by the HTTP header you mentioned earlier. However, you are right, those are the challenge. Because they are connected on prem but still you wish they could have Form Based Authentication. These are the options:

    • Split brain DNS for BYOD, possible thanks to DHCP for example. Some customers do not let the BYOD clients connect to their own network, for these it is easy to publish a different DHCP option for the DNS. Or if your domain joined assets are Windows 8 or higher, you could use a NPRT, make DJ assets point to a different DNS server for this specific namespace (which would point to the split DNS) and let others use the regular one (which would be set to point to resolve the FQDN of the farm to the WAP).
    • Play with the user-agent strings. You control what UAS will accept and try Windows Integrated Authentication. So you have several scenario. You can advertise that only IE will have SSO for example. And then non domain joined assets have to use IE if they want SSO (or another one, but communicate about it). Or, because you are just one GPO away to modify the UAS of all your DJ assets, you could create a custom one such as "MY DJ BROWSERS" and configure ADFS to play WIA only for this UAS and redirect to FBA for the rest. So the one that never applied the GPO would have FBA.

    Note that GPO are a very common way to reduce administrative overhead.

    Note that the original post was about a header of WAP. This play no role in this story. The fact that BYOD devices have no SSO is not a Windows issue, nor a WAP issue, nor an ADFS. Windows Integrated Authentication Single Sign On is a feature of domain joined assets.

    • You could also Workplace Join your BYOD devices to obtain a persistent MSISAuth cookie (aka WebSSO cookie) that they will be prompted only once a week for credentials (validity time is configurable) giving them an impression of SSO.

    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.

    Monday, August 22, 2016 12:57 PM

All replies

  • "I have a Web Application Proxy that publishes multiple kerberized non-claims-aware applications with ADFS preauthentication to have SSO"

    The purpose of publishing non-claim aware applications with Kerberos Constraint Delegation is not to provide SSO. It is just to make authentication possible without modifying the application authentication mode (which would be a major change for the application). If you publish an application using Kerberos as-is on the internet, users' experience will not be ideal (either prompted or just not working). It is also not meant to be used by internal clients. Internal clients already have SSO provided by Kerberos given that they can reach domain controllers.

    "My scenario consists of non-claims-aware applications, so all traffic must go through the proxy"

    Domain joined clients should reach the applications directly, without the hop through the proxy.

    BYOD clients connected locally will also have to reach out the application directly. And they will be prompted by their browser (depending on the configuration of the browser).

    I might have missed the point, so please tell me if any of this makes sense.


    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, August 12, 2016 10:15 PM
  • Any update?

    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.

    Tuesday, August 16, 2016 12:06 AM
  • Hi,

    my specific scenario looks like this:

    The network environment has several claims-aware applications that use ADFS and several kerberized non-claims-aware applications. The user experience is:

    For a non domain joined machine (BYOD) or firefox not configured to allow kerberos:
    1) log on to the machine
    2) log on to one of the claims-aware applications
    3) doesn't have to log on to the other claims-aware applications due to SSO
    4) log on to each non-claims-aware application individually

    For a domain joined machine with a browser that uses kerberos by default:
    1) log on to windows
    2) doesn't have to log on to claims aware applications
    3) doesn't have to log on to non-claims-aware applications

    Now I have added Web Application Proxy and published the non-claims-aware applications. The user experience is:

    For BYOD or firefox:
    1) log on to the machine
    2) log on to any application
    3) everything else (claims-aware and non-claims-aware) uses SSO

    For domain joined:
    1) log on to windows
    2) log on to any application
    3) everything else uses SSO

    As you can see SSO works great, but because I added the proxy to the network, all requests to the claims-aware applications are also routed through it. This forces forms authentication and the domain-joined users can not take advantage of kerberos.

    Allowing Windows Authentication on the proxy or being able to define Extranet in other way than "comes from the proxy" would solve my problem.

    Tuesday, August 16, 2016 6:24 AM
  • The WAP is not meant to be used by internal clients.

    There are scenarios where it could be a good idea IF you want form based auth on non domain joined devices seating on prem (but this is not your scenario).

    Non-claim aware applications should use the WIA application directly because they can, they already have SSO! The WAP IS NOT meant to be used as a proxy for internal clients when publishing non claim aware app. This is why the header doesn't have the value you are expecting and can't have the value you are expecting.

    You request in asking if it is a bug. No it is by design, it is not meant to be used this way.


    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.


    Thursday, August 18, 2016 2:44 PM
  • Too bad ADFS with WAP does not offer SSO for non claims aware applications. Firefox in its default configuration does not use kerberos - even ADFS without proxy pops up a WIA dialog (falls back to NTLM) on firefox, while IE and chrome use the credentials you logged into the domain joined machine with. That's why Kerberos is not considered an SSO solution for my client. I was hoping to address that with your product, but looks like I need to find something else.

    Sorry for the mixup.


    Thursday, August 18, 2016 7:15 PM
  • Your issue here is not an ADFS nor a WAP issue. It is a configuration issue of your Firefox browser.

    Fix the browser


    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.

    Thursday, August 18, 2016 8:53 PM
  • I'm aware of this configuration setting, but telling each and every user on the network to change that is not what would be considered a professional approach. The problem could be solved with an authentication proxy that authenticates the firefox user with NTLM, performs S4U and replies to 401s for that user with kerberos. WAP does most of that, but unfortunatelly, when youforce windows authentication on it, it messes up the WWW-Authenticate header. Like you said it will not solve my client's problem.
    Friday, August 19, 2016 6:14 AM
  • "I'm aware of this configuration setting, but telling each and every user on the network to change that is not what would be considered a professional approach."

    Since we are talking about domain joined assets, you can look at enterprise ways to deploy settings on Firefox via group policy (either by pushing a config files, or by using a custom ADM or ADMX). Or if you already have an agent pushing stuff on the workstations, it could be leverage to. I would definitely explore that path.


    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, August 19, 2016 10:36 PM
  • What about non domain joined machines that are still in the internal network (as I said in my first post, we also have those - as in BYOD - bring your own laptop) like people who brought their own laptop or VPN users? Because there are non-domain-joined machines in the internal network, we can't use split-brain DNS to tell them to use the proxy, while domain joined machines use the other side of the split-brain. Because of this even internal domain joined users would see adfs.domain.com as the proxy, which would show them a login form - this is the biggest issue, as it degrades the existing SSO experience for domain joined machines. Would be great if I could deploy two proxies and make one of them the intranet proxy (with WIA) and the other one an extranet proxy (published outside, with forms auth).

    The only solution (other than finding a better proxy) I would see here is having another DNS, so:
    public internet facing DNS
    internal all devices DNS (configured by DHCP)
    internal domain joined DNS (configured by GPO in Computer Configuration/Policies/Admin Templates/Network/DNS Client/DNS Servers or through a logon script)

    This might work as intended, but creates a significant management overhead by adding a third DNS server.

    Monday, August 22, 2016 8:27 AM
  • I was assuming that the devices were domain joined since you wanted to perform SSO using Windows Integrated Authentication.

    Non Domain Joined machines do not have SSO in the first place, so there is no challenge brought by the HTTP header you mentioned earlier. However, you are right, those are the challenge. Because they are connected on prem but still you wish they could have Form Based Authentication. These are the options:

    • Split brain DNS for BYOD, possible thanks to DHCP for example. Some customers do not let the BYOD clients connect to their own network, for these it is easy to publish a different DHCP option for the DNS. Or if your domain joined assets are Windows 8 or higher, you could use a NPRT, make DJ assets point to a different DNS server for this specific namespace (which would point to the split DNS) and let others use the regular one (which would be set to point to resolve the FQDN of the farm to the WAP).
    • Play with the user-agent strings. You control what UAS will accept and try Windows Integrated Authentication. So you have several scenario. You can advertise that only IE will have SSO for example. And then non domain joined assets have to use IE if they want SSO (or another one, but communicate about it). Or, because you are just one GPO away to modify the UAS of all your DJ assets, you could create a custom one such as "MY DJ BROWSERS" and configure ADFS to play WIA only for this UAS and redirect to FBA for the rest. So the one that never applied the GPO would have FBA.

    Note that GPO are a very common way to reduce administrative overhead.

    Note that the original post was about a header of WAP. This play no role in this story. The fact that BYOD devices have no SSO is not a Windows issue, nor a WAP issue, nor an ADFS. Windows Integrated Authentication Single Sign On is a feature of domain joined assets.

    • You could also Workplace Join your BYOD devices to obtain a persistent MSISAuth cookie (aka WebSSO cookie) that they will be prompted only once a week for credentials (validity time is configurable) giving them an impression of SSO.

    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.

    Monday, August 22, 2016 12:57 PM
  • The whole environment consists of users who are:
    - on the internal network and domain joined (company owned workstations)
    - on the internal network and not domain joined (private laptops, mobile devices)
    - outside - only they use the public part of split-brain, which doesn't know about our internal services

    And services:
    - SAML1, SAML2... which already use ADFS
    - SVC1, SVC2... which have Kerberos only

    The users on the internal network already access claims aware applications through ADFS. The domain joined ones don't see any authentication prompts, because ADFS uses WIA with Kerberos. The non domain joined ones log into SAML1 and then don't have to log into (enter the login and password for) SAML2, because ADFS provides SSO through its cookie.

    The users who are on the internal network who access SVC1 and SVC2 don't see authentication prompts for SVC1 and SVC2, because of Kerberos. The users who are not domain joined see authentication prompts for both SVC1 and SVC2.

    I want to make SVC1 and SVC2 to use ADFS through Web Application Proxy, so that when you log into one of them (or SAML1 or 2) you don't have to log into the other, because ADFS would accept the SSO cookie and authenticate without prompting for credentials again. Works well with forms - you have to enter credentials only once and if you select Keep Me Signed In it persists when you restart the browser.

    I deployed Web Application Proxy in my test network, but it forces Forms Authentication even for domain joined users who are accessing SAML1 and 2, because I also have to set adfs.domain.com to WAP IP address. So this is a degraded experience for domain joined users.

    I tried to tell WAP to use WIA by configuring it with Set-WebApplicationProxyConfiguration -ADFSUrl https://adfs.domain.com/adfs/ls/wia. This causes the request to the published https://web1.domain.com/ service to be redirected correctly to /adfs/ls/wia??version=1.0&action=signin&realm=urn%3AAppProxy%3Acom&appRealm=f94e6681-c25f-e611-80c4-000d3a21f680&returnUrl=https%3A%2F%2Fweb1.domain.com%2F&client-request-id=27568390-F948-0000-EC83-562748F9D101 so it seems to work fine. Unfortunatelly, the WWW-Authenticate header in 401 contains "Negotiate,NTLM" to which the browser does not respond. If only it could respond with separate WWW-Authenticate headers, it would work just fine and I could deploy one WIA web application proxy for internal users and one default configuration proxy for extranet. This would help us avoid deploying a third DNS server and messing around with GPOs.

    The BYOD clients must have access to internal resources (they RDP to our virtual machines), that's why a third DNS is needed for this setup.

    I hoped that addressing the WWW-Authenticate header issue would let me implement this as is without making the underlying network infrastructure more complex.

    Monday, August 22, 2016 1:43 PM
  • I understand the scenario. It is common to face the challenge of WIA prompt/FBA with BYOD connected devices on prem. And these have been discussed in the forum previously. However, WAP is not the way to proceed.

    You are trying to fix a workaround which should not be used in the first place.

    The suggested workarounds of my previous post are legit. They are used in the field, they do work. While not ideal because it sometimes requires extra configurations. BUT this is because of BYOD, not because of ADFS, WAP or federation in general. When a company decides to accept BYOD, yes it will be add some overhead and challenges, switching to a highly controlled environment to a totally uncontrolled one. This is what we try to address with some of our products. In that space, Device Registration Services (Workplace join a device) is a part of our solution. Quite frankly the most common challenges with BYOD I discuss onsite are security/compliancy related not SSO. Besides, why would you like SSO on a device for which you do not control the level of security, update and compliance. SSO implied some sort of cached credentials on - sometimes - shared devices. These are quite challenging too (even with workplace joined devices). Microsoft provides interesting solutions around managing BYOD thanks to Intune and Azure AD. Do they fix your problems of SSO? Not necessarily. They just might if we are talking about Windows 10 and Passport. But it might just not. And other service providers also have their BYOD management providing solution to some level.

    Note that other users of this forum are facing the same issue. They also need to find the guidance reading through our thread. I hope they can get the full extend of this, this is why I am often kind of repeating or rephrasing things. I do hope that I have provided you with the adequate level of information to opt for a deployment path in your situation.


    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.

    Monday, August 22, 2016 2:09 PM
  • Thank you for your insights. We will be looking into implementing the three way split brain configuration. The debate on this subject is so complicated because the end client doesn't care about IT and technical details. They want convenience and they want it their way, so even if I explain the security implications, at the end of the day they want me to do my job the way they want it.

    On one hand I have the software vendor (Microsoft), who goes on the security side and on the other I have my clients, who want to go to the convenience side.

    Again, thank you for your time. This discussion helped me a lot. I will keep all that in mind in my future projects.

    Tuesday, August 23, 2016 7:58 AM