Standalone – Restricted users

Hi John,

Thank you for opening this feature request.

Can you tell me a bit more how you see this feature? Would you be satisfied with a PowerShell cmdlet for managing the presets? Do you need the password to be saved along the preconfigured sessions? We could imagine a user admin with access to some administration panel for managing that, but this will take more development time to achieve.

I can’t promise when we would work on that, but we will definitely consider your suggestions. If you have any more ideas or specific requirements, feel free to share them with us.

Best regards,

No scripts would be fine, even config files somewhere....

I see it as being as the standalone edition is now, but a method to change from how it is now a quickconnect type resource, into preset sessions per each local user that I would set manually. Granted implementing multiple presets of sessions per use might complicate things a bit but as long as the user accessing the GW externally using their credentials would only see their own desktops session for RDP or multiple sessions depending on the users requirements it would fit my scenario...

Its effectively as the standalone edition is now but with kind of zero trust implementation where users only see the sessions, they have been provided....

Let me clarify the requirements a bit.

Feature 1: Restriction System

• Migrate users.txt to a SQLite database.
• Add groups with lists of IPs and subnets.
• Verify that a user has access to a specific IP before generating and returning the session token.

Feature 2: Connection Presets and Listing

• Add support for connection presets within the groups.
  • A connection preset includes a friendly name, the protocol and either a hostname or an IP.
• Add a page displaying the list of presets the currently logged-in user has access to, based on the groups they belong to.
• Clicking on a preset will open the quick connect view for the associated protocol, with the host field pre-filled.
• A preset implies that the associated IP can be accessed by users in the group without being subject to the restrictions defined in Feature 1.
• The quick connect feature can still be used as long as the rules described in Feature 1 are not violated.

Feature 3: Password Auto-Filling

• Add functionality to specify a password in the connection preset.
• When a password is specified, pre-fill the password field when the preset is clicked in the listing.

Each feature builds upon the previous one:

1. Feature 1 can be implemented relatively easily, as it doesn't require changes to the frontend.
2. Feature 2 involves more effort on the frontend and would require an additional developer.
3. Feature 3 builds on Feature 2. Since passwords require special handling, this functionality should be carefully addressed as a separate concern.

Does that sound like what you want? I understand that Feature 1 could unlock your use case. This allow you to restrict accesses while not being the most convenient for your users. The other features would be making things more convenient for them.

Let me clarify the requirements a bit.

Feature 1: Restriction System

• Migrate users.txt to a SQLite database.
• Add groups with lists of IPs and subnets.
• Verify that a user has access to a specific IP before generating and returning the session token.

This part I would actually add the user to the gateway hosts local users and groups, which is already implemented isn't it?

Feature 2: Connection Presets and Listing

• Add support for connection presets within the groups.
  • A connection preset includes a friendly name, the protocol and either a hostname or an IP.
• Add a page displaying the list of presets the currently logged-in user has access to, based on the groups they belong to.
• Clicking on a preset will open the quick connect view for the associated protocol, with the host field pre-filled.
• A preset implies that the associated IP can be accessed by users in the group without being subject to the restrictions defined in Feature 1.
• The quick connect feature can still be used as long as the rules described in Feature 1 are not violated.

This feature I forsee it not using any user preset selection via the Web app, but the available sessions would actually be defined by the admin / myself via a settings file somewhere, effectively using some sort of templating functionality, when the user logs in, building on feature 1 the gateway sessions page would dynamically generate the users sessions from the templating from the preset settings file. As the users are being manually set on the gw host the preset settings file would use some sort of username matching to associate the logged in user with there predefined presets from the settings file / templating file.

Feature 3: Password Auto-Filling

• Add functionality to specify a password in the connection preset.
• When a password is specified, pre-fill the password field when the preset is clicked in the listing.

This feature I would have left to be filled by the user, this would allow the user to fill the sessions credentials themselves.

Each feature builds upon the previous one:

1. Feature 1 can be implemented relatively easily, as it doesn't require changes to the frontend.
2. Feature 2 involves more effort on the frontend and would require an additional developer.
3. Feature 3 builds on Feature 2. Since passwords require special handling, this functionality should be carefully addressed as a separate concern.

Does that sound like what you want? I understand that Feature 1 could unlock your use case. This allow you to restrict accesses while not being the most convenient for your users. The other features would be making things more convenient for them.

Let me know if my notes make sense. As long as the gw user logging in had there sess that wrre oredifined then it would fill my scenario? The main use case is for each gw user to have at min 1 rdp session generated for there office desktop with any additional sessions being set as required but as previously mentioned the desktop ip for rdp i would define myself via the settings file.

