Domain attribute of PAM accounts not retrieved after updating to 2025.3.7
Hello,
After updating to DVLS 2025.3.7, RDP entries using domain user PAM credentials would no longer work because the correct domain attribute was not being passed to target host. It appeared that the currently logged in user's domain was being passed instead. Rolled back to 2025.2.x all the respective RDP entries started working again. Using RDM 2025.3.16
Wondering if this (or a similar) issue been reported elsewhere?
Please let me know if you would like any additional info.
Thanks
Joe
Hello Joe,
Thank you for reaching out to the Devolutions support team.
I was able to reproduce a similar issue, but with a JIT user and not just a PAM account.
Could you send us your RDP logs at services@devolutions.net?
I'll need the API hooking and also the logging enabled for this case.
Could you also include how this PAM account is configured and how the credential is set on the entry?
https://docs.devolutions.net/rdm/kb/troubleshooting-articles/rdp-session-troubleshooting/
Best regards,
Patrick Ouimet
Hi Patrick,
Thanks for assisting with this.
The DVLS upgrade had to be rolled back as it broke the ability to use all the RDP connections which utilize PAM credentials, so I'm currently unable to reproduce with RDM logging enabled etc.
Regarding how the PAM account is configured, it is a standard 'domain user' type entry with the password entered either manually or generated by DVLS during rotation. The credential passes heartbeat checks successfully.
Regarding how it is used, in the RDM user vault, an entry called 'My Domain Admin' of type 'Devolutions Server Privileged Account' exists which links to the PAM credential. The credential property of an RDP entry is set to find by name in user vault and look for 'My Domain Admin'.
Launching connections with DVLS 2025.2.x works, once upgraded to 2025.3.x the RDP sessions fail. If I copy the username/password from RDM and paste them into a manual RDP connection outside of RDM it works fine, so I believe its just the domain part of the credential that is missing when launching via RDM.
Please let me know if you would like more info.
Joe
Hello,
We have reproduced this issue and opened an internal case.
This is related to a subdomain provider.
The workaround for now is to set the complete name of your subdomain.
Example:
Main domain = <Main>
Subdomain = <sub>
The host entry should be Sub.Main.loc, and not just Sub.loc
We will post here when a fixed version is available.
Best regards,
Patrick Ouimet
Hi Patrick,
Thanks for the update, and glad the issue has been able to be reproduced.
Regarding the work around, I'm not sure that I understand what is being asked, as the target host is in the parent domain, as is the PAM credential configured for the entry. The child domain aspect is only involved to the extent of the user running RDM. In other words, user@child.parent.tld (CHILD\User) logs onto a RDS server joined to trusted parent domain (i.e. rds1.parent.tld). Said user launches RDM and opens a RDP entry for host1.parent.tld configured to use PAM credential adminuser@parent.tld (PARENT\adminuser). As reported, after upgrading to 2025.3.x, what appears to happen is that RDM attempts authentication using username adminuser@child.parent.tld (or CHILD\adminuser or just .\user) which subsequently fails.
Please let me know if you would like any additional info.
Joe
Hi Patrick,
Just wondering if there was any progress on a fix for this issue yet?
Thanks
Joe