So you've put all of your user accounts into LDAP for your Unix machines, but some of your users persist in running Windows so you need a Samba file server. Perhaps you're currently using an smbpasswd file but think it would be nice to integrate all of that information into LDAP. Well here's how to do it. The Samba HOWTO has a fair bit of documentation about this subject, but it wasn't super clear to me and I generally feel that a second view on a subject can be helpful.
This information is based on Samba 3.0.0 and newer. Older versions of Samba have some LDAP support but things changed significantly with version 3.0.0. These are not instructions for making Samba act as a domain controller, something I know nothing about. They're just instructions for setting up a plain file server using LDAP as the backend for Samba user settings and passwords.
I'm going to presume you already have LDAP working and populated with user accounts using the posixAccount object class or similar. If not then see the link above to my Kerberos and LDAP HOWTO, you'll want to start there. I'm also assuming your LDAP server is OpenLDAP. The first step is to add the Samba LDAP schema file to your LDAP servers. This file can be found at examples/LDAP/samba.schema in the Samba source distribution, or at /usr/share/doc/samba-ver/LDAP/samba.schema on Red Hat systems. Copy that into /etc/openldap/schema/ or wherever your schema files are kept on your LDAP servers, add a line to slapd.conf referencing it it, and restart slapd.
Next you need to populate your user accounts with the sambaSamAccount object class and associated attributes. sambaSID is the only additional attribute required by the schema, but you'll need at least sambaLMPassword and sambaNTPassword as well. In addition to those I added sambaAcctFlags for consistency with the smbpasswd file. You'll also need to add a sambaDomain entry for each Samba server (otherwise Samba will repeatedly try to add one for you) and configure a user that Samba can use to access the sambaLMPassword and sambaNTPassword fields.
Let's start with the SID and sambaDomain. SID is short for Security IDentifier as best I can tell and seems to be the Windows equivalent of Unix UIDs and GIDs, with the ability to reflect organizational hierarchy. If you have a real Windows domain then the SID heirarchy is created automatically, but we just want to fake it. The shortest one I could get Samba to take is S-1-0-0. I haven't been able to find a reference to the structure of a SID so I just guessed until it worked. So your resulting sambaDomain entry for myserver.example.com will look something like this. I put these under a seperate "samba" organizationalUnit to keep them seperate from users, groups, etc.
dn: sambaDomainName=myserver,ou=samba,dc=example,dc=com objectClass: sambaDomain sambaDomainName: myserver sambaSID: S-1-0-0
Before we move on to the actual user entries, you should create an entry in LDAP that Samba can authenticate as and access the sambaLMPassword and sambaNTPassword attributes. The contents of those attributes are equivalent to the user's plaintext password when authenticating to Samba, so you need to make sure your LDAP server ACLs prohibit anyone but the special Samba account from accessing them. The Samba account needs to have a regular userPassword entry, SASL or other fancy authentication methods aren't supported. Here's roughly what mine looks like. The password entry can be generated with slappasswd.
dn: uid=samba_servers,ou=people,dc=example,dc=com
objectClass: person
objectClass: uidObject
uid: samba_servers
description: Account used by Samba servers to access user passwords
cn: samba_servers
sn: samba_servers
userPassword: {SSHA}xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
And a sample ACL for slapd.conf:
access to attr=sambaLMPassword,sambaNTPassword
by dn.exact="uid=samba_servers,ou=people,dc=example,dc=com" read
by * none
Ok, now the regular user entries themselves. Here are the relevant attributes specific to Samba. The password values can be generated by mkntpwd, the souce to which can be found in examples/LDAP/smbldap-tools/mkntpwd/ in the Samba source distribution, or in /usr/share/doc/samba-ver/LDAP/smbldap-tools/mkntpwd/ on Red Hat systems. Keeping them in sync with Kerberos or wherever you store your Unix passwords is generally site specific and is left as an exercise to the reader.
The first part of the SID should match the SID in the sambaDomain entry created above. The final element is a little weird. Take the user's Unix UID (13988 in this case), multply it by 2 and add 1000. This is the formula used by the smbldap-tools scripts included with Samba. They do the same thing for groups but add 1001 instead. The result is that you can store users and groups in the same SID space and not have the UIDs and GIDs collide, because UIDs always translate to an even number and GIDs translate to an odd number.
objectClass: sambaSamAccount sambaAcctFlags: [U ] sambaLMPassword: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx sambaNTPassword: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy sambaSID: S-1-0-0-28976
At this point you should have LDAP populated with all of the necessary fields. Now the moment of truth, to configure Samba to reference LDAP for this information. Here's a sample of what goes in smb.conf. See the note in the comments here about storing the password for the special Samba user.
security = user passdb backend = ldapsam:ldap://ldap.example.com ldap ssl = start tls ldap suffix = dc=example,dc=com ldap user suffix = ou=people ldap group suffix = ou=group # FYI, the password for this user is stored in # /etc/samba/secrets.tdb. It is created by running # 'smbpasswd -w passwd' ldap admin dn = uid=samba_servers,ou=people,dc=example,dc=com
Restart Samba and watch syslog for errors. If you're curious you can view the contents of secrets.tdb with tdbdump, it comes with Samba.