philippmarti

Hi Sayed,

we are meanwhile running on Devolutions Server v2025.2.10.0 and RDM v2025.2.26.0 and we still have this issue, that copying the PAM password still very takes long :-(

Is a fix for this issue still under development?

I created a new performance profile:

Best regards,

Philipp

Hi Sayed,

just a short update: we found out that if we give a user admin rights the slowness is gone. If we remove the admin rights again, it's slow again.

Regards,

Philipp

Hi Philipp,

I'm from the Devolutions QA team, we're working on trying to reproduce the issue. I have a couple of questions that can help us narrow down the scope of the investigation if you don't mind.

1. What is the type of user with which you're encountering the slowness (Admin or none admin)

2. How many PAM entries are in the vault

3. Do you have the same PAM account numbers as your colleagues who don't have the slowness issue?

4. Could you open the Profiler with these options checked and send us a screenshot of the result, please?

Best regards.

Hello Sayed

1. none admin

2. +/- 20 entries

3. some have 17 others 21 entries, but it's not that those with less entries have faster access. The PAM entries come from 8 providers - all are of the type "Domain User".

4. find attached (I did two copy-to-clipboard tries from two different providers)

Best regards,

Philipp

Hi Maurice

Thanks for your swift reply.

I meanwhile tested to copy the PAM password via the web UI of Devolutions Server and there it seems to work faster than via RDM.

I also must admit that I learned today, that not all of my colleagues have that issue. For some it's as slow as mine and for some it's fast.

So, it's maybe also something related to the user profile or a cache-thing of RDM?

To answer your question: the server has an acceptable performance when opening a vault or also in general when working with it.

Best regards,

Philipp

Hi

We use the PAM feature of the Devolutions Server together with RDM. We have noticed that copying a password from an entry in a PAM Vault to the clipboard takes much longer (about 4-6 seconds) than copying the password of an entry in a shared, normal vault to the clipboard (<1 sec).

Server version: 2024.3.11.0

RDM version: 2024.3.26.0 64-bit

.NET 8.0.2

Is this a performance bug or is there a setting which could improve this behaviour?

Best regards,

Philipp

Hello François,

well, in our Active Directory we have a OU structure which separates different tiers. e.g.

root

|

|_OU: TIER_0

| |

| |_OU: TIER_0_GROUPS

| |_OU: TIER_0_ADMINS

|

|_OU: TIER_1

| |

| |_OU: TIER_1_GROUPS

| |_OU: TIER_1_ADMINS

|

|_OU: TIER_2

|

|_OU: TIER_2_GROUPS

|_OU: TIER_2_ADMINS

There's delegation of control configured between the tiers.

We mapped the tier structure to Dvls PAM and uses the Privilege Sets to separate the privileged PAM accounts between the tiers. We have a 1:1 relation between privileged accounts and privilege set.

From a logical but also security point of view it would be helpful, if the temporary JIT groups for let's say Privilege Set "TIER_0" accounts would create its temporary group in OU "TIER_0_GROUPS" and the Privilege Set "TIER_1" accounts would create its temporary group in OU "TIER_1_GROUPS".

Currently I can specify only one location for the temporary groups.I hope this clarifies the request.

But I understand that my request conflicts with such scenarios where a privileged account is included in many Privilege Sets (1:n). Maybe you guys have still an idea how both scenarios could be fullfilled.

Best regards,

Philipp

Hi there

It would be helpful if it would be possible to specifiy a "Temporary group creation location" per Privilege Set.

Today it's only possible to specify just one "Temporary group creation location" which is used for all Privilege Sets.

Best regards,

Philipp

Hi there

We are using the PAM module in Devolutions Server for a while now.

Since the used service account credentials in a PAM Provider is a critical account (because it most probably has elevated rights like Domain Admin within the target domain), there were two questions I'd like to address:

• Why is it not possible to link those credentials with an entry in a "normal" vault? (when selecting "Credential Type = linked credential" it's only possible to access PAM vaults)

• It would be an increase in security if the password of the used service account could be rotated automatically on a scheduled basis (incl. propagation to the target domain user withint the provider domain/active directory).

Maybe I missed the way how this is feasable today. Any hints much appreciated.

Best Regards,

Philipp

Hi François,

thanks for your explanation.

I understand the argument of your security team, but I don't particularly agree. Even if the benefit of JIT in our scenario is low, it's still a benefit.

As stated above, we have customers which are interessted to keep the amount of members of privileged groups as low as possible. Those customers often go through security audits year by year and it's a common audit control to verify the members of privileged groups (such as domain admins). If we, as a service provider, can offer the JIT functionality towards our customers, we are very welcome.

But thanks for your statements, I think we can close this thread :-)

Best regards,

Philipp

Hello François,

thanks for your answer.

Well, in my opinion password rotation is good, but combined with temporary elevation on a by-request, timed basis is even better. That's the idea of Just-In-Time access, isn't it? It reduces the risk of privileged access abuse and lateral movement when a privileged account not permanently has the elevated rights.

It's also an recurring argument in the discussions with our customers. We ofter hear complaints that for example there are too many permanent members of the Domain Admins group, etc. So we try to follow the principle of least privilege.

Best regards,

Philipp

Hello François,

thanks a lot for your answer.

Maybe I'm also missing something, but let me explain our use case:

We have a tiered Active Directory; the whole domain is separated into 3 tiers (yellow, organge, red) by group policies. Critical assets like domain controllers, backup or CA belong to the red tier. Member servers belong to the orange tier. Client computers belong to the yellow tier. An administrator needs to have a dedicated account per tier, because we want to prevent passing password hashes from one tier to another. He's not allowed to manage a "red server" with his "orange account", etc. This means the administrator might have 3 admin-accounts which he needs to checkout in order to be able to connect/manage the servers or clients.

So I configured 3 JIT Privilege Sets on the provider (one set per tier -> yellow, orange, red) and assigned the corresponding privileged accounts. This leads to the situation when a user requests a checkout for a privileged account, there's always only one elevation group to pick on the checkout request dialog.

I did not see another way to configure this, if we'd like to leverage the JIT feature.

User					Accounts		Privileged AD Groups
------------------------------------------------------------------------
						YellowAdmBob 	-> Member of Yellow-Admin-Group
					  /
Privileged User "Bob" - OrangeAdmBob 	-> Member of Orange-Admin-Group
					  \
						RedAdmBob		-> Member of Red-Admin-Group

I hope I could clarify our use case.

Best regards,

Philipp

Hi,

It would be nice, if there's only one elevation group configured, to make it selected per default on the checkout request (or at least make it configureable if it should be already selected or not ;-).

Users could save two clicks and make the checkout process more efficient.

Best regards,

Phil

Hi

Is ist possible to configure multiple domain controllers on the PAM Provider configuration for redundancy reasons? I tried with comma, space and semicolon separation, but nothing worked.

(PWS version 2024.2.3.0)

Hi François,

We have meanwhile started testing the PAM function with a trial license.

In a small concept, we have defined that each employee should have their "own" private PAM Vault, as you proposed above. Only the employee in question should be able to check the accounts in and out.

Unfortunately, we have not found how to exclude the Administrator accounts from accessing these private PAM Vaults. According the Dvls technician which supports us during the trial, it's currently not possible to deny access on PAM Vaults for other users and groups. In other words, users which are member of the Administrators groups, which we created, can access the PAM Vaults of other users and check-out/-in those "foreign" accounts (not so nice).

Would you consider this as another feature request?

Best regards,

Philipp

Hi François,

thanks a lot for your feedback and research. I'll try to create an efficient solution with the PS module.

Regarding the feature on the roadmap you mentioned for the role limitation: Can you approx. predict when this will be developed and/or released (is this a question of weeks, months or years...)?

Best regards,

Philipp

Hello François,

Thanks a lot for your swift reply!

It sounds promising that you're working on a feature for role limitation.

Also your hint regarding the "PAM vault per user" concept sounds like a good idea. Is it possible to configure the user import task with the Devolutions PowerShell module (-> import user and assign it to its corresponding vault)? Because each of the mentioned 600 accounts would have to be assigned to its vault individually, right?

Best regards,

Philipp

Hi

In order to mitigate Pass-The-Hash attacks in our customers Active Directories, we're generally implementing a Tier-Model in AD which divides an AD forest in 3 tiers (Tier 0, 1 and 2). (the Tier-Model is an architecture described by Microsoft in the following paper: https://www.microsoft.com/en-us/download/details.aspx?id=36036)

The model is intended to prevent an escalation of privilege path for an attacker using stolen credentials.

IT staff with responsibilities at multiple tiers will have separate administrative accounts created for each required tier. Any account that currently logs on to multiple tiers will be split into multiple accounts, each of which fits within only one tier definition. These accounts will also be required to have different passwords (in order to have different hashes in the background).

When using your PAM solution (JIT function) this leads to the requirement that a PA should be limited to which elevated role she/he can select when checking out the account (1:1 relation instead of 1:n).

Example:

| User            | Relation   | Elev. Role   
---------------------------------------------------
| adm_tier0_usrx  | 1:1        | secgroup_tier0
| adm_tier1_usrx  | 1:1        | secgroup_tier1
| adm_tier2_usrx  | 1:1        | secgroup_tier2

In addition our customers require us to use personal, individual accounts.

Let's assume we have 20 customers and we have 10 employees and each employee has 3 (tier) accounts per customer.

This leads to 600 accounts on which we need to set the permissions within the PAM vault respectively on each PA within the vaults :-(

It would be great if there would be an efficient way to set permissions on multiple accounts (maybe rule-based?).

I hope I could explain the issues we see with your product and would love to see this improved in a future release!

Please don't hesitate to ask if something is not clear.

Regards,

Philipp