Kerberos 401 authentication with form fallback

It’s actually not that simple, and not really an APM issue. The problem is that there’s no event to fire on. When the client (browser) receives the 401, it has to do something. It’ll either try to satisfy the negotiate request, or fail. And if it fails, it doesn’t send anything back to the server, hence nothing for the server (APM) to trigger on.

The prescribed workarounds usually involve making sure the client *can* authenticate, often by making sure they’re on the right network (by source IP).

No, not what I'm saying. When the server sends its 401, it's also going to send one or more "Authorization" headers, which can either have a value of "Basic", "NTLM", or "Negotiate" (which means Kerberos or NTLM). The browser uses this information to decide how to authenticate. For example, if only a Basic authorization header is sent, the browser can only respond with Basic credentials. If it gets a Negotiate, and it's a member of a domain, it'll try Kerberos or NTLM (with a preference for Kerberos). If, however, it cannot satisfy any of these, it will just fail. It won't send anything back to the server. It won't ask for other options. It will just fail.

And since there's no request from the browser if it fails, there's no event for the server (APM) to respond to. APM cannot follow a fallback branch, simply because the client didn't send any request. You can actually see this if you fire up Developer tools in your browser (or Fiddler). It doesn't matter if it's Edge, Firefox, Chrome, whatever. This is how all browsers behave with Windows Integrated Authentication. That you're setting negotiate+basic, and the browser selects Basic, means that the browser itself can't satisfy the negotiate request, so falls back to Basic.

Thanks again, Kevin. Appreciate all you are sharing.

So then, we have devices that are not joined to the domain.. or are not setup for Kerberos. Before the 401 query, is there something that can be done to check to see if the client/client browser is joined so a 401 negotiate is only done when they are able to respond?

Our current situation is that some devices don't have a policy that provides for this and they should be presented with a login form by APM.

Think I will open a support ticket to see what they might be able to suggest.

You can but it you need a few requirements:

Add the web app hostname or a wildcard domain name like *.mywebapp.com to the intranet zone (ie, chrome) or trusted.uris (firefox). Safari is out of the game here sorry. All devices should do this even people not in your AD domain. This won't work for people coming from the internet but will do for partners coming from an internal network and using your AD domains or a trusted domain.

Now you need an ECA Profile enabled on the VS.

This also requires an NLTM configuration with an computer object created in you Active Directorry.

This way all devices will need to do an NTLM challenge with this computer (F5 computer object created in AD) and you will have to use an iRule to decode the NTLM message and get the user/domain info.

All allowed domains (datagroup list or inside the irule) for which you don't need an APM login page wll do an sso login (automaric login). All the domains not in the allowed list will be redirected to the APM login page.

It's not a straightforward task but I have it all set up and running.

For mobile devices you use certificates to check for allowed domains then either do an apm page or Kerberos sso based on what you get from the device. If no client certificate then go to an apm login page.

That's just it. There are a number of options here. JoeTheFifth is talking about computer checks - the computer or mobile device identifies itself, and you use that information to decide whether or not to challenge the user. And that *usually* gets tracked as an IP address in a table.

If you can't manage the client devices though, the easiest option is to divide users by subnet. Authenticate-able users on one subnet, contractors and customers on another... That would be the simplest solution.

It's also possible to do "step-up" auth options. Gov customers will often do this. Bring all users to a non-auth landing page and let them choose how to authenticate - AD, client cert, user/pass. Whatever they click on triggers a secondary step-up mechanism. It's not transparent to the user of course, but a reasonable solution nonetheless.

Thanks all. Yes I agree, checking their IP can determine if the device is on the internal network. There are cases, however, where a device internal is not joined to the network and Kerberos 401 will fail.

It seems it could be possible to alter the response message that is displayed. It would be nice if this was a standard option. A few ideas better than issuing a simple 'Authentication required to access the resources" message. Not quite sure what the URL would be to continue the access policy 'fallback' or another branch on the 401:

1. Present a login page and the user can complete and submit to continue the access policy. This would provide a familiar set of information that the users are familiar with (the basic login tends to confuse people and not everyone trusts it as they don't know who is asking for their information).
2. Embed a link to a login page (somehow) <a href>. If there is a URL available that the user could click to respond back to the 401 and hit the 'fallback' or perhaps another custom branch of that step.
3. Meta http-equiv refresh to the response URL so the user would not need to click anything.
4. Javascript to handle a redirect to a login page.

Just seems there should be cleaner way to allow the user to proceed, especially when the SSO was initiated by the service provider.