Simon Leroux

Hi @Simon Leroux!

 I confirmed that the problem is solved! I hadn't have noticed that the version that was being shown in web version was 3.12. I opened an anonym tab in another browser and it worked!

 Thank you very much!

Regards,

Elaine

Hi @elaineberenguer

Glad to hear it’s working now, and thank you for the feedback. It helps us improve our products.

Best regards,

Simon

Hi Elaine,

Thanks for updating and for the screenshots.

We retested this exact scenario on Devolutions Server 2026.3.13.0: an RDP entry that prompts with a folder of DVLS Privileged Account entries, opened in the web interface. It works on our side. The error you see is the one the previous version showed, so your browser is most likely still running the old web interface files from its cache.

Could you try the following?

1. Do a hard refresh in the web interface (Ctrl+F5), or open it in a private window.

2. Check the version under About in the web interface, and confirm that it shows 2026.3.13.0.

3. Open AVC RDS Server again and pick Suporte FUR from the list.

If the error still shows after that, please open the browser developer tools (F12) on the Network tab before you connect. Then send us the response of the next-action or validate-credential-for-web-client request that fails. That will show us exactly which check rejects the entry.

About the log you shared: that error comes from the Microsoft Entra ID synchronization. It could not find one user object in Microsoft Graph, and it is not related to opening the session. If it keeps coming back, feel free to open a separate thread so we can look into it.

Best regards,

Simon

Hi Elaine,

The bug we logged for this issue (DVLS-15592) has been fixed and is available in Devolutions Server 2026.3.13.0. Once you have updated, you can set AVC RDS Server back to prompting on the Credenciais TS folder instead of using the workaround.

Thanks again for the detailed report!

Best regards,

Simon

Hi elaineberenguer,

Thank you for checking all the entries and for the detailed screenshots. Your configuration is correct.

We reproduced the issue on our side, and it is a bug in the web interface. When an RDP entry prompts for credentials from a folder and you pick a DVLS Privileged Account from the list, the web interface checks the selected entry in a way that rejects it, even though "Use active DVLS workspace when available" is enabled. That is why you get the error, followed by "AVC RDS Server cannot be opened at this time". The Launcher does not run that check, which is why the same configuration works there.

We apologize for the inconvenience. We have logged this for our team to fix (DVLS-15592), and the ticket is linked to this forum post.

In the meantime, here is a workaround we confirmed: on AVC RDS Server, set the credentials to one specific privileged account entry (for example Suporte FOR) instead of Prompt on connection on the Credenciais TS folder. With that configuration, the session opens correctly in the web interface. If the contractor needs to choose between several accounts, the Launcher remains the option until the fix is available.

Best regards,

Simon

Hi Elaine,

Glad the Launcher is working now, thanks for confirming.

About the web interface error: the check is made on the DVLS Privileged Account entry you pick from the list, not on the RDS entry. Since AVC RDS Server prompts with the Credenciais TS folder, the web client checks whichever entry you select (Projeto MAT 3, Suporte CCA or Suporte FOR) when you connect.

In the web interface, a DVLS Privileged Account entry can only be used when it runs against the session you are already signed in with. Each entry needs these settings:

• Use active DVLS workspace when available: enabled

• Use “My account settings”: enabled (or a username that matches the contractor account signed in to the web interface)

The Launcher is more permissive: when an entry does not use the active workspace, it can open a separate connection to the Host URL. That is why the same configuration works there (and why you saw the extra login prompt before). The web interface cannot open a second connection, so it shows this error.

Could you check that Projeto MAT 3 and Suporte CCA have the same settings as Suporte FOR? If the error still shows after that, let us know which entry you picked from the list when it happened.

Best regards,

Simon

Hi Elaine,

Thank you for the detailed post and the screenshots, and sorry it took us a few days to get back to you.

Here is what we found so far for each behaviour.

Launcher: Devolutions Server login prompt

When Use active DVLS workspace when available is enabled, the privileged account entry should use the session you already have in the Launcher. The login window you see means the Launcher did not find an active Devolutions Server data source to use. It then opened a new connection to the URL in the Host field, which is why you are asked to sign in again.

This usually happens in one of these situations:

