path: root/docs/Samba-Guide/SBE-2000UserNetwork.xml

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
<chapter id="2000users">
  <title>A Distributed 2000 User Network</title>

    <para>There is something indeed mystical about things that are
      big. Large networks exhibit a certain magnetism and exude a sense of
      importance that obscures reality. You and I know that it is no more
      difficult to secure a large network than it is a small one. We all
      know that over and above a particular number of network clients, the
      rules no longer change; the only real dynamic is the size of the domain
      (much like a kingdom) over which the network ruler (oops, administrator)
      has control. The real dynamic then transforms from the technical to the
      political. Then again, that point is often reached well before the
      kingdom (or queendom) grows large.</para>

    <para>If you have systematically worked your way to this chapter, hopefully you
      have found some gems and techniques that are applicable in your
      world. The network designs you have worked with in this book with have their
      strong points as well as weak ones. That is to be expected given that
      they are based on real business environments, excepting that the facts
      have been moulded to serve the purposes of this book.</para>

    <para>This chapter is intent on wrapping up issues that are central to
    implementation and design of progressively larger networks. Are you ready
    for this chapter? Good, it is time to move on.</para>

    <para>In previous chapters, you made the assumption that your network
      administration staff need detailed instruction right down to the
      nuts-and-bolts of implementing the solution. That's is still the case,
      but they have graduated now. You decide to document only those issues,
      methods and techniques that are new or complex. Routine tasks such as
      implementing a DNS or a DHCP server are under control. Even the basics of
      Samba are largely under control. So in this section you focus on the
      specifics of implementing LDAP changes, Samba changes, and approach and
      design of the solution and its deployment.</para>

<sect1>
	<title>Introduction</title>

	<para>
	Abmas is a miracle company. Most businesses would have collapsed under
	the weight of rapid expansion that this company has experienced. Samba 
	is flexible, so there is no need to reinstall the whole operating 
	system just because you need to implement a new network design. In fact, 
	you can keep an old server running right up to the moment of cut-over 
	and then do a near-live conversion. There is no need to reinstall a 
	Samba server just to change the way your network should function.
	</para>

      <para><indexterm>
	  <primary>LDAP</primary>
	</indexterm>
	Network growth is common to all organizations. In this exercise,
	your preoccupation is with the mechanics of implementing Samba and
	LDAP so that network users on each network segment can work
        without impediment.</para>

	<sect2>
		<title>Assignment Tasks</title>

	<para>
	  Starting with the configuration files for the server called
	  <constant>MASSIVE</constant> in Chapter 6, you now deal with the
	  issues that are particular to large distributed networks. Your task
	  is simple &smbmdash; identify the challenges, consider the 
	  alternatives, and then design and implement a solution.</para>

	<para><indexterm>
	    <primary>VPN</primary>
	  </indexterm>
	  Remember, you have users based in London (UK), Los Angeles,
	  Washington DC, and three buildings in New York. A significant portion
	  of your workforce have notebook computers and roam all over the
	  world. Some dial into the office, others use VPN connections over the
	  Internet and others just move between buildings.</para>

	<para>What do you say to an employee who normally uses a desktop
	  system but must spend six weeks on the road with a notebook computer?
	  She is concerned over email access and how to keep co-workers current
	  with changing documents.</para>

	<para>To top it all off, you have one network support person and one 
  	  Help desk person based in London, a single person dedicated to all 
	  network operations in Los Angeles, five staff for user administration 
	  and Help desk in New York, plus one <emphasis>floater</emphasis> for 
	  Washington DC.</para>

	<para>You have outsourced all desktop deployment and management to
	  DirectPointe,Inc. Your concern is server maintenance and third-level
	  support. Build a plan and show what must be done.</para>

	</sect2>
</sect1>

