EDIT: Can anybody actually answer the question? Thanks, I don't need no audit trail, I WILL know all the passwords and users can't change them and I will continue to do so.

This is not for hacking!

We recently migrated away from a old and rusty Linux/Samba domain to an active directory. We had a custom little interface to manage accounts there. It always stored the passwords of all users and all service accounts in cleartext in a secure location (Of course, many of you will certainly not think of this a being secure, but without real exploits nobody could read that) and disabled password changing on the samba domain controller. In addition, no user can ever select his own passwords, we create them using pwgen. We don't change them every 40 days or so, but only every 2 years to reward employees for really learning them and NOT writing them down.

We need the passwords to e.g. go into user accounts and modify settings that are too complicated for group policies or to help users.

These might certainly be controversial policies, but I want to continue them on AD. Now I save new accounts and their PWGEN-generated (pwgen creates nice sounding random words with nice amounts of vowels, consonants and numbers) manually into the old text-file that the old scripts used to maintain automatically.

How can I get this functionality back in AD?

I see that there is "reversible encryption" in AD accounts, probably for challenge response authentication systems that need the cleartext password stored on the server.

Is there a script that displays all these passwords? That would be great. (Again: I trust my DC not to be compromised.)

Or can I have a plugin into AD users&computers that gets a notification of every new password and stores it into a file?

On clients that is possible with GINA-dlls, they can get notified about passwords and get the cleartext.

  • 2
    I am also very interested in this, but for another reason. It would be useful for syncing accounts to an application that can use ldap for authentication.
    – Zoredache
    Commented May 15, 2009 at 23:48
  • 1
    If you generate the passwords and want to keep them why can't you store them elsewhere?
    – axk
    Commented May 16, 2009 at 12:08
  • 6
    You are trying to bend a system (AD) into doing something it wasn't designed to do (retrieve clear text passwords). What you are doing is bizarre and the reason no-one can help is because most people have a more sensible password strategy. Commented May 17, 2009 at 2:55
  • 3
    @Zoredache: AD is a LDAP-server - why can't your app auth against it? Commented May 17, 2009 at 6:07
  • 10
    If you're making a record of the passwords and not allowing user to change their own, why do you need to be able to read them from active directory?
    – Tubs
    Commented May 19, 2009 at 7:58

13 Answers 13


To answer the question, read this: http://blog.teusink.net/2009/08/passwords-stored-using-reversible.html

At the bottom of the article is described how to get the stored reversible password. Havent tried it, so don't know exactly how to do as described, but it should work.

Other than that, I concur with the rest of the people who cries wolf at the suggestion to use reversible encryption. It just isn't secure.


It sounds to me like you're giving user support by logging on with their accounts - knowing their passwords? As you said, that's a very bad idea for many reasons.

I know some oldschool users tend to like that, they just shrug their shoulders and ask you to fix it remotely and give you their password. But just say no. No one should know their password but themselves - basic principle.

Most things can be fixed from another user context, your own. Those who really can't, and need to be done with the user interactively logged in, require the user to do that and stay and watch as the staff fixes stuff through that user's account.

Remotely there is RDP Shadow, Remote Help and similar interactive solutions where the user is in control and no one needs to know his or her password to help with some desktop-related problem. With Group Policies there's basically no need for this behaviour anyway, since most things are easily configured by an administrator.

If you give other people access to other people's user accounts - you also lose the audit trail and accountability for actions made by users in the system - which could easily go outside the authorized administrator group.

  • 1
    +1 for mentioning accountability. Really important imo! Commented May 17, 2009 at 6:08
  • 2
    Audit trail and accountability? You're joking, right? It's soo easy to do something bad as someone else if you are admin. You can even manipulate the event log using a trick where someone injects code into LSASS. I can always inject bad scripts into users pcs, programms, login profiles, etc. that steal oder manipulate informationen. You people are just THINKING your systems would be secure from yourself, but that is not the case, a admin can always do everything he wants
    – Christian
    Commented Jun 17, 2010 at 8:40
  • 3
    I'm sorry but it's no joking matter. At one office the users wrote their passwords on the cupboard next to the coffee machine. The majority of the users are not admins, hence cannot poke around the systems that way. But teaching users (and lazy admins) to not share passwords and accounts is an important step towards better security. Granted, it is not "secure" in itself but it's one of many, many layers needed to get anywhere near a decent level requiring a bit more work to circumvent. Also, admin powers should be delegated per system, not all-encompassing BOFH style. Commented Jun 17, 2010 at 12:39