• The option is enabled on Suporte FOR, but not on the other privileged account entries (Projeto MAT 3, Suporte CCA).

• The Launcher is running in offline mode or from its local cache, so the active data source is not seen as a live Devolutions Server connection.

Web interface: “Use active DVLS workspace” error

Your configuration (active workspace + “My account settings”) is supported in the web interface. However, this error can also appear when the privileged account cannot be resolved for the signed-in user, even if the option is enabled. The most common cause is a permission issue: the contractor user needs the right to use the privileged account itself (for example for.suporteIFS) in the PAM vault. Being allowed to see the entry in the contractor vault is not enough.

To narrow it down, could you share the following?

1. The version of the Launcher you are using (Help > About).

2. The settings of the other two privileged account entries, and whether the login prompt appears for all three or only some of them.

3. Whether the Launcher is connected online to your Devolutions Server data source, or running in offline or cached mode.

4. How the credentials are configured on the AVC RDS Server RDP entry: linked to one entry, or set to prompt with a list from the Credenciais TS folder.

5. Whether the contractor user has permission to use the PAM accounts behind these entries (for example for.suporteIFS) in the PAM vault.

This information could help us find the cause of both behaviours.

Best regards,

Simon

Hi Simon,

Any news about this issue? In which next release is this fixed?

Hi @hjbos,

Devolutions Server 2026.3.8.0 was just released, and it includes the fix for this issue.

Thanks for your patience, and let us know if you still see the problem after updating.

Best regards,

Simon

Hi hjbos,

To add a bit more detail to Sayed's reply: the issue happens when you use the search field in the JIT (Just-In-Time) group selection list. When you add a group from the search results, any selected groups that don't match the current search are removed.

Until the fix is released, you can work around it by not using the search field. Instead, scroll through the list and check the groups you want to add directly. Your existing selections will then be kept.

Sorry for the inconvenience, and thanks for reporting it.

Regards,

Simon

Hi hjbos,

Thank you for this information, we will try to reproduce this behavior on our end.

Best regards,

Simon Leroux

Hi,

Thank you, that detail is very helpful. If the account stayed enabled in Devolutions while disabled on the provider side, it means the sync detected the disabled status but never applied it locally. Since our notification logic fires on an enabled→disabled transition, and the local status never actually flipped, each sync run treats it as a new transition — hence the repeated hourly emails.

This looks like a separate issue from the one we fixed previously: the disable action from the sync isn't being applied in Devolutions. We're looking into it. In the meantime, manually disabling the account (as you did) is the right workaround.

Could you confirm which authentication provider you're syncing with (AD, Entra ID, LDAP...)? That'll help us reproduce it.

Best regards,

Simon Leroux

Hello hjbos,

Thanks for the update, and sorry to hear you're still seeing this.

Here's the expected behavior: a notification is only sent when the system detects a transition in the account's sync heartbeat — i.e., when an account goes from "in sync" to "out of sync." Once an account is flagged as out of sync, subsequent checks are skipped and no new notification is sent, until the account goes back to "in sync" and then fails again — at which point a new notification is sent, since that's a new failure event.

Given this, if you're still receiving repeated alerts for the same account, it's likely its sync status is toggling between "in sync" and "out of sync" rather than staying consistently disabled — each toggle would legitimately trigger a new notification under this logic.

Could you confirm roughly how many notifications you've received and over what time window? We'll also dig into this further on our end. Thanks again for your patience.

Best regards,

Simon Leroux

Hi,

A few questions before reporting a bug:

Are you using JIT privilege elevation?

When you say that mstsc works correctly, do you mean after performing JIT privilege elevation with RDM, and then running mstsc?

Have you try to configured a replication latency in the JIT privilege elevation provider settings? If not, I suggest you try a 5-second delay, just for testing. If it's works, you can try lower value.

Best regards

Simon Leroux

Bonjour maximetremblay,

Merci pour cette demande de nouvelle fonctionnalité. C'est une fonctionnalité intéressante.

J'ai ouvert un ticket pour évaluer la faisabilité et nous allons considérer l'inclure dans un release futur.

Salutations

Simon Leroux

Hi bryan_ricciardo,

Thank you for the detailed feature request and for sharing the use case.

