Kerberos Authentication with K2 Servers

Kerberos authentication is a type of Integrated Windows Authentication that allows delegation of user credentials across multiple servers, allowing a server to pass the credentials of the user to another server or service. In contrast, NTLM, another type of Integrated Windows Authentication, can only pass user credentials to a single server, which is typically between client and server. You run into the NTLM "double-hop" problem when a second server requires those credentials. If you've installed all K2 components on a single server environment, you can use NTLM. However, in a distributed environment where K2 components or supporting technologies are installed on different servers on the network, you need Kerberos authentication . An alternative to Kerberos is K2 Pass-Through Authentication (K2PTA), but this may not be suitable in all scenarios. See the K2PTA topics for more information.

You only need Kerberos when there is the potential for two or more hops, like having a your web server separate from your K2 server, for example as seen in the Distributed Environments supported topology topic. You do not need Kerberos in a scenario like in the Single Application server, Separate SQL Server supported topology topic.
The following notes are based on customer support issues that may pertain to your environment. For more information read Kerberos Authentication Overview for Windows Server 2012 (https://technet.microsoft.com/en-us/library/hh831553.aspx).
  1. When searching for SmartObjects to create a BDC Application, the Central Administration AppPool account needs to delegate credentials to K2 and must be configured to use Kerberos authentication. This is typically not a problem if the portal site has been configured to use Kerberos and the Central Administration site uses the same AppPool account as the portal site. Configure the Central Admin AppPool account to use Constrained Delegation with Protocol Transition.
  2. It is sometimes necessary to configure the SSRS AppPool account to use Constrained Delegation when delegating credentials to the K2 host server to get reporting data. Using Full Delegation it fails with a 401.

The information in this section is based on the following assumptions:

  1. The administrator or person responsible for configuring Kerberos is familiar with the K2 installation documentation.
  2. K2 Server and other components have been successfully installed.
  3. K2 Configuration Analysis tool has been run and completed successfully.
  4. K2 Server can be started up successfully.
  5. SQL Server and SQL Reporting Services are running properly.
  6. SharePoint Server is running properly (if applicable in the environment).

Kerberos configuration can occur either before or after the installation of K2. The configuration of K2, which occurs directly after installation, allows for the automatic setting of the K2 Server SPNs.

K2 supports a variety of installation configurations, including single server, distributed and server farms.

  • Single Server Installation
    All the K2 components, dependencies and prerequisites are installed locally on the same physical machine, with the exception of the SQL Server, which can be installed on a remote or adjacent physical machine.
    Kerberos is not required in a single server environment. However we recommended using Kerberos authentication if K2 solutions will be migrated and deployed to a distributed system environment such as for testing and production.
  • Distributed Installation
    K2 components, dependencies and prerequisites are installed on multiple servers across a network. Kerberos must be configured for a distributed installation to function correctly.
  • Server Farm
    A K2 server farm is a clustering environment for multiple K2 Host Servers. There are multiple vendors offering solutions for system clustering and load balancing. Configuration for clustering and / or load balancing systems is beyond the scope of this article.

The following server components and web services require Kerberos authentication when K2 is installed in a distributed environment. Some specific K2, SQL and SQL Reporting Service, and SharePoint rights are discussed as they pertain to successfully using the feature or service. In some cases, Kerberos and K2 Impersonation are required for user authentication and for the server or service to act on the users behalf.

The diagrams in the Reference Information and K2 Platform Architecture section of the K2 Developer Reference, depict the communication flow of a typical distributed environment. Be aware that although this will give you a better idea how K2 components communicate, it may not be representative of your specific environment, and because of that you will need to verify with your network experts the exact nature of the communication flow in your environment.

See the K2 Developer Reference topics (K2 Five Architecture, K2 Five Communication Flow) for this and more architectural diagrams of the K2 platform.