Recently I had an interesting support case where we spent way too much time on investigation of a problem which was simple one as soon as we figure it out 🙂 It was the typical case where it was difficult to see the forest behind the trees as K2 environment we dealt with was quite complex and involved F5 NLBs so it was easy to be distracted by all this complexity and blame issue  environment configuration problems.
Anyhow main symptom was that custom application built on top of K2 platform which worked just fine in K2 4.6.6 started to fail immediately after environment upgrade to 4.6.11. Specifically application started to throw the following exceptions when calling ReleaseWorklistItem method:
“2025 Error Marshalling SourceCode.Workflow.Runtime.Management.WorkflowManagementHostServer.ReleaseWorklistItem, 24404 Authentication with server failed for %K2_Service_Account% with Message: AcceptSecurityContext failed: The logon attempt failed“
We were a bit distracted in the beginning by NLBs and environment complexity (which I should admit was designed and managed remarkably well) but in the end root cause was isolated to the way K2 connection string was configured. Let’s assume app connection string is configured as follows:
<appSettings> <!-- K2 Workflow management API keys --> <add key="K2HostWFManagement" value="k2.denallix.com"/> <add key="K2HostPortWFManagement" value="5555"/> <add key="SystemUserWFManagement" value="Denallix\k2service"/> <add key="SystemUserPasswordWFManagement" value="Password"/> <add key="UseAutheniticateWFManagement" value="True"/> <add key="UseEncryptedPasswordWFManagement" value="False"/> <add key="UseIntegratedWFManagement" value="True"/> <add key="UseIsPrimaryLoginWFManagement" value="True"/> <add key="SecurityLabelNameWFManagement" value="K2"/> <add key="WindowsDomainWFManagement" value="denallix"/> </appSettings>
So this connection string if we look at it does not seem to be correct as if you look at it carefully you may notice that we indicate use of integrated authentication for WF Management but at the same time provide explicit credentials. And indeed as soon as we remove credentials or set UseIntegratedWFManagement to false app starts working in 4.6.11. But now the thing is that such connection string works just fine in K2 4.6.6 – 4.6.10 but does not work in 4.6.11. So it looks a bit like breaking change which in reality is a fix implemented in 4.6.11 which changed system behavior.
Prior to 4.6.11Â when you Authenticate a HostServer session with the following connection string:
Integrated=True;IsPrimaryLogin=True;Authenticate=True;EncryptedPassword=False;Host=k2.denallix.com;Port=5555;UserID=Denallix\Administrator;Password=Password!;WindowsDomain=denallix;SecurityLabelName=K2
the connection string associated with the session was:
Integrated=True;IsPrimaryLogin=True;Authenticate=True;EncryptedPassword=False;Host=dlx;Port=5555;UserID=DENALLIX\Administrator;Password=Password!;AuthData=Denallix;SecurityLabelName=K2
If you pay attention to the end of sample connection strings above the WindowsDomain key wasn’t persisted pre-SSO and instead it was added as AuthData.
When you open a connection from the WorkflowManagmentServer to the WorkflowClient, there is a check to see if the connection has a WindowsDomain, Username and Password. If it had all 3 of them, it would try and use those details to authenticate a user. In versions prior to 4.6.11 K2 didn’t persist the WindowsDomain property, and because of that even if you specified all three parameters it would just do a normal integrated connection string without the username and password as WindowsDomain is “missing”.
In 4.6.11 K2 persists the WindowsDomain, so with connection string properties configured as above K2 actually tries to authenticate with the following values:
WindowsDomain = "Denallix"
UserID = “Denallix\Administrator”
Password = “Password”
This works in HostServer because there K2 checks if we specified WindowsDomain AND if there is a domain specified in the UserID, but there is no such check in WorkflowServer. This leads to connection attempt with values from both WindowsDomain + UserID which leads to use of something like “Domain\Domain\User” for authentication and authentication attempt will fail because of that.
Workaround to this is to not specify the WindowsDomain in the connectionstring if it is already included in the UserID
OR to not specify the domain with the userName.
e. g.
Integrated=True;IsPrimaryLogin=True;Authenticate=True;EncryptedPassword=False;Host=k2.denallix.com;Port=5555;UserID=Denallix\Administrator;Password=Password!;SecurityLabelName=K2
or
Integrated=True;IsPrimaryLogin=True;Authenticate=True;EncryptedPassword=False;Host=k2.denallix.com;Port=5555;UserID=Administrator;Password=Password!;WindowsDomain=denallix;SecurityLabelName=K2
This is something to be aware of if you using connection strings and your app connects to WorkflowServer, otherwise you can have sort of little surprise after upgrading to 4.6.11 from older versions.