diff options
| author | Samba Release Account <samba-bugs@samba.org> | 1997-08-26 01:43:28 +0000 |
|---|---|---|
| committer | Samba Release Account <samba-bugs@samba.org> | 1997-08-26 01:43:28 +0000 |
| commit | 1cc8103fd6508e0b710ef8e119bf71d7de65f9d9 (patch) | |
| tree | c0809353d4f8a1d2a2cdfd754d17999edfcf9e58 /docs/faq/Samba-meta-FAQ-4.html | |
| parent | bede27be4e8e16859de1d7e878e9d674571237c0 (diff) | |
| download | samba-1cc8103fd6508e0b710ef8e119bf71d7de65f9d9.tar.gz samba-1cc8103fd6508e0b710ef8e119bf71d7de65f9d9.tar.bz2 samba-1cc8103fd6508e0b710ef8e119bf71d7de65f9d9.zip | |
Added draft cversions of the new Samba doco. Dan.
(This used to be commit b5983092a6e63118564c6d1460b522ea8ef02c3a)
Diffstat (limited to 'docs/faq/Samba-meta-FAQ-4.html')
| -rw-r--r-- | docs/faq/Samba-meta-FAQ-4.html | 215 |
1 files changed, 215 insertions, 0 deletions
diff --git a/docs/faq/Samba-meta-FAQ-4.html b/docs/faq/Samba-meta-FAQ-4.html new file mode 100644 index 0000000000..73a9eea847 --- /dev/null +++ b/docs/faq/Samba-meta-FAQ-4.html @@ -0,0 +1,215 @@ +<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> |