LDAP System Administration
Page 21
The mod_ldap module supports two means of authenticating user connections once their directory entries are located. The LDAPAuthBinds directive controls which method is used. If it is set to off, mod_ldap searches the LDAP server anonymously (or uses a simple bind as the LDAPDNInfo entry) to retrieve all of the user information including the userPassword attribute. The module then hashes the password entered by the user (if necessary) using the local system's crypt( ) function and compares it to the value obtained from the directory search. This means that the userPassword must be stored in either {CLEAR} or {CRYPT} formats.
The preferred and default method (LDAPAuthBinds on) authenticates the connecting user by binding to the directory server. In this case, ProFTPD locates the DN of the connecting user by searching the directory (either anonymously or as the LDAPDNInfo). However, the userPassword attribute is never requested from the LDAP server under this configuration. The module then binds to the directory again, using the user's DN and the password that the user entered. If this bind succeeds, ProFTPD considers the user to be authenticated.
To configure ProFTPD for the preferred authentication method, add the following line to proftpd.conf:
## Require that an incoming user can successfully bind to the LDAPServer.
LDAPAuthBinds on
The final hurdle to overcome is to inform proftpd how to resolve UIDs and GIDs when listing files without using the standard getpwuid( ) and getgrgid( ) calls. The LDAPDoUIDLookups and LDAPDoGIDLookups directives instruct proftpd to query the directory server using the specified base suffix. Each directive accepts an optional parameter if you find it necessary to override the respective default search filters of (&(uidNumber= UNIX uid )(objectclasses=posixAccount)) and (&(gidNumber= UNIX gid ) (objectclasses=posixGroup)). These filters work well with your directory, so there is no need to change them.
## Look up UIDs and GIDs in the directory.
LDAPDoGIDLookups on "ou=group,dc=plainjoe,dc=org"
LDAPDoUIDLookups on "ou=people,dc=plainjoe,dc=org"
Assuming that you have a valid user named kristi in the directory, you can verify that mod_ldap and proftpd are working by connecting to the server (www.plainjoe.org) and uploading a file:
$ ncftp -u kristi -p testpass www.plainjoe.org
NcFTP 3.1.3 (Mar 27, 2002) by Mike Gleason (ncftp@ncftp.com).
Connecting to 192.168.1.100...
ProFTPD 1.2.7 Server (ProFTPD Default Installation) [www.plainjoe.org]
Logging in . . .
User kristi logged in.
Logged in to localhost.
ncftp / > put index.html
index.html: 1.38 kB 69.43 kB/s
ncftp / > ls -l
-rw-r--r-- 1 kristi ftpusers 464 Dec 18 2002 index.html
Table 8-1 lists the entire set of directives for mod_ldap.
Table 8-1. Parameters for the ProFTPD mod_ldap 2.7 module
Directive
Default
Description
LDAPAuthBinds
on
Should the connecting user be authenticated by binding to the directory server using the located DN and the user's password (on), or should the module hash the password locally and compare it with the userPassword attribute obtained from the directory (off)?
LDAPDefaultAuthScheme
crypt
Specifies the hashing scheme for passwords that are not prefixed by a type string ({ }). Possible values are crypt and clear.
LDAPDefaultGID
None
Specifies the default Unix GID to be assigned to the user if the gidNumber attribute is unavailable.
LDAPDefaultUID
None
Specifies the default Unix UID to be assigned to the user if the uidNumber attribute is unavailable.
LDAPDNInfo
"" ""
Defines the DN and password to use when binding to the directory server for searches.
LDAPDoAuth
off
Should mod_ldap be enabled for authentication?
LDAPDoGIDLookups
off
Should mod_ldap attempt to resolve GID numbers to names by querying the directory for matching posixGroup entries?
LDAPDoUIDLookups
off
Should mod_ldap attempt to resolve UID numbers to names by querying the directory for matching posixAccount entries?
LDAPForceDefaultGID
off
Forces the GID of all connected users to the LDAPDefaultGID, even if a gidNumber attribute can be obtained.
LDAPForceDefaultUID
off
Forces the UID of all connected users to the LDAPDefaultUID, even if a uidNumber attribute can be obtained.
LDAPHomedirOnDemand
off
Instructs mod_ldap to create the user's home directory (from the homeDirectory attribute) if it does not already exist. The directive also accepts a second parameter that sets the mode of the new directory.
LDAPHomedirOnDemandSuffix
""
Specifies additional subdirectories to be created in the event that LDAPHomedirOnDemand has been enabled. Multiple directories can be included in a whitespace-delimited list.
LDAPNegativeCache
off
Instructs mod_ldap to cache negative responses to UID/GID resolution attempts.
LDAPQueryTimeout
LDAP client library default
Specifies the maximum amount of time, in seconds, to wait for a search to complete.
LDAPSearchScope
subtree
Defines the LDAP search scope as onelevel or subtree.
LDAPServer
localhost
Specifies the hostname of the directory server. An alternative to port 389 can be defined using the syntax server:port. Multiple servers can be specified; separate server hostnames by spaces.
LDAPUseTLS
off
This parameter is available only if mod_ldap.c has been modified to define USE_LDAPV3_TLS. If enabled, mod_ldap will use the StartTLS extension when contacting the LDAP server. If the directory does not support TLS, mod_ldap will downgrade to an unencrypted channel and simply report failure to the proftpd server.
Apache
Now that users can upload files to your web server, Apache must be configured to resolve URLs such as http://www.plainjoe.org/~kristi. Traditionally, Apache administrators have used a subdirectory named public_html in home directories to provide a simple mechanism for users to publish personal web pages. This associates the tilde (~) with a home directory by asking the operating system to provide the details about the user from the local system password file, NIS map, or LDAP directory via NSS modules.
Because we have chosen not to implement any nss_ldap functionality on the server, we will have to use another means of instructing Apache how to determine a user's home directory location. Morrissey's mod_ldap_userdir module allows us to do just that.
This module obtains the path to a user's home directory by searching an LDAP directory for a posixAccount entry with a matching uid value. Our LDAP directory already supports the schema required for mod_ldap_userdir, so the new work to be done is localized to the web server. As usual, we focus only on the aspects of Apache needed to integrate the server with an LDAP directory. Full coverage of Apache configuration is well beyond the scope of a single chapter, as is the case with all of the server packages discussed in this chapter. For more information on Apache and its httpd.conf, refer to Apache: The Definitive Guide, by Ben and Peter Laurie (O'Reilly).
The first step is to download the latest version of the module from http://www.horde.net/~jwm/software/mod_ldap_userdir/. Building mod_ldap_userdir requires adding only a single option (—with-activate) to the configure script. However, unless the Apache eXtenSion tool is located in a directory in your $PATH, it will also be necessary to set the absolute path to the apxs binary. These are the steps I used to build the module for an Apache 1.3.23 installation, although an Apache 2.0 installation
is no different:
$ ./configure --with-activate --with-apxs=/usr/sbin/apxs
$ make
$ /bin/su -c "make install"
/usr/sbin/apxs -i -a mod_ldap_userdir.so
[activating module 'ldap_userdir' in /etc/httpd/conf/httpd.conf]
cp mod_ldap_userdir.so /usr/lib/apache/mod_ldap_userdir.so
chmod 755 /usr/lib/apache/mod_ldap_userdir.so
cp /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.bak
cp /etc/httpd/conf/httpd.conf.new /etc/httpd/conf/httpd.conf
rm /etc/httpd/conf/httpd.conf.new
The build process will fail if configure cannot locate the necessary LDAP libraries and header files. The two options, —with-sdk-headers=
## Activate the LDAP userdir module (this may also require an AddModule
## mod_ldap_userdir.c directive later in the file depending on the server's
## configuration).
LoadModule ldap_userdir_module /usr/lib/apache/mod_ldap_userdir.so
The module itself has seven directives, which are presented in Table 8-2. Your web server uses four of these directives:
LDAPUserDirServer ldap.plainjoe.org
LDAPUserDirSearchScope subtree
LDAPUserDirBaseDN ou=people,dc=plainjoe,dc=org
LDAPUserDir public_html
Table 8-2. Directives for mod_ldap_userdir
Directive
Default
Description
LDAPUserDir
public_html
The expected name of the subdirectory.
LDAPUserDirServer
None
The hostname of the LDAP directory server.
LDAPUserDirDNInfo
None
The DN and password to be used to bind to the directory. The password should be given in clear text.
LDAPUserDirBaseDN
""
The base search suffix to use when searching the directory.
LDAPUserDirFilter
(&(uid=%v)(objectclass=posixAccount))
The RFC 2254-compliant LDAP search filter to use when querying the directory.
LDAPUserDirSearchScope
subtree
The scope of the LDAP search; can be a onelevel or subtree.
LDAPUserDirUseTLS
off
Whether to use the StartTLS extended operation (on) or an unencrypted connection (off) when searching the directory.
The values for each directive in your configuration are fairly self-explanatory. LDAPUserDirServer, LDAPUserDirSearchScope, and LDAPUserDirBaseDN set the standard LDAP search parameters: the server's hostname (ldap.plainjoe.org), the search scope (subtree), and the base suffix (ou=people,dc=plainjoe,dc=org). The search filter is not set explicitly because the default filter string, (&(uid=%v)(objectclass=posixAccount)), works nicely with your directory; it matches the current username against the uid attributes of all posixAccount objects.
By default, Apache binds to the directory anonymously. However, you could specify a DN and password to be used when binding to the LDAP server by defining the LDAPUserDirDNInfo parameter. There is no need to avoid anonymous searches in this case because the uid and homeDirectory attributes have already been made available anonymously to support other services such as ProFTPD.
Once all of these pieces are in place, you can verify that the module is working correctly by viewing the index.html file uploaded to ~kristi/public_html in the previous section. If there are any errors, the two places to look for clues are Apache's error_log and OpenLDAP's syslog messages.
* * *
[2] ProFTPD's mod_ldap module should not be confused with any of Apache's modules of the same name (http://modules.apache.org/).
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.
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]
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.