LDAP: error code 66 - Not Allowed On Non-leaf

[ilyas]

Hi,
Still with sync between AD and IDS.
I tried to rename an OU(Organizational Unit) in AD, and I got this error:
LDAP: error code 66 - Not Allowed On Non-leaf.
I understood that I'm not allowed to make changes on entries that are not
leaves.
How can I do to fix that problem?
Regards

[Eddie Hartman]

Hi Ilyas,

I think you will need to do this:

1. Create the new ou
2. Migrate the old sub-nodes to the new one
3. Delete the old ou

Note that you can call ALs recursively,
so if you have a migration AL, then it could
check for children for any node and then
call itself with this node as the base for
further migration.

-Eddie

[ilyas]

Hi,
Good idea, Eddie. But how to test if a node is a leaf or not?
Regards,

"Eddie Hartman" <eddie....@no.ibm.com> a écrit dans le message de news:
eh2cqt$1ok6k$1...@news.boulder.ibm.com...

[Christian Chateauvieux]

Ilyas,

The attached dumpdir.cfg example a very old (Metamerge days) and
incredibly simple example which deals with recursive LDAP adds from
<initial_base_dn> downards: the loop is as follows:

for all entries returned in current level
add entry in target system
if (success)
start same AssemblyLine with search base level set to current’s
entry DN

This AL descends an LDAP tree and copies it over some other place.

Note the starting of AssemblyLines can be parallelized to make the
processing faster. It is of course important to control the max number
of threads; and because the Admin tool sets the -w parameter you will
have to start IBM Directory Integrator from the command line:

ibmdisrv -rDumpDir -cDumpDirectory.cfg

The code customization is simple: the AddOnly Connector (on_success
hook) starts recursively the same AssemblyLine with an initial entry; in
the AssemblyLine Prolog (Before Connectors Initialized) this entry is used.

If you want to adapt this example for recusively deleting a subtree, you
will need to change the addOnly connector to delete mode, and change the
recursive loop to stack the parent DNs for later deletions. I have also
attached the delete subtree example.

Here is the concept:
The AL is supposed to be triggered from another AL. It receives a IWE
containing a DN to be used as SearchBase. This is done within the AL
Prolog-BeforeInit.
The first conector is in iterator mode searching for any objectclass
starting from the SearchBase (taken from IWE). The search scope is
"One-Level" only!
For each search result (After Get Next Hook) it reads the DN of the
current object (conn). Then the AL calls itself passing this current DN
as new Searchbase.
This will cause the recursion. The calling AL will wait until the
"sub-"AL has finished.
The recursion stopps if there is no Child LDAP object. At this point we
have found the end of a subtree and the AL will stop and...
... control will be passed back to the calling AL After Get Next Hook.
Since we know that we only should reach this point if the current object
does not have a child object, we can delete the current object.
This is done by calling a passive connector in delete mode

I am sure that it would also would be possible to simplify this by
making use of TDI 6.1 loops using connectors. Also, note that these
examples are network-hungry. They do not make connector re-use, so a new
LDAP connection is opened at each AL execution (i.e at each DIT level).
This is definitely something you will need to modify (using ITDI 6.1
connector pools for instance) to improve performance. Finally, note that
error handling and logging should also be improved!

Let us know if you have any difficulty with this.

Hope this helps,

Christian