Just when I thought we had solved one set of IT security problems by getting the human resources department to properly train new hires, another has cropped up with our IT team and a new single sign-on system it has deployed. The system was designed without input from the IT security team and at least one other department that will be affected. Now we're dealing with the issues after the fact.

The single sign-on project addresses a significant problem. There are several ways for employees to log into different parts of our IT infrastructure, and each requires entering a separate set of credentials.

The single sign-on system will make life easier for users, giving them access to a broad set of applications and services with just one user ID and password.

The IT group has been talking about this for some time, but several obstacles have kept the project sidelined until now. The biggest was the fact that we bought Novell Inc.'s eDirectory directory services and iChain identity management software to handle the authentication of our PeopleSoft system.

But we also deployed Windows 2000, which uses Active Directory for authentication, and our Exchange server uses yet another directory structure.

Unfortunately, these infrastructures were designed separately, with no common vision, so there's a lot of duplication. To make matters worse, none of these directories were mirrored in anticipation of a catastrophe. Sure, we backed up the data, but we didn't have another system on standby to take over the authentication process in the event of a hardware failure.

This week, the IT group and I finally began migrating users to a single authentication system based on eDirectory that's fully mirrored, clustered and load-balanced.

We mirror the data to another data center, so in the event of a fire, malicious damage or other event, the alternate data center will automatically begin accepting authentication requests.

The no-name log-in

This new system makes logging in very convenient, except for one problem. Instead of logging in with our traditional usernames (we used a naming convention that closely matches each employee's actual name), we're using employee ID numbers.

Personally, I didn't even recall that I had an employee ID, much less remember the number itself. Until now, our IDs had been used only by the HR and finance departments for personnel tracking, so I was surprised when I received an e-mail stating that I must start using mine. Like other employees, I was given a week's advance notice and informed that I would also have to change my password.

The decision to use our employee ID numbers in this way has implications for the IT security team. It will end up creating more work for my group and some other groups, such as the IT help desk. Here's why: In our case, most of the audit and security software we use lets us view users by name. Because our log-in names are based on the users' real names, we can quickly match the person to the event when there's a problem.

With the new system, all we see is a number. Identifying the users requires the extra step of matching the IDs to the users' names. Given the frequency with which we'll need to do that, it will be an annoyance and take a lot of time.

Neither the IT security group nor the IT help desk was included in the decision-making during the design of the single sign-on system. Had we been involved, both groups would have voiced strong arguments against using employee IDs for this purpose.

While I don't yet know why the decision was made, I would certainly agree that there is a sense of anonymity in using numbers. Perhaps that was the driving factor.

So far, the problem isn't so bad, because only a few hundred people have been converted to the new system. But soon the entire company will be using it.

Not-so-single sign-on

There's another problem with the new system: It's not inclusive of all our applications. For example, our software developers use a content versioning application that tracks changes in software under development. There are also a dozen or so external development sites, several of which are outside of the U.S., that use this system. To configure this application to use single sign-on would be a nightmare.

Also, the sales department uses CRM tools. Since the information this system contains is highly confidential, the IT team decided not to incorporate the sign-on for it in the enterprise directory.

Within the security department, we have RSA SecurID servers configured to authenticate systems and network administrators to resources within the infrastructure. It would be nice if we could tie that whole system into the enterprise single sign-on application, but we would have too much to lose if there was a security breach.

We use SecurID for access to our most critical systems, which are responsible for our revenue and corporate image. But for now, we are going to keep all of these specialized environments separate from the environment that caters to the mass employee populace.

So, what's the lesson learned here? It's that even as my company and others throw around the term single sign-on, it's rare that an organization of our size can institute a true single sign-on environment that works for all applications enterprisewide.