1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
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>
|