Just to add the min session of the users RDP session, the user probably doesn't know the hosts IP / host name, so this would be predefined, also generally the rdp would be to an Entraid joined client so will need to prefix the username with .\azuread\, the user will know there upn for username and there password so these would be the only custom cred fields to be filed by the user, everything else would be predefined in the setting file for each user (sufficient for my scenario) / groups (could be used for preset matching for larger deployments)

> Feature 1: Restriction System
> […]

This part I would actually add the user to the gateway hosts local users and groups, which is already implemented isn't it?

I’m sorry, I’m not sure to follow you here. Do you mean that we should be able to specify restrictions at the user level (as well as groups for completeness)?

> Feature 2: Connection Presets and Listing
> […]

This feature I forsee it not using any user preset selection via the Web app, but the available sessions would actually be defined by the admin / myself via a settings file somewhere, effectively using some sort of templating functionality, when the user logs in, building on feature 1 the gateway sessions page would dynamically generate the users sessions from the templating from the preset settings file. As the users are being manually set on the gw host the preset settings file would use some sort of username matching to associate the logged in user with there predefined presets from the settings file / templating file.

To clarify, I didn’t mean to say that the configuration would happen in the web application. However, I’m not sure it would be a user-readable configuration file either. Since the data will be relational, I think it would make sense to use a single-file sqlite database to work with that more efficiently. In this case, you would need to interact with the database using a PowerShell cmdlet. Of course this decision is not set in stone yet!

> Feature 3: Password Auto-Filling
> […]

This feature I would have left to be filled by the user, this would allow the user to fill the sessions credentials themselves.

Got you, I’ll not include this as part of your feature request then.

Just to add the min session of the users RDP session, the user probably doesn't know the hosts IP / host name, so this would be predefined, also generally the rdp would be to an Entraid joined client so will need to prefix the username with .\azuread\, the user will know there upn for username and there password so these would be the only custom cred fields to be filed by the user, everything else would be predefined in the setting file for each user (sufficient for my scenario) / groups (could be used for preset matching for larger deployments)

If I understand you correctly, you want the ability to have a property “this is an Entra joined machine” that will transparently add the “.\azuread\” prefix to the user name when logging in so the user only needs to enter their UPN/password. Is that correct?

Shall I try again with my scenario?

**Feature Request:**

**Current Functionality:**
- The Web App allows authenticated users to initiate quick connect sessions.

**Proposed Enhancement:**
- Instead of limiting authenticated users to quick connect sessions, I would like to introduce the ability to set specific sessions for users. This would include:
- Displaying specific RDP sessions to users in the Web App.
- Utilizing the user's UPN (User Principal Name) and password to authenticate and grant access to their designated sessions.
- Enabling users to connect directly to their office desktops running Windows 11 Enterprise, joined to the domain / entraid in my case .
- Expanding the customization of sessions beyond RDP, allowing for various session types as required by different use cases.
- Ensuring that session settings are configurable by the admin to tailor the user experience based on organizational needs and policies.
- admin will have a basic configuration method ie json, yaml, ini etc for controlling these customisations, with access control for user / group name matching for assignment of customisationss

**Use Case:**
- This feature would provide users with seamless access to their personalized sessions, particularly for accessing their office desktops securely and efficiently. It would enhance user productivity by streamlining the connection process and ensuring they have the necessary resources readily available.

Apologies, this was copilot'd lol

Let me go through your points to make sure I understand your request.

- Displaying specific RDP sessions to users in the Web App.

✔ A listing of the administrator-configured presets for the current user.

- Utilizing the user's UPN (User Principal Name) and password to authenticate and grant access to their designated sessions.

？ Mostly like the current quick connect window, but with the hostname field prefilled/locked to the preconfigured value?

- Enabling users to connect directly to their office desktops running Windows 11 Enterprise, joined to the domain / entraid in my case.

？ I believe we already support connecting to domain joined desktops, but you need to add the “.\azuread\” prefix to the user name. In this point, do you request the ability to have a checkbox “this is an Entra joined machine” that when checked will transparently add the “.\azuread\” prefix to the user name when logging in so the user only needs to enter their UPN/password?

- Expanding the customization of sessions beyond RDP, allowing for various session types as required by different use cases.

✔ The same as RDP presets, but for SSH, etc.

- Ensuring that session settings are configurable by the admin to tailor the user experience based on organizational needs and policies.

✔ Only the administrator can modify the presets.

- admin will have a basic configuration method ie json, yaml, ini etc for controlling these customisations, with access control for user / group name matching for assignment of customisationss

？ Is using a textual configuration file very important for you? Would you be okay with PowerShell cmdlets interacting with a SQLite database?

Let me go through your points to make sure I understand your request.

Displaying specific RDP sessions to users in the Web App:

✔ A listing of the administrator-configured presets for the current user.

