RSA Authentication Agent 7.3.1 for Microsoft Windows prompts for passcode when used as an RDP jump host

[#1]

Article Number

000034009

Applies To

RSA Product Set: SecurID
RSA Product/Service Type: Authentication Agent for Windows
RSA Version/Condition: 7.3.1[43] and later, 7.3.1 and 7.2.x

Issue

When a challenged user clicks on the RDP application from a machine that has the RSA Authentication Agent 7.3.1 or 7.2.1 for Microsoft Windows installed,  the user is immediately prompted for an RSA passcode, when previously they saw a logon prompt for the remote Windows server.  This change usually happens after a Microsoft Windows update has been applied.  
 

Image description

If this challenged user enters valid SecurID credentials, this is treated as a local agent authentication and sometimes fails with the following error:
 

Node Secret Mismatch cleared on Agent not on server  

If the authentication does not fail with the node secret mismatch error, and the user successfully authenticates on the first machine with a passcode, the user will next see a remote Windows Credential Provider logon prompt, requesting a password if the RSA Authentication Agent is not installed and a passcode if the RSA agent is installed.

Reverting the Windows update typically is not an option even if it returns the Windows platform to its previous method of connecting directly to the remote RDP host and its Credential Provider prompt.

If verbose logging was enabled, the authentication agent's logs will indicate that the Windows update has made the Windows Credential Provider UI call a different RDP application, one that the RSA agent did not expect, so the RSA Credential provider prompts for local SecurID Credentials 

Cause

This issue with the use of the Remote Desktop Connection Manager as a jump host application on Windows Server 2012 R2 is a variation on the problem described in article 000033802 (Microsoft Windows update MS16-101 breaks RDP from the RSA Authentication Agent 7.3.1 for Windows for all RSA challenged users).  This solution referenced both C:\Windows\System32\mstsc.exe and C:\Windows\System32\CredentialUIBroker.exe as possible RDP applications called by a user or administrator.  But other RDP applications such as Remote Desktop Connection Manager may have been called instead.  

To enable agent verbose logging in the RSA Control Center,

1. From Home, select Advanced Tools.
2. Select Tracing.
3. On the Tracing page, set the Trace Level to Verbose.
4. Use the default trace file destination folder or click Browse to select a different location.
5. For Selected Components, check Select All.
6. When done, click OK.

Image description

8. Test the connection again.
9. In the location defined as the trace files destination folder, there will be a log file that includes the called RDP application name.  For example, SIDAuthenticator(RDCMan).log, SIDCredentialProvider(RDCMan).log and other logs with RDCMan in the name that indicate that Remote Desktop Connection Manager is being called, therefore the fix is to set the registry setting to use Remote Desktop Connection Manager.

The critical differences between Remote Desktop Connection Manager and either mstsc.exe or CredentialUIBroker.exe are:

1. Remote Desktop Connection Manager is a stand-alone application from Microsoft that runs on a variety of Windows operating systems.
2. Based on a very brief investigation, it appears to be available ONLY as an x86 application, based on agent logs where mstsc.exe was called instead of RDP  
3. RSA Product Management for the Windows authentication agent did not require that the agent support RDP authentication through any client other than the native Remote Desktop Connection application (mstsc.exe). 
4. Put these three pieces together and supporting the Remote Desktop Connection Manager will require an enhancement to the Windows authentication agent.  Refer to AAWIN-2319 when asking your RSA sales contact about any work being done as an enhancement for this.

Note that the fully qualified name of the application can be found in the SIDCredentialProvider(RDCMan).log in the call to Helpers::getModuleLongFilename, as shown in the log snippet below:

​2016-09-09 15:53:54.264 764.5496 [I] [Helpers::getModuleLongFilename] 
szLongNameBuff=C:\Program Files (x86)\Microsoft\Remote Desktop Connection Manager\RDCMan.exe

Resolution

Using a variant of the workaround in article 000033802 (Microsoft Windows update MS16-101 breaks RDP from the RSA Authentication Agent 7.3.1 for Windows for all RSA challenged users) for this defect MIGHT provide a PARTIAL WORKAROUND in this case.  "Partial," because it will break the use of native Remote Desktop Connection (mstsc.exe) on remote connections. 

1. Launch the registry editor.
2. Open or create the key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\RSA\RSA Desktop\Local Authentication Settings.
3. Create a REG_SZ value named RDCFileName and populate it with the fully qualified path to the application. For Remote Desktop Connection Manager, that would be C:\Program Files (x86)\Microsoft\Remote Desktop Connection Manager\RDCMan.exe instead of C:\Windows\System32\CredentialUIBroker.exe or C:\Windows\System32\mstsc.exe.

On some Microsoft Windows 10 systems, for some as yet unknown reason, we found that the RDP client was collecting credentials through LogonUI.exe rather than CredentialUIBroker.exe.  By design, the RSA Windows agent is supposed to detect that it is being called to provide credentials for OUTBOUND RDP and pass the calls through to the Microsoft password provider.  Adding LogonUI (C:\windows\system32\logonui.exe) to the Remote Desktop Connection applications policy settings addressed the problem for a specific customer. This workaround appears viable in this case, but only when applied to Windows 10.

An alternative would be to see if RSA Engineering provides a fix or another work-around through AAWIN-2319, for the capability to run the Remote Desktop Connection Manager from a Windows 2012 R2 Server that is protected by an RSA Authentication Agent to a Windows server that does not have the RSA agent installed. This is deemed a known Issue because using the GPO is a workaround unless/until RSA can re-architect the Windows agent to eliminate the need for elevated privilege.

Workaround

Use mstsc.exe instead of the RDP manager or CredentialUIBroker.exe or initiate RDP sessions with a non-challenged RSA user.


 

Notes

If you are stuck at the Node Secret Mismatch error and for some reason cannot successfully implement the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\RSA\RSA Desktop\Local Authentication Settings resolution, you may need to open up read permissions to the node secret directory for all authenticated users on the agent machine.  

First, change permissions on the node secret file (named securid by default) to grant read permissions to Authenticated Users. To do this,

1. Open Windows Explorer on the machine on which the authentication agent is installed.
2. Navigate to C:\Program Files\Common Files\RSA Shared\Auth Data.
3. Right click the RSA Shared directory and choose Properties.
4. Click on the Security tab.
5. Under Group or user names, click the Edit button.
6. Click Add...
7. Create a new object named Authenticated Users and click OK when done.
8. Highlight the Authenticated Users object.
9. Under Permissions, check the Allow box next to Read.

Image description

10. Click Apply.
11. Click OK.
12. Try to RDP with a challenged user again.
13.  You will see two prompts here. The first is from the local Windows machine. The second will be on the remote server. There will be a prompt for a passcode if an RSA authentication agent is installed or for password if the RSA agent is not installed.