Mass extract of unicodePwd?

Zare

Zare

I need to migrate existing ISP-level mail system which holds basic user data in Windows Server AD LDAP scheme. Thousands of users, and looks like Microsoft doesn't allow read access to unicodePwd attribute. Does anyone know an "offline" tool for the job? Akin to those reset-password-boot-cd's that usually run live Linux, mount NTFS, and then dig files manually.

P.S. This is a prime example of Microsoft's bullshit-security policy.
 
Even if you get access to unicodePwd, it's going to be hashed. Which means you're going to have to bruteforce them, which will take about a million years, give or take a couple of thousand.
 
Not any different if you were migrating user accounts from a system that uses a password hashing method that is not supported in the target system. The plain text passwords are meant to 100% unrecoverable from the hashes, otherwise you have a very serious security problem.
 
Well, you could leave the user database on AD and set up LDAP authentication with it.
 
SirDice said:
Even if you get access to unicodePwd, it's going to be hashed. Which means you're going to have to bruteforce them, which will take about a million years, give or take a couple of thousand.
Click to expand...

I don't need passwords, I need hashes.

Going to migrate user data to PostgreSQL, there is a 3rd party NTLM hash library, so it comes down to writing a procedure that'll prepare string for hashing (quoting, UTF-16, padding). The user/hash combinations dumped (hopefully!) would go straight into the tables. So basically, I would leave unicodePwd hashed format as is, and write a couple of stored procedures that would handle password check and update.

I do have default passwords that users initially received, I can check how many of those are still valid. For changed ones, well, if I don't get those unicodePwd's I could just sniff them. Which is a completely valid option, but it might last forever.
 
Both 2K3 and 2K8 use NTLM hashes for unicodePwd attribute, even LM/NTLM pair if plaintext input is less than 15 characters. The hash(es) are stored in SAM database. We're talking about Active Directory, not local passwords.

Edit : http://sourceforge.net/projects/ophcrack/ looks promising. If it can read out hashes in order to crack them with rainbow tables lookup, it can read out hashes :) Fortunately, we have virtualized the server in question, so I can play around with a clone (this thing is a live CD, of course).
 
You must log in or register to reply here.
Back
Top