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

Click to see: 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.

Whitepapers

• Best Practices in Lifecycle Management: Comparing KAC(tm), Altiris, LANDesk, and Microsoft SMS
• Security vs. Flexibility: Must IT Management Choose?
• Systems Management Buyer's Guide For Medium Enterprises
• The Trend from UNIX to Linux in SAP(r) Data Centers
• Vulnerability Management For Dummies
• Forrester Rates WAN Optimization Solutions

View more SECURITY whitepapers

Webcasts

• Key Considerations for a Successful 802.11n Deployment
• The Secure Web Gateway. Mission Critical For Business - Webcast
• Mobile Data Security
• Best Practices for Deploying WAN Optimization for Disaster Recovery
• Solutions to the Toughest IT Challenges in Remote Offices
• Lowering the Cost of Email Archives

View more SECURITY webcasts

Special Reports

• IT Buyer's Guide to Security Information Management
• The Evolution of Network Security
• IP address management in 2008 - six things to know
• The self-managed network

View more SECURITY special reports