kerberos authentication: who am I?

Question

So I'm not a big fan of STAS, NTML, SSO or heartbeat authentication. What can I say, I'm a hater. Anyway - kerberos has been introduced in this version but I don't really know how to "get it going". I've enabled the AD SSO authentication, enabled SSO under device access for LAN, disabled the STAS service on my DC and then done some testing. So far it just looks like NTLM standard browser authentication that only works in IE. 
 What's new, what should I expect from the new kerberos stuff?

RichBaldry · Accepted Answer

Thanks all for the feedback on this thread. I can see we need to revisit the documentation around this before GA. 
 To address some of the points on this thread, here's a brief explanation of what our support for Kerberos involves. 
 Under the hood, web-based authentication has three steps: 
 1. There is the challenge from the firewall to the browser, requesting that the browser provide credentials. 
 2. The firewall authenticates those credentials. 
 3. If successful, the firewall caches the fact that the authenticated user is associated with that source IP 
 This fundamental mechanism has not really changed in v18 from the method called 'NTLM' in v17.x. 
 What has changed is in step 1, we support an additional way for the browser to provide the credentials, and in step 2, we can use that method to validate those credentials. In version 17.x, NTLM was the only protocol we supported, and in version 18, we support a hybrid challenge that allows the client to specify either NTLM or Kerberos credentials. 
 Because the mechanism called 'NTLM' now supports more than just NTLM we renamed it 'AD SSO'. We also grouped it together with Captive Portal under the heading 'Web Authentication' because all those authentication methods work by capturing and redirecting web traffic and using the browser either transparently or interactively to provide credentials. 
 The HTTP-defined method for challenging the browser for Kerberos credentials is via a challenge known as 'Negotiate'. This challenge fundamentally supports a range of different authentication protocols - NTLM, Digest, etc. To disable NTLM authentication, it is way better to disable it in the AD settings. Now that SFOS supports Kerberos, it is possible to do that. In version 17.x, we used a different challenge that was specific to NTLM. 
 Configuring AD SSO (including Kerberos) 
 1. When you join your XG to the AD server, it will do all it can to ensure that Kerberos will work, including setting a service principal name for itself in the Active Directory system. This does mean that the hostname of the device needs to be properly configured before joining, and the device needs to be configured to use its hostname when redirecting browsers to authentication challenges. This hostname-related stuff is configured in Administration > Admin settings. 
 
 One you've set up the device host name, you can go through the additional steps: 
 2. Configure the AD Server in Authentication > Servers 
 3. Ensure your AD Server is set as the primary service for Firewall authentication methods under Authentication > Services 
 4. Ensure AD SSO is enabled for the relevant zones in Administration > Device access 
 
 5. Ensure that 'Kerberos and NTLM' is selected under Authentication > Web authentication 
 Now, any web traffic that matches a firewall rule requiring authentication, and that is not already authenticated by this or another method, will be subject to AD SSO authentication, which will generally use Kerberos for preference.