docs/faq/Samba-meta-FAQ-4.html

   1 <HTML>
   2 <HEAD>
   3 <TITLE> Samba meta FAQ: Designing A SMB and CIFS Network</TITLE>
   4 </HEAD>
   5 <BODY>
   6 <A HREF="Samba-meta-FAQ-3.html">Previous</A>
   7 <A HREF="Samba-meta-FAQ-5.html">Next</A>
   8 <A HREF="Samba-meta-FAQ.html#toc4">Table of Contents</A>
   9 <HR>
  10 <H2><A NAME="s4">4. Designing A SMB and CIFS Network</A></H2>
  11
  12
  13 <P>The big issues for installing any network of LAN or WAN file and print
  14 servers are </P>
  15 <P>
  16 <UL>
  17 <LI>How and where usernames, passwords and other security information
  18 is stored
  19 </LI>
  20 <LI>What method can be used for locating the resources that users have
  21 permission to use
  22 </LI>
  23 <LI>What protocols the clients can converse with
  24 </LI>
  25 </UL>
  26  </P>
  27 <P>If you buy Netware, Windows NT or just about any other LAN fileserver
  28 product you are expected to lock yourself into the product's preferred
  29 answers to these questions. This tendancy is restrictive and often very
  30 expensive for a site where there is only one kind of client or server,
  31 and for sites with a mixture of operating systems it often makes it
  32 impossible to share resources between some sets of users.</P>
  33 <P>The Samba philosophy is to make things as easy as possible for
  34 administators, which means allowing as many combinations of clients,
  35 servers, operating systems and protocols as possible.</P>
  36
  37 <H2><A NAME="ss4.1">4.1 Workgroups, Domains, Authentication and Browsing</A></H2>
  38
  39
  40 <P>From the point of view of networking implementation, Domains and
  41 Workgroups are <EM>exactly</EM> the same, except for the client logon
  42 sequence. Some kind of distributed authentication database is associated
  43 with a domain (there are quite a few choices) and this adds so much
  44 flexibility that many people think of a domain as a completely different
  45 entity to a workgroup. From Samba's point of view a client connecting to
  46 a service presents an authentication token, and it if it is valid they
  47 have access. Samba does not care what mechanism was used to generate
  48 that token in the first place.</P>
  49 <P>The SMB client logging on to a domain has an expectation that every other
  50 server in the domain should accept the same authentication information.
  51 However the network browsing functionality of domains and workgroups is
  52 identical and is explained in
  53 <A HREF="../BROWSING.txt">../BROWSING.txt</A>.</P>
  54 <P>There are some implementation differences: Windows 95 can be a member of
  55 both a workgroup and a domain, but Windows NT cannot. Windows 95 also
  56 has the concept of an "alternative workgroup". Samba can only be a
  57 member of a single workgroup or domain, although this is due to change
  58 with a future version when nmbd will be split into two daemons, one for
  59 WINS and the other for browsing (
  60 <A HREF="../NetBIOS.txt">../NetBIOS.txt</A> explains
  61 what WINS is.)</P>
  62
  63 <H3>Defining the Terms</H3>
  64
  65 <P>
  66 <A NAME="BrowseAndDomainDefs"></A>
  67 </P>
  68 <P>
  69 <DL>
  70
  71 <DT><B>Workgroup</B><DD><P>means a collection of machines that maintain a common
  72 browsing database containing information about their shared resources.
  73 They do not necessarily have any security information in common (if they
  74 do, it gets called a Domain.) The browsing database is dynamic, modified
  75 as servers come and go on the network and as resources are added or
  76 deleted. The term "browsing" refers to a user accessing the database via
  77 whatever interface the client provides, eg the OS/2 Workplace Shell or
  78 Windows 95 Explorer. SMB servers agree between themselves as to which
  79 ones will maintain the browsing database. Workgroups can be anywhere on
  80 a connected TCP/IP network, including on different subnets or even on
  81 the Interet. This is a very tricky part of SMB to implement.</P>
  82
  83 <DT><B>Master Browsers</B><DD><P>are machines which holds the master browsing
  84 database for a workgroup or domain. There are two kinds of Master Browser:</P>
  85 <P>
  86 <UL>
  87 <LI> Domain Master Browser, which holds the master browsing
  88 information for an entire domain, which may well cross multiple TCP/IP
  89 subnets.
  90 </LI>
  91 <LI> Local Master Browser, which holds the master browsing database
  92 for a particular subnet and communicates with the Domain Master Browser
  93 to get information on other subnets.
  94 </LI>
  95 </UL>
  96 </P>
  97 <P>Subnets are differentiated because browsing is based on broadcasts, and
  98 broadcasts do not pass through routers. Subnets are not routed: while it
  99 is possible to have more than one subnet on a single network segment
 100 this is regarded as very bad practice.</P>
 101 <P>Master Browsers (both Domain and Local) are elected dynamically
 102 according to an algorithm which is supposed to take into account the
 103 machine's ability to sustain the browsing load. Samba can be configured
 104 to always act as a master browser, ie it always wins elections under all
 105 circumstances, even against systems such as a Windows NT Primary Domain
 106 Controller which themselves expect to win. </P>
 107 <P>There are also Backup Browsers which are promoted to Master Browsers in
 108 the event of a Master Browser disappearing from the network.</P>
 109 <P>Alternative terms include confusing variations such as "Browse Master",
 110 and "Master Browser" which we are trying to eliminate from the Samba
 111 documentation. </P>
 112
 113 <DT><B>Domain Controller</B><DD><P>is a term which comes from the Microsoft and IBM
 114 etc implementation of the LAN Manager protocols. It is tied to
 115 authentication. There are other ways of doing domain authentication, but
 116 the Windows NT method has a large market share. The general issues are
 117 discussed in
 118 <A HREF="../DOMAIN.txt">../DOMAIN.txt</A> and a Windows NT-specific
 119 discussion is in
 120 <A HREF="../DOMAIN_CONTROL.txt">../DOMAIN_CONTROL.txt</A>.</P>
 121
 122 </DL>
 123 </P>
 124
 125 <H3>Sharelevel (Workgroup) Security Services</H3>
 126
 127 <P>
 128 <A NAME="ShareModeSecurity"></A>
 129 </P>
 130 <P>With the Samba setting "security = SHARE", all shared resources
 131 information about what password is associated with them but only hints
 132 as to what usernames might be valid (the hint can be 'all users', in
 133 which case any username will work. This is usually a bad idea, but
 134 reflects both the initial implementations of SMB in the mid-80s and
 135 its reincarnation with Windows for Workgroups in 1992. The idea behind
 136 workgroup security was that small independant groups of people could
 137 share information on an ad-hoc basis without there being an
 138 authentication infrastructure present or requiring them to do more than
 139 fill in a dialogue box.</P>
 140
 141 <H3>Authentication Domain Mode Services</H3>
 142
 143 <P>
 144 <A NAME="DomainModeSecurity"></A>
 145 </P>
 146 <P>With the Samba settings "security = USER" or "security = SERVER"
 147 accesses to all resources are checked for username/password pair matches
 148 in a more rigorous manner. To the client, this has the effect of
 149 emulating a Microsoft Domain. The client is not concerned whether or not
 150 Samba looks up a Windows NT SAM or does it in some other way.</P>
 151
 152
 153 <H2><A NAME="ss4.2">4.2 Authentication Schemes</A></H2>
 154
 155
 156 <P>In the simple case authentication information is stored on a single
 157 server and the user types a password on connecting for the first time.
 158 However client operating systems often require a password before they
 159 can be used at all, and in addition users usually want access to more
 160 than one server. Asking users to remember many different passwords in
 161 different contexts just does not work. Some kind of distributed
 162 authentication database is needed. It must cope with password changes
 163 and provide for assigning groups of users the same level of access
 164 permissions. This is why Samba installations often choose to implement a
 165 Domain model straight away.</P>
 166 <P>Authentication decisions are some of the biggest in designing a network.
 167 Are you going to use a scheme native to the client operating system,
 168 native to the server operating system, or newly installed on both? A
 169 list of options relevant to Samba (ie that make sense in the context of
 170 the SMB protocol) follows. Any experiences with other setups would be
 171 appreciated. <F>refer to server FAQ for "passwd chat" passwd program
 172 password server etc etc...</F></P>
 173
 174 <H3>NIS</H3>
 175
 176
 177 <P>For Windows 95, Windows for Workgroups and most other clients Samba can
 178 be a domain controller and share the password database via NIS
 179 transparently. Windows NT is different.
 180 <A HREF="http://www.dcs.qmw.ac.uk/~williams">Free NIS NT client</A></P>
 181
 182 <H3>Kerberos</H3>
 183
 184
 185 <P>Kerberos for US users only:
 186 <A HREF="http://www.cygnus.com/product/unifying-security.html">Kerberos overview</A>
 187 <A HREF="http://www.cygnus.com/product/kerbnet-download.html">Download Kerberos</A></P>
 188
 189 <H3>FTP</H3>
 190
 191
 192 <P>Other NT w/s logon hack via NT</P>
 193
 194 <H3>Default Server Method</H3>
 195
 196
 197
 198 <H3>Client-side Database Only</H3>
 199
 200
 201
 202
 203 <H2><A NAME="ss4.3">4.3 Post-Authentication: Netlogon, Logon Scripts, Profiles</A></H2>
 204
 205
 206 <P>See
 207 <A HREF="../DOMAIN.txt">../DOMAIN.txt</A></P>
 208
 209
 210 <HR>
 211 <A HREF="Samba-meta-FAQ-3.html">Previous</A>
 212 <A HREF="Samba-meta-FAQ-5.html">Next</A>
 213 <A HREF="Samba-meta-FAQ.html#toc4">Table of Contents</A>
 214 </BODY>
 215 </HTML>