We have three separate instances of Cognos EP 8.4.1 - DEV, QA, and PROD. When logging into Cognos Connection, I frequently get the following error:
PRS-CSE-1258
com.cognos.accman.jcam.crypto.CAMCryptoException : CAM-CRP-1346 Failed to get the HMAC value to verify the package capability trust token. Invalid digest of the common symmetric key. Unable to find an appropriate common symmetric key to decrypt the data.
It appears as if there is a cryptography error. The reality is that I just need to log off from one instance before opening another instance in a new browser.
Cognos suggests updating the domain and path in the global configuration.
What syntax should be used? Which server(s) does this need to be done to? We have a BI App Server, an EP App Server, and a Gateway server.
(cont.)
Our URL's are in the following format:
http://planning.domain.com/cognos8
http://planningqa.domain.com/cognos8
http://planningdev.domain.com/cognos8
Any help would be greatly appreciated.
Hey Jeffowentn,
You're likely running into: http://www-01.ibm.com/support/docview.wss?uid=swg21343437
The session information from one environment is cached in the browser, so when you log into the other environment it attempts to use the cached session information from the previous environment. You may also have to regenerate the crypto keys between the servers in each environment.
Something I read one time lead me to believe you may be able to get around this if you change up the virtual directory names, so that from the perspective of the client system they're unique:
http://planning.domain.com/congos8
http://planningqa.domain.com/cognos8qa
http://planningdev.domain.com/cognos8dev
Cheers
Eric,
Thanks for the response.
This is what I was referring to but couldn't readily find, earlier:
http://publib.boulder.ibm.com/infocenter/c8bi/v8r4m0/index.jsp?topic=/com.ibm.swg.im.cognos.inst_cr_winux.8.4.1.doc/inst_cr_winux_id19066CustomizeHTMLcookiesettings.html
Would this work in our situation?
Jeff
Nice find, I'm going to file this away for future reference.
I don't believe it will address your issue because the cookie is still being created in the default location in the browser. My understanding is that it will then try to use the same cookie and session information that's been cached when you attempt to access the other environment without first logging out of the first.
From the looks of this document, it was written to address the specific behavior of repeated login prompts due to domain issues within the cookie that's been cached. I don't believe this will affect the way the cookie is created and stored locally. It might be worth a try.
Any help with the syntax of the values entered for the domain and path? I tried entering values but it did not seem to do anything...I can't find any documentation that expressly states how the values should be entered in the global configuration setting.
Sorry, Jeff -- I'm not familiar with the required syntax on this one.
Looking at it though, I would expect that you'd want to provide the FQDN of the machine.. and mirror these settings in the other 2 environments. This should effectively hard code the domain information into the cookie. Not sure how the browser will interpret this, or if the behavior will remain the same.
Good luck!