Symark makes its own mark in the privileged access market

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.

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 tracks managed system profiles in an easy to review GUI.

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.

PowerKeeper, like e-DMZ PAR, uses functional accounts at the same privilege level as actual root/privileged/administrative accounts that are established once PowerKeeper is set to control an account as a sort of safety measure. These functional accounts aren't for everyday use, but are employed for backup and maintenance purposes. Once a functional account (think shadow root) is established, the appliance can presumably always be accessed using the PowerKeeper functions (unless physical access is removed).The installation process takes preparation because PowerKeeper -- like e-DMZ -- has a weak discovery process. You have to do your homework to make sure that PowerKeeper is intimately aware of its environment. To get our systems imported onto PowerKeeper, we made a list in its favored format (it's a unique and tedious one). Once we did this, we very quickly had PowerKeeper as a primary manager of our root and administrative passwords for the two Linux prototypes, Active Directory and FreeBSD servers on the test network. PowerKeeper, through this privileged account, manages all subsequent password controls, including issuance of new passwords and checks with its store of existing ones as passwords expire or must be changed.

Less simple is synchronization of privileged passwords controlled by PowerKeeper, as the direction of control is one-way from PowerKeeper to the account under its control. PowerKeeper doesn't sync with directory services, because it controls its own accounts. On the upside, this lack of backwards synchronization also doesn't pollute PowerKeeper with other directory services passwords, be they a problem or not (for example unvetted in some way to keep with below standard password policy updates).

Changes are made to a privileged password outside of the auspices of PowerKeeper, will turn into an alarm — because it no longer has access to the system. PowerKeeper, like e-DMZ, becomes the master source for passwords. Change passwords elsewhere, and PowerKeeper's usefulness is thwarted.

For example, if an administrative password for a Microsoft Exchange Server is changed by a Windows administrative account user without using the PowerKeeper process -- PowerKeeper will determine that it no longer has the secure password for that system. In that instance the PowerKeeper shadow account will change that password to one that only PowerKeeper (by policy definition in terms of strength and third-party authentication) will know. The PowerKeeper privilege account on a controlled host can resynchronize the password back, once it is needed to be done. This means that if an organization chooses PowerKeeper to hold its passwords, the IT department must be prepared to rely on it as a 'master' source.

PowerKeeper can aggregate systems through an object management system called Collections. Collections are objects representing systems, devices, and/or applications with like-type characteristics whose logons/credentials/passwords are similar and can be treated similarly. Collections might differentiate sites or branches, like-type applications, such as Oracle where a database administrator password access could be kept by PowerKeeper and changed for a number of Oracle instances as a single object type.

PowerKeeper, once configured, went through our test use cases (vetted and unvetted logons to all of the hosts, devices and applications we used in our test bed) successfully, correctly logging the fact that passwords had been issued or had been denied issuance.

PowerKeeper doesn't keep very close track of what's done with the passwords it manages. If changes are made to a system, those changes must be tracked outside of PowerKeeper. Only the fact that the password's been issued is recorded. There is no session activity recording as we found in e-DMZ PAR

The reporting capability with the Symark spinoff is pretty similar to what e-DMZ offers.

PowerKeeper's documents need work and would be infinitely more useful if they included concrete examples and scenarios that work. Some lack indices, acronym decryption, process explanations and even consistency.

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

Copyright © 2008 IDG Communications, Inc.

SD-WAN buyers guide: Key questions to ask vendors (and yourself)