Directory Programming .NET

    I am completely new to all this LDAP and Active Directory stuff. After a week of code searching I was glad to find this forum on the subject. We want our software to be able to store it's configuration settings inside a directory server along with users for authentication. We don't want to be tied down to Microsoft Active Directory so we were hoping to just use the S.DS.P namespace classes to perform everything we want to do. To first get familiar with directory servers that implement LDAP, I installed Apache Directory Server and viewed it's contents with LDAP Admin (from source forge). We also have a test machine that is running Server 2003 along with Active Directory.
    I understand now that all servers have a schema that lists all the class objects and class attributes that the server should know about. Some of these classes seem to occur in all servers such as 'Person' or 'inetOrgPerson'. Other classes are specific to the server such as 'ApacheCatalogEntry'. I am looking for C# code that can add a new class to either Active Directory or another directory server like Apache. I have seen some post talking about creating an LDIF file and importing it to the server. This seems to work, but I would rather perform this programatically.
    I am hoping for code samples on how to add a class programatically to a server schema, along with how to add new class attributes. I am hoping this can all be done with the S.DS.P namespace, since that simply uses LDAP protocol. Obviously the S.DS.AD namespace is purely for AD, but what about the S.DS namespace and the classes such as DirectoryEntry? One concern of mine is with regards to the unique identifier that each class/attribute must have. How do you create a unique identifier when you are not sure what identifiers the directory server schema file already has?
   What I am hoping to end up with is a new class object called ProductName with attributes WebPort, DisplayTime, Name, etc. There are going to be some attributes that already exist on the server such as Name. I'm not sure if it's best to mix the new class with new attributes and current attributes, or if we should simply append the class name to the attributes to help make them unique to the class, such as ProductName_WebPort, ProductName_DisplayTime, ProductName_Name, etc.

It is generally regarded as bad form to do schema mods programmatically.  Admins tend to hate this.  Also, the permissions you need to do this are usually much higher than the permissions needed to do other tasks like read operations or mods to specific objects in the tree, so admins tend to not like to grant these permissions.

You really want to specify your schema mods in LDIF files.  It is the universal way of doing it and allows the admins to inspect your schema to see what it is that you are doing.  It also makes it very easy to transport your schema settings from one directory to another and make sure your deployments repeatable.

The actual steps to do this via LDIF vs. programmatically are about the same.  Creating schema mods (in AD and ADAM at least) is done by adding new objects to the schema container of type attributeSchema or classSchema.  If you examine any sample LDIF files such as the ones that come with the ADAM install, you can get a good feel for how this is done.

Note that there may be some platform-specific differences between different directories that may require you to have slightly different versions.  This may or may not be true.  I'm not sure, but it is something to look out for.  Some of it depends on the syntaxes you use for attributes and what you do with more advanced features that may be platform-specific such as linked attribute pairs and indexing flags.

All in all, LDAP schema design is a bit of a black hole in terms of knowledge, code samples and tool support.  You can definitely piece together what you need to know by reading the MSDN docs on extending the schema and some LDIF files and trying things out (that's how I did it), but it is hard to find the perfect jumpstart.

    Thanks Joe,
I've discussed it with the others and they agree an ldif file is a good way to version our products, ie: every new version can have a new ldif file associated with it. I've actually seen different types of ldif formats so I'm confused as to what to look for in terms of research. Wikkipedia gave this example of ldif:

dn: CN=John Smith,OU=Legal,DC=example,DC=com
changetype: modify
replace:employeeID
employeeID: 1234
-
replace:employeeNumber
employeeNumber: 98722
-
replace: extensionAttribute6
extensionAttribute6: JSmith98
-

Here the ldif file modifications to the values of a particular entry. Using LDAPAdmin, a client application for exploring LDAP enabled directories, I asked to export the entire thing to an LDIF file. It created a list of all the classe objects and attributes along with matching rules and syntax. An example is:

dn: 2.5.4.3=schema,2.5.4.11=system
attributeTypes: ( 2.5.4.49 NAME 'distinguishedName' DESC 'RFC2256: common supert
 ype of DN attributes'  EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.
 115.121.1.12 USAGE userApplications )
objectClasses: ( 1.3.6.1.4.1.4203.1.4.1 NAME ( 'OpenLDAProotDSE' 'LDAProotDSE' )
  DESC 'OpenLDAP Root DSE object' SUP top STRUCTURAL MAY cn )
matchingRules: ( 2.5.13.10 NAME 'numericStringSubstringsMatch'  SYNTAX 1.3.6.1.4
 .1.1466.115.121.1.58 )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.47 NAME 'Supplier Or Consumer'  )

