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.
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
# 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.
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
# scp /etc/opt/quest/qpm4u/.qpm4u/.keyfiles/key_localhost \
# scp root@host1:/etc/opt/quest/qpm4u/.qpm4u/.keyfiles/key_localhost \
# /opt/quest/sbin/pmkey -i /etc/opt/quest/qpm4u/.qpm4u/.keyfiles/key_host1
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.
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.