Chat now with support
지원 담당자와 채팅

Privilege Manager for Sudo 6.1 Common Documents - Administration Guide

One Identity Privileged Access Suite for Unix Introducing Privilege Manager for Sudo Planning Deployment Installation and Configuration Upgrade Privilege Manager for Sudo System Administration Managing Security Policy Administering Log and Keystroke Files Troubleshooting Privilege Manager Variables Privilege Manager programs Installation Packages Unsupported Sudo Options Privilege Manager for Sudo Policy Evaluation

Join hosts to policy group

Once you have installed and configured the primary policy server, you are ready to join it to a policy group. When you join a policy server to a policy group, it enables that host to validate security privileges against a single common policy file located on the primary policy server, instead of on the host.

For Sudo Plugin hosts (qpm-plugin), you must "join" your policy servers to the policy groups using the pmjoin_plugin command.

Joining Sudo Plugin to Policy Server

Run the pmjoin_plugin command after installing the Sudo Plugin package (qpm-plugin) on a remote host to allow it to communicate with the servers in the policy group.

To join Sudo Plugin to policy server

  1. Join the Sudo Plugin host to the policy server by running the following command:
    # pmjoin_plugin <primary_policy_server>

    where <primary_policy_server> is the host name of the primary policy server.

    To automatically accept the End User License Agreement (EULA), use the –a option with the "join" command, as follows:

    # pmjoin_plugin -a <primary_policy_server> 

You have now joined the host to a primary policy server. The primary policy server is now ready to accept commands using sudo.

Swap and install keys

If certificates are enabled in the /etc/opt/quest/qpm4u/pm.settings file of the primary server, then you must exchange keys (swap certificates) prior to joining a client or secondary server to the primary server. Optionally, you can run the configuration or join with the -i option to interactively join and exchange keys.

NOTE: One Identity recommends that you enable certificates for higher security.

NOTE: The examples below use the keyfile paths that are created when using interactive configuration or join if certificates are enabled.

To swap certificate keys

  1. Copy Host2's key to Host1. For example:
    # scp /etc/opt/quest/qpm4u/.qpm4u/.keyfiles/key_localhost \
    root@Host1:/etc/opt/quest/qpm4u/.qpm4u/.keyfiles/key_server2
  2. Copy Host1's certificate to Host2. For example:
    # scp root@host1:/etc/opt/quest/qpm4u/.qpm4u/.keyfiles/key_localhost \
    /etc/opt/quest/qpm4u/.qpm4u/.keyfiles/key_host1
  3. Install Host1's certificate on Host2. For example:
    # /opt/quest/sbin/pmkey -i /etc/opt/quest/qpm4u/.qpm4u/.keyfiles/key_host1
  4. Log on to Host1 and install Host2's certificate. For example:

    # /opt/quest/sbin/pmkey -i /etc/opt/quest/qpm4u/.qpm4u/.keyfiles/key_host2

    NOTE: If you use the interactive configure or join, the script will exchange and install keyfiles automatically.

Configure a secondary policy server

The primary policy server is always the first server configured in the policy server group; secondary servers are subsequent policy servers set up in the policy server group to help with load balancing. The "master" copy of the policy is kept on the primary policy server.

All policy servers (primary and secondary) maintain a production copy of the security policy stored locally. The initial production copy is initialized by means of a checkout from the repository when you configure the policy server. Following this, the policy servers automatically retrieve updates as required.

By adding one or more secondary policy servers, the work of validating policy is balanced across all of the policy servers in the group, and provides failover in the event a policy server becomes unavailable. Use pmsrvconfig with the –s option to configure the policy server as a secondary server.

관련 문서