These both seem quite different. The first looks more organized with a DN login at the top and then a series of command keywords terminated by the finished symbol '-'. The second is what I would probably have to make in order to describe my own classes and attributes. I'm not clear on if matchingRules and ldapSyntaxes is something I would need to create. Also there are a lot of keywords here like NAME and DESC. Where could I get a list off all keywords that LDIF files use?

    One other thing, what is the significance of the OID and Syntax numbers? Are these dot seperated numbers supposed to represent a date or version? More importantly how do I go about creating my own OID and Syntax numbers for my custom classes and attributes? Do I first have to search through the directory server to get a list of all known OID/Syntax numbers to avoid conflict?

I'd suggest looking at the schema files that come with the ADAM install as good examples of LDIF files that do schema mods.  They demonstrate best practices for doing AD schema updates.  You can go from there to figure out how to apply the same types of schema mods to other directories.  The files will be in the ADAM directory after you run the installer.

Regarding OIDs, they are basically similar to GUIDs in that they represent unique identifiers, but they are more like DNS in that the decimal/dot notation implies hierarchy.  There are many well-known OIDs out there for things like attribute syntaxes.  OIDs are used extensively in cryptography and PKI as well.

For naming schema elements, you generally get your own prefix and then create schema mods based on issuing sequential values to your prefix.  For example, if you register the prefix 1.2.3.4, then you might issue new attributes like 1.2.3.4.1, 1.2.3.4.2, etc.  You can get a new random prefix from Microsoft or you can get one through a number of different services like IANA as I recall.  It depends on what you want to do.

We also discuss some of these details in ch 7 of our book in case you are interested.

    I was looking at RFC 2849 which talks about the LDIF format. I was surprised that it didn't mention syntax for schema objects/attributes. It only gives examples on how to add/del/modify entries. Does this mean the LDIF used to create schema objects/attributes is specific to the directory server used (AD vs Appache for example)? If so this is not good news for us as we would want to create an LDIF file that lists our objects/attributes that we can then imput into any LDAP aware directory server.
    When it comes to the OIDs, you mentioned going to Microsoft or IANA to get a new prefix. Are there any known test prefixes that are ok to use for the time being? I guess I could just make up my own, then try to add them into the server to see if it conflicts.
    What is the name of your book? I would be interested in a good LDAP resource, but we are not looking to only be AD compatible, so if most of the book is specific to AD then it's likely not for us.

LDIF is a general purpose format for exporting and modifying LDAP directories.  Since the LDAP schema is stored within the directory itself, LDIF can be used to modify the schema.  It does not suprise me that a tutorial on LDIF would not mention schema mods directly.  From the LDIF perspective, these are just other objects in the directory to modify.

I would not be surprised if you run into a few differences between directories in terms of the "schema" for schema types.  I think many of the attributes are the same, but there will likely be some differences.  For example, Microsoft recommends that you set the schemaIDGUID attribute on your schema objects but that is a proprietary AD and ADAM feature, so it would not apply to other directories.  MS also uses different OIDs for LDAP syntaxes that most other directories (2.5.5.1 for DN for example) instead of the longer versions.  I think it accepts the traditional longer versions for backwards compat purposes, but none of the MS docs cover this.

Essentially, you'll need to dig deeper to understand this subject completely and know exactly what you are up against.  In general, cross directory LDAP support is tricky, much like trying to do platform agnostic SQL.  You tend to end up adding significant layers of abstraction to make it work and frequently end up compromising on features to support the lowest common denominator.

I'm not sure about know test prefixes, but you can make your own up as long as they never leak out.  When you request a prefix from MS these days, they just use a tool to generate a new random one for you.  There is no real magic there.

This site is actually the support site for our book, so you can find info about it at the root level of the site.  :)

Just want to chime in on one thing.  Microsoft no longer registers OIDs for users anymore.  Instead, you are pointed to a script that will generate a random OID.  However, you should never use this OID if you are an ISV (especially if you are an ISV).  You should register your OID appropriately.

---

Ryan Dunn
Extemporaneous Mumblings
The .NET Developer's Guide to Directory Services Programming