8.3 User Authentication with Samba

This book has concentrated on Unix services, with only a few exceptions; email applications often cross platform boundaries, as do requirements for file and printer sharing. The Samba project (http://www.samba.org/) has become a staple for administrators seeking to integrate Unix file and print servers with Windows clients. Samba is a suite of programs that implement the server portion of the SMB (Server Message Block) protocol, later renamed CIFS (Common Internet File System).

Samba includes several client programs and administrative tools in addition to its server components. Adequate coverage of Samba is well beyond the scope of this book. For more information about Samba, see Sams Teach Yourself Samba in 24 Hours, Second Edition, by Gerald Carter (Sams Publishing), or Using Samba, Second Edition, by Jay Ts, Robert Eckstein, and David Collier-Brown (O'Reilly).

To support the challenge/response authentication methods used by Microsoft clients, Samba requires a list of hashed passwords separate from the normal Unix account information stored in /etc/passwd (or in the posixAccount object class). This collection of LanManager and Windows NT password hashes is normally stored in a file named smbpasswd(5); the format of each entry is:

username:uid:LM_HASH:NT_HASH:account flags:timestamp

Samba's smbpasswd file has several disadvantages for sites with many users:

• Lookups are performed sequentially. When servicing a domain logon request from a Windows NT/2000/XP client, there are a minimum of two lookups. These lookups can be a performance bottleneck.

• Attempts at using a single smbpasswd file for multiple standalone servers requires the administrator to use external tools, such as a combination of rsync(1) and ssh(1) or scp(1), to replicate the file. This solution also requires that the set of Unix users and groups be synchronized between the servers, perhaps using the methods outlined in Chapter 6.

• The format of the smbpasswd file limits the number of attributes that can be maintained for each user. When Samba is acting as a Windows Primary Domain Controller, there are many additional fields, such as the location of a user's roving profile, that should be maintained on an individual basis.

8.3.1 Configuring Samba

All of these deficiencies can be addressed by moving the information from a local, flat file into sambaAccount objects in an LDAP directory. The LDAP support in Samba 2.2.7a must be enabled at compile time using the �with-ldapsam configure script option.^[3]

^[3] The LDAP support in Samba 2.2 has no relationship to the LDAP support in a Windows 2000 domain or in Windows 2000 Active Directory servers.

This support requires the OpenLDAP 2 client libraries to be present when compiling Samba. Here's a typical Samba build:

root# ./configure --with-ldapsam
< . . . output deleted . . . >
checking whether to use LDAP SAM database . . .  yes
root# make 
root# make install

After installing the LDAP-enabled version of the Samba, the next step is to create a working configuration file (smb.conf) for the smbd(8) and nmbd(8) binaries. The following smb.conf creates a single file share named [files]:

## smb.conf file for LDAP-enabled Samba server 
[global]
  netbios name       = TASHTEGO
  workgroup          = PEQUOD
  security           = user
  encrypt passwords  = yes
      
  ## LDAPsam-related passwords
  ldap admin dn = "cn=smbadmin,ou=people,dc=plainjoe,dc=org"
  ldap server   = ldap.plainjoe.org
  ldap ssl      = start_tls
  ldap port     = 389
  ldap suffix   = "ou=people,dc=plainjoe,dc=org"
  ## The following is the default LDAP filter used if one is not explicitly defined.
  ldap filter   = "(&(uid=%U)(objectclass=sambaAccount))"
      
## Define the file service to be shared.
[files]
  path      = /export/files
  read only = no

If you've been following along, the LDAP-related parameters should be familiar. Table 8-3 provides descriptions of the various parameters as well as the default value assigned to each option.

Table 8-3. Samba's LDAPsam smb.conf parameters

Parameter	Default	Description
ldap admin dn	""	The DN used by smbd when connecting to the LDAP server. This DN should be able to read all attribute values for sambaAccount entries, including lmPassword and ntPassword.
ldap filter	(&(uid=%u)(objectclass=sambaAccount))	The RFC 2254-compliant search filter to use when locating a user's Samba account information.
ldap port	636	The tcp port to use when contacting the LDAP server.
ldap server	localhost	The FQDN of the directory server.
ldap ssl	on	The parameter that specifies how smbd connects to the LDAP server. The possible values are off (do not use encryption when communicating with the directory), on (use LDAPS when contacting the directory server), and start_tls (use the StartTLS command to establish an encrypted transport layer).
ldap suffix	""	The base search suffix to use when querying the directory.

Samba must obtain the Windows password hashes from the directory in order to authenticate a user using encrypted passwords. Due to their security-sensitive nature, the hashes should never be retrievable by an anonymous user. To bind to the host specified by the ldap server parameter, Samba requires a valid ldap admin dn value and a password. The clear-text password is not stored in Samba's configuration file (smb.conf is often world-readable, so storing the password in this file would be pointless). Rather, the password is stored in the secrets.tdb file located in /usr/local/samba/private/ by default. The password is still stored in clear text, but the permissions assigned to this file should restrict read and write access to the superuser account.

Samba's smbpasswd(8) utility is normally used to perform duties such as manipulating user entries in the smbpasswd(5) file, joining the Samba server to a Windows domain, and changing passwords for remote Windows users. Use it to store the ldap admin dn password by executing:

root# /usr/local/samba/bin/smbpasswd -w secret
Setting stored password for "cn=smbadmin,ou=people,dc=plainjoe,dc=org" in secrets.tdb

Because secrets.tdb can be read or written only by root, you must execute this command as root. If the smbpasswd command does not support the -w option, either LDAPsam support was not properly enabled when compiling Samba, or a non-LDAP-enabled version of the tool exists in your $PATH.

Currently, the Samba server uses a simple bind when contacting the directory server to retrieve user information. Given the access rights required by the ldap admin dn account and the clear text-equivalent nature of the LanManager and NT password hashes, it is strongly advised that the ldap ssl parameter be left enabled or set to use the StartTLS operation.

8.3.1.1 Configuring OpenLDAP

To store sambaAccount entries in the directory, your LDAP server must support the appropriate schema. Samba developers provide a definition of the sambaAccount schema for use with OpenLDAP 2 servers in the file examples/LDAP/samba.schema (included in the Samba source distribution). Copy samba.schema to an appropriate location, such as /usr/local/etc/openldap/schema/, and include it in the server's configuration by adding the appropriate include statements to the slapd.conf file. Two dependencies are noted at the beginning of the samba.schema file: cosine.schema (for the uid attribute) and inetorgperson.schema (for the displayName attribute). After you've finished editing the schema portion of slapd.conf, it should look like this:

## /usr/local/etc/openldap/slapd.conf
      
## core.schema is required for all servers.
include  /usr/local/etc/openldap/schema/core.schema
      
## Included from Chapter 6
include  /usr/local/etc/openldap/schema/cosine.schema
include  /usr/local/etc/openldap/schema/nis.schema
      
## Included from Chapter 4
include  /usr/local/etc/openldap/schema/inetorgperson.schema
      
## Dependencies for samba.schema: cosine.schema and inetorgperson.schema needed to
## support --with-ldapsam in Samba 
include  /usr/local/etc/openldap/schema/samba.schema

Figure 8-3 shows attributes used by the sambaAccount object class. The Samba-LDAP-HOWTO file (also distributed with the Samba source distribution) defines each attribute and its expected values. All of the attributes are stored as ASCII string values (IA5String).

Figure 8-3. sambaAccount object class

In addition to the schema changes, you must add a new access control rule to prevent normal users (authenticated or not) from retrieving LanMan/NT password hashes (the lmPassword and ntPassword attributes) from the directory. Since OpenLDAP never uses these attributes for authenticating a bind request, there is no reason for a user to access these attributes. The other attributes of the sambaAccount object class do not contain any sensitive information, so it doesn't matter who reads them. The first and last slapd.conf ACLs are repeats from Chapter 6. The second access rule denies all users except smbadmin access to the lmPassword and ntPassword attributes. This ACL could be modified to allow users to change their own password hashes without any adverse security affects. The third allows the cn=smbadmin user to write to all entries in the ou=people subtree. You could tighten down this ACL by restricting the smbadmin's access to the attributes of the a sambaAccount object only, but the simpler version is presented here:

## Previous ACL from Chapter 6
access to attrs=userPassword
    by self write
    by * auth
      
## Don't let users snoop Windows passwords.
access to attrs=lmPassword,ntPassword
    by dn="cn=smbadmin,ou=people,dc=plainjoe,dc=org" write
    by * none
      
## Allow the Samba admin user to add new entries and modify existing ones.
access to dn.subtree="ou=people,dc=plainjoe,dc=org"
    by dn="cn=smbadmin,ou=people,dc=plainjoe,dc=org" write
    by * read
      
## Previous ACL from Chapter 6
access to dn.subtree="ou=group,dc=plainjoe,dc=org"
    by * read

I have already added Samba's ldap admin dn to smb.conf, but have yet to explain what its directory entry looks like. Samba will bind to the directory as the user, so it must possess a userPassword attribute value. However, it is not necessary that this entry have a numeric UID or other POSIX attribute. The person structural object class in OpenLDAP's core.schema file includes just the attributes you need: a name and a password. Figure 8-4 displays the required and optional attributes held by a person in the directory.

Figure 8-4. person object class

A simple LDIF representation of the cn=smbadmin entry would be:

dn: cn=smbadmin,ou=people,dc=plainjoe,dc=org
objectclass: person
cn: smbadmin
sn: smbadmin
userPassword: {SSHA}xDG3/Cfj7ATgJ9yP0exS2lGD+infJqCj

In this case, the userPassword attribute holds the SSHA hash of the passphrase string "secret."

You have now finished all the configuration details, and are ready to add a real sambaAccount entry. When you've done this, you can start testing.

8.3.2 Adding and Using a sambaAccount

Just as entries in the smbpasswd(5) file supplement entries in the local system passwd file, the sambaAccount entries in the directory supplement the basic Unix account information. smbd always queries the server's operating system for attributes such as the Unix home directory and user ID. By using both the posixAccount and the sambaAccount auxiliary object classes, you can store all of this information in your directory.

The only requirement Samba places on sambaAccount or smbpasswd entries is that the operating system must provide a valid set of Unix attributes for the user (e.g., a Unix UID and primary GID). The example presented here uses the directory structure presented earlier in this chapter and therefore assumes that a posixAccount entry already exists for all valid Unix users.

To add the sambaAccount information required for validating Windows users, we turn to the smbpasswd(8) utility. The -a option specifies the username of the account to be added, and the -s option specifies the initial password. For example, to add a user named kristi, execute the following command as root:

root# smbpasswd -a kristi -s testpass
LDAP search "(&(uid=kristi)(objectclass=sambaAccount))"     
     returned 0 entries.
Added user kristi.

The message about the LDAP query returning 0 entries is normal. smbpasswd(8) initially looks for a preexisting account with the specified username. Since you are adding a new account, this search returns 0 entries. The resulting entry in the directory (with sambaAccount attributes highlighted), including the preexisting posixAccount attributes, appears as:

dn: uid=kristi,ou=people,dc=plainjoe,dc=org
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: sambaAccount
cn: Kristi Carter
cn: Kristi W. Carter
sn: Carter
mail: [email protected]
labeledURI: http://www.plainjoe.org/~kristi
roomNumber: 102 Ramsey Hall
telephoneNumber: 222-555-2356
userPassword: {SSHA}7eXyEM+Q+1BVUGFz/MOWYUCONdovP3uM
loginShell: /bin/bash
uidNumber: 781
gidNumber: 100
homeDirectory: /home/kristi
gecos: Kristi Carter
uid: kristi
pwdLastSet: 1040186720
logonTime: 0
logoffTime: 2147483647
kickoffTime: 2147483647
pwdCanChange: 0
pwdMustChange: 2147483647
rid: 2570
primaryGroupID: 1201
lmPassword: 3AE6CCCE2A2A253F93E28745B8BF4BA6
ntPassword: 35CCBA9168B1D5CA6093B4B7D56C619B
acctFlags: [UX         ]

We can confirm that Samba can authenticate the new user by using smbclient:

$ smbclient //tashtego/files -Ukristi%testpass
Domain=[PEQUOD] OS=[Unix] Server=[Samba 2.2.7a]   
smb: \>