Begin of another reorg.
[tprouty/samba.git] / docs / Samba-Guide / SBE-2000UserNetwork.xml
1 <?xml version="1.0" encoding="iso-8859-1"?>
2 <!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
3 <chapter id="2000users">
4   <title>A Distributed 2000 User Network</title>
5
6     <para>There is something indeed mystical about things that are
7       big. Large networks exhibit a certain magnetism and exude a sense of
8       importance that obscures reality. You and I know that it is no more
9       difficult to secure a large network than it is a small one. We all
10       know that over and above a particular number of network clients, the
11       rules no longer change; the only real dynamic is the size of the domain
12       (much like a kingdom) over which the network ruler (oops, administrator)
13       has control. The real dynamic then transforms from the technical to the
14       political. Then again, that point is often reached well before the
15       kingdom (or queendom) grows large.</para>
16
17     <para>If you have systematically worked your way to this chapter, hopefully you
18       have found some gems and techniques that are applicable in your
19       world. The network designs you have worked with in this book with have their
20       strong points as well as weak ones. That is to be expected given that
21       they are based on real business environments, excepting that the facts
22       have been moulded to serve the purposes of this book.</para>
23
24     <para>This chapter is intent on wrapping up issues that are central to
25     implementation and design of progressively larger networks. Are you ready
26     for this chapter? Good, it is time to move on.</para>
27
28     <para>In previous chapters, you made the assumption that your network
29       administration staff need detailed instruction right down to the
30       nuts-and-bolts of implementing the solution. That's is still the case,
31       but they have graduated now. You decide to document only those issues,
32       methods and techniques that are new or complex. Routine tasks such as
33       implementing a DNS or a DHCP server are under control. Even the basics of
34       Samba are largely under control. So in this section you focus on the
35       specifics of implementing LDAP changes, Samba changes, and approach and
36       design of the solution and its deployment.</para>
37
38 <sect1>
39         <title>Introduction</title>
40
41         <para>
42         Abmas is a miracle company. Most businesses would have collapsed under
43         the weight of rapid expansion that this company has experienced. Samba 
44         is flexible, so there is no need to reinstall the whole operating 
45         system just because you need to implement a new network design. In fact, 
46         you can keep an old server running right up to the moment of cut-over 
47         and then do a near-live conversion. There is no need to reinstall a 
48         Samba server just to change the way your network should function.
49         </para>
50
51       <para><indexterm>
52           <primary>LDAP</primary>
53         </indexterm>
54         Network growth is common to all organizations. In this exercise,
55         your preoccupation is with the mechanics of implementing Samba and
56         LDAP so that network users on each network segment can work
57         without impediment.</para>
58
59         <sect2>
60                 <title>Assignment Tasks</title>
61
62         <para>
63           Starting with the configuration files for the server called
64           <constant>MASSIVE</constant> in Chapter 6, you now deal with the
65           issues that are particular to large distributed networks. Your task
66           is simple &smbmdash; identify the challenges, consider the 
67           alternatives, and then design and implement a solution.</para>
68
69         <para><indexterm>
70             <primary>VPN</primary>
71           </indexterm>
72           Remember, you have users based in London (UK), Los Angeles,
73           Washington DC, and three buildings in New York. A significant portion
74           of your workforce have notebook computers and roam all over the
75           world. Some dial into the office, others use VPN connections over the
76           Internet and others just move between buildings.</para>
77
78         <para>What do you say to an employee who normally uses a desktop
79           system but must spend six weeks on the road with a notebook computer?
80           She is concerned over email access and how to keep co-workers current
81           with changing documents.</para>
82
83         <para>To top it all off, you have one network support person and one 
84           Help desk person based in London, a single person dedicated to all 
85           network operations in Los Angeles, five staff for user administration 
86           and Help desk in New York, plus one <emphasis>floater</emphasis> for 
87           Washington DC.</para>
88
89         <para>You have outsourced all desktop deployment and management to
90           DirectPointe,Inc. Your concern is server maintenance and third-level
91           support. Build a plan and show what must be done.</para>
92
93         </sect2>
94 </sect1>
95
96 <sect1>
97         <title>Dissection and Discussion</title>
98
99       <para><indexterm>
100           <primary>passdb backend</primary>
101         </indexterm><indexterm>
102           <primary>LDAP</primary>
103         </indexterm>
104         In the previous chapter, you implemented an LDAP server that provided the
105         <parameter>passdb backend</parameter> for the Samba servers. You
106         explored ways to accelerate Windows desktop profile handling and you
107         took control of network performance.
108         </para>
109
110       <para><indexterm>
111           <primary>ldapsam</primary>
112         </indexterm><indexterm>
113           <primary>tdbsam</primary>
114         </indexterm><indexterm>
115           <primary>smbpasswd</primary>
116         </indexterm><indexterm>
117           <primary>replicated</primary>
118         </indexterm>
119         The implementation of an LDAP-based passdb backend (known as
120         <emphasis>ldapsam</emphasis> in Samba parlance), or some form of database
121         that can be distributed, is essential to permit the deployment of Samba
122         Primary and Backup Domain Controllers (PDC/BDCs). You see, the problem
123         is that the <emphasis>tdbsam</emphasis> style passdb backend does not
124         lend itself to being replicated. The older plain-text-based
125         <emphasis>smbpasswd</emphasis> style passdb backend can be replicated
126         using a tool such as <command>rsync</command>, but
127         <emphasis>smbpasswd</emphasis> suffers the drawback that it does not
128         support the range of account facilities demanded by modern network
129         managers.</para>
130
131       <para><indexterm>
132           <primary>XML</primary>
133         </indexterm><indexterm>
134           <primary>SQL</primary>
135         </indexterm>
136         The new <emphasis>tdbsam</emphasis> facility supports functionality
137         that is similar to an <emphasis>ldapsam</emphasis>, but the lack of
138         distributed infrastructure sorely limits the scope for its
139         deployment. This does raise the following questions: "Why can't I just use
140         an XML based backend, or for that matter, why not use an SQL based
141         backend?" "Is support for these tools broken?" No. Answers to these
142         questions require a bit of background.</para>
143
144       <para><indexterm>
145           <primary>directory</primary>
146         </indexterm><indexterm>
147           <primary>database</primary>
148         </indexterm><indexterm>
149           <primary>transaction processing</primary>
150         </indexterm><indexterm>
151           <primary>LDAP</primary>
152         </indexterm>
153         <emphasis>What is a directory?</emphasis> A directory is a
154         collection of information regarding objects that can be accessed to
155         rapidly find information that is relevant in a particular and
156         consistent manner. A directory differs from a database in that it is
157         generally more often searched (read) than updated. As a consequence, the
158         information is organized to facilitate read access rather than to
159         support transaction processing.</para>
160
161       <para><indexterm>
162           <primary>Lightweight Directory Access Protocol </primary>
163           <see>LDAP</see>
164         </indexterm><indexterm>
165           <primary>LDAP</primary>
166         </indexterm><indexterm>
167           <primary>master</primary>
168         </indexterm><indexterm>
169           <primary>slave</primary>
170         </indexterm>
171         The Lightweight Directory Access Protocol (LDAP) differs
172         considerably from a traditional database. It has a simple search
173         facility that uniquely makes a highly preferred mechanism for managing
174         user identities. LDAP provides a scalable mechanism for distributing
175         the data repository and for keeping all copies (slaves) in sync with
176         the master repository.</para>
177
178       <para><indexterm>
179           <primary>identity management</primary>
180         </indexterm><indexterm>
181           <primary>Active Directory</primary>
182         </indexterm><indexterm>
183           <primary>OpenLDAP</primary>
184         </indexterm>
185         Samba is a flexible and powerful file and print sharing
186         technology. It can use many external authentication sources and can be
187         part of a total authentication and identity management
188         infrastructure. The two most important external sources for large sites
189         are Microsoft Active Directory and LDAP. Sites that specifically wish to
190         avoid the proprietary implications of Microsoft Active Directory
191         naturally gravitate toward OpenLDAP.</para>
192
193       <para><indexterm>
194           <primary>network</primary>
195           <secondary>routed</secondary>
196         </indexterm>
197         In Chapter 6, you had to deal with a locally routed
198         network. All deployment concerns focused around making users happy,
199         and that simply means taking control over all network practices and
200         usage so that no one user is disadvantaged by any other. The real
201         lesson is one of understanding that no matter how much network
202         bandwidth you provide, bandwidth remains a precious resource.</para>
203
204       <para>In this chapter, you must now consider how the overall network must
205         function. In particular, you must be concerned with users who move
206         between offices. You must take into account the way users need to
207         access information globally. And you must make the network robust
208         enough so that it can sustain partial breakdown without causing loss of
209         productivity.</para>
210
211         <sect2>
212                 <title>Technical Issues</title>
213
214         <para>There are at least three areas that need to be addressed as you
215           approach the challenge of designing a network solution for the newly
216           expanded business. These are:</para>
217
218         <itemizedlist>
219           <listitem>
220             <para><indexterm>
221                 <primary>mobility</primary>
222               </indexterm>
223               User needs such as mobility and data access</para>
224           </listitem>
225           <listitem>
226             <para>The nature of Windows networking protocols</para>
227           </listitem>
228           <listitem>
229             <para>Identity management infrastructure needs</para>
230           </listitem>
231         </itemizedlist>
232
233         <para>Let's look at each in turn.</para>
234
235         <sect3>
236           <title>User Needs</title>
237
238           <para>The new company has three divisions. Staff for each division
239             are spread across the company. Some staff are office-bound and
240             some are mobile users. Mobile users travel globally. Some spend
241             considerable periods working in other offices. Everyone wants to be
242             able to work without constraint of productivity.</para>
243
244           <para>The challenge is not insignificant. In some parts of the world,
245             even dial-up connectivity is poor, while in other regions political
246             encumbrances severely curtail user needs. Parts of the global
247             Internet infrastructure remain shielded-off for reasons outside 
248             the scope of this discussion.</para>
249
250           <para><indexterm>
251               <primary>synchronize</primary>
252             </indexterm>
253             Decisions must be made regarding where data is to be stored, how
254             it will be replicated (if at all), and what the network bandwidth
255             implications are. For example, one decision that can be made is
256             to give each office its own master file storage area that can be
257             synchronized to a central repository in New York. This would permit
258             global data to be backed up from a single location. The
259             synchronization tool could be <command>rsync,</command> run via a
260             cron job. Mobile users may use off-line file storage under Windows
261             XP Professional. This way, they can synchronize all files that have
262             changed since each logon to the network.</para>
263
264           <para><indexterm>
265               <primary>bandwidth</primary>
266               <secondary>requirements</secondary>
267             </indexterm><indexterm>
268               <primary>roaming profile</primary>
269             </indexterm>
270             No matter which way you look at this, the bandwidth requirements
271             for acceptable performance are substantial even if only 10 percent of
272             staff are global data users. A company with 3500 employees
273             and 280 of those were mobile users, and who used a similarly distributed
274             network, found they needed at least 2 Megabit/sec connectivity
275             between the UK and US offices. Even over 2 Mb/s bandwidth, this
276             company abandoned any attempt to run roaming profile usage for
277             mobile users. At that time, the average roaming profile took 480
278             Kbytes, while today the minimum Windows XP Professional roaming
279             profile involves a transfer of over 750 Kbytes from the profile
280             server to/from the client.</para>
281
282           <para><indexterm>
283               <primary>wide-area</primary>
284             </indexterm>
285             Obviously then, user needs and wide-area practicalities
286             dictate the economic and technical aspects of your network
287             design as well as for standard operating procedures.</para>
288
289         </sect3>
290
291         <sect3>
292           <title>The Nature of Windows Networking Protocols</title>
293
294           <para><indexterm>
295               <primary>profile</primary>
296               <secondary>mandatory</secondary>
297             </indexterm>
298             Network logons that include roaming profile handling requires
299             from 140 Kbytes to 2 Mbytes. The inclusion of support for a minimal
300             set of common desktop applications can push the size of a complete
301             profile to over 15 Mbytes. This has substantial implications so far
302             as location of user profiles is concerned. Additionally, it is a
303             significant factor in determining the nature and style of mandatory
304             profiles that may be enforced as part of a total service level
305             assurance program that might be implemented.</para>
306
307           <para><indexterm>
308               <primary>logon traffic</primary>
309             </indexterm><indexterm>
310               <primary>redirected folders</primary>
311             </indexterm>
312             One way to reduce the network bandwidth impact of user logon
313             traffic is through folder redirection. In Chapter 6, you
314             implemented this in the new Windows XP Professional standard
315             desktop configuration. When desktop folders such as <guimenu>My
316             Documents</guimenu> are redirected to a network drive, they should
317             also be excluded from synchronization to/from the server on
318             logon/out. Redirected folders are analogous to network drive
319             connections.</para>
320
321           <para><indexterm>
322               <primary>application servers</primary>
323             </indexterm>
324             Of course, network applications should only be run off
325             local application servers. As a general rule, even with 2 Mbit/sec
326             network bandwidth, it would not make sense at all for someone who
327             is working out of the London office to run applications off a
328             server that is located in New York.</para>
329
330           <para><indexterm>
331               <primary>affordability</primary>
332             </indexterm>
333             When network bandwidth becomes a precious commodity (that is most
334             of the time), there is a significant demand to understand network
335             processes and to mould the limits of acceptability around the
336             constraints of affordability.</para>
337
338           <para>When a Windows NT4/200x/XP Professional client user logs onto
339             the network, several important things must happen.</para>
340
341           <itemizedlist>
342             <listitem>
343               <para><indexterm>
344                   <primary>DHCP</primary>
345                 </indexterm>
346                 The client obtains an IP address via DHCP. (DHCP is
347                 necessary so that users can roam between offices.)</para>
348             </listitem>
349             <listitem>
350               <para><indexterm>
351                   <primary>WINS</primary>
352                 </indexterm><indexterm>
353                   <primary>DNS</primary>
354                 </indexterm>
355                 The client must register itself with the WINS and/or DNS
356                 server.</para>
357             </listitem>
358             <listitem>
359               <para><indexterm>
360                   <primary>Domain Controller</primary>
361                   <secondary>closest</secondary>
362                 </indexterm>
363                 The client must locate the closest Domain Controller.</para>
364             </listitem>
365             <listitem>
366               <para>The client must log onto a Domain Controller and obtain as
367                 part of that process the location of the user's profile, load
368                 it, connect to redirected folders, and establish all network
369                 drive and printer connections.</para>
370             </listitem>
371             <listitem>
372               <para>The Domain Controller must be able to resolve the user's
373                 credentials before the logon process is fully implemented.</para>
374             </listitem>
375           </itemizedlist>
376
377           <para>Given that this book is about Samba and the fact that it
378             implements the Windows NT4 style domain semantics, it makes little
379             sense to compare Samba with Microsoft Active Directory insofar as
380             the logon protocols and principles of operation are
381             concerned. The following information pertains exclusively to the
382             interaction between a Windows XP Professional workstation and a
383             Samba-3.0.12 server. In the discussion that follows, use is made of
384             DHCP and WINS.</para>
385
386           <para>As soon as the Windows workstation starts up, it obtains an
387             IP address. This is immediately followed by registration of its
388             name both by broadcast and Unicast registration that is directed
389             at the WINS server.</para>
390
391           <para><indexterm>
392               <primary>Unicast</primary>
393             </indexterm><indexterm>
394               <primary>broadcast</primary>
395               <secondary>directed</secondary>
396             </indexterm><indexterm>
397               <primary>NetBIOS</primary>
398             </indexterm>
399             Given that the client is already a Domain Member, it then sends
400             a directed (Unicast) request to the WINS server seeking the list of
401             IP addresses for domain controllers (NetBIOS name type 0x1C). The
402             WINS server replies with the information requested.</para>
403
404           <para><indexterm>
405               <primary>broadcast</primary>
406               <secondary>mailslot</secondary>
407             </indexterm><indexterm>
408               <primary>Unicast</primary>
409             </indexterm><indexterm>
410               <primary>WINS</primary>
411             </indexterm>
412             The client sends two netlogon mailslot broadcast requests
413             to the local network and to each of the IP addresses returned by
414             the WINS server. Whichever answers this request first appears to
415             be the machine that the Windows XP client attempts to use to
416             process the network logon. The mailslot messages use UDP broadcast
417             to the local network and UDP Unicast directed at each machine that
418             was listed in the WINS server response to a request for the list of
419             Domain Controllers.</para>
420
421           <para><indexterm>
422               <primary>protocol</primary>
423               <secondary>negotiation</secondary>
424             </indexterm><indexterm>
425               <primary>logon server</primary>
426             </indexterm><indexterm>
427               <primary>fail</primary>
428             </indexterm>
429             The logon process begins with negotiation of the SMB/CIFS
430             protocols that are to be used; this is followed by an exchange of
431             information that ultimately includes the client sending the
432             credentials with which the user is attempting to logon. The logon
433             server must now approve the further establishment of the
434             connection, but that is a good point to halt for now. The priority
435             here must center around identification of network infrastructure
436             needs. A secondary fact we need to know is, what happens when
437             local Domain Controllers fail or break?</para>
438
439           <para><indexterm>
440               <primary>Domain Controller</primary>
441             </indexterm><indexterm>
442               <primary>PDC</primary>
443             </indexterm><indexterm>
444               <primary>BDC</primary>
445             </indexterm><indexterm>
446               <primary>netlogon</primary>
447             </indexterm>
448             Under most circumstances, the nearest Domain Controller
449             responds to the netlogon mailslot broadcast. The exception to this
450             norm occurs when the nearest Domain Controller is too busy or is out
451             of service. Herein lies an important fact. This means it is
452             important that every network segment should have at least two
453             Domain Controllers. Since there can be only one Primary Domain
454             Controller (PDC), all additional Domain Controllers are by definition
455             Backup Domain Controllers (BDCs).</para>
456
457           <para><indexterm>
458               <primary>authentication</primary>
459             </indexterm><indexterm>
460               <primary>Identity Management</primary>
461             </indexterm>
462             The provision of sufficient servers that are BDCs is an
463             important design factor. The second important design factor
464             involves how each of the BDCs obtains user authentication
465             data. That is the subject of the next section as it involves key
466             decisions regarding Identity Management facilities.</para>
467
468         </sect3>
469
470         <sect3>
471           <title>Identity Management Needs</title>
472
473           <para><indexterm>
474               <primary>privacy</primary>
475             </indexterm><indexterm>
476               <primary>user credentials</primary>
477             </indexterm><indexterm>
478               <primary>validated</primary>
479             </indexterm><indexterm>
480               <primary>privileges</primary>
481             </indexterm>
482             Network managers recognize that in large organizations users
483             generally need to be given resource access based on needs, while
484             being excluded from other resources for reasons of privacy. It is,
485             therefore, essential that all users identify themselves at the
486             point of network access. The network logon is the principal means
487             by which user credentials are validated and filtered, and appropriate
488             rights and privileges are allocated.</para>
489
490           <para><indexterm>
491               <primary>Identity Management</primary>
492             </indexterm><indexterm>
493               <primary>Yellow Pages</primary>
494             </indexterm><indexterm>
495               <primary>NIS</primary>
496             </indexterm>
497             Unfortunately, network resources tend to have their own Identity 
498             Management facilities, the quality and manageability of which varies 
499             from quite poor to exceptionally good. Corporations that use a mixture 
500             of systems soon discover that until recently, few systems were 
501             designed to interoperate. For example, UNIX systems each have an 
502             independent user database. Sun Microsystems developed a facility that 
503             was originally called <constant>Yellow Pages</constant>, and was renamed 
504             when a telephone company objected to the use of its trademark. 
505             What was once called <constant>Yellow Pages</constant> is today known 
506             as <constant>Network Information System</constant> (NIS).</para>
507
508           <para><indexterm>
509               <primary>NIS+</primary>
510             </indexterm>
511             NIS gained a strong following throughout the UNIX/VMS space in a
512             short period of time and retained that appeal and use
513             for over a decade. Security concerns as well as inherent limitations
514             have caused it to enter its twilight. NIS did not gain widespread
515             appeal outside of the UNIX world and was not universally
516             adopted. Sun updated this to a more secure implementation called
517             NIS+, but even it has fallen victim to changing demands as the
518             demand for directory services that can be coupled with other
519             information systems is catching on.</para>
520
521           <para><indexterm>
522               <primary>NIS</primary>
523             </indexterm><indexterm>
524               <primary>government</primary>
525             </indexterm><indexterm>
526               <primary>education</primary>
527             </indexterm>
528             Nevertheless, both NIS and NIS+ continue to hold ground in
529             business areas where UNIX still has major sway. Examples of
530             organizations that remain firmly attached to the use of NIS and
531             NIS+ includes large government departments, education institutions,
532             as well as large corporations that have a scientific or engineering
533             focus.</para>
534
535           <para><indexterm>
536               <primary>scalable</primary>
537             </indexterm><indexterm>
538               <primary>distributed</primary>
539             </indexterm>
540             Today's networking world needs a scalable, distributed Identity 
541             Management infrastructure, commonly called a directory. The most 
542             popular technologies today are Microsoft Active Directory service 
543             and a number of LDAP implementations.</para>
544
545           <para><indexterm>
546               <primary>multiple directories</primary>
547             </indexterm>
548             The problem of managing multiple directories has become a focal
549             point over the past decade. This has created a large market for
550             meta-directory products and services that allow organizations that
551             have multiple directories and multiple management and control
552             centers to provision information from one directory into
553             another. The attendant benefit to end users is the promise of
554             having to remember and deal with fewer login identities and
555             passwords.</para>
556
557           <para><indexterm>
558               <primary>network</primary>
559               <secondary>bandwidth</secondary>
560             </indexterm>
561             The challenge of every large network is to find the optimum
562             balance of internal systems and facilities for Identity
563             Management resources. How well the solution is chosen and
564             implemented has potentially significant impact on network bandwidth
565             and systems response needs.</para>
566
567           <para><indexterm>
568               <primary>LDAP server</primary>
569             </indexterm><indexterm>
570               <primary>LDAP</primary>
571               <secondary>master</secondary>
572             </indexterm><indexterm>
573               <primary>LDAP</primary>
574               <secondary>slave</secondary>
575             </indexterm>
576             In Chapter 6, you implemented a single LDAP server for the
577             entire network. This may work for smaller networks, but almost
578             certainly fails to meet the needs of large and complex networks. The
579             following section documents how one may implement a single
580             master LDAP server, with multiple slave servers.</para>
581
582           <para>What is the best method for implementing master/slave LDAP
583             servers within the context of a distributed 2000 user network is a
584             question that remains to be answered.</para>
585
586           <para><indexterm>
587               <primary>distributed domain</primary>
588             </indexterm><indexterm>
589               <primary>wide-area</primary>
590             </indexterm>
591             One possibility that has great appeal is to create one single
592             large distributed domain. The practical implications of this
593             design (see <link linkend="chap7net"/>) demands the placement of
594             sufficient BDCs in each location. Additionally, network
595             administrators must make sure that profiles are not transferred
596             over the wide-area links, except as a totally unavoidable
597             measure. Network design must balance the risk of loss of user
598             productivity against the cost of network management and
599             maintenance.</para>
600
601           <para><indexterm>
602               <primary>domain name space</primary>
603             </indexterm>
604             The network design in <link linkend="chap7net2"/> takes the
605             approach that management of networks that are too remote to be
606             capable of being managed effectively from New York ought
607             to be given a certain degree of autonomy. With this rationale, the
608             Los Angeles and London networks, though fully integrated with that
609             on the east coast of the USA, each have their own domain name space
610             and can be independently managed and controlled. One of the key
611             drawbacks of this design is that it flies in the face of the
612             ability for network users to roam globally without some compromise
613             in how they may access global resources.</para>
614
615           <para><indexterm>
616               <primary>interdomain trusts</primary>
617             </indexterm>
618             Desk-bound users need not be negatively affected by this
619             design, since the use of interdomain trusts can be used to satisfy
620             the need for global data sharing.</para>
621
622           <para><indexterm>
623               <primary>LDAP</primary>
624             </indexterm><indexterm>
625               <primary>LDAP</primary>
626               <secondary>backend</secondary>
627             </indexterm><indexterm>
628               <primary>SID</primary>
629             </indexterm>
630             When Samba-3 is configured to use an LDAP backend, it stores the domain
631             account information in a directory entry. This account entry contains
632             the domain SID. An unintended but exploitable side effect is that
633             this makes it possible to operate with more than one PDC on a
634             distributed network.</para>
635
636           <para><indexterm>
637               <primary>WINS</primary>
638             </indexterm><indexterm>
639               <primary>wins.dat</primary>
640             </indexterm><indexterm>
641               <primary>SID</primary>
642             </indexterm>
643             How might this peculiar feature be exploited? The answer is
644             simple. It is imperative that each network segment should have its
645             own WINS server. Major servers on remote network segments can be
646             given a static WINS entry in the <filename>wins.dat</filename> file
647             on each WINS server. This allows all essential data to be
648             visible from all locations. Each location would, however, function
649             as if it is an independent domain, while all sharing the same
650             domain SID. Since all domain account information can be stored in a
651             single LDAP backend, users have unfettered ability to
652             roam.</para>
653
654           <para><indexterm>
655               <primary>NetBIOS name</primary>
656               <secondary>aliases</secondary>
657             </indexterm><indexterm>
658               <primary>fail-over</primary>
659             </indexterm>
660             This concept has not been exhaustively validated, though we can
661             see no reason why this should not work. The important facets
662             are: The name of the domain must be identical in all
663             locations. Each network segment must have its own WINS server. The
664             name of the PDC must be the same in all locations; this
665             necessitates the use of NetBIOS name aliases for each PDC so that
666             they can be accessed globally using the alias and not the PDC's
667             primary name. A single master LDAP server can be based in New York,
668             with multiple LDAP slave servers located on every network
669             segment. Finally, the BDCs should each use fail-over LDAP servers
670             that are in fact slave LDAP servers on the local segments.</para>
671
672           <para><indexterm>
673               <primary>LDAP</primary>
674               <secondary>updates</secondary>
675             </indexterm><indexterm>
676               <primary>domain tree</primary>
677             </indexterm><indexterm>
678               <primary>LDAP</primary>
679               <secondary>database</secondary>
680             </indexterm><indexterm>
681               <primary>LDAP</primary>
682               <secondary>directory</secondary>
683             </indexterm>
684             With a single master LDAP server, all network updates are
685             effected on a single server. In the event that this should become
686             excessively fragile or network bandwidth limiting, one could
687             implement a delegated LDAP domain. This is also known as a 
688             partitioned (or multiple partition) LDAP database
689             and as a distributed LDAP directory.</para>
690
691           <para>As the LDAP directory grows, it becomes increasingly important
692             that its structure is implemented in a manner that mirrors
693             organizational needs, so as to limit network update and
694             referential traffic. It should be noted that all directory
695             administrators must of necessity follow the same standard
696             procedures for managing the directory, as retroactive correction of
697             inconsistent directory information can be exceedingly difficult.</para>
698
699         <image id="chap7net">
700                 <imagedescription>Network Topology &smbmdash; 2000 User Complex Design A</imagedescription>
701                 <imagefile scale="60">chap7-net-Ar</imagefile>
702         </image>
703
704         <image id="chap7net2">
705                 <imagedescription>Network Topology &smbmdash; 2000 User Complex Design B</imagedescription>
706                 <imagefile scale="60">chap7-net2-Br</imagefile>
707         </image>
708
709         </sect3>
710
711         </sect2>
712
713
714         <sect2>
715                 <title>Political Issues</title>
716
717         <para>As organizations grow, the number of points of control increase
718           also. In a large distributed organization, it is important that the
719           Identity Management system must be capable of being updated from
720           many locations, and it is equally important that changes made should
721           become capable of being used in a reasonable period, typically
722           minutes rather than days (the old limitation of highly manual
723           systems).</para>
724
725         </sect2>
726
727 </sect1>
728
729 <sect1>
730         <title>Implementation</title>
731
732       <para><indexterm>
733           <primary>winbind</primary>
734         </indexterm><indexterm>
735           <primary>LDAP</primary>
736         </indexterm><indexterm>
737           <primary>UID</primary>
738         </indexterm><indexterm>
739           <primary>GID</primary>
740         </indexterm>
741         Samba-3 has the ability to use multiple password (authentication
742         and identity resolution) backends. The diagram in <link
743           linkend="chap7idres"/> demonstrates how Samba uses winbind, LDAP,
744         and NIS, the traditional system password database. The diagram only
745         documents the mechanisms for authentication and identity resolution
746         (obtaining a UNIX UID/GID) using the specific systems shown.
747         </para>
748
749         <image id="chap7idres">
750                 <imagedescription>Samba and Authentication Backend Search Pathways</imagedescription>
751                 <imagefile scale="55">chap7-idresol</imagefile>
752         </image>
753
754       <para><indexterm>
755           <primary>smbpasswd</primary>
756         </indexterm><indexterm>
757           <primary>xmlsam</primary>
758         </indexterm><indexterm>
759           <primary>SMB passwords</primary>
760         </indexterm><indexterm>
761           <primary>tdbsam</primary>
762         </indexterm><indexterm>
763           <primary>mysqlsam</primary>
764         </indexterm><indexterm>
765           <primary>LDAP</primary>
766         </indexterm><indexterm>
767           <primary>distributed</primary>
768         </indexterm>
769         Samba is capable of using the <constant>smbpasswd</constant>,
770         <constant>tdbsam</constant>, <constant>xmlsam</constant>,
771         and <constant>mysqlsam</constant> authentication databases. The SMB
772         passwords can, of course, also be stored in an LDAP ldapsam
773         backend. LDAP is the preferred passdb backend for distributed network
774         operations.</para>
775
776       <para><indexterm>
777           <primary>passdb backend</primary>
778         </indexterm>
779         Additionally, it is possible to use multiple passdb backends
780         concurrently as well as have multiple LDAP backends. As a result, one
781         can specify a fail-over LDAP backend. The syntax for specifying a
782         single LDAP backend in &smb.conf; is:
783 <screen>
784 ...
785 passdb backend = ldapsam:ldap://master.abmas.biz
786 ...
787 </screen>
788         This configuration tells Samba to use a single LDAP server as shown in
789         <link linkend="ch7singleLDAP"/>.
790         <image id="ch7singleLDAP">
791                 <imagedescription>Samba Configuration to Use a Single LDAP Server</imagedescription>
792                 <imagefile scale="65">ch7-singleLDAP</imagefile>
793         </image>
794         <indexterm>
795           <primary>LDAP</primary>
796           <secondary>fail-over</secondary>
797         </indexterm><indexterm>
798           <primary>fail-over</primary>
799         </indexterm>
800         The addition of a fail-over LDAP server can simply be done by adding a
801         second entry for the fail-over server to the single
802         <parameter>ldapsam</parameter> entry as shown here (note the particular
803         use of the double quotes):
804 <screen>
805 ...
806 passdb backend = ldapsam:"ldap://master.abmas.biz \
807                           ldap://slave.abmas.biz"
808 ...
809 </screen>
810         This configuration tells Samba to use a master LDAP server, with fail-over to a slave server if necessary,
811         as shown in <link linkend="ch7dualLDAP"/>.
812         <image id="ch7dualLDAP">
813                 <imagedescription>Samba Configuration to Use a Dual (Fail-over) LDAP Server</imagedescription>
814                 <imagefile scale="65">ch7-fail-overLDAP</imagefile>
815         </image>
816       </para>
817
818       <para>Some folks have tried to implement this without the use of
819         double quotes as shown above. This is the type of entry they had
820         created:
821 <screen>
822 ...
823 passdb backend = ldapsam:ldap://master.abmas.biz \
824                  ldapsam:ldap://slave.abmas.biz
825 ...
826 </screen>
827         <indexterm>
828           <primary>contiguous directory</primary>
829         </indexterm>
830         The effect of this style of entry is that Samba lists the users
831         that are in both LDAP databases. If both contain the same information,
832         it results in each record being shown twice. This is, of course, not the
833         solution desired for a fail-over implementation. The net effect of this
834         configuration is shown in <link linkend="ch7dualadd"/>
835         </para>
836
837         <image id="ch7dualadd">
838                 <imagedescription>Samba Configuration to Use Dual LDAP Databases - Broken - Do Not Use!</imagedescription>
839                 <imagefile scale="55">ch7-dual-additive-LDAP</imagefile>
840         </image>
841
842         <para>
843         If, however, each LDAP database contains unique information, this may 
844         well be an advantageous way to effectively integrate multiple LDAP databases 
845         into one seemingly contiguous directory. Only the first database will be updated.
846         An example of this configuration is shown in <link linkend="ch7dualok"/>.
847         </para>
848
849                 <image id="ch7dualok">
850                         <imagedescription>Samba Configuration to Use Two LDAP Databases - The result is additive.</imagedescription>
851                         <imagefile scale="55">ch7-dual-additive-LDAP-Ok</imagefile>
852                 </image>
853
854         <note><para>
855         When the use of ldapsam is specified twice, as shown here, it is imperative
856         that the two LDAP directories must be disjoint. If the entries are for a
857         master LDAP server as well as its own slave server, updates to the LDAP
858         database may end up being lost or corrupted. You may safely use multiple
859         LDAP backends only so long as both are entirely separate from each other.
860         </para></note>
861
862       <para>It is assumed that the network you are working with follows in a
863         pattern similar to what has been covered in Chapter 6. The following steps
864         permit the operation of a Master/Slave OpenLDAP arrangement.</para>
865
866         <procedure>
867
868                 <step><para>
869             <indexterm>
870               <primary>SUSE Linux</primary>
871             </indexterm><indexterm>
872               <primary>Red Hat Linux</primary>
873             </indexterm>
874                 Log onto the master LDAP server as <constant>root</constant>.
875                 You are about to change the configuration of the LDAP server, so it
876                 makes sense to temporarily halt it. Stop OpenLDAP from running on 
877                 SUSE Linux by executing:
878 <screen>
879 &rootprompt; rcldap stop
880 </screen>
881                 On Red Hat Linux, you can do this by executing:
882 <screen>
883 &rootprompt; service ldap stop
884 </screen>
885                 </para></step>
886
887         <step><para><indexterm>
888               <primary>/etc/openldap/slapd.conf</primary>
889             </indexterm>
890                 Edit the <filename>/etc/openldap/slapd.conf</filename> file so it
891                 matches the content of <link linkend="ch7-LDAP-master"/>.
892                 </para></step>
893
894         <step><para>
895                 Create a file called <filename>admin-accts.ldif</filename> with the following contents:
896 <screen>
897 dn: cn=updateuser,dc=abmas,dc=biz
898 objectClass: person
899 cn: updateuser
900 sn: updateuser
901 userPassword: not24get
902
903 dn: cn=sambaadmin,dc=abmas,dc=biz
904 objectClass: person
905 cn: sambaadmin
906 sn: sambaadmin
907 userPassword: buttercup
908 </screen>
909         </para></step>
910
911         <step><para>
912                 Add an account called <quote>updateuser</quote> to the master LDAP server
913                 as shown here:
914 <screen>
915 &rootprompt; slapadd -v -l admin-accts.ldif
916 </screen>
917         </para></step>
918
919         <step><para><indexterm>
920               <primary>LDIF</primary>
921             </indexterm><indexterm>
922               <primary>LDAP</primary>
923               <secondary>preload</secondary>
924             </indexterm>
925                 Change directory to a suitable place to dump the contents of the
926                 LDAP server. The dump file (and LDIF file) is used to preload
927                 the Slave LDAP server database. You can dump the database by executing:
928 <screen>
929 &rootprompt; slapcat -v -l LDAP-transfer-LDIF.txt
930 </screen>
931                 Each record is written to the file.     
932                 </para></step>
933
934         <step><para><indexterm>
935               <primary>LDAP-transfer-LDIF.txt</primary>
936             </indexterm>
937                 Copy the file <filename>LDAP-transfer-LDIF.txt</filename> to the intended
938                 slave LDAP server. A good location could be in the directory 
939                 <filename>/etc/openldap/preload</filename>.
940                 </para></step>
941
942                 <step><para>
943                 Log onto the slave LDAP server as <constant>root</constant>. You can
944                 now configure this server so the <filename>/etc/openldap/slapd.conf</filename>
945                 file matches the content of <link linkend="ch7-LDAP-slave"/>.
946                 </para></step>
947
948                 <step><para>
949                 Change directory to the location in which you stored the 
950                 <filename>LDAP-transfer-LDIF.txt</filename> file (<filename>/etc/openldap/preload</filename>).
951                 While in this directory, execute:
952 <screen>
953 &rootprompt; slapadd -v -l LDAP-transfer-LDIF.txt
954 </screen>
955                 If all goes well, the following output confirms that the data is being loaded
956                 as intended:
957 <screen>
958 added: "dc=abmas,dc=biz" (00000001)
959 added: "cn=sambaadmin,dc=abmas,dc=biz" (00000002)
960 added: "cn=updateuser,dc=abmas,dc=biz" (00000003)
961 added: "ou=People,dc=abmas,dc=biz" (00000004)
962 added: "ou=Groups,dc=abmas,dc=biz" (00000005)
963 added: "ou=Computers,dc=abmas,dc=biz" (00000006)
964 added: "uid=Administrator,ou=People,dc=abmas,dc=biz" (00000007)
965 added: "uid=nobody,ou=People,dc=abmas,dc=biz" (00000008)
966 added: "cn=Domain Admins,ou=Groups,dc=abmas,dc=biz" (00000009)
967 added: "cn=Domain Users,ou=Groups,dc=abmas,dc=biz" (0000000a)
968 added: "cn=Domain Guests,ou=Groups,dc=abmas,dc=biz" (0000000b)
969 added: "uid=bobj,ou=People,dc=abmas,dc=biz" (0000000c)
970 added: "sambaDomainName=MEGANET2,dc=abmas,dc=biz" (0000000d)
971 added: "uid=stans,ou=People,dc=abmas,dc=biz" (0000000e)
972 added: "uid=chrisr,ou=People,dc=abmas,dc=biz" (0000000f)
973 added: "uid=maryv,ou=People,dc=abmas,dc=biz" (00000010)
974 added: "cn=Accounts,ou=Groups,dc=abmas,dc=biz" (00000011)
975 added: "cn=Finances,ou=Groups,dc=abmas,dc=biz" (00000012)
976 added: "cn=PIOps,ou=Groups,dc=abmas,dc=biz" (00000013)
977 </screen>
978                 </para></step>
979
980                 <step><para>
981                 Now start the LDAP server and set it to run automatically on system reboot
982                 by executing:
983 <screen>
984 &rootprompt; rcldap start
985 &rootprompt; chkconfig ldap on
986 </screen>
987                 On Red Hat Linux, you would execute the following:
988 <screen>
989 &rootprompt; service ldap start
990 &rootprompt; chkconfig ldap on
991 </screen>
992             <indexterm>
993               <primary>chkconfig</primary>
994             </indexterm><indexterm>
995               <primary>service</primary>
996             </indexterm><indexterm>
997               <primary>rcldap</primary>
998             </indexterm>
999                 </para></step>
1000
1001                 <step><para>
1002                 Go back to the master LDAP server. Execute the following to start LDAP as well
1003                 as <command>slurpd</command>, the synchronization daemon, as shown here:
1004 <screen>
1005 &rootprompt; rcldap start
1006 &rootprompt; chkconfig ldap on
1007 &rootprompt; rcslurpd start
1008 &rootprompt; chkconfig slurpd on
1009 </screen>
1010             <indexterm>
1011               <primary>slurpd</primary>
1012             </indexterm>
1013                 On Red Hat Linux, check the equivalent command to start <command>slurpd</command>.
1014                 </para></step>
1015
1016         <step><para><indexterm>
1017               <primary>smbldap-useradd</primary>
1018             </indexterm>
1019                 On the master ldap server you may now add an account to validate that replication
1020                 is working. Assuming the configuration shown in Chapter 6, execute:
1021 <screen>
1022 &rootprompt; /var/lib/samba/sbin/smbldap-useradd -a fruitloop
1023 </screen>
1024                 </para></step>
1025
1026                 <step><para>
1027                 On the slave LDAP server, change to the directory <filename>/var/lib/ldap</filename>.
1028                 There should now be a file called <filename>replogfile</filename>. If replication worked
1029                 as expected, the content of this file should be:
1030 <screen>
1031 time: 1072486403
1032 dn: uid=fruitloop,ou=People,dc=abmas,dc=biz
1033 changetype: modify
1034 replace: sambaProfilePath
1035 sambaProfilePath: \\MASSIVE\profiles\fruitloop
1036 -
1037 replace: sambaHomePath
1038 sambaHomePath: \\MASSIVE\homes
1039 -
1040 replace: entryCSN
1041 entryCSN: 2003122700:43:38Z#0x0005#0#0000
1042 -
1043 replace: modifiersName
1044 modifiersName: cn=Manager,dc=abmas,dc=biz
1045 -
1046 replace: modifyTimestamp
1047 modifyTimestamp: 20031227004338Z
1048 -
1049 </screen>
1050                 </para></step>
1051
1052                 <step><para>
1053                 Given that this first slave LDAP server is now working correctly, you may now
1054                 implement additional slave LDAP servers as required.
1055                 </para></step>
1056
1057         </procedure>
1058
1059 <example id="ch7-LDAP-master">
1060 <title>LDAP Master Server Configuration File &smbmdash; <filename>/etc/openldap/slapd.conf</filename></title>
1061 <screen>
1062 include     /etc/openldap/schema/core.schema
1063 include     /etc/openldap/schema/cosine.schema
1064 include     /etc/openldap/schema/inetorgperson.schema
1065 include     /etc/openldap/schema/nis.schema
1066 include     /etc/openldap/schema/samba.schema
1067
1068 pidfile     /var/run/slapd/slapd.pid
1069 argsfile    /var/run/slapd/slapd.args
1070
1071 database    bdb
1072 suffix      "dc=abmas,dc=biz"
1073 rootdn      "cn=Manager,dc=abmas,dc=biz"
1074
1075 # rootpw = not24get
1076 rootpw      {SSHA}86kTavd9Dw3FAz6qzWTrCOKX/c0Qe+UV
1077
1078 replica     host=lapdc.abmas.biz:389
1079             suffix="dc=abmas,dc=biz"
1080             binddn="cn=updateuser,dc=abmas,dc=biz"
1081             bindmethod=simple credentials=not24get
1082
1083 access to attrs=sambaLMPassword,sambaNTPassword
1084            by dn="cn=updateuser,dc=abmas,dc=biz" write
1085            by * none
1086
1087 replogfile  /var/lib/ldap/replogfile
1088
1089 directory   /var/lib/ldap
1090
1091 # Indices to maintain
1092 index objectClass           eq
1093 index cn                    pres,sub,eq
1094 index sn                    pres,sub,eq
1095 index uid                   pres,sub,eq
1096 index displayName           pres,sub,eq
1097 index uidNumber             eq
1098 index gidNumber             eq
1099 index memberUID             eq
1100 index sambaSID              eq
1101 index sambaPrimaryGroupSID  eq
1102 index sambaDomainName       eq
1103 index default               sub
1104 </screen>
1105 </example>
1106
1107 <example id="ch7-LDAP-slave">
1108 <title>LDAP Slave Configuration File &smbmdash; <filename>/etc/openldap/slapd.conf</filename></title>
1109 <screen>
1110 include     /etc/openldap/schema/core.schema
1111 include     /etc/openldap/schema/cosine.schema
1112 include     /etc/openldap/schema/inetorgperson.schema
1113 include     /etc/openldap/schema/nis.schema
1114 include     /etc/openldap/schema/samba.schema
1115
1116 pidfile     /var/run/slapd/slapd.pid
1117 argsfile    /var/run/slapd/slapd.args
1118
1119 database    bdb
1120 suffix      "dc=abmas,dc=biz"
1121 rootdn      "cn=Manager,dc=abmas,dc=biz"
1122
1123 # rootpw = not24get
1124 rootpw      {SSHA}86kTavd9Dw3FAz6qzWTrCOKX/c0Qe+UV
1125
1126 access to *
1127             by dn=cn=updateuser,dc=abmas,dc=biz write
1128             by * read
1129
1130 updatedn    cn=updateuser,dc=abmas,dc=biz
1131 updateref   ldap://massive.abmas.biz
1132
1133 directory   /var/lib/ldap
1134
1135 # Indices to maintain
1136 index objectClass           eq
1137 index cn                    pres,sub,eq
1138 index sn                    pres,sub,eq
1139 index uid                   pres,sub,eq
1140 index displayName           pres,sub,eq
1141 index uidNumber             eq
1142 index gidNumber             eq
1143 index memberUID             eq
1144 index sambaSID              eq
1145 index sambaPrimaryGroupSID  eq
1146 index sambaDomainName       eq
1147 index default               sub
1148 </screen>
1149 </example>
1150
1151 <smbconfexample id="ch7-massmbconfA">
1152 <title>Primary Domain Controller &smb.conf; File &smbmdash; Part A</title>
1153 <smbconfcomment>Global parameters</smbconfcomment>
1154 <smbconfsection name="[global]"/>
1155 <smbconfoption name="unix charset">LOCALE</smbconfoption>
1156 <smbconfoption name="workgroup">MEGANET2</smbconfoption>
1157 <smbconfoption name="passdb backend">ldapsam:ldap://massive.abmas.biz</smbconfoption>
1158 <smbconfoption name="username map">/etc/samba/smbusers</smbconfoption>
1159 <smbconfoption name="log level">1</smbconfoption>
1160 <smbconfoption name="syslog">0</smbconfoption>
1161 <smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
1162 <smbconfoption name="max log size">0</smbconfoption>
1163 <smbconfoption name="smb ports">139 445</smbconfoption>
1164 <smbconfoption name="name resolve order">wins bcast hosts</smbconfoption>
1165 <smbconfoption name="time server">Yes</smbconfoption>
1166 <smbconfoption name="printcap name">CUPS</smbconfoption>
1167 <smbconfoption name="add user script">/opt/IDEALX/sbin/smbldap-useradd -m '%u'</smbconfoption>
1168 <smbconfoption name="delete user script">/opt/IDEALX/sbin/smbldap-userdel '%u'</smbconfoption>
1169 <smbconfoption name="add group script">/opt/IDEALX/sbin/smbldap-groupadd -p '%g'</smbconfoption>
1170 <smbconfoption name="delete group script">/opt/IDEALX/sbin/smbldap-groupdel '%g'</smbconfoption>
1171 <smbconfoption name="add user to group script">/opt/IDEALX/sbin/</smbconfoption>
1172 <member><parameter>smbldap-groupmod -m '%g' '%u'</parameter></member>
1173 <smbconfoption name="delete user from group script">/opt/IDEALX/sbin/</smbconfoption>
1174 <member><parameter>smbldap-groupmod -x '%g' '%u'</parameter></member>
1175 <smbconfoption name="set primary group script">/opt/IDEALX/sbin/</smbconfoption>
1176 <member><parameter>smbldap-usermod -g '%g' '%u'</parameter></member>
1177 <smbconfoption name="add machine script">/opt/IDEALX/sbin/</smbconfoption>
1178 <member><parameter>smbldap-useradd -w '%u'</parameter></member>
1179 <smbconfoption name="shutdown script">/var/lib/samba/scripts/shutdown.sh</smbconfoption>
1180 <smbconfoption name="abort shutdown script">/sbin/shutdown -c</smbconfoption>
1181 <smbconfoption name="logon script">scripts\logon.bat</smbconfoption>
1182 <smbconfoption name="logon path">\\%L\profiles\%U</smbconfoption>
1183 <smbconfoption name="logon drive">X:</smbconfoption>
1184 <smbconfoption name="domain logons">Yes</smbconfoption>
1185 <smbconfoption name="domain master">Yes</smbconfoption>
1186 <smbconfoption name="wins support">Yes</smbconfoption>
1187 <smbconfoption name="ldap suffix">dc=abmas,dc=biz</smbconfoption>
1188 <smbconfoption name="ldap machine suffix">ou=People</smbconfoption>
1189 <smbconfoption name="ldap user suffix">ou=People</smbconfoption>
1190 <smbconfoption name="ldap group suffix">ou=Groups</smbconfoption>
1191 <smbconfoption name="ldap idmap suffix">ou=Idmap</smbconfoption>
1192 <smbconfoption name="ldap admin dn">cn=Manager,dc=abmas,dc=biz</smbconfoption>
1193 <smbconfoption name="idmap backend">ldap://massive.abmas.biz</smbconfoption>
1194 <smbconfoption name="idmap uid">10000-20000</smbconfoption>
1195 <smbconfoption name="idmap gid">10000-20000</smbconfoption>
1196 <smbconfoption name="printer admin">root</smbconfoption>
1197 <smbconfoption name="printing">cups</smbconfoption>
1198 </smbconfexample>
1199
1200 <smbconfexample id="ch7-massmbconfB">
1201 <title>Primary Domain Controller &smb.conf; File &smbmdash; Part B</title>
1202 <smbconfsection name="[IPC$]"/>
1203 <smbconfoption name="path">/tmp</smbconfoption>
1204
1205 <smbconfsection name="[accounts]"/>
1206 <smbconfoption name="comment">Accounting Files</smbconfoption>
1207 <smbconfoption name="path">/data/accounts</smbconfoption>
1208 <smbconfoption name="read only">No</smbconfoption>
1209
1210 <smbconfsection name="[service]"/>
1211 <smbconfoption name="comment">Financial Services Files</smbconfoption>
1212 <smbconfoption name="path">/data/service</smbconfoption>
1213 <smbconfoption name="read only">No</smbconfoption>
1214
1215 <smbconfsection name="[pidata]"/>
1216 <smbconfoption name="comment">Property Insurance Files</smbconfoption>
1217 <smbconfoption name="path">/data/pidata</smbconfoption>
1218 <smbconfoption name="read only">No</smbconfoption>
1219
1220 <smbconfsection name="[homes]"/>
1221 <smbconfoption name="comment">Home Directories</smbconfoption>
1222 <smbconfoption name="valid users">%S</smbconfoption>
1223 <smbconfoption name="read only">No</smbconfoption>
1224 <smbconfoption name="browseable">No</smbconfoption>
1225
1226 <smbconfsection name="[printers]"/>
1227 <smbconfoption name="comment">SMB Print Spool</smbconfoption>
1228 <smbconfoption name="path">/var/spool/samba</smbconfoption>
1229 <smbconfoption name="guest ok">Yes</smbconfoption>
1230 <smbconfoption name="printable">Yes</smbconfoption>
1231 <smbconfoption name="browseable">No</smbconfoption>
1232 </smbconfexample>
1233
1234 <smbconfexample id="ch7-massmbconfC">
1235 <title>Primary Domain Controller &smb.conf; File &smbmdash; Part C</title>
1236 <smbconfsection name="[apps]"/>
1237 <smbconfoption name="comment">Application Files</smbconfoption>
1238 <smbconfoption name="path">/apps</smbconfoption>
1239 <smbconfoption name="admin users">bjones</smbconfoption>
1240 <smbconfoption name="read only">No</smbconfoption>
1241
1242 <smbconfsection name="[netlogon]"/>
1243 <smbconfoption name="comment">Network Logon Service</smbconfoption>
1244 <smbconfoption name="path">/var/lib/samba/netlogon</smbconfoption>
1245 <smbconfoption name="admin users">root, Administrator</smbconfoption>
1246 <smbconfoption name="guest ok">Yes</smbconfoption>
1247 <smbconfoption name="locking">No</smbconfoption>
1248
1249 <smbconfsection name="[profiles]"/>
1250 <smbconfoption name="comment">Profile Share</smbconfoption>
1251 <smbconfoption name="path">/var/lib/samba/profiles</smbconfoption>
1252 <smbconfoption name="read only">No</smbconfoption>
1253 <smbconfoption name="profile acls">Yes</smbconfoption>
1254
1255 <smbconfsection name="[profdata]"/>
1256 <smbconfoption name="comment">Profile Data Share</smbconfoption>
1257 <smbconfoption name="path">/var/lib/samba/profdata</smbconfoption>
1258 <smbconfoption name="read only">No</smbconfoption>
1259 <smbconfoption name="profile acls">Yes</smbconfoption>
1260
1261 <smbconfsection name="[print$]"/>
1262 <smbconfoption name="comment">Printer Drivers</smbconfoption>
1263 <smbconfoption name="path">/var/lib/samba/drivers</smbconfoption>
1264 <smbconfoption name="write list">root</smbconfoption>
1265 <smbconfoption name="admin users">root, Administrator</smbconfoption>
1266 </smbconfexample>
1267
1268 <smbconfexample id="ch7-slvsmbocnfA">
1269 <title>Backup Domain Controller &smb.conf; File &smbmdash; Part A</title>
1270 <smbconfcomment># Global parameters</smbconfcomment>
1271 <smbconfsection name="[global]"/>
1272 <smbconfoption name="unix charset">LOCALE</smbconfoption>
1273 <smbconfoption name="workgroup">MEGANET2</smbconfoption>
1274 <smbconfoption name="netbios name">BLDG1</smbconfoption>
1275 <smbconfoption name="passdb backend">ldapsam:ldap://lapdc.abmas.biz</smbconfoption>
1276 <smbconfoption name="username map">/etc/samba/smbusers</smbconfoption>
1277 <smbconfoption name="log level">1</smbconfoption>
1278 <smbconfoption name="syslog">0</smbconfoption>
1279 <smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
1280 <smbconfoption name="max log size">50</smbconfoption>
1281 <smbconfoption name="smb ports">139 445</smbconfoption>
1282 <smbconfoption name="name resolve order">wins bcast hosts</smbconfoption>
1283 <smbconfoption name="printcap name">CUPS</smbconfoption>
1284 <smbconfoption name="show add printer wizard">No</smbconfoption>
1285 <smbconfoption name="logon script">scripts\logon.bat</smbconfoption>
1286 <smbconfoption name="logon path">\\%L\profiles\%U</smbconfoption>
1287 <smbconfoption name="logon drive">X:</smbconfoption>
1288 <smbconfoption name="domain logons">Yes</smbconfoption>
1289 <smbconfoption name="os level">63</smbconfoption>
1290 <smbconfoption name="domain master">No</smbconfoption>
1291 <smbconfoption name="wins server">192.168.2.1</smbconfoption>
1292 <smbconfoption name="ldap suffix">dc=abmas,dc=biz</smbconfoption>
1293 <smbconfoption name="ldap machine suffix">ou=People</smbconfoption>
1294 <smbconfoption name="ldap user suffix">ou=People</smbconfoption>
1295 <smbconfoption name="ldap group suffix">ou=Groups</smbconfoption>
1296 <smbconfoption name="ldap idmap suffix">ou=Idmap</smbconfoption>
1297 <smbconfoption name="ldap admin dn">cn=Manager,dc=abmas,dc=biz</smbconfoption>
1298 <smbconfoption name="utmp">Yes</smbconfoption>
1299 <smbconfoption name="idmap backend">ldap://massive.abmas.biz</smbconfoption>
1300 <smbconfoption name="idmap uid">10000-20000</smbconfoption>
1301 <smbconfoption name="idmap gid">10000-20000</smbconfoption>
1302 <smbconfoption name="printing">cups</smbconfoption>
1303
1304 <smbconfsection name="[accounts]"/>
1305 <smbconfoption name="comment">Accounting Files</smbconfoption>
1306 <smbconfoption name="path">/data/accounts</smbconfoption>
1307 <smbconfoption name="read only">No</smbconfoption>
1308
1309 <smbconfsection name="[service]"/>
1310 <smbconfoption name="comment">Financial Services Files</smbconfoption>
1311 <smbconfoption name="path">/data/service</smbconfoption>
1312 <smbconfoption name="read only">No</smbconfoption>
1313 </smbconfexample>
1314
1315 <smbconfexample id="ch7-slvsmbocnfB">
1316 <title>Backup Domain Controller &smb.conf; File &smbmdash; Part B</title>
1317 <smbconfsection name="[pidata]"/>
1318 <smbconfoption name="comment">Property Insurance Files</smbconfoption>
1319 <smbconfoption name="path">/data/pidata</smbconfoption>
1320 <smbconfoption name="read only">No</smbconfoption>
1321
1322 <smbconfsection name="[homes]"/>
1323 <smbconfoption name="comment">Home Directories</smbconfoption>
1324 <smbconfoption name="valid users">%S</smbconfoption>
1325 <smbconfoption name="read only">No</smbconfoption>
1326 <smbconfoption name="browseable">No</smbconfoption>
1327
1328 <smbconfsection name="[printers]"/>
1329 <smbconfoption name="comment">SMB Print Spool</smbconfoption>
1330 <smbconfoption name="path">/var/spool/samba</smbconfoption>
1331 <smbconfoption name="guest ok">Yes</smbconfoption>
1332 <smbconfoption name="printable">Yes</smbconfoption>
1333 <smbconfoption name="browseable">No</smbconfoption>
1334
1335 <smbconfsection name="[apps]"/>
1336 <smbconfoption name="comment">Application Files</smbconfoption>
1337 <smbconfoption name="path">/apps</smbconfoption>
1338 <smbconfoption name="admin users">bjones</smbconfoption>
1339 <smbconfoption name="read only">No</smbconfoption>
1340
1341 <smbconfsection name="[netlogon]"/>
1342 <smbconfoption name="comment">Network Logon Service</smbconfoption>
1343 <smbconfoption name="path">/var/lib/samba/netlogon</smbconfoption>
1344 <smbconfoption name="guest ok">Yes</smbconfoption>
1345 <smbconfoption name="locking">No</smbconfoption>
1346
1347 <smbconfsection name="[profiles]"/>
1348 <smbconfoption name="comment">Profile Share</smbconfoption>
1349 <smbconfoption name="path">/var/lib/samba/profiles</smbconfoption>
1350 <smbconfoption name="read only">No</smbconfoption>
1351 <smbconfoption name="profile acls">Yes</smbconfoption>
1352
1353 <smbconfsection name="[profdata]"/>
1354 <smbconfoption name="comment">Profile Data Share</smbconfoption>
1355 <smbconfoption name="path">/var/lib/samba/profdata</smbconfoption>
1356 <smbconfoption name="read only">No</smbconfoption>
1357 <smbconfoption name="profile acls">Yes</smbconfoption>
1358 </smbconfexample>
1359
1360         <sect2>
1361                 <title>Key Points Learned</title>
1362
1363                 <para>
1364                 </para>
1365
1366                 <itemizedlist>
1367           <listitem><para><indexterm>
1368                 <primary>LDAP</primary>
1369               </indexterm><indexterm>
1370                 <primary>BDC</primary>
1371               </indexterm>
1372                         Where Samba-3 is used as a Domain Controller, the use of LDAP is an 
1373                         essential component necessary to permit the use of BDCs.
1374                         </para></listitem>
1375
1376           <listitem><para><indexterm>
1377                 <primary>wide-area</primary>
1378               </indexterm>
1379                         Replication of the LDAP master server to create a network of BDCs
1380                         is an important mechanism for limiting wide-area network traffic.
1381                         </para></listitem>
1382
1383                         <listitem><para>
1384                         Network administration presents many complex challenges, most of which
1385                         can be satisfied by good design, but that also require sound communication
1386                         and unification of management practices. This can be highly challenging in
1387                         a large, globally distributed network.
1388                         </para></listitem>
1389
1390                         <listitem><para>
1391                         Roaming profiles must be contained to the local network segment. Any
1392                         departure from this may clog wide-area arteries and slow legitimate network
1393                         traffic to a crawl.
1394                         </para></listitem>
1395                 </itemizedlist>
1396
1397         </sect2>
1398
1399 </sect1>
1400
1401 <sect1>
1402         <title>Questions and Answers</title>
1403
1404         <para>
1405         There is much rumor and misinformation regarding the use of MS Windows networking protocols.
1406         These questions are just a few of those frequently asked.
1407         </para>
1408
1409         <qandaset defaultlabel="chap07qa">
1410         <qandaentry>
1411         <question>
1412
1413             <para><indexterm>
1414                 <primary>DHCP</primary>
1415               </indexterm><indexterm>
1416                 <primary>network</primary>
1417                 <secondary>bandwidth</secondary>
1418               </indexterm>
1419                 Is it true that DHCP uses lots of wide-area network bandwidth?
1420                 </para>
1421
1422         </question>
1423         <answer>
1424
1425             <para><indexterm>
1426                 <primary>DHCP</primary>
1427                 <secondary>Relay Agent</secondary>
1428               </indexterm><indexterm>
1429                 <primary>routers</primary>
1430               </indexterm><indexterm>
1431                 <primary>DHCP</primary>
1432                 <secondary>servers</secondary>
1433               </indexterm>
1434                 It is a smart practice to localize DHCP servers on each network segment. As a 
1435                 rule, there should be two DHCP servers per network segment. This means that if
1436                 one server fails, there is always another to service user needs. DHCP requests use
1437                 only UDP broadcast protocols. It is possible to run a DHCP Relay Agent on network
1438                 routers. This makes it possible to run fewer DHCP servers.
1439                 </para>
1440
1441             <para><indexterm>
1442                 <primary>DHCP</primary>
1443                 <secondary>request</secondary>
1444               </indexterm><indexterm>
1445                 <primary>DHCP</primary>
1446                 <secondary>traffic</secondary>
1447               </indexterm>
1448                 A DHCP network address request and confirmation usually results in about six UDP packets.
1449                 The packets are from 60 to 568 bytes in length. Let us consider a site that has 300 DHCP
1450                 clients and that uses a 24-hour IP address lease. This means that all clients renew
1451                 their IP address lease every 24 hours. If we assume an average packet length equal to the
1452                 maximum (just to be on the safe side), and we have a 128 Kbit/sec wide-area connection, 
1453                 how significant would the DHCP traffic be if all of it were to use DHCP Relay?
1454                 </para>
1455
1456                 <para>
1457                 I must stress that this is a bad design, but here is the calculation:
1458 <screen>
1459 Daily Network Capacity: 128,000 (Kbits/s) / 8 (bits/byte) 
1460                              x 3600 (sec/hr) x 24 (hrs/day)= 2288 Mbytes/day.
1461
1462 DHCP traffic:          300 (clients) x 6 (packets) 
1463                                        x 512 (bytes/packet) = 0.9 Mbytes/day.
1464 </screen>
1465                 From this can be seen that the traffic impact would be minimal.
1466                 </para>
1467
1468             <para><indexterm>
1469                 <primary>DNS</primary>
1470                 <secondary>Dynamic</secondary>
1471               </indexterm><indexterm>
1472                 <primary>DHCP</primary>
1473               </indexterm>
1474                 Even when DHCP is configured to do DNS update (Dynamic DNS) over a wide-area link,
1475                 the impact of the update is no more than the DHCP IP address renewal traffic and, thus,
1476                 still insignificant for most practical purposes.
1477                 </para>
1478
1479         </answer>
1480         </qandaentry>
1481
1482         <qandaentry>
1483         <question>
1484
1485             <para><indexterm>
1486                 <primary>background communication</primary>
1487               </indexterm><indexterm>
1488                 <primary>LDAP</primary>
1489                 <secondary>master/slave</secondary>
1490                 <tertiary>background communication</tertiary>
1491               </indexterm>
1492                 How much background communication takes place between a Master LDAP 
1493                 server and its slave LDAP servers?
1494                 </para>
1495
1496         </question>
1497         <answer>
1498
1499             <para><indexterm>
1500                 <primary>slurpd</primary>
1501               </indexterm>
1502                 The process that controls the replication of data from the Master LDAP server to the Slave LDAP
1503                 servers is called <command>slurpd</command>. The <command>slurpd</command> remains nascent (quiet)
1504                 until an update must be propagated. The propagation traffic per LDAP salve to update (add/modify/delete)
1505                 two user accounts requires less than 10Kbytes traffic.
1506                 </para>
1507
1508         </answer>
1509         </qandaentry>
1510
1511         <qandaentry>
1512         <question>
1513
1514                 <para>
1515                 LDAP has a database. Is LDAP not just a fancy database front end?
1516                 </para>
1517
1518         </question>
1519         <answer>
1520
1521             <para><indexterm>
1522                 <primary>database</primary>
1523               </indexterm><indexterm>
1524                 <primary>LDAP</primary>
1525                 <secondary>database</secondary>
1526               </indexterm><indexterm>
1527                 <primary>SQL</primary>
1528               </indexterm><indexterm>
1529                 <primary>transactional</primary>
1530               </indexterm>
1531                 LDAP does store its data in a database of sorts. In fact the LDAP backend is an application-specific
1532                 data storage system. This type of database is indexed so that records can be rapidly located, but the
1533                 database is not generic and can be used only in particular pre-programmed ways. General external
1534                 applications do not gain access to the data. This type of database is used also by SQL servers. Both
1535                 an SQL server and an LDAP server provide ways to access the data. An SQL server has a transactional
1536                 orientation and typically allows external programs to perform ad-hoc queries, even across data tables.
1537                 An LDAP front end is a purpose-built tool that has a search orientation that is designed around specific
1538                 simple queries. The term <constant>database</constant> is heavily overloaded and, thus, much misunderstood.
1539                 </para>
1540
1541         </answer>
1542         </qandaentry>
1543
1544         <qandaentry>
1545         <question>
1546
1547             <para><indexterm>
1548                 <primary>OpenLDAP</primary>
1549               </indexterm>
1550                 Can Active Directory obtain account information from an OpenLDAP server?
1551                 </para>
1552
1553         </question>
1554         <answer>
1555
1556             <para><indexterm>
1557                 <primary>meta-directory</primary>
1558               </indexterm>
1559                 No, at least not directly. It is possible to provision Active Directory from/to an OpenLDAP
1560                 database through use of a meta-directory server. Microsoft MMS (now called MIIS) can interface
1561                 to OpenLDAP using standard LDAP queries/updates. 
1562                 </para>
1563
1564         </answer>
1565         </qandaentry>
1566
1567         <qandaentry>
1568         <question>
1569
1570                 <para>
1571                 What are the parts of a roaming profile? How large is each part?
1572                 </para>
1573
1574         </question>
1575         <answer>
1576
1577             <para><indexterm>
1578                 <primary>roaming profile</primary>
1579               </indexterm>
1580                 A roaming profile consists of:
1581                 </para>
1582
1583                 <itemizedlist>
1584                         <listitem><para>
1585                         Desktop folders such as: <constant>Desktop, My Documents, My Pictures, My Music, Internet Files,
1586                         Cookies, Application Data, Local Settings,</constant> and more. See <link linkend="XP-screen001"/>.
1587                         </para>
1588
1589                 <para><indexterm>
1590                     <primary>folder redirection</primary>
1591                   </indexterm>
1592                         Each of these can be anywhere from a few bytes to gigabytes in capacity. Fortunately, all
1593                         such folders can be redirected to network drive resources. See <link linkend="redirfold"/>
1594                         for more information regarding folder redirection.
1595                         </para></listitem>
1596
1597                         <listitem><para>
1598                         A static or re-writable portion that is typically only a few files (2-5 Kbytes of information).
1599                         </para></listitem>
1600
1601               <listitem><para><indexterm>
1602                     <primary>NTUSER.DAT</primary>
1603                   </indexterm><indexterm>
1604                     <primary>HKEY_LOCAL_USER</primary>
1605                   </indexterm>
1606                         The registry load file that modifies the <constant>HKEY_LOCAL_USER</constant> hive. This is
1607                         the <filename>NTUSER.DAT</filename> file. It can be from 0.4-1.5 MBytes.
1608                         </para></listitem>
1609                 </itemizedlist>
1610
1611             <para><indexterm>
1612                 <primary>Microsoft Outlook</primary>
1613                 <secondary>PST files</secondary>
1614               </indexterm>
1615                 Microsoft Outlook PST files may be stored in the <constant>Local Settings\Application Data</constant>
1616                 folder. It can be up to 2 Gbytes in size per PST file.
1617                 </para>
1618
1619         </answer>
1620         </qandaentry>
1621
1622         <qandaentry>
1623         <question>
1624
1625                 <para>
1626                 Can the <constant>My Documents</constant> folder be stored on a network drive?
1627                 </para>
1628
1629         </question>
1630         <answer>
1631
1632             <para><indexterm>
1633                 <primary>UNC name</primary>
1634               </indexterm><indexterm>
1635                 <primary>Universal Naming Convention</primary>
1636                 <see>UNC name</see>
1637               </indexterm>
1638                 Yes. More correctly, such folders can be redirected to network shares. No specific network drive
1639                 connection is required. Registry settings permit this to be redirected directly to a UNC (Universal
1640                 Naming Convention) resource, though it is possible to specify a network drive letter instead of a
1641                 UNC name. See <link linkend="redirfold"/>.
1642                 </para>
1643
1644         </answer>
1645         </qandaentry>
1646
1647         <qandaentry>
1648         <question>
1649
1650             <para><indexterm>
1651                 <primary>wide-area</primary>
1652               </indexterm><indexterm>
1653                 <primary>network</primary>
1654                 <secondary>bandwidth</secondary>
1655               </indexterm><indexterm>
1656                 <primary>WINS</primary>
1657               </indexterm>
1658                 How much wide-area network bandwidth does WINS consume?
1659                 </para>
1660
1661         </question>
1662         <answer>
1663
1664             <para><indexterm>
1665                 <primary>NetBIOS</primary>
1666                 <secondary>name cache</secondary>
1667               </indexterm><indexterm>
1668                 <primary>WINS server</primary>
1669               </indexterm><indexterm>
1670                 <primary>domain replication</primary>
1671               </indexterm>
1672                 MS Windows clients cache information obtained from WINS lookups in a local NetBIOS name cache.
1673                 This keeps WINS lookups to a minimum. On a network with 3500 MS Windows clients and a central WINS
1674                 server, the total bandwidth demand measured at the WINS server, averaged over an eight-hour working day,
1675                 was less than 30 Kbytes/sec. Analysis of network traffic over a six-week period showed that the total
1676                 of all background traffic consumed about 11 percent of available bandwidth over 64 Kbit/sec links.
1677                 Back-ground traffic consisted of domain replication, WINS queries, DNS lookups, authentication
1678                 traffic. Each of 11 branch offices had a 64 Kbit/sec wide-area link, with a 1.5 Mbit/sec main connection
1679                 that aggregated the branch office connections plus an Internet connection.
1680                 </para>
1681
1682                 <para>
1683                 In conclusion, the total load afforded through WINS traffic is again marginal to total operational
1684                 usage &smbmdash; as it should be.
1685                 </para>
1686
1687         </answer>
1688         </qandaentry>
1689
1690         <qandaentry>
1691         <question>
1692
1693                 <para>
1694                 How many BDCs should I have? What is the right number of Windows clients per server?
1695                 </para>
1696
1697         </question>
1698         <answer>
1699
1700                 <para>
1701                 It is recommended to have at least one BDC per network segment, including the segment served
1702                 by the PDC. Actual requirements vary depending on the working load on each of the BDCs and the
1703                 load demand pattern of client usage. I have seen sites that function without problem with 200
1704                 clients served by one BDC, and yet other sites that had one BDC per 20 clients. In one particular
1705                 company, there was a drafting office that has 30 CAD/CAM operators served by one server, a print
1706                 server; and an application server. While all three were BDCs, typically only the print server would
1707                 service network logon requests after the first 10 users had started to use the network. This was
1708                 a reflection of the service load placed on both the application server and the data server.
1709                 </para>
1710
1711                 <para>
1712                 As unsatisfactory as the answer might sound, it all depends on network and server load
1713                 characteristics.
1714                 </para>
1715
1716         </answer>
1717         </qandaentry>
1718
1719         <qandaentry>
1720         <question>
1721
1722             <para><indexterm>
1723                 <primary>NIS server</primary>
1724               </indexterm><indexterm>
1725                 <primary>LDAP</primary>
1726               </indexterm>
1727                 I've heard that you can store NIS accounts in LDAP. Is LDAP not just a smarter way to
1728                 run an NIS server?
1729                 </para>
1730
1731         </question>
1732         <answer>
1733
1734                 <para>
1735                 The correct answer to both questions is yes. But do understand that an LDAP server has
1736                 a configurable schema that can store far more information for many more purposes than
1737                 just NIS.
1738                 </para>
1739
1740         </answer>
1741         </qandaentry>
1742
1743         <qandaentry>
1744         <question>
1745
1746                 <para>
1747                 Can I use NIS in place of LDAP?
1748                 </para>
1749
1750         </question>
1751         <answer>
1752
1753             <para><indexterm>
1754                 <primary>NIS</primary>
1755               </indexterm><indexterm>
1756                 <primary>NIS schema</primary>
1757               </indexterm>
1758                 No. The NIS database does not have provision to store Microsoft encrypted passwords and does not deal
1759                 with the types of data necessary for interoperability with Microsoft Windows networking. The use
1760                 of LDAP with Samba requires the use of a number of schemas, one of which is the NIS schema, but also
1761                 a Samba-specific schema extension.
1762                 </para>
1763
1764         </answer>
1765         </qandaentry>
1766
1767         </qandaset>
1768
1769 </sect1>
1770
1771 </chapter>
1772