justpaul

Crowdstrike Friday has exposed operating systems and kernel-level software like antivirus as potential single points of failure, causing outages that DR plans may not have adequately prepared for.

We are being asked to enhance the break-glass part of our DR plan to make it more resilient. Everyone in the infrastructure team has hardware-encrypted USB thumb drives they keep with them whenever possible that have exports of RDM/DPS passwords in encrypted zipfiles for maximum portability. Additionally, they have a “portable app”-ish copy of RDM on the USB they can run locally (RDM is usually a published app run out of the datacenter). On a scheduled basis, we run exports via PowerShell to create team-specific backups of just what they should have access to, using all the parameters to include all available data, including attachments and documentation. The issue is how to read the exported RDM file.

Ideally, RDM would be able to natively open an RDM XML export. However, when we add a data source of XML and point it to an 80MB RDM export file, the file is truncated to 5MB and all of the documentation and attachments are gone. Opening an XML backup in RDM would not be a data destructive event. If we create a SQLite data source and import it, we have the attachments but we do not have the documentation tab, However, importing the 80MB RDM file can take 20 to 30 minutes, which would be rather stressful amount of time during a DR.

In summary, we’d love a way for RDM to be able to read an RDM XML export in a read-only, break-glass way that showed all properties, including attachments and documentation.

+1 this request. Native, no-code support for LAPS in RDM would be ideal.

You could do this in Powershell.

1. Create a Windows task that runs as you, only when logged in (do not save password) and set it to run at a specific time

2. For the task's action, point it to a script that opens your sessions, it could be as easy as this:

Import-Module Devolutions.Powershell #Imports module (assumes you've already installed it)
Get-RdmInstance # useful to confirm which instance you are connected to
Open-RdmSession -ID 56adf7f5-xxxx-xxxx-xxxx-e007c4xxxxxx #check the session's properties to get its ID
Open-RdmSession -ID 56adf7f5-xxxx-xxxx-xxxx-f007c4xxxxxx #check the session's properties to get its ID
Open-RdmSession -ID 56adf7f5-xxxx-xxxx-xxxx-g007c4xxxxxx #check the session's properties to get its ID

Due to a particular configuration element no longer being supported in our default.xml, we needed to update it the default.cfg to no longer have that element. This led to confusion on our end-users' who didn't know if they should click accept or ignore when opening RDM. We have since set the GPO to not prompt and to just import the default.cfg when it changes. This also caused confusion because a lot of their particular settings/themes get changed back to the way it was when they opened RDM for the first time. We tried editing the default.cfg and removed all of the settings we did not need control over, hoping that what would happen is the default.cfg would only overwrite those settings explicitly within the default.cfg. Instead, anything not in the default.cfg was reset back to application defaults. The ask is that a partial default.cfg will only overwrite those explicit settings and leave the rest alone.

For example. Let's say I launch RDM for the first time, which will import the default.cfg so my datastores are preset for me. I go into options and change my theme to dark. Sometime later, the admin needs to change a particular setting in RDM (for example. <NoInternetConnection>true</NoInternetConnection>). Currently, there is no way for the admin to change that setting without resetting my theme back to default white and causing confusion.

Bumping this feature request. It's one of the main pain-points that is keeping my users from replacing their existing tools with RDM/DPS.

That fixed the MFA, thank you! The app creds still do not work.

PS C:\> $dsname = "xxxxdevolpsrv01app"
PS C:\> $ds = Get-RDMDataSource -Name $dsname
### I get an MFA prompt, which is unexpected, since we are asking it to get the datasource for the app cred datasource, not our interactive datasource
PS C:\> Set-RDMDataSource $ds
PS C:\> Get-RDMdataSource

ID          : 402d92ac-5db1-47d7-9b94-d5865611bb65
IsConnected : True
IsOffline   : False
Name        : xxxxdevlpsrv01
Type        : RDMS

ID          : dac85dbd-845f-482f-9f58-b723896e940d
IsConnected : False
IsOffline   : False
Name        : xxxxdevolpsrv01app
Type        : RDMS

Devolutions Server v2022.3.8.0

RDM v2022.3.30.0 64-bit

RDM PS module v2022.3.1.2

PSCore v7.3.1

