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

I don't immediately see how it's possible to tell if a PC is able to authenticate without asking it via a 401, which produces a browser auth pop-up. Is there anything in the initial HTTP request that you can use to tell this class of clients from the other class of clients?

Well, perhaps you could use Group-Policy IEM tool to modify the User-Agent and show the 401 to only those guys via some simple VPE logic? But they would have to use only IE, unless there is some way to do this with Firefox to a group of PCs.

https://technet.microsoft.com/en-us/library/cc770379.aspx

The solution works but I still have Firefox prompting for credential first. If I cancel it switch back to Kerberos. Any way to force Firefox to use Kerberos prior to basic auth ?

JoeTheFifth,

What do you mean by adding all spns ?

You can "overload" the keytab file by using the -in option with ktpass:

ktpass -princ  -mapuser  -ptype KRB5_NT_PRINCIPAL -pass 'password' -in  -out c:\keytab.next

You'd run this command for each SPN, adding the resulting key information to the last keytab file.

If you want to avoid the initial 401 response you have to configue IE and Firefox for that

Even if you put the URL in the browser's trusted intranet sites list, I believe (specifically for Kerberos) that the browser still makes an initial anonymous request.

I think we're mixing (client side) AAA and (server side) SSO here. Totally different things.

For client side, you create a keytab file that contains the key (or keys) for the SPN(s) that browser clients will be accessing. In your case you have a single site, so you have a single hostname in the keytab file.

For server side, you don't use a keytab. Server side Kerberos uses Protocol Transition and Constrained Delegation. CD allows APM to do S4U2Proxy - proxied Kerberos, and PT allows APM to do S4U2Self - which is how it doesn't rely on client side Kerberos to function. Server side Kerberos requires basically 2 things:

• Access to a KDC - to fetch delegated Kerberos tickets to an application. This implies rights to (an account) and a path to (DNS SRV and direct access).

• The name (SPN) of the account to request a ticket to. This is sometimes the hardest to achieve depending on the nature of the services, but can generally be defined in one of three options:

   

  • A static SPN value (ex. HTTP/servers.mydomain.com@MYDOMAIN.COM) - where all of the target web servers are running under the SAME service account, so no need to have APM try to go figure it out.
  • The %s option (ex. HTTP/%s@MYDOMAIN.COM) - where APM uses reverse DNS from the selected pool member IP to get the name used in the Kerberos ticket request. This would usually be where the servers are each owned by their respective machine accounts. This could also rely on a local Hosts file in lieu of DNS.
  • The %h option (ex. HTTP/%h@MYDOMAIN.COM) - where APM simply uses the client's HTTP Host header as the name to use in the Kerberos ticket request.

The important thing to understand here is that client side and server side Kerberos are completely independent things. Protocol Transition makes server side Kerberos possible as long as you have the two previously-defined things (access and a name).

I can't find the QOUTE button so I'm replying to this: Even if you put the URL in the browser's trusted intranet sites list, I believe (specifically for Kerberos) that the browser still makes an initial anonymous request.

yes. That's the normal behaviour. See the blog above:

Before diving into both Kerberos and NTLM request/response flows, it's worth noting that the vast majority of HTTP clients (browsers, apps, etc.) don't send any credentials on their first request for a resource. This means that first request is anonymous, even if credentials have been configured for that resource. This anonymous request, when Windows Auth is enabled and Anonymous Auth is disabled in IIS, results in an HTTP 401 status, which shows up as "401 2 5" in the normal IIS logs. Both request flows below will demonstrate this with a browser, and show that it is normal.

I don't have an issue with that. My only issue for the moment is using multiple servers with a site configured to run under a user account.

Hi Stanislas. Do you confirm this works for non-domain users? Like I said earlier the 401 pop up will occur for browsers who do not trust the url/hostname. I don't see how this can work for user (domain or non domain) without putting the url in the intranet trusted zone (ex IE). I understand internal users (domain) get the trusted url configured but that's not the case for non domain or external users. Are you external users trusting the url/hosname?

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

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!!!