On this page, we share with you some facts, tricks and tips
that we uncovered during our "playing around" with
eDirectory and LDAP over the years. Some of these are
just "fun facts," but some of which will hopefully save you
some headaches.

Modifying Schema using LDAPTo add a new attribute or class to your eDirectory schema, it is easiest to use the Schema Manager
(either from within ConsoleOne or iManager). However, if you need to make changes to the schema, it
is easiest to do so using a LDIF file via LDAP. The LDIF file for modifying an object class looks like this:

You need to first delete the existing class definition and then add it back with the change(s) you want
to include. The key is to perform the delete and add in a single step as shown in the LDIF file above;
the two operations must be done in the same changeType operation. Note that the delete and add
operations are separated by a "-" on a line by itself. This tells the LDAP server to perform them as
one single operation, known as an atomic change.

You can modify an attribute definition in a similar manner by changing "objectClasses" to
"attrubuteTypes".

Creating a Test TreeIt is fairly often that a test environment mirroring the production tree need to be created for
development and testing purposes. In most instances, one just needs the same users and groups be
duplicated - since it will be difficult to duplicate all NCP Server and Volume objects in a medium- to
large setup due to hardware requirement. The main challenge in creating a test tree is in creating the
container structure.

For a small or flat tree, the tree struture can be easily created manually. However, for a large or deep
tree, it will be labor-intensive. However, this can be easily accomplished in two simple setps using the ldapSearch and ldapModify gadgets as follows.

Searching for High-Valued AttributesSometimes you may experience high server utilization due to some attributes having a high number of
values, say, 500 or more. You can use DSBrowse NLM to look for such attributes (see Novell TID
10081054) on NetWare. The DSBrowse module on non-NetWare platforms (such as Windows) do not
support this feature, but you can use iMonitor instead (see Novell TID 10090648).

An easier alternative method for searching high-valued attributes is to use the Attribute Tools gadget.
Attribute Tools v2.4 and later has a Report high-valued attributes option that can generate a report of
objects (types based on the specified search filter) and list of attributes that have "x" or more values.
You can optionally check only selected attributes instead of all, and list their values:

Importing Binary Data via LDIF FilesWe are all familiar with how to import binary data into an LDAP datastore using an LDIF file. You first Base64-encode the binary data or file and then include the result in the LDIF file, in the syntax similar
to the following example:

Next, create the containers in the test tree, using the LDIF file created by the ldapSearch gadget. You
can either use the ldapModify gadget, ldapadd, ICE, or your faviroite import tool. Note, however, the
tool you use must be able to use LDIF content records as add changetype records or you will need to
modify the LDIF to include changetype records before using it.

Use these steps to create the containers using ldapModify gadget (see Figure 2):

Once the tree structure is created, you can then populate it with User and Group object information
exported from the source tree using ldapSearch. To retain the correct user-group attribute
relationship, you need to export/create/update them in the following order:

*You can include other attributes values for export, but need to be careful of any attribute that
references a DN, such as ACL or homeDirectory, as the target DN may not exist in the test tree. For
example, a user or a group may be granted trustee rights over a Volume object for file management
purposes. However, more often than not, the test tree will not have such an object. When importing
an LDIF file, each record set (each DN "record") is treated as a whole, meaning that if one of the
attribute values in the set failed to be modified, all other changes specified in that set are discarded.
This is known as an atomic change operation. Therefore, if your export include such values, check and
remove values referencing non-existing DNs from the LDIF file before performing the update.

(Base64 encoders and decoders are readily available for most, if not all, O/S platforms. There are even Web-based ones which are handy should you find yourself in need for a Base64 encoder/decoder on
short notice and you do not have one on your workstation.)

The above procedure is fine if you only need to import a few binary data values or files. But it
becomes labor intensive very quickly if you have, say, five or more files or data values to import or if
you need to perform this task frequently. Here is a seldomly-employed shortcut.

It is a little known/used fact that LDIF supports the use of URL as an attribute value specification.
We do not mean using URLs as values for Network Address or string-based attributes such as
Description. Instead, this feature allows you to instead of putting the data in the LDIF file, specify
where the actual data is to be retrieved from.

The LDAP Data Interchange Format (LDIF) - Technical Specification (RFC 2849), states that
implementations should support the file:// URL format where the contents of the referenced file are
to be included verbatim in the interpreted output of the LDIF file. What this means is that instead of
having to Base64-encode the file first, you simply specify the filename in the LDIF file directly:

Unlike iMonitor, the log file generated by the Attribute Tools gadget can be easily accessed and be
copy-and-pasted into your own reports. A future version of Attribute Tools will support batch mode for
this reporting function so you can run it under a scheduler and have the log file email to you
automatically on a regular basis.

Isn't this a lot simpler and easier?

Notice the syntax: you need to use ":<" as the value specifier instead of ":" or "::", and the actual URL
specification is file:///path where the last "/" indicates localhost, a requirement. The path's notation
is OS-dependent; for example, on Windows, it would be in the form [drive:]\path\path\file, and on
Linux/Unix, it would be /path/path/file.

So far, we have only tested this feature successfully using openLDAP-based tools, such as the ldapModify gadget, Novell's ldapmodify, ldapadd, and ICE, but most modern implemenations of
ldapModify or similar utilities "should" support the file:// specification but may not (as the RFC does
not call for mandatory support).

Tip: You can use this URL method to import data, either text or binary, into attributes of any type. Although it generally does not make much sense to use this method for integers
or short text strings, but it is handy in importing data such as login scripts or SSL
certificates without having to Base64-encoding the files.

LDAP Search Filter Tips and TricksMultiple-match conditions. The LDAP search filters are fairly straightforward to understand and use.
However, when you need to impose some complex conditions, such as searching based on three or
more tests, the syntax becomes involved rather quickly.

For example, to match on more than one attribute, one uses either the AND (&) or OR (|) operator:

(&(cn=test_user)(objectclass=user))
(|(title=manager)(title=vp))

The first example searches for all user objects whose CN is test_user. The second example searches for
any object that has "manager" or "vp" as the title. When you need to impose additional conditions, you
need to "nest" them. For instance, to match on three attributes:

This works for eDirectory versions at least up through 8.8.3 but may not work with later versions, as
such filter construct is not RFC-compliant. However, in the mean time it provides a nice, more
readable, filter to a complex search situation.

Substring searches. We all know how to search for a substring, such as using (title=*manager*) to look
for objects that has the word manager anywhere within the title attribute. However, how do you
search for the character "*" or a substring that has a "*" in it? LDAP provides a simple escape mechanism
to handle cases where ambiguities may exist:

! = \21, & = \26, * = \2A, : = \3A, | = \7C, ~ = \7E

For example, the filter for finding objects with the "title" attribute containing a value with the "*"
anywhere in it would be represented as "(title=*\2a*)".