[K12OSN] Samba 3/LDAP and smbldap tools...anyone?

[Shahms King]

On Fri, 2004-05-21 at 11:30, David Trask wrote:
> Hi,
> 
> Has anyone out there managed to get a Samba 3 /LDAP server up and running?
>  I'm trying and would like to compare notes.  The newer version of
> smbldap-tools and ao forth deal with more security in the past....so I'm
> running into a few hurdles....I'm not too familiar with TLS.  In fact,
> I've been trying to turn it off.  Out of curiousity....why would TLS and
> certicficates...etc. help me with my own PDC in my building...one
> server....behind a firewall.  I'm soliciting opinions here...so let me
> know.  Also...please let me know if you have or are working on getting a
> Samba 3/LDAP server up and running.
> 
> David N. Trask
> Technology Teacher/Coordinator
> Vassalboro Community School
> dtrask at vcs.u52.k12.me.us
> (207)923-3100

We haven't yet migrated to Samba 3, but it's on the (long) list for this
summer.  TLS is essentially "negotiated SSL". Rather than connecting to
the ldaps port, you connect to the plain ldap port and send a
'START_TLS' command.  The rest of the connection is then encrypted as if
you'd connected to the SSL port.  And having them enabled (especially if
you're using LDAP for authentication) is good for the same reasons ssh
is better than telnet.  You might be behind a firewall, but that doesn't
mean no one is trying to sniff your passwords.  Here's a list of reasons
to use TLS/SSL for the LDAP connection:

1) Samba has to connect to the LDAP server as an administrative user to
retrieve the LANMAN and NT password hashes.

2) LANMAN hashes can be cracked on a modern computer in a matter of
minutes, probably much faster.

3) NT hashes take a little bit longer, but not much.

4) The windows machines already send them over the wire, might as well
not send the *known correct* password immediately after. (The weakness
of the hashes is why you want to protect those attributes with ACLs on
the LDAP server to begin with)

5) Because of all of this, not using TLS/SSL means someone sniffing the
connection between the LDAP server and the Samba server can not only get
the LDAP administrative password, but, failing that, they can get the
easily crackable hashes for every account as it logs in.  Not good.

-- 
Shahms King <shahms at shahms.com>