cathans01

Hi David,

Any update/ETA to this feature request? Is it on the planned roadmap?

I work for a large multi-national company with delegated IT Staff at a Regional level. I'm torn between building out 1 DB and delegated permissions by Region or giving each other their own repository. There is a global group that's settings should be available to everyone in individual regions, but each region doesn't really need to see each other's information.

I think repositories is the right way to go from a scalability standpoint. It would be nice to have an 'Entry Type' that is a Link to another Source + Repository that when clicked would open that up. The entry should contain enough information that RDM could open up the Source without it having to be installed as a source in the RDM.

In my scenario, I'd log into the Global Source/Repo and there's be an Entry that says 'Europe' that when clicked, opens up the European Repository with its credentials. In the European Repo, I'd create a link/entry back to the global repository.

This may be seen as a duplication of an existing feature, but I think this approach provides a better user experience because it's just another entry, the information is already embedded and reduced the need to distribute connection profiles.

Excellent! Thank you.

When adding a new connection and selecting a repository, the UI could be improved.

1 - The column currently says 'Values' rather than Repository

2 - The Description of the Repository is missing even though you set a value when you created

Side note: It would be nice to be able to edit the Description of the default Repository so it can be displayed as well.

Thanks for the quick Reply Erica; you were right. My Issue was I wasn't specifying the username as "ADNETBIOS\username" so it didn't have access to it. once I added my AD Domain to the username it worked. (I guess this is reasonable behavior, but contrary to how the AD GUI works where I can just type in my username and it'll search)

-Chris

I'm trying to write a PS script to run my RDM Sync Importers as a scheduled task. My code this below (String vars removed).

When I call the Open-RDMSyncSession, I get an error "Warning: Connection not found"

Import-Module 'C:\Program Files (x86)\Devolutions\Remote Desktop Manager\RemoteDesktopManager.PowerShellModule.psd1'

$SecureString = ConvertTo-SecureString -String $securepassword

Set-RDMCurrentDataSource -ID $DataSourceID -Username $username -Password $SecureString

Open-RDMSyncSession -ID $syncsessionid

My Ideal view in the Favorites Navigation pane is:

Name of Entry , Descriptions, and maybe another column. I really don't want them grouped by their original folder structure--presumably, i know what they are and just need to find them by alphabetical order.

It seems I can neither turn off the grouping functionality nor rearrange/add columns to the list when I'm in List or Details Mode. This would be helpful.

Thanks,

Chris

Hi,

I'm looking for a roadmap/time frame for when the nested AD Group issue will be fixed in DVLS? Due to delegation and size of AD, we can't work around by adding directly to a single group. I'm also stuck on RDM 11 because I can't upgrade DVLS and I really would like to use the new Powershell features of RDM 12.

Thanks,

Chris

I want to use a common password stored in our RDM DB in a powershell script, but I don't want the person executing the script to know the password.

The documentation I've seen thus far indicated the credential must be flagged to view the password. Am I missing something?

If I'm indeed correct, maybe it should be a Feature Request for a PS Function to be created that can retrieve the Credential from RDM and return it to the user as a SecureString variable. This would allow for use/reuse by the user without knowing it.

Something like

$secrecredential = "PasswordFromRDMGoesHere" | ConvertTo-SecureString -AsPlainText -Force

Of course, you should probably log this separately in the session logs since once it's in a variable it could be 're-used' multiple times within a session with only 1 logged action of it being used.

Hi,

This is a question on the interaction between DVLS & RDM so hopefully this the more appropriate forum.

Test Scenario:

In DVLS DataSource, In Password Complexity, I've Created a password complexity template and set it to Enforcement to Warn.

In RDM, I've applied the Password Complexity Template as a Security Requirement for the entry. When I edit the Entry it correctly warns me about not meeting the complexity. When I use the Password Generator icon on the entry next to the password, and look in the template section, there's nothing there.

Wouldn't it make sense that if there's a password complexity requirement assigned to the entry that generating a new password when then entry is open that it automatically selects/uses the enforcement template as the basis for the generation template? Also, if the enforcement is set to Required in the DataSource, you shouldn't even be able to change the password generation template when the entry is open.

Is this a new feature request or am I missing something to link these 2 events?

Hi David,

Your understanding is correct, and I'd be willing to accept the offline limitation you mention; however, if you have a secure way of storing/caching data locally (client-side encryption) then you could also offer a feature to cache the user's 2factor secret (assuming OTP-based) during their login for x Days offline and execution 2F validation client-side.

Additionally, don't forget the elevated authentication timeout variable. If I execute a session with 2F attached at say 2pm, and then try to execute another session with 2F attached at 2:15 and the Elevated timeout value is 30 mins, I wouldn't have to use 2F for objects until 2:31pm.

Hi, I accidentally posted this same request in the RDM forum, but meant it to be here before I noticed this.

https://forum.devolutions.net/messages.aspx?TopicID=24862&MessageID=91428#post91428

I too would rather have two factor on the object level. Maybe the object or group has an option for 'Require Recent 2FA' . Somewhere 'Recent' would be defined in minutes or seconds as a timeout period before you would have re-type your 2FA Code when opening back to back sessions. Once implemented, I'd also like not enroll, but not require 2FA for authentication. 80% of our entries rely on the operator to key in their username/password so exposing session information details isn't an issue. It's the sessions that link to credentials or sessions that are high-value (accounting) that we'd like to require recent 2FA validation on.

Sorry, this should have been posted in Devolutions Server, not RDM. (although it could go in both places)

Today, when 2 Factor is checked, it's required at login. This is great, but I'd like the option to check 2factor at the Object level for High-Security Objects.

Since RDM is our main connection tool, for the 80% of the entries or so that use the prompt for the user's credentials at session, there's not much to protect. (Name, IP, etc isn't a security issue). However, when the session is linked to credentials, that may be a different story, or when you're attempting to access a specific session (Accounting for ex), you may want to always ensure 2-Factor login.

User Story is something like this: As an Devolutions Server Admin, I'd like to enroll users who need it into two-factor auth, but have the flexibility to require two-factor authentication at the Group or Object level rather than just at login so that I can be sure at the time of execution that the user is who they were at login. There should be a timeout variable since last two-factor such that If a user connects to 2 protected sessions back to back they don't have to use two-factor for both. With this feature implemented, two-factor during authentication would be possible, but not required and still enable protection of objects.

It seems as of now the two choices for user account creation are:

1 - Create users manually to allow access

2 - Allow AD Auto-Creation by any valid domain login.

Is it possible to require a specific AD Group membership in order to login--irrespective of the AD Group <-> Rights Membership groups? The end result would be that the 'public' or non-security group controlled contexts would only be visible to users that were part of the original AD Access group rather than just anyone with a valid AD login.