We find ourselves unable to connect to our DVLS datasource again. Assistance from the PS team would be appreciated.

We use MFA for our connections and started noticing we were getting double-prompted for MFA and after successfully logging in, we get a prompt to go into offline mode.

As a workaround, we have registered an app in DVLS and attempted to login using the code below with no success.

PS C:\> $dsname = "xxxxdevolpsrv01"
PS C:\> $dsurl = "https://xxxxdevolpsrv01.xxxxxxxxxx.net/dps"
PS C:\> $appkey = "d029a000-320f-xxxx-xxxx-xxxxxxxxxxxxx"
PS C:\> $appsecret = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
PS C:\> $ds = New-RDMDataSource -DVLS -Name $dsname -Server $dsurl -ScriptingTenantID $appkey -ScriptingApplicationPassword $appsecret -SetDatasource
PS C:\> Set-RDMDataSource $ds
PS C:\> Get-RdmDataSource

ID          : 8076da6f-b328-4bcc-9831-df9661ab7176
IsConnected : False
IsOffline   : False
Name        : xxxxdevolpsrv01
Type        : RDMS

ID          : 450acbea-8be7-48e8-8392-aea66f094e22
IsConnected : True
IsOffline   : False
Name        : Local Data Source
Type        : SQLite


PS C:\> Get-RdmInstance

ApplicationVersion OptionFilename
------------------ --------------
2022.3.1.2         C:\Users\xxxxxxxx\AppData\Roaming\Devolutions\RemoteDesktopManager\RemoteDesktopManager.cfg

PS C:\> Get-RdmDiagnostic

Serial                        LicenseType IsLicenseValid IsLicenseExpired
------                        ----------- -------------- ----------------
xxxxx-xxxxx-xxxxx-xxxxx-xxxxx Enterprise            True            False

PS C:\> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.3.1
PSEdition                      Core
GitCommitId                    7.3.1
OS                             Microsoft Windows 10.0.17763
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

PS C:\> get-module -ListAvailable RemoteDesktopManager | select version

Version
-------
2022.3.1.2

PS C:\>

That's great news! Thanks, team, I look forward to using it once deployed.

Obligatory xkcd: xkcd: Password Strength

I think this would be a cool feature, too. I typically use correcthorsebatterystaple.net for generating passphrases instead of the generator in RDM.

Team, I completely understand the challenge of trying to get from where you were to where you want to be when it comes to authentication types, .NET Core, 32bit vs 64bit, etc. but as a customer, I am hoping we find a solution that doesn't involve a rapid deploy of RDM and DPS upgrades simultaneously. We run A/B deployment rings and will usually have about half on latest and half on n-1 versions. It also means I can lazily deploy patches to my rings and let them migrate over during their next log off/on. Most of the time, this works great but when we have a deployment like RDM/DVLS 2022.2.x.x where they both had to be updated at the exact same time, we had to collapse the rings and force log offs, etc. Not the end of the world, but I'd like to see more grace time in the products, where both RDM and DVLS can support current and at least one major version behind of each other.

Thanks,

Paul

For security reason I disable all links except trusted sites. I'll try to uninstall RDM and test it again.

BTW, ftp function was not stabilized, sometimes it refreshes all the time that I can't do anything, and if I delete all the files in directory, I can't go back parent directory.

Regarding ftp, it's best to open a new thread to keep things from getting muddled and to make others who might be experiencing similar issues able to find an existing thread more easily.

The internal FTP is not the best and we use RDM's ability to encapsulate the external FileZilla into an RDM tab. That being said, I was curious about your symptom and I tried to recreate it. I took a test FTP and set it to use the native client and then created some test folders and a bunch of test files.

I then deleted all of the files.

and was able to go up to the Parent Folder (testing) by double-clicking the ..

That being said, if I just let the native FTP idle, I do get a disconnect.

Could be that the server is not seeing any activity, I'm not sure. My recommendation is to use FileZilla embedded.

-Paul

Most likely, you are being disconnected due to the session being idle. If you haven't already, enable TCP Keepalive on your SSH servers:

SSH Session Timeout - TCP Keepalive - .matrixpost.net

Then, in the properties of your session in RDM, in the Advanced tab, check the "Enable TCP keepalives" option (not enabled by default).

