Identity Engines enables central policy management

In this Clear Choice Test, an identity-management appliance called Identity Engines' Ignition Server proved to be adept at aggregating control of multiple user repositories and devices once we got used to the somewhat cumbersome interface.

How we tested Identity Engines

Archive of Network World tests

Subscribe to the Network Product Test Results newsletter

The Ignition appliance goes beyond standard authentication, authorization and auditing to include centralized policy management, user consolidation, compliance automation and distributed deployment. Ignition uses RADIUS, 802.1x and other standard protocols.

We installed the appliance in our test network using the configuration that routes all traffic through the administration interface (See "How we did it," below) There also is the option of splitting management traffic and authentication/authorization traffic to a separate network interface. Initial setup of the appliance took less than 10 minutes.

Management is accomplished through the product's Ignition Dashboard, a thick-client console that we installed on a separate server. With the increasing movement toward Web-based management consoles, we were a little surprised to see the thick-client approach. We would prefer a Web-based management console to make distributed management a bit easier.

After logon, the Ignition appliance is selected and configured. We would like a more centralized approach to management in which we can make configuration changes and then choose which appliances to apply them to. This prevents the need to make changes multiple times to different devices in a distributed environment.

How we did it

The test environment consisted of a Cisco 3000 VPN Concentrator and a Fortinet Fortigate-60 security appliance. Active Directory, with 50 accounts, running on Windows 20003 Server was the primary user repository.

A Cisco 3500 switch provided the core network connection. The Ignition Dashboard and Ignition Jumpstart software was installed on a 3GHz, 2GB RAM Windows 2003 Server.

We configured the network devices and user repositories in Ignition and created multiple policy scenarios for testing. For Ignition Jumpstart, we configured guest accounts to be placed on virtual LAN 50.

We viewed transactions in the Log Viewer, noting successful and failed access attempts as well as which policy provided the access. We also configured Ignition to send logs to the lab syslog server.

Before testing, we upgraded Ignition to the latest release, 3.2. The appliance firmware upgraded without issue. When upgrading Ignition Dashboard, the Sun Java Virtual Machine (JVM) was removed (or unlinked) and the new version could not find it. We had to manually install the JVM for the upgraded software to function correctly, though this took only a few minutes.

Devices that are secured by Ignition are called authenticators, which can be grouped into service categories. We configured our Cisco 3000 VPN Concentrator and our Fortigate appliance to use Radius authentication and then defined them as authenticators in Ignition. We created a VPN service category to group the devices together.

We had some initial difficulty performing those tasks through the Ignition Dashboard management GUI. The software is not intuitive and was confusing at times. After working with the product for a while, we became familiar with the console and understood how to get the job done, but it has a bit of a learning curve.

Indentity Engine's Ignition Server

Next, we set up the user repositories. For testing, we used Active Directory in conjunction with the onboard user repository contained and administered on the Ignition server. The configuration to communicate with Active Directory was very straightforward. We used the wizard and the simple Active Directory configuration within Ignition, because our Active Directory implementation is pretty standard. Ignition also offers support for SSL-encrypted communication with Active Directory, which is very nice to see.

Once we had the user repositories configured, we created a directory set, which groups disparate user stores together. We then created a virtual group, which aggregates groups across multiple directories. For testing, we created a virtual group called Admin that included the Domain Admin group from Active Directory and an Admin group we defined in the Ignition embedded user store. The ability to consolidate multiple user repositories and devices into a single point of control is a great feature that could easily stand on its own.

Once we had the devices and repositories configured, we set up our authentication policies. We started simply, configuring a policy that said anyone trying to access the network from the VPN was approved. This meant that if you came in through the Cisco Concentrator or the Fortinet device and you successfully authenticated to Active Directory or the embedded user store, wherever your account resided, you were allowed access. We tested valid and invalid accounts, and everything worked great.

To get a little more complicated, we set some conditions on the VPN service category. We required the user to be in a specific group in Active Directory, using the virtual group we created previously. We tested multiple account scenarios based on user store and group membership and everything worked as expected.

We would like to see more detail and flexibility in the policy development. We were not able to disable a policy if we removed it from use temporarily for testing. If we needed the policy again, we had to delete it and recreate it later.

We also were not able to specify complex policy relationships. For example, we wanted to develop a policy that says if you are in an admin group or you come through a specific service category, then access is allowed. In our testing, we were only able to set an "and" policy that required both criteria to be met to get access. We would like to create embedded policy statements or more complex if/then scenarios for policy application.

Ignition also contains Ignition Jumpstart, a Web-based system for managing guest access. We installed Jumpstart and configured it to allow registered guests onto a specific virtual LAN (VLAN) on the network. Setting up the Jumpstart components was straightforward. Controlling access for guest users followed the same setup we tested for regular users. In our test configuration, guest users were assigned to a VLAN that allowed only Internet access. We could track guest registrations and what they tried to access from the network perspective.

For logging, Ignition's primary focus is syslog, but files can be exported through FTP/SFTP to a separate location. Logs are stored locally and can be viewed, but no specific reporting is available. Some statistics are provided on transactions, such as authentication attempts, but graphs or exportable reports are not included.

Ignition is definitely worth a look for any company struggling with network access control. Ignition does not require significant architecture changes and integrates easily into existing environments. While policy development could be expanded to allow for more complex scenarios, the current functionality helps solve problems that many companies do not have an answer for.

Andress is president of ArcSec Technologies, a security company focusing on product reviews and analysis. She can be reached at

NW Lab Alliance

Andress is also a member of the Network World Lab Alliance, a cooperative of the premier reviewers in the network industry, each bringing to bear years of practical experience on every review. For more Lab Alliance information, including what it takes to become a member, go to

Learn more about this topic

Buyer's Guide for ID management

Is your Active Directory properly provisioned for network access control?


Momentum building for identity management


What you should know about Identity Engines, Fox Technologies and OctetString


Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Now read: Getting grounded in IoT