Friday, July 26, 2013

Old: Samba, LDAP


An old task I thought I'd toss up into a post.  I had all of my user accounts into LDAP for my Unix machines, but some of my users persist in running Windows.  I needed a Samba file server, but I wanted the same LDAP credentials to work.  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.

Populating LDAP

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
Configure Samba

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.

No comments:

Post a Comment