PAM account names reset to SAM account name after update

Resolved

PAM account names reset to SAM account name after update

avatar

Hi,

We have two issues after the updates from RDM 2025.2.30.0 to 2025.3.20.0 and DVLS 2025.2.14.0 to 2025.3.4.0.

- Our PAM vaults disappeared from RDM (client installation). I found this comment in your blog post: "PAM vaults now appear alongside standard vaults in a single selector, eliminating the need to switch between views." Can you please provide a screenshot where to find the PAM vaults, we couldn't find it anymore ;-) Thanks.

- With the new DVLS version but the old RDM version we are still able to see the PAM vaults but after the first PAM synchronization (from scan configurations) all the account display names in the PAM vaults are set to the SAM account names. We have renamed the accounts so that we can see at a glance which customer or domain the user belongs to. With the new Devolutions server version, the display names have been reset to the SAM account names, and even in the dashboard, the associated domains are no longer visible. This makes it impossible to identify which account it is.

Thank you for your help and kind regards,
Simone

All Comments (17)

avatar

Hi Simone,

Thank you for reaching out. Your PAM vaults should appear alongside your normal vaults now. They will have a little shield icon overlaid on the regular vault image. Here is an example where AD-Test is a PAM vault.

Screenshot 2025-10-28 at 9.47.19 AM(1).png

In regards to the account being renamed with the SAM account name, this was an issue with DVLS 2025.3.3 and was fixed in 2025.3.4. Did you update to 2025.3.3 before updating to 2025.3.4? If the issue still persists, let us know.

Best regards,

Luc Fauvel

Screenshot 2025-10-28 at 9.47.19 AM(1).png

Screenshot 2025-10-28 at 9.47.19 AM.png

avatar

Thank you Luc, for your answer.

In this case, the PAM vaults were indeed not displayed; we had checked this menu. Only the regular vaults were in this list.

We had updated to 2025.3.3 a week earlier, where we had the same issues with renamed PAM accounts and disappeard PAM vaults, then went back and updated to 2025.3.4 last Sunday. Because the same two issues persisted, we reverted back to the old version (2025.2.14), each time using Hyper-V checkpoint. I just saw there is a new server version available again. I'll try again and let you know how it goes.

Best regards, Simone

avatar

Hello, We did yesterday the update van DVLS 2025.3.5 and RDM to 2025.3.20. The problem was that PAM not work at al. When we wan't to check-out a account it look it doesn't go to the PAM module. It looks that it's not avaible in the RDM client. Because the users can't work we dit a rollback to 2025.2 and had no time to troubleshoot the update. It looks that the PAM module is broken in the last update.

avatar

Interesting, others seem to have the same or a similar problem. Thanks freddy1 for your comment.

@Luc Fauvel: I could run the update again over the weekend and provide any useful logs or screenshots if you like. If that would help, just let me know exactly what you need.

avatar

Hi Simone,

That would be helpful thank you as right now we don't reproduce this behavior internally.

Without much data to go on, gut feeling is that the licensing might not be following properly after the upgrade and thus hiding all the PAM features. After the update if the issue still occurs, can you check the state of your PAM license? If everything seems to be in order, maybe removing it and adding it back in?

Thank you,

Luc Fauvel

avatar

Hi Luc,

I tried again and this is the recap:

  • With DVLS 2025.3.5.0 and RDM 2025.3.20.0 the issue with disappeared PAM vaults is solved, the PAM vaults are displayed in the vaults menu now.
  • The PAM license is ok and valid
  • The usernames in the PAM vaults are okay until the first sync after the update. Once synchronization was running (configuration scan), the accounts in PAM were reset to the sam account name.
  • In the latest version, at least the associated domain names are now displayed in the dashboard. That's why I renamed some users manually back to our usernames. But after the next sync, they were reset back to sam account name.
  • It seems as if every scan overwrites the PAM usernames and resets them to sam account. So manual renaming is not an option either.

I hope this information helps to identify and resolve the problem. Thanks @Luc Fauvel

Happy weekend and best regards,
Simone

avatar

Hi @simone9,

Thank you very much for the info, it helped us pin point the issue. We had only detected and fixed the issue upon account credential synchronization but it also occurs during account discovery. We're working on a patch and we'll let you know once it's available.

Cheers,

Luc Fauvel

avatar

Hi @Luc Fauvel,
It hasn't been fixed in version 2025.3.6 yet, right? I haven't tried it since 2025.3.5.
Thanks.

avatar

Hi @simone9,

You are correct, we didn't manage to get the change in in time for 2025.3.6. We'll make sure it lands in the next release.

Correction:
Unfortunately, 2025.3.7 is already in release candidate and we weren't fast enough to slip the change in so it will be in 2025.3.8

Thank you,

Luc Fauvel

avatar

Hi @Luc Fauvel
We have updated to 2025.3.8 and RDM 2025.3.23 (and tried also 3.22). The rename problem is solved, thank you!
However, there is a new problem. RDP sessions can no longer be connected. PAM accounts are stored in the user-specific settings. The PAM check-out wizard is displayed and the check-out works, but the following error is then displayed: Remote access to the server is not enabled.

RDM_error.png
What could be the cause of this?
Thanks and best regards,
Simone

RDM_error.png

avatar

Hi @simone9,

Thank you again for reaching out, we'll try to reproduce this internally. In the mean time, if you checkout the entry manually and create a temporary RDP entry with the checked-out credentials, does it work? It would help us narrow down where the issue could be.

Cheers,

Luc Fauvel

avatar

Hi @Luc Fauvel,
I updated again last night to test. New (dublicated) RDP session entry with a manually checked out pam user directly attached (not in user specific settings), same error. Then tried with "promt for credentials" and with the pam account, same error message. And last I tried with a local account instead of pam, same error. Please tell me if I can test something else.
Cheers,
Simone

avatar

Hi @simone9

Thank you for the info, this confirms our suspicion that it's probably not a PAM issue, I'll transfer this over to the RDM team. In the mean time, you confirm that this RDP session works before upgrading to 2025.3.23? Does this RDP entry use the Devolutions Gateway or any other type of parameter that would be different from a default RDP session entry?

Cheers,

Luc Fauvel

avatar

Hi @Luc Fauvel
Thanks and tell me if I should answer somewhere or someone else.
Yes, the RDP session works before upgrading and the same error appears on many (probably all) RDP sessions after the upgrade. Same vault but different subfolders. No known difference to default sessions, only the tab group is additionally configured but this shouldn't be the problem ;)
Thanks.
Simone

avatar

Hello Simone,

Thank you for your feedback.

We discuss this internally, and it will be easier to troubleshoot your issue during a support session. Please send an email to service@devolutions.net so we can send you a booking link.

Thank you for your collaboration.

Best regards,

Érica Poirier

avatar

Hi,
Everything works now with RDM 2025.3.25.0 and DVLS 2025.3.10.0.
Thanks and best regards,
Simone

avatar

Hello,

Thank you for your feedback. That's good news that these versions solved your issue.

Best regards,

Érica Poirier