Kerberos 401 authentication with form fallback

I found when refreshing the page, it is falling back to form based logon screen.

So I have just added the below java script to "HTTP response message"

<script>
location.reload();
</script>

Screenshots are provided for your reference

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.

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.

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.

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.

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.

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.

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).

bumping this as it has been a while since there was activity.. but we are running into the same problem and are on version 14.

Why would APM 401 decide to issue this message "Authentication required to access the resources." and STOP the entire policy evaluation??

It should exit on 'fallback' and provide the access policy to continue and decide what to do..

Other things mentioned (to do some tests BEFORE issuing the 401) seem to be nothing more than a workaround to not get stuck on the 401 and it's ABORT of the policy.

This just makes something that should be so simple very very complicated ... simple .. negotiate/Kerberos fail.. go to fallback.. let the policy issue a login form.

I set to basic+negotiate and it will follow the basic path for the user but we don't want to issue the basic credentials box.. We want to issue the login form if it isn't able to authenticate using Kerberos.

Before I open a case with support, I am seeing if there are some others who have gone down this path and any other advise.

Much appreciated!!!

To be honest, I didn't test the solutions that are suggested here in the various answers of this post, but I've worked out a workaround. The workaround I've created uses javascript and the HTML5 Web Worker technology to determine if a browser is willing to perform Kerberos authentication. If so, it will proceed to authenticate the user by using Kerberos authentication. If not, it will fallback to another authentication method, like SAML for example. You can find my solution here:

https://devcentral.f5.com/s/articles/APM-Kerberos-Auth-or-fallback-to-another-authentication-method

https://devcentral.f5.com/s/articles/Transparent-Kerberos-Authenticaton-and-APM-fallback-authentication