<sect1>
	<title>Dissection and Discussion</title>

      <para><indexterm>
	  <primary>passdb backend</primary>
	</indexterm><indexterm>
	  <primary>LDAP</primary>
	</indexterm>
	In the previous chapter, you implemented an LDAP server that provided the
	<parameter>passdb backend</parameter> for the Samba servers. You
	explored ways to accelerate Windows desktop profile handling and you
	took control of network performance.
	</para>

      <para><indexterm>
	  <primary>ldapsam</primary>
	</indexterm><indexterm>
	  <primary>tdbsam</primary>
	</indexterm><indexterm>
	  <primary>smbpasswd</primary>
	</indexterm><indexterm>
	  <primary>replicated</primary>
	</indexterm>
	The implementation of an LDAP-based passdb backend (known as
	<emphasis>ldapsam</emphasis> in Samba parlance), or some form of database
        that can be distributed, is essential to permit the deployment of Samba
	Primary and Backup Domain Controllers (PDC/BDCs). You see, the problem
	is that the <emphasis>tdbsam</emphasis> style passdb backend does not
	lend itself to being replicated. The older plain-text-based
	<emphasis>smbpasswd</emphasis> style passdb backend can be replicated
	using a tool such as <command>rsync</command>, but
	<emphasis>smbpasswd</emphasis> suffers the drawback that it does not
	support the range of account facilities demanded by modern network
	managers.</para>

      <para><indexterm>
	  <primary>XML</primary>
	</indexterm><indexterm>
	  <primary>SQL</primary>
	</indexterm>
	The new <emphasis>tdbsam</emphasis> facility supports functionality
        that is similar to an <emphasis>ldapsam</emphasis>, but the lack of
	distributed infrastructure sorely limits the scope for its
	deployment. This does raise the following questions: "Why can't I just use
	an XML based backend, or for that matter, why not use an SQL based
	backend?" "Is support for these tools broken?" No. Answers to these
	questions require a bit of background.</para>

      <para><indexterm>
	  <primary>directory</primary>
	</indexterm><indexterm>
	  <primary>database</primary>
	</indexterm><indexterm>
	  <primary>transaction processing</primary>
	</indexterm><indexterm>
	  <primary>LDAP</primary>
	</indexterm>
	<emphasis>What is a directory?</emphasis> A directory is a
	collection of information regarding objects that can be accessed to
	rapidly find information that is relevant in a particular and
	consistent manner. A directory differs from a database in that it is
	generally more often searched (read) than updated. As a consequence, the
	information is organized to facilitate read access rather than to
	support transaction processing.</para>

      <para><indexterm>
	  <primary>Lightweight Directory Access Protocol </primary>
	  <see>LDAP</see>
	</indexterm><indexterm>
	  <primary>LDAP</primary>
	</indexterm><indexterm>
	  <primary>master</primary>
	</indexterm><indexterm>
	  <primary>slave</primary>
	</indexterm>
	The Lightweight Directory Access Protocol (LDAP) differs
	considerably from a traditional database. It has a simple search
	facility that uniquely makes a highly preferred mechanism for managing
	user identities. LDAP provides a scalable mechanism for distributing
	the data repository and for keeping all copies (slaves) in sync with
	the master repository.</para>

      <para><indexterm>
	  <primary>identity management</primary>
	</indexterm><indexterm>
	  <primary>Active Directory</primary>
	</indexterm><indexterm>
	  <primary>OpenLDAP</primary>
	</indexterm>
	Samba is a flexible and powerful file and print sharing
	technology. It can use many external authentication sources and can be
	part of a total authentication and identity management
	infrastructure. The two most important external sources for large sites
        are Microsoft Active Directory and LDAP. Sites that specifically wish to
	avoid the proprietary implications of Microsoft Active Directory
	naturally gravitate toward OpenLDAP.</para>

      <para><indexterm>
	  <primary>network</primary>
	  <secondary>routed</secondary>
	</indexterm>
	In Chapter 6, you had to deal with a locally routed
	network. All deployment concerns focused around making users happy,
	and that simply means taking control over all network practices and
	usage so that no one user is disadvantaged by any other. The real
	lesson is one of understanding that no matter how much network
	bandwidth you provide, bandwidth remains a precious resource.</para>

      <para>In this chapter, you must now consider how the overall network must
	function. In particular, you must be concerned with users who move
        between offices. You must take into account the way users need to
	access information globally. And you must make the network robust
	enough so that it can sustain partial breakdown without causing loss of
        productivity.</para>

	<sect2>
		<title>Technical Issues</title>

	<para>There are at least three areas that need to be addressed as you
	  approach the challenge of designing a network solution for the newly
	  expanded business. These are:</para>

	<itemizedlist>
	  <listitem>
	    <para><indexterm>
		<primary>mobility</primary>
	      </indexterm>
	      User needs such as mobility and data access</para>
	  </listitem>
	  <listitem>
	    <para>The nature of Windows networking protocols</para>
	  </listitem>
	  <listitem>
	    <para>Identity management infrastructure needs</para>
	  </listitem>
	</itemizedlist>

	<para>Let's look at each in turn.</para>

	<sect3>
	  <title>User Needs</title>

	  <para>The new company has three divisions. Staff for each division
	    are spread across the company. Some staff are office-bound and
	    some are mobile users. Mobile users travel globally. Some spend
	    considerable periods working in other offices. Everyone wants to be
	    able to work without constraint of productivity.</para>

	  <para>The challenge is not insignificant. In some parts of the world,
	    even dial-up connectivity is poor, while in other regions political
	    encumbrances severely curtail user needs. Parts of the global
	    Internet infrastructure remain shielded-off for reasons outside 
	    the scope of this discussion.</para>

	  <para><indexterm>
	      <primary>synchronize</primary>
	    </indexterm>
	    Decisions must be made regarding where data is to be stored, how
	    it will be replicated (if at all), and what the network bandwidth
	    implications are. For example, one decision that can be made is
	    to give each office its own master file storage area that can be
	    synchronized to a central repository in New York. This would permit
	    global data to be backed up from a single location. The
	    synchronization tool could be <command>rsync,</command> run via a
	    cron job. Mobile users may use off-line file storage under Windows
	    XP Professional. This way, they can synchronize all files that have
	    changed since each logon to the network.</para>

	  <para><indexterm>
	      <primary>bandwidth</primary>
	      <secondary>requirements</secondary>
	    </indexterm><indexterm>
	      <primary>roaming profile</primary>
	    </indexterm>
	    No matter which way you look at this, the bandwidth requirements
	    for acceptable performance are substantial even if only 10 percent of
	    staff are global data users. A company with 3500 employees
	    and 280 of those were mobile users, and who used a similarly distributed
	    network, found they needed at least 2 Megabit/sec connectivity
	    between the UK and US offices. Even over 2 Mb/s bandwidth, this
	    company abandoned any attempt to run roaming profile usage for
	    mobile users. At that time, the average roaming profile took 480
	    Kbytes, while today the minimum Windows XP Professional roaming
	    profile involves a transfer of over 750 Kbytes from the profile
	    server to/from the client.</para>

	  <para><indexterm>
	      <primary>wide-area</primary>
	    </indexterm>
	    Obviously then, user needs and wide-area practicalities
	    dictate the economic and technical aspects of your network
	    design as well as for standard operating procedures.</para>

	</sect3>

	<sect3>
	  <title>The Nature of Windows Networking Protocols</title>

	  <para><indexterm>
	      <primary>profile</primary>
	      <secondary>mandatory</secondary>
	    </indexterm>
	    Network logons that include roaming profile handling requires
	    from 140 Kbytes to 2 Mbytes. The inclusion of support for a minimal
	    set of common desktop applications can push the size of a complete
	    profile to over 15 Mbytes. This has substantial implications so far
	    as location of user profiles is concerned. Additionally, it is a
	    significant factor in determining the nature and style of mandatory
	    profiles that may be enforced as part of a total service level
	    assurance program that might be implemented.</para>

	  <para><indexterm>
	      <primary>logon traffic</primary>
	    </indexterm><indexterm>
	      <primary>redirected folders</primary>
	    </indexterm>
	    One way to reduce the network bandwidth impact of user logon
	    traffic is through folder redirection. In Chapter 6, you
	    implemented this in the new Windows XP Professional standard
	    desktop configuration. When desktop folders such as <guimenu>My
	    Documents</guimenu> are redirected to a network drive, they should
	    also be excluded from synchronization to/from the server on
	    logon/out. Redirected folders are analogous to network drive
	    connections.</para>

	  <para><indexterm>
	      <primary>application servers</primary>
	    </indexterm>
	    Of course, network applications should only be run off
	    local application servers. As a general rule, even with 2 Mbit/sec
	    network bandwidth, it would not make sense at all for someone who
	    is working out of the London office to run applications off a
	    server that is located in New York.</para>

	  <para><indexterm>
	      <primary>affordability</primary>
	    </indexterm>
	    When network bandwidth becomes a precious commodity (that is most
	    of the time), there is a significant demand to understand network
	    processes and to mould the limits of acceptability around the
	    constraints of affordability.</para>

	  <para>When a Windows NT4/200x/XP Professional client user logs onto
	    the network, several important things must happen.</para>

	  <itemizedlist>
	    <listitem>
	      <para><indexterm>
		  <primary>DHCP</primary>
		</indexterm>
		The client obtains an IP address via DHCP. (DHCP is
		necessary so that users can roam between offices.)</para>
	    </listitem>
	    <listitem>
	      <para><indexterm>
		  <primary>WINS</primary>
		</indexterm><indexterm>
		  <primary>DNS</primary>
		</indexterm>
		The client must register itself with the WINS and/or DNS
		server.</para>
	    </listitem>
	    <listitem>
	      <para><indexterm>
		  <primary>Domain Controller</primary>
		  <secondary>closest</secondary>
		</indexterm>
		The client must locate the closest Domain Controller.</para>
	    </listitem>
	    <listitem>
	      <para>The client must log onto a Domain Controller and obtain as
		part of that process the location of the user's profile, load
		it, connect to redirected folders, and establish all network
		drive and printer connections.</para>
	    </listitem>
	    <listitem>
	      <para>The Domain Controller must be able to resolve the user's
		credentials before the logon process is fully implemented.</para>
	    </listitem>
	  </itemizedlist>

	  <para>Given that this book is about Samba and the fact that it
	    implements the Windows NT4 style domain semantics, it makes little
	    sense to compare Samba with Microsoft Active Directory insofar as
	    the logon protocols and principles of operation are
	    concerned. The following information pertains exclusively to the
	    interaction between a Windows XP Professional workstation and a
	    Samba-3.0.15 server. In the discussion that follows, use is made of
	    DHCP and WINS.</para>

	  <para>As soon as the Windows workstation starts up, it obtains an
	    IP address. This is immediately followed by registration of its
	    name both by broadcast and Unicast registration that is directed
	    at the WINS server.</para>

	  <para><indexterm>
	      <primary>Unicast</primary>
	    </indexterm><indexterm>
	      <primary>broadcast</primary>
	      <secondary>directed</secondary>
	    </indexterm><indexterm>
	      <primary>NetBIOS</primary>
	    </indexterm>
	    Given that the client is already a Domain Member, it then sends
  	    a directed (Unicast) request to the WINS server seeking the list of
	    IP addresses for domain controllers (NetBIOS name type 0x1C). The
	    WINS server replies with the information requested.</para>

	  <para><indexterm>
	      <primary>broadcast</primary>
	      <secondary>mailslot</secondary>
	    </indexterm><indexterm>
	      <primary>Unicast</primary>
	    </indexterm><indexterm>
	      <primary>WINS</primary>
	    </indexterm>
	    The client sends two netlogon mailslot broadcast requests
	    to the local network and to each of the IP addresses returned by
	    the WINS server. Whichever answers this request first appears to
	    be the machine that the Windows XP client attempts to use to
	    process the network logon. The mailslot messages use UDP broadcast
	    to the local network and UDP Unicast directed at each machine that
	    was listed in the WINS server response to a request for the list of
	    Domain Controllers.</para>

	  <para><indexterm>
	      <primary>protocol</primary>
	      <secondary>negotiation</secondary>
	    </indexterm><indexterm>
	      <primary>logon server</primary>
	    </indexterm><indexterm>
	      <primary>fail</primary>
	    </indexterm>
	    The logon process begins with negotiation of the SMB/CIFS
	    protocols that are to be used; this is followed by an exchange of
	    information that ultimately includes the client sending the
	    credentials with which the user is attempting to logon. The logon
	    server must now approve the further establishment of the
	    connection, but that is a good point to halt for now. The priority
	    here must center around identification of network infrastructure
	    needs. A secondary fact we need to know is, what happens when
	    local Domain Controllers fail or break?</para>

	  <para><indexterm>
	      <primary>Domain Controller</primary>
	    </indexterm><indexterm>
	      <primary>PDC</primary>
	    </indexterm><indexterm>
	      <primary>BDC</primary>
	    </indexterm><indexterm>
	      <primary>netlogon</primary>
	    </indexterm>
	    Under most circumstances, the nearest Domain Controller
	    responds to the netlogon mailslot broadcast. The exception to this
	    norm occurs when the nearest Domain Controller is too busy or is out
	    of service. Herein lies an important fact. This means it is
	    important that every network segment should have at least two
	    Domain Controllers. Since there can be only one Primary Domain
	    Controller (PDC), all additional Domain Controllers are by definition
	    Backup Domain Controllers (BDCs).</para>

	  <para><indexterm>
	      <primary>authentication</primary>
	    </indexterm><indexterm>
	      <primary>Identity Management</primary>
	    </indexterm>
	    The provision of sufficient servers that are BDCs is an
	    important design factor. The second important design factor
	    involves how each of the BDCs obtains user authentication
	    data. That is the subject of the next section as it involves key
	    decisions regarding Identity Management facilities.</para>

	</sect3>

	<sect3>
	  <title>Identity Management Needs</title>

	  <para><indexterm>
	      <primary>privacy</primary>
	    </indexterm><indexterm>
	      <primary>user credentials</primary>
	    </indexterm><indexterm>
	      <primary>validated</primary>
	    </indexterm><indexterm>
	      <primary>privileges</primary>
	    </indexterm>
	    Network managers recognize that in large organizations users
	    generally need to be given resource access based on needs, while
	    being excluded from other resources for reasons of privacy. It is,
	    therefore, essential that all users identify themselves at the
	    point of network access. The network logon is the principal means
	    by which user credentials are validated and filtered, and appropriate
	    rights and privileges are allocated.</para>

	  <para><indexterm>
	      <primary>Identity Management</primary>
	    </indexterm><indexterm>
	      <primary>Yellow Pages</primary>
	    </indexterm><indexterm>
	      <primary>NIS</primary>
	    </indexterm>
	    Unfortunately, network resources tend to have their own Identity 
	    Management facilities, the quality and manageability of which varies 
	    from quite poor to exceptionally good. Corporations that use a mixture 
	    of systems soon discover that until recently, few systems were 
	    designed to interoperate. For example, UNIX systems each have an 
	    independent user database. Sun Microsystems developed a facility that 
	    was originally called <constant>Yellow Pages</constant>, and was renamed 
	    when a telephone company objected to the use of its trademark. 
	    What was once called <constant>Yellow Pages</constant> is today known 
	    as <constant>Network Information System</constant> (NIS).</para>

	  <para><indexterm>
	      <primary>NIS+</primary>
	    </indexterm>
	    NIS gained a strong following throughout the UNIX/VMS space in a
	    short period of time and retained that appeal and use
	    for over a decade. Security concerns as well as inherent limitations
	    have caused it to enter its twilight. NIS did not gain widespread
	    appeal outside of the UNIX world and was not universally
	    adopted. Sun updated this to a more secure implementation called
	    NIS+, but even it has fallen victim to changing demands as the
	    demand for directory services that can be coupled with other
	    information systems is catching on.</para>

	  <para><indexterm>
	      <primary>NIS</primary>
	    </indexterm><indexterm>
	      <primary>government</primary>
	    </indexterm><indexterm>
	      <primary>education</primary>
	    </indexterm>
	    Nevertheless, both NIS and NIS+ continue to hold ground in
	    business areas where UNIX still has major sway. Examples of
	    organizations that remain firmly attached to the use of NIS and
	    NIS+ includes large government departments, education institutions,
	    as well as large corporations that have a scientific or engineering
	    focus.</para>

	  <para><indexterm>
	      <primary>scalable</primary>
	    </indexterm><indexterm>
	      <primary>distributed</primary>
	    </indexterm>
	    Today's networking world needs a scalable, distributed Identity 
	    Management infrastructure, commonly called a directory. The most 
	    popular technologies today are Microsoft Active Directory service 
	    and a number of LDAP implementations.</para>

	  <para><indexterm>
	      <primary>multiple directories</primary>
	    </indexterm>
	    The problem of managing multiple directories has become a focal
	    point over the past decade. This has created a large market for
	    meta-directory products and services that allow organizations that
	    have multiple directories and multiple management and control
	    centers to provision information from one directory into
	    another. The attendant benefit to end users is the promise of
	    having to remember and deal with fewer login identities and
	    passwords.</para>

	  <para><indexterm>
	      <primary>network</primary>
	      <secondary>bandwidth</secondary>
	    </indexterm>
	    The challenge of every large network is to find the optimum
	    balance of internal systems and facilities for Identity
	    Management resources. How well the solution is chosen and
	    implemented has potentially significant impact on network bandwidth
	    and systems response needs.</para>

	  <para><indexterm>
	      <primary>LDAP server</primary>
	    </indexterm><indexterm>
	      <primary>LDAP</primary>
	      <secondary>master</secondary>
	    </indexterm><indexterm>
	      <primary>LDAP</primary>
	      <secondary>slave</secondary>
	    </indexterm>
	    In Chapter 6, you implemented a single LDAP server for the
	    entire network. This may work for smaller networks, but almost
	    certainly fails to meet the needs of large and complex networks. The
	    following section documents how one may implement a single
	    master LDAP server, with multiple slave servers.</para>

	  <para>What is the best method for implementing master/slave LDAP
	    servers within the context of a distributed 2000 user network is a
	    question that remains to be answered.</para>

	  <para><indexterm>
	      <primary>distributed domain</primary>
	    </indexterm><indexterm>
	      <primary>wide-area</primary>
	    </indexterm>
	    One possibility that has great appeal is to create one single
	    large distributed domain. The practical implications of this
	    design (see <link linkend="chap7net"/>) demands the placement of
	    sufficient BDCs in each location. Additionally, network
	    administrators must make sure that profiles are not transferred
	    over the wide-area links, except as a totally unavoidable
	    measure. Network design must balance the risk of loss of user
	    productivity against the cost of network management and
	    maintenance.</para>

	  <para><indexterm>
	      <primary>domain name space</primary>
	    </indexterm>
	    The network design in <link linkend="chap7net2"/> takes the
	    approach that management of networks that are too remote to be
	    capable of being managed effectively from New York ought
	    to be given a certain degree of autonomy. With this rationale, the
	    Los Angeles and London networks, though fully integrated with that
	    on the east coast of the USA, each have their own domain name space
	    and can be independently managed and controlled. One of the key
	    drawbacks of this design is that it flies in the face of the
	    ability for network users to roam globally without some compromise
	    in how they may access global resources.</para>

	  <para><indexterm>
	      <primary>interdomain trusts</primary>
	    </indexterm>
	    Desk-bound users need not be negatively affected by this
	    design, since the use of interdomain trusts can be used to satisfy
	    the need for global data sharing.</para>

	  <para><indexterm>
	      <primary>LDAP</primary>
	    </indexterm><indexterm>
	      <primary>LDAP</primary>
	      <secondary>backend</secondary>
	    </indexterm><indexterm>
	      <primary>SID</primary>
	    </indexterm>
	    When Samba-3 is configured to use an LDAP backend, it stores the domain
	    account information in a directory entry. This account entry contains
	    the domain SID. An unintended but exploitable side effect is that
	    this makes it possible to operate with more than one PDC on a
	    distributed network.</para>

	  <para><indexterm>
	      <primary>WINS</primary>
	    </indexterm><indexterm>
	      <primary>wins.dat</primary>
	    </indexterm><indexterm>
	      <primary>SID</primary>
	    </indexterm>
	    How might this peculiar feature be exploited? The answer is
	    simple. It is imperative that each network segment should have its
	    own WINS server. Major servers on remote network segments can be
	    given a static WINS entry in the <filename>wins.dat</filename> file
	    on each WINS server. This allows all essential data to be
	    visible from all locations. Each location would, however, function
	    as if it is an independent domain, while all sharing the same
	    domain SID. Since all domain account information can be stored in a
	    single LDAP backend, users have unfettered ability to
	    roam.</para>

	  <para><indexterm>
	      <primary>NetBIOS name</primary>
	      <secondary>aliases</secondary>
	    </indexterm><indexterm>
	      <primary>fail-over</primary>
	    </indexterm>
	    This concept has not been exhaustively validated, though we can
	    see no reason why this should not work. The important facets
	    are: The name of the domain must be identical in all
	    locations. Each network segment must have its own WINS server. The
	    name of the PDC must be the same in all locations; this
	    necessitates the use of NetBIOS name aliases for each PDC so that
	    they can be accessed globally using the alias and not the PDC's
	    primary name. A single master LDAP server can be based in New York,
	    with multiple LDAP slave servers located on every network
	    segment. Finally, the BDCs should each use fail-over LDAP servers
	    that are in fact slave LDAP servers on the local segments.</para>

	  <para><indexterm>
	      <primary>LDAP</primary>
	      <secondary>updates</secondary>
	    </indexterm><indexterm>
	      <primary>domain tree</primary>
	    </indexterm><indexterm>
	      <primary>LDAP</primary>
	      <secondary>database</secondary>
	    </indexterm><indexterm>
	      <primary>LDAP</primary>
	      <secondary>directory</secondary>
	    </indexterm>
	    With a single master LDAP server, all network updates are
	    effected on a single server. In the event that this should become
	    excessively fragile or network bandwidth limiting, one could
	    implement a delegated LDAP domain. This is also known as a 
	    partitioned (or multiple partition) LDAP database
	    and as a distributed LDAP directory.</para>

	  <para>As the LDAP directory grows, it becomes increasingly important
	    that its structure is implemented in a manner that mirrors
	    organizational needs, so as to limit network update and
	    referential traffic. It should be noted that all directory
	    administrators must of necessity follow the same standard
	    procedures for managing the directory, as retroactive correction of
	    inconsistent directory information can be exceedingly difficult.</para>

	<image id="chap7net">
		<imagedescription>Network Topology &smbmdash; 2000 User Complex Design A</imagedescription>
		<imagefile scale="60">chap7-net-Ar</imagefile>
	</image>

	<image id="chap7net2">
		<imagedescription>Network Topology &smbmdash; 2000 User Complex Design B</imagedescription>
		<imagefile scale="60">chap7-net2-Br</imagefile>
	</image>

	</sect3>

	</sect2>


	<sect2>
		<title>Political Issues</title>

	<para>As organizations grow, the number of points of control increase
	  also. In a large distributed organization, it is important that the
	  Identity Management system must be capable of being updated from
	  many locations, and it is equally important that changes made should
	  become capable of being used in a reasonable period, typically
	  minutes rather than days (the old limitation of highly manual
	  systems).</para>

	</sect2>

