Symark, late in 2006, broke code development ranks with OEM partner eDMZ Security. The PowerKeeper 2.0 running on HP hardware we tested represents some slight changes in terms of flexibility, operating system and application support between the two offerings. The company plans to release PowerKeeper 3.0 this summer, but that revised code was not ready for us to test.
Symark's PowerKeeper is a password safe that can take on increasing gradients of password control -- from general user account access to servers right up through to root access to administrative accounts on business critical resources. Additionally, like all of its competitors, PowerKeeper can tap into layers of third-party authentication mechanisms as well.
At its highest level, an organization's passwords become totally dependent on PowerKeeper's resources, and its domain of passwords becomes autonomous, where even high-level administrators don't know what they are. There is no locksmith you can call; like e-DMZ's PAR, the appliance disk is encrypted with AES-256.
This high level of controlled use also mandates that PowerKeeper, like e-DMZ PAR, be backed up and made highly available. To that end there are cold spare and paired-hot spare options offered by Symark should disaster recovery or route availability problems to the PowerKeeper appliance arise. In this redundant configuration, a chain of authority is created that vets according to pre-determined applied policy.
PowerKeeper was supplied as a physical appliance based on an HP DL360G5 server. Like e-DMZ, it's a Windows hardened server with no console capabilities. There is no access to the operating system after installation.
Administration of the appliance is separated from the application functionality of the appliance; passwords for appliance administration are separate from those involved with the privileged password authentication services afforded by the product. The administration passwords can be authenticated against another source, such as the RSA SecureID platform we used, but Symark recommends at least one password be unencumbered by a possibly/potentially unavailable authenticator. Passwords can be strong, but it's not easy to set policies regarding password length and enforce these policies accordingly as the Symark admin user interface is somewhat difficult to use.
Like e-DMZ (whose user interface is similar), PowerKeeper uses a Web page for access to its appliance, and workflow in the user interface of both applications is both non-obvious and non-trivial. There are no wizards or processes or aggregations (beyond grouping objects into collections, explained below) to help administrators remember what needs to be done procedurally to admit, administer and manage the processes surrounding the privilege accessibility. A thorough read of the documents is needed, but better still, taking advantage of live training offered by the vendor is recommended for the most productive results. The user interface needs process aggregation, and the manuals need a complete rewrite.
PowerKeeper's Automation Engine application serves as the product's central nervous system. PowerKeeper stores all privileged passwords for systems it's linked to internally, responding to requests as they're made. A Windows service running on the appliance called the Change Agent, services a queue of requests for privileged accessibility. This process can involve interactions with approved third party authenticators (we used SecureID and 802.1X in our test and encountered no difficulties).
The automation engine is also responsible for periodically changing passwords according to predefined rules regarding password lifetime and checking validity of stored passwords. If someone were to change the password of a managed account, it would automatically be resynchronized when the periodic password change takes place or one can manually resynchronize the password by request, also similar in function to e-DMZ.
The policies that govern passwords are set after the initial deployment of the initial system and systems/applications/authenticators. We set our detailed policies via options provided in the Secure-HTTP Web-based administrative user interface. We also linked PowerKeeper to our SNMP monitor (on a Fluke OptiView III) to watch how fast errors (like authentication problems and repeated request attempt failures) showed up and found no hesitation in the messages sent. We also monitored failures using RSA SecureID to see how fast they showed up as problems, and the effect was seemingly instantaneous in our admittedly small test environment.