Kerberos authentication

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.

Michael,

Thanks for the detailed reply. I'd be interested to understand why customers would choose STAS over Kerberos if it is available?

In our environment, STAS can be (despite many configuration tweaks) a little hit and miss. We have had scenarios where the user account has been located in the event log, and added to the STAS live users DB, but the user still cannot authenticate successfully against the XG. In most of these cases, restarting the STAS service will fix the problem.

Am I right in thinking that Kerberos would effectively be single sign-on, and that the users wouldn't need to manually authenticate with the XG?

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?

RF

Michael,

Thanks for the detailed reply. I'd be interested to understand why customers would choose STAS over Kerberos if it is available?

In our environment, STAS can be (despite many configuration tweaks) a little hit and miss. We have had scenarios where the user account has been located in the event log, and added to the STAS live users DB, but the user still cannot authenticate successfully against the XG. In most of these cases, restarting the STAS service will fix the problem.

Am I right in thinking that Kerberos would effectively be single sign-on, and that the users wouldn't need to manually authenticate with the XG?

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?

RF

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.

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 is one of the few devs here that take times to explain how things work.

I was aware of the Windows authentication mechanism since Terminal services on Win2003. It is a not a XG fault. The SATC uses a nice mechanism to link IP, User and those information to XG which can apply the proper user policy.

Thanks Michael again for your effort here and in the code dev. As I said in another thread, Web protection is one of the best implemented feature in XG.

To sum this up, Kerberos is not like in UTM the one way to go in each case. Simply because UTM uses Kerberos only for Web. 

XG interacts user based in all matters. So you need always the be able to interact with the User. 

That is one of the biggest benefits of STAS vs AD SSO. 

It is not the one weapon against every setup. As far as i would expect, like Michael, most customer will not move. 

Maybe the Web Only Users (Use XG as web proxy only), will consider AD SSO over STAS.