</sect1>

<sect1>
	<title>Implementation</title>

      <para><indexterm>
	  <primary>winbind</primary>
	</indexterm><indexterm>
	  <primary>LDAP</primary>
	</indexterm><indexterm>
	  <primary>UID</primary>
	</indexterm><indexterm>
	  <primary>GID</primary>
	</indexterm>
	Samba-3 has the ability to use multiple password (authentication
	and identity resolution) backends. The diagram in <link
	  linkend="chap7idres"/> demonstrates how Samba uses winbind, LDAP,
	and NIS, the traditional system password database. The diagram only
	documents the mechanisms for authentication and identity resolution
	(obtaining a UNIX UID/GID) using the specific systems shown.
	</para>

	<image id="chap7idres">
		<imagedescription>Samba and Authentication Backend Search Pathways</imagedescription>
		<imagefile scale="55">chap7-idresol</imagefile>
	</image>

      <para><indexterm>
	  <primary>smbpasswd</primary>
	</indexterm><indexterm>
	  <primary>xmlsam</primary>
	</indexterm><indexterm>
	  <primary>SMB passwords</primary>
	</indexterm><indexterm>
	  <primary>tdbsam</primary>
	</indexterm><indexterm>
	  <primary>mysqlsam</primary>
	</indexterm><indexterm>
	  <primary>LDAP</primary>
	</indexterm><indexterm>
	  <primary>distributed</primary>
	</indexterm>
	Samba is capable of using the <constant>smbpasswd</constant>,
	<constant>tdbsam</constant>, <constant>xmlsam</constant>,
	and <constant>mysqlsam</constant> authentication databases. The SMB
	passwords can, of course, also be stored in an LDAP ldapsam
	backend. LDAP is the preferred passdb backend for distributed network
	operations.</para>

      <para><indexterm>
	  <primary>passdb backend</primary>
	</indexterm>
	Additionally, it is possible to use multiple passdb backends
	concurrently as well as have multiple LDAP backends. As a result, one
	can specify a fail-over LDAP backend. The syntax for specifying a
	single LDAP backend in &smb.conf; is:
