Interesting Schema Syntaxes in eDirectory from an Identity Manager Perspective – Part 1


By: geoffc

December 19, 2008 4:14 pm

Reads: 286



As we all know by now, Novell eDirectory is a very powerful and scalable directory service with lots of really neat features.

One of the many nice things that differentiate it from its competitors is the ease of replication and partitioning the database. It is hard to find some other directory service that makes it as easy to move partitions and replicas around quite like eDirectory.

This has real world benefits, for cases where you have applications you need to accommodate that have strange or unique data requirements. For example you might have an LDAP application you want to authenticate to eDirectory that for some reason decided that the attribute for email should be ‘eMail’ not the more standard ‘mail’ attribute name. Or perhaps the other way around, the directory is not storing the email address in Internet EMail Address (which is what LDAP gets back when it asks for ‘mail’) but rather in acmeEmailAddress and you want to make the LDAP application work for your design.

Well you can quite trivially change the LDAP attribute mapping in the LDAP Group object, so that when an LDAP application asks for ‘mail’ the attribute the Novell LDAP server (NLDAP actually is the module name, original eh? NLDAP.NLM on Netware, nldap.dlm on Windows, and nldap on Linux/Unix) returns will now be the value found in acmeEmailAddress instead of Internet Email Address.

Now this might break other applications that were expecting the value that is actually in Internet EMail Address. Well you could just start another eDirectory instance somewhere else (on the same box (Linux/Unix) is allowed with eDirectory 8.8 or on another box or VM slice) for this application and all is good. It is so easy to add another replica on another box somewhere that it is not even worth fighting the issue, just do it.

That can solve an entire class of problems. However there is another entire class of issues that will be trickier. That would be the case of different schema types that eDirectory supports.

Out of the box there are a number of really interesting schema syntaxes in Novell eDirectory available that we can use. I am getting my definitions from LogicSource for NDS, a super cool document that alas, seems not to be maintained. Used to have to buy it, and now you do not seem able to get it. It is a great document explaining a lot of low level eDirectory internals. (1500 page PDF! I kid you not! Appendix B is syntax types, pages 1345 to 1357)

Many of them we are familiar with and some of them are used in the background and we do not see them, but they are used all over the place.

Lets start with the simplest and I think the most common syntax type and work towards the more interesting and complex syntax types.

Case Ignore String (CIS, coincidentally the acronym for the company I work for):

This is a very common type for pretty much any attribute that needs to store text data. What is unique about it, is that it stores the case of string (upper case or lower case) but if you compare against it, it ignore the case when comparing.

This is great and very popular when making your own schema attributes.

The size of the attribute (how many characters long can it be?) is immaterial to the syntax, and is set when you create an attribute USING this syntax.

If the attribute is multivalued is also immaterial to the syntax, as that is attribute specific as well.

This syntax type is used pretty much on every single line, free text attribute that you see hanging around in eDirectory.

Case Exact String:

This is sort of the same as CIS syntax, difference should be obvious from the name, it stores case and enforces the case on compares.

Pretty straightforward.


This is sort of a neat syntax. It basically stores an integer counter, but you are really supposed to just increment/decrement it, rather than setting a specific value.

Things like Account Balance, Login Intruder Attempts use this one.


This one is just an integer value syntax. You can size it when you define an attribute, or leave it completely unsized. I guess it maxes out at a 32 bit number.


The classic true/false attribute.

Ironically, in eDirectory this attribute actually has three possible values. Does anyone remember the old Cat Vax joke? The story was something like the Rochester Institute of Technology came up with a new quantum computing model, involving large arrays of Schroedinger cats experiments. The cats were in one of three states, alive, dead, or somewhere in between.

Well eDirectory has much the same third value, almost, but thankfully no cats were harmed in the use of this syntax.

That is, if the attribute that is using Boolean syntax, and is set to true. It is true. If it is set to false it is false. If the attribute does not exist then its value is false.

This has a huge consequence for Identity Manager implementations where if you want to test if a boolean value, you have to think about those three possible values, not just true/false or true/absence. Once you know about it, it is trivial to account for, but took me an embarrassing long time to notice. This taught me a lesson about learning. Turns out you can learn something from ANYONE even a professional bowler! (This is a hat tip to you Ray G!) I was at a client, and a guy working there, really new to IDM was using a boolean and setting it to false. I always thought it could be true or absent. Oops… Had to fix some code for that but was a great thing to learn.

Distinguished Name:

This is probably one of eDirectory’s most powerful attributes. I use this at every single client. Lets use the example of a Work Order in eDirectory. For whatever reason there is no attribute that is DN syntax in the default DirXML-WorkOrder object class by default. I consider a strange lacking.
Using the Work Order Driver in IDM

