The above setup sure is a bitch to get running. There is plenty of documentation and tools scattered around the Web, but it looks like the user funnel goes something like this:
- 1.000.000 users running Samba on their Linux
- 1.000 out of the above users are running OpenLDAP on their Linux(es)
- 1 out of the above users are running Samba with passdb backend = ldapsam
In the end, there is no definite document or tool to rely on. I spent about two weeks gathering information and trying out various approaches. I had to run my LDAP-queries unencrypted while sniffing the traffic with Wireshark to get an idea what kind of information is being requested.
In the end, just getting LDAP working on your server(s) is difficult enough for most people to get discouraged by the constant failures while attempting the setup. The advantages are there, being able to authenticate SSH-shell, secured web pages, WebDAV and any number of applications against exactly same user name / password -pair in a tested and secure manner is an execllent reward. Just having HTTP Basic Auth running against existing Linux userbase without LDAP is very difficult and mostly requires poking unnecessary holes to system security to get it running.
One of the really bad things is that not all documentations describes a simple step-by-step -process of making the setup secure. There is no need to allow all access to everybody, for example a simple:
olcAccess: {0}to attrs=userPassword,shadowLastChange
by self write
by anonymous auth
by dn="cn=admin,dc=example,dc=org" write
by * none
will make harvesting accidentally stored plain text -password much more difficult than the out-of-the-box solution does. All stored LDAP-passwords should be hashes, right? Not all tools default doing that.
When all the Samba-parts are in the LDAP, the above issue raises again. Using LanManager-passwords is out right stupid, they can be brute-forced with ease, but NTLM-passwords need to be protected with similar access-line:
olcAccess: {1}to attrs=sambaLMPassword,sambaNTPassword
by dn.base="cn=admin,dc=example,dc=org" write
by dn.base="cn=sambaservers,dc=example,dc=org" write
by anonymous auth
by self write
by * none
After that, there is some sanity in system setup.
To get all the "Samba-parts" working into your LDAP, Microsoft Knowledgebase article Q243330 about Well-known security identifiers in Windows operating systems is a must-have reference. While debugging the LDAP-queries you will face something like this:
ldapsearch -x -b "dc=example,dc=org" \
"(&(&(objectclass=sambaGroupMapping)(sambaGroupType=4))
(|(|(|(|(|(|(|(|(|(sambaSIDList=S-1-1-0)(sambaSIDList=S-1-5-2))(sambaSIDList=S-1-5-11))
(sambaSIDList=S-1-22-2-1099))
(sambaSIDList=S-1-5-32-545))
(sambaSIDList=S-1-22-2-1101))
(sambaSIDList=S-1-22-2-1102))
(sambaSIDList=S-1-5-32-544)))))" cn gid
Initial impression will be WTF!? However, most of the SIDs are needed in your LDAP to make Windowses happy.
Some kind of setup wizard would be nice. It would save couple of weeks debugging / setup time.