<screen>
...
passdb backend = ldapsam:ldap://master.abmas.biz
...
</screen>
	This configuration tells Samba to use a single LDAP server as shown in
	<link linkend="ch7singleLDAP"/>.
	<image id="ch7singleLDAP">
		<imagedescription>Samba Configuration to Use a Single LDAP Server</imagedescription>
		<imagefile scale="65">ch7-singleLDAP</imagefile>
	</image>
	<indexterm>
	  <primary>LDAP</primary>
	  <secondary>fail-over</secondary>
	</indexterm><indexterm>
	  <primary>fail-over</primary>
	</indexterm>
	The addition of a fail-over LDAP server can simply be done by adding a
	second entry for the fail-over server to the single
	<parameter>ldapsam</parameter> entry as shown here (note the particular
	use of the double quotes):
<screen>
...
passdb backend = ldapsam:"ldap://master.abmas.biz \
	                  ldap://slave.abmas.biz"
...
</screen>
	This configuration tells Samba to use a master LDAP server, with fail-over to a slave server if necessary,
	as shown in <link linkend="ch7dualLDAP"/>.
	<image id="ch7dualLDAP">
		<imagedescription>Samba Configuration to Use a Dual (Fail-over) LDAP Server</imagedescription>
		<imagefile scale="65">ch7-fail-overLDAP</imagefile>
	</image>
      </para>

      <para>Some folks have tried to implement this without the use of
	double quotes as shown above. This is the type of entry they had
	created:
<screen>
...
passdb backend = ldapsam:ldap://master.abmas.biz \
                 ldapsam:ldap://slave.abmas.biz
...
</screen>
	<indexterm>
	  <primary>contiguous directory</primary>
	</indexterm>
	The effect of this style of entry is that Samba lists the users
	that are in both LDAP databases. If both contain the same information,
	it results in each record being shown twice. This is, of course, not the
	solution desired for a fail-over implementation. The net effect of this
	configuration is shown in <link linkend="ch7dualadd"/>
	</para>

	<image id="ch7dualadd">
		<imagedescription>Samba Configuration to Use Dual LDAP Databases - Broken - Do Not Use!</imagedescription>
		<imagefile scale="55">ch7-dual-additive-LDAP</imagefile>
	</image>

	<para>
	If, however, each LDAP database contains unique information, this may 
	well be an advantageous way to effectively integrate multiple LDAP databases 
	into one seemingly contiguous directory. Only the first database will be updated.
	An example of this configuration is shown in <link linkend="ch7dualok"/>.
        </para>

		<image id="ch7dualok">
			<imagedescription>Samba Configuration to Use Two LDAP Databases - The result is additive.</imagedescription>
			<imagefile scale="55">ch7-dual-additive-LDAP-Ok</imagefile>
		</image>

	<note><para>
	When the use of ldapsam is specified twice, as shown here, it is imperative
	that the two LDAP directories must be disjoint. If the entries are for a
	master LDAP server as well as its own slave server, updates to the LDAP
	database may end up being lost or corrupted. You may safely use multiple
	LDAP backends only so long as both are entirely separate from each other.
	</para></note>

      <para>It is assumed that the network you are working with follows in a
	pattern similar to what has been covered in Chapter 6. The following steps
        permit the operation of a Master/Slave OpenLDAP arrangement.</para>

	<procedure>

		<step><para>
	    <indexterm>
	      <primary>SUSE Linux</primary>
	    </indexterm><indexterm>
	      <primary>Red Hat Linux</primary>
	    </indexterm>
		Log onto the master LDAP server as <constant>root</constant>.
		You are about to change the configuration of the LDAP server, so it
		makes sense to temporarily halt it. Stop OpenLDAP from running on 
		SUSE Linux by executing:
