I'm having lots of fun with the edir-to-edir password synchronization,
but tight schedule forces my hand to stop playing and get some more
experienced advice.
Before I begin, I have to apologize for the wall of text - The whole
situation is a chain reaction of weird problems and awkward solutions so
please bear with me while I try to make sense out of things.

I have two connected drivers - META and SSPR. Normally, since the two
drivers pass passwords around in both directions i'd use the bidirection
edir driver, but there's a 'critical unresolved bug'
(http://tinyurl.com/ma5cnmm) with it so I had to switch to edir-to-edir.
Off to a great start!

Problems start with default password synchronization policies.
When a password modify is issued in the subscriber channel of one
driver, it tags the event with event-id="pwd-subscribe" and adds
operation-data with an association so when the result status returns
it'll know which user it applies to. Unfortunately, when the event
crosses to the other driver's publisher channel, the event-id gets set
to "pwd-publish", so the operation data never gets reattached.

Here's the original event in the SSPR's publisher channel:

My solution is to give driver specific names to the event-ids subscriber
operations, for example "meta-pwd-subscribe" and "sspr-pwd-subscribe",
and translate the "pwd-publish" event-id in each driver's output
transformation policies back to the other driver's subscriber specific
event-id name. That brings me to the next problem.

Novell's default policies also set the password expiration time in the
publisher channel, thus creating another modify event and eventually
another status, all with the same event-id. That means that when the
status events return to the other driver, it'll attach the operation
data to them both, making it impossible to distinguish which event was
the actual password modification.

Here's how the events are submitted and the resulting status messages:

My awkward solution to this was to translate only the event with
operation-data/password-publish-status/association, so when this is how
the subscribing driver receives the statuses:

It looks and feels ugly and there has to be a better way, but the real
problem is when password synchronization fails. When that happens
(normally because it doesn't comply with the password policy) I get an
extra status message I can't explain:

I began working on yet another awkward solution when I noticed 2

- The warning status payload is not well formed XML, so what good does
restoring the operation data to it do? I can't iterate it, use XPath
on it, access it with the xml tokens or anything and I really don't
want to start parsing it manually if I can help it.
- This should be an easy task, i'm definitely doing something wrong.

I've included the full traces for both drivers for both password
synchronization results:
META success - Valid password created on subscriber channel.
SSPR success - Valid password received on publisher channel.
META fail - Invalid password created on subscriber channel.
SSPR fail - Invalid password received on publisher channel.

Any help would be greatly appreciated!

|Filename: meta2engsspr_pwd_success.log |
|Download: https://forums.netiq.com/attachment....tachmentid=112 |

YLivay's Profile: https://forums.netiq.com/member.php?userid=5678
View this thread: https://forums.netiq.com/showthread.php?t=49585