This page describes how to set up a Samba PDC using LDAP for its user database. There may be easier ways to get this running, but this text was written with the goal that you you will actually know what you are doing after reading this. It may be harder than, say, running YaST, but knowing the background usually saves much grieve in the long run.

There's a summary including, complete configuration files, at the end of this page.

LDAP configuration

The basic configuration of the OpenLDAP server is quite easy. Only the following options have to be set in /etc/openldap/slapd.conf (manual).

include   /etc/openldap/schema/core.schema
include   /etc/openldap/schema/cosine.schema
include   /etc/openldap/schema/inetorgperson.schema
include   /etc/openldap/schema/nis.schema
include   /etc/openldap/schema/samba3.schema

# suffix this server is responsible for ("superior knowledge")
suffix    "dc=prudence,dc=taliesyn"

# superuser
rootdn    "cn=Manager,dc=prudence,dc=taliesyn"
rootpw    descht

This includes some needed schema files and, with the suffix option, tells OpenLDAP that it is responsible for queries ending in “dc=prudence,dc=taliesyn”. The rootdn and rootpw options create a superuser. The man page advises to delete this user after populating the database. The password could also be saved as a hash value instead of plain text.

The OpenLDAP clients will be needed quite a bit during the rest of the installation, so it's a good idea to set the “bind DN” (the DN of the user that is used to connect to the directory) and the “base DN” in ~/.ldaprc now:

binddn  cn=Manager,dc=prudence,dc=taliesyn
base    dc=prudence,dc=taliesyn

This safes the options -D cn=Manager,dc=prudence,dc=taliesyn and -b dc=prudence,dc=taliesyn when executing any of the OpenLDAP utilities.

The next step of is to create the “root” of the database with ldapadd -W -x < init.ldif.

OpenLDAP ACLs

Not every user should be able to read or write to every DN in the directory. Access can be restricted by placing ACLs in slapd.conf. Here's a litte crash course:

ACLs are processed from the top to the bottom, so order is important
every entry consists of “what”, “who” and “access”
- what defines the object in the database that is affected by this ACL
  - base defines a specific DN
  - one specifies all objects that have the given DN as a parent (i.e. one level down)
  - sub matches all entries in the subtree whose root is the provided DN
  - children everything below the given DN, but not the DN itself
- who defines for which DN (user) this ACL is in effect
- access defines what should happen with the request
processing of ACLs stops after the first match of what and who
what has an implicit access to * by * none (“granting no access privileges to an otherwise unspecified datum”)
who has an implicit by * none stop (denies access and stops further ACL processing)

For example, if in the ACL

access to dn.base="ou=addressbook,dc=apfelboymchen,dc=dol"
	by dn="cn=addressbook,ou=serviceuser,dc=apfelboymchen,dc=dol" manage
	by * read

the by * read had been placed before the manage for the addressbook service user, the service user couldn't add anything to the address book.

Concerning Samba I dreamed up the following ACLs. Note that I'm in now way an expert on this, so use these at your own risk!

#
# allow the "ldap admin dn" access, but deny everyone else
# this catches possible "by * read" below
access to attrs=userPassword,SambaLMPassword,SambaNTPassword,sambaPasswordHistory
        by dn="cn=Samba Admin,ou=serviceuser,dc=prudence,dc=taliesyn" write
        by dn="cn=admin,ou=Users,dc=prudence,dc=taliesyn" write
        by anonymous auth
        by self write
        by * none

#
# the next two ACLs allow the creation of
# dn=sambaDomainName=TALIESYN,dc=prudence,dc=taliesyn
access to dn.base="dc=prudence,dc=taliesyn"
        by dn="cn=Samba Admin,ou=serviceuser,dc=prudence,dc=taliesyn" write
        by dn="cn=admin,ou=Users,dc=prudence,dc=taliesyn" write
        by * read
access to dn.one="dc=prudence,dc=taliesyn"
        by dn="cn=Samba Admin,ou=serviceuser,dc=prudence,dc=taliesyn" write
        by dn="cn=admin,ou=Users,dc=prudence,dc=taliesyn" write
        by * read

#
# Allow everbody to read public information (UIDs and GIDs)
access to dn.sub="ou=Users,dc=prudence,dc=taliesyn"
        by dn="cn=Samba Admin,ou=serviceuser,dc=prudence,dc=taliesyn" write
        by dn="cn=admin,ou=Users,dc=prudence,dc=taliesyn" write
        by * read
