Can I get all active directory passwords in clear text using reversible encryption? [closed]

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.

Solution 1:

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.

Solution 2:

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.

Solution 3:

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.

Solution 4:

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.

Solution 5:

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.