Our startup time is about 6 seconds when OTP is not required, which our customers consider acceptable given that they launch RDM once a day.

Can confirm the resize issue affects RemoteApp over RDP as well. Resizing only works at the corners for us. I can't say for certain what version introduced this behavior, I recall it happening before 2022.1.27.0 but simply acclimated to using the corners for resizing.

Yes, we have multiple groups that should not be able to see each other's data. I'm sure there is more than one way to do this, but here's what we did that works for us:

In DVLS, by default, folders are created with Everyone having all permissions. You will want to modify all of the folders you do not want group 1 to see by removing the Everyone permissions and setting the permissions to allow just the group(s) that should have permissions to those folders.

Using the web client, go to the properties of the vault and set the permission "Add in root" to Custom and select a privileged group (create one, if needed) that will be tasked with creating folders off the root. This is so a folder isn't created accidentally at the root without the appropriate permissions set.

Next, for each of the folders at the root-level, you will need to set the permissions to Custom. Here, the "Grant Access" button is your best friend for quickly adding permissions. For all of the folders that you want to secure from others, you will want to minimally set the View permission to the appropriate group(s), again, creating the groups if they don't already exist.

Repeat the above step for each root folder, securing them so that just the appropriate groups have the correct permissions.

Edit: I forgot to add the link to the documentation on securing entries in DVLS: Permissions (devolutions.net)

Thanks for the update, Richard. Would you please provide additional details for:

• Core - Fixed issues in the login process

Thanks,

Paul

Ouch. This hit us. We had 2022.1.23 on our planned patch for this week, but did not realize the critical nature from the Release Note:

Fixed an important start up issue

Ideally, this would have been marked, Critical/Breaking Bug, but it does bring up an interesting question:

When a critical bug is found in a Devolutions product, what is the official channel that will be used so customers have a single, consistent location to find these critical bugs. Would the blog be the location?

Great work, Richard. We have confirmed the MFA is back using the slick browser pop-up. Two observations:

1. On our VDI, it is using IE as the default pop-up (we have not investigated what their default browser is, yet). Is it possible to force the pop-up to use a modern browser like Edge Chromium?

2. The MFA prompt only seems to happen once a week or so. We are not sure if that is a token timeout or if it is from our VDI lifecycle (they get patched/cycled weekly). Can you provide additional insight as to MFA token timeout and if the token is expected to remain active even after logoff?

We are very happy to see MFA is back, thank you!

I definitely see both sides here. From our pen-tests, we know that an attacker gaining/stealing user identity in Windows Active Directory is trivial (kerberoasting, pass the hash, etc). For that reason, we were really happy for the "belts and suspenders" option of an additional MFA layer. I also see Devolutions' desire to move this back onto the client via something like OAuth with SAML for identification/authorization.

We started doing publishing management applications via Microsoft RDS to ensure everyone was using the latest tools and to minimize configuration drift. This also allowed us to implement MFA at the RDS Gateway. With the latest RDM/DPS change, we are going to block access to DPS except from published apps to ensure MFA requirements are still met. If you are interested in how we did it, let me know and I can write up a blog and post it to the forum.

Closing the loop on this, version 2021.2.0.29 has fixed the issue and I am now able to connect to my RDM with an enterprise (DPS) backend without issues. Thanks to Jonathan Lafontaine for doggedly stick with this until it was fixed!

Hay Jasper, we do something similar here where, most of the time, when our users close an RDM tab they want to log off the session. Our RDM is configured to automatically log off when disconnecting. In those times where they want to keep the session running, they disconnect from within Windows by clicking the Start Menu, Click on the Power icon and click Disconnect.

While it is more clicks than if RDM prompted, our users have accepted this as a solution.

Andreas, does your webpage have javascript to prepend your domain name on submit?

I would not mind at all, happy help to the community. Thanks!

Sorry for the delay. Yes, I have a non-user facing DEV box that is built using the same scripts as production, so functionally identical. We can break that all day long to assist in isolating the issue.

Hey Richard, what I noticed was to get Windows Authentication working, I needed to create an SPN and then configure IIS to use the AppPool credentials to decrypt Kerberos tokens. After that, it worked perfectly. I documented my steps for deploying a new server from scratch as an HA node in the forum for anyone else who may want to do something similar. Thanks.