<screen>
&rootprompt; rcldap stop
</screen>
		On Red Hat Linux, you can do this by executing:
<screen>
&rootprompt; service ldap stop
</screen>
		</para></step>

	<step><para><indexterm>
	      <primary>/etc/openldap/slapd.conf</primary>
	    </indexterm>
		Edit the <filename>/etc/openldap/slapd.conf</filename> file so it
		matches the content of <link linkend="ch7-LDAP-master"/>.
		</para></step>

	<step><para>
		Create a file called <filename>admin-accts.ldif</filename> with the following contents:
<screen>
dn: cn=updateuser,dc=abmas,dc=biz
objectClass: person
cn: updateuser
sn: updateuser
userPassword: not24get

dn: cn=sambaadmin,dc=abmas,dc=biz
objectClass: person
cn: sambaadmin
sn: sambaadmin
userPassword: buttercup
</screen>
	</para></step>

	<step><para>
		Add an account called <quote>updateuser</quote> to the master LDAP server
		as shown here:
<screen>
&rootprompt; slapadd -v -l admin-accts.ldif
</screen>
	</para></step>

	<step><para><indexterm>
	      <primary>LDIF</primary>
	    </indexterm><indexterm>
	      <primary>LDAP</primary>
	      <secondary>preload</secondary>
	    </indexterm>
		Change directory to a suitable place to dump the contents of the
		LDAP server. The dump file (and LDIF file) is used to preload
		the Slave LDAP server database. You can dump the database by executing:
<screen>
&rootprompt; slapcat -v -l LDAP-transfer-LDIF.txt
</screen>
		Each record is written to the file.	
		</para></step>

	<step><para><indexterm>
	      <primary>LDAP-transfer-LDIF.txt</primary>
	    </indexterm>
		Copy the file <filename>LDAP-transfer-LDIF.txt</filename> to the intended
		slave LDAP server. A good location could be in the directory 
		<filename>/etc/openldap/preload</filename>.
		</para></step>

		<step><para>
		Log onto the slave LDAP server as <constant>root</constant>. You can
		now configure this server so the <filename>/etc/openldap/slapd.conf</filename>
		file matches the content of <link linkend="ch7-LDAP-slave"/>.
		</para></step>

		<step><para>
		Change directory to the location in which you stored the 
		<filename>LDAP-transfer-LDIF.txt</filename> file (<filename>/etc/openldap/preload</filename>).
		While in this directory, execute:
<screen>
&rootprompt; slapadd -v -l LDAP-transfer-LDIF.txt
</screen>
		If all goes well, the following output confirms that the data is being loaded
		as intended:
<screen>
added: "dc=abmas,dc=biz" (00000001)
added: "cn=sambaadmin,dc=abmas,dc=biz" (00000002)
added: "cn=updateuser,dc=abmas,dc=biz" (00000003)
added: "ou=People,dc=abmas,dc=biz" (00000004)
added: "ou=Groups,dc=abmas,dc=biz" (00000005)
added: "ou=Computers,dc=abmas,dc=biz" (00000006)
added: "uid=Administrator,ou=People,dc=abmas,dc=biz" (00000007)
added: "uid=nobody,ou=People,dc=abmas,dc=biz" (00000008)
added: "cn=Domain Admins,ou=Groups,dc=abmas,dc=biz" (00000009)
added: "cn=Domain Users,ou=Groups,dc=abmas,dc=biz" (0000000a)
added: "cn=Domain Guests,ou=Groups,dc=abmas,dc=biz" (0000000b)
added: "uid=bobj,ou=People,dc=abmas,dc=biz" (0000000c)
added: "sambaDomainName=MEGANET2,dc=abmas,dc=biz" (0000000d)
added: "uid=stans,ou=People,dc=abmas,dc=biz" (0000000e)
added: "uid=chrisr,ou=People,dc=abmas,dc=biz" (0000000f)
added: "uid=maryv,ou=People,dc=abmas,dc=biz" (00000010)
added: "cn=Accounts,ou=Groups,dc=abmas,dc=biz" (00000011)
added: "cn=Finances,ou=Groups,dc=abmas,dc=biz" (00000012)
added: "cn=PIOps,ou=Groups,dc=abmas,dc=biz" (00000013)
</screen>
		</para></step>

		<step><para>
		Now start the LDAP server and set it to run automatically on system reboot
		by executing:
<screen>
&rootprompt; rcldap start
&rootprompt; chkconfig ldap on
</screen>
		On Red Hat Linux, you would execute the following:
<screen>
&rootprompt; service ldap start
&rootprompt; chkconfig ldap on
</screen>
	    <indexterm>
	      <primary>chkconfig</primary>
	    </indexterm><indexterm>
	      <primary>service</primary>
	    </indexterm><indexterm>
	      <primary>rcldap</primary>
	    </indexterm>
		</para></step>

		<step><para>
		Go back to the master LDAP server. Execute the following to start LDAP as well
		as <command>slurpd</command>, the synchronization daemon, as shown here:
<screen>
&rootprompt; rcldap start
&rootprompt; chkconfig ldap on
&rootprompt; rcslurpd start
&rootprompt; chkconfig slurpd on
</screen>
	    <indexterm>
	      <primary>slurpd</primary>
	    </indexterm>
		On Red Hat Linux, check the equivalent command to start <command>slurpd</command>.
		</para></step>

	<step><para><indexterm>
	      <primary>smbldap-useradd</primary>
	    </indexterm>
		On the master ldap server you may now add an account to validate that replication
		is working. Assuming the configuration shown in Chapter 6, execute:
<screen>
&rootprompt; /var/lib/samba/sbin/smbldap-useradd -a fruitloop
</screen>
		</para></step>

		<step><para>
		On the slave LDAP server, change to the directory <filename>/var/lib/ldap</filename>.
		There should now be a file called <filename>replogfile</filename>. If replication worked
		as expected, the content of this file should be:
<screen>
time: 1072486403
dn: uid=fruitloop,ou=People,dc=abmas,dc=biz
changetype: modify
replace: sambaProfilePath
sambaProfilePath: \\MASSIVE\profiles\fruitloop
-
replace: sambaHomePath
sambaHomePath: \\MASSIVE\homes
-
replace: entryCSN
entryCSN: 2003122700:43:38Z#0x0005#0#0000
-
replace: modifiersName
modifiersName: cn=Manager,dc=abmas,dc=biz
-
replace: modifyTimestamp
modifyTimestamp: 20031227004338Z
-
</screen>
		</para></step>

		<step><para>
		Given that this first slave LDAP server is now working correctly, you may now
		implement additional slave LDAP servers as required.
		</para></step>

	</procedure>

<example id="ch7-LDAP-master">
<title>LDAP Master Server Configuration File &smbmdash; <filename>/etc/openldap/slapd.conf</filename></title>
<screen>
include     /etc/openldap/schema/core.schema
include     /etc/openldap/schema/cosine.schema
include     /etc/openldap/schema/inetorgperson.schema
include     /etc/openldap/schema/nis.schema
include     /etc/openldap/schema/samba.schema

pidfile     /var/run/slapd/slapd.pid
argsfile    /var/run/slapd/slapd.args

database    bdb
suffix      "dc=abmas,dc=biz"
rootdn      "cn=Manager,dc=abmas,dc=biz"

# rootpw = not24get
rootpw      {SSHA}86kTavd9Dw3FAz6qzWTrCOKX/c0Qe+UV

replica     host=lapdc.abmas.biz:389
            suffix="dc=abmas,dc=biz"
            binddn="cn=updateuser,dc=abmas,dc=biz"
            bindmethod=simple credentials=not24get

access to attrs=sambaLMPassword,sambaNTPassword
           by dn="cn=updateuser,dc=abmas,dc=biz" write
           by * none

replogfile  /var/lib/ldap/replogfile

directory   /var/lib/ldap

# Indices to maintain
index objectClass           eq
index cn                    pres,sub,eq
index sn                    pres,sub,eq
index uid                   pres,sub,eq
index displayName           pres,sub,eq
index uidNumber             eq
index gidNumber             eq
index memberUID             eq
index sambaSID              eq
index sambaPrimaryGroupSID  eq
index sambaDomainName       eq
index default               sub
</screen>
</example>

