Follow

Info: Configuring Privileged Access Management Integration

When Trust Protection Platform is doing agentless operations with SSH (such as certificate provisioning for SSH key discovery or provisioning), it may need to run certain commands as privileged user. Starting with Trust Protection platform version 17.1, it is possible to set up agentless operations performed by TPP to integrate with Privileged Access Management (futher referenced as PAM) solution for the purpose of privilege elevation. This is done by invoking some sort of sudo replacement command that does privilege elevation with permissions checking in centralized database. The name and syntax of the command depends on vendor.

This article describes how to properly configure accounts in some popular PAM solutions for best security.

The following principles apply to all PAM solutions:

  • Create separate user for Venafi operations and apply least privilege principle to that user.
  • Define list of commands that need to be run with elevated privileges and deny everything else. For SSH key discovery and remediation, the actual list of commands can be found in this article. 
  • Venafi TPP requires password prompt text during elevation to be [VSUDOPROMPT] or disabled. Elevation password prompt has to be disabled for products that do not allow customization of it.
  • Venafi TPP requires password caching in session for 1 minute or more. Typically this is default configuration of sudo and PAM solutions.
  • In Aperture web interface, "Other" way to privilege elevation has to be selected in device connection settings which are set either on folder level or individually on device. The elevation command also needs to be filled in and depends on PAM vendor. Refer to Trust Protection Platform documentation for more details.

BeyondTrust PowerBroker

PowerBroker ships with "pbrun" utility that is used to elevate privileges. PowerBroker policy files need to be modified to define which commands can Venafi account run and that privileges need to be elevated. For example:

/etc/pb/pbul_functions.conf: 

## Checks for user name, command name and asks for password if needed (with customized prompt and 1 minute caching)

procedure VenafiRole()
{
    if ( EnableVenafiRole && user == "venafi" && basename(command) in VenafiCommands && getuserpasswd(user, "[VSUDOPROMPT]", 3, "/etc/pb/data/" + user, 60) ) {
        SetRunEnv("root", true);
        accept;
    }
    else
    {
        reject;
    }
}

/etc/pb/pbul_policy.conf:

EnableVenafiRole = true;
VenafiCommands = {"chmod", "chown", "cp", "mkdir", "echo", "grep", "ls", "rm", "sha256sum", "stat"};
VenafiRole();

FoxT BoKS

BoKS uses "/opt/boksm/bin/suexec" utility to elevate privileges. 

The following is example of boksadm shell commands for adding access route that enables "venafi" account to run certain commands:

#add all commands required for SSH key management to program group VENGRP

pgrpadmin -a -g VENGRP -Z /bin/chmod

pgrpadmin -a -g VENGRP -Z /bin/chown

pgrpadmin -a -g VENGRP -Z /bin/cp

pgrpadmin -a -g VENGRP -Z /bin/echo

pgrpadmin -a -g VENGRP -Z /bin/grep

pgrpadmin -a -g VENGRP -Z /bin/ls

pgrpadmin -a -g VENGRP -Z /bin/mkdir

pgrpadmin -a -g VENGRP -Z /bin/rm

pgrpadmin -a -g VENGRP -Z /usr/bin/sha256sum

pgrpadmin -a -g VENGRP -Z /usr/bin/stat

 

# create access route that allows user venafi to execute commands in VENGRP

ttyadmin -a -l <host>:venafi -z 'SUEXEC:$USER@*->root@*%VENGRP'

 

Centrify Server Suite DirectAuthorize

Centrify DirectAuthorize uses the /usr/bin/dzdo command (which is typically a symbolic link to “/usr/share/centrifydc/bin/dzdo") to elevate privileges. To assign rights, DirectAuthorize role with the associated commands in the DirectManage Access Manager GUI needs to be built:

  1. In the UNIX Rights Definitions container, create command objects for the commands that are required to be run with root privileges.

 

Details for each command object can take the defaults unless you have moved commands to non-standard paths.

2. Create a new Role Definition for the Venafi SSH Key Manager. On the System Rights tab under “UNIX rights” be sure to check the boxes for “Password login and non-Password (SSO) Login are allowed”, “Non password (SSO) login is allowed” and “Login with non-Restricted Shell”:

Alternatively, set up "[VSUDOPROMPT]" password prompt for the user.

3. Add the UNIX commands to the new Role Definition. If the service account you plan on using does not already have login rights on the target servers be sure to include the “login-all” PAM Access right:

4. Make sure that appropriate service account is added to the zone and assign the Venafi SSH Key Manager role to it:

5. On a target UNIX/Linux system, as root, run the “adflush” command to clear the local cache.  Log in as the Venafi service account and run the “dzdo -l” command to verify the Venafi service account has been granted the required command rights:

 

Was this article helpful?
1 out of 1 found this helpful

Comments