Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We're considering storing authentication data (username + password) in ActiveDirectory for a new product platform at my company. We're not 100% sure AD is the right long-term solution for us, but there is a team ready and willing to support it now so there is appeal to using it.

However, I'm concerned that if we decide to migrate away from it (even to something simple, like MySQL + a REST interface), we won't be able to retain the passwords for existing users. I do not want to have to ask our customers to change their password down the road simply because our backend changed.

So my question is this: is the hashing algorithm (including salt!) that AD uses documented and predictable? I am not asking to decrypt the password (I expect that is impossible). I'm simply asking if I needed to, could I extract the hashed password and reproduce the hashing algorithm so that we could move off of AD if we needed to down the road? Thanks!

UPDATE: Seems a lot of folks are misunderstanding my question. I do NOT want to decrypt any passwords. Not only is that super sketch, it's not what I'm trying to do. What I want to do is know the routine that AD uses for hashing passwords in a safe, one-way manner. Once I know that, I could easily just re-implement my own system that can authenticate users in a compatible manner. I hope that clears things up!

share|improve this question
I'm a little lost why changing passwords is such a big deal? Should this system ever fall Under any normal regulations or compliance your users will be be required to change them at regular intervals. Just my two cents but I'd put your foot down instead of solving a problem that shouldn't exist. – SpacemanSpiff Oct 31 '11 at 4:36
Seems that a lot of folks are looking at it from the perspective of an IT administrator and that this is going to be used for some internal system to manage Windows logins. It's not. It's for a public-facing webapp. Last I checked, Twitter and Facebook do not require me to change passwords at regular intervals and neither do we. – Patrick Lightbody Oct 31 '11 at 14:34
Twitter and Facebook are not under regulatory compliance for their customer interfaces. If you ever fall under this category, it could be a concern. Maybe eDirectory or OpenLDAP has more documentation that will help you here. – SpacemanSpiff Oct 31 '11 at 16:13
I'm not under any regulatory compliance either and my original question never hinted at such a restriction :) – Patrick Lightbody Oct 31 '11 at 18:33

There is an option in AD for storing password with reversible encryption that you can turn on, which will allow you to decrypt the passwords. That being said, I would never ever want to pay money for a product or service that stores passwords in a reversible or portable format and I fully expect that you would fail any audits if you have this turned on.

It's irresponsible, in my opinion, to store user passwords in a reversible manner using any system. You should weigh the pros and cons and make a decision before you put any authentication mechanism into production.

share|improve this answer
So true. If preserving authentication tokens is so important, I'd look at something other than a password. – gravyface Oct 30 '11 at 23:19
I do NOT want to store the passwords in a reversible manner. I said as much: "I am not asking to decrypt the password". The fact that AD can store it in a manner is a bit sketch, but besides the point. My question for the community is: what is the hashing algorithm and how do I get the hashes? – Patrick Lightbody Oct 31 '11 at 3:33

This is quite doable, though somewhat... shady in the tools. Extracting password hashes is fairly simple, there are a variety of gray-market tools that'll do just that. Once you have those hashes, the existence of things like L0phtcrack and John the Ripper are strong evidence that the Windows password-hashing mechanism has been fully documented and is fully predictable.

Side note: part of the reason that Windows passwords are vulnerable to Rainbow Tables in a way that other password systems aren't is that Windows doesn't salt the hash.

If you can completely replicate the hashing process of Windows, you should be able to re-use the dumped hashes as the basis of an authentication system; all without actually decrypting the passwords. I just don't know of a product that does so.

share|improve this answer
or store it in NTLM v1 and break it in seconds. – gravyface Oct 30 '11 at 23:19
@gravyface Exactly. I've seen it first hand. – sysadmin1138 Oct 30 '11 at 23:25
There's nothing inherently "shady" about dumping your password hashes. Try pwdump2. – quadruplebucky Oct 31 '11 at 0:24
@quadruplebucky It's shady as far as the AV software is concerned. – sysadmin1138 Oct 31 '11 at 0:47
Again, I'm not looking to decrypt any passwords. I have no interest in that. What I am asking is: what is the hashing routine and can I get the hashes back out of AD? I simply would want to re-implement the routine so that I could authenticate users down the road even if I migrated off of AD. – Patrick Lightbody Oct 31 '11 at 3:34

The hashing algorithm for AD may well be predictable and repeatable, but it is not well documented. So I don't know that there is any way you're going to be able to do it that way. What I would suggest is looking into Active Directory to OpenLDAP migrations. The back end for OpenLDAP is much better documented. You could then use that as an intermediate step to implementing whatever it is you want to do.

I guess the other question I would ask is - what would cause you to move away from AD? If it's licensing costs or a general disdain for Microsoft products, build out the application differently to begin with. I would suggest that you should build it as you intend to proceed. Rearchitecting after the product has gone live will cause you nothing but heartache, regardless of how easy the migration plan appears to be.

share|improve this answer
One word: politics :) – Patrick Lightbody Oct 31 '11 at 4:12

sounds like a pretty tough task. maybe you can find something in the samba documentation

you could use the same algorithm in your new backend so you can use the encrypted passwords

share|improve this answer
Despite being down-voted, your answer is actually the closest to what I'm looking for! Your link actually tries describing a hashing routine. The problem is I can't be sure if it's the one AD uses (or if it has many options - I'm an AD newbie), and I also don't know whether I can get those hashes out of AD in the future. But I appreciate that you understood the core of what I was asking :) – Patrick Lightbody Oct 31 '11 at 3:38
it was probably downvoted becuse its too short and im not so well formated :). the passwords should be an attribute of the user object in the AD. since its ldap based you could use any ldap browser or a script to read it. – weberik Oct 31 '11 at 12:54

It sounds like you'd want to install something to intercept user password changes in AD and store them elsewhere. Something like passwdhk can grab the pw and do whatever you want with it (storing it unencrypted or in anything reversible is a bad idea, obviously).

You might have a look at sha1hexfltr This is used to copy AD passwords as SHA1 hashes into an attribute on the AD user (unsalted in a publicly readable AD attribute, which is a problem IMHO, angrytechnician has some ideas on that.

I dont see how a "forklift" from AD to something else would be possible (well, easy) - you'd need to have another system running simultaneously to be populated with auth data as users authenticated against AD, at the very least.

share|improve this answer
We're not using an Windows authentication, so no need for passwdhk or anything else. We have a Java program that is making standard LDAP calls to AD. In the future we might want to replace it with a simple MySQL database and not even use AD. – Patrick Lightbody Oct 31 '11 at 3:35

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.