<example id="ch7-LDAP-slave">
<title>LDAP Slave Configuration File &smbmdash; <filename>/etc/openldap/slapd.conf</filename></title>
<screen>
include     /etc/openldap/schema/core.schema
include     /etc/openldap/schema/cosine.schema
include     /etc/openldap/schema/inetorgperson.schema
include     /etc/openldap/schema/nis.schema
include     /etc/openldap/schema/samba.schema

pidfile     /var/run/slapd/slapd.pid
argsfile    /var/run/slapd/slapd.args

database    bdb
suffix      "dc=abmas,dc=biz"
rootdn      "cn=Manager,dc=abmas,dc=biz"

# rootpw = not24get
rootpw      {SSHA}86kTavd9Dw3FAz6qzWTrCOKX/c0Qe+UV

access to *
            by dn=cn=updateuser,dc=abmas,dc=biz write
            by * read

updatedn    cn=updateuser,dc=abmas,dc=biz
updateref   ldap://massive.abmas.biz

directory   /var/lib/ldap

# Indices to maintain
index objectClass           eq
index cn                    pres,sub,eq
index sn                    pres,sub,eq
index uid                   pres,sub,eq
index displayName           pres,sub,eq
index uidNumber             eq
index gidNumber             eq
index memberUID             eq
index sambaSID              eq
index sambaPrimaryGroupSID  eq
index sambaDomainName       eq
index default               sub
</screen>
</example>

<smbconfexample id="ch7-massmbconfA">
<title>Primary Domain Controller &smb.conf; File &smbmdash; Part A</title>
<smbconfcomment>Global parameters</smbconfcomment>
<smbconfsection name="[global]"/>
<smbconfoption name="unix charset">LOCALE</smbconfoption>
<smbconfoption name="workgroup">MEGANET2</smbconfoption>
<smbconfoption name="passdb backend">ldapsam:ldap://massive.abmas.biz</smbconfoption>
<smbconfoption name="username map">/etc/samba/smbusers</smbconfoption>
<smbconfoption name="log level">1</smbconfoption>
<smbconfoption name="syslog">0</smbconfoption>
<smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
<smbconfoption name="max log size">0</smbconfoption>
<smbconfoption name="smb ports">139 445</smbconfoption>
<smbconfoption name="name resolve order">wins bcast hosts</smbconfoption>
<smbconfoption name="time server">Yes</smbconfoption>
<smbconfoption name="printcap name">CUPS</smbconfoption>
<smbconfoption name="add user script">/opt/IDEALX/sbin/smbldap-useradd -m '%u'</smbconfoption>
<smbconfoption name="delete user script">/opt/IDEALX/sbin/smbldap-userdel '%u'</smbconfoption>
<smbconfoption name="add group script">/opt/IDEALX/sbin/smbldap-groupadd -p '%g'</smbconfoption>
<smbconfoption name="delete group script">/opt/IDEALX/sbin/smbldap-groupdel '%g'</smbconfoption>
<smbconfoption name="add user to group script">/opt/IDEALX/sbin/</smbconfoption>
<member><parameter>smbldap-groupmod -m '%g' '%u'</parameter></member>
<smbconfoption name="delete user from group script">/opt/IDEALX/sbin/</smbconfoption>
<member><parameter>smbldap-groupmod -x '%g' '%u'</parameter></member>
<smbconfoption name="set primary group script">/opt/IDEALX/sbin/</smbconfoption>
<member><parameter>smbldap-usermod -g '%g' '%u'</parameter></member>
<smbconfoption name="add machine script">/opt/IDEALX/sbin/</smbconfoption>
<member><parameter>smbldap-useradd -w '%u'</parameter></member>
<smbconfoption name="shutdown script">/var/lib/samba/scripts/shutdown.sh</smbconfoption>
<smbconfoption name="abort shutdown script">/sbin/shutdown -c</smbconfoption>
<smbconfoption name="logon script">scripts\logon.bat</smbconfoption>
<smbconfoption name="logon path">\\%L\profiles\%U</smbconfoption>
<smbconfoption name="logon drive">X:</smbconfoption>
<smbconfoption name="domain logons">Yes</smbconfoption>
<smbconfoption name="domain master">Yes</smbconfoption>
<smbconfoption name="wins support">Yes</smbconfoption>
<smbconfoption name="ldap suffix">dc=abmas,dc=biz</smbconfoption>
<smbconfoption name="ldap machine suffix">ou=People</smbconfoption>
<smbconfoption name="ldap user suffix">ou=People</smbconfoption>
<smbconfoption name="ldap group suffix">ou=Groups</smbconfoption>
<smbconfoption name="ldap idmap suffix">ou=Idmap</smbconfoption>
<smbconfoption name="ldap admin dn">cn=Manager,dc=abmas,dc=biz</smbconfoption>
<smbconfoption name="idmap backend">ldap://massive.abmas.biz</smbconfoption>
<smbconfoption name="idmap uid">10000-20000</smbconfoption>
<smbconfoption name="idmap gid">10000-20000</smbconfoption>
<smbconfoption name="printer admin">root</smbconfoption>
<smbconfoption name="printing">cups</smbconfoption>
</smbconfexample>

<smbconfexample id="ch7-massmbconfB">
<title>Primary Domain Controller &smb.conf; File &smbmdash; Part B</title>
<smbconfsection name="[IPC$]"/>
<smbconfoption name="path">/tmp</smbconfoption>

<smbconfsection name="[accounts]"/>
<smbconfoption name="comment">Accounting Files</smbconfoption>
<smbconfoption name="path">/data/accounts</smbconfoption>
<smbconfoption name="read only">No</smbconfoption>

<smbconfsection name="[service]"/>
<smbconfoption name="comment">Financial Services Files</smbconfoption>
<smbconfoption name="path">/data/service</smbconfoption>
<smbconfoption name="read only">No</smbconfoption>

<smbconfsection name="[pidata]"/>
<smbconfoption name="comment">Property Insurance Files</smbconfoption>
<smbconfoption name="path">/data/pidata</smbconfoption>
<smbconfoption name="read only">No</smbconfoption>

<smbconfsection name="[homes]"/>
<smbconfoption name="comment">Home Directories</smbconfoption>
<smbconfoption name="valid users">%S</smbconfoption>
<smbconfoption name="read only">No</smbconfoption>
<smbconfoption name="browseable">No</smbconfoption>

<smbconfsection name="[printers]"/>
<smbconfoption name="comment">SMB Print Spool</smbconfoption>
<smbconfoption name="path">/var/spool/samba</smbconfoption>
<smbconfoption name="guest ok">Yes</smbconfoption>
<smbconfoption name="printable">Yes</smbconfoption>
<smbconfoption name="browseable">No</smbconfoption>
</smbconfexample>

<smbconfexample id="ch7-massmbconfC">
<title>Primary Domain Controller &smb.conf; File &smbmdash; Part C</title>
<smbconfsection name="[apps]"/>
<smbconfoption name="comment">Application Files</smbconfoption>
<smbconfoption name="path">/apps</smbconfoption>
<smbconfoption name="admin users">bjones</smbconfoption>
<smbconfoption name="read only">No</smbconfoption>

<smbconfsection name="[netlogon]"/>
<smbconfoption name="comment">Network Logon Service</smbconfoption>
<smbconfoption name="path">/var/lib/samba/netlogon</smbconfoption>
<smbconfoption name="admin users">root, Administrator</smbconfoption>
<smbconfoption name="guest ok">Yes</smbconfoption>
<smbconfoption name="locking">No</smbconfoption>

<smbconfsection name="[profiles]"/>
<smbconfoption name="comment">Profile Share</smbconfoption>
<smbconfoption name="path">/var/lib/samba/profiles</smbconfoption>
<smbconfoption name="read only">No</smbconfoption>
<smbconfoption name="profile acls">Yes</smbconfoption>

<smbconfsection name="[profdata]"/>
<smbconfoption name="comment">Profile Data Share</smbconfoption>
<smbconfoption name="path">/var/lib/samba/profdata</smbconfoption>
<smbconfoption name="read only">No</smbconfoption>
<smbconfoption name="profile acls">Yes</smbconfoption>

<smbconfsection name="[print$]"/>
<smbconfoption name="comment">Printer Drivers</smbconfoption>
<smbconfoption name="path">/var/lib/samba/drivers</smbconfoption>
<smbconfoption name="write list">root</smbconfoption>
<smbconfoption name="admin users">root, Administrator</smbconfoption>
</smbconfexample>

