Establishing a Connection with the K2 Server

A connection can be made with the K2 server from many different sources, including both K2 and non-K2 applications. Some examples of connection sources are:

When the connection is attempted, it may be a direct connection or the connection may have been delegated via another machine. Direct connections use integrated (AD) or some other form of authentication. Delegated must use Kerberos or K2 Pass-Through Authentication (K2PTA).

Kerberos vs K2 Pass-Through

If Kerberos has not been configured, there is a possibility that the credentials will be lost as they are delegated through application layers, in particular when the number of physical machines in question increases. The primary reason for this is that the application layers do not have valid credentials from Active Directory because of the double-hop authentication problem. The most obvious evidence of this is an anonymous user error is displayed or logged when a client application on one machine attempts a connection with another domain machine and the connection is refused.

Since the credentials would normally only be lost on the second hop (i.e. the second machine-to-machine delegation) K2PTA can be requested.

As described above, the credentials would normally lose context on the second hop, for example when the IIS server attempts to place a call to the K2 server, but the credentials come through as anonymous and no valid Windows token is present on the thread.

K2PTA is only available on the second hop, such as when the K2 client APIs contact the K2 server. When this takes place, there is one of two possible outcomes:

  1. When the connection is made via the K2 client APIs, they gather information relevant to the user. If these credentials are the same as the user on the K2 server, then the APIs are successful in passing the credentials in the same manner as Kerberos or NTLM, allowing a successful log-on.
  2. If however, the information that has been gathered about the user is not the same (this could be because of an anonymous error or the thread is not executing as the same user), delegation fails and the call does not succeed. For this scenario, the details of the original user are passed to the K2 server and they are used instead.

Connection Pass Through

A 'hop' refers to when credentials are passed from one machine to the next. In most cases the first hop takes place between the client and service (or server) of some kind.
The diagram below illustrates a single hop, (but this only applies to non-distributed installations where passing of credentials is not a problem), NTLM is used and the credentials succeed.

In the diagram, the credentials are passed twice, from client to the IIS Server and then onto the K2 server. This is a double hop and represents a typical scenario in which the K2 server is contacted, and (unless Kerberos is properly configured) is also where K2PTA is useful.

In the first step, NTLM is used to authenticate between the client and the IIS Server. This could be the K2 Workspace machine, for example. However, when the IIS server needs to place a request to the K2 server, this crosses the physical machine boundary and the IIS service does not have the authority to pass these credentials. Without Kerberos or K2PTA, an anonymous error would occur.
Double Hop

A virtual machine is still considered as a physical machine since it introduces the logical machine boundary barrier.

The triple hop limitation comes into effect when there are too many machines located either before or after the K2 server in the sequence of credential passing. If the K2 server is the third machine in line (or a web service or SQL Database is the third machine away from the K2 server), this causes a delegation failure and credentials are not passed. Also, in this triple-hop scenario, Kerberos is needed to negotiate the credentials in a secure manner.

In this scenario, the hop between the web service and the K2 server means that the context of the user has been completely lost and, in this instance, K2PTA cannot be used. This is because the identity of the user and their credentials are lost before they reached the K2 server, and the K2 server cannot recover the identity because it is coming through to K2 as anonymous without any additional detail.

The reverse is also true, where credentials are passed to a custom web service successfully using NTLM, but when the web service tries to pass those same credentials onto a 3rd-party system, for example SQL Server, a delegation error takes place.

K2PTA only comes into effect in relation to the K2 server and K2 components. The triple-hop limitation is not a limitation of K2PTA per se, but a limitation of the extent to which K2PTA  can be leveraged to ensure that credentials are passed from machine to machine. When you're dealing with triple hops or more, Kerberos must be configured.
Triple Hop Limitation