How Harry met Sally on our identity management test bed

We tested our six identity management solutions — from Courion, IBM, Microsoft, Novell, Sun Microsystems, and Thor Technologies — at the Advanced Network Computing Lab at the University of Hawaii, Manoa, which always serves us well, both in function and distraction. Much thought went into both the test environment and our test scenarios. We wanted to throw some curveballs at the participants, but we also needed to make completion possible within the three-day time limit given to each vendor. We also needed to be practical regarding the makeup of the test infrastructure — but at the same time do our best to represent a real-world enterprise.

In order to quickly reset the environment for each vendor in turn, we opted to run almost the entire test infrastructure on a single HP ProLiant DL585 with four Opteron 252 CPUs and 32GB of RAM running Red Hat Advanced Server 3 and VMware GSX Server 3.1. This enabled us to quickly build, run, and revert the five Windows Server 2003 servers and two Fedora Core 3 systems that comprised our test infrastructure. Our backup platform was a Tyan-based dual-Opteron server from LZS Global Services running several extra Windows XP Workstation images under VMware GSX Server.

After much internal discussion and debate, we settled on Microsoft’s AD (Active Directory) as the foundation for our test. Our fictional company, named TCPIP Corp., would be largely Windows-based, with many core services running on Windows Server 2003, but with some key components running on Fedora Core 3, which is Red Hat’s community-supported Linux distribution. We chose this scenario to replicate organically developed infrastructures commonly found in production.

The AD layout was relatively simple, with an employee OU (organizational unit) that housed eight other OUs consisting of major business segments such as accounting, production, shipping, and so on. Each OU contained a significant number of users, with the total user count reaching 2,270. Each user object in AD came complete with a suitable number of defined attributes, including valid address, telephone, and department information, as well as AD schema extensions to include Social Security numbers and birth dates. Also on the TCPIP network were a Microsoft Exchange Server 2003 server, a Windows file/print server, and an IIS Web server. An Apache Web server ran on one Fedora Core 3 server, and the key HR and ERP applications ran on another.

Rather than opt for HR and ERP applications that all the vendors would have easily wrapped up, such as PeopleSoft or SAP, we implemented open source solutions that wouldn’t have the same familiarity: e-HRMS and webERP. Both of these applications are built on PHP and make use of a MySQL back end.

After more careful thought, we decided that our test environment could use a bit more variety, so we also threw in a z/OS mainframe emulator from Cornerstone Systems (provided by IBM, however) and a Lotus Notes server (also graciously provided by IBM). Our test scenarios wouldn’t require that these systems be provisioned, but we allowed vendors to do so for extra credit. Each participant in the test was given the test parameters one month prior to the test and general information about the test infrastructure: that it would be based on Active Directory, that e-HRMS and webERP would be our HR and accounting applications, and that these apps would run on Fedora Core. This enabled them to prepare connectors ahead of time, helping to speed along the integration of their identity servers into the TCPIP environment. Of course, we kept a few specific details quiet until the test began.

We allowed each vendor one day to install and configure the various infrastructure components necessary to work with our test bed, including installation of any required agents, implementation of any servers necessary to run their solutions, and some time to verify that the solution was functional. Then, we hired our fictional junior accountant, Harry Truman, who was destined for an exciting — if brief — experience with TCPIP Corp.

Harry proved to be on a fast track, as he was quickly promoted to accounting supervisor. This bump granted him additional rights on several key systems, including the webERP application, and entered him in additional security groups in Active Directory. Harry’s good fortune would only continue, as he would meet a stunning young woman named Sally Fergenschmeir, who in my mind’s eye looks much like Alyssa Milano in a business suit. Sally is the daughter of Bartholomew Fergenschmeir, who loses his company to TCPIP in a hostile acquisition, but who otherwise doesn’t enter into this story at all. Harry meets Sally during negotiations for TCPIP to purchase Fergenschmeir. As luck would have it, Sally was single and attracted to pudgy bean counters. It was kismet.

Before any nuptials could be planned, however, TCPIP Corp. bought out Fergenschmeir Inc., requiring the two AD stores to be merged in some form or another. The test scenario required the solutions to be able to manage two directories, to provision users from one directory into the other for the purpose of accessing file shares and applications across domains, and to migrate the entire contents of the Fergenschmeir directory into the TCPIP AD forest to complete the acquisition.

With the TCPIP acquisition behind them, Sally and Harry could finally plan their wedding, and Sally would take Harry’s name. Taking their cue from the change to Sally’s record in the HR application, our solutions would then change Sally’s last name across all managed resources within the infrastructure without administrator intervention.

Unfortunately for Harry, things were about to take a turn for the worse. One evening over dinner, Sally inadvertently mentioned that one of Harry’s senior colleagues had successfully bargained for a sizable bonus during the acquisition process. Harry had to see this for himself, and he surreptitiously stole an administrator password by watching a careless admin log in to a system. Armed with his misbegotten admin privileges, Harry added a user account directly to AD and gave that account access to the payroll files.

Although tracing this action to an individual is really outside of the realm of identity management, flagging and fixing this breach was a test requirement. Indeed, a good identity management system should be able to prevent the creation of rogue accounts via a properly configured rules system. When proof of Harry’s subversive activities surfaced due to a keen-eyed network admin, Harry was unceremoniously dismissed, prompting us to change Harry’s status in the HR system and requiring each solution to detect this change and de-provision all of Harry’s accounts.

Of course, Sally was far from impressed with Harry’s cavalier actions. She immediately filed for divorce and changed her name back to Fergenschmeir, requiring our identity management systems to facilitate one last change across all the systems.

Did Sally quickly rise through the ranks at TCPIP, gain control of the company, and convince shareholders to rebrand it Fergenshmeir Inc.? Did Harry sink into despair but re-emerge years later as the CEO of a global spamming operation? The fates of Harry and Sally following the completion of our test is left as an exercise to the reader, but the ways in which our six identity management solutions handled their ups and downs are quite telling.