000036981 - RSA Archer pages do not load, have unexpected errors, display "cmmn:", or display "undefined" at the top of the page when Windows Authentication (Single Sign On) is used

Document created by RSA Customer Support Employee on Dec 3, 2018Last modified by RSA Customer Support Employee on Apr 2, 2019
Version 6Show Document
  • View in full screen mode

Article Content

Article Number000036981
Applies ToRSA Product Set: Archer
RSA Product/Service Type: RSA Archer (On-Premise)
RSA Version/Condition: 6.X
Platform: Windows
IssueWhen Windows Authentication is enabled the following issues are observed:
  • Pages do not load at all
  • Pages load with the header text "cmmn:Search" at the top User-added image
  • Pages load with the header text "undefined" at the top.User-added image
  • "cmmn:" text is in column headers
User-added image
  • Users receive "Unexpected Error: An unexpected error has occurred in the system. Please try your request again. If problems persist, please contact your system administrator" popups after spending more than 1 minute on a page.User-added image

Steps to confirm you are impacted by this issue are below:

  1. Log into Archer using Windows Authentication
  2. Wait 2 minutes without clicking on anything.
  3. From the MegaMenu, open the Advanced Search page of any application
  4. If the page displays " cmmn :", "undefined", an Unexpected Error popup or the page does not load, then you are impacted by this issue.

  1. On the Advanced Search page for any application where you select fields for the search results.
  2. Wait 2 minutes.
  3. Click the Search button. If an unexpected error popup is received, then you are impacted by this issue.


This behavior is caused by a setting within Windows pertaining to Microsoft Internet Explorer in combination with different authentication mechanisms across different portions of the RSA Archer web application. It will be seen in any part of 6.x which has been modernized from using Silverlight. The behavior will affect anyone who is using Internet Explorer 11 as their main browser for end-user pages, and who simultaneously has enabled Windows Authentication on IIS. These pages are affected because they are rendered in the UI (which is served from a WinAuth endpoint) but retrieve their data via a call to the RESTful API, (which is behind an Anonymous endpoint).


Investigations continue into enhancements in the RESTful API that will render the condition which causes this behavior obsolete. This will be addressed at a later time.


There is a range of alternative options available to customers who are affected by this behavior. Anyone of these approaches will address the behavior and cause the problem to be resolved. RSA recommends each customer individually assess the four options listed and determine a suitable approach.

Workaround 1: Apply the registry change Microsoft describes in their Support Article 2749007 (https://support.microsoft.com/en-us/help/2749007/an-unexpected-401-1-status-is-returned-when-using-pre-authentication-h). This change would amend the way in which Internet Explorer behaves when making calls to applications that feature mixed authentication models, such as RSA Archer. There will be a very small performance cost associated with this change, but for customers who do not have a lot of traffic from end users to such applications, this will be minimal. Changing registry settings is not something which end-users can typically do, therefore a request would need to be made to a supporting IT department to roll out the change via group policy. This approach remains RSA's recommended approach since it is Microsoft's recommended approach and the issue pertains to the interaction of two Microsoft products. RSA recognizes, however, that some customers will not be able to request this change of their IT Departments.

Workaround 2: Encourage non-admin users to use a different supported browser such as Chrome in place of Internet Explorer 11. While, obviously, admins will still need Internet Explorer to access Silverlight based pages, most users do not need access to these pages. For these users, if corporate policies permit different browsers, this may be an appropriate resolution to this issue.

Workaround 3: Enable Kerberos on the Archer Web Server(s) (See: https://support.microsoft.com/en-us/help/929650/how-to-use-spns-when-you-configure-web-applications-that-are-hosted-on  for instructions). If this setting is changed, the problem will not reoccur as the place the issue is coming from is in the client-server handshake and Kerberos manages this in a different way. This option will resolve the issue for customers whose users are hitting the RSA Archer environment within the bounds of their network, and where there is network connectivity to a Domain Controller. 

Workaround 4: Contrary to the instructions in the Installation Guide, Windows Authentication may be enabled on the ArcherAPI site in IIS. This issue will no longer be present and the RSA Archer web application will continue to work correctly.

IMPORTANT: For those customers not using any custom integrations or utilities that call into the RESTful API, Workaround 4 will be sufficient. For those customers who do have custom integrations or utilities which call into the RESTful API, there will be a further change required. If choosing Workaround 4 these customers will need to set up a separate web host with the ArcherAPI folder configured for Anonymous access, outside the pool of hosts which end users connect to. This endpoint can be used for integrations while the other servers are used as the user endpoints. See attached document below for instructions on how to add an additional API site for your installation.


RSA appreciates that these four workarounds will suit different customers to different degrees. Between them, they provide a range of options to allow the issue to be overcome."