000033802 - Microsoft Windows update MS16-101 breaks RDP from the RSA Authentication Agent 7.3.1 for Windows for all RSA challenged users

Document created by RSA Customer Support Employee on Aug 23, 2016•Last modified by RSA Customer Support on Jun 16, 2018
Version 10Show Document
  • Comment • 0
  • View in full screen mode

Article Content

Article Number000033802
Applies ToRSA Product Set: SecurID
RSA Product/Service Type: Authentication Agent for Windows
RSA Version/Condition: 7.3.1
IssueAfter Microsoft Windows update MS16-101 was applied on a Windows 10 server with the RSA Authentication Agent 7.3.1 for Windows, RDP logon fails to a destination server for challenged users. The authentication activity log shows the reason for failure is a node secret mismatch on the local agent, not from the destination server/workstation.

When a user launches an RDP session from this RSA-protected source machine, he sees the following screen:
 
From
 

Then he will see the following window if he is RSA challenged:
 
To


However, this logon always fails even with known good RSA username and passcode.  The Security Console Authentication Activity monitor or report shows the following error:
 
Node secret mismatch; node secret cleared on agent but not on server.


The Source IP column in the Authentication Activity log lists the source Windows 10 machine, not the destination Windows server to which the user is creating an RDP session.

This behavior started after running Windows update MS16-101, which includes security updates for Windows authentication methods.
CauseInitial indications are that something changed in how Microsoft calls the RSA credential provider through the CredUA in relation to how RSA was configured. There are two applications that Microsoft can call.  These are C:\Windows\System32\CredentialUIBroker.exe or C:\Windows\System32\mstsc.exe.

This problem behavior is due to a change, so the fix is to change it back in the registry.  Details below.

This issue happens when the local host meets the following criteria:
  • It uses Windows 10 as the operating system,
  • It has the MS-101 security updates from 9 August 2016 or later installed, and
  • When the local user who initiates an RDP session is challenged by RSA.   That is, the user is required to authenticate with a passcode. 
The authentication fails with the error Node secret mismatch; cleared on agent not server, because RDP runs as non-privileged and cannot read the node secret.  The Authentication Manager logs indicate the source RSA agent fails the authentication.

If the user is unchallenged, he can successfully initiate an RDP session, and get prompted by the Remote Credential Provider (either by Windows or by RSA) and it works as expected.  This second logon, if prompted for passcode of the RSA challenged user, will show the remote destination RDP host as the agent in the Authentication Manager logs.
ResolutionIn RSA Authentication Agent 7.3.2, a Remote Desktop Connection Application policy was added to the GPO template to make it easier to apply the workaround described below.

From the agent logs, it seems that the application being used to collect credentials for RDP on Windows 10 needs to be changed back to the RSA version, which is C:\Windows\System32\CredentialUIBroker.exe.

To do this, 
  1. From Start > Run, key in regedit and press Enter.
  2. Open or create the key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\RSA\RSA Desktop\Local Authentication Settings.  (On Windows10 the location is HKEY_LOCAL_MACHINE\software\RSA\RSA Desktop Preferences\Local Authentication Settings\.   You may need to search for Local Authentication Settings.)
  3. Create a REG_SZ value named RDCFileName and populate it with the FULLY QUALIFIED path to the application. Set it to C:\Windows\System32\CredentialUIBroker.exe first.

Regedit_RDCFileName.


  1. Reboot the machine and test.  

Note:  This registry change will be configurable in the GPO templates for RSA Authentication Agent 7.3.2 for Windows.


  1. If you still have the problem, check spelling and registry settings or use the GPO template.
Workaround

Initiate RDP sessions with a non-challenged RSA user


Since this may be the result of a hardening or security upgrades to Windows, you may simply need to 

  • Open up read (and possibly write, if using auto-registration) permissions to authenticated users to C:\Program Files\Common Files\RSA Shared\Auth Data folder where the securid node secret file is located. This may be due to the fact that RDP is non-priv by default, and something changed in how Microsoft calls the RSA Credential Provider through the CredUA..

To change permissions:



  1. Open Windows Explorer on the machine with the agent 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.

AuthDataProperties 


  1. Click Apply.
  2. Click OK.
  3. Now try to RDP with a challenged user again.
  4. You will see two prompts here. The first is from the local Windows 10 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.
NotesJIRA defect AAWIN-2315 has been opened to track the issue.

The Windows 10 update from 9 August 2016 contains updates to Windows authentication methods.  Listed in the Known Issues section of MS16-101, is the following note: 

This security update disables the ability of the Negotiate process to fall back to NTLM when Kerberos authentication fails for password change operations.


From the RSA Authentication Agent logs, it seems that the application being used to collect credentials for RDP on Windows 10 is now C:\Windows\System32\CredentialUIBroker.exe, rather than C:\Windows\System32\mstsc.exe. That change breaks the logic used by the RSA agent to identify the RDP use case (in which the RSA agent defers authentication to the Microsoft password provider).
1 person found this helpful

Attachments

    Outcomes