I would not be so certain that my DC is safe. If I was an attacker or a pen-tester, I'm not going after your DC first, anyway. I'm going after your workstations and servers. Basic attack vector:

  1. Discover weak username/password either domain or some service (say sa account on SQL Server) or vulnerability I can exploit that lets me get admin rights (patch your systems, folks).
  2. Find system where that account has admin rights.
  3. Dump LSA Secrets to find username/password of all service accounts.
  4. Use CacheDump to dump cached username/passwords.
  5. See if any of those have admin rights anywhere.
  6. Repeat 1-5 until I get a domain admin account.
  7. Use domain admin account to access domain controller.
  8. Dump SAM of domain controller.
  9. Use rainbow tables to crack more passwords, or brute force if necessary off-line.

Unless you're all Vista / Windows Server 2008 / Windows 7, this is the basic attack pattern used by most pentesters. The reason those 3 OSes break the pattern is because the DLL injection attack against LSA Secrets hasn't been made to work against those OSes.

With all that said, you should not use reversible encryption and you should disable LM hashes. You want NTLM hashes. And you don't want to store those passwords in plaintext.

  • If I do this attack and gain access to the domain controller, what worth do these user passwords still have? I could use the admin access on the domain controller to inject keyloggers into any workstation via group policies. I can directly modify any rights and any files. Why would I care about the user passwords becoming cleartext? It's not that the users can choose their passwords and then unwisely choose to use their private passwords on our company system. In that case I accept that I would be a bit responsible to protect these passwords. But we randomly choose the passwords anyway.
    – Christian
    Commented Jan 21, 2015 at 17:10

What you're doing is a really, really bad idea. If you don't want users to have to manage passwords, you can invest in a challenge/response token system for AD that will cost you minimal money.


To be honest, I don't think your reasoning for wanting to do this is valid. As an admin I get a major dose of the heebeejeebees from the thought of knowing a user's password. It's their personal territory, and you're asking them to place a HUGE level of trust in you. Even aside from that, if there's ever a confidential data leak, you will be instantly under suspicion as you would know the user's passwords. Lack of a verifiable audit trail is a colossal security red flag. Rule 1 is "protect yourself", and if this means having to accept some inconvenience, then so be it.

I think there are alternative solutions that will accomplish what you want without having to go to such an extreme as knowing passwords. Have you looked at group policy preferences? What are your scripting skills like? Use of brute force methods is normally a clear indication that the standard approach is not being used optimally, so I think you would be far better off backtracking and rethinking what you're doing.


Accountability, Logging and Tracking.

We have been struggling with management over this for a few years. The CEO and President refused to change their password for years, and every IT guy that had come and gone in 7+ years knew their passwords. Even if you "Trust" everyone, it is very unsafe for multiple people who are no longer employees to have access to powerful accounts. Let alone that all of them know that others know the passwords, and it would be safe to use them.

We preach to users over and over to never share their passwords, even with us, ever. This is the start to prevent "Social Hacking" How many of your users would give their password out to someone calling and saying they are one of the new IT guys?

If we absolutely need to be in a users account to do something, we have them login and ride shotgun, or we change their password. As soon as we change their password, we are then responsible for their account and they are no longer accountable, until we give them a new password, with the account marked that the user must change password at next login. This preserves logging and tracking. With everything bad, illegal, and unethical that users can do on the internet. If they can blame many others who know their passwords, it could generate lots of problems.

Now we are working on eliminating all shared account logins such as for shared computers. If we must have one, that account has very limited rights, and no internet access.

There's a reason why passwords are so important. They are not just to protect your data, they are there to protect you and your users, etc. It's not hard to find or brainstorm examples. Play the conversations in your head. "They all knew my password, and one of them got in my computer and read the email from my mistress and told my wife" There are many, many possible privacy considerations apart from security.


