6.3. Implementation Samba-3 has the ability to use multiple password (authentication and identity resolution) backends. The diagram in Figure 6.1 demonstrates how Samba uses winbind, LDAP, and NIS, the traditional system password database. The diagram only documents the mechanisms for authentication and identity resolution (obtaining a UNIX UID/GID) using the specific systems shown. Figure 6.1. Samba and Authentication Backend Search Pathways 
Samba is capable of using the smbpasswd, tdbsam, xmlsam, and mysqlsam authentication databases. The SMB passwords can, of course, also be stored in an LDAP ldapsam backend. LDAP is the preferred passdb backend for distributed network operations. Additionally, it is possible to use multiple passdb backends concurrently as well as have multiple LDAP backends. As a result, you can specify a failover LDAP backend. The syntax for specifying a single LDAP backend in smb.conf is: ... passdb backend = ldapsam:ldap://master.abmas.biz ...
This configuration tells Samba to use a single LDAP server, as shown in Figure 6.2. Figure 6.2. Samba Configuration to Use a Single LDAP Server 
The addition of a failover LDAP server can simply be done by adding a second entry for the failover server to the single ldapsam entry, as shown here (note the particular use of the double quotes): ... passdb backend = ldapsam:"ldap://master.abmas.biz \ ldap://slave.abmas.biz" ...
This configuration tells Samba to use a master LDAP server, with failover to a slave server if necessary, as shown in Figure 6.3. Figure 6.3. Samba Configuration to Use a Dual (Fail-over) LDAP Server 
Some folks have tried to implement this without the use of double quotes. This is the type of entry they created: ... passdb backend = ldapsam:ldap://master.abmas.biz \ ldapsam:ldap://slave.abmas.biz ...
The effect of this style of entry is that Samba lists the users that are in both LDAP databases. If both contain the same information, it results in each record being shown twice. This is, of course, not the solution desired for a failover implementation. The net effect of this configuration is shown in Figure 6.4 Figure 6.4. Samba Configuration to Use Dual LDAP Databases - Broken - Do Not Use! 
If, however, each LDAP database contains unique information, this may well be an advantageous way to effectively integrate multiple LDAP databases into one seemingly contiguous directory. Only the first database will be updated. An example of this configuration is shown in Figure 6.5. Figure 6.5. Samba Configuration to Use Two LDAP Databases - The result is additive. 
Figure 6.6. Network Topology 2000 User Complex Design A 
Figure 6.7. Network Topology 2000 User Complex Design B 
Note  | When the use of ldapsam is specified twice, as shown here, it is imperative that the two LDAP directories must be disjoint. If the entries are for a master LDAP server as well as its own slave server, updates to the LDAP database may end up being lost or corrupted. You may safely use multiple LDAP backends only if both are entirely separate from each other. |
It is assumed that the network you are working with follows in a pattern similar to what was covered in Chapter 5, "Making Happy Users". The following steps permit the operation of a master/slave OpenLDAP arrangement. IMPLEMENTATION STEPS FOR AN LDAP SLAVE SERVER 1. | Log onto the master LDAP server as root. You are about to change the configuration of the LDAP server, so it makes sense to temporarily halt it. Stop OpenLDAP from running on SUSE Linux by executing:
root# rcldap stop
On Red Hat Linux, you can do this by executing:
root# service ldap stop
| 2. | Edit the /etc/openldap/slapd.conf file so it matches the content of Example 6.3.1.
| 3. | Create a file called admin-accts.ldif with the following contents:
dn: cn=updateuser,dc=abmas,dc=biz objectClass: person cn: updateuser sn: updateuser userPassword: not24get dn: cn=sambaadmin,dc=abmas,dc=biz objectClass: person cn: sambaadmin sn: sambaadmin userPassword: buttercup
| 4. | Add an account called "updateuser" to the master LDAP server as shown here:
root# slapadd -v -l admin-accts.ldif
| 5. | Change directory to a suitable place to dump the contents of the LDAP server. The dump file (and LDIF file) is used to preload the slave LDAP server database. You can dump the database by executing:
root# slapcat -v -l LDAP-transfer-LDIF.txt
Each record is written to the file.
| 6. | Copy the file LDAP-transfer-LDIF.txt to the intended slave LDAP server. A good location could be in the directory /etc/openldap/preload.
| 7. | Log onto the slave LDAP server as root. You can now configure this server so the /etc/openldap/slapd.conf file matches the content of Example 6.3.2.
| 8. | Change directory to the location in which you stored the LDAP-transfer-LDIF.txt file (/etc/openldap/preload). While in this directory, execute:
root# slapadd -v -l LDAP-transfer-LDIF.txt
If all goes well, the following output confirms that the data is being loaded as intended:
added: "dc=abmas,dc=biz" (00000001) added: "cn=sambaadmin,dc=abmas,dc=biz" (00000002) added: "cn=updateuser,dc=abmas,dc=biz" (00000003) added: "ou=People,dc=abmas,dc=biz" (00000004) added: "ou=Groups,dc=abmas,dc=biz" (00000005) added: "ou=Computers,dc=abmas,dc=biz" (00000006) added: "uid=Administrator,ou=People,dc=abmas,dc=biz" (00000007) added: "uid=nobody,ou=People,dc=abmas,dc=biz" (00000008) added: "cn=Domain Admins,ou=Groups,dc=abmas,dc=biz" (00000009) added: "cn=Domain Users,ou=Groups,dc=abmas,dc=biz" (0000000a) added: "cn=Domain Guests,ou=Groups,dc=abmas,dc=biz" (0000000b) added: "uid=bobj,ou=People,dc=abmas,dc=biz" (0000000c) added: "sambaDomainName=MEGANET2,dc=abmas,dc=biz" (0000000d) added: "uid=stans,ou=People,dc=abmas,dc=biz" (0000000e) added: "uid=chrisr,ou=People,dc=abmas,dc=biz" (0000000f) added: "uid=maryv,ou=People,dc=abmas,dc=biz" (00000010) added: "cn=Accounts,ou=Groups,dc=abmas,dc=biz" (00000011) added: "cn=Finances,ou=Groups,dc=abmas,dc=biz" (00000012) added: "cn=PIOps,ou=Groups,dc=abmas,dc=biz" (00000013)
| 9. | Now start the LDAP server and set it to run automatically on system reboot by executing:
root# rcldap start root# chkconfig ldap on
On Red Hat Linux, execute the following:
root# service ldap start root# chkconfig ldap on
| 10. | Go back to the master LDAP server. Execute the following to start LDAP as well as slurpd, the synchronization daemon, as shown here:
root# rcldap start root# chkconfig ldap on root# rcslurpd start root# chkconfig slurpd on
On Red Hat Linux, check the equivalent command to start slurpd.
| 11. | On the master LDAP server you may now add an account to validate that replication is working. Assuming the configuration shown in Chapter 5, "Making Happy Users", execute:
root# /var/lib/samba/sbin/smbldap-useradd -a fruitloop
| 12. | On the slave LDAP server, change to the directory /var/lib/ldap. There should now be a file called replogfile. If replication worked as expected, the content of this file should be:
time: 1072486403 dn: uid=fruitloop,ou=People,dc=abmas,dc=biz changetype: modify replace: sambaProfilePath sambaProfilePath: \\MASSIVE\profiles\fruitloop - replace: sambaHomePath sambaHomePath: \\MASSIVE\homes - replace: entryCSN entryCSN: 2003122700:43:38Z#0x0005#0#0000 - replace: modifiersName modifiersName: cn=Manager,dc=abmas,dc=biz - replace: modifyTimestamp modifyTimestamp: 20031227004338Z -
| 13. | Given that this first slave LDAP server is now working correctly, you may now implement additional slave LDAP servers as required.
| 14. | On each machine (PDC and BDCs) after the respective smb.conf files have been created as shown in Example 6.3.3 and on BDCs the Example 6.3.6 execute the following:
root# smbpasswd -w buttercup
This will install in the secrets.tdb file the password that Samba will need to manage (write to) the LDAP Master server to perform account updates.
|
6.3.1. Key Points Learned Where Samba-3 is used as a domain controller, the use of LDAP is an essential component to permit the use of BDCs. Replication of the LDAP master server to create a network of BDCs is an important mechanism for limiting WAN traffic. Network administration presents many complex challenges, most of which can be satisfied by good design but that also require sound communication and unification of management practices. This can be highly challenging in a large, globally distributed network. Roaming profiles must be contained to the local network segment. Any departure from this may clog wide-area arteries and slow legitimate network traffic to a crawl.
|