<smbconfexample id="ch7-slvsmbocnfA">
<title>Backup Domain Controller &smb.conf; File &smbmdash; Part A</title>
<smbconfcomment># Global parameters</smbconfcomment>
<smbconfsection name="[global]"/>
<smbconfoption name="unix charset">LOCALE</smbconfoption>
<smbconfoption name="workgroup">MEGANET2</smbconfoption>
<smbconfoption name="netbios name">BLDG1</smbconfoption>
<smbconfoption name="passdb backend">ldapsam:ldap://lapdc.abmas.biz</smbconfoption>
<smbconfoption name="username map">/etc/samba/smbusers</smbconfoption>
<smbconfoption name="log level">1</smbconfoption>
<smbconfoption name="syslog">0</smbconfoption>
<smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
<smbconfoption name="max log size">50</smbconfoption>
<smbconfoption name="smb ports">139 445</smbconfoption>
<smbconfoption name="name resolve order">wins bcast hosts</smbconfoption>
<smbconfoption name="printcap name">CUPS</smbconfoption>
<smbconfoption name="show add printer wizard">No</smbconfoption>
<smbconfoption name="logon script">scripts\logon.bat</smbconfoption>
<smbconfoption name="logon path">\\%L\profiles\%U</smbconfoption>
<smbconfoption name="logon drive">X:</smbconfoption>
<smbconfoption name="domain logons">Yes</smbconfoption>
<smbconfoption name="os level">63</smbconfoption>
<smbconfoption name="domain master">No</smbconfoption>
<smbconfoption name="wins server">192.168.2.1</smbconfoption>
<smbconfoption name="ldap suffix">dc=abmas,dc=biz</smbconfoption>
<smbconfoption name="ldap machine suffix">ou=People</smbconfoption>
<smbconfoption name="ldap user suffix">ou=People</smbconfoption>
<smbconfoption name="ldap group suffix">ou=Groups</smbconfoption>
<smbconfoption name="ldap idmap suffix">ou=Idmap</smbconfoption>
<smbconfoption name="ldap admin dn">cn=Manager,dc=abmas,dc=biz</smbconfoption>
<smbconfoption name="utmp">Yes</smbconfoption>
<smbconfoption name="idmap backend">ldap://massive.abmas.biz</smbconfoption>
<smbconfoption name="idmap uid">10000-20000</smbconfoption>
<smbconfoption name="idmap gid">10000-20000</smbconfoption>
<smbconfoption name="printing">cups</smbconfoption>

<smbconfsection name="[accounts]"/>
<smbconfoption name="comment">Accounting Files</smbconfoption>
<smbconfoption name="path">/data/accounts</smbconfoption>
<smbconfoption name="read only">No</smbconfoption>

<smbconfsection name="[service]"/>
<smbconfoption name="comment">Financial Services Files</smbconfoption>
<smbconfoption name="path">/data/service</smbconfoption>
<smbconfoption name="read only">No</smbconfoption>
</smbconfexample>

<smbconfexample id="ch7-slvsmbocnfB">
<title>Backup Domain Controller &smb.conf; File &smbmdash; Part B</title>
<smbconfsection name="[pidata]"/>
<smbconfoption name="comment">Property Insurance Files</smbconfoption>
<smbconfoption name="path">/data/pidata</smbconfoption>
<smbconfoption name="read only">No</smbconfoption>

<smbconfsection name="[homes]"/>
<smbconfoption name="comment">Home Directories</smbconfoption>
<smbconfoption name="valid users">%S</smbconfoption>
<smbconfoption name="read only">No</smbconfoption>
<smbconfoption name="browseable">No</smbconfoption>

<smbconfsection name="[printers]"/>
<smbconfoption name="comment">SMB Print Spool</smbconfoption>
<smbconfoption name="path">/var/spool/samba</smbconfoption>
<smbconfoption name="guest ok">Yes</smbconfoption>
<smbconfoption name="printable">Yes</smbconfoption>
<smbconfoption name="browseable">No</smbconfoption>

<smbconfsection name="[apps]"/>
<smbconfoption name="comment">Application Files</smbconfoption>
<smbconfoption name="path">/apps</smbconfoption>
<smbconfoption name="admin users">bjones</smbconfoption>
<smbconfoption name="read only">No</smbconfoption>

<smbconfsection name="[netlogon]"/>
<smbconfoption name="comment">Network Logon Service</smbconfoption>
<smbconfoption name="path">/var/lib/samba/netlogon</smbconfoption>
<smbconfoption name="guest ok">Yes</smbconfoption>
<smbconfoption name="locking">No</smbconfoption>

<smbconfsection name="[profiles]"/>
<smbconfoption name="comment">Profile Share</smbconfoption>
<smbconfoption name="path">/var/lib/samba/profiles</smbconfoption>
<smbconfoption name="read only">No</smbconfoption>
<smbconfoption name="profile acls">Yes</smbconfoption>

<smbconfsection name="[profdata]"/>
<smbconfoption name="comment">Profile Data Share</smbconfoption>
<smbconfoption name="path">/var/lib/samba/profdata</smbconfoption>
<smbconfoption name="read only">No</smbconfoption>
<smbconfoption name="profile acls">Yes</smbconfoption>
</smbconfexample>

	<sect2>
		<title>Key Points Learned</title>

		<para>
		</para>

		<itemizedlist>
	  <listitem><para><indexterm>
		<primary>LDAP</primary>
	      </indexterm><indexterm>
		<primary>BDC</primary>
	      </indexterm>
			Where Samba-3 is used as a Domain Controller, the use of LDAP is an 
			essential component necessary to permit the use of BDCs.
			</para></listitem>

	  <listitem><para><indexterm>
		<primary>wide-area</primary>
	      </indexterm>
			Replication of the LDAP master server to create a network of BDCs
			is an important mechanism for limiting wide-area network traffic.
			</para></listitem>

			<listitem><para>
			Network administration presents many complex challenges, most of which
			can be satisfied by good design, but that also require sound communication
			and unification of management practices. This can be highly challenging in
			a large, globally distributed network.
			</para></listitem>

			<listitem><para>
			Roaming profiles must be contained to the local network segment. Any
			departure from this may clog wide-area arteries and slow legitimate network
			traffic to a crawl.
			</para></listitem>
		</itemizedlist>

	</sect2>

</sect1>

<sect1>
	<title>Questions and Answers</title>

	<para>
	There is much rumor and misinformation regarding the use of MS Windows networking protocols.
	These questions are just a few of those frequently asked.
	</para>

	<qandaset defaultlabel="chap07qa">
	<qandaentry>
	<question>

	    <para><indexterm>
		<primary>DHCP</primary>
	      </indexterm><indexterm>
		<primary>network</primary>
		<secondary>bandwidth</secondary>
	      </indexterm>
		Is it true that DHCP uses lots of wide-area network bandwidth?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>DHCP</primary>
		<secondary>Relay Agent</secondary>
	      </indexterm><indexterm>
		<primary>routers</primary>
	      </indexterm><indexterm>
		<primary>DHCP</primary>
		<secondary>servers</secondary>
	      </indexterm>
		It is a smart practice to localize DHCP servers on each network segment. As a 
		rule, there should be two DHCP servers per network segment. This means that if
		one server fails, there is always another to service user needs. DHCP requests use
		only UDP broadcast protocols. It is possible to run a DHCP Relay Agent on network
		routers. This makes it possible to run fewer DHCP servers.
		</para>

	    <para><indexterm>
		<primary>DHCP</primary>
		<secondary>request</secondary>
	      </indexterm><indexterm>
		<primary>DHCP</primary>
		<secondary>traffic</secondary>
	      </indexterm>
		A DHCP network address request and confirmation usually results in about six UDP packets.
		The packets are from 60 to 568 bytes in length. Let us consider a site that has 300 DHCP
		clients and that uses a 24-hour IP address lease. This means that all clients renew
		their IP address lease every 24 hours. If we assume an average packet length equal to the
		maximum (just to be on the safe side), and we have a 128 Kbit/sec wide-area connection, 
		how significant would the DHCP traffic be if all of it were to use DHCP Relay?
		</para>

		<para>
		I must stress that this is a bad design, but here is the calculation:
