Techniques for Extending the Schema

Creating and updating the directory's schema can be done the same way as any other update to a directory's objects. We discussed how to create and modify objects in Chapters 3 and 6 and these techniques are still valid for schema objects as well. It is possible to use any of the various tools or APIs that can perform these operations. In fact, for .NET version 2.0 users, there is pretty good support for all things schema related using the ActiveDirectorySchema* classes in the System.DirectoryServices.ActiveDirectory (SDS.AD) namespace.

As such, you might be surprised to hear us recommend not using SDS to create or modify schema. After all, it does work, and it is the API this book is primarily about. Why not use it here too?

Instead, we propose to stick with using Lightweight Data Interchange Format (LDIF) scripts, which are standard ASCII-based scripts, for declaratively updating the directory. Both Active Directory and ADAM ship with an LDIF client (called LDIFDE.exe). There are a few reasons for suggesting LDIF as your primary tool for performing schema extensions.

• Schema extensions are performed infrequently and are generally performed by administrators, not developers, especially with Active Directory, which requires high privileges for schema modification.
• LDIF makes it very easy to keep a record of schema modifications so that we can perform them again later, perhaps when moving between a development and a production environment or from ADAM to Active Directory.
• Compiled code is fairly opaque to administrators, who typically prefer LDIF scripts for their readability. Very few administrators will simply trust a compiled program to update their directory, unless they wrote it themselves. LDIF scripts are easy to read, and as such, administrators can view what they are supposed to do.

Is it still possible to extend the schema with SDS? Of course! However, we do not believe this should be done as a general rule. There will always be cases where this is the appropriate thing to and we leave that to your discretion. We will include some samples at the book's web site for performing these operations should we need them.

If we think about it for a moment, we do not often find ourselves building a SQL database with ADO.NET calls, do we? Instead, it is far more prevalent to script out the database design in a set of files that contain DDL statements, and then execute them with a tool such as a query analyzer (or to hand them over to a database administrator!). The same basic theory applies here as well.

We do not attempt to provide a tutorial on LDIF here, but there are a variety of online resources that can help with this, including the Microsoft online documentation we already referenced. The tool and file syntax are very straightforward and developers or administrators should not have any difficulty using them.