Shared PAM Account Pool for Service Groups
1 vote
We manage multiple services that consist of server groups. For example, the "File" service contains approximately 30 servers. Access to each server is controlled through an Active Directory security group, which includes all authorized users, including those managed through Devolutions PAM.
Currently, a dedicated PAM account must be assigned to each server, resulting in a large number of privileged accounts that need to be created, managed, and maintained.
However, in our environment, there are never more than three administrators working concurrently across the servers of the same service group. Therefore, maintaining 30 separate PAM accounts provides little operational value.
We would like to request a Shared PAM Account Pool feature for service groups. Instead of assigning a dedicated PAM account to every server, a configurable pool of accounts could be shared across all servers within a service group. In this example, a pool of three PAM accounts would be sufficient for all 30 file servers
.
When an administrator requests access to a server within the service group, an available PAM account would be automatically allocated from the pool. Once the session is completed and the account is checked back in, it becomes available for the next administrator.
Important: A Just-In-Time (JIT) approach that creates a new account on demand and deletes it after use is not a suitable alternative in our environment. The required waiting time for Active Directory replication can introduce delays and negatively impact operational efficiency. We require immediately available privileged accounts without dependency on AD replication timing.
Benefits
- Significant reduction in the number of PAM accounts that must be managed.
- Lower administrative overhead.
- Faster onboarding of new servers into existing service groups.
- Improved scalability for large environments.
- Better alignment between the number of PAM accounts and the actual number of concurrent administrators.
- No delays caused by AD replication as can occur with JIT-created accounts.
This feature would provide a practical and efficient solution for organizations where servers are managed in service-based groups and concurrent administrative usage is considerably lower than the total number of managed systems.
All Comments (7)
Hi @Christian Egli,
In an effort to best address your request, I'd like to understand your current constraints. What is the specific reason that you need to have 1 account per server if you are using a DC. Is the replication delay of JiT elevation the cause?
Thank you,
Luc Fauvel
Hi Luc,
The main reason for this requirement is to improve the administrator experience and workflow. Today, administrators are used to simply launching a connection and being logged in automatically. They do not need to think about which privileged account to use.
With the current PAM workflow, an administrator must first identify the correct account, check it out, then search for the target server and launch the connection. This introduces additional steps and complexity into the daily administration process.
Ideally, the account selection and assignment should happen automatically in the background, allowing administrators to simply launch the connection without having to manually manage privileged accounts.
To achieve this, we need a pool of domain accounts from which an available account can be automatically assigned when a connection is opened.
Hi @Christian Egli,
If I understand your request properly, this should all be possible today without a dedicated "pool" feature. In the credentials section of your RDP or SSH entry, you can select the privileged account that needs to be used and you can also select the default privileges for that target.
Is this something that works for you?
Cheers,
Luc Fauvel
Screenshot 2026-09-02 at 9.59.17 AM.png
Hi Luc,
What we need is the ability to select a pool instead of a single account. This pool would contain multiple AD accounts.
When a connection is opened, the system should automatically select an available account from the pool that is not currently checked out or in use by another administrator. The account assignment should happen transparently in the background, so the administrator can connect without having to manually choose or manage the account.
Hi @Christian Egli,
What is the reason you need a pool specifically? I would suggest instead using the My privileged account setting in File -> My account settings where the administrators can each have their own privileged account set. Then in the entries, select My privileged account as the credential source.
Cheers,
Luc Fauvel
Hi Luc,
The main reason we need a pool is that multiple administrators share a limited set of privileged AD accounts.
Using My privileged account requires each administrator to have a dedicated privileged account assigned to them. In our environment, this is not possible because the accounts are shared and must be allocated dynamically.
What we need is the ability to select a pool as the credential source. The pool would contain multiple privileged AD accounts, and when a connection is opened, the system would automatically select an available account that is not currently checked out by another administrator.
This ensures that:
- Administrators can continue to open connections directly without manually selecting credentials.
- Shared privileged accounts are managed centrally.
- Account collisions are avoided because only free accounts are assigned.
For this reason, the My privileged account feature does not meet our requirements.
Cheers,
Christian
Hi @Christian Egli,
We'll keep note of this request.
Cheers,
Luc Fauvel