summaryrefslogtreecommitdiff
path: root/docs/faq/Samba-meta-FAQ-4.html
diff options
context:
space:
mode:
Diffstat (limited to 'docs/faq/Samba-meta-FAQ-4.html')
-rw-r--r--docs/faq/Samba-meta-FAQ-4.html215
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>