mirror of
https://github.com/samba-team/samba.git
synced 2024-12-27 03:21:53 +03:00
216 lines
8.6 KiB
HTML
216 lines
8.6 KiB
HTML
<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>
|