<screen>
Daily Network Capacity: 128,000 (Kbits/s) / 8 (bits/byte) 
                             x 3600 (sec/hr) x 24 (hrs/day)= 2288 Mbytes/day.

DHCP traffic:          300 (clients) x 6 (packets) 
                                       x 512 (bytes/packet) = 0.9 Mbytes/day.
</screen>
		From this can be seen that the traffic impact would be minimal.
		</para>

	    <para><indexterm>
		<primary>DNS</primary>
		<secondary>Dynamic</secondary>
	      </indexterm><indexterm>
		<primary>DHCP</primary>
	      </indexterm>
		Even when DHCP is configured to do DNS update (Dynamic DNS) over a wide-area link,
		the impact of the update is no more than the DHCP IP address renewal traffic and, thus,
		still insignificant for most practical purposes.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

	    <para><indexterm>
		<primary>background communication</primary>
	      </indexterm><indexterm>
		<primary>LDAP</primary>
		<secondary>master/slave</secondary>
		<tertiary>background communication</tertiary>
	      </indexterm>
		How much background communication takes place between a Master LDAP 
		server and its slave LDAP servers?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>slurpd</primary>
	      </indexterm>
		The process that controls the replication of data from the Master LDAP server to the Slave LDAP
		servers is called <command>slurpd</command>. The <command>slurpd</command> remains nascent (quiet)
		until an update must be propagated. The propagation traffic per LDAP salve to update (add/modify/delete)
		two user accounts requires less than 10Kbytes traffic.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

		<para>
		LDAP has a database. Is LDAP not just a fancy database front end?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>database</primary>
	      </indexterm><indexterm>
		<primary>LDAP</primary>
		<secondary>database</secondary>
	      </indexterm><indexterm>
		<primary>SQL</primary>
	      </indexterm><indexterm>
		<primary>transactional</primary>
	      </indexterm>
		LDAP does store its data in a database of sorts. In fact the LDAP backend is an application-specific
		data storage system. This type of database is indexed so that records can be rapidly located, but the
		database is not generic and can be used only in particular pre-programmed ways. General external
		applications do not gain access to the data. This type of database is used also by SQL servers. Both
		an SQL server and an LDAP server provide ways to access the data. An SQL server has a transactional
		orientation and typically allows external programs to perform ad-hoc queries, even across data tables.
		An LDAP front end is a purpose-built tool that has a search orientation that is designed around specific
		simple queries. The term <constant>database</constant> is heavily overloaded and, thus, much misunderstood.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

	    <para><indexterm>
		<primary>OpenLDAP</primary>
	      </indexterm>
		Can Active Directory obtain account information from an OpenLDAP server?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>meta-directory</primary>
	      </indexterm>
		No, at least not directly. It is possible to provision Active Directory from/to an OpenLDAP
		database through use of a meta-directory server. Microsoft MMS (now called MIIS) can interface
		to OpenLDAP using standard LDAP queries/updates. 
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

		<para>
		What are the parts of a roaming profile? How large is each part?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>roaming profile</primary>
	      </indexterm>
		A roaming profile consists of:
		</para>

		<itemizedlist>
			<listitem><para>
			Desktop folders such as: <constant>Desktop, My Documents, My Pictures, My Music, Internet Files,
			Cookies, Application Data, Local Settings,</constant> and more. See <link linkend="XP-screen001"/>.
			</para>

		<para><indexterm>
		    <primary>folder redirection</primary>
		  </indexterm>
			Each of these can be anywhere from a few bytes to gigabytes in capacity. Fortunately, all
			such folders can be redirected to network drive resources. See <link linkend="redirfold"/>
			for more information regarding folder redirection.
			</para></listitem>

			<listitem><para>
			A static or re-writable portion that is typically only a few files (2-5 Kbytes of information).
			</para></listitem>

	      <listitem><para><indexterm>
		    <primary>NTUSER.DAT</primary>
		  </indexterm><indexterm>
		    <primary>HKEY_LOCAL_USER</primary>
		  </indexterm>
			The registry load file that modifies the <constant>HKEY_LOCAL_USER</constant> hive. This is
			the <filename>NTUSER.DAT</filename> file. It can be from 0.4-1.5 MBytes.
			</para></listitem>
		</itemizedlist>

	    <para><indexterm>
		<primary>Microsoft Outlook</primary>
		<secondary>PST files</secondary>
	      </indexterm>
		Microsoft Outlook PST files may be stored in the <constant>Local Settings\Application Data</constant>
		folder. It can be up to 2 Gbytes in size per PST file.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

		<para>
		Can the <constant>My Documents</constant> folder be stored on a network drive?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>UNC name</primary>
	      </indexterm><indexterm>
		<primary>Universal Naming Convention</primary>
		<see>UNC name</see>
	      </indexterm>
		Yes. More correctly, such folders can be redirected to network shares. No specific network drive
		connection is required. Registry settings permit this to be redirected directly to a UNC (Universal
		Naming Convention) resource, though it is possible to specify a network drive letter instead of a
		UNC name. See <link linkend="redirfold"/>.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

	    <para><indexterm>
		<primary>wide-area</primary>
	      </indexterm><indexterm>
		<primary>network</primary>
		<secondary>bandwidth</secondary>
	      </indexterm><indexterm>
		<primary>WINS</primary>
	      </indexterm>
		How much wide-area network bandwidth does WINS consume?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>NetBIOS</primary>
		<secondary>name cache</secondary>
	      </indexterm><indexterm>
		<primary>WINS server</primary>
	      </indexterm><indexterm>
		<primary>domain replication</primary>
	      </indexterm>
		MS Windows clients cache information obtained from WINS lookups in a local NetBIOS name cache.
		This keeps WINS lookups to a minimum. On a network with 3500 MS Windows clients and a central WINS
		server, the total bandwidth demand measured at the WINS server, averaged over an eight-hour working day,
		was less than 30 Kbytes/sec. Analysis of network traffic over a six-week period showed that the total
		of all background traffic consumed about 11 percent of available bandwidth over 64 Kbit/sec links.
		Back-ground traffic consisted of domain replication, WINS queries, DNS lookups, authentication
		traffic. Each of 11 branch offices had a 64 Kbit/sec wide-area link, with a 1.5 Mbit/sec main connection
		that aggregated the branch office connections plus an Internet connection.
		</para>

		<para>
		In conclusion, the total load afforded through WINS traffic is again marginal to total operational
		usage &smbmdash; as it should be.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

		<para>
		How many BDCs should I have? What is the right number of Windows clients per server?
		</para>

	</question>
	<answer>

		<para>
		It is recommended to have at least one BDC per network segment, including the segment served
		by the PDC. Actual requirements vary depending on the working load on each of the BDCs and the
		load demand pattern of client usage. I have seen sites that function without problem with 200
		clients served by one BDC, and yet other sites that had one BDC per 20 clients. In one particular
		company, there was a drafting office that has 30 CAD/CAM operators served by one server, a print
		server; and an application server. While all three were BDCs, typically only the print server would
		service network logon requests after the first 10 users had started to use the network. This was
		a reflection of the service load placed on both the application server and the data server.
		</para>

		<para>
		As unsatisfactory as the answer might sound, it all depends on network and server load
		characteristics.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

	    <para><indexterm>
		<primary>NIS server</primary>
	      </indexterm><indexterm>
		<primary>LDAP</primary>
	      </indexterm>
		I've heard that you can store NIS accounts in LDAP. Is LDAP not just a smarter way to
		run an NIS server?
		</para>

	</question>
	<answer>

		<para>
		The correct answer to both questions is yes. But do understand that an LDAP server has
		a configurable schema that can store far more information for many more purposes than
		just NIS.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

		<para>
		Can I use NIS in place of LDAP?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>NIS</primary>
	      </indexterm><indexterm>
		<primary>NIS schema</primary>
	      </indexterm>
		No. The NIS database does not have provision to store Microsoft encrypted passwords and does not deal
		with the types of data necessary for interoperability with Microsoft Windows networking. The use
		of LDAP with Samba requires the use of a number of schemas, one of which is the NIS schema, but also
		a Samba-specific schema extension.
		</para>

	</answer>
	</qandaentry>

	</qandaset>

</sect1>

</chapter>