diff options
Diffstat (limited to 'docs/Samba-Guide/SBE-2000UserNetwork.xml')
| -rw-r--r-- | docs/Samba-Guide/SBE-2000UserNetwork.xml | 1772 |
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> + |