How to prevent windows credential manager data from being used?
How to prevent windows credential manager data from being used?
In my evaluation of RDM I have been following the "Team setup" videos and created a tree, secured by security groups on a parent node and applied RDP credentials from a RDM private vault through by linking to them with a user specific setting. That's all very nice really. Then, by mistake, I forgot to apply the user specific settings for some user and it was still working ... so I was wondering as to why.
It seems that I need to delete the credentials stored in my Windows credential manager to force RDM to use the credentials from the RDM private vault. Or put it this way: RDM seems to use shared credentials from the hierarchy first (which I don't have), then the windows credential manager credentials, if they exist, and the ones from RDM private vault only if they don't. (I can reproduce this by entering wrong credentials into the RDM private vault.)
I can delete the credentials from the Windows credential manager of course but how would I enforce that once RDM is deployed and installed on my co-workers machines? What if, after some time, users change their password on the server and in the RDM private vault (as they should), but there is still the (then wrong) credentials in Windows? So in short:
Is there a way to make RDM ignore Windows credential manager credentials altogether?
Best regards, Thomas.
Best regards, Thomas.
All Comments (6)
Hi,
The application does not use the Windows credentials manager If I remember correctly when using embedded RDP with the username and password saved in the database.
Were you using the embedded or external mode?
David Hervieux
Hi,
embedded mode. While searching for a solution I found this post by Maurice where he says that RDM would use the Windows CM.
Best regards, Thomas.
Best regards, Thomas.
Hi again,
In embedded mode we extract the username and password from the Credential Manager when nothing is specified in the database and we can find an entry in the CM.
David Hervieux
Hi David,
thank you for investigating. I think there may be some caching effect involved that confuses me. I need to repeat my description to make that understandable:
In the shared RDP sessions, there are no shared credentials applied. RDM should find them at a parent node (folder), where I applied the credentials from my private vault as "user specific settings". They are all using embedded mode.
This didn't work quite as expected on the weekend: I had made my private vault credentials "wrong" by adding an "x" to the domain name. RDM would still connect me - so I concluded it must be using my Windows CM credentials instead. I verified this by deleting the Windows CM credentials for one of my RDP targets, et voila, it would then fail due to the wrong domain name in private vault credentials.
Today, though, RDM failed for RDP connections, as it should, although I had not deleted the corresponding windows CM credentials. I verified this and found 2 connections where RDM connected successfully, but that was my fault - I had forgotten to set the credentials to "inherited". So I fixed that - and this is where things are getting strange:
RDM is still connecting me on these two sessions despite the domain name being wrong in my private vault. It seems as if the credentials (from the Windows CM) or from my previous successful attempt have been cached. So I closed RDM and re-opened it, but that would not help.
I'm quite confident, though, that it will work (i.e. fail as it should) tomorrow. So, don't worry, but maybe that description rings a bell ... FWIW, I made that fix to "inherited" with a bulk edit.
Best regards, Thomas.
Best regards, Thomas.
You could test the cached credentials by using mstsc.exe and see if it connect without any username/password supplied
David Hervieux
MSTSC was behaving as it should, i.e. it was connecting from Windows CM credentials and it failed to connect when I deleted the password from Windows CM credentials from within RDM in a few cases for testing purposes.
I lost my bet. Today, these 2 connections (which would connect despite my private vault connections being wrong on purpose) would still connect. Then I discovered Edit -> Edit -> Batch Edit -> Reset All Saved Credentials, tried them and now everything works as it should, i.e. these two now fail too as all the others do when I set my private vault credentials to a wrong domain name.
Please believe me that I checked multiple times ... these 2 offenders were configured identically as far as that is visible in the dialog. There must have been something "under the hood" that was deleted with the batch edit function that wasn't visible.
Best regards, Thomas.