I can't comment on changes between versions, but what I can offer is that it is best practice to have a host file on each K2 Server in the farm with an entry to keeps the call to the K2 DNS entry local to the server. This addresses many issues with performance, security, SNATing etc. If you are seeing the servers try to call back out to the NLB then it tells me the host entry must be missing.

 

FIrst step is to have your infrastrucutre team update the hosts files on each K2 server to keep those calls local and test again.

 

Hope this helps.

 

S.

Thanks Scott. We'll update you on how this goes.

 

 

We tried the above and also opened firewall from K2 hosts to the load balancer. In both cases the error has changed to 

2025 Error Marshalling SourceCode.Workflow.Runtime.Management.WorkflowManagementHostServer.ReleaseWorklistItem, 24404 Authentication with server failed for Âusername] with Message: AcceptSecurityContext failed: The logon attempt failed

This was resolved with the help of K2 support. There were changes in the way K2 makes connections and the way we made connection string needed to be changed.

 

This was introduced in 4.6.11 with the SSO changes (TFS 524432 - SSO Prompt for Credential cache). In 4.6.10, 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=DenallixAdministrator;Password=K2pass!;WindowsDomain=denallix;SecurityLabelName=K2

the connectionstring associated with the session is: Integrated=True;IsPrimaryLogin=True;Authenticate=True;EncryptedPassword=False;Host=dlx;Port=5555;UserID=DENALLIXAdministrator;Password=K2pass!;AuthData=Denallix;SecurityLabelName=K2

So the WindowsDomain key wasn't persisted pre SSO and instead it was added as AuthData (pay attention to the end of sample connection strings above).

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, it would try and use those details to Auth a user, in 4.6.10 we didn't persist the WindowsDomain, it would just do a normal integrated connection string without the username and password.

Essentially with such configuration you are trying to authenticate with the following credentials WindowsDomain + UserID which leads to use of something like "DomainDomainUser" for authentication and authentication attempt will fail because of that.