access to dn.sub="ou=Groups,dc=prudence,dc=taliesyn"
        by dn="cn=Samba Admin,ou=serviceuser,dc=prudence,dc=taliesyn" write
        by * read
access to dn.sub="ou=Computers,dc=prudence,dc=taliesyn"
        by dn="cn=Samba Admin,ou=serviceuser,dc=prudence,dc=taliesyn" write
        by dn="cn=admin,ou=Users,dc=prudence,dc=taliesyn" write
        by * read

#
# not sure... only needed for winbindd?
access to dn.sub="ou=Idmap,dc=prudence,dc=taliesyn"
        by dn="cn=Samba Admin,ou=serviceuser,dc=prudence,dc=taliesyn" write
        by dn="cn=admin,ou=Users,dc=prudence,dc=taliesyn" write
        by * none

#
# Allow write to self (password updates) and deny everything else
access to *
        by self write
        by * none

Samba configuration

TODO

LDAP: The Windows part

ldapadd -W -x < samba.ldif adds the Windows-specific structure to the directory. The file creates the domain object, some Well-known security identifiers and the OUs that will hold the users, groups and computers.

If you have some Windows users from a previous samba installation, now it's a good time to insert them! The easiest way to do so are the MigrationTools by PADL. You won't need most of the scripts if you follow this HOWTO. They provide, however, an easy way to convert any old /etc/passwd and /etc/group into an LDIF file to create the user DNs and load the Unix-specific user attributes into the directory. Just edit the $DEFAULT_BASE entry in migrate_common.ph and run migrate_passwd.pl / migrate_group.pl on the passwd and group of your old samba installation.

The Samba specific attributes can be easily added to these new DNs by running
pdbedit -i tdbsam:/path/to/old/passdb.tdb.

The following script is useful to delete and re-create the directory from scratch.

#!/bin/bash

# recursively deleting only seems to work if there are no indices on the database!
ldapdelete -D "cn=Manager,dc=prudence,dc=taliesyn" -r -W "dc=prudence,dc=taliesyn"

for i in init.ldif samba.ldif passwd-import.ldif group-import.ldif; do
  echo $i
  ldapadd -W -x < $i
done
pdbedit -i tdbsam:$PWD/passdb.tdb

domain master = auto (default) sets domain master browser dependant of role

LDAP: The Unix part

Samba now stores its users in LDAP, but ist must also be able to map the Windows user to a Unix system user (i.e. a UID) for the file system permissions to work.

Unix (the C library) checks if a given user exists with the Name Service Switch (NSS) mechanism. All that needs to be done is to tell the NSS to also search for Unix users and groups in the LDAP Directory. This is no standard functionality. For the NSS to be able to use LDAP as its database, the NSS module nss_ldap has to be installed.

Configuration

The configuration file for nss_ldap is /etc/ldap.conf (manual).

# LDAP server
host 127.0.0.1

# The distinguished name of the search base
base dc=prudent,dc=taliesyn

# Where to find users
nss_base_passwd   ou=Users,dc=prudence,dc=taliesyn?uidNumber>=100
nss_base_passwd	  ou=Computers,dc=prudence,dc=taliesyn?uidNumber>=100
nss_base_group    ou=Groups,dc=prudence,dc=taliesyn?uidNumber>=100

Two things to note here:

There are two entries for nss_base_passwd. This is needed because Samba also needs a valid UID for every computer account. The second entry tells nss_ldap to also search for Unix users under the “Computers” OU, making it possible to store computer accounts and user accounts in different OUs.
nss_ldap is not configured to look up passwords in the LDAP directory via the nss_base_shadow option. The authentication of the users is done by Samba, there is no need for Windows user to also be authenticated by the system.

The following changes in /etc/nsswitch.conf (manual) tell the Name Service Switch to also look up users and groups in the LDAP directory via nss_ldap:

passwd: files ldap
group:  files ldap

Testing

getent passwd and getent group should now show both the Unix and the Windows users / groups created before! If you get strange results, try stopping nscd.

Summary

Configure LDAP
- /etc/openldap/slapd.conf
- ~/.ldaprc
Configure Samba
- /etc/openldap/smb.conf
Import some users
Configure the NSS and nss_ldap to also look up users in the LDAP directory
- /etc/nsswitch.conf
- /etc/ldap.conf
Experience the strange and backward feeling that adding a Windows client to a NT domain can be rewarding.