Uniqueness in the schema....what a pain!

  • Article

For a variety of reasons, several elements of the schema in AD and ADAM must be defined as globally unique. For example, Object Identifiers (OIDs) are assigned by a central authority, and everyone needs to have a unique OID for every element in their schema. When you purchase applications that extend the schema, the application vendor has (hopefully! :)) obtained their OIDs properly such that you will never overlap with another application. We (Microsoft) hand out OIDs to anyone that might need them over the web.

 

One of the AD/ADAM-specific schema elements which must be unique are link IDs. Link IDs are defined at creation of a schema element, and are used in link valued attributes, aka “link value pairs.” When one creates a link valued attribute they typically create tthem in pairs: one is the forward link and one is the backlink. You (the user/administrator) create and delete forward links and AD maintains the backlinks for you. It’s magic. :)

(As time goes on we’ll definitely spend a lot more time talking about the schema)

 

Just like OIDs, one can obtain link IDs from Microsoft. Obtaining your own link IDs for custom schema extensions ensures that you never overlap with anyone else. Of course, everyone and anyone can get all of the link IDs they might want here.

 

That said, it would be nice if this concern were not at all something that application developers needed to think about. That is, wouldn’t it be nice if AD auto-generated your link IDs for you, and you could then read them out of the schema if you would like (it is worth noting that most applications never need to know their own link IDs….therefore even though we might generate them for you, your application probably does not even care what they are, so long as they are unique and work!).

 

Well, we heard you. :) As of the release of Server 2003, AD can generate link IDs for you without a problem. It’s actually pretty easy, and requires a minor modification to your existing schema extensions.

 

So when we create the attributes, here’s the general flow of what we’ll do:

- create forward link

- Update schema cache

- Create back link

- Update schema cache

 

Now the trick, of course, is how to create the forward and back links properly. Let’s say you want to create an attribute ericIsVeryCoolForward and -Back. Here is what your ldif might look like partial of course):

 

ldapDisplayName: ericIsVeryCoolForward
OID: <your forward link OID here>

LinkID: 1.2.840.113556.1.2.50

 

dn:

changetype: modify

add: schemaUpdateNow

schemaUpdateNow: 1

-

 

ldapDisplayName: ericIsVeryCoolBack

OID: <your back link OID here>

LinkID: ericIsVeryCoolForward

 

dn:

changetype: modify

add: schemaUpdateNow

schemaUpdateNow: 1

-

 

 

Note that the back link attribute has the link ID of ericIsVeryCoolForward. In place of that you could also use the OID of the forward (the OID you use where I placed <your forward link OID here>).

 

Of course, use OIDs of your own or that were properly given to you by a proper authority.

 

Also, note that I did a schemaUpdateNow in the middle of the. That is also required as otherwise the second element may be unable to find the first when it goes to use it during extension as the first element is not yet in the schema cache.

 

Happy extending!