I’m trying to set pwdLastSet to true in the provisioning policy for Active Directory. After adding the value in the provisioning policy, I submitted a create request for a user. Then I ran aggregation and Perform Identity Request Maintenance. In the Provisioning Engine, all attributes show as Finished, except pwdLastSet, which remains in ‘Committed’ status. The request does not complete and shows the Execution Status: Verifying and Completion Status: Pending.
Does anyone know why this attribute isn’t moving to Finished? Is there an additional step or configuration required for verification. Could the verification be skipped for this attribute? Appreciate any input on this matter. Thank you.
pwdLastSet attribute contains the date time stamp for when the last time password was set successfully. you can set it to today’s date since you are creating a password on the current date.
Hi @j_place When set to zero, the identity cube displays a date value for the attribute, and the request fails to complete successfully. When set to true, the cube shows a zero value for the attribute, but the request still does not complete successfully.
Hi @bobbysrik based on my understanding and knowledge pwdLastSet in AD is a timestamp with special values (0 = force change at next logon, -1 = let AD set “now”)… In IIQ AD connector you should treat it as a Boolean flag in your provisioning policy “pwdLastSet as static value to be true” to force “change password at next logon” and let the connector translate that to 0 for AD, which what exactly you did here and absolutely correct…
However (and again based on my understanding only ) the reason that the attribute sits in Committed and the request stays in Verifying/Pending is that AD immediately replaces 0 with a real timestamp, so when IIQ re-aggregates, the live value no longer matches the requested value and verification never goes fully green.
In fact, as a functionality, if AD shows “User must change password at next logon” and the user is prompted to change the password on first login, the provisioning is correct… most implementations just accept pwdLastSet as a write-only flag and ignoring these verifications noise.
I hope that helps, or maybe someone has another PoV, have a nice and great one!
and absolutely correct…
) the reason that the attribute sits in Committed and the request stays in Verifying/Pending is that AD immediately replaces 0 with a real timestamp, so when IIQ re-aggregates, the live value no longer matches the requested value and verification never goes fully green.