Over in the identity management newsletter I've been recently talking about "virtual directories" and their uses. As part of the discussion, I listed the four virtual directory vendors I was aware of: Radiant Logic, OctetString, MaXware and SymLabs. Some folks wrote to me wondering why Novell wasn't listed. They'd remembered some news stories coming out of last year's BrainShare Europe touting the release of Novell Virtual Directory Services.

Unfortunately, there's nothing "virtual" about this service.

A virtual directory is one without its own datastore. It's what the database people call a "join engine," taking data from disparate directories and tying them together by synchronizing the various accounts that a person has. That is oversimplified. If you want to know more about virtual directories, you could benefit by starting with some of the writings of OctetString CTO, Clayton Donley. His "Directories, Metadirectories and Virtual Directories" white paper is an excellent treatise on the differences between virtual directories and meta directories. It's something Novell's marketing folk should have read before naming their embeddable identity store service because Novell's product much more closely resembles a metadirectory service.

A virtual directory should not impose a requirement to establish yet another directory store. It should help you consolidate the existing identity storage systems you already have. But Novell's Virtual Directory Services does create yet another datastore.

How would you like to be the "manager of VD Services"? As I said, marketing didn't think this one through.

In fact, the one thing that VD Services does resemble is Microsoft's Active Directory Application Mode (ADAM) product. It's a way to create a local directory for use by a specific application that may or may not be connected to the workgroup, department or enterprise directory system. There's nothing wrong with that. In the Active Directory world, administrators are even more reluctant than eDirectory administrators to authorize schema changes. Application developers are then forced to either forego using the directory for storing information or, worse, are forced to use existing attributes for purposes other than that for which they were intended.

For example, suppose there was a field called "home phone" to list a user's home phone number. Your organization doesn't use it but an enterprising programmer on your staff realizes that it's the right size and format for storing a social security number (which his app needs in order to allow a user to access their 401k plan). Some time later a new administrator, who's just come in and wants to roll out a quick and dirty application so folks know he's doing something, notices that the "home phone" field is populated so publishes a report listing everyone's "home phone" number. Both ADAM and VD Services allow you to safeguard the intended purpose of all the attributes in your directory while allowing the software engineers to most effectively use a directory structure for their apps.

Virtual Directory Services is a good idea. Too bad it has such a deceptive name.

The top 5: Today's most-read stories

1. Windows worm beginning to spread

2. Cisco to juice 6500 switch

3. Help Desk: Sniffing on a switch

4. Zotob worm exploits Windows 2000 Plug and Play

5. Google goes berserk

Today's most-forwarded story:

Cisco to juice 6500 switch

To contact Dave Kearns:

Dave Kearns is a writer and consultant in Silicon Valley. He's written a number of books including the (sadly) now out of print "Peter Norton's Complete Guide to Networks." His musings can be found here.