The building blocks for what you describe already exist in the Devolutions PowerShell module and the DVLS REST API. Here is how to wire them together today, plus the one small workaround you will need.

A quick note before the snippets: the PowerShell examples below are provided as a starting point to illustrate the intended flow. They have not been executed end-to-end as written in your specific environment, so please treat them as a reference rather than a guaranteed turnkey script — minor adjustments (parameter values, folder IDs, credential prompts, error handling) may be needed when you adapt them to your fleet. If anything behaves unexpectedly or you would like help validating the workflow against a real DVLS instance, our support team will be happy to assist — do not hesitate to reach out.

1. Create a standalone PAM credential

$cred = New-DSPamAccount `

-CredentialType Standalone `

-Name 'linux-bootstrap' `

-FolderID $folderID `

-Username 'svc_bootstrap' `

-Password (Read-Host -AsSecureString) `

-Description 'Bootstrap account used by the Linux SSH provider'

Checkout policy and permissions can then be set with the standard PAM cmdlets (Get-DSPamCheckoutPolicy, Get-DSPamAccountSecurity).

2. Create a Linux SSH PAM provider

New-DSPamProvider `

-CredentialType LocalUser `

-Name 'linux-fleet-east' `

-Host 'host.example.com' `

-Port 22 `

-Username 'svc_bootstrap' `

-Password (Read-Host -AsSecureString)

Heartbeat mode, SSH key rotation type/bit count, timeout, and gateway are all exposed on the underlying provider connection (PamProviderConnection). They can be set on creation via the dynamic parameters or adjusted afterwards through Update-DSPamProvider.

3. Link the provider to the standalone credential (current workaround)

New-DSPamProvider does not expose -LinkedCredentialID for the LocalUser type, and it does not return the created provider object. Until that lands, fetch the provider back, mutate it, and push it through Update-DSPamProvider -InputObject:

$provider = Get-DSPamProvider | Where-Object label -eq 'linux-fleet-east'

$provider.ProviderLinkedCredentialID = $cred.ID

Update-DSPamProvider -InputObject $provider

Or do create + link via the REST API:

POST /api/pam/providers # create / update provider, body includes CredentialConnectionID

POST /api/pam/credentials # create credential

GET /api/pam/providers/summary # filter by linked credential

POST /api/pam/providers/{id}/quick-scan # account discovery

The PamProvider DTO carries CredentialConnectionID so the REST round-trip can do both create + link in a single call if you prefer to skip PowerShell entirely (useful for Ansible uri tasks).

4. Create managed SSH accounts under the provider

New-DSPamAccount `

-CredentialType LocalUser `

-Name 'linux-root-host01' `

-ProviderID $provider.ID `

-FolderID $folderID `

-Username 'root' `

-Password (Read-Host -AsSecureString)

Rotation and heartbeat are driven by Account Lifecycle Policies — Get-DSAccountLifecyclePolicyCommand lists them, and the policy ID can be attached to the account. Checkout / check-in cycles use Invoke-DSPamCheckout / Invoke-DSPamCheckin, and Reset-DSPamPassword triggers an on-demand rotation.

Ansible / CI/CD shape

For Ansible the easiest pattern is to wrap the three steps above in PowerShell (win_shell / shell with pwsh) per host or per host-group, idempotent on the provider name. If you need a pure-HTTP path, the REST routes listed above cover the same surface.

Our support team is also available should you need any assistance. Feel free to let us know if this helps.

For reference, the full Devolutions PowerShell cmdlet catalog (including the DS PAM commands used above) is documented here:

https://docs.devolutions.net/powershell/powershell-commands/

Regards,

Simon Leroux

Hi cyrillschreiber,

Thank you for sharing this request.

Our password generator is designed around security best practices, and this isn't something we're looking to implement in the short term.

We do understand that real-world environments can come with constraints, and we appreciate you taking the time to describe your use case.

Best regards,

Simon Leroux

Hi Christian,

As Luc mentioned a few days ago, we were actively working on this feature. Your two suggestions have been added to the password rotation schedule in RDM and DVLS.

It is currently available in 2026.2 beta version.

Thanks again for your feedback.

Simon

Hello,

Thank you for contacting us about this.

I have created a ticket regarding this issue and we will review it shortly.

Best regards,

Simon Leroux