Reset user password and force change at next logon


  • Using the delegate control wizard, I've delegated "Reset user password and force change at next logon" to a group called Support-Staff for users under the people container.

    They are able to reset passwords on all users, but the box to force the password to be changed at next logon is grayed out.

    I have checked the effective permissions of the user whose password is being reset and can confirm that "Reset Password", "Read pwdLastSet" and "Write pwdLastSet" ACEs are all ticked for group Support-Staff (and also for the user trying to reset the password that is a member of Support-Staff).

    The user whose password is being reset is not a member of AdminSDHolder. If the user resetting the password tries to reset his own password through the same means, then the box for forcing the user to reset password on next logon is no longer grayed out.

    The domain is Windows 2008 R2 and is members of Support-Staff use a Windows XP machine with Administration Tool Pack 2003 SP1 installed.




    Friday, August 06, 2010 9:58 AM


All replies

  • Have you checked if members of Support-Staff are able to set the value of pwdLastSet attribute via a script ( or PowerShell)?

    If so, are you seeing the same symptoms when using RSAT from a Vista/Windows 7 computer?


    • Marked as answer by John Ubuntu Thursday, August 12, 2010 9:31 AM
    Friday, August 06, 2010 11:06 AM
  • Hello,

    check the following article:

    Best regards Meinolf Weber Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.
    Friday, August 06, 2010 11:24 AM
  • Hi John,


    Please check if the user whose password is being reset is a member of domain admins. For test purpose, you can create a new normal user in the people container. Then try to reset its password on Windows XP. Is the "User must change password at next logon" active for the new user?




    Friday, August 06, 2010 12:58 PM
  • @ Meinolf Weber, giving them the ACE to Write Account Restrictions does enable them to tick "Force change at next logon". However, as mentioned in that document, it also gives them more rights than those needed.

    As for changing the filter in Dssec.dat, in Windows 2008 R2 pwdLastSet is already shown by default and they have both Read and Write to pwdLastSet field. I do not want to give them Write Account Restrictions.


    Tuesday, August 10, 2010 5:16 PM
  • @ Bruce-Liu the password is being reset on a normal member of staff. Domain Admin accounts do not exist under the OU I delegated this right to.

    The same issue happens on new users.

    Tuesday, August 10, 2010 5:24 PM
  • @ Marcin Policht, I will test that tomorrow. However, because giving them Write Account Restrictions did fix the problem, I doubt it has to do with Windows XP and Administration Tool Pack 2003 SP1, worth a shot though.
    Tuesday, August 10, 2010 5:26 PM
  • I have tried changing the pwdLastSet attribute through a script as Marcin Policht suggested and I am able to change that attribute. The GUI also shows the updated information after the attribute is changed through the scrip (as in, in user properties is shows the user does have to change password on next logon)

    I haven't had a chance to test it on a Windows 7 machine computer using RSAT as of yet though, finding a Windows 7 computer is not easy.

    Will let you know once I've done that.

    In the meantime, any other suggestions?

    Wednesday, August 11, 2010 12:47 PM
  • Do you have any Windows Server 2008 R2 member servers? If so, use those to check whether the behavior you are seeing is specific to non-RSAT-based admin tools (based on the outcome of your tests, this does NOT appear to be the issue caused by lack of sufficient privileges - but rather an interface anomaly).

    If not, create a test account mirroring the group membership of the delegated staff, grant that account permissions to log on locally on the DC, and test it there instead.


    Wednesday, August 11, 2010 12:56 PM
  • I've just had a chance to test this on a Windows 7 workstation with RSAT installed and I can confirm that, using the same account, I am able to tick "user must reset password on next logon".

    So it appears that the problem it indeed an interface anomaly.

    Next question would be, I suppose, short of upgrading the workstations of all members of staff that require rights to reset passwords to Windows Vista/7 (or having them RDP to a Windows 7 box / member server running Windows 2008 just for the sake of resetting a password), what is the next best solution?


    John Ubuntu

    Wednesday, August 11, 2010 2:08 PM
  • Use the script - or create a custom secure Web page that would serve as a proxy for account administration...


    Wednesday, August 11, 2010 2:24 PM