My client wants to make sure when a user is created we set a randomly generated password in AD and then force a password change on first login.
So the way it's done is to set pwdLastSet in AD to 0. You cannot do that on the subscriber however, and I now know why. When you set the pwdLastSet to 0 the change is made via LDAP, but the password change is done via a "platform call" (MFC) and so it's on a separate asynchronous thread and happens later, causing the pwdLastSet to be the time the password gets set by the platform call.
Tried putting this in the publisher (technically the input xform) triggering on the add-association, which worked the first time, and never again. This was because we were getting the modify-password event from the filter after that, causing the same nonsense. So I put it on the modify-password and put some clever code to see if the password we are receiving from the filter is the initial password (otherwise every modify-password would require a password change on each login, lather, rinse, repeat).
This worked a few times and then I hit another timing issue where the add-association had not processed before the modify-password, so the query for the initial password failed. So I moved this out to the end of the publisher command transform, made it trigger on the modify of nspmDistributionPassword with the same check, and the trace is perfect, no errors, all success back. Just one problem: AD is still not reflecting the user must change password at next login.
This actually seems like some sort of a weird timing problem with AD (we had another issue where two consecutive identical commands on the subscriber would fail but sending just one would work) but wanted to reach out to the communal mind here to see if anyone has an absolute rock solid foolproof way to do this that I am overlooking. I've been doing this way too long for this to be so vexing....