You can provision a CA Privileged Access Manager device to permit execution of sudo or BeyondTrust PowerBroker pbrun using the login password for the device from the SSH Access Method applet.
Important:
Transparent login can be configured on the device level, but it's not available on the device group level, and when defining an access policy against a device group, transparent login cannot be enabled, even if it is configured for the devices in the group.
Example: Device demodevice.example.com is configured with sudo transparent login:
When defining a policy between a user and this device, transparent login can be enabled:
The device is a member of device group TLDemoGroup, but there is no Transparent Login tab on the device group level,
and when defining a policy for the device group, transparent login cannot be enabled:
Applies to any PAM release as of June 2024.
Since there is no explicit TL configuration on the device group level, the policy editor does not find anything associated with the device group that could require TL to be enabled.
You can work around this limitation by assigning a hidden service with TL configuration to the device group. To implement this workaround, create a dummy RDP application from the Services > Manage RDP Applications page. Make sure to check the "Hide from User" option, so that it will not show on the user's access page.
It does not matter which transparent login configuration you choose, but there has to be one. In the above example the built-in PuTTY Example configuration is specified.
Next assign this RDP application to the device group as a service:
Now when you edit an existing policy against the device group, or create a new one, you will find that you can enable transparent login:
To save the policy successfully, you need to select the dummy service in the policy:
Because the "Hide from User" option was checked in the dummy RDP application service, it does not show on the access page.
As the checking for Transparent Login configuration is done at the device level, the suggested workaround is bypassing this validation during policy creation. For this to work the Transparent Login configuration still needs to be done on the device level.
Also, the suggested workaround is not suitable for 'Command String' Transparent Login.