From 992f1e6b8f86b346fddd266b04d29cde69585633 Mon Sep 17 00:00:00 2001 From: Jelmer Vernooij Date: Wed, 7 Apr 2004 10:15:11 +0000 Subject: Add all the source files from the old CVS tree, add the 5 missing chapters from the HOWTO and add jht's Samba by Example book. (This used to be commit 9fb5bcb93e57c5162b3ee6f9c7d777dc0269d100) --- docs/guide/Chap07-2000UserNetwork.xml | 1815 +++++++++++++++++++++++++++++++++ 1 file changed, 1815 insertions(+) create mode 100644 docs/guide/Chap07-2000UserNetwork.xml (limited to 'docs/guide/Chap07-2000UserNetwork.xml') diff --git a/docs/guide/Chap07-2000UserNetwork.xml b/docs/guide/Chap07-2000UserNetwork.xml new file mode 100644 index 0000000000..a8f7b91e2d --- /dev/null +++ b/docs/guide/Chap07-2000UserNetwork.xml @@ -0,0 +1,1815 @@ + + + + %xinclude; + + + + %global_entities; + +]> + + + A Distributed 2000 User Network + + There is something indeed mystical about things that are + big. Large networks exhibit a certain magnetism and exude a sense of + importance that obscures reality. You and I know that it is no more + difficult to secure a large network than it is a small one. We all + know that over and above a particular number of network clients, the + rules no longer change; the only real dynamic is the size of the domain + (much like a kingdom) over which the network ruler (oops, administrator) + has control. The real dynamic then transforms from the technical to the + political. Then again, that point is often reached well before the + kingdom (or queendom) grows large. + + If you have systematically worked your way to this chapter, hopefully you + have found some gems and techniques that are applicable in your + world. The network designs you have worked with in this book with have their + strong points as well as weak ones. That is to be expected given that + they are based on real business environments, excepting that the facts + have been moulded to serve the purposes of this book. + + This chapter is intent on wrapping up issues that are central to + implementation and design of progressively larger networks. Are you ready + for this chapter? Good, it is time to move on. + + In previous chapters, you made the assumption that your network + administration staff need detailed instruction right down to the + nuts-and-bolts of implementing the solution. That's is still the case, + but they have graduated now. You decide to document only those issues, + methods and techniques that are new or complex. Routine tasks such as + implementing a DNS or a DHCP server are under control. Even the basics of + Samba are largely under control. So in this section you focus on the + specifics of implementing LDAP changes, Samba changes, and approach and + design of the solution and its deployment. + + + Introduction + + + Abmas is a miracle company. Most businesses would have collapsed under + the weight of rapid expansion that this company has experienced. Samba + is flexible, so there is no need to reinstall the whole operating + system just because you need to implement a new network design. In fact, + you can keep an old server running right up to the moment of cut-over + and then do a near-live conversion. There is no need to reinstall a + Samba server just to change the way your network should function. + + + + LDAP + + Network growth is common to all organizations. In this exercise, + your preoccupation is with the mechanics of implementing Samba and + LDAP so that network users on each network segment can work + without impediment. + + + Assignment Tasks + + + Starting with the configuration files for the server called + MASSIVE in Chapter 6, you now deal with the + issues that are particular to large distributed networks. Your task + is simple &smbmdash; identify the challenges, consider the + alternatives, and then design and implement a solution. + + + VPN + + Remember, you have users based in London (UK), Los Angeles, + Washington DC, and three buildings in New York. A significant portion + of your workforce have notebook computers and roam all over the + world. Some dial into the office, others use VPN connections over the + Internet and others just move between buildings. + + What do you say to an employee who normally uses a desktop + system but must spend six weeks on the road with a notebook computer? + She is concerned over email access and how to keep co-workers current + with changing documents. + + To top it all off, you have one network support person and one + Help desk person based in London, a single person dedicated to all + network operations in Los Angeles, five staff for user administration + and Help desk in New York, plus one floater for + Washington DC. + + You have outsourced all desktop deployment and management to + DirectPointe,Inc. Your concern is server maintenance and third-level + support. Build a plan and show what must be done. + + + + + + Dissection and Discussion + + + passdb backend + + LDAP + + In the previous chapter, you implemented an LDAP server that provided the + passdb backend for the Samba servers. You + explored ways to accelerate Windows desktop profile handling and you + took control of network performance. + + + + ldapsam + + tdbsam + + smbpasswd + + replicated + + The implementation of an LDAP-based passdb backend (known as + ldapsam in Samba parlance), or some form of database + that can be distributed, is essential to permit the deployment of Samba + Primary and Backup Domain Controllers (PDC/BDCs). You see, the problem + is that the tdbsam style passdb backend does not + lend itself to being replicated. The older plain-text-based + smbpasswd style passdb backend can be replicated + using a tool such as rsync, but + smbpasswd suffers the drawback that it does not + support the range of account facilities demanded by modern network + managers. + + + XML + + SQL + + The new tdbsam facility supports functionality + that is similar to an ldapsam, but the lack of + distributed infrastructure sorely limits the scope for its + deployment. This does raise the following questions: "Why can't I just use + an XML based backend, or for that matter, why not use an SQL based + backend?" "Is support for these tools broken?" No. Answers to these + questions require a bit of background. + + + directory + + database + + transaction processing + + LDAP + + What is a directory? A directory is a + collection of information regarding objects that can be accessed to + rapidly find information that is relevant in a particular and + consistent manner. A directory differs from a database in that it is + generally more often searched (read) than updated. As a consequence, the + information is organized to facilitate read access rather than to + support transaction processing. + + + Lightweight Directory Access Protocol + LDAP + + LDAP + + master + + slave + + The Lightweight Directory Access Protocol (LDAP) differs + considerably from a traditional database. It has a simple search + facility that uniquely makes a highly preferred mechanism for managing + user identities. LDAP provides a scalable mechanism for distributing + the data repository and for keeping all copies (slaves) in sync with + the master repository. + + + identity management + + Active Directory + + OpenLDAP + + Samba is a flexible and powerful file and print sharing + technology. It can use many external authentication sources and can be + part of a total authentication and identity management + infrastructure. The two most important external sources for large sites + are Microsoft Active Directory and LDAP. Sites that specifically wish to + avoid the proprietary implications of Microsoft Active Directory + naturally gravitate toward OpenLDAP. + + + network + routed + + In Chapter 6, you had to deal with a locally routed + network. All deployment concerns focused around making users happy, + and that simply means taking control over all network practices and + usage so that no one user is disadvantaged by any other. The real + lesson is one of understanding that no matter how much network + bandwidth you provide, bandwidth remains a precious resource. + + In this chapter, you must now consider how the overall network must + function. In particular, you must be concerned with users who move + between offices. You must take into account the way users need to + access information globally. And you must make the network robust + enough so that it can sustain partial breakdown without causing loss of + productivity. + + + Technical Issues + + There are at least three areas that need to be addressed as you + approach the challenge of designing a network solution for the newly + expanded business. These are: + + + + + mobility + + User needs such as mobility and data access + + + The nature of Windows networking protocols + + + Identity management infrastructure needs + + + + Let's look at each in turn. + + + User Needs + + The new company has three divisions. Staff for each division + are spread across the company. Some staff are office-bound and + some are mobile users. Mobile users travel globally. Some spend + considerable periods working in other offices. Everyone wants to be + able to work without constraint of productivity. + + The challenge is not insignificant. In some parts of the world, + even dial-up connectivity is poor, while in other regions political + encumbrances severely curtail user needs. Parts of the global + Internet infrastructure remain shielded-off for reasons outside + the scope of this discussion. + + + synchronize + + Decisions must be made regarding where data is to be stored, how + it will be replicated (if at all), and what the network bandwidth + implications are. For example, one decision that can be made is + to give each office its own master file storage area that can be + synchronized to a central repository in New York. This would permit + global data to be backed up from a single location. The + synchronization tool could be rsync, run via a + cron job. Mobile users may use off-line file storage under Windows + XP Professional. This way, they can synchronize all files that have + changed since each logon to the network. + + + bandwidth + requirements + + roaming profile + + No matter which way you look at this, the bandwidth requirements + for acceptable performance are substantial even if only 10 percent of + staff are global data users. A company with 3500 employees + and 280 of those were mobile users, and who used a similarly distributed + network, found they needed at least 2 Megabit/sec connectivity + between the UK and US offices. Even over 2 Mb/s bandwidth, this + company abandoned any attempt to run roaming profile usage for + mobile users. At that time, the average roaming profile took 480 + Kbytes, while today the minimum Windows XP Professional roaming + profile involves a transfer of over 750 Kbytes from the profile + server to/from the client. + + + wide-area + + Obviously then, user needs and wide-area practicalities + dictate the economic and technical aspects of your network + design as well as for standard operating procedures. + + + + + The Nature of Windows Networking Protocols + + + profile + mandatory + + Network logons that include roaming profile handling requires + from 140 Kbytes to 2 Mbytes. The inclusion of support for a minimal + set of common desktop applications can push the size of a complete + profile to over 15 Mbytes. This has substantial implications so far + as location of user profiles is concerned. Additionally, it is a + significant factor in determining the nature and style of mandatory + profiles that may be enforced as part of a total service level + assurance program that might be implemented. + + + logon traffic + + redirected folders + + One way to reduce the network bandwidth impact of user logon + traffic is through folder redirection. In Chapter 6, you + implemented this in the new Windows XP Professional standard + desktop configuration. When desktop folders such as My + Documents are redirected to a network drive, they should + also be excluded from synchronization to/from the server on + logon/out. Redirected folders are analogous to network drive + connections. + + + application servers + + Of course, network applications should only be run off + local application servers. As a general rule, even with 2 Mbit/sec + network bandwidth, it would not make sense at all for someone who + is working out of the London office to run applications off a + server that is located in New York. + + + affordability + + When network bandwidth becomes a precious commodity (that is most + of the time), there is a significant demand to understand network + processes and to mould the limits of acceptability around the + constraints of affordability. + + When a Windows NT4/200x/XP Professional client user logs onto + the network, several important things must happen. + + + + + DHCP + + The client obtains an IP address via DHCP. (DHCP is + necessary so that users can roam between offices.) + + + + WINS + + DNS + + The client must register itself with the WINS and/or DNS + server. + + + + Domain Controller + closest + + The client must locate the closest Domain Controller. + + + The client must log onto a Domain Controller and obtain as + part of that process the location of the user's profile, load + it, connect to redirected folders, and establish all network + drive and printer connections. + + + The Domain Controller must be able to resolve the user's + credentials before the logon process is fully implemented. + + + + Given that this book is about Samba and the fact that it + implements the Windows NT4 style domain semantics, it makes little + sense to compare Samba with Microsoft Active Directory insofar as + the logon protocols and principles of operation are + concerned. The following information pertains exclusively to the + interaction between a Windows XP Professional workstation and a + Samba-3.0.2 server. In the discussion that follows, use is made of + DHCP and WINS. + + As soon as the Windows workstation starts up, it obtains an + IP address. This is immediately followed by registration of its + name both by broadcast and Unicast registration that is directed + at the WINS server. + + + Unicast + + broadcast + directed + + NetBIOS + + Given that the client is already a Domain Member, it then sends + a directed (Unicast) request to the WINS server seeking the list of + IP addresses for domain controllers (NetBIOS name type 0x1C). The + WINS server replies with the information requested. + + + broadcast + mailslot + + Unicast + + WINS + + The client sends two netlogon mailslot broadcast requests + to the local network and to each of the IP addresses returned by + the WINS server. Whichever answers this request first appears to + be the machine that the Windows XP client attempts to use to + process the network logon. The mailslot messages use UDP broadcast + to the local network and UDP Unicast directed at each machine that + was listed in the WINS server response to a request for the list of + Domain Controllers. + + + protocol + negotiation + + logon server + + fail + + The logon process begins with negotiation of the SMB/CIFS + protocols that are to be used; this is followed by an exchange of + information that ultimately includes the client sending the + credentials with which the user is attempting to logon. The logon + server must now approve the further establishment of the + connection, but that is a good point to halt for now. The priority + here must center around identification of network infrastructure + needs. A secondary fact we need to know is, what happens when + local Domain Controllers fail or break? + + + Domain Controller + + PDC + + BDC + + netlogon + + Under most circumstances, the nearest Domain Controller + responds to the netlogon mailslot broadcast. The exception to this + norm occurs when the nearest Domain Controller is too busy or is out + of service. Herein lies an important fact. This means it is + important that every network segment should have at least two + Domain Controllers. Since there can be only one Primary Domain + Controller (PDC), all additional Domain Controllers are by definition + Backup Domain Controllers (BDCs). + + + authentication + + Identity Management + + The provision of sufficient servers that are BDCs is an + important design factor. The second important design factor + involves how each of the BDCs obtains user authentication + data. That is the subject of the next section as it involves key + decisions regarding Identity Management facilities. + + + + + Identity Management Needs + + + privacy + + user credentials + + validated + + privileges + + Network managers recognize that in large organizations users + generally need to be given resource access based on needs, while + being excluded from other resources for reasons of privacy. It is, + therefore, essential that all users identify themselves at the + point of network access. The network logon is the principal means + by which user credentials are validated and filtered, and appropriate + rights and privileges are allocated. + + + Identity Management + + Yellow Pages + + NIS + + Unfortunately, network resources tend to have their own Identity + Management facilities, the quality and manageability of which varies + from quite poor to exceptionally good. Corporations that use a mixture + of systems soon discover that until recently, few systems were + designed to interoperate. For example, UNIX systems each have an + independent user database. Sun Microsystems developed a facility that + was originally called Yellow Pages, and was renamed + when a telephone company objected to the use of its trademark. + What was once called Yellow Pages is today known + as Network Information System (NIS). + + + NIS+ + + NIS gained a strong following throughout the UNIX/VMS space in a + short period of time and retained that appeal and use + for over a decade. Security concerns as well as inherent limitations + have caused it to enter its twilight. NIS did not gain widespread + appeal outside of the UNIX world and was not universally + adopted. Sun updated this to a more secure implementation called + NIS+, but even it has fallen victim to changing demands as the + demand for directory services that can be coupled with other + information systems is catching on. + + + NIS + + government + + education + + Nevertheless, both NIS and NIS+ continue to hold ground in + business areas where UNIX still has major sway. Examples of + organizations that remain firmly attached to the use of NIS and + NIS+ includes large government departments, education institutions, + as well as large corporations that have a scientific or engineering + focus. + + + scalable + + distributed + + Today's networking world needs a scalable, distributed Identity + Management infrastructure, commonly called a directory. The most + popular technologies today are Microsoft Active Directory service + and a number of LDAP implementations. + + + multiple directories + + The problem of managing multiple directories has become a focal + point over the past decade. This has created a large market for + meta-directory products and services that allow organizations that + have multiple directories and multiple management and control + centers to provision information from one directory into + another. The attendant benefit to end users is the promise of + having to remember and deal with fewer login identities and + passwords. + + + network + bandwidth + + The challenge of every large network is to find the optimum + balance of internal systems and facilities for Identity + Management resources. How well the solution is chosen and + implemented has potentially significant impact on network bandwidth + and systems response needs. + + + LDAP server + + LDAP + master + + LDAP + slave + + In Chapter 6, you implemented a single LDAP server for the + entire network. This may work for smaller networks, but almost + certainly fails to meet the needs of large and complex networks. The + following section documents how one may implement a single + master LDAP server, with multiple slave servers. + + What is the best method for implementing master/slave LDAP + servers within the context of a distributed 2000 user network is a + question that remains to be answered. + + + distributed domain + + wide-area + + One possibility that has great appeal is to create one single + large distributed domain. The practical implications of this + design (see ) demands the placement of + sufficient BDCs in each location. Additionally, network + administrators must make sure that profiles are not transferred + over the wide-area links, except as a totally unavoidable + measure. Network design must balance the risk of loss of user + productivity against the cost of network management and + maintenance. + + + domain name space + + The network design in takes the + approach that management of networks that are too remote to be + capable of being managed effectively from New York ought + to be given a certain degree of autonomy. With this rationale, the + Los Angeles and London networks, though fully integrated with that + on the east coast of the USA, each have their own domain name space + and can be independently managed and controlled. One of the key + drawbacks of this design is that it flies in the face of the + ability for network users to roam globally without some compromise + in how they may access global resources. + + + interdomain trusts + + Desk-bound users need not be negatively affected by this + design, since the use of interdomain trusts can be used to satisfy + the need for global data sharing. + + + LDAP + + LDAP + backend + + SID + + When Samba-3 is configured to use an LDAP backend, it stores the domain + account information in a directory entry. This account entry contains + the domain SID. An unintended but exploitable side effect is that + this makes it possible to operate with more than one PDC on a + distributed network. + + + WINS + + wins.dat + + SID + + How might this peculiar feature be exploited? The answer is + simple. It is imperative that each network segment should have its + own WINS server. Major servers on remote network segments can be + given a static WINS entry in the wins.dat file + on each WINS server. This allows all essential data to be + visible from all locations. Each location would, however, function + as if it is an independent domain, while all sharing the same + domain SID. Since all domain account information can be stored in a + single LDAP backend, users have unfettered ability to + roam. + + + NetBIOS name + aliases + + fail-over + + This concept has not been exhaustively validated, though we can + see no reason why this should not work. The important facets + are: The name of the domain must be identical in all + locations. Each network segment must have its own WINS server. The + name of the PDC must be the same in all locations; this + necessitates the use of NetBIOS name aliases for each PDC so that + they can be accessed globally using the alias and not the PDC's + primary name. A single master LDAP server can be based in New York, + with multiple LDAP slave servers located on every network + segment. Finally, the BDCs should each use fail-over LDAP servers + that are in fact slave LDAP servers on the local segments. + + + LDAP + updates + + domain tree + + LDAP + database + + LDAP + directory + + With a single master LDAP server, all network updates are + effected on a single server. In the event that this should become + excessively fragile or network bandwidth limiting, one could + implement a delegated LDAP domain. This is also known as a + partitioned (or multiple partition) LDAP database + and as a distributed LDAP directory. + + As the LDAP directory grows, it becomes increasingly important + that its structure is implemented in a manner that mirrors + organizational needs, so as to limit network update and + referential traffic. It should be noted that all directory + administrators must of necessity follow the same standard + procedures for managing the directory, as retroactive correction of + inconsistent directory information can be exceedingly difficult. + +
+ Network Topology &smbmdash; 2000 User Complex Design A + + + + + + + + +
+ +
+ Network Topology &smbmdash; 2000 User Complex Design B + + + + + + + + +
+ + + + + + + + Political Issues + + As organizations grow, the number of points of control increase + also. In a large distributed organization, it is important that the + Identity Management system must be capable of being updated from + many locations, and it is equally important that changes made should + become capable of being used in a reasonable period, typically + minutes rather than days (the old limitation of highly manual + systems). + + + + + + + Implementation + + + winbind + + LDAP + + UID + + GID + + Samba-3 has the ability to use multiple password (authentication + and identity resolution) backends. The diagram in 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. + + +
+ Samba and Authentication Backend Search Pathways + + + + + + + + +
+ + + smbpasswd + + xmlsam + + SMB passwords + + tdbsam + + mysqlsam + + LDAP + + distributed + + 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. + + + passdb backend + + Additionally, it is possible to use multiple passdb backends + concurrently as well as have multiple LDAP backends. As a result, one + can specify a fail-over 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 + . +
+ Samba Configuration to Use a Single LDAP Server + + + + + + + + +
+ + LDAP + fail-over + + fail-over + + The addition of a fail-over LDAP server can simply be done by adding a + second entry for the fail-over 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 fail-over to a slave server if necessary, + as shown in . +
+ Samba Configuration to Use a Dual (Fail-over) LDAP Server + + + + + + + + +
+ + + Some folks have tried to implement this without the use of + double quotes as shown above. This is the type of entry they had + created: + +... +passdb backend = ldapsam:ldap://master.abmas.biz \ + ldapsam:ldap://slave.abmas.biz +... + + + contiguous directory + + 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 fail-over implementation. The net effect of this + configuration is shown in + + +
+ 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 . + + +
+ Samba Configuration to Use Two LDAP Databases - The result is additive. + + + + + + + + +
+ + + 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 so long as both are entirely separate from each other. + + + It is assumed that the network you are working with follows in a + pattern similar to what has been covered in Chapter 6. The following steps + permit the operation of a Master/Slave OpenLDAP arrangement. + + + + + + SUSE Linux + + Red Hat Linux + + 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: + +&rootprompt; rcldap stop + + On Red Hat Linux, you can do this by executing: + +&rootprompt; service ldap stop + + + + + /etc/openldap/slapd.conf + + Edit the /etc/openldap/slapd.conf file so it + matches the content of . + + + + LDIF + + LDAP + preload + + 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: + +&rootprompt; slapcat -v -l LDAP-transfer-LDIF.txt + + Each record is written to the file. + + + + LDAP-transfer-LDIF.txt + + Copy the file LDAP-transfer-LDIF.txt to the intended + slave LDAP server. A good location could be in the directory + /etc/openldap/preload. + + + + 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 . + + + + Change directory to the location in which you stored the + LDAP-transfer-LDIF.txt file (/etc/openldap/preload). + While in this directory, execute: + +&rootprompt; 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) + + + + + Now start the LDAP server and set it to run automatically on system reboot + by executing: + +&rootprompt; rcldap start +&rootprompt; chkconfig ldap on + + On Red Hat Linux, you would execute the following: + +&rootprompt; service ldap start +&rootprompt; chkconfig ldap on + + + chkconfig + + service + + rcldap + + + + + Go back to the master LDAP server. Execute the following to start LDAP as well + as slurpd, the synchronization daemon, as shown here: + +&rootprompt; rcldap start +&rootprompt; chkconfig ldap on +&rootprompt; slurpd start +&rootprompt; chkconfig slurpd on + + + slurpd + + On Red Hat Linux, check the equivalent command to start slurpd. + + + + smbldap-useradd.pl + + On the master slave server you may now add an account to validate that replication + is working. Assuming the configuration shown in Chapter 6, execute: + +&rootprompt; /var/lib/samba/sbin/smbldap-useradd.pl -a fruitloop + + + + + 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 +- + + + + + Given that this first slave LDAP server is now working correctly, you may now + implement additional slave LDAP servers as required. + + + + + +LDAP Master Server Configuration File &smbmdash; <filename>/etc/openldap/slapd.conf</filename> + +include /etc/openldap/schema/core.schema +include /etc/openldap/schema/cosine.schema +include /etc/openldap/schema/inetorgperson.schema +include /etc/openldap/schema/nis.schema +include /etc/openldap/schema/samba.schema + +pidfile /var/run/slapd/slapd.pid +argsfile /var/run/slapd/slapd.args + +database ldbm +suffix "dc=abmas,dc=biz" +rootdn "cn=Manager,dc=abmas,dc=biz" + +# rootpw = not24get +rootpw {SSHA}86kTavd9Dw3FAz6qzWTrCOKX/c0Qe+UV + +replica host=lapdc.abmas.biz:389 + suffix="dc=abmas,dc=biz" + binddn="cn=updateuser,dc=abmas,dc=biz" + bindmethod=simple credentials=not24get + +access to attrs=sambaLMPassword,sambaNTPassword + by dn="cn=updateuser,dc=abmas,dc=biz" write + by * none + +replogfile /var/lib/ldap/replogfile + +directory /var/lib/ldap + +# Indices to maintain +index objectClass eq +index cn pres,sub,eq +index sn pres,sub,eq +index uid pres,sub,eq +index displayName pres,sub,eq +index uidNumber eq +index gidNumber eq +index memberUID eq +index sambaSID eq +index sambaPrimaryGroupSID eq +index sambaDomainName eq +index default sub + + + + +LDAP Slave Configuration File &smbmdash; <filename>/etc/openldap/slapd.conf</filename> + +include /etc/openldap/schema/core.schema +include /etc/openldap/schema/cosine.schema +include /etc/openldap/schema/inetorgperson.schema +include /etc/openldap/schema/nis.schema +include /etc/openldap/schema/samba.schema + +pidfile /var/run/slapd/slapd.pid +argsfile /var/run/slapd/slapd.args + +database ldbm +suffix "dc=abmas,dc=biz" +rootdn "cn=Manager,dc=abmas,dc=biz" + +# rootpw = not24get +rootpw {SSHA}86kTavd9Dw3FAz6qzWTrCOKX/c0Qe+UV + +access to * + by dn=cn=updateuser,dc=abmas,dc=biz write + by * read + +updatedn cn=updateuser,dc=abmas,dc=biz +updateref ldap://massive.abmas.biz +replogfile /var/lib/ldap/replogfile + +directory /var/lib/ldap + +# Indices to maintain +index objectClass eq +index cn pres,sub,eq +index sn pres,sub,eq +index uid pres,sub,eq +index displayName pres,sub,eq +index uidNumber eq +index gidNumber eq +index memberUID eq +index sambaSID eq +index sambaPrimaryGroupSID eq +index sambaDomainName eq +index default sub + + + + +Primary Domain Controller &smb.conf; File &smbmdash; Part A +Global parameters +[global] +unix charsetLOCALE +workgroupMEGANET2 +passdb backendldapsam:ldap://massive.abmas.biz +username map/etc/samba/smbusers +log level1 +syslog0 +log file/var/log/samba/%m +max log size0 +smb ports139 445 +name resolve orderwins bcast hosts +time serverYes +printcap nameCUPS +add user script/var/lib/samba/sbin/smbldap-useradd.pl -a -m '%u' +delete user script/var/lib/samba/sbin/smbldap-userdel.pl %u +add group script/var/lib/samba/sbin/smbldap-groupadd.pl -p '%g' +delete group script/var/lib/samba/sbin/smbldap-groupdel.pl '%g' +add user to group script/var/lib/samba/sbin/ +smbldap-groupmod.pl -m '%g' '%u' +delete user from group script/var/lib/samba/sbin/ +smbldap-groupmod.pl -x '%g' '%u' +set primary group script/var/lib/samba/sbin/ +smbldap-usermod.pl -g '%g' '%u' +add machine script/var/lib/samba/sbin/ +smbldap-useradd.pl -w '%u' +shutdown script/var/lib/samba/scripts/shutdown.sh +abort shutdown script/sbin/shutdown -c +logon scriptscripts\logon.bat +logon path\\%L\profiles\%U +logon driveX: +domain logonsYes +domain masterYes +wins supportYes +ldap suffixdc=abmas,dc=biz +ldap machine suffixou=People +ldap user suffixou=People +ldap group suffixou=Groups +ldap idmap suffixou=Idmap +ldap admin dncn=Manager,dc=abmas,dc=biz +idmap backendldap://massive.abmas.biz +idmap uid10000-20000 +idmap gid10000-20000 +printer adminroot +printingcups + + + +Primary Domain Controller &smb.conf; File &smbmdash; Part B +[IPC$] +path/tmp + +[accounts] +commentAccounting Files +path/data/accounts +read onlyNo + +[service] +commentFinancial Services Files +path/data/service +read onlyNo + +[pidata] +commentProperty Insurance Files +path/data/pidata +read onlyNo + +[homes] +commentHome Directories +valid users%S +read onlyNo +browseableNo + +[printers] +commentSMB Print Spool +path/var/spool/samba +guest okYes +printableYes +browseableNo + + + +Primary Domain Controller &smb.conf; File &smbmdash; Part C +[apps] +commentApplication Files +path/apps +admin usersbjones +read onlyNo + +[netlogon] +commentNetwork Logon Service +path/var/lib/samba/netlogon +admin usersroot, Administrator +guest okYes +lockingNo + +[profiles] +commentProfile Share +path/var/lib/samba/profiles +read onlyNo +profile aclsYes + +[profdata] +commentProfile Data Share +path/var/lib/samba/profdata +read onlyNo +profile aclsYes + +[print$] +commentPrinter Drivers +path/var/lib/samba/drivers +write listroot +admin usersroot, Administrator + + + +Backup Domain Controller &smb.conf; File &smbmdash; Part A +# Global parameters +[global] +unix charsetLOCALE +workgroupMEGANET2 +netbios nameBLDG1 +passdb backendldapsam:ldap://lapdc.abmas.biz +username map/etc/samba/smbusers +log level1 +syslog0 +log file/var/log/samba/%m +max log size50 +smb ports139 445 +name resolve orderwins bcast hosts +printcap nameCUPS +show add printer wizardNo +logon scriptscripts\logon.bat +logon path\\%L\profiles\%U +logon driveX: +domain logonsYes +os level63 +domain masterNo +wins server192.168.2.1 +ldap suffixdc=abmas,dc=biz +ldap machine suffixou=People +ldap user suffixou=People +ldap group suffixou=Groups +ldap idmap suffixou=Idmap +ldap admin dncn=Manager,dc=abmas,dc=biz +utmpYes +idmap backendldap://massive.abmas.biz +idmap uid10000-20000 +idmap gid10000-20000 +printingcups + +[accounts] +commentAccounting Files +path/data/accounts +read onlyNo + +[service] +commentFinancial Services Files +path/data/service +read onlyNo + + + +Backup Domain Controller &smb.conf; File &smbmdash; Part B +[pidata] +commentProperty Insurance Files +path/data/pidata +read onlyNo + +[homes] +commentHome Directories +valid users%S +read onlyNo +browseableNo + +[printers] +commentSMB Print Spool +path/var/spool/samba +guest okYes +printableYes +browseableNo + +[apps] +commentApplication Files +path/apps +admin usersbjones +read onlyNo + +[netlogon] +commentNetwork Logon Service +path/var/lib/samba/netlogon +guest okYes +lockingNo + +[profiles] +commentProfile Share +path/var/lib/samba/profiles +read onlyNo +profile aclsYes + +[profdata] +commentProfile Data Share +path/var/lib/samba/profdata +read onlyNo +profile aclsYes + + + + Key Points Learned + + + + + + + LDAP + + BDC + + Where Samba-3 is used as a Domain Controller, the use of LDAP is an + essential component necessary to permit the use of BDCs. + + + + wide-area + + Replication of the LDAP master server to create a network of BDCs + is an important mechanism for limiting wide-area network 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. + + + + + + + + + Questions and Answers + + + There is much rumor and misinformation regarding the use of MS Windows networking protocols. + These questions are just a few of those frequently asked. + + + + + + + + DHCP + + network + bandwidth + + Is it true that DHCP uses lots of wide-area network bandwidth? + + + + + + + DHCP + Relay Agent + + routers + + DHCP + servers + + It is a smart practice to localize DHCP servers on each network segment. As a + rule, there should be two DHCP servers per network segment. This means that if + one server fails, there is always another to service user needs. DHCP requests use + only UDP broadcast protocols. It is possible to run a DHCP Relay Agent on network + routers. This makes it possible to run fewer DHCP servers. + + + + DHCP + request + + DHCP + traffic + + A DHCP network address request and confirmation usually results in about six UDP packets. + The packets are from 60 to 568 bytes in length. Let us consider a site that has 300 DHCP + clients and that uses a 24-hour IP address lease. This means that all clients renew + their IP address lease every 24 hours. If we assume an average packet length equal to the + maximum (just to be on the safe side), and we have a 128 Kbit/sec wide-area connection, + how significant would the DHCP traffic be if all of it were to use DHCP Relay? + + + + I must stress that this is a bad design, but here is the calculation: + +Daily Network Capacity: 128,000 (Kbits/s) / 8 (bits/byte) + x 3600 (sec/hr) x 24 (hrs/day)= 2288 Mbytes/day. + +DHCP traffic: 300 (clients) x 6 (packets) + x 512 (bytes/packet) = 0.9 Mbytes/day. + + From this can be seen that the traffic impact would be minimal. + + + + DNS + Dynamic + + DHCP + + Even when DHCP is configured to do DNS update (Dynamic DNS) over a wide-area link, + the impact of the update is no more than the DHCP IP address renewal traffic and, thus, + still insignificant for most practical purposes. + + + + + + + + + + background communication + + LDAP + master/slave + background communication + + How much background communication takes place between a Master LDAP + server and its slave LDAP servers? + + + + + + + slurpd + + The process that controls the replication of data from the Master LDAP server to the Slave LDAP + servers is called slurpd. The slurpd remains nascent (quiet) + until an update must be propagated. The propagation traffic per LDAP salve to update (add/modify/delete) + two user accounts requires less than 10Kbytes traffic. + + + + + + + + + + LDAP has a database. Is LDAP not just a fancy database front end? + + + + + + + database + + LDAP + database + + SQL + + transactional + + LDAP does store its data in a database of sorts. In fact the LDAP backend is an application-specific + data storage system. This type of database is indexed so that records can be rapidly located, but the + database is not generic and can be used only in particular pre-programmed ways. General external + applications do not gain access to the data. This type of database is used also by SQL servers. Both + an SQL server and an LDAP server provide ways to access the data. An SQL server has a transactional + orientation and typically allows external programs to perform ad-hoc queries, even across data tables. + An LDAP front end is a purpose-built tool that has a search orientation that is designed around specific + simple queries. The term database is heavily overloaded and, thus, much misunderstood. + + + + + + + + + + OpenLDAP + + Can Active Directory obtain account information from an OpenLDAP server? + + + + + + + meta-directory + + No, at least not directly. It is possible to provision Active Directory from/to an OpenLDAP + database through use of a meta-directory server. Microsoft MMS (now called MIIS) can interface + to OpenLDAP using standard LDAP queries/updates. + + + + + + + + + + What are the parts of a roaming profile? How large is each part? + + + + + + + roaming profile + + A roaming profile consists of: + + + + + Desktop folders such as: Desktop, My Documents, My Pictures, My Music, Internet Files, + Cookies, Application Data, Local Settings, and more. See . + + + + folder redirection + + Each of these can be anywhere from a few bytes to gigabytes in capacity. Fortunately, all + such folders can be redirected to network drive resources. See + for more information regarding folder redirection. + + + + A static or re-writable portion that is typically only a few files (2-5 Kbytes of information). + + + + NTUSER.DAT + + HKEY_LOCAL_USER + + The registry load file that modifies the HKEY_LOCAL_USER hive. This is + the NTUSER.DAT file. It can be from 0.4-1.5 MBytes. + + + + + Microsoft Outlook + PST files + + Microsoft Outlook PST files may be stored in the Local Settings\Application Data + folder. It can be up to 2 Gbytes in size per PST file. + + + + + + + + + + Can the My Documents folder be stored on a network drive? + + + + + + + UNC name + + Universal Naming Convention + UNC name + + Yes. More correctly, such folders can be redirected to network shares. No specific network drive + connection is required. Registry settings permit this to be redirected directly to a UNC (Universal + Naming Convention) resource, though it is possible to specify a network drive letter instead of a + UNC name. See . + + + + + + + + + + wide-area + + network + bandwidth + + WINS + + How much wide-area network bandwidth does WINS consume? + + + + + + + NetBIOS + name cache + + WINS server + + domain replication + + MS Windows clients cache information obtained from WINS lookups in a local NetBIOS name cache. + This keeps WINS lookups to a minimum. On a network with 3500 MS Windows clients and a central WINS + server, the total bandwidth demand measured at the WINS server, averaged over an eight-hour working day, + was less than 30 Kbytes/sec. Analysis of network traffic over a six-week period showed that the total + of all background traffic consumed about 11 percent of available bandwidth over 64 Kbit/sec links. + Back-ground traffic consisted of domain replication, WINS queries, DNS lookups, authentication + traffic. Each of 11 branch offices had a 64 Kbit/sec wide-area link, with a 1.5 Mbit/sec main connection + that aggregated the branch office connections plus an Internet connection. + + + + In conclusion, the total load afforded through WINS traffic is again marginal to total operational + usage &smbmdash; as it should be. + + + + + + + + + + How many BDCs should I have? What is the right number of Windows clients per server? + + + + + + + It is recommended to have at least one BDC per network segment, including the segment served + by the PDC. Actual requirements vary depending on the working load on each of the BDCs and the + load demand pattern of client usage. I have seen sites that function without problem with 200 + clients served by one BDC, and yet other sites that had one BDC per 20 clients. In one particular + company, there was a drafting office that has 30 CAD/CAM operators served by one server, a print + server; and an application server. While all three were BDCs, typically only the print server would + service network logon requests after the first 10 users had started to use the network. This was + a reflection of the service load placed on both the application server and the data server. + + + + As unsatisfactory as the answer might sound, it all depends on network and server load + characteristics. + + + + + + + + + + NIS server + + LDAP + + I've heard that you can store NIS accounts in LDAP. Is LDAP not just a smarter way to + run an NIS server? + + + + + + + The correct answer to both questions is yes. But do understand that an LDAP server has + a configurable schema that can store far more information for many more purposes than + just NIS. + + + + + + + + + + Can I use NIS in place of LDAP? + + + + + + + NIS + + NIS schema + + No. The NIS database does not have provision to store Microsoft encrypted passwords and does not deal + with the types of data necessary for interoperability with Microsoft Windows networking. The use + of LDAP with Samba requires the use of a number of schemas, one of which is the NIS schema, but also + a Samba-specific schema extension. + + + + + + + + + + + -- cgit