summaryrefslogtreecommitdiff
path: root/docs/Samba-Guide/SBE-2000UserNetwork.xml
diff options
context:
space:
mode:
authorJohn Terpstra <jht@samba.org>2005-04-13 02:26:17 +0000
committerGerald W. Carter <jerry@samba.org>2008-04-23 08:46:25 -0500
commit6262d3083458e4fc1dfcff77e616063e4b71e477 (patch)
treeddfea67e7c0c679d69a0fea331795971cc42e58a /docs/Samba-Guide/SBE-2000UserNetwork.xml
parent2b7907805aeb32775f11795b88e01721b115eafe (diff)
downloadsamba-6262d3083458e4fc1dfcff77e616063e4b71e477.tar.gz
samba-6262d3083458e4fc1dfcff77e616063e4b71e477.tar.bz2
samba-6262d3083458e4fc1dfcff77e616063e4b71e477.zip
Begin of another reorg.
(This used to be commit 131d76df85ab12f5a171120113d4dfa7ad3f2220)
Diffstat (limited to 'docs/Samba-Guide/SBE-2000UserNetwork.xml')
-rw-r--r--docs/Samba-Guide/SBE-2000UserNetwork.xml1772
1 files changed, 1772 insertions, 0 deletions
diff --git a/docs/Samba-Guide/SBE-2000UserNetwork.xml b/docs/Samba-Guide/SBE-2000UserNetwork.xml
new file mode 100644
index 0000000000..870a060549
--- /dev/null
+++ b/docs/Samba-Guide/SBE-2000UserNetwork.xml
@@ -0,0 +1,1772 @@
+<?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.12 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>
+