It’s been a while since I’ve blogged about anything, but today we managed to solve a particularly important problem, that we were having trouble finding answers to, and I wanted to share it so that others might benefit.

First, a little back story.  We’re currently running a Samba 3 domain, on RHEL, which emulates an NT4 windows domain.  This has a down-side or two, one of them being these weak-ish ntlm hashes that we have to store in ldap.  Well we’re working toward resolving that by finally giving in and moving to Windows AD. Go ahead, point and laugh, I’ll wait.

…

Ok, got that out of your system?  Let’s continue.

We’ve got a number of hurdles already worked out, we are leveraging a grouper provisioner to populate our AD from ldap, and our password utility which lets users change their password in ldap is setup with AD hooks so we can set AD passwords.  The problem?  The initial password import!  The team has been banging their heads off of the issue for a few weeks now, while I’ve been tied up in other things. Trying different migration tools, we’ve even entertained the idea of paying someone to crack all of the NTLM hashes we’ve got!  Mass password resets maybe? Password re-assert?  Scraping passwords from our SSO app? Migrate the samba 3 domain to a samba 4 domain??  This morning I actually spent a few hours trying to see if I could tcpdump the traffic to our smtp servers, and then ssl decrypt the sessions to get logins that way.  All of these options met some success, but none of them were a great 100% solution.  Finally I decided to reach out to a guy I know from my years at DerbyCon.

I met Evil_Mog a few years ago he had some cool ideas for the Hack My Derby project and I’d sat in one of his talks about crypto currency.  He’s also done some cool stuff with HashCat, cracking NTLM hashes. See the link?  Yea.  So I hit up Mog on a slack group we’re both members of, and we chatted for a bit.  He gave me a slew of options of varying complexity and evilness.  One looked really promising though.  DSInternals.  This is a tool for powershell, which will, among other things, let you directly insert a hash for a user account’s password in AD!  Yea, this means we’re carrying forward the bad ntlm hashes, but at least it gets us running, and we can, hopefully, later have some password hygiene event or something where we have a mass password reset or re-assert that will re-set these hashes to something more modern.  I’d give you a blow-by-blow of the process, but so much of what we’re doing is specific to our environment that it probably wont help you, and could hurt us I suppose.  The ntlm hash insertion was as simple as getting the hash from our ldap, and then using the Set-SamAccountPasswordHash cmdlet to set the hash on an AD account (from a machine and account with proper permissions of course).  Boom!  Password sync.

I hope this helps someone else out!  We were almost in panic mode with deadlines approaching on our AD move, and no clear solution in site.  Thanks Mog! Remember folks, it’s not always what you know, it’s the network you cultivate.