For administrative purposes, I sometimes need to log in as another user to diagnose a problem with their account. I'd like to be able to do this without having to change their password so I don't have to keep bothering them. Under Unix, I can just save the encrypted password from the passwd file, change the password, then edit the old encrypted password back into the passwd file. Is there a way of doing something similar in AD?


Since MarkM already explained why we shouldn't replace and restore user passwords, I'll try to address how the system prevents us from making those changes.

In Unix, the password hashes were originally stored in /etc/passwd and could be read by anyone. Realizing that this allowed any user to potentially steal passwords, newer unix systems store the password hashes in /etc/shadow which is only readable by root.

Windows followed a similar path. In a domain environment, the password hashes of domain users are stored in the SAM registry hive on each domain controller. You're probably already familiar with hives like HKLM and HKCU.

Starting with Windows 2000, the SAM hive is encrypted with a 128-bit password encryption key, which is itself encrypted using the SYSKEY. It should be apparent that since the operating system must read the contents of the hive in order to authenticate users at logon, the encryption key must be saved on the computer somewhere. For more in-depth coverage of the obfuscation techniques that are used, check out SysKey and the SAM.

Windows tries very hard to prevent administrative users from being able to read/write the hashes directly, and normally only lsass.exe running as the SYSTEM user is able to read the hashes.

However, I'm sure you've encountered tools that bypass these protections. For example, fgdump is capable of exporting password hashes from a live system by injecting code into lsass.exe, although that can potentially crash the entire system. And there are a wide variety of bootable tools that can overwrite password hashes when Windows isn't running.

Although it is theoretically possible to replace user passwords, you'll first need to circumvent a wide variety of protections built into the Windows operating system. Any of these methods have the potential to destabilize your system, and should never be used in a production environment.

  • 3
    Excellent answer that deserves many more upvotes than mine, – MDMarra Nov 17 '11 at 17:46

No, you can't.

Food for thought: If you work for a company of moderate size, there's likely a policy in place disallowing people in IT (or other areas) from impersonating other users without their explicit consent. If your company doesn't have a policy like this in place, you should strongly consider it.

  • 2
    +1 for explaining the most likely reason this isn't possible – Nic Nov 14 '11 at 20:57
  • Do you have any citations supporting the idea that you cannot? – Zoredache Nov 14 '11 at 21:28
  • The kicker here is that in the scenario laid out by Robert Perlberg's question, the impersonation can occur without being explicitly logged. Windows is designed to leave an audit trail when Administrators diddle with user accounts. – quux Nov 18 '11 at 4:55

I've never seen this done with just the password, although you might be able to backup / restore the AD object.

Another way is to have them reset the password with the AD Users and Computers admin tool. It will let you bypass the security restrictions of reusing passwords.


This is not possible. The passwords are stored using irreversible encryption. You can however change that behavior by checking the box next to "Store password using reversible encryption" on the Account tab in the Properties dialog of the desired user object. Any future password changes would be stored using reversible encryption.

As for exporting that information from the AD database, I don't think that is possible.

  • 2
    He didn't ask if he could reverse it. He simply wants to store the current hash to another location, then be able to restore it. – Zoredache Nov 14 '11 at 21:27

if your question is legit, you should just ask the user for their password, then get them to reset it once you're finished "diagnosing". that way you are being transparent, and the user is acutely aware of what is going on in the background.


The closet you could come to this is resetting the password through ADUC for your use, and re-resetting it so the user can put back in his own password. However, I'm not sure password repeat restrictions would come into play here.

As an alternative, why not use a tool like AMMYY to interact with the user's session? Or if it's a problem with the computer itself, have them log out and RDP in as an administrator.

  • Password age and repetition requirements do not prevent someone with appropriate rights from resetting a password to a previous one. It only prevents the end user from changing it to one in the history. – MDMarra Nov 17 '11 at 17:46
  • Yes. If an administrator resets the users password to a known default and has the user change it on their next login, that's where the restrictions might come into play. – Bigbio2002 Nov 17 '11 at 18:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.