docs-xml/Samba3-ByExample/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="net2000users">
   4   <title>A Distributed 2000-User Network</title>
   5
   6 <para>
   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.
  17 </para>
  18
  19 <para>
  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.
  26 </para>
  27
  28 <para>
  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.
  32 </para>
  33
  34 <para>
  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.
  44 </para>
  45
  46 <sect1>
  47 <title>Introduction</title>
  48
  49 <para>
  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.
  57 </para>
  58
  59 <para>
  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
  64 without impediment.
  65 </para>
  66
  67         <sect2>
  68         <title>Assignment Tasks</title>
  69
  70         <para>
  71         Starting with the configuration files for the server called
  72         <constant>MASSIVE</constant> in <link linkend="happy"/>, 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.
  76         </para>
  77
  78         <para>
  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
  85         </para>
  86
  87         <para>
  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.
  92         </para>
  93
  94                 <para>
  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
  99         Washington.
 100         </para>
 101
 102                 <para>
 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.
 106         </para>
 107
 108         </sect2>
 109 </sect1>
 110
 111 <sect1>
 112 <title>Dissection and Discussion</title>
 113
 114 <para>
 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.
 121 </para>
 122
 123 <para>
 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
 138 managers.
 139 </para>
 140
 141 <para>
 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>
 151
 152 <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>
 164
 165 <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>
 176
 177 <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>
 188
 189 <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>
 197
 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
 203 productivity.</para>
 204
 205         <sect2>
 206         <title>Technical Issues</title>
 207
 208         <para>
 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
 211         expanded business:
 212         </para>
 213
 214         <itemizedlist>
 215                 <listitem><para><indexterm><primary>mobility</primary></indexterm>
 216                 User needs such as mobility and data access</para></listitem>
 217
 218                 <listitem><para>The nature of Windows networking protocols</para></listitem>
 219
 220                 <listitem><para>Identity management infrastructure needs</para></listitem>
 221         </itemizedlist>
 222
 223         <para>Let's look at each in turn.</para>
 224
 225         <sect3>
 226           <title>User Needs</title>
 227
 228         <para>
 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.
 233         </para>
 234
 235         <para>
 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.
 240         </para>
 241
 242         <para>
 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
 252         to the network.
 253         </para>
 254
 255         <para>
 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.
 269         </para>
 270
 271         <para>
 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.
 275         </para>
 276
 277         </sect3>
 278
 279         <sect3>
 280           <title>The Nature of Windows Networking Protocols</title>
 281
 282         <para>
 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.
 290         </para>
 291
 292         <para>
 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 <link linkend="happy"/>, 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
 302         connections.
 303         </para>
 304
 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.
 311         </para>
 312
 313         <para>
 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.
 319         </para>
 320
 321         <para>
 322         When a Windows NT4/200x/XP Professional client user logs onto
 323         the network, several important things must happen.
 324         </para>
 325
 326         <itemizedlist>
 327                 <listitem><para>
 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.)
 331                 </para></listitem>
 332
 333                 <listitem><para>
 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.
 337                 </para></listitem>
 338
 339                 <listitem><para>
 340                 <indexterm><primary>Domain Controller</primary><secondary>closest</secondary></indexterm>
 341                 The client must locate the closest domain controller.
 342                 </para></listitem>
 343
 344                 <listitem><para>
 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.
 348                 </para></listitem>
 349
 350                 <listitem><para>
 351                 The domain controller must be able to resolve the user's
 352                 credentials before the logon process is fully implemented.
 353                 </para></listitem>
 354         </itemizedlist>
 355
 356         <para>
 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.
 363         </para>
 364
 365         <para>
 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
 369         at the WINS server.
 370         </para>
 371
 372         <para>
 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>
 380
 381         <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
 392         domain controllers.
 393         </para>
 394
 395         <para>
 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?
 408         </para>
 409
 410         <para>
 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.
 422         </para>
 423
 424         <para>
 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.
 432         </para>
 433
 434         </sect3>
 435
 436         <sect3>
 437         <title>Identity Management Needs</title>
 438
 439         <para>
 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.
 451         </para>
 452
 453         <para>
 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).
 467         </para>
 468
 469         <para>
 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.
 479         </para>
 480
 481
 482         <para>
 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
 491         focus.
 492         </para>
 493
 494         <para>
 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.
 501         </para>
 502
 503         <para>
 504         <indexterm><primary>multiple directories</primary></indexterm>
 505         The problem of managing multiple directories has become a focal
 506         point over the past decade, creating a large market for
 507         metadirectory products and services that allow organizations that
 508         have multiple directories and multiple management and control
 509         centers to provision information from one directory into
 510         another. The attendant benefit to end users is the promise of
 511         having to remember and deal with fewer login identities and
 512         passwords.</para>
 513
 514         <para>
 515         <indexterm><primary>network</primary><secondary>bandwidth</secondary></indexterm>
 516         The challenge of every large network is to find the optimum
 517         balance of internal systems and facilities for Identity
 518         Management resources. How well the solution is chosen and
 519         implemented has potentially significant impact on network bandwidth
 520         and systems response needs.</para>
 521
 522         <para>
 523         <indexterm><primary>LDAP server</primary></indexterm>
 524         <indexterm><primary>LDAP</primary><secondary>master</secondary></indexterm>
 525         <indexterm><primary>LDAP</primary><secondary>slave</secondary></indexterm>
 526         In <link linkend="happy"/>, you implemented a single LDAP server for the
 527         entire network. This may work for smaller networks, but almost
 528         certainly fails to meet the needs of large and complex networks. The
 529         following section documents how you may implement a single
 530         master LDAP server with multiple slave servers.</para>
 531
 532         <para>
 533         What is the best method for implementing master/slave LDAP
 534         servers within the context of a distributed 2,000-user network is a
 535         question that remains to be answered.</para>
 536
 537         <para>
 538         <indexterm><primary>distributed domain</primary></indexterm>
 539         <indexterm><primary>wide-area</primary></indexterm>
 540         One possibility that has great appeal is to create a single,
 541         large distributed domain. The practical implications of this
 542         design (see <link linkend="chap7net"/>) demands the placement of
 543         sufficient BDCs in each location. Additionally, network
 544         administrators must make sure that profiles are not transferred
 545         over the wide-area links, except as a totally unavoidable
 546         measure. Network design must balance the risk of loss of user
 547         productivity against the cost of network management and
 548         maintenance.
 549         </para>
 550
 551         <para>
 552         <indexterm><primary>domain name space</primary></indexterm>
 553         The network design in <link linkend="chap7net2"/> takes the approach
 554         that management of networks that are too remote to be managed
 555         effectively from New York ought to be given a certain degree of
 556         autonomy. With this rationale, the Los Angeles and London networks,
 557         though fully integrated with those on the East Coast, each have their
 558         own domain name space and can be independently managed and controlled.
 559         One of the key drawbacks of this design is that it flies in the face of
 560         the ability for network users to roam globally without some compromise
 561         in how they may access global resources.
 562         </para>
 563
 564         <para>
 565         <indexterm><primary>interdomain trusts</primary></indexterm>
 566         Desk-bound users need not be negatively affected by this design, since
 567         the use of interdomain trusts can be used to satisfy the need for global
 568         data sharing.
 569         </para>
 570
 571         <para>
 572         <indexterm><primary>LDAP</primary></indexterm>
 573         <indexterm><primary>LDAP</primary><secondary>backend</secondary></indexterm>
 574         <indexterm><primary>SID</primary></indexterm>
 575         When Samba-3 is configured to use an LDAP backend, it stores the domain
 576         account information in a directory entry. This account entry contains the
 577         domain SID. An unintended but exploitable side effect is that this makes it
 578         possible to operate with more than one PDC on a distributed network.
 579         </para>
 580
 581         <para>
 582         <indexterm><primary>WINS</primary></indexterm>
 583         <indexterm><primary>wins.dat</primary></indexterm>
 584         <indexterm><primary>SID</primary></indexterm>
 585         How might this peculiar feature be exploited? The answer is simple. It is
 586         imperative that each network segment have its own WINS server. Major
 587         servers on remote network segments can be given a static WINS entry in
 588         the <filename>wins.dat</filename> file on each WINS server. This allows
 589         all essential data to be visible from all locations. Each location would,
 590         however, function as if it is an independent domain, while all sharing the
 591         same domain SID. Since all domain account information can be stored in a
 592         single LDAP backend, users have unfettered ability to roam.
 593         </para>
 594
 595         <para>
 596         <indexterm><primary>NetBIOS name</primary><secondary>aliases</secondary></indexterm>
 597         <indexterm><primary>fail-over</primary></indexterm>
 598         This concept has not been exhaustively validated, though we can see no reason
 599         why this should not work. The important facets are the following: The name of
 600         the domain must be identical in all locations. Each network segment must have
 601         its own WINS server. The name of the PDC must be the same in all locations; this
 602         necessitates the use of NetBIOS name aliases for each PDC so that they can be
 603         accessed globally using the alias and not the PDC's primary name. A single master
 604         LDAP server can be based in New York, with multiple LDAP slave servers located
 605         on every network segment. Finally, the BDCs should each use failover LDAP servers
 606         that are in fact slave LDAP servers on the local segments.
 607         </para>
 608
 609         <para>
 610         <indexterm><primary>LDAP</primary><secondary>updates</secondary></indexterm>
 611         <indexterm><primary>domain tree</primary></indexterm>
 612         <indexterm><primary>LDAP</primary><secondary>database</secondary></indexterm>
 613         <indexterm><primary>LDAP</primary><secondary>directory</secondary></indexterm>
 614         With a single master LDAP server, all network updates are effected on a single
 615         server. In the event that this should become excessively fragile or network
 616         bandwidth limiting, one could implement a delegated LDAP domain. This is also
 617         known as a partitioned (or multiple partition) LDAP database and as a distributed
 618         LDAP directory.
 619         </para>
 620
 621         <para>
 622         As the LDAP directory grows, it becomes increasingly important
 623         that its structure is implemented in a manner that mirrors
 624         organizational needs, so as to limit network update and
 625         referential traffic. It should be noted that all directory
 626         administrators must of necessity follow the same standard
 627         procedures for managing the directory, because retroactive correction of
 628         inconsistent directory information can be exceedingly difficult.
 629         </para>
 630
 631         </sect3>
 632
 633         </sect2>
 634
 635
 636         <sect2>
 637                 <title>Political Issues</title>
 638
 639         <para>
 640         As organizations grow, the number of points of control increases
 641         also. In a large distributed organization, it is important that the
 642         Identity Management system be capable of being updated from
 643         many locations, and it is equally important that changes made should
 644         become usable in a reasonable period, typically
 645         minutes rather than days (the old limitation of highly manual
 646         systems).
 647         </para>
 648
 649         </sect2>
 650
 651 </sect1>
 652
 653 <sect1>
 654         <title>Implementation</title>
 655
 656         <para>
 657         <indexterm><primary>winbind</primary></indexterm>
 658         <indexterm><primary>LDAP</primary></indexterm>
 659         <indexterm><primary>UID</primary></indexterm>
 660         <indexterm><primary>GID</primary></indexterm>
 661         Samba-3 has the ability to use multiple password (authentication and
 662         identity resolution) backends. The diagram in <link linkend="chap7idres"/>
 663         demonstrates how Samba uses winbind, LDAP, and NIS, the traditional system
 664         password database. The diagram only documents the mechanisms for
 665         authentication and identity resolution (obtaining a UNIX UID/GID)
 666         using the specific systems shown.
 667         </para>
 668
 669         <figure id="chap7idres">
 670                 <title>Samba and Authentication Backend Search Pathways</title>
 671                 <imagefile scale="55">chap7-idresol</imagefile>
 672         </figure>
 673
 674         <para>
 675         <indexterm><primary>smbpasswd</primary></indexterm>
 676         <indexterm><primary>xmlsam</primary></indexterm>
 677         <indexterm><primary>SMB passwords</primary></indexterm>
 678         <indexterm><primary>tdbsam</primary></indexterm>
 679         <indexterm><primary>mysqlsam</primary></indexterm>
 680         <indexterm><primary>LDAP</primary></indexterm>
 681         <indexterm><primary>distributed</primary></indexterm>
 682         Samba is capable of using the <constant>smbpasswd</constant>,
 683         <constant>tdbsam</constant>, <constant>xmlsam</constant>,
 684         and <constant>mysqlsam</constant> authentication databases. The SMB
 685         passwords can, of course, also be stored in an LDAP ldapsam
 686         backend. LDAP is the preferred passdb backend for distributed network
 687         operations.
 688         </para>
 689
 690         <para>
 691         <indexterm><primary>passdb backend</primary></indexterm>
 692         Additionally, it is possible to use multiple passdb backends
 693         concurrently as well as have multiple LDAP backends. As a result, you
 694         can specify a failover LDAP backend. The syntax for specifying a
 695         single LDAP backend in &smb.conf; is:
 696 <screen>
 697 ...
 698 passdb backend = ldapsam:ldap://master.abmas.biz
 699 ...
 700 </screen>
 701         This configuration tells Samba to use a single LDAP server, as shown in <link linkend="ch7singleLDAP"/>.
 702         <figure id="ch7singleLDAP">
 703                 <title>Samba Configuration to Use a Single LDAP Server</title>
 704                 <imagefile scale="65">ch7-singleLDAP</imagefile>
 705         </figure>
 706         <indexterm><primary>LDAP</primary><secondary>fail-over</secondary></indexterm>
 707         <indexterm><primary>fail-over</primary></indexterm>
 708         The addition of a failover LDAP server can simply be done by adding a
 709         second entry for the failover server to the single <parameter>ldapsam</parameter>
 710         entry, as shown here (note the particular use of the double quotes):
 711 <screen>
 712 ...
 713 passdb backend = ldapsam:"ldap://master.abmas.biz \
 714                           ldap://slave.abmas.biz"
 715 ...
 716 </screen>
 717         This configuration tells Samba to use a master LDAP server, with failover to a slave server if necessary,
 718         as shown in <link linkend="ch7dualLDAP"/>.
 719         <figure id="ch7dualLDAP">
 720                 <title>Samba Configuration to Use a Dual (Fail-over) LDAP Server</title>
 721                 <imagefile scale="65">ch7-fail-overLDAP</imagefile>
 722         </figure>
 723         </para>
 724
 725         <para>
 726         Some folks have tried to implement this without the use of double quotes. This is the type of entry they
 727         created:
 728 <screen>
 729 ...
 730 passdb backend = ldapsam:ldap://master.abmas.biz \
 731                  ldapsam:ldap://slave.abmas.biz
 732 ...
 733 </screen>
 734         <indexterm><primary>contiguous directory</primary></indexterm>
 735         The effect of this style of entry is that Samba lists the users
 736         that are in both LDAP databases. If both contain the same information,
 737         it results in each record being shown twice. This is, of course, not the
 738         solution desired for a failover implementation. The net effect of this
 739         configuration is shown in <link linkend="ch7dualadd"/>
 740         </para>
 741
 742         <figure id="ch7dualadd">
 743                 <title>Samba Configuration to Use Dual LDAP Databases - Broken - Do Not Use!</title>
 744                 <imagefile scale="55">ch7-dual-additive-LDAP</imagefile>
 745         </figure>
 746
 747         <para>
 748         If, however, each LDAP database contains unique information, this may
 749         well be an advantageous way to effectively integrate multiple LDAP databases
 750         into one seemingly contiguous directory. Only the first database will be updated.
 751         An example of this configuration is shown in <link linkend="ch7dualok"/>.
 752         </para>
 753
 754         <figure id="ch7dualok">
 755                 <title>Samba Configuration to Use Two LDAP Databases - The result is additive.</title>
 756                 <imagefile scale="55">ch7-dual-additive-LDAP-Ok</imagefile>
 757         </figure>
 758
 759         <note><para>
 760         When the use of ldapsam is specified twice, as shown here, it is imperative
 761         that the two LDAP directories must be disjoint. If the entries are for a
 762         master LDAP server as well as its own slave server, updates to the LDAP
 763         database may end up being lost or corrupted. You may safely use multiple
 764         LDAP backends only if both are entirely separate from each other.
 765         </para></note>
 766
 767     <para>
 768         It is assumed that the network you are working with follows in a
 769         pattern similar to what was covered in <link linkend="happy"/>. The following steps
 770     permit the operation of a master/slave OpenLDAP arrangement.
 771         </para>
 772
 773         <procedure>
 774         <title>Implementation Steps for an LDAP Slave Server</title>
 775
 776                 <step><para>
 777             <indexterm><primary>SUSE Linux</primary></indexterm>
 778                 <indexterm><primary>Red Hat Linux</primary></indexterm>
 779                 Log onto the master LDAP server as <constant>root</constant>.
 780                 You are about to change the configuration of the LDAP server, so it
 781                 makes sense to temporarily halt it. Stop OpenLDAP from running on
 782                 SUSE Linux by executing:
 783 <screen>
 784 &rootprompt; rcldap stop
 785 </screen>
 786                 On Red Hat Linux, you can do this by executing:
 787 <screen>
 788 &rootprompt; service ldap stop
 789 </screen>
 790                 </para></step>
 791
 792                 <step><para>
 793                 <indexterm><primary>/etc/openldap/slapd.conf</primary></indexterm>
 794                 Edit the <filename>/etc/openldap/slapd.conf</filename> file so it
 795                 matches the content of <link linkend="ch7-LDAP-master"/>.
 796                 </para></step>
 797
 798                 <step><para>
 799                 Create a file called <filename>admin-accts.ldif</filename> with the following contents:
 800 <screen>
 801 dn: cn=updateuser,dc=abmas,dc=biz
 802 objectClass: person
 803 cn: updateuser
 804 sn: updateuser
 805 userPassword: not24get
 806
 807 dn: cn=sambaadmin,dc=abmas,dc=biz
 808 objectClass: person
 809 cn: sambaadmin
 810 sn: sambaadmin
 811 userPassword: buttercup
 812 </screen>
 813                 </para></step>
 814
 815                 <step><para>
 816                 Add an account called <quote>updateuser</quote> to the master LDAP server as shown here:
 817 <screen>
 818 &rootprompt; slapadd -v -l admin-accts.ldif
 819 </screen>
 820                 </para></step>
 821
 822                 <step><para>
 823                 <indexterm><primary>LDIF</primary></indexterm>
 824                 <indexterm><primary>LDAP</primary><secondary>preload</secondary></indexterm>
 825                 Change directory to a suitable place to dump the contents of the
 826                 LDAP server. The dump file (and LDIF file) is used to preload
 827                 the slave LDAP server database. You can dump the database by executing:
 828 <screen>
 829 &rootprompt; slapcat -v -l LDAP-transfer-LDIF.txt
 830 </screen>
 831                 Each record is written to the file.
 832                 </para></step>
 833
 834                 <step><para>
 835                 <indexterm><primary>LDAP-transfer-LDIF.txt</primary></indexterm>
 836                 Copy the file <filename>LDAP-transfer-LDIF.txt</filename> to the intended
 837                 slave LDAP server. A good location could be in the directory
 838                 <filename>/etc/openldap/preload</filename>.
 839                 </para></step>
 840
 841                 <step><para>
 842                 Log onto the slave LDAP server as <constant>root</constant>. You can
 843                 now configure this server so the <filename>/etc/openldap/slapd.conf</filename>
 844                 file matches the content of <link linkend="ch7-LDAP-slave"/>.
 845                 </para></step>
 846
 847                 <step><para>
 848                 Change directory to the location in which you stored the
 849                 <filename>LDAP-transfer-LDIF.txt</filename> file (<filename>/etc/openldap/preload</filename>).
 850                 While in this directory, execute:
 851 <screen>
 852 &rootprompt; slapadd -v -l LDAP-transfer-LDIF.txt
 853 </screen>
 854                 If all goes well, the following output confirms that the data is being loaded
 855                 as intended:
 856 <screen>
 857 added: "dc=abmas,dc=biz" (00000001)
 858 added: "cn=sambaadmin,dc=abmas,dc=biz" (00000002)
 859 added: "cn=updateuser,dc=abmas,dc=biz" (00000003)
 860 added: "ou=People,dc=abmas,dc=biz" (00000004)
 861 added: "ou=Groups,dc=abmas,dc=biz" (00000005)
 862 added: "ou=Computers,dc=abmas,dc=biz" (00000006)
 863 added: "uid=Administrator,ou=People,dc=abmas,dc=biz" (00000007)
 864 added: "uid=nobody,ou=People,dc=abmas,dc=biz" (00000008)
 865 added: "cn=Domain Admins,ou=Groups,dc=abmas,dc=biz" (00000009)
 866 added: "cn=Domain Users,ou=Groups,dc=abmas,dc=biz" (0000000a)
 867 added: "cn=Domain Guests,ou=Groups,dc=abmas,dc=biz" (0000000b)
 868 added: "uid=bobj,ou=People,dc=abmas,dc=biz" (0000000c)
 869 added: "sambaDomainName=MEGANET2,dc=abmas,dc=biz" (0000000d)
 870 added: "uid=stans,ou=People,dc=abmas,dc=biz" (0000000e)
 871 added: "uid=chrisr,ou=People,dc=abmas,dc=biz" (0000000f)
 872 added: "uid=maryv,ou=People,dc=abmas,dc=biz" (00000010)
 873 added: "cn=Accounts,ou=Groups,dc=abmas,dc=biz" (00000011)
 874 added: "cn=Finances,ou=Groups,dc=abmas,dc=biz" (00000012)
 875 added: "cn=PIOps,ou=Groups,dc=abmas,dc=biz" (00000013)
 876 </screen>
 877                 </para></step>
 878
 879                 <step><para>
 880                 Now start the LDAP server and set it to run automatically on system reboot by executing:
 881 <screen>
 882 &rootprompt; rcldap start
 883 &rootprompt; chkconfig ldap on
 884 </screen>
 885                 On Red Hat Linux, execute the following:
 886 <screen>
 887 &rootprompt; service ldap start
 888 &rootprompt; chkconfig ldap on
 889 </screen>
 890                 </para></step>
 891
 892                 <step><para>
 893             <indexterm><primary>chkconfig</primary></indexterm>
 894                 <indexterm><primary>service</primary></indexterm>
 895                 <indexterm><primary>rcldap</primary></indexterm>
 896                 Go back to the master LDAP server. Execute the following to start LDAP as well
 897                 as <command>slurpd</command>, the synchronization daemon, as shown here:
 898 <screen>
 899 &rootprompt; rcldap start
 900 &rootprompt; chkconfig ldap on
 901 &rootprompt; rcslurpd start
 902 &rootprompt; chkconfig slurpd on
 903 </screen>
 904             <indexterm><primary>slurpd</primary></indexterm>
 905                 On Red Hat Linux, check the equivalent command to start <command>slurpd</command>.
 906                 </para></step>
 907
 908                 <step><para>
 909                 <indexterm><primary>smbldap-useradd</primary></indexterm>
 910                 On the master LDAP server you may now add an account to validate that replication
 911                 is working. Assuming the configuration shown in <link linkend="happy"/>, execute:
 912 <screen>
 913 &rootprompt; /var/lib/samba/sbin/smbldap-useradd -a fruitloop
 914 </screen>
 915                 </para></step>
 916
 917                 <step><para>
 918                 On the slave LDAP server, change to the directory <filename>/var/lib/ldap</filename>.
 919                 There should now be a file called <filename>replogfile</filename>. If replication worked
 920                 as expected, the content of this file should be:
 921 <screen>
 922 time: 1072486403
 923 dn: uid=fruitloop,ou=People,dc=abmas,dc=biz
 924 changetype: modify
 925 replace: sambaProfilePath
 926 sambaProfilePath: \\MASSIVE\profiles\fruitloop
 927 -
 928 replace: sambaHomePath
 929 sambaHomePath: \\MASSIVE\homes
 930 -
 931 replace: entryCSN
 932 entryCSN: 2003122700:43:38Z#0x0005#0#0000
 933 -
 934 replace: modifiersName
 935 modifiersName: cn=Manager,dc=abmas,dc=biz
 936 -
 937 replace: modifyTimestamp
 938 modifyTimestamp: 20031227004338Z
 939 -
 940 </screen>
 941                 </para></step>
 942
 943                 <step><para>
 944                 Given that this first slave LDAP server is now working correctly, you may now
 945                 implement additional slave LDAP servers as required.
 946                 </para></step>
 947
 948                 <step><para>
 949                 On each machine (PDC and BDCs) after the respective &smb.conf; files have been created as shown in
 950                 <link linkend="ch7-massmbconfA">Primary Domain Controller &smb.conf; File &smbmdash; Part A + B + C</link> and
 951                 on BDCs the <link linkend="ch7-slvsmbocnfA">Backup Domain Controller &smb.conf; File &smbmdash; Part A
 952                 + B + C</link> execute the following:
 953 <screen>
 954 &rootprompt; smbpasswd -w buttercup
 955 </screen>
 956                 This will install in the <filename>secrets.tdb</filename> file the password that Samba will need to
 957                 manage (write to) the LDAP Master server to perform account updates.
 958                 </para></step>
 959
 960         </procedure>
 961
 962 <example id="ch7-LDAP-master">
 963 <title>LDAP Master Server Configuration File &smbmdash; <filename>/etc/openldap/slapd.conf</filename></title>
 964 <screen>
 965 include     /etc/openldap/schema/core.schema
 966 include     /etc/openldap/schema/cosine.schema
 967 include     /etc/openldap/schema/inetorgperson.schema
 968 include     /etc/openldap/schema/nis.schema
 969 include     /etc/openldap/schema/samba.schema
 970
 971 pidfile     /var/run/slapd/slapd.pid
 972 argsfile    /var/run/slapd/slapd.args
 973
 974 database    bdb
 975 suffix      "dc=abmas,dc=biz"
 976 rootdn      "cn=Manager,dc=abmas,dc=biz"
 977
 978 # rootpw = not24get
 979 rootpw      {SSHA}86kTavd9Dw3FAz6qzWTrCOKX/c0Qe+UV
 980
 981 replica     host=lapdc.abmas.biz:389
 982             suffix="dc=abmas,dc=biz"
 983             binddn="cn=updateuser,dc=abmas,dc=biz"
 984             bindmethod=simple credentials=not24get
 985
 986 access to attrs=sambaLMPassword,sambaNTPassword
 987            by dn="cn=sambaadmin,dc=abmas,dc=biz" write
 988            by * none
 989
 990 replogfile  /var/lib/ldap/replogfile
 991
 992 directory   /var/lib/ldap
 993
 994 # Indices to maintain
 995 index objectClass           eq
 996 index cn                    pres,sub,eq
 997 index sn                    pres,sub,eq
 998 index uid                   pres,sub,eq
 999 index displayName           pres,sub,eq
