|Applies To||RSA Access Manager (AxM) 6.x|
RSA Access Manager Agent versions 4.9/5.0
|Issue||Symptom Error: "Unable to create token" in RSA ClearTrust Agent|
Symptom Auth server debug output reports:
16:36:56:853 EST,Client IP Address = 255.255.255.255,Client Port = 1058,Result Code = 0,Result Action = User Token Failed,Result Reason = Token error
Symptom ctagent.log file logs the following error message:
Mar 30, 2004 8:52:39 AM EST -  - <Critical> - Unable to create token. Authorization server returned: 15
ctagent.log files logs the following error message:
Dec 22, 2005 11:42:53 AM CST -  - <Debug> - exception_type=TokenException, msg=(Token decryption failed)
|Cause||Typically these error messages appear as expected behavior, and can be ignored.|
More information on cookie decryption errors
All ClearTrust cookies are encrypted with an encryption key that is changed on a periodic basis. The frequency of key creation is determined by the cleartrust.keyserver.session_key_life setting in the keyserver.conf file. By default, this value is 30 minutes. The keyserver holds 14 old keys in a first-in first-out buffer. Once created the key is held in that buffer for a period determined by cleartrust.keyserver.token_lifetime which is 1 hr by default.
If a new key is created every 30 minutes, and held in this buffer for 1 hr means that old keys are retained on average for 1 1/2 hours. Testing and internal logic shows that it is actually greater and is actually 2 hours. (see note #2)
With these numbers the buffer usually has 3 to 4 keys it after it been up for few hours and maintains that number while site is up. The newly created key is used for both encryption and decryption while the older keys are just used for decryption.
ClearTrust-encrypted cookies are presented to the client Web browsers, and are stored in the browser for as long as the browser session is active by default (they can be persisted). These cookies are updated if the user access a Web page; but if the user's browser is inactive, the cookies maintained by the Web browser are not updated.
Users who are inactive are normally required to re-authenticate based on the value of the cleartrust.agent.idle_timeout (default is 15 minutes). If a user presents with a cookie, it is decrypted, and the last touch time is read. If the cookie is older than 15 minutes, the user is asked to re-authenticate.
Once the key expires after 2 hours it is dropped from the buffer. Any token/cookie encrypted by that key cannot be decrypted and generates a token error. “Unable to extract session information from token. Authorization server returned: 15”. or "Token Error" depending on version used.. That is usually the case for sessions that are left open idle for greater than 2 hour. Common if user leaves session open at the end of the day and tries to resume working the following morning.
The user will again be forced to re-authenticate. In this case, instead of logging a user idle event, the AServer will log the cookie decryption event error.
The quantity of cookie decryption errors in the log files is not a one-to-one correspondence with the number of users being asked to authenticate. Cookies are presented to the Web server for each element of a Web page, and each cookie will cause an error message in the log file. The cookies will be presented to the server during the display of the logon page itself as well. This means when a user presents with an old browser session, they may see a dozen or so messages logged for each event. In newer versions features were added to reduce the redundant error messages.
In specific instances if this error is noted in increased frequency this error may indicate a problem with keyserver synchronization. In these instances the error message is associated with authenticated users being prompted for re-authentication before the idle timeout period. This problem may occur when more than on aserver is in use, and the aservers are unable to retrieve new keys from their keyserver, or the keyservers are not in sync. Look to the aserver and keyserver logs. Restart the aservers and keyserver so that you know they are in sync.
Also see articles:
000024719 Error: 'Unable to create token. Authorization server returned 15.' in agent log at log level 'Critical' in RSA ClearTrust Agent 4.5 for Microsoft IIS
000019166 Error: '16:36:56:853 EST Client IP Address = 255.255.255.255 Client Port = 1058 Result Code = 0 Result Action = User Token Failed Result Reason = Token error' in RSA ClearTrust Authorization Server debug output
000014966 AXM- unable to login to Cleartrust agent error: 'Cookie creation failed authorization server returned an unexpected value CT_COOKIE_ERROR'000014966
000015054 AxM Agent 4.9.1 for Apache 2.X: 'Token decryption failed' when using some browsers.
As of hotfix 220.127.116.11 the agent logfile message has been changed from <critical> to <warning> level for this error.
Keyserver starts counting the keys after encryption key has moved down a slot in the table so it's always 1+ the ratio of the two numbers and then there is potentially and extra one as it creates the keys on even boundaries 1/2, 1, 1 1/2 so when we check again at 1 1/2 there may be a delay and by the time we check a 4th has already been created. It is ratio of keys + 2 times the key life.
Note #3 The solution supercedes solution 000021220