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

[David Trask]

Ok....aside from the smbldap-tools config stuff and the switches in the
openldap files.....is there anything special I have to do to make TLS run?
 I have Net::LDAP installed.


"Support list for opensource software in schools." <k12osn at redhat.com>
writes:
>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.


David N. Trask
Technology Teacher/Coordinator
Vassalboro Community School
dtrask at vcs.u52.k12.me.us
(207)923-3100