Kerberos 401 authentication with form fallback

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?

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.

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

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.

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 ?

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