The MD5 hash you are using for your LDAP "userPassword" attribute is
non-reversible - there isn't any straightforward way to convert it
into anything else. Unless you happen to have a supercomputer grid
handy to brute-force crack them, that is.

See, whenever you use that password, your machine takes some string
that the end-user has supplied and runs it through MD5. Then the
machine compares the UserPassword value with the MD5-hash of the
password string that the user supplied. If they match, you are
allowed in. But the machine does not actually know your password, and
it can't unconvert the MD5 into a string that could be NT-hashed for
an SMB password. The NT-hash is similarly not reversible, although
it's not very good (no salt, for one thing) so it is relatively easy
to crack (and quick, if you use rainbow tables).

When I converted our networks to samba a decade or more ago, I started
out by trying to crack all our user passwords by brute force, but I
could only get about 90% of them in any reasonable time frame. So,
instead, we modified our password changing process to produce the NT
and LM hashes as well as the MD5 hashes and made all our users
passwords expire over the course of the next two weeks.

That way I had matching NT, LM, and SMD5 password hashes which we've
maintained to this day in our enterprise LDAP directory.

--Charlie

On Fri, May 30, 2008 at 4:31 AM, Olivier Miquel
wrote:
> Hello,
>
> I'm trying to migrate openldap users to a samba+ldap solution.
> I had set up the samba+ldap server succesfully, and restored my accounts via
> smbldap-populate and an ldif file.
> But all my LDAP accounts didn't got all the samba field and i'm forced to
> update it manually via smbldap-usermod -a %user and smbldap -u %user ( and
> typing a new password ).
>
> So my question is :
> Wich is the way to update all acounts with the same samba password as unix
> password (without typing *manually* the samba password) in order to get them
> recognized by samba?
> or
> Is there a script that sync samba information / Password using the field
> userPassword that contains the hash for unix password ?
>
> Thanks for reading me,
>
> Olivier.
> ________
>
> Example of old account imported with "smbldap-populate dump.ldif" ( missing
> all samba information ! ) :
>
> dn: uid=charrasse,ou=Users,dc=mri.cnrs,dc=fr
> loginShell: /bin/bash
> sn: Charrasse
> objectClass: top,inetOrgPerson,posixAccount,mri-user
> gidNumber: 513
> accountType: user
> status: active
> mail: sophie.charrasse@BLAH.fr
> givenName: Sophie
> uid: charrasse
> uidNumber: 1583
> cn: charrasse
> userPassword: {MD5}c+URcajBLAHDcSObg==
> homeDirectory: /home/alluser
>
> Same account, now valid, modified with "smbldap-usermod -a %user" and
> "smbldap -u %user"
>
> dn: uid=charrasse,ou=Users,dc=mri.cnrs,dc=fr
> loginShell: /bin/bash
> sn: Charrasse
> objectClass: top,inetOrgPerson,posixAccount,mri-user,sambaSamAccount
> gidNumber: 513
> accountType: user
> status: active
> mail: sophie.charrasse@BLAH.fr
> givenName: Sophie
> uid: charrasse
> uidNumber: 1583
> cn: charrasse
> homeDirectory: /home/alluser
> sambaLogonTime: 0
> sambaLogoffTime: 2147483647
> sambaKickoffTime: 2147483647
> sambaPwdCanChange: 0
> displayName: User
> sambaSID: S-1-5-21-1510206305-3765163916-174898732-4166
> sambaLMPassword: 48FF388ABA3E5B33AAD3B435B51404EE
> sambaAcctFlags: [U]
> sambaNTPassword: BB37D7E678271274F1BF1133F9694C29
> sambaPwdLastSet: 1212142328
> sambaPwdMustChange: 1527502328
> userPassword: {MD5}uJ96BLAHctrDiypn9w==
>
>
>
> --
> passerelle antivirus du campus CNRS de Montpellier
> --
>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/listinfo/samba
>
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

On Fri, May 30, 2008 at 3:12 PM, Charlie wrote:

> When I converted our networks to samba a decade or more ago, I started
> out by trying to crack all our user passwords by brute force, but I
> could only get about 90% of them in any reasonable time frame. So,


Wow. *Only* 90%. Did the security admin have a cow? Perhaps your password
policies were too lax?

instead, we modified our password changing process to produce the NT
> and LM hashes as well as the MD5 hashes and made all our users
> passwords expire over the course of the next two weeks.


Maybe it should be mentioned that this can be accomplished with the 'unix
password sync = yes' if you are using pam_ldap on your Samba server.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

Apologies to the original poster for Rob & I chopping this all up...

On Fri, May 30, 2008 at 4:37 PM, Rob Shinn wrote:

> On Fri, May 30, 2008 at 3:12 PM, Charlie wrote:
>>
>> When I converted our networks to samba a decade or more ago, I started
>> out by trying to crack all our user passwords by brute force, but I
>> could only get about 90% of them in any reasonable time frame. So,
>
> Wow. *Only* 90%. Did the security admin have a cow? Perhaps your password
> policies were too lax?

Nowadays I could probably do better. There's more compute power
available, and rainbow tables are easy script-kiddy stuff these days.
But yes, I did have a cow, and yes, our password policies were (but no
longer are) certainly much too lax.

>> instead, we modified our password changing process to produce the NT
>> and LM hashes as well as the MD5 hashes and made all our users
>> passwords expire over the course of the next two weeks.
>
> Maybe it should be mentioned that this can be accomplished with the 'unix
> password sync = yes' if you are using pam_ldap on your Samba server.

AFAIK, that will only work *after* you've gotten synchronized to
start with. If you haven't any NT hashes, just MD5 hashes like the
original poster, your users can't log into samba since samba can't
supply an NT hash to the client PC with CHAP or whatever. Samba makes
it easy to maintain sync even though it's hard to establish sync
initially.

Oh, and "ldap password sync = yes" is probably more efficient -
keeps the name service switch and PAM out of the picture - but I think
you should watch out to make sure your LDAP transport is using the
encryption you want it to, or you might get plaintext or SHA hashes in
userPassword instead of salted MD5s.

--Charlie
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba