LDAP System Administration [Electronic resources] نسخه متنی

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.

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: kcarter@plainjoe.org
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: \>