Entry configured to use UPN of PAM domain user incorrectly resolving to username@domainFQDN instead of actual UPN

Hello Joe,

Thank you for reaching to our support team. Based on our investigation and replication attempts, here are some steps to help resolve the username domain issue you’re experiencing:

1. Please go to Administration > Privileged Access > Provider, then edit your PAM provider configuration. Verify that the "Domain name" and "Domain controller" fields are correctly set to your public domain (e.g., devo.com) and ensure that no local/internal domain (such as domain.local) appears anywhere in this configuration.
2. If the PAM provider configuration is correct (no local domain present), open your user vault in Remote Desktop Manager (RDM), create a new website entry from scratch, and link it to your user vault as the credential. Be sure to choose the same PAM account. This test helps determine if the issue persists with a newly created entry.
3. Additionally, for your existing website entries, edit the entry and open the Advanced settings. In the "Username format" field, explicitly set the format you prefer (for example, {UPN}). This setting can override domain-related inconsistencies.

Following these steps should help isolate and resolve the cause of the incorrect username domain in your environment.
Please let us know if the issue persists afterward.

Best regards,
Michel Audi

Hi Michel,

Thanks for assisting with this.

Regarding the steps you mentioned:
1) Not sure how it sense to change the PAM provider's internal domain provider to a disjointed public DNS namespace. If fact doing so would likely result in invalid DNS resolution, because dc1.domain.local does not have a corresponding record of dc1.domain.com, and even if it did LDAPS certificate validation from the PAM service to DC would/should fail.
2) Already tried creating new entries, and as mentioned the behavior occurs even when a shared vault website entry explicitly links to a PAM entry, thus bypassing the user vault.
3) As mentioned, the website entries were configured in Advanced settings to use the username format {UPN}, it is the fact this is not resolving to the true UPN that is the issue the ticket was raised.

Please let me know if you would like any additional info.

Joe

Hi Joe,

Thank you for the clarification.

After testing in our lab this behavior is an RDM regression probably , I will confrim this as soon as possible.

When a Website entry is configured to use the {UPN} username format with a PAM Domain User (via a Hub Privileged Account), RDM is not resolving {UPN} to the actual userPrincipalName attribute. Instead, it falls back to constructing username@<domain> from the account’s domain context, which results in values like username@domain.local in disjoint namespace environments and breaks providers such as Microsoft 365 that require the routable UPN.
We will escalate this to engineering for correction so that {UPN} resolves to the true UPN value.
As a temporary workaround, set the website username explicitly to the required routable format (for example {USERNAME}@domain.com or the full UPN) until a fix is available.

Thank you for your patience.

Best regards,

Hi Michel,

Thanks for confirming the issue has been identified.

Regarding the workaround, how can a username format of {USERNAME}@customdomain.com be configured for an entry in a shared vault accessed by multiple users. As mentioned in the initial post, the respective website entry utilizes a PAM account via find by name in user vault which loops back to each users' individual PAM credential.

The username override setting on an entry doesn't appear to accommodate free form text for a custom format.

Joe

Hello Joe,

Thank you for the follow-up.
You are correct that, given this limitation, there is no suitable shared-entry workaround to force a routable UPN while {UPN} is currently resolving incorrectly. I also attempted to use RDM user-specific settings (Edit > User-specific settings) to override the domain behavior, but that did not resolve the issue in this scenario.

Since this is already being addressed by our engineering team, the practical options are:

1. Roll back to an earlier RDM version (for example 2025.1.x) and validate in your environment whether {UPN} resolves to the correct value (username@domain.com) for the same PAM Domain User, or
2. Remain on your current version and wait for the fix release that restores {UPN} to the actual userPrincipalName value from PAM/Active Directory.

Thank you for your patience.

Best regards,

Thanks Michel. As the data source is Hub for the system impacted by this limitation, which is already at 2025.3.x, rolling back to RDM 2025.1.x will likely result in other incompatibilities. Will wait for update to RDM 2025.3.x, hopefully not too long

Hello,

Thank you for being so patient!

I'm pleased to inform you that a new version of RDM (2026.1.10.0) has been released, featuring the fix for your issue.

Latest Version: Download RDM

Please let us know if this works or if you encounter any issues.

Best regards,

Thanks Maxim. Confirming issue resolved in 2026.1.10