New Active Directory mode improves little

There's a lot that is good and lot that is bad about directory services.

They have brought a level of consistency, logic, and organization to network administration and programming that was impossible before their arrival. They're also failures in many ways.

The latest development from Active Directoryland in Redmond is the new Application Directory Application Mode (AD/AM). As a recent Gartner analysis put it, AD/AM is a concession to the failures of the full-blown Active Directory in some markets. Some of these failures have to do with extranets and other complex applications where Active Directory causes problems, but I think that it's also a more general attempt by Microsoft to let people nibble at Windows 2000 and Windows .Net Server without having to change their lives.

Misconceptions and false rumors have littered the history of directory services. When LDAP was all the rage about 5 years ago, many assumed that LDAP support brought with it a certain level of inherent interoperability. This was true, except that the certain level was "none." LDAP is a programming method for interacting with directories, but it says nothing about the schemas in the directories, and any useful application will have to know the schema. It's sort of similar to how an inventory application that uses SQL to access the database still needs to know what the structure of the tables and the names of the fields are, and these can differ between inventory databases.

AD/AM runs as a service on any Windows server, or even on Windows XP Pro for development purposes. Administration of the specific directories involved is separate from the domain administration, so IT doesn't need to own it in the way that they need to own directory administration for the network in general. Replication is another important distinction; AD/AM directories will replicate on their own under the control of the designer/developer, so a large amount of bandwidth isn't necessary. In fact, some custom directories may have no need for replication at all.

AD/AM is clearly useful, but it is not, as originally reported, an "unbundling" of Active Directory. It still runs only on Windows, and programmers will likely use Active Directory Services Interface (ADSI) to program it. And while you can make custom schemas and program them through LDAP, that was true of Active Directory in Windows 2000 too.

AD/AM will have some success with new applications, and it may be more appealing to port existing LDAP-based applications to .Net Server with AD/AM than it was with Active Directory. It's tempting at one level to use a global facility like Active Directory to share data between applications or systems across a network, but Active Directory is terrible for this. You don't want to put rapidly-changing data into AD because performance won't be acceptable, and you don't want to use it to replicate changes across public networks because there's so much NOS baggage that goes along with it.

AD/AM changes this by allowing for small directories that can replicate in a more controlled manner. This is why, as Gartner says, AD/AM opens up Active Directory to the extranet market: Finally you can imagine sharing data with client systems across the Internet.

But AD/AM doesn't address the real global problems with Active Directory, unless it makes them less relevant by moving more installations to AD. The real problems essentially come down to a lack of interoperability at different levels. If directory services interoperated better we'd be able to cut administration costs dramatically. The fact that they don't means it's either really hard to do or nobody has an incentive to do it. Shame.

My biggest question is whether AD/AM will help or hinder Active Directory adoption in general. Since AD/AM will work even in an NT4 domain, Windows shops that have been putting off moving to AD will have one more excuse.

Tempting as it might be to think of this as a back door for sneaking Active Directory into such shops, AD/AM isn't AD and won't force anyone to use it. Much as Microsoft might want you to use AD, that's not the point here.

Is your organization considering AD/AM? TalkBack or send e-mail to us.