Trawling through the
namespace as we have been, it may have occurred to you that it's a bit, well, flat. There's very little use made of containers, for example, the schema is limited, and it's unlikely to scale very well when we move towards large distributed systems — we're talking about systems requiring directories of millions of objects here. Microsoft has realized this, and is now making a major push towards the Lightweight Directory Access Protocol, or LDAP. Now, who said that Microsoft ignores existing non-proprietary standards and persists with its own? Actually, I can think of just two proprietary standards that Microsoft has stuck to in the face of pressure from the rest of the software industry: Windows and COM. Everywhere else the move has been towards implementing standards such as LDAP. Mind you, the proprietary standards that they have kept to aren't at all bad. Say what you like about Windows, but COM is a thing of pure beauty … but then we all knew that, didn't we?WinNT:
LDAP was developed at the University of Michigan as a front-end to the more complex X500 directory protocol, and was formalised in 1995 in RFC 1777. If you want to do some more extensive reading, the best place to start is the University of Michigan's LDAP page, located at URL
. This has got links to just about every resource to do with LDAP.http://www.umich.edu/~dirsvcs/ldap/
There are five distinct aspects to the LDAP definition:
The Data Model defines the syntax of the data in the directory. The model is centered around entries, which are composed of attributes; each attribute has a type and one or more values. Remember what I said about ADSI properties being increasingly referred to as attributes these days? Guess why.
The Organizational Model defines how the data is organized in the directory. Entries are organized in a Directory Information Tree and divided among servers in a geographical and organizational distribution. Each entry has a Distinguished Name (DN), each component of which is called a Relative Distinguished Name (RDN). We’ll see some of these very soon.
The Security Model defines how the information in the directory is accessed in a secure manner. This is based on the Kerberos authentication model, which we’ll be looking at briefly in Chapter 9.
The Functional Model defines the operations for querying and modifying the directory. This defines how to carry out such operations as adding entries, deleting entries, modifying entries and making queries. There is in fact an entire LDAP ‘C’ API specified and supported by Microsoft, which you can use in place of ADSI if you’re feeling perverse. (ADSI’s a whole lot more straightforward!)
The Topological Model defines how the directory service integrates with other directory services to form a global internet-based directory service. One or more LDAP servers together make up the directory tree. If an LDAP client makes a request of an LDAP server, and that server can’t satisfy the request, it passes the request on to another that can. All this is completely transparent to the client — in marked contrast to the WinNT style of directory. Note also that the remote server doesn’t have to be running Windows, provided that it supports LDAP.
One word of terminology here — an LDAP server is a piece of software that implements the LDAP protocol. An LDAP provider, on the other hand, implements the OLE DB-based ADSI provider protocol on one side, and LDAP on the other; it’s a gateway between ADSI and LDAP.
Note that in order to run the rest of the examples in this chapter, you'll need to be running the NT5 beta.
If you run our
application again, and explore the DirManager
namespace, you'll notice some significant differences. First of all, the pathnames have a different format. For example, the first container that you'll come to under LDAP:
has a pathname like this: LDAP:LDAP://DC=OverTheHills,O=Internet
(Depending on which version of Active Directory you're using, you may or may not see the
part — this is being phased out).O=Internet
The part to the right of the
namespace identifier is referred to as the distinguished name (or DN), and it identifies the domain that holds the object, as well as the complete path to reach the object through the hierarchy of containers. You read the DN from right to left. Typical components in a DN are organizations (identified by LDAP:
), domain components (identified by O=
) and common names (identified by DC=
). If your domain looks like, say, CN=
, you'll have two segments in your DNs: microsoft.com
.CN=microsoft,CN=COM
Domains can be linked together into domain trees and forests by trust relationships. Here's a typical transitive domain trust relationship:
Let's dig a little further into our
namespace by double-clicking on the entry for the domain component. Here we come across our second major difference: the namespace is fully containerized! There are containers here for entities like LDAP:
, Users
and so on. One curious thing, though: the schema isn't part of the standard tree; in the Computers
implementation, the schema is hidden — we'll see where in a little while.LDAP:
If we open up the
container, we get to an administrator object, similar to the one we found earlier in the Users
namespace. This time, however, it's got a pathname of:WinNT:
.LDAP://CN=Administrator,CN=Users,DC=OverTheHills,O=Internet
What else is different about it?
If you click on the Class… button to display its properties, the most striking thing is the sheer number of properties that have been specified for this class (of type
). Here is a screen shot of my ADS object for user user
:Administrator
As you can see, we've now got some mandatory properties, plus a whole host of optional properties (I've only shown some of the ones starting with 'a'!). The other interesting thing is that our user class now has an Object Identifier (or OID). Remember that OIDs are unique identifiers, which are issued by international standards organizations in much the same way as IP addresses. If you explore further, you'll probably notice that the
class has an OID of 1.2.840.113556.1.3.23, and that the container
class has an OID of 1.2.840.113556.1.3.30, which suggests that Microsoft have probably been allocated the space 1.2.840.113556 in the universal ISO-ITU OID tree.computer
The fact that we have got this far without changing a single line of code in our
application (which was — quite frankly — a pretty rudimentary demonstration of ADSI) is, I think, pretty impressive. It is a testament to the way in which ADSI has successfully hidden from us the provider-specific aspects of the two namespaces that we have been exploring.DirManager
Let's consider the implications of these OIDs. The OID structure in LDAP is about nothing more than setting up an environment in which any type of object in the entire world can be uniquely parameterised. You could, in theory, put together all the LDAP directory systems in the world, using one single schema, and they would all work together without any class ambiguity! It's an astonishingly powerful concept, and ever so slightly scary. (For some reason, the SkyNet system in the Terminator films comes to my mind whenever I think of this …)
However, a significant corollary of this is that you really should think twice before extending the schema. The chances are, unless your object class is really obscure and unusual, there's something already out there that will do. If you really must, then OK, go ahead and contact your friendly neighborhood ISO, get your OID space and set up your own internal standards organization to manage it within your corporation. Once you've set up the logistics of managing the allocation of OIDs, creating them is child's play using ADSI. It's just a question of creating new objects in the schema container using the ADSI methods that we've already encountered.
Ah! The schema container. In the
namespace, this is hidden away in the highly non-standard path of LDAP:
. If you take a look at it using our sample application, you'll find all the usual suspects, plus a host of others. All the properties are there, too. In LDAP://schema
, however, the syntax objects are built in — you can't change these or add to them. Here's a screen shot of the start of the schema:LDAP:
