In some cases, it makes sense to setup constrained delegation with protocol transition for service accounts running websites (MOSS, ASP.NET client page custom applications, K2 Workspace) that connect to the K2 Host Server (and the web services included with K2 Workspace). We hear about users accessing those sites have logged into their laptops remotely (with their domain credentials) before initiating a VPN connection. These users’ client machines are unable to get a service ticket (TGT) from the KDC when authenticating with those web applications using Windows Integrated Authentication (Kerberos). Because we normally set the NTAuthenticationProviders node for the site to "Negotiate,NTLM", they will always authenticate against the site itself even if Kerberos authentication fails. When this (Kerberos authentication failure) happens, their user credentials are not authorized to be delegated to the K2 Host Server because they authenticated via NTLM, not Kerberos, as the metabase setting allows. Of course, we get the dreaded "NT AUTHORITY\ANONYMOUS" error in the K2 Host Server logs. It also is safe to say that this configuration gives a false sense of security, because if the authentication process scales down to NTLM upon a Kerberos authentication failure, the browser to web server communication authentication process is open to attack.
How do you setup constrained delegation with protocol transition? For the purposes of this example, I’m going to assume you have your SPNs (SPN=Service Principle Name) set correctly. For more information on this crucial step, please study the documents available (such as Security and Kerberos Authentication with K2 Servers on K2Underground).
Here’s an example of how to allow the domain service account setup to run the K2 Host Server to delegate credentials (with protocol transition enabled) to Kerberos enabled services running on that same account (it may seem counter intuitive, but it is required – particularly if Workspace is running under the same account as the Host Server). You can also setup the MOSS Service account or any account running a web application (using AppPools) that connects to the K2 Host Server as follows to constrain delegation to the K2 server and allow for any authentication protocol the web application permits (normally NTLM, but could even be HTTP basic or forms authentication).
• First Open Active Directory Users and Computers
• Find your K2 Service account, then > Right click > Properties > go to Delegation Tab
• Select the radio button to “Trust this user for delegation to specified services only”. This is called Constrained Delegation, and is more secure than the first option, because you must explicitly list which services (SPNs) an account may delegate to.
• Now select the “Use any authentication protocol” radio button.
• To use Constrained Delegation, you must set each of the accounts to delegate to specific SPNs. To start, Click on Add.
• Click on the Users or Computers button and specify the account whose services (SPNs) you want this account to be allowed to delegate to (this is normally the K2 server’s domain service account). In this example, it is the same account we are setting up for constrained delegation. Find the service account and click Ok.
• In the "Add Services" window, Select the appropriate SPNs (often, it is all of them) from the list, and click Ok.
• The results should look something like this (with the computer name part of the SPN being different):
Service Type User or Computer Port Service Name
HTTP blackpearl.k2demo.local
HTTP blackpearl
K2Server blackpearl 5252
K2Server blackpearl.k2demo.local 5252
K2HostServer blackpearl.k2demo.local 5555
K2HostServer blackpearl 5555
• Click OK.
You can wait for replication now or force it.
If you are concerned about security, I suggest using SSL so all browser-webserver traffic will be encrypted. Why stop with simply securing the authentication step if security is a concern?
Regards,
Sam
--------------------------------------------------------------------------------
The statements and opinions made in my postings are my own, and do not reflect the opinions of SourceCode Technology Holdings, Inc. or its subsidiaries. All information is provided as is with no warranties, express or implied, and grants no rights or licenses.