Utilizing the user's UPN (User Principal Name) and password to authenticate and grant access to their designated sessions:

❓ Mostly like the current quick connect window, but with the hostname field prefilled/locked to the preconfigured value?

Effectively just like it is now for quickconnect sessions but the hostname prefilled, username and password can be user filled, if its possible without much fuss having the option of using credentials taken from the Gateway login, or to make it perfect also the option to use EntraID SSO (like you can in RDM RDP entries.).

Enabling users to connect directly to their office desktops running Windows 11 Enterprise, joined to the domain / entraid in my case:

❓ I believe we already support connecting to domain-joined desktops, but you need to add the “.\azuread\” prefix to the username. In this point, do you request the ability to have a checkbox “this is an Entra joined machine” that when checked will transparently add the “.\azuread\” prefix to the username when logging in so the user only needs to enter their UPN/password?

This is just an extension of step 2, again like in RDM RDP entries the option to set that the host is EntraID Joined (This is the main reason for this additional step), as you mentioned domain auth is built in as default to RDP.

Expanding the customization of sessions beyond RDP, allowing for various session types as required by different use cases:

✔ The same as RDP presets, but for SSH, etc.

Basically the admin would be able to set preset entries for users to match the standalones functionality now although rather than the single quickconnect entry they additional session options would obviously be tiled entries on the web app

Ensuring that session settings are configurable by the admin to tailor the user experience based on organizational needs and policies:

✔ Only the administrator can modify the presets.

Admin will have a basic configuration method (e.g., JSON, YAML, INI) for controlling these customizations, with access control for user/group name matching for assignment of customizations:

❓ Is using a textual configuration file very important for you? Would you be okay with PowerShell cmdlets interacting with a SQLite database?

Powershell cmdlets would be fine but if possible to manually edit whatever configs / modifications the powershell cmdlets themselves work with. I dont know what the cmdlets modify themselves files or the db, if its files that they modify / configure then having those files grouped together in an restriced path for the admin to access as an alternative config option in addition to the cmdlets (but cmdlets will be fine if it saves you work, the secondary method mentioned isnt critical requirment if it would create excessive work for you guys).

Thank you for going through that with me!
I’ll open the internal ticket and submit the feature request.

Have a great day,

Hi Benoit,

I have been periodically watching the Devolutions Gateway repository, and I like what I've seen and see, although tbh I've not actually played around with the new additions and changes, I will have a play around with the web app form configuration stuff that's mentioned in the cookbook devolutions-gateway/webapp/docs/cookbook.md at master · Devolutions/devolutions-gateway, from what I've read and read it's just what I wished for from Gateway Standalone so wish me luck! I realise this is a work in progress with commits daily, so it won't be used for anything in production. I'll let you know how I get on.

I really appreciate everyone's hard work regarding Gateway development its very much appreciated...

Good Morning to all

This is an interesting topic.

I actually have a similar request what concerns Gateway WebUI Access.

For the moment it can be configure with a user.txt but it would nice to have an option to allow the users dynamically from the users groups created in Devolutions, such as Local AD or Entra ID.

This would allow easy user management and the possbility to use a WebUI to access resources.

If this feature is already available, I apologize for the "bump" to this topic.

TY in advance.

Have all great day.

BR,
Greg

Good Morning to all

This is an interesting topic.

I actually have a similar request what concerns Gateway WebUI Access.

For the moment it can be configure with a user.txt but it would nice to have an option to allow the users dynamically from the users groups created in Devolutions, such as Local AD or Entra ID.

This would allow easy user management and the possbility to use a WebUI to access resources.

If this feature is already available, I apologize for the "bump" to this topic.

TY in advance.

Have all great day.

BR,
Greg

@GGORG


Hi gorg, you probably jumped in on my Feature request down stream a bit as that was my big request as per above, that as mentioned looks to be slowly coming to life thanks to the team who queried my wants in detail in past posts above and look to have been delivering most parts.... 👌👍 Although, I'm only making educated guesses from my very very limited coding knowledge to come to all these assumptions which could be completely off base lol.

But every now and then ill checkup on the repo and go through the commits etc and going through the changes. Rust defiantly isn't in my wheelhouse of skills, only Python, so again, I'm going by educated guesses.

I would like to ask how much of what's in the repo is now usable with current public PowerShell modules / PSRepo releases?? I do really need to revisit my PowerShell 101 again I think, as I would need to use PowerShell's help related cmdlets / cmds to actually work that question out myself without extensive documentation on the PowerShell modules / PSRepos from you guys, Although, being as lazy as I am, Ill prob let GitHub Copilot decipher the repo for me which gets better every week.....

Thanks for you reply and the info regarding the user config txt file👍