When you migrate Sharepoint and K2 you may run into a problem where all K2 links for your site just give you “Value cannot be null. Parameter name: token.” I end up having issue after just changing site collection compatibility range (for testing purposes, here is how to do it) and then creating new site within it in SP 2010 compatibility mode. Immediately it was possible to see that something is wrong/missing:
Here is how to fix this. What you need to do is configure classic windows claims to work with K2 from SharePoint Claims enabled site with K2 (see my earlier blog post on how to configure claims authentication for your site also there is related K2 help section). To configure classic windows claims for K2 you have to do the following:
1) Retrieve SigningCertificateThumbprint by issuing the following command in SharePoint 2013 Management shell:
(Get-SPServiceApplication -Name SecurityTokenServiceApplication).SigningCertificateThumbprint
Copy returned value to use it on step 2.
2) Open SQL Server Management Studio and edit SQL script below by replacing value “CAEF8EEA3D68074C347AC9584E60C6FC406C8AAB” with one retrieved on step (1) in your environment.
DECLARE @issuerId INT
INSERT INTO [K2].[Identity].[ClaimIssuer] (Name,Description, Issuer, Thumbprint, Uri, UseForLogin)
VALUES ('SharePoint Windows STS', 'SharePoint Windows Authentication', 'SharePoint', 'CAEF8EEA3D68074C347AC9584E60C6FC406C8AAB',null, 0)
SET @issuerId = SCOPE_IDENTITY();
SET ClaimType = 'http://schemas.microsoft.com/sharepoint/2009/08/claims/userlogonname'
INSERT INTO [K2].[Identity].[ClaimTypeMap] (ClaimTypeMappingID, ClaimMappingType, OriginalIssuer, ClaimType, ClaimValue)
VALUES (2,'IdentityProviderClaim', 'SecurityTokenService', 'http://schemas.microsoft.com/sharepoint/2009/08/claims/identityprovider', 'windows')
3) Next you can check Identity.ClaimsIssuer table in K2 database:
SELECT * FROM [identity].ClaimIssuer
It should contain SharePoint Windows STS with appropriate thumbrint value:
Once this is done that “Value cannot be null. Parameter name: token” should gone. It seems that in my case thumbprint value changed in my environment (i.e. I’m pretty sure that entry for SharePoint Windows STS did exist in my ClaimIssuer table) though I’m not sure what triggered that change.