The e-DMZ Password Auto Repository (PAR) is delivered as a hardware appliance with all the services necessary for it to act as a privileged password manager. All privileged passwords are issued based on administratively designed rules. The passwords may be deemed valid for an indefinite life, for finite periods of time or for single purpose activities such as installations, upgrades or configuration changes.
e-DMZ’s Password Auto Repository (PAR) is delivered as a hardware appliance with all the services necessary for it to act as a privileged account password manager. All privileged account passwords are issued based on administratively designed rules. The passwords may be deemed valid for an indefinite life, for finite periods of time or for single purpose activities such as installations, upgrades or configuration changes.
Most all modern operating systems have passwords that can have a short-term life with quick expiration, but what separates PAR from this basic functionality is its ability to keep track of up to 20,000 (PAR ‘Standard Edition’) or 250K or more with the PAR Enterprise Edition. Arguably, a large organization with more than 1,000 servers and you have multiple administrators that handle different aspects of these servers, that capacity is not out of reach.
PAR replaces stored paper lists and spreadsheets of privileged account passwords, and automates the process of asking for one, getting one, and what happens to the password after issuance.
e-DMZ offers an optional product called e-GuardPost that will record sessions when the password is in use for auditing purposes, in a similar fashion as Quest Privilege Manager does. In our tests, we found that it collects a voluminous amount of information on log sessions, especially when things such as service packs are installed.
Overall, the e-DMZ PAR password storage and issuance system was less evolved than its genetic rival, PowerKeeper. While many features, such as password issuance, can be sophisticated, other features like systems grouping and related user object definition and functions were more difficult to set up and use.
There is no standard administrative ‘client’ portion of PAR. This ‘agentless operation’ puts the focus on the appliance as the single source for privileged password access, regardless of client type, and regardless of target platform password to be used. The PAR product was provided on an ‘OEM’ appliance that runs Windows 2003 ‘hardened’ Server operating system. Once configured, there is no console access; this is similar to PowerKeeper’s use. Backups and restores are easy to understand and complete, and a ‘cold spare can be kept’ as well as a primary/secondary ‘mirrored’ device that was tested and not difficult to configure and use.
We managed servers and all privileged users through a Web GUI by putting them into collections and groups, respectively. Access control can be role-based, and roles include password requestor, request approver, system/appliance administrator, user administrator, information security administrator, and auditor.
Initial installation of the rack-mounted appliance was trivial, PAR performs no ‘discovery’ for servers or hosts so we had to ID those ourselves. We could import Windows systems lists to be managed without much issue, but we had to enter that information for all other systems manually, a chore that would be quite tedious if you were pushing this product to its maximum password limits.
PAR doesn’t know LDAP and directory services with the same depth as Cyber-Ark’s EPV does by design. PAR is focused towards systems (and applications) through more direct logons, rather than pulling that user authentication process via directory services. Large changes in the LDAP structure, such as changing forests and trees, requires a bit of rework within the PAR system to make sure admin passwords stay in sync.
The next step was to define our rules for password strength and create root/administrative-equivalent accounts for the systems we wanted PAR to manage. These accounts handle privileged account expiration and password synchronization, test the viability of the root password accounts for auditing purposes and provide a recovery mechanism in the case of compromised passwords.
Requests for PAR-controlled passwords are made through a Web-based Secure-HTTP connection or via a direct SSH2 link to the command line interface on the appliance. One or more administrators may be required to approve a password request that’s been made, if that is how you established your policy.
When passwords are checked out, we found that they’re displayed on the users screen for only 20 seconds.
We tested PAR with an RSA Secure ID system in place. The appliance reacted quickly to our requests for passwords, which meant that we had time to hit the password numbers on the SmartCard and get a privileged password with lots of time to spare.
We then used both the Secure-HTTP and SSH interfaces to make requests, and challenge the system to see how it tracked both success and failures in terms of requests criteria. It logged problems instantly in our admittedly small test bed environment.
The PAR logs are detailed and easy to understand but its HTML reports about the data were more limited than those produced by Cyber-Ark EPV. Missing were features such as EPV’s easily formatted print-quality and customizable reports (when exported to a Microsoft Access or CSV format.)
Review: New tools control access by privileged users >
