Quest Privilege Manager for Unix (QPM) currently only works with Unix derivatives. No Windows allowed.

QPM also uses a different approach than the other three products we tested in that it permits the delegation of root by proxy access to privileged accounts (root or root-equivalents) where all keystrokes are recorded. QPM delivered a keystroke-by-keystroke recording of everything we did as root on the systems we tested, almost like the macro-recorders of years gone by that did much the same thing. This method of protection for root uses a daemon (pmmasterd) that accepts instructions from a user/client, then uses an agent (pmlocald) to execute the requests. It's a gatekeeping mechanism that permits users to perform root or equivalent tasks without being root.

We told QPM which users could perform specific tasks (as an example, to run a line printer job/print request using the lp daemon), when a task could be performed, which machine could make a request, whether another user or administrator's tacit and specific permission would be required to perform a task, and which tasks could be performed (a great way to inhibit savvy users from invoking utilities they shouldn't).

All of these specified jobs made it into audit files -- including information about who did them, the time they were done and the transcript of what was done. However, we found reports generated from these audit files were weak, reminding us of syslog dump text files with one record per line.

Encryption choices include Advanced Encryption Standard (tested), Kerberos, and Data Encryption Standard/Triple DES. Unfortunately, anyone with access to the /etc directory can look inside the /etc/pm.settings file to know which encryption method is employed -- a weakness in our opinion.

It's possible to associate an executable with a checksum value that matches a desired privileged accessed request -- not foolproof, but useful to prevent unwitting execution of a Trojan/replacement program (often found in 'rootkitted' installations). We like this unique authentication method, even if checksums aren't very strong file authentication mechanisms.

Communicating between the master machines and its agented 'slave machines' within the QPM deployment requires that multiple firewall ports be open (6+ are recommended). Multiple master systems are possible and recommended for hosts that have more than 150 possible users with privileged needs -- and multi-master keys need distribution capabilities to all master servers.

QPM also has the ability to authenticate a user against a Pluggable Authentication Module that's setup and working (in our test case that was an RSA SecureID Pluggable Authentication Module) and is accessible by the host where the Master 'lives'. Pluggable Authentication Modules can be LDAP-based, and while we confirmed that capability using Linux-Pluggable Authentication Module running OpenLDAP we could not get the product to work with the RSA SecureID PAM.