Configuring the RSA Authentication Agent 7.1 for Web for IIS to simplify logging and remove extraneous data

[#1]

Article Number

000029805

Applies To

RSA Product Set: SecurID
RSA Product/Service Type: Authentication Agent for Web for IIS 7.5
RSA Version/Condition: 7.1.3.128

Issue

Sometimes the web agent's AceClient.log can be difficult to read, with many cookie and Cross-Site Request Forgery (CSRF) messages clouding the log file.  When using SharePoint, symptoms such as the error below are seen:

Failed to get HTTP_COOKIE with error 183, <name>cookie_OFFICE_PERSISTENT, Get User Name from cookie api 
failed, local failed - look for domain cookie and
File:rsacookieapi.cpp Line:233 # Buffer copy error occurred in SDTraceMessage while writing log 
"Buffer copy error occurred in SDTraceMessage" are often related to the use of a named Microsoft cookie 
which the RSA agent is unaware of - configure the Use of Domain Cookies

Alternatively, sometimes there is not enough detail in the AceClient.log, due to insufficient privileges for the various API calls when writing to the \Windows directory.  To prevent this, change the location of the AceClient.log on the IIS server in the registry, to a folder with wide open permissions to everyone.
 

Alternatively, sometimes there is not enough detail in the AceClient.log, typically due to insufficient privileges.  To prevent this, create a registry entry on the IIS server that defines a new location for the AceClient.log to a directory with open permissions to everyone.  To make this change,

1. Set the log file to write to an unprotected folder by creating such a directory on the server, for example RSALogs.
2. Opening a registry editor and navigating to HKEY_LOCAL_MACHINE\SOFTWARE\SDTI\ACECLIENT.
3. From the Edit menu, click Add Key and create a key named TraceFile, with a type of REG_SZ.  
4. Set the value of TraceFile to C:\RSALogs\AceClient.log.
5. Reboot the server for the change to take effect.

Task

To capture error messages, do the following;

1. Disable the RSA Token for Cross-Site Request Forgery Protection option, as documented below. 
2. Move any existing AceClient logs to a new directory
3. Set verbose logging in web agent via the server's Control Panel > RSA Authentication Agent > Advanced tab. Choose all options for tracing level and tracing destination.
4. Reproduce the problem so new logs are generated.
5. Capture the new AceClient.log file.
6. Send the file to RSA Customer Support to open a new case for forward the log to the support engineer assigned to the case for review.

Image description

Resolution

RSA implemented a logoff cookie check to prevent hackers from using a copied cookie.  See the RSA knowledgebase article on how an authenticated user needs to re-authenticate if one of the clustered RSA SecurID web agent is rebooted that has been set up for multiple server authentication.

Every time a user logs off, a copy of their cookie is stored in cache and every time any other user presents a cookie, a cache lookup is performed.  This has two effects:

1. The web agent becomes very busy; and
2. ​The verbose logs become crowded with CSRF cookie messages, making them difficult to read.

Later versions of the agent prevent Java from hijacking the RSA cookie.  While this might not prevent a hacker from walking up to an unlocked console and using a browser tool to copy cookies, it may be reasonable to disable the RSA Logoff Cookie check environment variable.  To do this on the Windows 2012 server running the agent, ​

1. Open the Group Policy Management Console.  Right-click the Group Policy object (GPO) that should contain the new preference item, and then click Edit.
2. In the console tree under Computer Configuration or User Configuration, expand the Preferences folder, and then expand the Windows Settings folder.
3. Right-click the Environment node, point to New, and select Environment Variable.
4. In the New Environment Variable Properties dialog box, select an Action for Group Policy to perform. 
5. Create an environment variable named RSA_NO_LOGOFF_COOKIE_CHECKING and set the value to 1 to turn it off.
6. Click the Common tab, configure any options, and then type your comments in the Description box.
7. Click OK. The new preference item appears in the details pane.

A second source of log messiness is Cross-Site Request Forgery Protection (CSRF) enabled in the RSA IIS agent by default.  Turn off the option to Use RSA Token for Cross-Site Request Forgery Protection through the IIS Manager, as in the example below:

Image description

Note that CSRF is not cross-site scripting (XSS), and is not an easy exploit to pull off, but you may want to re-enable the option after debugging the web agent issue.  See articles on CSRF versus XSS for more information.  The main difference being XSS exploits the trust a user has for a particular site, while CSRF exploits the trust that a site has in a user's browser.

Notes

• The Logoff URL option works only if you have not selected the Use RSA Token for Cross-Site Request Forgery Protection option, which is the source of the CSRF messages in the logs.  See articles below for more information: 
  • ​Users wish to logout of their web application automatically; and
  • Web page display 'Bad Request' when using logoff URL feature.
• The Bad Request error when attempting to logoff the RSA-protected webpage logoff would only work when the Use RSA Token for Cross-Site Request Forgery Protection is set if you used the web agent API to get the token dynamically.
• Hot fixes created after version 7.1.3 build 128 will decouple the logout/logoff function from CSRF, so that you can configure the logout URL of the <http target address>/WebID/IISWebagentIF.dll?logoff  to invalidate the cookie and still keep CSRF checked.
• The registry entry of HKEY_LOCAL_MACHINE\SOFTWARE\SDTI\RSAWebAgent\Agent50CompatibleCookies set as a string value with a value of 1 may need to be set on the IIS server to use an older format of cookies.  For example, using a Microsoft Internet Security and Acceleration (ISA) server that will  authenticate a user with SecurID and send the resulting cookie along to web servers under its' dominion.  
• If the multi-domain URLs are all hosted on the same IIS server, the Multi-Domain support option does not need to be checked.  Doing so may actually cause unnecessary lookups.
• Local admin privileges may need to be assigned to accounts referenced in the app pools to see the ‘URLProcessor’ in entries the logs and for authentication based on an IIS/SHP shared secret to work. 
• The log entry COPIED_COOKIE_PROTECTION_SUPPORTED is not relevant to SharePoint or other web-based site problems. This value is set by the installer, for determining which platform will support the check for copied cookies.