< class="prominent-subhead ">

Basic Guide to enabling a K2.net® 2003 Implementation to use Kerberos Authentication

This article has been archived, and/or refers to legacy products, components or features. The content in this article is offered "as is" and will no longer be updated. Archived content is provided for reference purposes only. This content does not infer that the product, component or feature is supported, or that the product, component or feature will continue to function as described herein.

Kerberos authentication is a form of Windows Authentication that allows delegation of credentials through multiple application layers and across multiple servers – unlike NTLM, which will pass user credentials through one layer only. Therefore, if you have set up K2.net 2003, IIS and other 3rd party applications like SPS on multiple servers and need to pass user credentials throughout, you will have to make sure Kerberos authentication is working.

Article Contents


Configuring Active Directory

Configure K2.net 2003 Server

Configure SQL Server 2000

Configure IIS

Testing the Configuration

Implementation Discussion


The name "Kerberos" is derived from Greek mythology. Cerberus is the Latin variant of Kerberos. Kerberos the three-headed watchdog that guards the entrance to the lower world or Hades. It is a child of the giant Typhon and Echidna, a monstrous creature herself, being half woman and half snake. Originally, the dog was portrayed having fifty or hundred heads but was later pictured with only three heads (and sometimes with the tail of a serpent). Cerberus permitted new spirits to enter the realm of dead, but allowed none of them to leave. Only a few ever managed to sneak past the creature, among which Orpheus, who lulled it to sleep by playing his lyre, and Heracles, who brought it to the land of the living for a while (being the last of his Twelve Labors.

Like the mythical creature, the Kerberos security system guards electronic transmissions that are sent across the Internet.
Kerberos is a mature network authentication protocol designed to provide strong authentication for client/server applications by using shared secret-key cryptography.

Kerberos authentication is a form of Windows Authentication that allows delegation of credentials through multiple application layers and across multiple servers - unlike NTLM, which will pass user credentials through one layer only. Therefore, if you have set up K2.net 2003, IIS and other 3rd party applications like SPS on multiple servers and need to pass user credentials throughout, you will have to make sure Kerberos authentication is working. Kerberos authentication can either be implemented in a constrained delegation model (i.e trusting specific user/service accounts for delegation and using these accounts to run the applications) or in a full delegation model (i.e trusting machines for delegation and using the Local System or Network Service accounts to run the applications). It is however, the responsibility of each individual client to determine the best delegation model, whether it is constrained delegation or full delegation, that will satisfy the needs and constraints for their respective organizations.
Note: The following article is a "How to" explanation on configuring Kerberos Authentication. Owing to the complexity and potential for incorrect configuration, we recommend that only senior technical staff be enlisted or at least consulted with while configuring this authentication model.

How or when would I know if my Kerberos configuration is not functioning as it should?
When the K2.net 2003 Workspace or the K2.net 2003 Server, running in console mode displays that an anonymous user logged in when you have specified a user, or a NULL users credentials set is passed to K2.net 2003 Server. This serves as the first sign that Kerberos is not configured to work with K2.net 2003 correctly.
Examples of common authentication errors relating to Kerberos and Delegation
K2.net Service Manager (Console Mode)
  • Anonymous login transactions
Internet Explorer Web Pages
  • "401 - Access Denied"
  • Service Unavailable
K2 Workspace
  • Login displayed as "NT AUTHORITY \ ANONYMOUS LOGON"
  • Multiple Login prompts when attempting to access the K2.net Workspace
The errors indicate that the "Delegation" settings must be configured. By default, the system is not trusted for delegation.
Important: Making changes to the Authentication model for your network is the responsibility, and at the risk of each individual client. It is the client's responsibility to determine the best delegation model, whether it is constrained delegation or full delegation, which will satisfy the needs and constraints for their own company. This article merely provides the information required to implement the changes.

Delegation is where a service is configured to impersonate either a user account or computer account which then gives the service access to resources on the network. The delegation may be set to be trusted for any service (Full Delegation) or for specific services (Constrained Delegation) only.

To configure the delegation option of your choice, follow the steps outlined in this article.

Back to Top 

Configure Active Directory
To implement Full Delegation, all systems in Active Directory running K2.net 2003 components need to be configured for "Trusted for Delegation" (This may also include the Domain Controller).

The systems which would commonly require configuration include the IIS Server and the K2.net 2003 Server.
Note: Depending on your network architecture you may also need to enable "Trusted for Delegation" on the SQL Server as well.

To access this setting, open "Active Directory Users and Computers" and go to the "Computers" and "Domain Controller" sections. You can then right-click each computer and check the "Trusted for Delegation" option on the "Properties" dialog.

To implement Constrained Delegation, all Active Directory User / Service accounts that are used to run Services and Application Pools also need to be "Trusted for Delegation". ("Trust this user for delegation to any service (Kerberos only)").This setting is accessible from the "Account" tab of the user's properties in Active Directory. "Account is Sensitive and cannot be delegated" must NOT be enabled for any account used to run any service.
Note: AD needs to replicate before changes can take effect - this may take some time. The default setting is every 3 hours. It is possible to force replication Active Directory by using the repadmin tool that is part of the Windows Server 2003 Support Tools or as part of frsdiag from Microsoft Downloads File Replication Service Diagnostics Tool (FRSDiag.exe)

The Active Directory database must be replicated or shared between the domain controllers. The data replicated between controllers is also called the "Naming Context".

Active directory uses a multi-master model, so changes made on one controller are replicated on all controllers; when amendments are made to one of the domain controllers only the changes are replicated between controllers and not the entire database. The replication path in Active Directory forms a ring which adds reliability to the replication. To implement Kerberos authentication, a service must register its name. The registered name is called a Service Principal Name (SPN) and the name is registered under the account that the service is running under in Active Directory. For full delegation, Active Directory by default registers the NetBIOS, or computer name, and allows the NetworkService or LocalSystem account to use Kerberos and therefore, no SPN's need to be registered. If the K2.net 2003 Workspace Service or a WEB Service connecting to the K2.net 2003 Server are in an Application Pool that is running under a specific User / Service Account, (i.e. constrained delegation not using the Network Service/Local System accounts), that user/service account will require an SPN (Service Principal Name). If a host header is used, your site is referenced by a Windows Internet Name Service (WINS) or Domain Name System (DNS) and that name is not the same as the computer name of the server running IIS, or your application uses a port other than the default, an SPN needs to be registered.
Follow the steps below:
  1. Obtain the "Setspn" utility via internet download and install it on the Domain Controller. Use the URL specified below to obtain the utility.

    Microsoft Download Center: Setspn.exe

  2. If you do not have internet access, the "Setspn" utility is also available from the Support Tools folder on a Windows 2003 Server installation CD
  3. Once you have installed the utility, open a command prompt window and navigate to the directory in which this tool has been installed.
Note: Ensure that you are logged in as a domain administrator to add SPN's to AD. Alternatively, the command prompt must be run under a user with domain admin rights.
Enter one of the following commands, i.e. select only one option.
Option 1Application Pool running under a specific user account and the web site not using Host Headers:
 setspn -A HTTP/computer.domain.local Domain\User
setspn -A HTTP/computername Domain\User Note:  "computer.domain.local" is the fully qualified name "computername" or the NETBIOS name.
Option 2Application Pool running under a specific user, account with the web site using Host Headers:

setspn -A HTTP/hostheader.domain.local Domain\User
setspn -A HTTP/ hostheader Domain\User
Option 3Application Pool NOT running under a specific user account and the web site using Host Headers:
 setspn -A HTTP/hostheader.domain.local computername
setspn -A HTTP/ hostheader computername
Option 4Application Pool NOT running under a specific user account and the web site not using Host Headers:
 Do not use setspn

Back to Top 

Configure the K2.net 2003 Server
The user account, under which the K2.net 2003 Server Service is run, also needs to be configured with a Service Principal Name (SPN). This step can however be performed automatically from the K2.net 2003 Service Manager using the "K2.net Service Account" tab of the Server's "Properties".

Add the K2.net Server to Active Directory by clicking on the "Add" button.
Note: Ensure that the K2.net 2003 Service Manager is started by a user with Domain Admin rights. If the user logged onto Windows does not have these permissions, do the following.
Right-click on the K2.net 2003 Service Manager and select "Run as."
Enable the "The following user" radio button and enter the account name of a user that has rights to add an SPN to Active Directory.

It would also be advised that the "Log On As." account be an account that is trusted for delegation in Active Directory, (see above), rather than the Local System account.

No additional configuration is required specifically for the K2.net 2003 server for Kerberos to function. However, one additional configuration setting may be applied at the discretion of the reader as a simple configuration verification indicator.

The K2.net 2003 Server Registration in K2.net 2003 Service Manager may be configured to only use Kerberos. This setting, once enabled is useful to verify that the Kerberos configuration is functioning correctly.

The K2.net Service Account Settings can be confirmed after configuration when clicking "Ok" after changing the settings:
  • If the security package is set to "Kerberos" and no error message is returned after you clicked "OK", K2.net 2003 Server is successfully communicating with the SQL server using Kerberos.
  • If an error message does appear, please ensure that the steps as described in Part 1 of this document were followed and that enough time has elapsed for the Active Directory to replicate
Note: Remember that replication may take a few minutes - even hours, depending on the Active Directory settings.

Configure SQL Server 2000

Configuring the SQL Server to run as a "Local System", (and using TCP/IP), is the simplest method to ensure that the SQL Server will work correctly with Kerberos.

If this method is not chosen, the alternative would be to configure an SPN and trust Service accounts for delegations. This was done previously and can be configured in the same way as was done for K2.net 2003 Server in 1.1 above.

Back to Top 
Configure IIS
  • If the WEB Server is the same physical system as the IIS server the following section's configuration may not be required.
  • If the IIS's physical machine is not the same as the domain controller, the following Services will require configuration to enable Kerberos:
The Web Server/s containing the K2.net 2003 Workspace, web services and Smartforms, (as well as SharePoint if you are using the K2.net 2003 Task List Web Part), will need to be set up to enable Kerberos.
Note: If the IIS Server is the same physical machine as the Domain Controller, no configuration is necessary.
If the IIS Server and K2.net 2003 Server are on different servers, the IIS server needs to be "Trusted for Delegation" in Active Directory.
To configure the IIS Server do the following:
  • Open "Active Directory Users and Computers" and go to the "Computers" section
  • Right-click on the necessary computer and enable the "Trusted for Delegation" option on the "Properties" dialog
For more detailed information, see the section Configuring Active Directory in this article.
The IIS Metabase requires configuration to ensure that it will attempt to pass user account credentials using Kerberos. Firstly, configure IIS so that it is not necessary to stop IIS. An IIS reset will however be required once the configuration is complete.

To configure the ISS Metabase, do the following:
  • Right-click on the server name and select "Properties" in IIS v6.0
  • Enable the "Enable Direct Metabase Edit" checkbox
Configuring the Metabase (Recommended Method)

Admin Scripts should be used to set the required values in the IIS metabase. This is done as follows:
  1. Click "Start>Run>"
  2. Type "cmd" in the Input field labeled "Open" and then press enter
  3. At a command prompt, navigate to "C:\Inetpub\Adminscripts"
  4. Type the following commands:
    1. cscript adsutil.vbs set w3svc/NTAuthenticationProviders "Negotiate,NTLM"
    2. cscript adsutil.vbs set w3svc/xx/NTAuthenticationProviders "Negotiate,NTLM"
(Where "xx" is the ID of the web site you want to set, (the Default Web Site will be "1").
In section "4", "1" refers to the IIS Website Server and "2" to the Website folder. Ensure that both "1" and "2" are executed.
Note: "Negotiate,NTLM"is case sensitive.
Editing "Metabase.xml" (Method is discouraged)
If the file "Metabase.xml" is available at the location"%Systemroot%\System32\Inetsrv", then set all instances of "NTAuthenticationProviders="NTLM" to be NTAuthenticationProviders="Negotiate,NTLM".
This value will exist in that file for each web site on the Web Server,

Confirm the following settings. Once you have confirmed them, IIS should be restarted:

In IIS v6.0; configure the Application Pools under which the relevant Web Sites/Applications run as either a system account ("Network Service" or "Local System"), or as a user account configured correctly in Active Directory (as described in the section Configuring Active Directory)
Note: A specified user must belong to the "IIS Worker Process Group" (IIS_WPG) on the IIS local machine if he is in an application pool. If the user is not part of the group, the following error will occur once you try to execute the IIS application.
Note: If the IIS_WPG is added to this list, then the user is already added to the policy and this step is not necessary.

The system account used under the above-mentioned application pool must be added to "Impersonate a client after authentication" under "User Rights Assignment" in the local Security policy (on the IIS Server).
Note: If the IIS_WPG is added to this list, then the user is already added to the policy and this step is not necessary.
Ensure that the correct SPNs have been configured set up as per section Configuring Active Directory. If the web site has host headers set up, the SPN has to be set up for the PC name or Application Pool user with the host headers. A DNS resolve is done when the site is called and this is a Kerberos Authentication hop.
Finally, another important point to keep in mind is to ensure the following lines of code are in the "Web.config"file, (under the "system.web" node), of the ASP.NET application running on the configured IIS Server:
<authentication mode="Windows"/>
<identity impersonate="true"/>

Back to Top 
Configure Client Web Browsers

Verify that the "Enable Integrated Windows Authentication" option is enabled.

Do the following:
  1. From within Internet explorer, click "Tools>Internet Options>Advanced"
  2. Scroll down until you locate the option "Enable Integrated Windows Authentication" option
  3. If the option is disabled, enable it.
If this is disabled, it won't be possible for the servers to generate a Kerberos token. With IE6, the default setting is that Integrated Windows Authentication is enabled.

Include the workspace web server address/host header address to the "Local intranet" zone for the Client Browsers. This setting will log a user in using the current username and password. If not configured this way, "NT AUTHORITY\ANONYMOUS LOGON" will be displayed as the user name, even though Kerberos is configured correctly.


To insert the Address / Host Header, do the following from the Internet Browser :
  1. Click "Tools>Internet options"
  2. Click on the Security Tab and then locate the "Local intranet" icon
  3. Click on the button labeled "Sites"
  4. Click on the button labeled "Advanced"
  5. Enter the Workspace web server Addres/Host header in the format e.g. " http://hostheader.domain.com" or "http://workspaceserver.domain.com"
  6. Click "Add"
  7. Click "Ok" to save changes and to exit until you return to the Browser

Back to Top 
Testing the Configuration
The simplest test for the use of Kerberos is to use the K2.net 2003 Server in Console mode to verify that user credentials have been passed.
Alternatively, any one of the following methods can also be used:
  • Security Audits (in Event Viewer)
  • SQL Profiler
  • Kerbtray Application
(The Kerbtray application can be downloaded at the following link: )

Microsoft Download Center: Kerbtray.exe

Note: that this test scenario assumes that the environment is of such a nature that the client, IIS server and K2.net 2003 server are three different physical servers.
What follows is some simple code to test whether different applications can in fact communicate over the network:
  • Using Visual Studio 2003 create a new project
  • Once the project has been created add a reference to the K2ROM in the Web Application
  • Place a button and a label control on the page.
  • Use / Import SourceCode.K2ROM.
Using SK = SourceCode.K2ROM;
Imports SK = SourceCode.K2ROM
Add the following key to your K2.net "Web.config" file
<identity impersonate="true"/>
Place the following code (C# and VB.NET samples shown below) in the "Click" event of the button
Note: Replace #K2SERVERNAME# with the K2.net 2003 Server name and #WORKLISTNAME# with the Worklist to open (i.e. "ASP").
SK.Connection CN = new SK.Connection();
string K2Server = "#K2SERVERNAME#";
string WorklistToOpen = "#WORKLISTNAME#";
string LoggedOnUser = Request.ServerVariables["AUTH_USER"];
Response.Write(LoggedOnUser + "<BR>");
Response.Write(CN.User.Name + "<BR>");
catch (Exception ex)
Response.Write("Error opening connection : " + ex.ToString());
SK.Worklist worklist;
worklist = CN.OpenWorklist("ASP");
if (worklist.Count > 0)
lblLabel.Text = "Worklist Count: " + worklist.Count;
lblLabel.Text = "Worklist is empty";
catch (Exception ex)
Response.Write("Error polling activity : " + ex.ToString());


Dim CN As New SK.Connection
Dim K2Server As String = "#K2SERVERNAME#"
Dim WorklistToOpen As String = "#WORKLISTNAME#"
Dim LoggedOnUser As String = Request.ServerVariables("AUTH_USER")
Response.Write(LoggedOnUser & "
Response.Write(CN.User.Name & "
Catch ex As Exception
Response.Write("Error opening connection : " & ex.ToString)
End Try
Dim worklist As SK.Worklist
worklist = CN.OpenWorklist(WorklistToOpen)
If worklist.Count > 0 Then
lblLabel.Text = "Worklist Count: " & worklist.Count
lblLabel.Text = "Worklist is empty"
End If
Catch ex As Exception
Response.Write("Error polling activity : " & ex.ToString)
End Try


Once you have added the code to your project, run the project. When the button is clicked, the code will perform the following tasks:
  1. Display the logged-on user's name
  2. Connect to the K2.net 2003 Server, and again return the name used by IIS to log onto the K2.net 2003 Server. The two names should be identical
  3. Next, the application will attempt to open the Worklist of the given user. The label, (lblLabel), will display the number of items currently waiting in the user's Worklist

The above test checks the credentials passed to IIS from the client, from IIS to the K2.net 2003 Server, and the connection between K2.net 2003 Server and the SQL Server.


Open the IIS Server Security Log. You will see the credentials passed from the client to the IIS Server, and the credentials IIS uses to log onto the K2.net 2003 Server. Ensure that this is correct.

Back to Top 
Implementation Discussion

In the following scenario, a complex K2.net 2003, IIS, SPS and NLB setup is in play. The physical setup looks as follows:
The above illustrated scenario works as follows:
  • XP Client connects to the NLB (
  • The NLB decides' through its filtering algorithms which of the two IIS servers will handle the work load.
  • The IIS server handling the request connects to the NLB (, which in turn decides through its filtering algorithms' which of the two K2.net 2003 servers will handle the work load.
In the case of SPS - for the above scenario SPS is only installed on one of the two IIS servers ( running under a different port and using a host header. SPS has the K2.net 2003 Web Part which returns the user's work list. This scenario works as follows:
  • XP Client connects to the IIS server on the port specified in IIS for SPS using a host header.
  • The IIS server connects to the NLB ( which decides through its filtering algorithms which of the two K2.net 2003 servers will handle the work load.
To set up the above scenario, follow these steps:
Important: In the steps below, we will be referencing the names and IP addresses as described in the image above.
K2 Installation:
Note: That the K2Server nodes (physical servers) need to be able to communicate directly with each other. NLB takes ownership of one NIC (Network Interface Card) and for that reason we need to install a second NIC on each node to enable the nodes to communicate.
For more information regarding NLB, see the KB Article entitled "K2.net® 2003 Scalability, Clustering and Sizing".
K2.net 2003 Server NLB:
Affinity = None
K2.net 2003 Workspace NLB
Affinity = Single
Create host entries for the NLB Clusters in DNS
NLB Configuration - K2WSClust.K2Train.local example:
The two Nodes are:
  • K2Trainwww
  • K2Trainwww-02
Cluster Parameters:
Kerberos Configuration for the above setup:
In AD, create the following accounts. Each account will be used for the accompanied object
  • K2.net Server: K2Train\K2ServerAcc
  • K2.net Workspace: K2Train\K2WSAcc
  • SharePoint: K2Train\SPSService
In the two IIS servers create an application pool on each, using the above created user account as the application pool's identity. Please see the following for more information:
Application Pool: K2WSAppPool
Identity: K2Train\K2WSAcc
Add K2Train\K2WSAcc to IIS_WPG Group
Application Pool: K2WSAppPool
Identity: K2Train\K2WSAcc
Add K2Train\K2WSAcc to IIS_WPG Group
Note: IIS_WPG group is part of the local server groups.
In Active Directory, trust the following computers for delegation:
  1. Now create an SPN for the K2.net 2003 Server
  2. Open K2.net 2003 Service Manager on the K2.net Server PC
  3. Click on the K2.net Service Account tab
  4. Log on as: K2Train\K2ServerAcc
  5. Click Add to create the SPN's
Note: The K2.net Service Account tab will only be available if you are using Service Manager on the local K2.net Server.

Only have to do this for one of the two K2.net Servers

Testing the SPN
Edit the Server Registration and select Kerberos as the security package

Create SPNs for each of the IIS Servers

setspn -A HTTP/K2Trainwww k2train\k2wsacc
setspn -A HTTP/K2Trainwww.k2train.local k2train\k2wsacc

setspn -A HTTP/K2Trainwww-02 k2train\k2wsacc
setspn -A HTTP/K2Trainwww-02.k2train.local k2train\k2wsacc

Update the IIS Metabase for each of the IIS Servers
cscript adsutil.vbs set w3svc/NTAuthenticationProviders "Negotiate,NTLM"
cscript adsutil.vbs set w3svc/1/NTAuthenticationProviders "Negotiate,NTLM"

cscript adsutil.vbs set w3svc/NTAuthenticationProviders "Negotiate,NTLM"
cscript adsutil.vbs set w3svc/1/NTAuthenticationProviders "Negotiate,NTLM"
To get Website number (1), please see earlier in the document
Note: Reset IIS when done.
Set SPN for the K2.net Server Cluster (See "Important" box below)
NLB Cluster: K2Clust.K2Train.local
setspn -A K2Server2003/K2K2Cluster k2train\k2Serveracc
setspn -A K2Server2003/K2K2Cluster.k2train.Local k2train\k2Serveracc
Important: The name of the K2.net cluster must be prefixed with "K2" eg "K2[K2ClusterName]".
Note: K2.net Service Manager created the following SPNs in a previous step.
K2Server2003/K2K2TrainK2-01 K2Train\K2ServerAcc
K2Server2003/K2K2TrainK2-01.K2Train.Local K2Train\K2ServerAcc
These SPNs are no longer required, as the cluster SPN will now perform their task. You can now remove these SPNs by using the setspn -D command (see setspn -? Command for more details).
Trust the following accounts for delegation in AD:

Note: The delegation tab will only be available once a valid SPN exists for the account.


Note: The K2WSAcc user account was added to the local IIS_WPG group in a previous step. This group will have the "Impersonate client after authentication" rights by default.
Now check whether the IIS_WPG group has the "Impersonate client after authentication" user rights on the Local Security Policies of K2TrainWWW & K2TrainWWW-02.
  • Open Local Security Policies
  • Go to: Local Policies>User Rights Assignment
  • Open: Impersonate a client after Auth.
  • Make sure IIS_WPG is added to this list. If not, add the local IIS_WPG group to this list
Set up SPS and K2.net Task list:
  • Change SPS Application Pool Identity
    • K2Train \ SPSService
    • Add K2Train \ SPSService to IIS_WPG Group
  • Update IIS Metabase
    • cscript adsutil.vbs set w3svc/421112413/NTAuthenticationProviders "Negotiate,NTLM"
    • To get Website number (421112413), please see earlier in the document
  • Create SPN's for Host Header: SPS
    • setspn -A http/sps k2train\spsservice
    • setspn -A http/sps.k2train.local k2train\spsservice
  • Create SPN for IIS cluster
    • NLB Cluster: K2WSClust\K2Train.local
    • setspn -A http/k2wsclust k2train\k2wsacc
    • setspn -A http/k2wsclust.k2train.local k2train\k2wsacc

Back to Top 

"Negotiate,NTLM"is case sensitive.