Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

We often have to tweak, test, or repair some software when the users are not there.
For example, today one of us set up a new mail account on a user's computer, but the user is on holiday. This then requires that we impersonate the user.

Working on a computer when users are not here is very nice for us and them. But this often requires that we ask them their Windows account password, or we change it before we use it, and the user then have to change it back when he comes back but this require him to understand what has happened.

Is there a (fast) way to save then restore Active Directory passwords?
1 - we save the password
2 - we change the password to TECHPASS123
3 - we work on the computer, and we test if everything is okay with the user's account
4 - we restore the original password

share|improve this question
No there isn't. (Technically there is, which is explained in this article: – joeqwerty May 7 '12 at 17:29
Beware he is not asking to retrieve the original password, he only wants to save/restore it. Suppose the AD stores passwords salted+hashed. It would be enough to retrieve this hash, temporary use another password and then restore the hash. I do not know however if this is possible. – Jeff May 7 '12 at 17:57
could runas /savedcred solve some of the original problems? – rackandboneman May 7 '12 at 19:47
runas /savecred don't solve the problem because we often need the real user's environment. For example we configure printing properties for a complex software. So we have to configure the printer under this account, and launch the software which needs his mapped drives, which use Microsoft Office, etc etc. – Gregory MOUSSAT May 7 '12 at 22:37
for your comment above. GPO could Map Drives and setup printers. You can replicate pretty much any set up process you would do with GPO. You just need to learn it. – t1nt1n May 8 '12 at 7:15

2 Answers 2

up vote 2 down vote accepted

For a local computer, you can simply do it by copying the c:\windows\system32\config\sam file to a temporary one. Once you finished, just copy back.
But you can't do that while Windows is running. So you have to use a Linux CD or to boot from a Windows cd and open a command line.

For the first part, you can do it online with runas system account, or with shadow copy. So this is an easy step.
The last part must be done offline. If anyone find how to do it online, I'll be happy to know how.

Note you can have a problem if you check for password reuse.

The problem is: this don't work with active directory because you don't want to reboot your server in the middle of the day. And if you have several domain controlers, this don't work at all.

Some softwares can do it on the fly. I used one I forgot the name (it has "migration" in its name) and it is overkill for this use. I don't know if it exists anymore and if it works for 7 or 2008. Maybe a lighter software exists, but I don't know one.

share|improve this answer

This is a bad idea for a few reasons:

It circumvents the audit trail
When you change a user's password to impersonate them and then change it back. There is a trail that you did it. That gives you deniability and protects you if anything happens with that user's account. It would be really bad policy to allow this trail to be circumvented.

Imagine that an employee is fired for having child pornography. If you have a policy of swapping this hash in and out at will, there is little-to-no way to prove that the employee was the one that did it rather than you. If you were to reset the password, there is a clear log entry about it which will isolate the times that you were logged in as that user.

It's extremely difficult to do
While theoretically possible to do, you have to modify a whole bunch of stuff that would leave your Active Directory in an unsupported state. This is obviously not a good thing to do. Or you can store the passwords in Reversible Encryption, but doing so is a really bad idea.

It reduces communication between you and the users
Part of being good at supporting users is communicating with them. By having to set, and then reset their password when impersonation is absolutely required, you are forced to get in touch with that user and explain what happened and why. It gives more of a sense of trust than just logging in one morning and seeing that things are different.

share|improve this answer
+1 audit trail is a must. – t1nt1n May 7 '12 at 18:58
@t1nt1n, so they make the magical password switcher tool write lots of logs. – Zoredache May 7 '12 at 19:09
@Zoredache Will that magical password switcher's hand-written logger hold up in a wrongful termination case? :) – MDMarra May 7 '12 at 19:10
hand-written? Why would it need to be hand-written? Why wouldn't they send the log to the standard windows security logs? – Zoredache May 7 '12 at 19:30
I should have said "hand coded". Sorry for the confusion. – MDMarra May 7 '12 at 19:31

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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