Single Sign-On and the Corporate Directory, Part III

dn: uid=samba_server,ou=people,o=ci,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: uidObject
sn: samba_server
cn: samba_server
userPassword: {SSHA}xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
uid: samba_server

Next, we need to tell Samba how to access the LDAP directory as samba_server user by using the smbpasswd command:

# /usr/bin/smbpasswd -w <password>
Setting stored password for
&rarrhk;"uid=samba_server,ou=people,o=ci,dc=example,dc=com"
&rarrhk;in secrets.tdb

For added security, you should turn off your shell's history logging as the password is given on the command line. The smbpasswd command takes the password given and stores it in /var/lib/samba/private/secrets.tdb keyed to the Samba domain and the admin dn, so if either of those values change, you need to rerun smbpasswd.

Because Samba uses this user to query and modify values in the directory, we need to allow the Samba admin write access to certain attributes in the directory, so make sure to add the appropriate ACLs to /etc/openldap/slapd.conf.

At this point, we can get the SID for our domain. To obtain the domain's SID, you need to be root on the primary domain controller (PDC) for the domain, and run:

# net getlocalsid
SID for domain CI-PDC is:
↪S-1-5-21-2162541494-3670296480-3949091320

If you won't be using the smbldap tools to create all of the Samba LDAP entries, you need to use this SID when creating those. I've included a sample LDIF containing all the entries you need to create in the on-line Resources.

Samba also needs a user with uid 0 in the LDAP directory temporarily to perform certain actions. The entry need not be a full posixAccount user, but it should look like Listing 4.

dn: uid=root,ou=people,o=ci,dc=example,dc=com
objectClass: account
objectClass: sambaSamAccount
cn: root
uid: root
displayName: root
sambaSID:
↪S-1-5-21-2162541494-3670296480-3949091320-1000
sambaPrimaryGroupSID:
↪S-1-5-21-2162541494-3670296480-3949091320-512
sambaNTPassword: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
sambaAcctFlags: [U          ]
sambaLogonTime: 0
sambaLogoffTime: 2147483647
sambaKickoffTime: 2147483647

Notice that this user entry does have an NT password, but this password need not be the same as the actual root password, and it's only temporary to get rights assigned to normal users. I've included a simple Perl script in the on-line Resources that you can use to generate the NT password hashes that are needed. You need the Crypt::SmbHash and Term::ReadKey Perl modules to use it.

The last user to modify is your own, so that it's recognized as a Samba user and is a Domain Admin. Listing 5 shows the LDIF.

You'll notice that this account also has an NT password in the LDAP directory. Unfortunately, as of this writing, Samba has no stable support for using Kerberos authentication unless Samba is authenticating against an AD server. There are ways, however, to store Kerberos principal data in an LDAP directory if you're using the Heimdal Kerberos implementation. This potentially could make Samba authentication a little bit cleaner, though it won't make your Samba domain an AD server. Because we're not using Heimdal and this isn't officially supported, we must store Samba passwords in the directory. I've provided some links in the on-line Resources on the Kerberos/LDAP solution if you're interested.

We're now ready to start Samba, but make sure you also start the winbind service as well. Under Gentoo, modify /etc/conf.d/samba.