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

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!

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

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 4

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 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.

View more solutions

Comments

[Zoredache]

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.

[Cecile]

If you generate the passwords and want to keep them why can't you store them elsewhere?

[Chris]

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.

[Matt Bettiol]

@Zoredache: AD is a LDAP-server - why can't your app auth against it?

[Tubs]

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?

[Christian]

@axk: Follow the accepted answer until sourceforge.net/projects/passwdhk That project and it's parent project: acctsync.sourceforge.net That is surely what you want. Now we only need to erase all the crap answers in this post

[raja]

This question does not pertain to reasonably accepted admin practices.

[Christian]

My problem is not locked workstations, but knowing the password. Thank you

[Christian]

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

[K. Brian Kelley]

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.

[Matt Bettiol]

+1 for mentioning accountability. Really important imo!

[Oskar Duveborn]

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.

[Christian]

Your comment does not help to answer the question. Please consider deleting it

[Christian]

Thank you!!! This was a great link! Also follow this blog to blog.teusink.net/2009/08/windows-password-filters.html and then sourceforge.net/projects/passwdhk ! That's greate for syncing AND for my problem!

[Christian]

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.