A good set of rules from K2underground:

1. Kerberos delegation should be configured for each of the following services:
a. K2 server
b. K2 workspace
c. SharePoint – Sites that will interact with K2 and also your Central admin site
d. SQL reporting services
e. SQL server
2. SPNs needed (you should always create SPNs for both the Fully Qualified Domain name (FQDN) and the NetBIOS name of each service:
a. K2 server – When you run a K2 farm please remember that you will need to set the below settings for each server in the farm as well as the farm name itself (Therefore [MachineNameForServer1] can be = to [MachineNameForServer2] etc. or [FarmName]
i. setspn -A K2Server/[MachineNameForServer1]:5252 domain\K2 Service Account domain\K2 Service Account
ii. setspn -A K2Server/[MachineNameForServer1]:5252 domain\K2 Service Account
iii. setspn -A K2HostServer/[MachineNameForServer1]:5555 domain\K2 Service Account domain\K2 Service Account
iv. setspn -A K2HostServer/[MachineNameForServer1]:5555 domain\K2 Service Account domain\K2 Service Account
b. K2 workspace: The best implementation is to use host headers for site names. If you do want to use http://machinename:port, make sure that you don’t have multiple Application pool identities for different sites on the same IIS server and don’t include the port number in the SPN. Best way to avoid that is to use Host headers (A type or Host type DNS record and not CNAME)
i. setspn -A HTTP/K2WSSiteName domain\K2 Workspace Site Application pool identity
ii. setspn -A HTTP/K2WSSiteName.FQDN domain\K2 Workspace Site Application pool identity
c. SharePoint – Sites that will interact with K2 and also your Central admin site. The best implementation is to use hostheaders for site names. If you do want to use http://machinename:port, make sure that you don’t have multiple Application pool identities for different sites on the same IIS server. Best way to avoid that is to use Hostheaders (A type or Host type DNS record and not CNAME)
i. setspn -A HTTP/SharePointSiteName domain\SharePointSite Application pool identity
ii. setspn -A HTTP/SharePointSiteName.FQDN domain\SharePoint Site Application pool identity
iii. setspn -A HTTP/SharePointCentralAdminSiteName domain\SharePointCentralAdmin Application pool identity
iv. setspn -A HTTP/SharePointCentralAdminSiteName.FQDN domain\SharePointCentralAdmin Site Application pool identity
d. SQL reporting services:
i. setspn -A HTTP/SSRSSiteName domain\SSRS Application pool identity
ii. setspn -A HTTP/SSRSSiteName.FQDN domain\SSRS Site Application pool identity
e. SQL Server – please see SQL server documentation for the correct SPN value
3. Check your system for duplicate SPNs. This is a very important step to take. With Windows 2003 there is not any clean or easy way to check this, accept to make a dump of the SPNs in your AD structure and manually checking for duplicate values. With Windows 2008 you can run the following command to check for duplicate values: setspn –x
4. Make sure that each the mentioned accounts above has permissions to delegate to any service (less secure, but most simple way of configuring)
5. Set the NTAuthenticationProviders node to Negotiate,NTLM for each IIS site as noted above on each IIS server (If farming K2 workspace, SharePoint or SSRS make sure to set this on each machine where the site exists) PS. These steps only apply to IIS 6.0
6. Change Authentication per SharePoint site in SharePoint Central Admin to allow for Negotiate
7. Remember to always perform an IIS reset if you make any such changes to any of your sites and restart your services.