Hi all,

I encountered an issue with an irritate AD Sub channel behavior regarding group membership management, and I hope someone around here could advise.
Our client environment include single IDM engine connected to four ADs in a single forest (all domains are trusted).
Since one IDM user can be associated to one or more AD user (yet only one at each domain), we use four AD drivers.

We have several cases where users in domain B (or C..) need to be assigned/removed from group in domain A . In order to escape schema mapping issue, we implemented a code that convert the user's eDirectory dn to AD dn, using custom ADContext multi valued field we maintain. The code works quite well, but while working on it we noticed strange AD Subscriber behavior.
As far as we aware, ldap group membership operations can accept two formats. Either the shim provided with a plain text of the user specific AD dn format, or with the user's association value (the AD object GUID), where the latter include an 'association-ref' xml attribute, indicating the shim should use the GUID value for the ldap operations.
When sending AD shim a group member modify event, where the member value is the user's association value (not AD dn) the shim manage to perform ldap operations only with association value of the current driver. The ldap operations involving association values, a valid AD object GUID, from other AD drivers are simply ignored.

One can easily dismiss this selective approach stating the driver can only process the assocition values of its own, yet we inquired the issue a bit farther.
Events coming up the publisher channel include an 'association-ref' xml attributes for users from a different domain, so the lack of GUID support is unique for the subscriber channel alone.

Does anyone else had encountered this issue? Or faced a cases where the group and its member were not in the same domain and can offer another method for that?