In part one of this series (Interesting Schema Syntaxes in eDirectory from an Identity Manager Perspective - Part 1) I started talking about the common syntax types available to be used attributes in eDirectory. I covered the really common ones like:

Case Ignore String

Case Exact String

Counter

Integer

Boolean

Distinguished Name

Octet String

Time

E-Mail Address

If you were looking for information on those types, look back at that article and you can get caught up.

There are two more classes of syntaxes left. The first is the somewhat odd types that we pretty much do not use a lot, or are more system directed. The second class is the system related ones that are just really cool and powerful when we leverage them in ways, perhaps not considered when they were designed.

Lets get the first class (for completeness) over with so we can get to the interesting syntax types.

Interval:

This is a 32 bit integer as well, that is usually used to store time, in number of seconds. Like Time, but less about Dec 11, 2008 at 12:21PM and 32 seconds, but more like 3600 seconds, as the time to wait between polls.

Password Expiration Interval is stored in this syntax for example.

Class Name:

This is one of those sort of structural syntaxes, which is a 32 bit EID value. It is used to self define schema. Yet another 32 bit integer, and I cannot think of any cute ways to use it, if you can let me know, as I am always interested in cute tricks like this!

Hold:

This is a two 32 bit integers, one meant for an EID, the other for a value in hex. There is an attribute called Server Holds, that uses it, and I have no real insight into what it is used for. However we could probably leverage this for cases where we want to store a Hex value in reference to some object. I have yet to run into a use for this, but I will keep this one in my back pocket. (Look ahead to Backlink to see how this might work).

Telephone Number

This is just a Unicode string, but as I understand it (LogicSource does not discuss it, but experimentally I have seen this to be true) the comparison ignores the dash, open round bracket, close round bracket and space characters since in a telephone number there are many ways to represent it, but mean the same number. (555) 123-1234 should be equal to 5551231234 and to 555-123-1234.

Facsimile Telephone Number

This is a syntax like Telephone Number, but it has a cute twist, similar to E-Mail address at the back as it allows an additional attribute to describe the type of fax interface that will be used. I do not really understand this one, as by the time I got old enough, fax machines were pretty standardized. I missed much of the early Fax days due to incipient youth.

Edit: I was recently at a client and we ran into an issue where sending the fax number which uses this syntax, so I found out a bit more about it. It has three components, faxNumber the part we usually care about which is the telephone number fo the fax machine. Then we have faxBitCount which I think is meant to store the speed of the device, and then faxParameters which I guess is meant to be some configuration info for the fax machine.

This probably relates to fax issues when there were different standards, and different issues with fax machines. I will plead excessive youth on this one!

Net Address

This is used in attributes like Network Address, and has a 32 bit integer field for the transport type, 0 for IPX, 1 for IP, 4 for OSI NSAP and 5 for Appletalk. But again, just because usually it only uses values up to 5, does not mean you cannot go higher and store an interesting 32 bit number. Then you get an 8 bit field to hold the address.

Numeric String

This is basically the meant for a long numeric strings that you can do sub string compares against. The data is a Unicode text string.

Octet List

This is a list of Octet values.

Printable String

This is just a text (Unicode) field. There is really only a minor thing special about it. Basically it allows most ASCII characters, but disallows a few. Semi colon being the best well known. Avoid this in almost all cases, since you get syntax errors when you write a semi colon to it, which is otherwise inscrutable as an error message.

Replica Pointer

This is a system level syntax, that I would probably avoid using. It might useful as it has a bunch (six) of 32 bit integers followed by a data string, but I have yet to see a need for this one.

Stream

When you have an attribute that contains a large amount of data, or potentially could, it makes sense to store it as a Stream syntax attribute. This is stored as a separate file in the DIB directory, not as part of the eDirectory database (DIB, Directory Information Base, from the X.500 days) itself. This helps keep the DIB size reasonable and still allows you to 'attach' large data attributes to the directory.

Unknown

I actually do not get this syntax type, it looks like it is just a binary string. But I am not sure exactly how this would be used. From the name of Unknown, it is probably best to avoid this.

Now on to the second type of syntaxes, really cool syntax types that we can leverage and reuse all over the place.

Time-Stamp

This is a 32 bit integer, then a 16 bit integer, then a 16 bit integer. These have meaning in the context of describing information about a replica, but not that relevant to this article. However, this is one you could leverage when you need to store several numeric values in a single attribute type. As long as 16 bit integers are enough, you can use the set together. (Remembering that a 16 bit integer is only good for values up to 65536, which is large, but sometimes not large enough).

Typed Name

This one is three 32 bit integers. Meant to hold an object reference via Object ID, then a priority, and finally an interval, which gives you a useful data structure, like Time-Stamp, to hold three 32 bit integers together. I have not yet encountered a use for this one personally, but I can see where I might want to store a set of numbers in an attribute, and keep holding this one in my pocket for the time I need to use it.

