Symptoms
After upgrade of K2 from 4.6.6 to 4.6.11 your custom application does not work. After this upgrade, exceptions are thrown by custom application when calling ReleaseWorklistItem:
"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"
Diagnoses
To resolve this issue it is necessary to set "UseIntegratedWFManagement" to "False" in custom application connection string. Unchanged connection sting may look as follows:
<appSettings> <!-- K2 Workflow management API keys -->
<add key="K2HostWFManagement" value="k2.denallix.com"/>
<add key="K2HostPortWFManagement" value="5555"/>
<add key="SystemUserWFManagement" value="Denallixk2service"/>
<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>
And such configuration works in 4.6.6 - 4.6.10 but does not work in 4.6.11. How it behaves in 4.6.11 seems to be correct/normal, as you either have to specify explicit credentials + UseIntegratedWFManagement=False or no explicit credentials + UseIntegratedWFManagement=True, combination of explicit credentials + UseIntegratedWFManagement=True fails with this error:
24404 Authentication with server failed for K2Service@denallix.com with Message: AcceptSecurityContext failed: The logon attempt failed
The reason why it does not work in such configuration is that in 4.6.11 SSO changes were introduced to address issues with SSO Prompt for credential cache. In 4.6.10, when you Authenticate a HostServer session with the following connection string:
Integrated=TrueIsPrimaryLogin=TrueAuthenticate=TrueEncryptedPassword=FalseHost=k2.denallix.comPort=5555UserID=DenallixAdministratorPassword=PasswordWindowsDomain=denallixSecurityLabelName=K2
the connectionstring associated with the session is:
Integrated=TrueIsPrimaryLogin=TrueAuthenticate=TrueEncryptedPassword=FalseHost=dlxPort=5555UserID=DENALLIXAdministratorPassword=K2pass!AuthData=DenallixSecurityLabelName=K2 The
WindowsDomain key was not 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 has all 3, it would try and use those details to authenticate a user, in 4.6.10 and earlier K2 did not persist the WindowsDomain and because of that it would just do a normal integrated connection string without the username and password.
In 4.6.11 K2 persists the WindowsDomain, so K2 tries to authenticate with the following values WindowsDomain = "Denallix" UserID = "DenallixAdministrator" Password = "Password" It works in HostServer because we check if we specified a WindowsDomain AND if there is a domain specified in the UserID but we don't do this in WorkflowServer. A workaround is to not specify the WindowsDomain in the connection string if it is already included in the UserID or to not specify the domain with the userName. E.g.:
Integrated=TrueIsPrimaryLogin=TrueAuthenticate=TrueEncryptedPassword=FalseHost=k2.denallix.comPort=5555UserID=DenallixAdministratorPassword=K2pass!SecurityLabelName=K2
Or:
Integrated=TrueIsPrimaryLogin=TrueAuthenticate=TrueEncryptedPassword=FalseHost=k2.denallix.comPort=5555UserID=AdministratorPassword=K2pass!WindowsDomain=denallixSecurityLabelName=K2
Resolution
In K2 4.6.11 in your connection string to workflow server you have to specify domain either before user name (SystemUserWFManagement property) or separately (WindowsDomainWFManagement property) but not simultaneously to make integrated authentication work. In older versions (prior to 4.6.11) connection string to workflow server did not persist WindowsDomainWFManagement value and it used to work with domain specified in both places.
In 4.6.11 as it persists WindowsDomainWFManagement property in connection string specifying domain in both places obviously leds to authentication error: AcceptSecurityContext failed: The logon attempt failed Essentially with such configuration you are trying to authenticate with the following credentials WindowsDomain + UserID with domain which leads to use of something like "DomainDomainUser" for authentication and authentication attempt will fail because of that.