There was a great article about working around this issue, (Making Sure Your Work Orders Work!) to which I responded saying, all the work you need to do is solved if you use a DN syntax attribute to store the target user.

What DN syntax buys you is the ability to follow an object through a rename, move, and ultimately a delete of the object. What is actually stored is the Object ID of the object in the local replica. Whenever you look at it in any tool, it is instantly resolved to show you the full object name of the object. Thus on a rename or move of the object, the name and full location may change, but the object ID did not. Thus the resolution when you look before and after, shows you the correct values at those moments in time.

If you delete the referenced object then all DN syntax attributes that have its value get cleaned up in the background. This is an example of something sorely lacking in other systems, like Lotus Notes. Notes solves this problem by forcing an administrative process to run on regular intervals to clean up references for deleted objects. A pretty lousy solution (in my opinion) but something that needs to be done, because otherwise the data is all screwy. My experience is that admins in Notes systems do not want to run that process often due to load it causes, but then regretting it because of the crap left over due to not running it. It is a pretty bad problem, that does not exist in eDirectory because of this syntax type.

A number of other syntax types are combinations of other syntaxes, and it is pretty common to use a DN syntax field as part of the combined syntax (Path, ACL, Backlink, and others). This is a truly powerful feature, and I will probably never stop harping about how nice it is! (I have buried this discussion in dozens of articles now, because I think it is really important for people to understand).

Octet String:

This is used for storing binary data, like jpegPhoto, Private Key, and stores binary data. Not sure what more to say with this.

Very important, I have never really had the occasion to use this, but it is required for a number of basic function in eDirectory.


This is a great syntax, with a horrible secret. eDirectory uses a 32 bit signed integer for representing time, sometimes called CTIME, or Unixtime. Alas that means only 2 billion or so values in either positive or negative direction. Each unit represents a second since 1970 (either before (negative values) or after). The dirty little not-so-secret problem is that 2 billion seconds from Jan 1, 1970 run out sometime into the year 2036/2037. Yay, a Y2K37 problem!

Now it is not just eDirectory, it is in use all over the place (Oracle uses it in some places, Unix uses it), and everyone has the same problem. I have no clue what we will do when we get close, but I assume someone smarter than me will solve this issue and make it go away somehow. (Shades of Y2K non-planning, right? I apparently do not learn from past experience). Other time types that other systems use are thing like 100 millisecond counts from the year 1601, stored in a signed 64 bit integer value (what Active Directory and other systems use).

Now you will have noticed that ultimately time syntax is a 32 bit integer. So how is this different from Integer, Class Name, Distinguished Name, etc at the storage level? They all use the exact same data storage, a 32 bit integer. Probably one of the simplest data types around.

Well the ultimate difference in using the same storage type with three or more different names is that the tools know how to treat each one differently. A Time syntax attribute is displayed by all the tools that recognize it, usually in a date picker box. DN Syntax attributes should always be shown as a human readable DN, and so on.

Identity Manager uses CTIME internally as well, but probably is the easiest to fix, since the Time() and Convert Time() token can take pretty much any time syntax you can imagine and convert it to any other time format you need. I really like these tokens. Used to be you had to use the Java time functions, which these two tokens are just wrappers around. However the syntax was somewhat painful. Convert Time() and Time() are just plain amazingly simple to use wrappers to that Java time syntax. To see more about it, take a look at this article: Using the Time Tokens in IDM 3.5 These tokens became available in Identity Manager 3.5 so if you are earlier than that you would need to use Java time or upgrade, but it is worth upgrading, and 95% harmless (see these articles on the upgrade process if you are concerned:

E-Mail Address:

This one is NOT your usual email address syntax field. There is a reasonable history for this attribute. It was meant to be used in the days when there was no great standard for email addresses. Remember X.400? (Well if you use any Exchange you will see the X.400 address still (at least in Exchange 5.5, 2000, and 2003 I think. I do not recall seeing it in Exchange 2007 users lately)).

Actually you will often see email addresses stored in places in a syntax like {} and ultimately this is kind of the same idea. There is a 32 bit field, usually only store 0 or 1, then the length of the address in the next 32 bit field, and finally a string to store the email address.

Looking at it, you usually see 1, as the values. As a consequence, we usually do not use this syntax type much these days. In fact Internet EMail Address (yep, the M in EMail is capitalized in schema, so long ago typo) just uses Case Ignore String.

Component names for IDM use:

  • emailType
  • emailAddress
  • I hope this was interesting or helpful to you, more to follow in part 2.

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)

Tags: ,
Categories: Uncategorized

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.