Component names for IDM use:

• • dn

• • level

• interval

Backlink

This is probably my favorite syntax to reuse. My boss showed me this trick at a client, and I loved it so much, I just want to use it every where!

Backlink is two parts, a DN and then a 32 bit integer value. This is meant to be used to reference a link between objects in different server replicas. Thus we need the local Object ID (DN attribute part which we can translate since it is local) and then the remote object ID, which we cannot translate, since it is remote.

Well every time you see a 32 bit integer, you should be thinning, what else can I do with a 32 bit number? Well as we discussed in the Time syntax attribute, eDirectory stores time as a 32 bit signed integer that represents seconds since Jan 1, 1970.

What can you do with a DN and a time value? Well, that's where the fun begins. Imagine you want to store a timestamp on an object, but really you want to store one timestamp for each connected system they use. Say each driver in your Identity Manager system. I dunno, maybe just a create time attribute to track when this user in the Identity Vault was connected (association added) to the connected system. Do note, the criteria I am thinking about in this example is when the association value is added, which does not mean only when the user was created, as it could mean when the user was matched to an existing user in the connected system.

Thus you could define an attribute acmeSystemAddedDate of syntax Backlink, that is multivalued, and in the Input Transform of the various connected systems drivers in your Identity Vault, you could add a rule, if operation is add association, then add this attribute with the DN of the driver (use the Global Configuration Value dirxml.auto.driverdn which is always available) and the current time in CTIME, using the Time token.

Then as any object gets associated it also gets this attribute. You might want to check if it is already set, and then do something for the case where this user already has a value for this attribute for this driver. I dunno what, maybe just note it, as it is not a normal thing. Maybe send an Audit event, maybe send an email.

You could use this to track last login times from connected systems in a similar fashion. Or possibly password expiration times, per driver, or the like.

Object ACL

ACL's are the trustee rights that are granted between objects in eDirectory to allow access to other objects. It is a structure attribute as well, with three components. A DN (object that the trustee is to apply too), a privilege value (bit mask of the rights), and protectedName (attribute or pseudo attribute that the trustee applies too.). Take a look at a couple of articles on ACL's for much more information than I need to repeat here:

• • Example of a Use for a Toolkit Rule in Identity Manager

• • Setting eDirectory ACL Entries with IDM

• • Cool tricks using XPATH on nodesets

Here you have the ability to store an integer, with a DN, and with a string. Lots of possibilities here for leveraging this attribute. Could store a timestamp, and maybe a version number for the previous example of some timestamp per driver. Keep all the values, just store them as 1, 2, 3, etc...

Path

I suspect this is the most over used attribute. The dead giveaway before I understood this fact well was in the DSBrowse, the C-Worthy (Blue screen with yellow text menuing system used on Netware) tool to walk the eDirectory tree, when it was showing these type of attributes would decode the values with Path specific names, which made little sense in the actual context.

For example, DirXML-Associations use this syntax, which is an integer that stores association state (usually 0-5), but was originally meant to store a namespace value (0 for DOS, 1 for MAC, 2 for UNIX (NFS), 3 for FTAM, and 4 for OS2). The next component is a DN to reference the Driver this value is for, originally intended to be the DN of the volume object the trustee is pointing at. Finally a Case Ignore String attribute that we now use for the Association value (For what those values are see this article: Open Call - IDM Association Values for eDirectory Objects ) originally meant to be the path in the file system.

Home Directory uses it for its true purpose, of defining an actual path in the file system.

There are lots of fun uses much the same way as Object ACL can be reused in interesting ways all over the place.

Component names for IDM use:

• • nameSpace

• • volume

• path and sometimes path.xml

Postal Address

This is an interesting one, as it is basically 6 string fields, which can be quite useful. I have discussed in the past (Working in IDM 3.0.1 after using 3.5.1 ) a way to consider using this syntax type in an attribute to replicate the mapping table functionality that Identity Manager 3.5 added (Mapping tables and Render browsed DN relative to policy option ). Basically this could buy you 6 columns of data, in a multi valued attribute that could mimic a mapping table. Obviously mapping tables are a hugely better option, but sometimes you do not have that option available.

Having gone through some of the schema syntax options, it is clear that there are a lot of options, and sometimes the most obvious syntax (Case Ignore String), is not the best choice, even though you could probably make it work.

When considering your options, try to think creatively because you can get some real benefits by smart usage of syntax choices.

One thing I should mention at the end of this series is that while eDirectory Schema is quite extensible, it is not currently possible, through the standard methods, to extend the Schema syntax types. In other words we have this set of schema syntaxes available to use on any attribute we want, but we do not have the ability to add new Schema syntax types.

I imagine it would take a code update to eDirectory from Novell to add a new schema syntax, which I am sure, if there was a real need for it, Novell could or would do, but not something we as end users will get the option to do. Thus getting familiar with what there is available now, is fairly important.