Sudo-like CLI Option

(Click on images for higher definition view)

PUM offers three methods for a PUM User to access a privileged Account on a Managed Server under the control of PUM.  Two of these involve the PUM User accessing the PUM Access Server as themselves, and the Access Server then setting up a connection to the Managed Server, with all communication between the PUM User and the Managed Server flowing through the Access Server.  This applies whether the PUM User is using the PUMClient web UI or their own SSH Client.PUMX flow diagram  One of the major benefits of these two methods of access is that no agent needs to be installed on the Managed Server.

The third way is via the use of PUMX.  The PUMX utility simulates the use of Sudo (and is in fact built on top of Sudo) so that superusers may continue to access the Managed Servers directly, replacing the 'sudo' prefix to commands with 'pumx'.  Of course, pumx can be symbolically linked to sudo, resulting in no change at all in the way that systems administrators use Sudo.  In all ways the PUMX utility appears to the PUM User to work exactly the same as Sudo.

Instead of authenticating commands against a local or remote 'sudoers' file, the commands entered are validated against centralized PUM Access Policy by one or more Access Servers.   Communication with the Access Servers is via SSH.  All auditing of commands entered, and optionally the information returned, is also centrallized.  In this way, all Access Policy for privileged users can be defined centrally using PUM, but access to the Managed Servers can continue to be local, with minimal disruption for systems administrators who currently use Sudo.

One downside to this approach is that the PUMX agent has to be installed on every Managed Server to which such access is to be granted, so removing the benefit of agentless deployment which attracts so many organizations to PUM.