Technical Notes from DreamLAN.com

DreamLAN.com Home � Products � Tech Notes

DreamLAN.com | A posse ad esse : Creating dream solutions

Modifying schema using LDAP
Creating a test tree
Searching for high-valued attributes
Importing binary data via LDIF files
LDAP search filter tips and tricks

dn: cn=schema
changetype: modify
delete: objectClasses
objectClasses: (1.2.3.4.5)
-
add: objectClasses
objectClasses: (1.2.3.4.5 NAME 'myAuto' SUP top MUST (brand)
 MAY (colour $ nDoors $ sunRoof) X-NDS_NOT_CONTAINER '0')

Enter your LDAP bind information.
Set your start base context; leave it blank if starting from tree root.
Enter $containers$ as the search filter; this is a special ldapSearch gadget macro that expands to include Organization, Organizational Unit, Domain, Locaity, and Country object classes.
Specify objectclass for attribute.
Select sort data in ascending parentDN order.
Check Create output file.
Click OK to start the export process.

DreamLAN.com Home � Products � Tech Notes

DreamLAN.com | A posse ad esse : Creating dream solutions

Select the LDIF file created by ldapSearch in the previous step.
Enter your LDAP bind information.
Select Add DN and values as the default changeType action.
Uncheck Simulation safety ON.
Optionally, enable the VERBOSE mode checkbox.
Click OK to start the import process.

Export group objects with only the objectClass attribute values.
Export user objects with the objectClass, sn, securityEquals, and groupMembership attribute values*.
Create the group objects.
Create the user objects.
Export group objects with only the equivalentToMe and member attribute values*.
Update the group objects.

dn: cn=example_user,o=siteA
changetype: modify
add: photo
photo:: /9j/4BBKRklGAQEBYGD/20MIBgYHBgUIBwcHCQkIDQoMFA0KDAsLDBkSEw8UHRofHh0aHBwgJC4n
 ICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/20MBCQkJDAsMGA0KDQoYMiEcITIyMjIyMjIyMjIy
 MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8ARCBQyAwEiAhEBAxEB/8Qf
 AQUBAQEBAQEBAgMEBQYHCAkNCgv/xLUQAgEDAwIEAwUFBAQBfQECAwQRBRIhMUEGE1FhByJxFDKB
 kaEII0KxwRVS0fAkM2JyggkNChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVm
 Z2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS
 09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EHwEDAQEBAQEBAQEBAQIDBAUGBwgJDQoL/8S1
 EQIBAgQEAwQHBQQEAQJ3AQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictENChYkNOEl
 8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImK
 kpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP0
 9fb3+Pn6/9oMAwECEQMRP/XfGviVfDHh6W7UqbqT93bKecue+PQDn9O9WvDGvQ+JNAttRiwGcbZU
 H8Eg+8P6j2Irxj4gatfeJPEbmG2uTY2uYrceW2G9X6dz+gFXfhlrF7oWvfYrm3uFsb4hGJjOEk/h
 b29D9favPWLft7fZ2/4J9fPh+KytVP+Xq975fy/dr66FnxL8U/HnhnXLbTbzwnp8bX0zR2ObkMZh
 uCg/K5C53L1x1q7qfxR8VabLpfh+Twzbf8JdqDEi0+0Booo8kKSysck4Y9RgDNUvjLa3E/j/wG8M
 EsiR3eXZEJC/vYuuOlRfEa0vvC/xe0Tx2bC5vNIjjEdw1um9ojh1OR2+VgRnGSCK9A+QNLT/i9qK
 2/iTTdb0eGy8RaNayXIhWQtFMFA465HVT1OQc1jj4z+Mbfw1aeKLvw0KWDaHPMYhNHc4YkEgjGSR
 yp5IxxXOy2N/4x17x143g027t9LfTJYrYzRFWmby1jDvwpJxnGQNCtn4bfB7RPEXgzTNU1ybVzK0
 khexMwSEbZGUfLt3DIHr3oA9y0vUYdW0iy1K33CC7gSeMNwdrqGGffBoqeCCK1t4reCNY4YkCIij
 AVQMPbFFSUUUUAFFFFABRRRQAUUUUAf/2Q==

 dn: cn=test_me,ou=delTree_test,o=SiteA
 (User)
  
   acl
     value count = 7
     >>> "2#subtree#cn=test_me,ou=delTree_test,o=SiteA#[All Attributes Rights]"
     >>> "6#entry#cn=test_me,ou=delTree_test,o=SiteA#loginScript"
     >>> "2#entry#[Public]#messageServer"
     >>> "2#entry#[Root]#groupMembership"
     >>> "6#entry#cn=test_me,ou=delTree_test,o=SiteA#printJobConfiguration"
     >>> "2#entry#[Root]#networkAddress"
     >>> "2#entry#[Public]#nDSPKIUserCertificateInfo"
  
   title
     value count = 3
     >>> "title-a"
     >>> dMOJZXN0LTE0NA==
         [16 bytes of B64-encoded data]
     >>> "my name is test_me"

dn: cn=example_user,o=siteA
changetype: modify
add: photo
photo:< file:///c:\photos\example_user_photo.jpg

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 LDAP
To 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 Tree
It 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.

First, export the container object names from the source tree using the ldapSearch gadget (see Figure
1):

Searching for High-Valued Attributes
Sometimes 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 Files
We 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 Tricks
Multiple-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:

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

To match on four attributes, the search filter would look like this:

(&(&(&(cn=test_user)(objectclass=user))(title=manager))(telephonenumber=555-1212))

As you can see, this gets rather cumbersome very quickly as the number of conditions increases.
Fortunately, there is a shortcut when using eDirectory.

If all the conditions within the filter is the same (i.e., all AND or all OR), you can use this syntax
instead:

(&(cn=test_user)(objectclass=user)(title=manager)(telephonenumber=555-1212)(...))

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*)".