p.s. trying very hard to not be argumentative. Although I did not answer the question, but did editorialize against doing what is suggested. I would also recommend not saying things like this, quote from question - "EDIT: Can anybody actually answer the question? Thanks, I don't need no audit trail, I WILL know all the passwords and users can't change them and I will continue to do so. This is not for hacking!"

  1. This would get you removed from your job as System Admin at many, many companies.
  2. An attitude such as this could also impact any future job opportunities for you. I would immediately eliminate anyone applying for a Sys Admin job at our company if I googled them and found that they had posed this question.
  3. I'm trying very hard to imagine what kind of scenario would need and support this. A 3-4 person family only office, maybe. I could see this attitude being prevalent in a religious scenario, but even then no one is perfect and can make mistakes.
  4. If this is overly argumentative or pejorative, please feel free to edit or remove the p.s.
  • Your comment does not help to answer the question. Please consider deleting it
    – Christian
    Commented Aug 28, 2010 at 6:21

I think the auditing, accountability, and general security concerns have been adequately addressed, so I'll try a different answer :)

There is a Password Change Notification Service that can be installed on all domain controllers which will forward all password changes securely to a receiving service.

This was designed for Identity Integration Server (now Identity Lifecycle Manager) as a target, but it should be possible to write your own target, or even use MIIS/MILM to receive the password and forward it via another connector to your own system.


You would have to get the hashes (either LM or NTLM) and do a dictionary attack on them. Anyone with a moderately complex password would be nearly impossible to discover. Don't enable "reversible encryption" - you need to change the way you manage passwords.

  • I don't need to change the way I manage passwords. Why shouldn't I enable revers encryption?? The question is how to read out the passwords
    – Christian
    Commented May 16, 2009 at 16:33
  • 3
    Why shouldn't you? The risk is detailed here: technet.microsoft.com/en-us/library/dd349793(WS.10).aspx Ultimately it's a business decision. However, just about every auditor that comes through is going to flag this if your organization ever undergoes an audit. Commented May 16, 2009 at 20:14

Unlock Administrator might solve part of your problem without requiring knowing the password.

  • My problem is not locked workstations, but knowing the password. Thank you
    – Christian
    Commented May 16, 2009 at 16:31

There are a variety of ways of doing this which I've seen used by people who've penetrated our servers. The most popular method is to dump the password hashes to a file using something like pwdump4, and then running the resulting hashes through a Rainbow Table. There are some password length limits which make this approach a lot harder, which is why our administrative passwords are all 16 characters or longer.

Once you've invested in a good set of rainbow tables (can be had for good money many places on the internet, and if this really is line-of-business for you the cost shouldn't be an issue) the dump-and-decrypt process can be done in less than 30 minutes for most users.

We did this once to get a feel for how easily guessed our user's passwords were. Something like 30% of the passwords were cracked within 5 minutes after the start of a simple dictionary attack, and close to 80% were cracked via self-generated Rainbow Table in under a day. This was.... 3 years ago, so things have gotten faster. The results were presented to upper management, who quickly agreed to beef up (okay, actually create) password policies.


As others have covered, your policy and practices are unorthodox at best. Previously mentioned Unlock Administrator seems like a decent compromise (no pun intended). Your stated purpose for knowing your user passwords it to provide support within their Windows user profile. Fine. When your users need support and need to be somewhere else, have them lock their workstation. Then with Unlock Administrator you can unlock the station and remain in their user profile.

You lose the ability to walk up to any workstation, but you no longer need to know their password. That seems like a decent compromise between security and ease of support.


Microsoft has their ILM product which can replicate passwords, perhaps to a foreign LDAP store.


Get L0phtcrack and run it against the DC. May take HOURS but it should be able to get most passwords.

I actually stumbled upon this because I was looking for the same thing but my motives for knowing user passwords are quite different.

I am migrating a former network admins solution of using IIS for customer FTP hosting, recently we found that our IIS ftp had been brute forced and was hosting spyware. User passwords were not documented just reset if someone forgot, So I am moving to another solution (FileZilla) which doesnt use AD. I need to recreate all these AD accounts with the same passwords (compromised accounts excluded) to make the migration transparent to end users. Since there is no IIS migration utility for FileZilla my only hope is to crack the users passwords.

I am open to any suggestions on how to accomplish this without cracking the users passwords.

Not the answer you're looking for? Browse other questions tagged .