Stored credentials not working properly when used in conjuction with alternate shell since last weeks update
Stored credentials not working properly when used in conjuction with alternate shell since last weeks update
Last week I updated my client and our database (SQL backend). Since then, I cannot get my connections to use the stored credentials as they did previously. I updated to the latest revision this morning, but it has not helped the situation. This was all working just fine before last weeks update.
We use CyberArk PSM for remote sessions. We authenticate to it with a standard user account and PSM checks out the correct credential from the Vault upon connection by running the following program on connection: PSM /u $DATA_SOURCE_USERPROFILE_EMAIL$ /a $NAME$ /c PSM-RDP
If I have a stored credential, whether embedded or in my personal vault, it almost seems like RDM doesn't pass the credential to start the program on connection. If I enter the password here, everything downstream from there works as expected.
Here is what I see upon connection:
Here are the properties of a previously working connection:
There are no other changes made to the connection besides what is shown here. Note that the host that is used is our PSM server. The variable $DATA_SOURCE_USERPROFILE_EMAIL$ has each users admin account defined in the format user@domain.com. Finally, the $NAME$ variable is used to reference the desired endpoint to connect to.
If I do nothing else but change the stored credential to something invalid, I get the following:
If I remove the "Start this program on connection (Alternate Shell)" checkbox, the following occurs.
This is expected, as my standard user does not have permission to RDP to the PSM server.
If I change the connection so it uses an admin user that has permission to RDP to the PSM server, and nothing else (i.e. Start this program on connection is still unchecked), the connection succeeds.
I can be available for remote session, phone call, chat, whatever. Please let me know!
Thanks,
Josh
Senior Infrastructure Engineer
All Comments (10)
Hello,
The symptom that you are describing would mean that our basic inheritance stopped working, which would have resulted in our support channels being flooded by help requests.
There may be something new on the CyberArk side, could you try testing with Microsoft's rdcman and a RDP file with an adapted alternate shell command?
I just want to ensure the issue is in RDM since I dont remember having seen the PAS logon screen of your first image.
If your test with RDCMan works, I'll be happy to jump on a session with you.
Best regards,
Maurice
I forgot to mention that I tested this same configuration on an older version of RDM and it worked just like it used to. Grabbing RDCMan now.
Senior Infrastructure Engineer
Shoot, RDCMan is no longer available for download from Microsoft.
Senior Infrastructure Engineer
Hello,
You can download RDC Manager from this help article
https://kb.devolutions.net/rdm_rdc_manager.html
Best regards,
Jeff Dagenais
We block sharefile.com and all subdomains of it. Is there any other way I can get it from you?
Senior Infrastructure Engineer
Hello,
I just sent it to you via Private Message.
Best regards,
Jeff Dagenais
Thanks Jeff!
I am seeing the same behavior with RDCMan as I am with the latest version of RDM. I uninstalled the most recent version of RDM and installed 2020.1.20.0 x64. My connections work as I am accustomed to with this older version.
Was there a change in how you are handling RDP sessions with the most recent versions of RDM? Our set up has worked for a few years now and just broke last week with the update.
Thanks,
Josh
Senior Infrastructure Engineer
Hello,
Since you experience the issue with both RDCMan and RDM, it points to something else. As to why it works with the older version of RDM its really throwing me into a loop.
I guess it would be easiest to switch to a ticket, we will probably need to compare the RDP file that are generated by our various tests.
Could you send an email to ticket@devolutions.net so we get your contact info?
Maurice
Yes sir, doing that now!
Senior Infrastructure Engineer
Hello,
For the benefit of those that would fall on this topic using a search, the issue is introduced by an improvement titled"Removed the EnableCredSSPSupport option to get rid of the confusion with the NLA option" in the release notes of version 2020.3.12 (or ticket RDMW-5361 for our staff).
In resolving that confusion, a particular combination of values (or absence thereof) triggered RDM to interpret NLA as being enforced even though it had been disabled in the previous releases
The fix was to use batch edit to untick the NLA option from all affected entries (all of them in Josh's case)
Thanks @Josh for showing me the issue, we will evaluate if we need a breaking change flag or it turns out to be an edge case.
Best regards,
Maurice