1000 index uidNumber             eq
1001 index gidNumber             eq
1002 index memberUID             eq
1003 index sambaSID              eq
1004 index sambaPrimaryGroupSID  eq
1005 index sambaDomainName       eq
1006 index default               sub
1007 </screen>
1008 </example>
1009
1010 <example id="ch7-LDAP-slave">
1011 <title>LDAP Slave Configuration File &smbmdash; <filename>/etc/openldap/slapd.conf</filename></title>
1012 <screen>
1013 include     /etc/openldap/schema/core.schema
1014 include     /etc/openldap/schema/cosine.schema
1015 include     /etc/openldap/schema/inetorgperson.schema
1016 include     /etc/openldap/schema/nis.schema
1017 include     /etc/openldap/schema/samba.schema
1018
1019 pidfile     /var/run/slapd/slapd.pid
1020 argsfile    /var/run/slapd/slapd.args
1021
1022 database    bdb
1023 suffix      "dc=abmas,dc=biz"
1024 rootdn      "cn=Manager,dc=abmas,dc=biz"
1025
1026 # rootpw = not24get
1027 rootpw      {SSHA}86kTavd9Dw3FAz6qzWTrCOKX/c0Qe+UV
1028
1029 access to *
1030             by dn=cn=updateuser,dc=abmas,dc=biz write
1031             by * read
1032
1033 updatedn    cn=updateuser,dc=abmas,dc=biz
1034 updateref   ldap://massive.abmas.biz
1035
1036 directory   /var/lib/ldap
1037
1038 # Indices to maintain
1039 index objectClass           eq
1040 index cn                    pres,sub,eq
1041 index sn                    pres,sub,eq
1042 index uid                   pres,sub,eq
1043 index displayName           pres,sub,eq
1044 index uidNumber             eq
1045 index gidNumber             eq
1046 index memberUID             eq
1047 index sambaSID              eq
1048 index sambaPrimaryGroupSID  eq
1049 index sambaDomainName       eq
1050 index default               sub
1051 </screen>
1052 </example>
1053
1054 <example id="ch7-massmbconfA">
1055 <title>Primary Domain Controller &smb.conf; File &smbmdash; Part A</title>
1056 <smbconfblock>
1057 <smbconfcomment>Global parameters</smbconfcomment>
1058 <smbconfsection name="[global]"/>
1059 <smbconfoption name="unix charset">LOCALE</smbconfoption>
1060 <smbconfoption name="workgroup">MEGANET2</smbconfoption>
1061 <smbconfoption name="passdb backend">ldapsam:ldap://massive.abmas.biz</smbconfoption>
1062 <smbconfoption name="username map">/etc/samba/smbusers</smbconfoption>
1063 <smbconfoption name="log level">1</smbconfoption>
1064 <smbconfoption name="syslog">0</smbconfoption>
1065 <smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
1066 <smbconfoption name="max log size">0</smbconfoption>
1067 <smbconfoption name="smb ports">139</smbconfoption>
1068 <smbconfoption name="name resolve order">wins bcast hosts</smbconfoption>
1069 <smbconfoption name="time server">Yes</smbconfoption>
1070 <smbconfoption name="printcap name">CUPS</smbconfoption>
1071 <smbconfoption name="add user script">/opt/IDEALX/sbin/smbldap-useradd -m '%u'</smbconfoption>
1072 <smbconfoption name="delete user script">/opt/IDEALX/sbin/smbldap-userdel '%u'</smbconfoption>
1073 <smbconfoption name="add group script">/opt/IDEALX/sbin/smbldap-groupadd -p '%g'</smbconfoption>
1074 <smbconfoption name="delete group script">/opt/IDEALX/sbin/smbldap-groupdel '%g'</smbconfoption>
1075 <smbconfoption name="add user to group script">/opt/IDEALX/sbin/smbldap-groupmod -m '%g' '%u'</smbconfoption>
1076 <smbconfoption name="delete user from group script">/opt/IDEALX/sbin/smbldap-groupmod -x '%g' '%u'</smbconfoption>
1077 <smbconfoption name="set primary group script">/opt/IDEALX/sbin/smbldap-usermod -g '%g' '%u'</smbconfoption>
1078 <smbconfoption name="add machine script">/opt/IDEALX/sbin/smbldap-useradd -w '%u'</smbconfoption>
1079 <smbconfoption name="shutdown script">/var/lib/samba/scripts/shutdown.sh</smbconfoption>
1080 <smbconfoption name="abort shutdown script">/sbin/shutdown -c</smbconfoption>
1081 <smbconfoption name="logon script">scripts\logon.bat</smbconfoption>
1082 <smbconfoption name="logon path">\\%L\profiles\%U</smbconfoption>
1083 <smbconfoption name="logon drive">X:</smbconfoption>
1084 <smbconfoption name="domain logons">Yes</smbconfoption>
1085 <smbconfoption name="domain master">Yes</smbconfoption>
1086 <smbconfoption name="wins support">Yes</smbconfoption>
1087 <smbconfoption name="ldap suffix">dc=abmas,dc=biz</smbconfoption>
1088 <smbconfoption name="ldap machine suffix">ou=People</smbconfoption>
1089 <smbconfoption name="ldap user suffix">ou=People</smbconfoption>
1090 <smbconfoption name="ldap group suffix">ou=Groups</smbconfoption>
1091 <smbconfoption name="ldap idmap suffix">ou=Idmap</smbconfoption>
1092 <smbconfoption name="ldap admin dn">cn=sambaadmin,dc=abmas,dc=biz</smbconfoption>
1093 <smbconfoption name="idmap backend">ldap://massive.abmas.biz</smbconfoption>
1094 <smbconfoption name="idmap uid">10000-20000</smbconfoption>
1095 <smbconfoption name="idmap gid">10000-20000</smbconfoption>
1096 <smbconfoption name="printer admin">root</smbconfoption>
1097 <smbconfoption name="printing">cups</smbconfoption>
1098 </smbconfblock>
1099 </example>
1100
1101 <example id="ch7-massmbconfB">
1102 <title>Primary Domain Controller &smb.conf; File &smbmdash; Part B</title>
1103 <smbconfblock>
1104 <smbconfsection name="[IPC$]"/>
1105 <smbconfoption name="path">/tmp</smbconfoption>
1106
1107 <smbconfsection name="[accounts]"/>
1108 <smbconfoption name="comment">Accounting Files</smbconfoption>
1109 <smbconfoption name="path">/data/accounts</smbconfoption>
1110 <smbconfoption name="read only">No</smbconfoption>
1111
1112 <smbconfsection name="[service]"/>
1113 <smbconfoption name="comment">Financial Services Files</smbconfoption>
1114 <smbconfoption name="path">/data/service</smbconfoption>
1115 <smbconfoption name="read only">No</smbconfoption>
1116
1117 <smbconfsection name="[pidata]"/>
1118 <smbconfoption name="comment">Property Insurance Files</smbconfoption>
1119 <smbconfoption name="path">/data/pidata</smbconfoption>
1120 <smbconfoption name="read only">No</smbconfoption>
1121
1122 <smbconfsection name="[homes]"/>
1123 <smbconfoption name="comment">Home Directories</smbconfoption>
1124 <smbconfoption name="valid users">%S</smbconfoption>
1125 <smbconfoption name="read only">No</smbconfoption>
1126 <smbconfoption name="browseable">No</smbconfoption>
1127
1128 <smbconfsection name="[printers]"/>
1129 <smbconfoption name="comment">SMB Print Spool</smbconfoption>
1130 <smbconfoption name="path">/var/spool/samba</smbconfoption>
1131 <smbconfoption name="guest ok">Yes</smbconfoption>
1132 <smbconfoption name="printable">Yes</smbconfoption>
1133 <smbconfoption name="browseable">No</smbconfoption>
1134 </smbconfblock>
1135 </example>
1136
1137 <example id="ch7-massmbconfC">
1138 <title>Primary Domain Controller &smb.conf; File &smbmdash; Part C</title>
1139 <smbconfblock>
1140 <smbconfsection name="[apps]"/>
1141 <smbconfoption name="comment">Application Files</smbconfoption>
1142 <smbconfoption name="path">/apps</smbconfoption>
1143 <smbconfoption name="admin users">bjones</smbconfoption>
1144 <smbconfoption name="read only">No</smbconfoption>
1145
1146 <smbconfsection name="[netlogon]"/>
1147 <smbconfoption name="comment">Network Logon Service</smbconfoption>
1148 <smbconfoption name="path">/var/lib/samba/netlogon</smbconfoption>
1149 <smbconfoption name="admin users">root, Administrator</smbconfoption>
1150 <smbconfoption name="guest ok">Yes</smbconfoption>
1151 <smbconfoption name="locking">No</smbconfoption>
1152
1153 <smbconfsection name="[profiles]"/>
1154 <smbconfoption name="comment">Profile Share</smbconfoption>
1155 <smbconfoption name="path">/var/lib/samba/profiles</smbconfoption>
1156 <smbconfoption name="read only">No</smbconfoption>
1157 <smbconfoption name="profile acls">Yes</smbconfoption>
1158
1159 <smbconfsection name="[profdata]"/>
1160 <smbconfoption name="comment">Profile Data Share</smbconfoption>
1161 <smbconfoption name="path">/var/lib/samba/profdata</smbconfoption>
1162 <smbconfoption name="read only">No</smbconfoption>
1163 <smbconfoption name="profile acls">Yes</smbconfoption>
1164
1165 <smbconfsection name="[print$]"/>
1166 <smbconfoption name="comment">Printer Drivers</smbconfoption>
1167 <smbconfoption name="path">/var/lib/samba/drivers</smbconfoption>
1168 <smbconfoption name="write list">root</smbconfoption>
1169 <smbconfoption name="admin users">root, Administrator</smbconfoption>
1170 </smbconfblock>
1171 </example>
1172
1173 <example id="ch7-slvsmbocnfA">
1174 <title>Backup Domain Controller &smb.conf; File &smbmdash; Part A</title>
1175 <smbconfblock>
1176 <smbconfcomment># Global parameters</smbconfcomment>
1177 <smbconfsection name="[global]"/>
1178 <smbconfoption name="unix charset">LOCALE</smbconfoption>
1179 <smbconfoption name="workgroup">MEGANET2</smbconfoption>
1180 <smbconfoption name="netbios name">BLDG1</smbconfoption>
1181 <smbconfoption name="passdb backend">ldapsam:ldap://lapdc.abmas.biz</smbconfoption>
1182 <smbconfoption name="username map">/etc/samba/smbusers</smbconfoption>
1183 <smbconfoption name="log level">1</smbconfoption>
1184 <smbconfoption name="syslog">0</smbconfoption>
1185 <smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
1186 <smbconfoption name="max log size">50</smbconfoption>
1187 <smbconfoption name="smb ports">139</smbconfoption>
1188 <smbconfoption name="name resolve order">wins bcast hosts</smbconfoption>
1189 <smbconfoption name="printcap name">CUPS</smbconfoption>
1190 <smbconfoption name="show add printer wizard">No</smbconfoption>
1191 <smbconfoption name="logon script">scripts\logon.bat</smbconfoption>
1192 <smbconfoption name="logon path">\\%L\profiles\%U</smbconfoption>
1193 <smbconfoption name="logon drive">X:</smbconfoption>
1194 <smbconfoption name="domain logons">Yes</smbconfoption>
1195 <smbconfoption name="os level">63</smbconfoption>
1196 <smbconfoption name="domain master">No</smbconfoption>
1197 <smbconfoption name="wins server">192.168.2.1</smbconfoption>
1198 <smbconfoption name="ldap suffix">dc=abmas,dc=biz</smbconfoption>
1199 <smbconfoption name="ldap machine suffix">ou=People</smbconfoption>
1200 <smbconfoption name="ldap user suffix">ou=People</smbconfoption>
1201 <smbconfoption name="ldap group suffix">ou=Groups</smbconfoption>
1202 <smbconfoption name="ldap idmap suffix">ou=Idmap</smbconfoption>
1203 <smbconfoption name="ldap admin dn">cn=sambaadmin,dc=abmas,dc=biz</smbconfoption>
1204 <smbconfoption name="utmp">Yes</smbconfoption>
1205 <smbconfoption name="idmap backend">ldap://massive.abmas.biz</smbconfoption>
1206 <smbconfoption name="idmap uid">10000-20000</smbconfoption>
1207 <smbconfoption name="idmap gid">10000-20000</smbconfoption>
1208 <smbconfoption name="printing">cups</smbconfoption>
1209
1210 <smbconfsection name="[accounts]"/>
1211 <smbconfoption name="comment">Accounting Files</smbconfoption>
1212 <smbconfoption name="path">/data/accounts</smbconfoption>
1213 <smbconfoption name="read only">No</smbconfoption>
1214
1215 <smbconfsection name="[service]"/>
1216 <smbconfoption name="comment">Financial Services Files</smbconfoption>
1217 <smbconfoption name="path">/data/service</smbconfoption>
1218 <smbconfoption name="read only">No</smbconfoption>
1219 </smbconfblock>
1220 </example>
1221
1222 <example id="ch7-slvsmbocnfB">
1223 <title>Backup Domain Controller &smb.conf; File &smbmdash; Part B</title>
1224 <smbconfblock>
1225 <smbconfsection name="[pidata]"/>
1226 <smbconfoption name="comment">Property Insurance Files</smbconfoption>
1227 <smbconfoption name="path">/data/pidata</smbconfoption>
1228 <smbconfoption name="read only">No</smbconfoption>
1229
1230 <smbconfsection name="[homes]"/>
1231 <smbconfoption name="comment">Home Directories</smbconfoption>
1232 <smbconfoption name="valid users">%S</smbconfoption>
1233 <smbconfoption name="read only">No</smbconfoption>
1234 <smbconfoption name="browseable">No</smbconfoption>
1235
1236 <smbconfsection name="[printers]"/>
1237 <smbconfoption name="comment">SMB Print Spool</smbconfoption>
1238 <smbconfoption name="path">/var/spool/samba</smbconfoption>
1239 <smbconfoption name="guest ok">Yes</smbconfoption>
1240 <smbconfoption name="printable">Yes</smbconfoption>
1241 <smbconfoption name="browseable">No</smbconfoption>
1242
1243 <smbconfsection name="[apps]"/>
1244 <smbconfoption name="comment">Application Files</smbconfoption>
1245 <smbconfoption name="path">/apps</smbconfoption>
1246 <smbconfoption name="admin users">bjones</smbconfoption>
1247 <smbconfoption name="read only">No</smbconfoption>
1248
1249 <smbconfsection name="[netlogon]"/>
1250 <smbconfoption name="comment">Network Logon Service</smbconfoption>
1251 <smbconfoption name="path">/var/lib/samba/netlogon</smbconfoption>
1252 <smbconfoption name="guest ok">Yes</smbconfoption>
1253 <smbconfoption name="locking">No</smbconfoption>
1254
1255 <smbconfsection name="[profiles]"/>
1256 <smbconfoption name="comment">Profile Share</smbconfoption>
1257 <smbconfoption name="path">/var/lib/samba/profiles</smbconfoption>
1258 <smbconfoption name="read only">No</smbconfoption>
1259 <smbconfoption name="profile acls">Yes</smbconfoption>
1260
1261 <smbconfsection name="[profdata]"/>
1262 <smbconfoption name="comment">Profile Data Share</smbconfoption>
1263 <smbconfoption name="path">/var/lib/samba/profdata</smbconfoption>
1264 <smbconfoption name="read only">No</smbconfoption>
1265 <smbconfoption name="profile acls">Yes</smbconfoption>
1266 </smbconfblock>
1267 </example>
1268
1269         <sect2>
1270                 <title>Key Points Learned</title>
1271
1272                 <itemizedlist>
1273                         <listitem><para>
1274                         <indexterm><primary>LDAP</primary></indexterm><indexterm><primary>BDC</primary></indexterm>
1275                         Where Samba-3 is used as a domain controller, the use of LDAP is an
1276                         essential component to permit the use of BDCs.
1277                         </para></listitem>
1278
1279                         <listitem><para>
1280                         <indexterm><primary>wide-area</primary></indexterm>
1281                         Replication of the LDAP master server to create a network of BDCs
1282                         is an important mechanism for limiting WAN traffic.
1283                         </para></listitem>
1284
1285                         <listitem><para>
1286                         Network administration presents many complex challenges, most of which
1287                         can be satisfied by good design but that also require sound communication
1288                         and unification of management practices. This can be highly challenging in
1289                         a large, globally distributed network.
1290                         </para></listitem>
1291
1292                         <listitem><para>
1293                         Roaming profiles must be contained to the local network segment. Any
1294                         departure from this may clog wide-area arteries and slow legitimate network
1295                         traffic to a crawl.
1296                         </para></listitem>
1297                 </itemizedlist>
1298
1299         </sect2>
1300
1301         <figure id="chap7net">
1302                 <title>Network Topology &smbmdash; 2000 User Complex Design A</title>
1303                 <imagefile scale="80">chap7-net-Ar</imagefile>
1304         </figure>
1305
1306         <figure id="chap7net2">
1307                 <title>Network Topology &smbmdash; 2000 User Complex Design B</title>
1308                 <imagefile scale="80">chap7-net2-Br</imagefile>
1309         </figure>
1310
1311 </sect1>
1312
1313 <sect1>
1314         <title>Questions and Answers</title>
1315
1316         <para>
1317         There is much rumor and misinformation regarding the use of MS Windows networking protocols.
1318         These questions are just a few of those frequently asked.
1319         </para>
1320
1321         <qandaset defaultlabel="chap07qa" type="number">
1322         <qandaentry>
1323         <question>
1324
1325             <para>
1326                 <indexterm><primary>DHCP</primary></indexterm>
1327                 <indexterm><primary>network</primary><secondary>bandwidth</secondary></indexterm>
1328                 Is it true that DHCP uses lots of WAN bandwidth?
1329                 </para>
1330
1331         </question>
1332         <answer>
1333
1334             <para>
1335                 <indexterm><primary>DHCP</primary><secondary>Relay Agent</secondary></indexterm>
1336                 <indexterm><primary>routers</primary></indexterm>
1337                 <indexterm><primary>DHCP</primary><secondary>servers</secondary></indexterm>
1338                 It is a smart practice to localize DHCP servers on each network segment. As a
1339                 rule, there should be two DHCP servers per network segment. This means that if
1340                 one server fails, there is always another to service user needs. DHCP requests use
1341                 only UDP broadcast protocols. It is possible to run a DHCP Relay Agent on network
1342                 routers. This makes it possible to run fewer DHCP servers.
1343                 </para>
1344
1345             <para>
1346                 <indexterm><primary>DHCP</primary><secondary>request</secondary></indexterm>
1347                 <indexterm><primary>DHCP</primary><secondary>traffic</secondary></indexterm>
1348                 A DHCP network address request and confirmation usually results in about six UDP packets.
1349                 The packets are from 60 to 568 bytes in length. Let us consider a site that has 300 DHCP
1350                 clients and that uses a 24-hour IP address lease. This means that all clients renew
1351                 their IP address lease every 24 hours. If we assume an average packet length equal to the
1352                 maximum (just to be on the safe side), and we have a 128 Kb/sec wide-area connection,
1353                 how significant would the DHCP traffic be if all of it were to use DHCP Relay?
1354                 </para>
1355
1356                 <para>
1357                 I must stress that this is a bad design, but here is the calculation:
1358 <screen>
1359 Daily Network Capacity: 128,000 (Kbits/s) / 8 (bits/byte)
1360                              x 3600 (sec/hr) x 24 (hrs/day)= 2288 Mbytes/day.
1361
1362 DHCP traffic:          300 (clients) x 6 (packets)
1363                                        x 512 (bytes/packet) = 0.9 Mbytes/day.
1364 </screen>
1365                 From this can be seen that the traffic impact would be minimal.
1366                 </para>
1367
1368             <para>
1369                 <indexterm><primary>DNS</primary><secondary>Dynamic</secondary></indexterm>
1370                 <indexterm><primary>DHCP</primary></indexterm>
1371                 Even when DHCP is configured to do DNS update (dynamic DNS) over a wide-area link,
1372                 the impact of the update is no more than the DHCP IP address renewal traffic and thus
1373                 still insignificant for most practical purposes.
1374                 </para>
1375
1376         </answer>
1377         </qandaentry>
1378
1379         <qandaentry>
1380         <question>
1381
1382             <para>
1383                 <indexterm><primary>background communication</primary></indexterm>
1384                 <indexterm><primary>LDAP</primary><secondary>master/slave</secondary><tertiary>background communication</tertiary></indexterm>
1385                 How much background communication takes place between a master LDAP server and its slave LDAP servers?
1386                 </para>
1387
1388         </question>
1389         <answer>
1390
1391             <para>
1392                 <indexterm><primary>slurpd</primary></indexterm>
1393                 The process that controls the replication of data from the master LDAP server to the slave LDAP
1394                 servers is called <command>slurpd</command>. The <command>slurpd</command> remains nascent (quiet)
1395                 until an update must be propagated. The propagation traffic per LDAP slave to update (add/modify/delete)
1396                 two user accounts requires less than 10KB traffic.
1397                 </para>
1398
1399         </answer>
1400         </qandaentry>
1401
1402         <qandaentry>
1403         <question>
1404
1405                 <para>
1406                 LDAP has a database. Is LDAP not just a fancy database front end?
1407                 </para>
1408
1409         </question>
1410         <answer>
1411
1412             <para>
1413                 <indexterm><primary>database</primary></indexterm>
1414                 <indexterm><primary>LDAP</primary><secondary>database</secondary></indexterm>
1415                 <indexterm><primary>SQL</primary></indexterm>
1416                 <indexterm><primary>transactional</primary></indexterm>
1417                 LDAP does store its data in a database of sorts. In fact, the LDAP backend is an application-specific
1418                 data storage system. This type of database is indexed so that records can be rapidly located, but the
1419                 database is not generic and can be used only in particular pre-programmed ways. General external
1420                 applications do not gain access to the data. This type of database is used also by SQL servers. Both
1421                 an SQL server and an LDAP server provide ways to access the data. An SQL server has a transactional
1422                 orientation and typically allows external programs to perform ad hoc queries, even across data tables.
1423                 An LDAP front end is a purpose-built tool that has a search orientation that is designed around specific
1424                 simple queries. The term <constant>database</constant> is heavily overloaded and thus much misunderstood.
1425                 </para>
1426
1427         </answer>
1428         </qandaentry>
1429
1430         <qandaentry>
1431         <question>
1432
1433             <para>
1434                 <indexterm><primary>OpenLDAP</primary></indexterm>
1435                 Can Active Directory obtain account information from an OpenLDAP server?
1436                 </para>
1437
1438         </question>
1439         <answer>
1440
1441             <para>
1442                 <indexterm><primary>meta-directory</primary></indexterm>
1443                 No, at least not directly. It is possible to provision Active Directory from and/or to an OpenLDAP
1444                 database through use of a metadirectory server. Microsoft MMS (now called MIIS) can interface
1445                 to OpenLDAP using standard LDAP queries and updates.
1446                 </para>
1447
1448         </answer>
1449         </qandaentry>
1450
1451         <qandaentry>
1452         <question>
1453
1454                 <para>
1455                 What are the parts of a roaming profile? How large is each part?
1456                 </para>
1457
1458         </question>
1459         <answer>
1460
1461             <para><indexterm>
1462                 <primary>roaming profile</primary>
1463               </indexterm>
1464                 A roaming profile consists of
1465                 </para>
1466
1467                 <itemizedlist>
1468                         <listitem><para>
1469                         Desktop folders such as <constant>Desktop</constant>, <constant>My Documents</constant>,
1470                         <constant>My Pictures</constant>, <constant>My Music</constant>, <constant>Internet Files</constant>,
1471                         <constant>Cookies</constant>, <constant>Application Data</constant>,
1472                         <constant>Local Settings,</constant> and more. See <link linkend="happy"/>, <link linkend="XP-screen001"/>.
1473                         </para>
1474
1475                         <para>
1476                         <indexterm><primary>folder redirection</primary></indexterm>
1477                         Each of these can be anywhere from a few bytes to gigabytes in capacity. Fortunately, all
1478                         such folders can be redirected to network drive resources. See <link linkend="redirfold"/>
1479                         for more information regarding folder redirection.
1480                         </para></listitem>
1481
1482                         <listitem><para>
1483                         A static or rewritable portion that is typically only a few files (2-5 KB of information).
1484                         </para></listitem>
1485
1486                         <listitem><para>
1487                         <indexterm><primary>NTUSER.DAT</primary></indexterm>
1488                         <indexterm><primary>HKEY_LOCAL_USER</primary></indexterm>
1489                         The registry load file that modifies the <constant>HKEY_LOCAL_USER</constant> hive. This is
1490                         the <filename>NTUSER.DAT</filename> file. It can be from 0.4 to 1.5 MB.
1491                         </para></listitem>
1492                 </itemizedlist>
1493
1494             <para>
1495                 <indexterm><primary>Microsoft Outlook</primary><secondary>PST files</secondary></indexterm>
1496                 Microsoft Outlook PST files may be stored in the <constant>Local Settings\Application Data</constant>
1497                 folder. It can be up to 2 GB in size per PST file.
1498                 </para>
1499
1500         </answer>
1501         </qandaentry>
1502
1503         <qandaentry>
1504         <question>
1505
1506                 <para>
1507                 Can the <constant>My Documents</constant> folder be stored on a network drive?
1508                 </para>
1509
1510         </question>
1511         <answer>
1512
1513             <para>
1514                 <indexterm><primary>UNC name</primary></indexterm>
1515                 <indexterm><primary>Universal Naming Convention</primary><see>UNC name</see></indexterm>
1516                 Yes. More correctly, such folders can be redirected to network shares. No specific network drive
1517                 connection is required. Registry settings permit this to be redirected directly to a UNC (Universal
1518                 Naming Convention) resource, though it is possible to specify a network drive letter instead of a
1519                 UNC name. See <link linkend="redirfold"/>.
1520                 </para>
1521
1522         </answer>
1523         </qandaentry>
1524
1525         <qandaentry>
1526         <question>
1527
1528             <para>
1529                 <indexterm><primary>wide-area</primary></indexterm>
1530                 <indexterm><primary>network</primary><secondary>bandwidth</secondary></indexterm>
1531                 <indexterm><primary>WINS</primary></indexterm>
1532                 How much WAN bandwidth does WINS consume?
1533                 </para>
1534
1535         </question>
1536         <answer>
1537
1538             <para>
1539                 <indexterm><primary>NetBIOS</primary><secondary>name cache</secondary></indexterm>
1540                 <indexterm><primary>WINS server</primary></indexterm>
1541                 <indexterm><primary>domain replication</primary></indexterm>
1542                 MS Windows clients cache information obtained from WINS lookups in a local NetBIOS name cache.
1543                 This keeps WINS lookups to a minimum. On a network with 3500 MS Windows clients and a central WINS
1544                 server, the total bandwidth demand measured at the WINS server, averaged over an 8-hour working day,
1545                 was less than 30 KB/sec. Analysis of network traffic over a 6-week period showed that the total
1546                 of all background traffic consumed about 11 percent of available bandwidth over 64 Kb/sec links.
1547                 Background traffic consisted of domain replication, WINS queries, DNS lookups, and authentication
1548                 traffic. Each of 11 branch offices had a 64 Kb/sec wide-area link, with a 1.5 Mb/sec main connection
1549                 that aggregated the branch office connections plus an Internet connection.
1550                 </para>
1551
1552                 <para>
1553                 In conclusion, the total load afforded through WINS traffic is again marginal to total operational
1554                 usage &smbmdash; as it should be.
1555                 </para>
1556
1557         </answer>
1558         </qandaentry>
1559
1560         <qandaentry>
1561         <question>
1562
1563                 <para>
1564                 How many BDCs should I have? What is the right number of Windows clients per server?
1565                 </para>
1566
1567         </question>
1568         <answer>
1569
1570                 <para>
1571                 It is recommended to have at least one BDC per network segment, including the segment served
1572                 by the PDC. Actual requirements vary depending on the working load on each of the BDCs and the
1573                 load demand pattern of client usage. I have seen sites that function without problem with 200
1574                 clients served by one BDC, and yet other sites that had one BDC per 20 clients. In one particular
1575                 company, there was a drafting office that had 30 CAD/CAM operators served by one server, a print
1576                 server; and an application server. While all three were BDCs, typically only the print server would
1577                 service network logon requests after the first 10 users had started to use the network. This was
1578                 a reflection of the service load placed on both the application server and the data server.
1579                 </para>
1580
1581                 <para>
1582                 As unsatisfactory as the answer might sound, it all depends on network and server load
1583                 characteristics.
1584                 </para>
1585
1586         </answer>
1587         </qandaentry>
1588
1589         <qandaentry>
1590         <question>
1591
1592             <para>
1593                 <indexterm><primary>NIS server</primary></indexterm><indexterm><primary>LDAP</primary></indexterm>
1594                 I've heard that you can store NIS accounts in LDAP. Is LDAP not just a smarter way to
1595                 run an NIS server?
1596                 </para>
1597
1598         </question>
1599         <answer>
1600
1601                 <para>
1602                 The correct answer to both questions is yes. But do understand that an LDAP server has
1603                 a configurable schema that can store far more information for many more purposes than
1604                 just NIS.
1605                 </para>
1606
1607         </answer>
1608         </qandaentry>
1609
1610         <qandaentry>
1611         <question>
1612
1613                 <para>
1614                 Can I use NIS in place of LDAP?
1615                 </para>
1616
1617         </question>
1618         <answer>
1619
1620             <para>
1621                 <indexterm><primary>NIS</primary></indexterm>
1622                 <indexterm><primary>NIS schema</primary></indexterm>
1623                 No. The NIS database does not have provision to store Microsoft encrypted passwords and does not deal
1624                 with the types of data necessary for interoperability with Microsoft Windows networking. The use
1625                 of LDAP with Samba requires the use of a number of schemas, one of which is the NIS schema, but also
1626                 a Samba-specific schema extension.
1627                 </para>
1628
1629 </answer>
1630         </qandaentry>
1631
1632         </qandaset>
1633 </sect1>
1634
1635 </chapter>
1636