Kerberos authentication

Question

Pleased to see that Kerberos authentication has made it into v18, as STAS has proved challenging. 
 Can somebody confirm it will replace (or remove the need for) STAS entirely and also STAC for those that use Citrix? 
 Thanks, 
 RF

Michael Dunn · Accepted Answer

First of all, I am not an expert in STAS or SATC. Archtectually I know how they work, operationally I do not. 
 Rockfish said: Thanks for the detailed reply. I'd be interested to understand why customers would choose STAS over Kerberos if it is available? 
 I'm going to throw the question right back at you. As a customer, why did you chose STAS over NTLM? NTLM and Kerberos are very similar and have a lot of the same benefits and drawbacks. If you considered NTLM and decided against it, why? The same reason may apply for Kerberos. If you never considered NTLM, why? The same reason may apply for Kerberos. 
 STAS vs AD SSO (irregardless of NTLM or Kerberos) 
 STAS effectively is asking the AD Server "What user at this IP?" AD SSO (Active Directory Single Sign On) is effectively asking each IP "What user are you?" 
 AD SSO works great for browsers and any application which makes internet connections that implements proper authentication. But maybe you have xyz software that comes bundled with an updater that periodically goes to xyz.com to get software updates. And that updater was not built to handle authentication. Requests that come in the middle of the night come as unauthenticated requests and that stupid updater doesn't know how to speak NTLM/Kerberos so it fails to update. 
 The way AD SSO (NTLM or Kerberos) works is that once you are authenticated, your login is cached for some time (default ~5 min) and all traffic from that IP is assumed to come from the same user. So if you are using a browser (which knows how to authenticate) and your stupid updater runs, the updater is allowed because the user is cached. 
 The point being that STAS effectively is communication between one XG and one AD server. AD SSO (NTLM or Kerberos) is communication between one XG and thousands of applications running on hundreds of clients. STAS is a single point of failure with high impact- which unfortunately fails often for some admins. AD SSO is a thousand points of failure but the impact is quite low - and it will fail all the time. 
 Notice how I don't say Kerberos, I say AD SSO. Because whether the client application sends credentials via NTLM to the XG or the client application sends a kerberos ticket to the XG, it is still the client application knowing how to authenticate. 
 As a separate issue, AD SSO is a web technology. It authenticates HTTP and HTTPS traffic, sets the user for that IP, and then all traffic from that IP is that user (such as SSH sessions or TCP connections to a Clash of Clans server on some high level port). AD SSO requires there to be web traffic to do the authentication. STAS is not a web technology. It can associate users and IPs even if there is no web traffic.

Michael Dunn · Answer

Rockfish said: 
 I take the point regarding STAC, and that a Citrix environment is a different challenge - but I would have thought that if Kerberos is supported, it'd be no different for a Citrix user to authenticate with the XG than it would be with a file share or printer? 
 
 SATC vs AD SSO (irregardless of NTLM or Kerberos) 
 Now for SATC. I know what you are thinking because there were a bunch of internal people hoping the same thing as you - that Kerberos would help in Citrix environments. Unfortunately due to some... fundamental design issues it won't. 
 The XG is a "user aware firewall". That means the user is part of the decision making process of choosing which firewall rule to apply. That basically means that the user needs to be known before the firewall chooses which firewall rule to apply. When a new TCP connection is made from internal IP going to some external IP, the only way for the firewall to know what firewall rule to apply is to look up the internal IP in a cache to find out the user on it. Authentication in XG fundamentally requires a user-to-IP cache in order to make user-aware firewall rules apply. 
 So what happens with AD SSO? Client application makes a connection on port 80/443, firewall says there is no user and flags the web proxy to please authenticate the user. Web proxy talks Kerberos to the client, authenticates the user, and puts it in the user-to-IP cache. Now that that point the current connection was initially made with no user and the firewall rule was chosen based off of no user. The only way to "re-evaluate" the firewall rules with the newly known user is to drop the connection and let it reconnect. So that is what AD SSO does. The client reconnects and the firewall now see the cached IP and knows what user it is, applying the correct firewall rule. 
 Now you bring Citrix in, multiple users on one IP. UserA authenticates, XG associates IP with UserA and drops the connection. UserA reconnects and does traffic and the firewall logs UserA. Then UserB connects from same IP and does some traffic and the firewall thinks it is UserA. Problem. 
 So what SATC does create an out-of-band communication channel from Citrix to the XG. Every time that a Citrix user does network traffic, SATC tells the XG who the user is on both the IP and the source port. Now the XG can differentiate different users on the same IP because SATC tells them which user is using which port. 
 Now we introduce Kerberos. So what? Kerberos is an AD SSO mechanism. If you start using Kerberos then after the user is authenticated it drops the connection and waits for a new connection from the same IP so that the user-aware firewall can re-evaluate rules. You are back at the original AD SSO problem because that means you need to associate an entire IP with a single user. 
 But lets pretend that you somehow magically solve this by breaking the whole "user aware firewall" and not re-evaluating rules. Now say someone on the citrix server make a SSH connection to an external server. It is not authenticated, but SSH does not speak kerberos, therefore kerberos cannot authenticate the connection. If you rely only on Kerberos to authenticate (and remove SATC) then you basically are in a situation where all non-web traffic can never be authenticated (must always be allowed unauthenticated). This is because Kerberos is HTTP/HTTPS only and because you are not allowed to cache user-to-IP like you do for other computers.

Michael Dunn · Answer

Kerberos is a very different method than STAS. There are environments where STAS may still be the better option. 
 Most customers using NTLM will switch to Kerberos. By default upgraded customers will still use NTLM (reduce change) but I recommend all NTLM environments consider switching. 
 Some customers using STAS will switch to Kerberos. Any STAS environments will need to evaluate whether Kerberos serves their needs. However in general, if they have already chosen STAS over NTLM, they will choose STAS over Kerberos. 
 STAS will continue to exist for customers who want to use it. 
 
 When using Citrix there is a the problem where many users are coming from the same IP, and Kerberos does not change that. SATC is still the solution there.