Hello, we are using APM for SAML authentication. Domain joined machines should authenticate transparently with Kerberos, users without the ability to use Kerberos (non domain joined, Firefox without negotiate-settings) should receive a form to login. Kerberos works fine, but users with non domain joined machines receive a browser authentication prompt and "Authentication required to access the resources.". Does anybody has set up such a scenario? Any help is appreciated.

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

Hi Lucas, thanks for your response. I already thought about changing the User-Agent so that I can check for this header. For the moment, I could live with the 401 prompt, when I can display the auth form after canceling the 401 prompt. But no matter what I do, I receive "Authentication required to access the resources.", when Negotiate is enabled in the 401 agent.

One possibility is to combine an IP address check and a client check to say "if the client is internal and running Internet Explorer, then they can probably do Keberos; otherwise, show the web form". For failed 401 returning "Authentication required to access the resources.", I think that must be a bug -- if the 401 fails, it should follow the failure branch to e.g. web form.

Sorry, it's not a bug, but is not desirable/expected behaviour either. When APM sends the 401 Unauthorized, the HTTP response content is the error message defined in the APM HTTP 401 Response block. This defaults to "Authentication required to access the resources.". Instead we would want it to return something that caused the client and APM to advance down the fallback path, perhaps like an auto-submit form that caused the fallback path to be executed. I have submitted bug C2012278 to request such an enhancement to the HTTP 401 Response block.

Kerberos 401 authentication with form fallback

39 Replies

JoeTheFifth
Altostratus
Oct 16, 2018
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?
JoeTheFifth
Altostratus
Oct 08, 2018
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.
Kevin_Stewart
Employee
Oct 08, 2018
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).
Kevin_Stewart
Employee
Oct 07, 2018
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.
Alexandre_Allai
Nimbostratus
Mar 03, 2017
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
  Altostratus
  Oct 07, 2018
  By the way here is the flow of NTLM authentication to an IIS server:
  
  https://blogs.technet.microsoft.com/mist/2018/02/14/windows-authentication-http-request-flow-in-iis/
  
  IIS is a user mode application. It sits on top of HTTP.sys, which is the kernel mode driver in the Windows network stack that receives HTTP requests. IIS picks up requests from http.sys, processes them, and calls http.sys to send the response.
  
  IIS, with the release of version 7.0 (Vista/Server 2008), introduced Kernel Mode authentication for Windows Auth (Kerberos & NTLM), and it's enabled by default on all versions. This feature offloads the NTLM and Kerberos authentication work to http.sys. Http.sys, before the request gets sent to IIS, works with the Local Security Authority (LSA, lsass.exe) to authenticate the end user. IIS just receives the result of the auth attempt, and takes appropriate action based on that result.
  
  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.
  
  The NTLM and Kerberos exchanges occur via strings encoded into HTTP headers.
  
  If you want to avoid the initial 401 response you have to configue IE and Firefox for that. Chrome picks IE settings:
  
  Example: https://support.avg.com/SupportArticleView?l=en&urlname=How-to-configure-silent-authentication-for-SSO
- JoeTheFifth
  Altostratus
  Oct 07, 2018
  I'm probably missing something here. I have one web application with hostname webapp1.domain.com. The app is running on multiple servers with service account webappsvc@domain.com I have an spn for this service account HTTP/webapp1.domain.com. I generated the keytab file and configured the aaa kerberos server with thiskeytab and i put webapp1.domain.com in the server name. If I put webapp1.domain.com in the hosts file and point it to the ip of one web server the auth works fine. But I have many servers. In the case of kerberos sso with kcd you only need to put HTTP/% in the spn to tell the bigip to talk to one of the nodes in the pool. What do you mean by adding all spns ?
- Kevin_Stewart
  Employee
  Oct 07, 2018
  In the case where you have multiple sites resolving to a single VIP and (Kerberos) access policy, you'd either need to switch the access policies based on incoming client IP subnet, or overload the APM keytab file to include all of the SPNs and keys.
Stanislas_Piro2
Cumulonimbus
Feb 20, 2016
Hi, Did the solution provided by Evan and Saravanan solve your issue? I have the same need (kerberos for domain computers, SAML for others) and this is really helpful for all others to know if you got a solution. I tried the solution on my lab successfully but it's better to know if you validate for production users. Stanislas
Lucas_Thompson_
Historic F5 Account
Jan 15, 2016
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
- Nolan_Jensen
  Cirrostratus
  Aug 06, 2018
  AN,
  
  I don't have a answer for you but wanted you to know I originally reported this as working. However just had a report today that when I have a non domain joined computer connected to our network the browser will prompt for username and password. You have the configuration the same as I do so appears to be an issue.
  
  I can also confirm what Chris said if I cancel the browser login prompt I am then taken to my F5 login page and have no issues getting to allow ending.
- Rich_M_138850
  Nimbostratus
  Apr 15, 2018
  I have been trying to set this up but IE and Chrome on none domain pc's always prompt for credentials.
  
  If I change the javascript to alert() I see it runs after the authentication popup so not sure how this will work?
  
  If I cancel the authentication popup then the policy follows the fallback to the logon page but this won't be acceptable.
  
  Any ideas on pre logon checks to run when source ip will not be an option?
- Chris_Wentland
  Nimbostratus
  Nov 07, 2017
  Hey AN, are you still having issues with this functionality? I am working on an issue right now where IE and Chrome WERE functional, but have stopped working. What we've noticed is that the authorization window is still presented, but we can just cancel it, and authentication is successful. It may be related to a Microsoft bug MS16-119. Can you attempt to cancel the login and see if that works?
  
  Thanks!
  
  Chris Wentland