According to the IDM Documentation the way to prevent loopback problems
with the BiDirectional eDir driver is to use ensure that the driver is
using its own user id to make all of it's modifications (Section 3.1 in
the Bidirectional eDirectory Driver Implementation Guide). I've done
that with my IDM test environment but I still seem to be running into
some odd loopback problems.

My Setup:

SGITST Tree - The primary user source. This is the only place where
user creates/deletes can be pushed into the vault.
AUTHTST Tree - Another eDir tree. Only users with specific attributes
are synced from the vault into this tree.
IDVault - Self explanatory

Now, I can create a user in the SGITST tree and it's properly synced
into the vault and, attribute dependent, into the AUTHTST tree. I can
then modify attributes etc. This is working fine and dandy and there are
no loopback problems here.

However, if I delete a user in the SGITST tree in the trace I see the
delete sync to the id vault then the delete sync from the vault to the
AUTHTST tree. Right after that I see an event from the AUTHTST tree to
delete the object the same id. From what I understand, this is the
change-log shim seeing the delete event and attempting to send it back
into the vault. This makes no sense to me as this shouldn't be

Here is a trace of the events going through with a lv2 trace on the
driver for AUTHTST

Lines 1-7: Successful delete from SGITST to the vault
Lines 8-74: Successful delete from vault to AUTHTST
Lines 75-114: The attempted delete from AUTHTST to the vault. This is
blocked by an event policy on the publisher channel for the AUTHTST

Am I wrong in thinking that this loopback shouldn't be happening?

pkoochin's Profile:
View this thread: