I have the following scenario and I would like to know if (a) it's even possible, and if so (b) what is the most secure way to do this
DSC Server: Windows Server 2016 core
RDM database: SQL 2016 SP1 (mixed auth)
RDM Version: Enterprise ( latest)
From the DSC server (note - server core/no gui) I want to be able to run a script which connects to the RDM datasource and retrieves passwords for various service accounts. The DSC side of things works fine, and I already have scripts connecting to our legacy password vault via API calls.
I am aware there is a zip package for the RDM client installation which I can extract and use to retrieve and import the RDM PS module, however where do I go from here?
It seems like the set-datasource command expects an already configured datasource within RDM but obviously I can't open the GUI and to this on server core. Is there a config file I need to setup/create to do this?
Even if I do get a datasource connected, given this will ultimately want to run automated, what is the most secure way to access the datasource so that I'm not hard-coding credentials in scripts? For example in my legacy (non RDM) password vault I'm able to create an API key which is only usable from the DSC server's IP, and only has access to a specific credential entry.
Hope this makes sense, look forward to hearing what can be done.
It is possible to properly configure the data source on your computer and then transfer the RemoteDesktopManager.cfg file that you will normally find in %localappdata%\Devolutions\RemoteDesktopManager folder on the core machine. You can get the exact .cfg file path in File - Options - Advanced.
As you are using the ZIP package of RDM, it is possible to set the folder where RDM will load the RemoteDesktopManager.cfg file. Please see the following online help page about Portable installation. Please see steps 3 to 5 for the ./config folder and override.cfg file.
Thankyou for the fast response
I have sucessfully completed the following:
On the core server:
Extracted the RDM client zip file
Configured the alternate config location
On a full GUI client:
Setup a new SQL database connection using a SQL credential, with the username and password saved (not sure if this is the best way to achieve my goal, as below).
Copied the config file to the server
On the server:
Imported the RDM PS module
Successfully retrieved a credential from the database (yay!)
So, my next question is (and pertaining to point (b) in the original post) - how do I secure this setup for use in automation?
As I understand it, the config file could be picked up and used on any machine.
I can't prompt for a password when the script runs as that means it's not automated
I obviously don't want to hardcode a password in a script
For example, with my previous password vault I could limit an API key to a particular IP address, which meant even if the API key was acquired it couldn't be used anywhere else.
What would the most secure way to achieve this automation be?
Can anyone assist with the above?
Sorry for the late reply.
It is possible to create a new SQL data source in RDM through PowerShell but instead of hard-coding the username and password in the script, you can set them in environment variables and use those environment variables in your script. Let us know if that could be a viable solution for you.
Thankyou for the reply.
If the credentials are stored in clear text in environment variables, this seems to be a security by obscurity measure - to be honest I don't know why we would bother adding this layer of complexity, when the credentials are already obscured/encoded in the config file.
Being hidden in the config file would mean an attacker would need to have indepth knowledge of RDM, as opposed to being called from env variables where an attacker would only need basic scripting knowledge. It seems like the RDM obscurity is better.
Is there no better way to do this? Perhaps I should look at storing the RDM credentials in an Azure key vault which would at least give me a proper API key which I can rotate and restrict?
Sorry to jump in.
You bring a fair point... Using RDM obfuscation may be a better way.
With our Devolutions Password Server, we provide a CLI to communicate with the API, making it safer to use an APP key and secret, Log its actions, and easily manage its permission on the entries... Would that suit more your needs?
Thanks for letting us know.