diff options
Diffstat (limited to 'docs/faq/Samba-meta-FAQ-4.html')
| -rw-r--r-- | docs/faq/Samba-meta-FAQ-4.html | 215 |
1 files changed, 0 insertions, 215 deletions
diff --git a/docs/faq/Samba-meta-FAQ-4.html b/docs/faq/Samba-meta-FAQ-4.html deleted file mode 100644 index 73a9eea847..0000000000 --- a/docs/faq/Samba-meta-FAQ-4.html +++ /dev/null @@ -1,215 +0,0 @@ -<HTML> -<HEAD> -<TITLE> Samba meta FAQ: Designing A SMB and CIFS Network</TITLE> -</HEAD> -<BODY> -<A HREF="Samba-meta-FAQ-3.html">Previous</A> -<A HREF="Samba-meta-FAQ-5.html">Next</A> -<A HREF="Samba-meta-FAQ.html#toc4">Table of Contents</A> -<HR> -<H2><A NAME="s4">4. Designing A SMB and CIFS Network</A></H2> - - -<P>The big issues for installing any network of LAN or WAN file and print -servers are </P> -<P> -<UL> -<LI>How and where usernames, passwords and other security information -is stored -</LI> -<LI>What method can be used for locating the resources that users have -permission to use -</LI> -<LI>What protocols the clients can converse with -</LI> -</UL> - </P> -<P>If you buy Netware, Windows NT or just about any other LAN fileserver -product you are expected to lock yourself into the product's preferred -answers to these questions. This tendancy is restrictive and often very -expensive for a site where there is only one kind of client or server, -and for sites with a mixture of operating systems it often makes it -impossible to share resources between some sets of users.</P> -<P>The Samba philosophy is to make things as easy as possible for -administators, which means allowing as many combinations of clients, -servers, operating systems and protocols as possible.</P> - -<H2><A NAME="ss4.1">4.1 Workgroups, Domains, Authentication and Browsing</A></H2> - - -<P>From the point of view of networking implementation, Domains and -Workgroups are <EM>exactly</EM> the same, except for the client logon -sequence. Some kind of distributed authentication database is associated -with a domain (there are quite a few choices) and this adds so much -flexibility that many people think of a domain as a completely different -entity to a workgroup. From Samba's point of view a client connecting to -a service presents an authentication token, and it if it is valid they -have access. Samba does not care what mechanism was used to generate -that token in the first place.</P> -<P>The SMB client logging on to a domain has an expectation that every other -server in the domain should accept the same authentication information. -However the network browsing functionality of domains and workgroups is -identical and is explained in -<A HREF="../BROWSING.txt">../BROWSING.txt</A>.</P> -<P>There are some implementation differences: Windows 95 can be a member of -both a workgroup and a domain, but Windows NT cannot. Windows 95 also -has the concept of an "alternative workgroup". Samba can only be a -member of a single workgroup or domain, although this is due to change -with a future version when nmbd will be split into two daemons, one for -WINS and the other for browsing ( -<A HREF="../NetBIOS.txt">../NetBIOS.txt</A> explains -what WINS is.)</P> - -<H3>Defining the Terms</H3> - -<P> -<A NAME="BrowseAndDomainDefs"></A> -</P> -<P> -<DL> - -<DT><B>Workgroup</B><DD><P>means a collection of machines that maintain a common -browsing database containing information about their shared resources. -They do not necessarily have any security information in common (if they -do, it gets called a Domain.) The browsing database is dynamic, modified -as servers come and go on the network and as resources are added or -deleted. The term "browsing" refers to a user accessing the database via -whatever interface the client provides, eg the OS/2 Workplace Shell or -Windows 95 Explorer. SMB servers agree between themselves as to which -ones will maintain the browsing database. Workgroups can be anywhere on -a connected TCP/IP network, including on different subnets or even on -the Interet. This is a very tricky part of SMB to implement.</P> - -<DT><B>Master Browsers</B><DD><P>are machines which holds the master browsing -database for a workgroup or domain. There are two kinds of Master Browser:</P> -<P> -<UL> -<LI> Domain Master Browser, which holds the master browsing -information for an entire domain, which may well cross multiple TCP/IP -subnets. -</LI> -<LI> Local Master Browser, which holds the master browsing database -for a particular subnet and communicates with the Domain Master Browser -to get information on other subnets. -</LI> -</UL> -</P> -<P>Subnets are differentiated because browsing is based on broadcasts, and -broadcasts do not pass through routers. Subnets are not routed: while it -is possible to have more than one subnet on a single network segment -this is regarded as very bad practice.</P> -<P>Master Browsers (both Domain and Local) are elected dynamically -according to an algorithm which is supposed to take into account the -machine's ability to sustain the browsing load. Samba can be configured -to always act as a master browser, ie it always wins elections under all -circumstances, even against systems such as a Windows NT Primary Domain -Controller which themselves expect to win. </P> -<P>There are also Backup Browsers which are promoted to Master Browsers in -the event of a Master Browser disappearing from the network.</P> -<P>Alternative terms include confusing variations such as "Browse Master", -and "Master Browser" which we are trying to eliminate from the Samba -documentation. </P> - -<DT><B>Domain Controller</B><DD><P>is a term which comes from the Microsoft and IBM -etc implementation of the LAN Manager protocols. It is tied to -authentication. There are other ways of doing domain authentication, but -the Windows NT method has a large market share. The general issues are -discussed in -<A HREF="../DOMAIN.txt">../DOMAIN.txt</A> and a Windows NT-specific -discussion is in -<A HREF="../DOMAIN_CONTROL.txt">../DOMAIN_CONTROL.txt</A>.</P> - -</DL> -</P> - -<H3>Sharelevel (Workgroup) Security Services</H3> - -<P> -<A NAME="ShareModeSecurity"></A> -</P> -<P>With the Samba setting "security = SHARE", all shared resources -information about what password is associated with them but only hints -as to what usernames might be valid (the hint can be 'all users', in -which case any username will work. This is usually a bad idea, but -reflects both the initial implementations of SMB in the mid-80s and -its reincarnation with Windows for Workgroups in 1992. The idea behind -workgroup security was that small independant groups of people could -share information on an ad-hoc basis without there being an -authentication infrastructure present or requiring them to do more than -fill in a dialogue box.</P> - -<H3>Authentication Domain Mode Services</H3> - -<P> -<A NAME="DomainModeSecurity"></A> -</P> -<P>With the Samba settings "security = USER" or "security = SERVER" -accesses to all resources are checked for username/password pair matches -in a more rigorous manner. To the client, this has the effect of -emulating a Microsoft Domain. The client is not concerned whether or not -Samba looks up a Windows NT SAM or does it in some other way.</P> - - -<H2><A NAME="ss4.2">4.2 Authentication Schemes</A></H2> - - -<P>In the simple case authentication information is stored on a single -server and the user types a password on connecting for the first time. -However client operating systems often require a password before they -can be used at all, and in addition users usually want access to more -than one server. Asking users to remember many different passwords in -different contexts just does not work. Some kind of distributed -authentication database is needed. It must cope with password changes -and provide for assigning groups of users the same level of access -permissions. This is why Samba installations often choose to implement a -Domain model straight away.</P> -<P>Authentication decisions are some of the biggest in designing a network. -Are you going to use a scheme native to the client operating system, -native to the server operating system, or newly installed on both? A -list of options relevant to Samba (ie that make sense in the context of -the SMB protocol) follows. Any experiences with other setups would be -appreciated. <F>refer to server FAQ for "passwd chat" passwd program -password server etc etc...</F></P> - -<H3>NIS</H3> - - -<P>For Windows 95, Windows for Workgroups and most other clients Samba can -be a domain controller and share the password database via NIS -transparently. Windows NT is different. -<A HREF="http://www.dcs.qmw.ac.uk/~williams">Free NIS NT client</A></P> - -<H3>Kerberos</H3> - - -<P>Kerberos for US users only: -<A HREF="http://www.cygnus.com/product/unifying-security.html">Kerberos overview</A> -<A HREF="http://www.cygnus.com/product/kerbnet-download.html">Download Kerberos</A></P> - -<H3>FTP</H3> - - -<P>Other NT w/s logon hack via NT</P> - -<H3>Default Server Method</H3> - - - -<H3>Client-side Database Only</H3> - - - - -<H2><A NAME="ss4.3">4.3 Post-Authentication: Netlogon, Logon Scripts, Profiles</A></H2> - - -<P>See -<A HREF="../DOMAIN.txt">../DOMAIN.txt</A></P> - - -<HR> -<A HREF="Samba-meta-FAQ-3.html">Previous</A> -<A HREF="Samba-meta-FAQ-5.html">Next</A> -<A HREF="Samba-meta-FAQ.html#toc4">Table of Contents</A> -</BODY> -</HTML> |