Good ol' fashioned pwdLastSet issue.


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....


  • Open a bug and an SR about it and make MF fix it in the shim? Can't be true we have to work around stuff like this in policy over and over again.
  • Just a thought and I haven't tested this but would you be able to do the change to pwdLastSet as a separate operation after the initial add of the user. Basically when the transaction comes through you could add a rule that says to set the pwdLastSet value to 0 after current operation. Not sure if that would help until MF can fix the root cause.

  • That was the first approach before all this nonsense began. It makes logical sense, send it as a separate command after the first command. But it doesn't work, because the "platform call" that is made based on the <password> element being sent to the shim is asynchronous from the LDAP updates (and it has to happen AFTER the LDAP update since there would be no user to set the password for until that completes).

    So the <add> makes the LDAP create happen, the <password> initiates a platform call on it's own asynchronous thread, and then a <modify> comes in to set pwdLastSet to 0. Then in most cases the platform call executes the password set next, and so AD dutifully sets pwdLastSet to the time that we just set the password. Game over.

    Which is why I moved this into the input transform, and now the command transform, but it's still not behaving as we need. I have all kinds of speculation now as to what might be happening; since we didn't see this behavior in a 1 server dev environment but we are seeing it in a 10 DC AD domain, maybe it's because the DC is not the PDC emulator, so it's replicating the password change up to the PDC emulator and it's replicating it back, so we are trying to change it to 0 before AD is done replicating, so our change is getting overwritten with the change from other DCs.  Considering AD's totally inefficient algorithm for what they allege is multi-master replication (which is send everything to the master first and let it replicate from there) I could imagine such a timing issue being a problem (but way too hard to prove).

    Don't have time to be MF's QA or open an SR, working on more workarounds.

  • If only IDM wasn't so darn fast an efficient, then AD being slow wouldn't matter. If you are running the User App maybe you could create a workflow that would modify the attribute. Then where you are having IDM update the pwdLastSet attribute you could just have the driver fire the workflow. You could even make the workflow have an approval and set a timeout on the approval to add a delay to when the workflow would actually update the attribute to allow for the DCs to get everything synced. Super convoluted way to hack something together to work around an issue.


  • Verified Answer

    As it turned out, the client told me that about 15 minutes after I reviewed the logs, the attribute got set (according to the screen shot they sent, 50 minutes after IDM sent the original command). So what I had done had actually worked correctly, but AD didn't reflect it for nearly an hour. They have about 10 DCs and the one I am connecting to is not the PDC emulator so it's possible that they had a replication problem that caused this. But you would think the DC I was updating would have reflected it immediately.

  • Thanks for confirming it did work.