docs/Samba-Guide/Chap07-2000UserNetwork.xml

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