9.4. passdb Recommendations
Chapter 5 covered the technical details of the three passdb plug-ins distributed with Samba: smbpasswd, tdbsam, and ldapsam. Our focus here is to address which one to use on a Samba domain controller. This discussion is less technical and more philosophical. We will reiterate some of the points made in earlier chapters that should also be considered in the context of Samba domains. Each passdb has its pros and cons. The ultimate choice is up to you.
Samba's smbpasswd file has the advantage of being very simple. It's a text file with one record per line and a small number of fields per record. Its main intended use is on standalone file and print servers. Because such servers merely have to authenticate users, all they need to store in the smbpasswd file are a username, a password, and possibly password expiration calculations. The user's SID is generated at runtime based on an internal algorithm and the user's Unix account. This means that if the uid ever changes, so will the user's SID: this situation can break roaming profiles. The lack of persistent SID storage is the main reason why we recommend against using the smbpasswd passdb on a domain controller.
The tdbsam passdb is targeted at both standalone servers and Samba domains with a single PDC. It can store a more complete set of user attributes than smbpasswd. For example, the logon options such as logon script can be set on a per-user basis rather than relying on a single default value from smb.conf. The tdbsam passdb also stores the user's SID, a feature that is required to migrate a Windows NT 4.0 domain to a Samba domain controller. However, the lack of replication makes tdbsam unsuitable for domains with multiple Samba domain controllers.
The ldapsam backend has the completeness of tdbsam with the added overhead of an LDAP directory. Very LDAP-savvy administrators may find it appealing (although it is not recommended) to edit user or group attributes directly, something impossible to do with tdbsam.
The attraction of directory services is to consolidate information that was previously duplicated across network services. Therefore, the ldapsam passdb module is intended as a means of sharing information between multiple Samba domain controllers. Because ldapsam, like tdbsam, stores the full SID in user and group entries, it is not a way to share this information between multiple standalone servers. Each host would have a different machine SID and hence would recognize only accounts matching its own SID. A user created by one workgroup server would be ignored by another.
Table 9-4 provides some basic rules to consider when choosing an account storage plug-in for your new Samba server. Remember that these are recommendations and not rules. You are the final judge concerning which passdb to deploy. For example, ldapsam may be completely acceptable on a standalone server if you have only one Samba host on the network and already have an LDAP directory available for use. If you need advice or someone to bounce ideas off of, the Samba mailing lists mentioned in Chapter 12 are good places to get peer review of your configurations.