Quest homes in on Unix password management

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).

Quest Privilege Manager for Unix manages privileged access via agents on Unix and Linux hosts which are all controlled from a central 'master' system.

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 methos  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.

Constructing a working QPM-password protected infrastructure can be daunting, as various aforementioned execution constraints imposed on users and groups must be entered into an /etc/pmconf file manually. Additionally, while the product includes a program called pmcheck that parses the deployment for errors, we found it not much help in debugging issues because it's not able to articulate what caused the problems, it just points to them.

It's up to administrators to use other applications that tap into syslog, or direct syslog examination, to determine problems, such as unauthorized user attempts at privilege, applications or logons that aren't working, or other difficulties with the QPM privilege granting processes.

Overall, QPM requires moderate Unix administrative skills to both install and use. It doesn't, of course, cover Windows, but does cover Solaris and HP-UX (not tested). It's very highly configurable, and puts reasonably strong barriers in place to prevent undesired privileged access. Configuration is moderately tedious but has a lot of flexibility. It's a usable alternative to the user-session isolation of privilege effects of SELinux and Solaris Containers, with a similar configuration dance to learn, with better cross-platform results.

< Return to main story: Review: New tools control access by privileged users >

Learn more about this topic

 
Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Must read: 10 new UI features coming to Windows 10