|Applies To||RSA Product Set: SecurID|
RSA Product/Service Type: Authentication Agent for Windows
RSA Version/Condition: 7.3.1
|Issue||After 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:
Then he will see the following window if he is RSA challenged:
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.
|Cause||Initial 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:
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.
|Resolution||In 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,
Note: This registry change will be configurable in the GPO templates for RSA Authentication Agent 7.3.2 for Windows.
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
To change permissions:
|Notes||JIRA 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