Jerome,
The original version of the KB recommended opening up permissions on the node secret file as a work around, but that only postponed the problem, so that section was removed after we figured out the registry setting thanks to Engineering.
In your case, you could try the work-around but mmc may never work because Engineering never was told to plan for it and it was never tested. The problem is "In general, MMC runs under the user account and so all the problems associated with trying to authenticate from an unprivileged process apply to MMC" which translates into the latest MS update has prompted for credentials because the user is challenged and asking for network access. The Node Secret mismatch is due to user running MMC RDP not being privileged. Workarounds are risky, but include;
- Grant Read (and possibly Write*) permissions on the RSA \Auth_data folder where the node secret lives to All Authenticated Users
- Use mstsc.exe instead of mmc
- Try full path to mmc.exe as the REG_SZ value of HKEY_LOCAL_MACHINE\SOFTWARE\Policies\RSA\RSA Desktop\Local Authentication Settings\RDCFileName
- Open a case for a Request for Enhancement, RFE, basically ask Engineering and Product management if they would add this feature to the Windows Agent.
Engineering notes - [CE] commented on AAWIN-2327
Re: RCP mmc does not work on Win10 when 7.3.0 AAWIN installed, m_credState=CS_CREDUI
In general, the usage scenario CS_CREDUI denotes that the CredProvider has been called because an application has called a Windows API to prompt for user credentials. The RSA provider supports that scenario because that is used by Windows UAC to collect credentials when user's elevate privilege.
The CredProvider logs are incomplete. It looks to me as if logging was enabled after the Credential Provider was loaded and so we don't see the initialization. However, I can make a few educated guesses...
1. In general, MMC runs under the user account and so all the problems associated with trying to authenticate from an unprivileged process apply to MMC. Add to that the factoid that the WinAgent did not have a requirement to support MMC, I think we should say that MMC – and any snap-ins that run within it, are not supported.
2. The typical path to MMC is: C:\Windows\System32\mmc.exe. (The specific path can be found by using Task Manager, but I doubt it varies.) The customer can experiment with using that for the registry value identified in AAWIN-2315. HOWEVER, I don't recommend that workaround for two reasons:
1) Windows uses MMC in a variety of scenarios, so exempting MMC from SecurID authentication has significant potential security ramifications.
2) That will break the normal RDP.
Concerning other problems occurring with Windows Agent after Microsoft Security update, The Registry change to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\RSA\RSA Desktop\Local Authentication Settings\RDCFileName may prevent the Triggering of an NLA redirected to RSA challenge when accessing the network via RDP, but the Possibly Write* permissions noted above in addition to read for all authenticated users might come back into play because we have now seen Non-Admin Users unable to update an agent IP address through Auto-registration - which writes to the sdconf.rec file in the same folder as the node secret securid file. We've also noted that a Non-Admin user accessing the RSA Control Center cannot create the node secret during initial authentication using the [Test Auth] feature.
