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 14servers are </P> 15<P> 16<UL> 17<LI>How and where usernames, passwords and other security information 18is stored 19</LI> 20<LI>What method can be used for locating the resources that users have 21permission 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 28product you are expected to lock yourself into the product's preferred 29answers to these questions. This tendancy is restrictive and often very 30expensive for a site where there is only one kind of client or server, 31and for sites with a mixture of operating systems it often makes it 32impossible to share resources between some sets of users.</P> 33<P>The Samba philosophy is to make things as easy as possible for 34administators, which means allowing as many combinations of clients, 35servers, 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 41Workgroups are <EM>exactly</EM> the same, except for the client logon 42sequence. Some kind of distributed authentication database is associated 43with a domain (there are quite a few choices) and this adds so much 44flexibility that many people think of a domain as a completely different 45entity to a workgroup. From Samba's point of view a client connecting to 46a service presents an authentication token, and it if it is valid they 47have access. Samba does not care what mechanism was used to generate 48that token in the first place.</P> 49<P>The SMB client logging on to a domain has an expectation that every other 50server in the domain should accept the same authentication information. 51However the network browsing functionality of domains and workgroups is 52identical 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 55both a workgroup and a domain, but Windows NT cannot. Windows 95 also 56has the concept of an "alternative workgroup". Samba can only be a 57member of a single workgroup or domain, although this is due to change 58with a future version when nmbd will be split into two daemons, one for 59WINS and the other for browsing ( 60<A HREF="../NetBIOS.txt">../NetBIOS.txt</A> explains 61what 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 72browsing database containing information about their shared resources. 73They do not necessarily have any security information in common (if they 74do, it gets called a Domain.) The browsing database is dynamic, modified 75as servers come and go on the network and as resources are added or 76deleted. The term "browsing" refers to a user accessing the database via 77whatever interface the client provides, eg the OS/2 Workplace Shell or 78Windows 95 Explorer. SMB servers agree between themselves as to which 79ones will maintain the browsing database. Workgroups can be anywhere on 80a connected TCP/IP network, including on different subnets or even on 81the 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 84database 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 88information for an entire domain, which may well cross multiple TCP/IP 89subnets. 90</LI> 91<LI> Local Master Browser, which holds the master browsing database 92for a particular subnet and communicates with the Domain Master Browser 93to get information on other subnets. 94</LI> 95</UL> 96</P> 97<P>Subnets are differentiated because browsing is based on broadcasts, and 98broadcasts do not pass through routers. Subnets are not routed: while it 99is possible to have more than one subnet on a single network segment 100this is regarded as very bad practice.</P> 101<P>Master Browsers (both Domain and Local) are elected dynamically 102according to an algorithm which is supposed to take into account the 103machine's ability to sustain the browsing load. Samba can be configured 104to always act as a master browser, ie it always wins elections under all 105circumstances, even against systems such as a Windows NT Primary Domain 106Controller which themselves expect to win. </P> 107<P>There are also Backup Browsers which are promoted to Master Browsers in 108the event of a Master Browser disappearing from the network.</P> 109<P>Alternative terms include confusing variations such as "Browse Master", 110and "Master Browser" which we are trying to eliminate from the Samba 111documentation. </P> 112 113<DT><B>Domain Controller</B><DD><P>is a term which comes from the Microsoft and IBM 114etc implementation of the LAN Manager protocols. It is tied to 115authentication. There are other ways of doing domain authentication, but 116the Windows NT method has a large market share. The general issues are 117discussed in 118<A HREF="../DOMAIN.txt">../DOMAIN.txt</A> and a Windows NT-specific 119discussion 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 131information about what password is associated with them but only hints 132as to what usernames might be valid (the hint can be 'all users', in 133which case any username will work. This is usually a bad idea, but 134reflects both the initial implementations of SMB in the mid-80s and 135its reincarnation with Windows for Workgroups in 1992. The idea behind 136workgroup security was that small independant groups of people could 137share information on an ad-hoc basis without there being an 138authentication infrastructure present or requiring them to do more than 139fill 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" 147accesses to all resources are checked for username/password pair matches 148in a more rigorous manner. To the client, this has the effect of 149emulating a Microsoft Domain. The client is not concerned whether or not 150Samba 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 157server and the user types a password on connecting for the first time. 158However client operating systems often require a password before they 159can be used at all, and in addition users usually want access to more 160than one server. Asking users to remember many different passwords in 161different contexts just does not work. Some kind of distributed 162authentication database is needed. It must cope with password changes 163and provide for assigning groups of users the same level of access 164permissions. This is why Samba installations often choose to implement a 165Domain model straight away.</P> 166<P>Authentication decisions are some of the biggest in designing a network. 167Are you going to use a scheme native to the client operating system, 168native to the server operating system, or newly installed on both? A 169list of options relevant to Samba (ie that make sense in the context of 170the SMB protocol) follows. Any experiences with other setups would be 171appreciated. <F>refer to server FAQ for "passwd chat" passwd program 172password 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 178be a domain controller and share the password database via NIS 179transparently. 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> 216