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>
7 There is something indeed mystical about things that are
8 big. Large networks exhibit a certain magnetism and exude a sense of
9 importance that obscures reality. You and I know that it is no more
10 difficult to secure a large network than it is a small one. We all
11 know that over and above a particular number of network clients, the
12 rules no longer change; the only real dynamic is the size of the domain
13 (much like a kingdom) over which the network ruler (oops, administrator)
14 has control. The real dynamic then transforms from the technical to the
15 political. Then again, that point is often reached well before the
16 kingdom (or queendom) grows large.
20 If you have systematically worked your way to this chapter, hopefully you
21 have found some gems and techniques that are applicable in your
22 world. The network designs you have worked with in this book have their
23 strong points as well as weak ones. That is to be expected given that
24 they are based on real business environments, the specifics of which are
25 molded to serve the purposes of this book.
29 This chapter is intent on wrapping up issues that are central to
30 implementation and design of progressively larger networks. Are you ready
31 for this chapter? Good, it is time to move on.
35 In previous chapters, you made the assumption that your network
36 administration staff need detailed instruction right down to the
37 nuts and bolts of implementing the solution. That is still the case,
38 but they have graduated now. You decide to document only those issues,
39 methods, and techniques that are new or complex. Routine tasks such as
40 implementing a DNS or a DHCP server are under control. Even the basics of
41 Samba are largely under control. So in this section you focus on the
42 specifics of implementing LDAP changes, Samba changes, and approach and
43 design of the solution and its deployment.
47 <title>Introduction</title>
50 Abmas is a miracle company. Most businesses would have collapsed under
51 the weight of rapid expansion that this company has experienced. Samba
52 is flexible, so there is no need to reinstall the whole operating
53 system just because you need to implement a new network design. In fact,
54 you can keep an old server running right up to the moment of cutover
55 and then do a near-live conversion. There is no need to reinstall a
56 Samba server just to change the way your network should function.
60 <indexterm><primary>LDAP</primary></indexterm>
61 Network growth is common to all organizations. In this exercise,
62 your preoccupation is with the mechanics of implementing Samba and
63 LDAP so that network users on each network segment can work
68 <title>Assignment Tasks</title>
71 Starting with the configuration files for the server called
72 <constant>MASSIVE</constant> in Chapter 5, you now deal with the
73 issues that are particular to large distributed networks. Your task
74 is simple &smbmdash; identify the challenges, consider the
75 alternatives, and then design and implement a solution.
79 <indexterm><primary>VPN</primary></indexterm>
80 Remember, you have users based in London (UK), Los Angeles,
81 Washington. DC, and, three buildings in New York. A significant portion
82 of your workforce have notebook computers and roam all over the
83 world. Some dial into the office, others use VPN connections over the
84 Internet, and others just move between buildings.i
88 What do you say to an employee who normally uses a desktop
89 system but must spend six weeks on the road with a notebook computer?
90 She is concerned about email access and how to keep coworkers current
91 with changing documents.
95 To top it all off, you have one network support person and one
96 help desk person based in London, a single person dedicated to all
97 network operations in Los Angeles, five staff for user administration
98 and help desk in New York, plus one <emphasis>floater</emphasis> for
103 You have outsourced all desktop deployment and management to
104 DirectPointe. Your concern is server maintenance and third-level
105 support. Build a plan and show what must be done.
112 <title>Dissection and Discussion</title>
115 <indexterm><primary>passdb backend</primary></indexterm>
116 <indexterm><primary>LDAP</primary></indexterm>
117 In <link linkend="happy"/>, you implemented an LDAP server that provided the
118 <parameter>passdb backend</parameter> for the Samba servers. You
119 explored ways to accelerate Windows desktop profile handling and you
120 took control of network performance.
124 <indexterm><primary>ldapsam</primary></indexterm>
125 <indexterm><primary>tdbsam</primary></indexterm>
126 <indexterm><primary>smbpasswd</primary></indexterm>
127 <indexterm><primary>replicated</primary></indexterm>
128 The implementation of an LDAP-based passdb backend (known as
129 <emphasis>ldapsam</emphasis> in Samba parlance), or some form of database
130 that can be distributed, is essential to permit the deployment of Samba
131 Primary and Backup Domain Controllers (PDC/BDCs). You see, the problem
132 is that the <emphasis>tdbsam</emphasis>-style passdb backend does not
133 lend itself to being replicated. The older plain-text-based
134 <emphasis>smbpasswd</emphasis>-style passdb backend can be replicated
135 using a tool such as <command>rsync</command>, but
136 <emphasis>smbpasswd</emphasis> suffers the drawback that it does not
137 support the range of account facilities demanded by modern network
142 <indexterm><primary>XML</primary></indexterm>
143 <indexterm><primary>SQL</primary></indexterm>
144 The new <emphasis>tdbsam</emphasis> facility supports functionality
145 that is similar to an <emphasis>ldapsam</emphasis>, but the lack of
146 distributed infrastructure sorely limits the scope for its
147 deployment. This raises the following questions: Why can't I just use
148 an XML-based backend, or for that matter, why not use an SQL-based
149 backend? Is support for these tools broken? Answers to these
150 questions require a bit of background.</para>
153 <indexterm><primary>directory</primary></indexterm>
154 <indexterm><primary>database</primary></indexterm>
155 <indexterm><primary>transaction processing</primary></indexterm>
156 <indexterm><primary>LDAP</primary></indexterm>
157 <emphasis>What is a directory?</emphasis> A directory is a
158 collection of information regarding objects that can be accessed to
159 rapidly find information that is relevant in a particular and
160 consistent manner. A directory differs from a database in that it is
161 generally more often searched (read) than updated. As a consequence, the
162 information is organized to facilitate read access rather than to
163 support transaction processing.</para>
166 <indexterm><primary>Lightweight Directory Access Protocol</primary><see>LDAP</see></indexterm>
167 <indexterm><primary>LDAP</primary></indexterm>
168 <indexterm><primary>master</primary></indexterm>
169 <indexterm><primary>slave</primary></indexterm>
170 The Lightweight Directory Access Protocol (LDAP) differs
171 considerably from a traditional database. It has a simple search
172 facility that uniquely makes a highly preferred mechanism for managing
173 user identities. LDAP provides a scalable mechanism for distributing
174 the data repository and for keeping all copies (slaves) in sync with
175 the master repository.</para>
178 <indexterm><primary>identity management</primary></indexterm>
179 <indexterm><primary>Active Directory</primary></indexterm>
180 <indexterm><primary>OpenLDAP</primary></indexterm>
181 Samba is a flexible and powerful file and print sharing
182 technology. It can use many external authentication sources and can be
183 part of a total authentication and identity management
184 infrastructure. The two most important external sources for large sites
185 are Microsoft Active Directory and LDAP. Sites that specifically wish to
186 avoid the proprietary implications of Microsoft Active Directory
187 naturally gravitate toward OpenLDAP.</para>
190 <indexterm><primary>network</primary><secondary>routed</secondary></indexterm>
191 In <link linkend="happy"/>, you had to deal with a locally routed
192 network. All deployment concerns focused around making users happy,
193 and that simply means taking control over all network practices and
194 usage so that no one user is disadvantaged by any other. The real
195 lesson is one of understanding that no matter how much network
196 bandwidth you provide, bandwidth remains a precious resource.</para>
198 <para>In this chapter, you must now consider how the overall network must
199 function. In particular, you must be concerned with users who move
200 between offices. You must take into account the way users need to
201 access information globally. And you must make the network robust
202 enough so that it can sustain partial breakdown without causing loss of
206 <title>Technical Issues</title>
209 There are at least three areas that need to be addressed as you
210 approach the challenge of designing a network solution for the newly
215 <listitem><para><indexterm><primary>mobility</primary></indexterm>
216 User needs such as mobility and data access</para></listitem>
218 <listitem><para>The nature of Windows networking protocols</para></listitem>
220 <listitem><para>Identity management infrastructure needs</para></listitem>
223 <para>Let's look at each in turn.</para>
226 <title>User Needs</title>
229 The new company has three divisions. Staff for each division are spread across
230 the company. Some staff are office-bound and some are mobile users. Mobile
231 users travel globally. Some spend considerable periods working in other offices.
232 Everyone wants to be able to work without constraint of productivity.
236 The challenge is not insignificant. In some parts of the world, even dial-up
237 connectivity is poor, while in other regions political encumbrances severely
238 curtail user needs. Parts of the global Internet infrastructure remain shielded
239 off for reasons outside the scope of this discussion.
243 <indexterm><primary>synchronize</primary></indexterm>
244 Decisions must be made regarding where data is to be stored, how it will be
245 replicated (if at all), and what the network bandwidth implications are. For
246 example, one decision that can be made is to give each office its own master
247 file storage area that can be synchronized to a central repository in New
248 York. This would permit global data to be backed up from a single location.
249 The synchronization tool could be <command>rsync,</command> run via a cron
250 job. Mobile users may use off-line file storage under Windows XP Professional.
251 This way, they can synchronize all files that have changed since each logon
256 <indexterm><primary>bandwidth</primary><secondary>requirements</secondary></indexterm>
257 <indexterm><primary>roaming profile</primary></indexterm>
258 No matter which way you look at this, the bandwidth requirements
259 for acceptable performance are substantial even if only 10 percent of
260 staff are global data users. A company with 3,500 employees,
261 280 of whom are mobile users who use a similarly distributed
262 network, found they needed at least 2 Mb/sec connectivity
263 between the UK and US offices. Even over 2 Mb/sec bandwidth, this
264 company abandoned any attempt to run roaming profile usage for
265 mobile users. At that time, the average roaming profile took 480
266 KB, while today the minimum Windows XP Professional roaming
267 profile involves a transfer of over 750 KB from the profile
268 server to and from the client.
272 <indexterm><primary>wide-area</primary></indexterm>
273 Obviously then, user needs and wide-area practicalities dictate the economic and
274 technical aspects of your network design as well as for standard operating procedures.
280 <title>The Nature of Windows Networking Protocols</title>
283 <indexterm><primary>profile</primary><secondary>mandatory</secondary></indexterm>
284 Network logons that include roaming profile handling requires from 140 KB to 2 MB.
285 The inclusion of support for a minimal set of common desktop applications can push
286 the size of a complete profile to over 15 MB. This has substantial implications
287 for location of user profiles. Additionally, it is a significant factor in
288 determining the nature and style of mandatory profiles that may be enforced as
289 part of a total service-level assurance program that might be implemented.
293 <indexterm><primary>logon traffic</primary></indexterm>
294 <indexterm><primary>redirected folders</primary></indexterm>
295 One way to reduce the network bandwidth impact of user logon
296 traffic is through folder redirection. In Chapter 5, you
297 implemented this in the new Windows XP Professional standard
298 desktop configuration. When desktop folders such as <guimenu>My
299 Documents</guimenu> are redirected to a network drive, they should
300 also be excluded from synchronization to and from the server on
301 logon or logout. Redirected folders are analogous to network drive
305 <para><indexterm><primary>application servers</primary></indexterm>
306 Of course, network applications should only be run off
307 local application servers. As a general rule, even with 2 Mb/sec
308 network bandwidth, it would not make sense at all for someone who
309 is working out of the London office to run applications off a
310 server that is located in New York.
314 <indexterm><primary>affordability</primary></indexterm>
315 When network bandwidth becomes a precious commodity (that is most
316 of the time), there is a significant demand to understand network
317 processes and to mold the limits of acceptability around the
318 constraints of affordability.
322 When a Windows NT4/200x/XP Professional client user logs onto
323 the network, several important things must happen.
328 <indexterm><primary>DHCP</primary></indexterm>
329 The client obtains an IP address via DHCP. (DHCP is
330 necessary so that users can roam between offices.)
334 <indexterm><primary>WINS</primary></indexterm>
335 <indexterm><primary>DNS</primary></indexterm>
336 The client must register itself with the WINS and/or DNS server.
340 <indexterm><primary>Domain Controller</primary><secondary>closest</secondary></indexterm>
341 The client must locate the closest domain controller.
345 The client must log onto a domain controller and obtain as part of
346 that process the location of the user's profile, load it, connect to
347 redirected folders, and establish all network drive and printer connections.
351 The domain controller must be able to resolve the user's
352 credentials before the logon process is fully implemented.
357 Given that this book is about Samba and that it implements the Windows
358 NT4-style domain semantics, it makes little sense to compare Samba with
359 Microsoft Active Directory insofar as the logon protocols and principles
360 of operation are concerned. The following information pertains exclusively
361 to the interaction between a Windows XP Professional workstation and a
362 Samba-3.0.20 server. In the discussion that follows, use is made of DHCP and WINS.
366 As soon as the Windows workstation starts up, it obtains an
367 IP address. This is immediately followed by registration of its
368 name both by broadcast and Unicast registration that is directed
373 <indexterm><primary>Unicast</primary></indexterm>
374 <indexterm><primary>broadcast</primary><secondary>directed</secondary>
375 </indexterm><indexterm><primary>NetBIOS</primary></indexterm>
376 Given that the client is already a domain member, it then sends
377 a directed (Unicast) request to the WINS server seeking the list of
378 IP addresses for domain controllers (NetBIOS name type 0x1C). The
379 WINS server replies with the information requested.</para>
382 <indexterm><primary>broadcast</primary><secondary>mailslot</secondary></indexterm>
383 <indexterm><primary>Unicast</primary></indexterm>
384 <indexterm><primary>WINS</primary></indexterm>
385 The client sends two netlogon mailslot broadcast requests
386 to the local network and to each of the IP addresses returned by
387 the WINS server. Whichever answers this request first appears to
388 be the machine that the Windows XP client attempts to use to
389 process the network logon. The mailslot messages use UDP broadcast
390 to the local network and UDP Unicast directed at each machine that
391 was listed in the WINS server response to a request for the list of
396 <indexterm><primary>protocol</primary><secondary>negotiation</secondary></indexterm>
397 <indexterm><primary>logon server</primary></indexterm>
398 <indexterm><primary>fail</primary></indexterm>
399 The logon process begins with negotiation of the SMB/CIFS
400 protocols that are to be used; this is followed by an exchange of
401 information that ultimately includes the client sending the
402 credentials with which the user is attempting to logon. The logon
403 server must now approve the further establishment of the
404 connection, but that is a good point to halt for now. The priority
405 here must center around identification of network infrastructure
406 needs. A secondary fact we need to know is, what happens when
407 local domain controllers fail or break?
411 <indexterm><primary>Domain Controller</primary></indexterm>
412 <indexterm><primary>PDC</primary></indexterm>
413 <indexterm><primary>BDC</primary></indexterm>
414 <indexterm><primary>netlogon</primary></indexterm>
415 Under most circumstances, the nearest domain controller
416 responds to the netlogon mailslot broadcast. The exception to this
417 norm occurs when the nearest domain controller is too busy or is out
418 of service. Herein lies an important fact. This means it is
419 important that every network segment should have at least two
420 domain controllers. Since there can be only one PDC, all additional
421 domain controllers are by definition BDCs.
425 <indexterm><primary>authentication</primary></indexterm>
426 <indexterm><primary>Identity Management</primary></indexterm>
427 The provision of sufficient servers that are BDCs is an
428 important design factor. The second important design factor
429 involves how each of the BDCs obtains user authentication
430 data. That is the subject of the next section, which involves key
431 decisions regarding Identity Management facilities.
437 <title>Identity Management Needs</title>
440 <indexterm><primary>privacy</primary></indexterm>
441 <indexterm><primary>user credentials</primary></indexterm>
442 <indexterm><primary>validated</primary></indexterm>
443 <indexterm><primary>privileges</primary></indexterm>
444 Network managers recognize that in large organizations users
445 generally need to be given resource access based on needs, while
446 being excluded from other resources for reasons of privacy. It is
447 therefore essential that all users identify themselves at the
448 point of network access. The network logon is the principal means
449 by which user credentials are validated and filtered and appropriate
450 rights and privileges are allocated.
454 <indexterm><primary>Identity Management</primary></indexterm>
455 <indexterm><primary>Yellow Pages</primary></indexterm>
456 <indexterm><primary>NIS</primary></indexterm>
457 Unfortunately, network resources tend to have their own Identity
458 Management facilities, the quality and manageability of which varies
459 from quite poor to exceptionally good. Corporations that use a mixture
460 of systems soon discover that until recently, few systems were
461 designed to interoperate. For example, UNIX systems each have an
462 independent user database. Sun Microsystems developed a facility that
463 was originally called <constant>Yellow Pages</constant>, and was renamed
464 when a telephone company objected to the use of its trademark.
465 What was once called <constant>Yellow Pages</constant> is today known
466 as <constant>Network Information System</constant> (NIS).
470 <indexterm><primary>NIS+</primary></indexterm>
471 NIS gained a strong following throughout the UNIX/VMS space in a short
472 period of time and retained that appeal and use for over a decade.
473 Security concerns and inherent limitations have caused it to enter its
474 twilight. NIS did not gain widespread appeal outside of the UNIX world
475 and was not universally adopted. Sun updated this to a more secure
476 implementation called NIS+, but even it has fallen victim to changing
477 demands as the demand for directory services that can be coupled with
478 other information systems is catching on.
483 <indexterm><primary>NIS</primary></indexterm>
484 <indexterm><primary>government</primary></indexterm>
485 <indexterm><primary>education</primary></indexterm>
486 Nevertheless, both NIS and NIS+ continue to hold ground in
487 business areas where UNIX still has major sway. Examples of
488 organizations that remain firmly attached to the use of NIS and
489 NIS+ include large government departments, education institutions,
490 and large corporations that have a scientific or engineering
495 <indexterm><primary>scalable</primary></indexterm>
496 <indexterm><primary>distributed</primary></indexterm>
497 Today's networking world needs a scalable, distributed Identity
498 Management infrastructure, commonly called a directory. The most
499 popular technologies today are Microsoft Active Directory service
500 and a number of LDAP implementations.
504 <primary>multiple directories</primary>
506 The problem of managing multiple directories has become a focal
507 point over the past decade, creating a large market for
508 metadirectory products and services that allow organizations that
509 have multiple directories and multiple management and control
510 centers to provision information from one directory into
511 another. The attendant benefit to end users is the promise of
512 having to remember and deal with fewer login identities and
516 <primary>network</primary>
517 <secondary>bandwidth</secondary>
519 The challenge of every large network is to find the optimum
520 balance of internal systems and facilities for Identity
521 Management resources. How well the solution is chosen and
522 implemented has potentially significant impact on network bandwidth
523 and systems response needs.</para>
526 <primary>LDAP server</primary>
527 </indexterm><indexterm>
528 <primary>LDAP</primary>
529 <secondary>master</secondary>
530 </indexterm><indexterm>
531 <primary>LDAP</primary>
532 <secondary>slave</secondary>
534 In Chapter 5, you implemented a single LDAP server for the
535 entire network. This may work for smaller networks, but almost
536 certainly fails to meet the needs of large and complex networks. The
537 following section documents how you may implement a single
538 master LDAP server with multiple slave servers.</para>
540 <para>What is the best method for implementing master/slave LDAP
541 servers within the context of a distributed 2,000-user network is a
542 question that remains to be answered.</para>
545 <indexterm><primary>distributed domain</primary></indexterm>
546 <indexterm><primary>wide-area</primary></indexterm>
547 One possibility that has great appeal is to create a single,
548 large distributed domain. The practical implications of this
549 design (see <link linkend="chap7net"/>) demands the placement of
550 sufficient BDCs in each location. Additionally, network
551 administrators must make sure that profiles are not transferred
552 over the wide-area links, except as a totally unavoidable
553 measure. Network design must balance the risk of loss of user
554 productivity against the cost of network management and
559 <indexterm><primary>domain name space</primary></indexterm>
560 The network design in <link linkend="chap7net2"/> takes the approach
561 that management of networks that are too remote to be managed
562 effectively from New York ought to be given a certain degree of
563 autonomy. With this rationale, the Los Angeles and London networks,
564 though fully integrated with those on the East Coast, each have their
565 own domain name space and can be independently managed and controlled.
566 One of the key drawbacks of this design is that it flies in the face of
567 the ability for network users to roam globally without some compromise
568 in how they may access global resources.
572 <indexterm><primary>interdomain trusts</primary></indexterm>
573 Desk-bound users need not be negatively affected by this design, since
574 the use of interdomain trusts can be used to satisfy the need for global
579 <indexterm><primary>LDAP</primary></indexterm>
580 <indexterm><primary>LDAP</primary><secondary>backend</secondary></indexterm>
581 <indexterm><primary>SID</primary></indexterm>
582 When Samba-3 is configured to use an LDAP backend, it stores the domain
583 account information in a directory entry. This account entry contains the
584 domain SID. An unintended but exploitable side effect is that this makes it
585 possible to operate with more than one PDC on a distributed network.
589 <indexterm><primary>WINS</primary></indexterm>
590 <indexterm><primary>wins.dat</primary></indexterm>
591 <indexterm><primary>SID</primary></indexterm>
592 How might this peculiar feature be exploited? The answer is simple. It is
593 imperative that each network segment have its own WINS server. Major
594 servers on remote network segments can be given a static WINS entry in
595 the <filename>wins.dat</filename> file on each WINS server. This allows
596 all essential data to be visible from all locations. Each location would,
597 however, function as if it is an independent domain, while all sharing the
598 same domain SID. Since all domain account information can be stored in a
599 single LDAP backend, users have unfettered ability to roam.
603 <indexterm><primary>NetBIOS name</primary><secondary>aliases</secondary></indexterm>
604 <indexterm><primary>fail-over</primary></indexterm>
605 This concept has not been exhaustively validated, though we can see no reason
606 why this should not work. The important facets are the following: The name of
607 the domain must be identical in all locations. Each network segment must have
608 its own WINS server. The name of the PDC must be the same in all locations; this
609 necessitates the use of NetBIOS name aliases for each PDC so that they can be
610 accessed globally using the alias and not the PDC's primary name. A single master
611 LDAP server can be based in New York, with multiple LDAP slave servers located
612 on every network segment. Finally, the BDCs should each use failover LDAP servers
613 that are in fact slave LDAP servers on the local segments.
617 <indexterm><primary>LDAP</primary><secondary>updates</secondary></indexterm>
618 <indexterm><primary>domain tree</primary></indexterm>
619 <indexterm><primary>LDAP</primary><secondary>database</secondary></indexterm>
620 <indexterm><primary>LDAP</primary><secondary>directory</secondary></indexterm>
621 With a single master LDAP server, all network updates are effected on a single
622 server. In the event that this should become excessively fragile or network
623 bandwidth limiting, one could implement a delegated LDAP domain. This is also
624 known as a partitioned (or multiple partition) LDAP database and as a distributed
629 As the LDAP directory grows, it becomes increasingly important
630 that its structure is implemented in a manner that mirrors
631 organizational needs, so as to limit network update and
632 referential traffic. It should be noted that all directory
633 administrators must of necessity follow the same standard
634 procedures for managing the directory, because retroactive correction of
635 inconsistent directory information can be exceedingly difficult.
638 <image id="chap7net">
639 <imagedescription>Network Topology &smbmdash; 2000 User Complex Design A</imagedescription>
640 <imagefile scale="70">chap7-net-Ar</imagefile>
643 <image id="chap7net2">
644 <imagedescription>Network Topology &smbmdash; 2000 User Complex Design B</imagedescription>
645 <imagefile scale="70">chap7-net2-Br</imagefile>
654 <title>Political Issues</title>
657 As organizations grow, the number of points of control increases
658 also. In a large distributed organization, it is important that the
659 Identity Management system be capable of being updated from
660 many locations, and it is equally important that changes made should
661 become usable in a reasonable period, typically
662 minutes rather than days (the old limitation of highly manual
671 <title>Implementation</title>
674 <indexterm><primary>winbind</primary></indexterm>
675 <indexterm><primary>LDAP</primary></indexterm>
676 <indexterm><primary>UID</primary></indexterm>
677 <indexterm><primary>GID</primary></indexterm>
678 Samba-3 has the ability to use multiple password (authentication and
679 identity resolution) backends. The diagram in <link linkend="chap7idres"/>
680 demonstrates how Samba uses winbind, LDAP, and NIS, the traditional system
681 password database. The diagram only documents the mechanisms for
682 authentication and identity resolution (obtaining a UNIX UID/GID)
683 using the specific systems shown.
686 <image id="chap7idres">
687 <imagedescription>Samba and Authentication Backend Search Pathways</imagedescription>
688 <imagefile scale="55">chap7-idresol</imagefile>
692 <indexterm><primary>smbpasswd</primary></indexterm>
693 <indexterm><primary>xmlsam</primary></indexterm>
694 <indexterm><primary>SMB passwords</primary></indexterm>
695 <indexterm><primary>tdbsam</primary></indexterm>
696 <indexterm><primary>mysqlsam</primary></indexterm>
697 <indexterm><primary>LDAP</primary></indexterm>
698 <indexterm><primary>distributed</primary></indexterm>
699 Samba is capable of using the <constant>smbpasswd</constant>,
700 <constant>tdbsam</constant>, <constant>xmlsam</constant>,
701 and <constant>mysqlsam</constant> authentication databases. The SMB
702 passwords can, of course, also be stored in an LDAP ldapsam
703 backend. LDAP is the preferred passdb backend for distributed network
708 <indexterm><primary>passdb backend</primary></indexterm>
709 Additionally, it is possible to use multiple passdb backends
710 concurrently as well as have multiple LDAP backends. As a result, you
711 can specify a failover LDAP backend. The syntax for specifying a
712 single LDAP backend in &smb.conf; is:
715 passdb backend = ldapsam:ldap://master.abmas.biz
718 This configuration tells Samba to use a single LDAP server, as shown in <link linkend="ch7singleLDAP"/>.
719 <image id="ch7singleLDAP">
720 <imagedescription>Samba Configuration to Use a Single LDAP Server</imagedescription>
721 <imagefile scale="65">ch7-singleLDAP</imagefile>
723 <indexterm><primary>LDAP</primary><secondary>fail-over</secondary></indexterm>
724 <indexterm><primary>fail-over</primary></indexterm>
725 The addition of a failover LDAP server can simply be done by adding a
726 second entry for the failover server to the single <parameter>ldapsam</parameter>
727 entry, as shown here (note the particular use of the double quotes):
730 passdb backend = ldapsam:"ldap://master.abmas.biz \
731 ldap://slave.abmas.biz"
734 This configuration tells Samba to use a master LDAP server, with failover to a slave server if necessary,
735 as shown in <link linkend="ch7dualLDAP"/>.
736 <image id="ch7dualLDAP">
737 <imagedescription>Samba Configuration to Use a Dual (Fail-over) LDAP Server</imagedescription>
738 <imagefile scale="65">ch7-fail-overLDAP</imagefile>
743 Some folks have tried to implement this without the use of double quotes. This is the type of entry they
747 passdb backend = ldapsam:ldap://master.abmas.biz \
748 ldapsam:ldap://slave.abmas.biz
751 <indexterm><primary>contiguous directory</primary></indexterm>
752 The effect of this style of entry is that Samba lists the users
753 that are in both LDAP databases. If both contain the same information,
754 it results in each record being shown twice. This is, of course, not the
755 solution desired for a failover implementation. The net effect of this
756 configuration is shown in <link linkend="ch7dualadd"/>
759 <image id="ch7dualadd">
760 <imagedescription>Samba Configuration to Use Dual LDAP Databases - Broken - Do Not Use!</imagedescription>
761 <imagefile scale="55">ch7-dual-additive-LDAP</imagefile>
765 If, however, each LDAP database contains unique information, this may
766 well be an advantageous way to effectively integrate multiple LDAP databases
767 into one seemingly contiguous directory. Only the first database will be updated.
768 An example of this configuration is shown in <link linkend="ch7dualok"/>.
771 <image id="ch7dualok">
772 <imagedescription>Samba Configuration to Use Two LDAP Databases - The result is additive.</imagedescription>
773 <imagefile scale="55">ch7-dual-additive-LDAP-Ok</imagefile>
777 When the use of ldapsam is specified twice, as shown here, it is imperative
778 that the two LDAP directories must be disjoint. If the entries are for a
779 master LDAP server as well as its own slave server, updates to the LDAP
780 database may end up being lost or corrupted. You may safely use multiple
781 LDAP backends only if both are entirely separate from each other.
785 It is assumed that the network you are working with follows in a
786 pattern similar to what was covered in Chapter 5. The following steps
787 permit the operation of a master/slave OpenLDAP arrangement.
793 <indexterm><primary>SUSE Linux</primary></indexterm>
794 <indexterm><primary>Red Hat Linux</primary></indexterm>
795 Log onto the master LDAP server as <constant>root</constant>.
796 You are about to change the configuration of the LDAP server, so it
797 makes sense to temporarily halt it. Stop OpenLDAP from running on
798 SUSE Linux by executing:
800 &rootprompt; rcldap stop
802 On Red Hat Linux, you can do this by executing:
804 &rootprompt; service ldap stop
809 <indexterm><primary>/etc/openldap/slapd.conf</primary></indexterm>
810 Edit the <filename>/etc/openldap/slapd.conf</filename> file so it
811 matches the content of <link linkend="ch7-LDAP-master"/>.
815 Create a file called <filename>admin-accts.ldif</filename> with the following contents:
817 dn: cn=updateuser,dc=abmas,dc=biz
821 userPassword: not24get
823 dn: cn=sambaadmin,dc=abmas,dc=biz
827 userPassword: buttercup
832 Add an account called <quote>updateuser</quote> to the master LDAP server as shown here:
834 &rootprompt; slapadd -v -l admin-accts.ldif
839 <indexterm><primary>LDIF</primary></indexterm>
840 <indexterm><primary>LDAP</primary><secondary>preload</secondary></indexterm>
841 Change directory to a suitable place to dump the contents of the
842 LDAP server. The dump file (and LDIF file) is used to preload
843 the slave LDAP server database. You can dump the database by executing:
845 &rootprompt; slapcat -v -l LDAP-transfer-LDIF.txt
847 Each record is written to the file.
851 <indexterm><primary>LDAP-transfer-LDIF.txt</primary></indexterm>
852 Copy the file <filename>LDAP-transfer-LDIF.txt</filename> to the intended
853 slave LDAP server. A good location could be in the directory
854 <filename>/etc/openldap/preload</filename>.
858 Log onto the slave LDAP server as <constant>root</constant>. You can
859 now configure this server so the <filename>/etc/openldap/slapd.conf</filename>
860 file matches the content of <link linkend="ch7-LDAP-slave"/>.
864 Change directory to the location in which you stored the
865 <filename>LDAP-transfer-LDIF.txt</filename> file (<filename>/etc/openldap/preload</filename>).
866 While in this directory, execute:
868 &rootprompt; slapadd -v -l LDAP-transfer-LDIF.txt
870 If all goes well, the following output confirms that the data is being loaded
873 added: "dc=abmas,dc=biz" (00000001)
874 added: "cn=sambaadmin,dc=abmas,dc=biz" (00000002)
875 added: "cn=updateuser,dc=abmas,dc=biz" (00000003)
876 added: "ou=People,dc=abmas,dc=biz" (00000004)
877 added: "ou=Groups,dc=abmas,dc=biz" (00000005)
878 added: "ou=Computers,dc=abmas,dc=biz" (00000006)
879 added: "uid=Administrator,ou=People,dc=abmas,dc=biz" (00000007)
880 added: "uid=nobody,ou=People,dc=abmas,dc=biz" (00000008)
881 added: "cn=Domain Admins,ou=Groups,dc=abmas,dc=biz" (00000009)
882 added: "cn=Domain Users,ou=Groups,dc=abmas,dc=biz" (0000000a)
883 added: "cn=Domain Guests,ou=Groups,dc=abmas,dc=biz" (0000000b)
884 added: "uid=bobj,ou=People,dc=abmas,dc=biz" (0000000c)
885 added: "sambaDomainName=MEGANET2,dc=abmas,dc=biz" (0000000d)
886 added: "uid=stans,ou=People,dc=abmas,dc=biz" (0000000e)
887 added: "uid=chrisr,ou=People,dc=abmas,dc=biz" (0000000f)
888 added: "uid=maryv,ou=People,dc=abmas,dc=biz" (00000010)
889 added: "cn=Accounts,ou=Groups,dc=abmas,dc=biz" (00000011)
890 added: "cn=Finances,ou=Groups,dc=abmas,dc=biz" (00000012)
891 added: "cn=PIOps,ou=Groups,dc=abmas,dc=biz" (00000013)
896 Now start the LDAP server and set it to run automatically on system reboot by executing:
898 &rootprompt; rcldap start
899 &rootprompt; chkconfig ldap on
901 On Red Hat Linux, execute the following:
903 &rootprompt; service ldap start
904 &rootprompt; chkconfig ldap on
909 <indexterm><primary>chkconfig</primary></indexterm>
910 <indexterm><primary>service</primary></indexterm>
911 <indexterm><primary>rcldap</primary></indexterm>
912 Go back to the master LDAP server. Execute the following to start LDAP as well
913 as <command>slurpd</command>, the synchronization daemon, as shown here:
915 &rootprompt; rcldap start
916 &rootprompt; chkconfig ldap on
917 &rootprompt; rcslurpd start
918 &rootprompt; chkconfig slurpd on
920 <indexterm><primary>slurpd</primary></indexterm>
921 On Red Hat Linux, check the equivalent command to start <command>slurpd</command>.
925 <indexterm><primary>smbldap-useradd</primary></indexterm>
926 On the master LDAP server you may now add an account to validate that replication
927 is working. Assuming the configuration shown in Chapter 5, execute:
929 &rootprompt; /var/lib/samba/sbin/smbldap-useradd -a fruitloop
934 On the slave LDAP server, change to the directory <filename>/var/lib/ldap</filename>.
935 There should now be a file called <filename>replogfile</filename>. If replication worked
936 as expected, the content of this file should be:
939 dn: uid=fruitloop,ou=People,dc=abmas,dc=biz
941 replace: sambaProfilePath
942 sambaProfilePath: \\MASSIVE\profiles\fruitloop
944 replace: sambaHomePath
945 sambaHomePath: \\MASSIVE\homes
948 entryCSN: 2003122700:43:38Z#0x0005#0#0000
950 replace: modifiersName
951 modifiersName: cn=Manager,dc=abmas,dc=biz
953 replace: modifyTimestamp
954 modifyTimestamp: 20031227004338Z
960 Given that this first slave LDAP server is now working correctly, you may now
961 implement additional slave LDAP servers as required.
966 <example id="ch7-LDAP-master">
967 <title>LDAP Master Server Configuration File &smbmdash; <filename>/etc/openldap/slapd.conf</filename></title>
969 include /etc/openldap/schema/core.schema
970 include /etc/openldap/schema/cosine.schema
971 include /etc/openldap/schema/inetorgperson.schema
972 include /etc/openldap/schema/nis.schema
973 include /etc/openldap/schema/samba.schema
975 pidfile /var/run/slapd/slapd.pid
976 argsfile /var/run/slapd/slapd.args
979 suffix "dc=abmas,dc=biz"
980 rootdn "cn=Manager,dc=abmas,dc=biz"
983 rootpw {SSHA}86kTavd9Dw3FAz6qzWTrCOKX/c0Qe+UV
985 replica host=lapdc.abmas.biz:389
986 suffix="dc=abmas,dc=biz"
987 binddn="cn=updateuser,dc=abmas,dc=biz"
988 bindmethod=simple credentials=not24get
990 access to attrs=sambaLMPassword,sambaNTPassword
991 by dn="cn=updateuser,dc=abmas,dc=biz" write
994 replogfile /var/lib/ldap/replogfile
996 directory /var/lib/ldap
998 # Indices to maintain
1000 index cn pres,sub,eq
1001 index sn pres,sub,eq
1002 index uid pres,sub,eq
1003 index displayName pres,sub,eq
1008 index sambaPrimaryGroupSID eq
1009 index sambaDomainName eq
1014 <example id="ch7-LDAP-slave">
1015 <title>LDAP Slave Configuration File &smbmdash; <filename>/etc/openldap/slapd.conf</filename></title>
1017 include /etc/openldap/schema/core.schema
1018 include /etc/openldap/schema/cosine.schema
1019 include /etc/openldap/schema/inetorgperson.schema
1020 include /etc/openldap/schema/nis.schema
1021 include /etc/openldap/schema/samba.schema
1023 pidfile /var/run/slapd/slapd.pid
1024 argsfile /var/run/slapd/slapd.args
1027 suffix "dc=abmas,dc=biz"
1028 rootdn "cn=Manager,dc=abmas,dc=biz"
1031 rootpw {SSHA}86kTavd9Dw3FAz6qzWTrCOKX/c0Qe+UV
1034 by dn=cn=updateuser,dc=abmas,dc=biz write
1037 updatedn cn=updateuser,dc=abmas,dc=biz
1038 updateref ldap://massive.abmas.biz
1040 directory /var/lib/ldap
1042 # Indices to maintain
1043 index objectClass eq
1044 index cn pres,sub,eq
1045 index sn pres,sub,eq
1046 index uid pres,sub,eq
1047 index displayName pres,sub,eq
1052 index sambaPrimaryGroupSID eq
1053 index sambaDomainName eq
1058 <smbconfexample id="ch7-massmbconfA">
1059 <title>Primary Domain Controller &smb.conf; File &smbmdash; Part A</title>
1060 <smbconfcomment>Global parameters</smbconfcomment>
1061 <smbconfsection name="[global]"/>
1062 <smbconfoption name="unix charset">LOCALE</smbconfoption>
1063 <smbconfoption name="workgroup">MEGANET2</smbconfoption>
1064 <smbconfoption name="passdb backend">ldapsam:ldap://massive.abmas.biz</smbconfoption>
1065 <smbconfoption name="username map">/etc/samba/smbusers</smbconfoption>
1066 <smbconfoption name="log level">1</smbconfoption>
1067 <smbconfoption name="syslog">0</smbconfoption>
1068 <smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
1069 <smbconfoption name="max log size">0</smbconfoption>
1070 <smbconfoption name="smb ports">139 445</smbconfoption>
1071 <smbconfoption name="name resolve order">wins bcast hosts</smbconfoption>
1072 <smbconfoption name="time server">Yes</smbconfoption>
1073 <smbconfoption name="printcap name">CUPS</smbconfoption>
1074 <smbconfoption name="add user script">/opt/IDEALX/sbin/smbldap-useradd -m '%u'</smbconfoption>
1075 <smbconfoption name="delete user script">/opt/IDEALX/sbin/smbldap-userdel '%u'</smbconfoption>
1076 <smbconfoption name="add group script">/opt/IDEALX/sbin/smbldap-groupadd -p '%g'</smbconfoption>
1077 <smbconfoption name="delete group script">/opt/IDEALX/sbin/smbldap-groupdel '%g'</smbconfoption>
1078 <smbconfoption name="add user to group script">/opt/IDEALX/sbin/</smbconfoption>
1079 <member><parameter>smbldap-groupmod -m '%g' '%u'</parameter></member>
1080 <smbconfoption name="delete user from group script">/opt/IDEALX/sbin/</smbconfoption>
1081 <member><parameter>smbldap-groupmod -x '%g' '%u'</parameter></member>
1082 <smbconfoption name="set primary group script">/opt/IDEALX/sbin/</smbconfoption>
1083 <member><parameter>smbldap-usermod -g '%g' '%u'</parameter></member>
1084 <smbconfoption name="add machine script">/opt/IDEALX/sbin/</smbconfoption>
1085 <member><parameter>smbldap-useradd -w '%u'</parameter></member>
1086 <smbconfoption name="shutdown script">/var/lib/samba/scripts/shutdown.sh</smbconfoption>
1087 <smbconfoption name="abort shutdown script">/sbin/shutdown -c</smbconfoption>
1088 <smbconfoption name="logon script">scripts\logon.bat</smbconfoption>
1089 <smbconfoption name="logon path">\\%L\profiles\%U</smbconfoption>
1090 <smbconfoption name="logon drive">X:</smbconfoption>
1091 <smbconfoption name="domain logons">Yes</smbconfoption>
1092 <smbconfoption name="domain master">Yes</smbconfoption>
1093 <smbconfoption name="wins support">Yes</smbconfoption>
1094 <smbconfoption name="ldap suffix">dc=abmas,dc=biz</smbconfoption>
1095 <smbconfoption name="ldap machine suffix">ou=People</smbconfoption>
1096 <smbconfoption name="ldap user suffix">ou=People</smbconfoption>
1097 <smbconfoption name="ldap group suffix">ou=Groups</smbconfoption>
1098 <smbconfoption name="ldap idmap suffix">ou=Idmap</smbconfoption>
1099 <smbconfoption name="ldap admin dn">cn=Manager,dc=abmas,dc=biz</smbconfoption>
1100 <smbconfoption name="idmap backend">ldap://massive.abmas.biz</smbconfoption>
1101 <smbconfoption name="idmap uid">10000-20000</smbconfoption>
1102 <smbconfoption name="idmap gid">10000-20000</smbconfoption>
1103 <smbconfoption name="printer admin">root</smbconfoption>
1104 <smbconfoption name="printing">cups</smbconfoption>
1107 <smbconfexample id="ch7-massmbconfB">
1108 <title>Primary Domain Controller &smb.conf; File &smbmdash; Part B</title>
1109 <smbconfsection name="[IPC$]"/>
1110 <smbconfoption name="path">/tmp</smbconfoption>
1112 <smbconfsection name="[accounts]"/>
1113 <smbconfoption name="comment">Accounting Files</smbconfoption>
1114 <smbconfoption name="path">/data/accounts</smbconfoption>
1115 <smbconfoption name="read only">No</smbconfoption>
1117 <smbconfsection name="[service]"/>
1118 <smbconfoption name="comment">Financial Services Files</smbconfoption>
1119 <smbconfoption name="path">/data/service</smbconfoption>
1120 <smbconfoption name="read only">No</smbconfoption>
1122 <smbconfsection name="[pidata]"/>
1123 <smbconfoption name="comment">Property Insurance Files</smbconfoption>
1124 <smbconfoption name="path">/data/pidata</smbconfoption>
1125 <smbconfoption name="read only">No</smbconfoption>
1127 <smbconfsection name="[homes]"/>
1128 <smbconfoption name="comment">Home Directories</smbconfoption>
1129 <smbconfoption name="valid users">%S</smbconfoption>
1130 <smbconfoption name="read only">No</smbconfoption>
1131 <smbconfoption name="browseable">No</smbconfoption>
1133 <smbconfsection name="[printers]"/>
1134 <smbconfoption name="comment">SMB Print Spool</smbconfoption>
1135 <smbconfoption name="path">/var/spool/samba</smbconfoption>
1136 <smbconfoption name="guest ok">Yes</smbconfoption>
1137 <smbconfoption name="printable">Yes</smbconfoption>
1138 <smbconfoption name="browseable">No</smbconfoption>
1141 <smbconfexample id="ch7-massmbconfC">
1142 <title>Primary Domain Controller &smb.conf; File &smbmdash; Part C</title>
1143 <smbconfsection name="[apps]"/>
1144 <smbconfoption name="comment">Application Files</smbconfoption>
1145 <smbconfoption name="path">/apps</smbconfoption>
1146 <smbconfoption name="admin users">bjones</smbconfoption>
1147 <smbconfoption name="read only">No</smbconfoption>
1149 <smbconfsection name="[netlogon]"/>
1150 <smbconfoption name="comment">Network Logon Service</smbconfoption>
1151 <smbconfoption name="path">/var/lib/samba/netlogon</smbconfoption>
1152 <smbconfoption name="admin users">root, Administrator</smbconfoption>
1153 <smbconfoption name="guest ok">Yes</smbconfoption>
1154 <smbconfoption name="locking">No</smbconfoption>
1156 <smbconfsection name="[profiles]"/>
1157 <smbconfoption name="comment">Profile Share</smbconfoption>
1158 <smbconfoption name="path">/var/lib/samba/profiles</smbconfoption>
1159 <smbconfoption name="read only">No</smbconfoption>
1160 <smbconfoption name="profile acls">Yes</smbconfoption>
1162 <smbconfsection name="[profdata]"/>
1163 <smbconfoption name="comment">Profile Data Share</smbconfoption>
1164 <smbconfoption name="path">/var/lib/samba/profdata</smbconfoption>
1165 <smbconfoption name="read only">No</smbconfoption>
1166 <smbconfoption name="profile acls">Yes</smbconfoption>
1168 <smbconfsection name="[print$]"/>
1169 <smbconfoption name="comment">Printer Drivers</smbconfoption>
1170 <smbconfoption name="path">/var/lib/samba/drivers</smbconfoption>
1171 <smbconfoption name="write list">root</smbconfoption>
1172 <smbconfoption name="admin users">root, Administrator</smbconfoption>
1175 <smbconfexample id="ch7-slvsmbocnfA">
1176 <title>Backup Domain Controller &smb.conf; File &smbmdash; Part A</title>
1177 <smbconfcomment># Global parameters</smbconfcomment>
1178 <smbconfsection name="[global]"/>
1179 <smbconfoption name="unix charset">LOCALE</smbconfoption>
1180 <smbconfoption name="workgroup">MEGANET2</smbconfoption>
1181 <smbconfoption name="netbios name">BLDG1</smbconfoption>
1182 <smbconfoption name="passdb backend">ldapsam:ldap://lapdc.abmas.biz</smbconfoption>
1183 <smbconfoption name="username map">/etc/samba/smbusers</smbconfoption>
1184 <smbconfoption name="log level">1</smbconfoption>
1185 <smbconfoption name="syslog">0</smbconfoption>
1186 <smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
1187 <smbconfoption name="max log size">50</smbconfoption>
1188 <smbconfoption name="smb ports">139 445</smbconfoption>
1189 <smbconfoption name="name resolve order">wins bcast hosts</smbconfoption>
1190 <smbconfoption name="printcap name">CUPS</smbconfoption>
1191 <smbconfoption name="show add printer wizard">No</smbconfoption>
1192 <smbconfoption name="logon script">scripts\logon.bat</smbconfoption>
1193 <smbconfoption name="logon path">\\%L\profiles\%U</smbconfoption>
1194 <smbconfoption name="logon drive">X:</smbconfoption>
1195 <smbconfoption name="domain logons">Yes</smbconfoption>
1196 <smbconfoption name="os level">63</smbconfoption>
1197 <smbconfoption name="domain master">No</smbconfoption>
1198 <smbconfoption name="wins server">192.168.2.1</smbconfoption>
1199 <smbconfoption name="ldap suffix">dc=abmas,dc=biz</smbconfoption>
1200 <smbconfoption name="ldap machine suffix">ou=People</smbconfoption>
1201 <smbconfoption name="ldap user suffix">ou=People</smbconfoption>
1202 <smbconfoption name="ldap group suffix">ou=Groups</smbconfoption>
1203 <smbconfoption name="ldap idmap suffix">ou=Idmap</smbconfoption>
1204 <smbconfoption name="ldap admin dn">cn=Manager,dc=abmas,dc=biz</smbconfoption>
1205 <smbconfoption name="utmp">Yes</smbconfoption>
1206 <smbconfoption name="idmap backend">ldap://massive.abmas.biz</smbconfoption>
1207 <smbconfoption name="idmap uid">10000-20000</smbconfoption>
1208 <smbconfoption name="idmap gid">10000-20000</smbconfoption>
1209 <smbconfoption name="printing">cups</smbconfoption>
1211 <smbconfsection name="[accounts]"/>
1212 <smbconfoption name="comment">Accounting Files</smbconfoption>
1213 <smbconfoption name="path">/data/accounts</smbconfoption>
1214 <smbconfoption name="read only">No</smbconfoption>
1216 <smbconfsection name="[service]"/>
1217 <smbconfoption name="comment">Financial Services Files</smbconfoption>
1218 <smbconfoption name="path">/data/service</smbconfoption>
1219 <smbconfoption name="read only">No</smbconfoption>
1222 <smbconfexample id="ch7-slvsmbocnfB">
1223 <title>Backup Domain Controller &smb.conf; File &smbmdash; Part B</title>
1224 <smbconfsection name="[pidata]"/>
1225 <smbconfoption name="comment">Property Insurance Files</smbconfoption>
1226 <smbconfoption name="path">/data/pidata</smbconfoption>
1227 <smbconfoption name="read only">No</smbconfoption>
1229 <smbconfsection name="[homes]"/>
1230 <smbconfoption name="comment">Home Directories</smbconfoption>
1231 <smbconfoption name="valid users">%S</smbconfoption>
1232 <smbconfoption name="read only">No</smbconfoption>
1233 <smbconfoption name="browseable">No</smbconfoption>
1235 <smbconfsection name="[printers]"/>
1236 <smbconfoption name="comment">SMB Print Spool</smbconfoption>
1237 <smbconfoption name="path">/var/spool/samba</smbconfoption>
1238 <smbconfoption name="guest ok">Yes</smbconfoption>
1239 <smbconfoption name="printable">Yes</smbconfoption>
1240 <smbconfoption name="browseable">No</smbconfoption>
1242 <smbconfsection name="[apps]"/>
1243 <smbconfoption name="comment">Application Files</smbconfoption>
1244 <smbconfoption name="path">/apps</smbconfoption>
1245 <smbconfoption name="admin users">bjones</smbconfoption>
1246 <smbconfoption name="read only">No</smbconfoption>
1248 <smbconfsection name="[netlogon]"/>
1249 <smbconfoption name="comment">Network Logon Service</smbconfoption>
1250 <smbconfoption name="path">/var/lib/samba/netlogon</smbconfoption>
1251 <smbconfoption name="guest ok">Yes</smbconfoption>
1252 <smbconfoption name="locking">No</smbconfoption>
1254 <smbconfsection name="[profiles]"/>
1255 <smbconfoption name="comment">Profile Share</smbconfoption>
1256 <smbconfoption name="path">/var/lib/samba/profiles</smbconfoption>
1257 <smbconfoption name="read only">No</smbconfoption>
1258 <smbconfoption name="profile acls">Yes</smbconfoption>
1260 <smbconfsection name="[profdata]"/>
1261 <smbconfoption name="comment">Profile Data Share</smbconfoption>
1262 <smbconfoption name="path">/var/lib/samba/profdata</smbconfoption>
1263 <smbconfoption name="read only">No</smbconfoption>
1264 <smbconfoption name="profile acls">Yes</smbconfoption>
1268 <title>Key Points Learned</title>
1272 <indexterm><primary>LDAP</primary></indexterm><indexterm><primary>BDC</primary></indexterm>
1273 Where Samba-3 is used as a domain controller, the use of LDAP is an
1274 essential component to permit the use of BDCs.
1278 <indexterm><primary>wide-area</primary></indexterm>
1279 Replication of the LDAP master server to create a network of BDCs
1280 is an important mechanism for limiting WAN traffic.
1284 Network administration presents many complex challenges, most of which
1285 can be satisfied by good design but that also require sound communication
1286 and unification of management practices. This can be highly challenging in
1287 a large, globally distributed network.
1291 Roaming profiles must be contained to the local network segment. Any
1292 departure from this may clog wide-area arteries and slow legitimate network
1302 <title>Questions and Answers</title>
1305 There is much rumor and misinformation regarding the use of MS Windows networking protocols.
1306 These questions are just a few of those frequently asked.
1309 <qandaset defaultlabel="chap07qa">
1314 <indexterm><primary>DHCP</primary></indexterm>
1315 <indexterm><primary>network</primary><secondary>bandwidth</secondary></indexterm>
1316 Is it true that DHCP uses lots of WAN bandwidth?
1323 <indexterm><primary>DHCP</primary><secondary>Relay Agent</secondary></indexterm>
1324 <indexterm><primary>routers</primary></indexterm>
1325 <indexterm><primary>DHCP</primary><secondary>servers</secondary></indexterm>
1326 It is a smart practice to localize DHCP servers on each network segment. As a
1327 rule, there should be two DHCP servers per network segment. This means that if
1328 one server fails, there is always another to service user needs. DHCP requests use
1329 only UDP broadcast protocols. It is possible to run a DHCP Relay Agent on network
1330 routers. This makes it possible to run fewer DHCP servers.
1334 <indexterm><primary>DHCP</primary><secondary>request</secondary></indexterm>
1335 <indexterm><primary>DHCP</primary><secondary>traffic</secondary></indexterm>
1336 A DHCP network address request and confirmation usually results in about six UDP packets.
1337 The packets are from 60 to 568 bytes in length. Let us consider a site that has 300 DHCP
1338 clients and that uses a 24-hour IP address lease. This means that all clients renew
1339 their IP address lease every 24 hours. If we assume an average packet length equal to the
1340 maximum (just to be on the safe side), and we have a 128 Kb/sec wide-area connection,
1341 how significant would the DHCP traffic be if all of it were to use DHCP Relay?
1345 I must stress that this is a bad design, but here is the calculation:
1347 Daily Network Capacity: 128,000 (Kbits/s) / 8 (bits/byte)
1348 x 3600 (sec/hr) x 24 (hrs/day)= 2288 Mbytes/day.
1350 DHCP traffic: 300 (clients) x 6 (packets)
1351 x 512 (bytes/packet) = 0.9 Mbytes/day.
1353 From this can be seen that the traffic impact would be minimal.
1357 <indexterm><primary>DNS</primary><secondary>Dynamic</secondary></indexterm>
1358 <indexterm><primary>DHCP</primary></indexterm>
1359 Even when DHCP is configured to do DNS update (dynamic DNS) over a wide-area link,
1360 the impact of the update is no more than the DHCP IP address renewal traffic and thus
1361 still insignificant for most practical purposes.
1371 <indexterm><primary>background communication</primary></indexterm>
1372 <indexterm><primary>LDAP</primary><secondary>master/slave</secondary><tertiary>background communication</tertiary></indexterm>
1373 How much background communication takes place between a master LDAP server and its slave LDAP servers?
1380 <indexterm><primary>slurpd</primary></indexterm>
1381 The process that controls the replication of data from the master LDAP server to the slave LDAP
1382 servers is called <command>slurpd</command>. The <command>slurpd</command> remains nascent (quiet)
1383 until an update must be propagated. The propagation traffic per LDAP slave to update (add/modify/delete)
1384 two user accounts requires less than 10KB traffic.
1394 LDAP has a database. Is LDAP not just a fancy database front end?
1401 <indexterm><primary>database</primary></indexterm>
1402 <indexterm><primary>LDAP</primary><secondary>database</secondary></indexterm>
1403 <indexterm><primary>SQL</primary></indexterm>
1404 <indexterm><primary>transactional</primary></indexterm>
1405 LDAP does store its data in a database of sorts. In fact, the LDAP backend is an application-specific
1406 data storage system. This type of database is indexed so that records can be rapidly located, but the
1407 database is not generic and can be used only in particular pre-programmed ways. General external
1408 applications do not gain access to the data. This type of database is used also by SQL servers. Both
1409 an SQL server and an LDAP server provide ways to access the data. An SQL server has a transactional
1410 orientation and typically allows external programs to perform ad hoc queries, even across data tables.
1411 An LDAP front end is a purpose-built tool that has a search orientation that is designed around specific
1412 simple queries. The term <constant>database</constant> is heavily overloaded and thus much misunderstood.
1422 <indexterm><primary>OpenLDAP</primary></indexterm>
1423 Can Active Directory obtain account information from an OpenLDAP server?
1430 <indexterm><primary>meta-directory</primary></indexterm>
1431 No, at least not directly. It is possible to provision Active Directory from and/or to an OpenLDAP
1432 database through use of a metadirectory server. Microsoft MMS (now called MIIS) can interface
1433 to OpenLDAP using standard LDAP queries and updates.
1443 What are the parts of a roaming profile? How large is each part?
1450 <primary>roaming profile</primary>
1452 A roaming profile consists of
1457 Desktop folders such as <constant>Desktop</constant>, <constant>My Documents</constant>, <constant>My Pictures</constant>, <constant>My Music</constant>, <constant>Internet Files</constant>,
1458 <constant>Cookies</constant>, <constant>Application Data</constant>, <constant>Local Settings,</constant> and more. See Chapter 5, <link linkend="XP-screen001"/>.
1462 <primary>folder redirection</primary>
1464 Each of these can be anywhere from a few bytes to gigabytes in capacity. Fortunately, all
1465 such folders can be redirected to network drive resources. See <link linkend="redirfold"/>
1466 for more information regarding folder redirection.
1470 A static or rewritable portion that is typically only a few files (2-5 KB of information).
1474 <indexterm><primary>NTUSER.DAT</primary></indexterm>
1475 <indexterm><primary>HKEY_LOCAL_USER</primary></indexterm>
1476 The registry load file that modifies the <constant>HKEY_LOCAL_USER</constant> hive. This is
1477 the <filename>NTUSER.DAT</filename> file. It can be from 0.4 to 1.5 MB.
1482 <indexterm><primary>Microsoft Outlook</primary><secondary>PST files</secondary></indexterm>
1483 Microsoft Outlook PST files may be stored in the <constant>Local Settings\Application Data</constant>
1484 folder. It can be up to 2 GB in size per PST file.
1494 Can the <constant>My Documents</constant> folder be stored on a network drive?
1501 <indexterm><primary>UNC name</primary></indexterm>
1502 <indexterm><primary>Universal Naming Convention</primary><see>UNC name</see></indexterm>
1503 Yes. More correctly, such folders can be redirected to network shares. No specific network drive
1504 connection is required. Registry settings permit this to be redirected directly to a UNC (Universal
1505 Naming Convention) resource, though it is possible to specify a network drive letter instead of a
1506 UNC name. See <link linkend="redirfold"/>.
1516 <indexterm><primary>wide-area</primary></indexterm>
1517 <indexterm><primary>network</primary><secondary>bandwidth</secondary></indexterm>
1518 <indexterm><primary>WINS</primary></indexterm>
1519 How much WAN bandwidth does WINS consume?
1526 <indexterm><primary>NetBIOS</primary><secondary>name cache</secondary></indexterm>
1527 <indexterm><primary>WINS server</primary></indexterm>
1528 <indexterm><primary>domain replication</primary></indexterm>
1529 MS Windows clients cache information obtained from WINS lookups in a local NetBIOS name cache.
1530 This keeps WINS lookups to a minimum. On a network with 3500 MS Windows clients and a central WINS
1531 server, the total bandwidth demand measured at the WINS server, averaged over an 8-hour working day,
1532 was less than 30 KB/sec. Analysis of network traffic over a 6-week period showed that the total
1533 of all background traffic consumed about 11 percent of available bandwidth over 64 Kb/sec links.
1534 Background traffic consisted of domain replication, WINS queries, DNS lookups, and authentication
1535 traffic. Each of 11 branch offices had a 64 Kb/sec wide-area link, with a 1.5 Mb/sec main connection
1536 that aggregated the branch office connections plus an Internet connection.
1540 In conclusion, the total load afforded through WINS traffic is again marginal to total operational
1541 usage &smbmdash; as it should be.
1551 How many BDCs should I have? What is the right number of Windows clients per server?
1558 It is recommended to have at least one BDC per network segment, including the segment served
1559 by the PDC. Actual requirements vary depending on the working load on each of the BDCs and the
1560 load demand pattern of client usage. I have seen sites that function without problem with 200
1561 clients served by one BDC, and yet other sites that had one BDC per 20 clients. In one particular
1562 company, there was a drafting office that had 30 CAD/CAM operators served by one server, a print
1563 server; and an application server. While all three were BDCs, typically only the print server would
1564 service network logon requests after the first 10 users had started to use the network. This was
1565 a reflection of the service load placed on both the application server and the data server.
1569 As unsatisfactory as the answer might sound, it all depends on network and server load
1580 <indexterm><primary>NIS server</primary></indexterm><indexterm><primary>LDAP</primary></indexterm>
1581 I've heard that you can store NIS accounts in LDAP. Is LDAP not just a smarter way to
1589 The correct answer to both questions is yes. But do understand that an LDAP server has
1590 a configurable schema that can store far more information for many more purposes than
1601 Can I use NIS in place of LDAP?
1608 <indexterm><primary>NIS</primary></indexterm>
1609 <indexterm><primary>NIS schema</primary></indexterm>
1610 No. The NIS database does not have provision to store Microsoft encrypted passwords and does not deal
1611 with the types of data necessary for interoperability with Microsoft Windows networking. The use
1612 of LDAP with Samba requires the use of a number of schemas, one of which is the NIS schema, but also
1613 a Samba-specific schema extension.