This article was created in response to a support issue logged with K2. The content may include typographical errors and may be revised at any time without notice This article is not considered official documentation for K2 software and is provided “as is” with no warranties.
After updating the K2 Service account due to an Active Directory Policy or alternative reasoning, the password needs to be updated within the K2 Product as it does not know this has been changed within AD and has the old password cached.
Before You Begin
Before starting, ensure that this is done during downtime. You will need to run the K2 Setup Manager for Blackpearl and SmartForms which does a K2 Blackpearl Service and IIS Reset. This restart can cause a minor interruption for users/developers.
Takes notes whether or not this account is used across multiple K2 Environments. If the same account is used elsewhere the same steps will most likely need to be done on other K2 environments as well.
Also, take note of any other applications outside of the K2 Product in which this could also be used to see if they have any caching mechanisms that might not update.
The best starting point is to go through the K2 Blackpearl and K2 SmartForms Setup managers (Configure Option).
Find these in the Start Menu > K2 Blackpearl location. They can also be found within the install directory under Setup > K2 SmartForms Setup Folders.
When going through the Setup Managers you will be presented with the screen shown on the below documentation:
Add the correct password and test to make sure it is valid.
After updating the Setup Manager they should now have correctly updated the Service Account Password across K2.
Most commonly, after the password is changed in AD but not in K2, the K2 Service account will get locked out within Active Directory. If this behavior appears within K2, double check the following locations to ensure that there are no other locations that are storing the old password as cached data:
1. The SSO credentials are stored if someone has specifically cached them within K2 Workspace. These credentials are encrypted and stored within the K2 DB under the [HostServer].[SecurityCredentialCache] table. Run the following update query to remove the old password from this table:
UPDATE [HostServer].[SecurityCredentialCache] SET Password = 0
WHERE UserName = 'DENALLIX\Administrator'
After this, recache the credentials via the SSO cache page of Workspace. This will then store the correct new password that will need to be supplied.
2. Check the email connection strings that also use the K2 Service account. Verify that the password is correct by going to:
[Install Directory]\K2 blackpearl\Host Server\Bin\ConnectionStringEditor.exe.
Check that all noted connection strings using the K2.im account does have the proper password.
3. Control Panel > Credential Manager. Check if there are any Windows and/or Web Credentials stored on the machine for the relevant account.
4. If the account is running an App pool in IIS, it could have cached credentials.
Go into IIS > App Pools > right-click on App Pool > Advanced Settings > Process Model > Identity > click Ellipses next to username > click Set Button.
Re-add the correct credentials and then click Save. Do an IIS reset to cement the change and then check that the browser loads properly.
5. Check any Service Instances using Static Credentials for that Service account.
Edit the Service Instance and update the password manually by using the SmartObject Tester tool. Once verified that the above settings are all set with the correct password, start searching outside of K2 for anything else that could be locking out this account within AD.
Additionally, check the Event Logs on the Domain Controller to figure out the exact location of where the account was hitting and getting locked out: