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.
One Identity recommends that you enable certificates for higher security.
The examples below use the keyfile paths that are created when using interactive configuration or join if certificates are enabled.
To swap certificate keys
-
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
-
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
-
Install Host1's certificate on Host2. For example:
# /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
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.
Installing secondary servers
To install the secondary server
-
From the command line of the host designated as your secondary policy server, log on as the root user.
-
Change to the directory containing the qpm-server package for your specific platform.
For example, on a 64-bit Red Hat Linux, run:
# cd server/linux-x86_64
-
Run the platform-specific installer. For example, run:
# rpm --install qpm-server-*.rpm
The Solaris server has a filename that starts with QSFTpmsrv.
When you install the qpm-server package, it installs all three Safeguard for Sudo components on that host:
-
Safeguard for Sudo Policy Server
-
PM Agent (which is used by Privilege Manager for Unix)
-
Sudo Plugin (which is used by Safeguard for Sudo)
You can only join a PM Agent host to a Safeguard for Sudo policy server or a Sudo Plugin host to a sudo policy server. For more information about policy types, see Security policy types.
Configuring a secondary server
You use the pmsrvconfig -s <primary_policy_server> command to configure a secondary server. For more information about the pmsrvconfig command options, see pmsrvconfig.
To configure the secondary server
-
From the command line of the secondary server host, run:
# pmsrvconfig -s <primary_policy_server>
where <primary_policy_server> is the hostname of your primary policy server.
pmsrvconfig prompts you for the "Join" password from the primary policy server, exchanges ssh keys for the pmpolicy service user, and updates the new secondary policy server with a copy of the master (production) policy.
Once you have installed and configured a secondary server, you are ready to join the Sudo Plugin to it. For more details, see Join hosts to policy group.
