Hi Joel,

You can build a "similar" policy, but your conditions are

1. password match ".+"

and

2. if destination DN not in container "path\to\ou"

veto()

According to your explanation, you want to sync the password only when the user is in specific OU and skip (veto) all other password sync events.

Later, you can add more validation conditions, if it will be required.

Worth mentioning that passwords in IDM come in a couple of forms, at different points in teh flow.

If you want to do it earlier, Alex's idea is still fine, but the attribute you are looking for is op-attribute nspmDistributionPassword.  In the Sub-CTP that gets converted according to the GCV's to possible a <modify-password> event.  Before that it was a <modify> with an <modify-attr attr-name="nspmDistributionPassword">.  Also if you are setting the NDS password (not sure the Bi Dir can do this) then it sends the attributes Private Key and Public Key. 

So take care to consider where you are in the process, and which attribute/event is of interest.

that's good to know i think at first I'm going to go the basic route like Alex mentioned. but I'll watch out for the issues with setting the password that way.

Just to be clear, nothing I said contradicts Alex, rather I am suggesting that 'password' may be the wromg attribute, and modify the wrong event, depending on where in the process you put your policy.

Three cases, iirc:

• modify-password operation: veto if out of scope
• modify operation with nspmDistributionPassword (or whatever it's mapped to in app namespace, when looking at it in an input transform) attribute: strip attribute if out of scope but leave remaining attributes for further processing
• add operation with password node: strip password node but leave remainder of add for further processing.

Depends on where you look in the processing flow what you get to see, though. Also different apps/shims may have different ways to report a password change event on the publisher.

I'm currently planning on implementing it in a modify-password operation and then veto if out of scope. so I think that should work well.

Ahh, that makes sense. I had planned on piggybacking on the existing modify-password operation so I think my implementation will be ok.