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
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>Samba as Stand-Alone server (User and Share security level)</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="SAMBA Project Documentation"
HREF="samba-howto-collection.html"><LINK
REL="UP"
TITLE="Type of installation"
HREF="type.html"><LINK
REL="PREVIOUS"
TITLE="Nomenclature of Server Types"
HREF="servertype.html"><LINK
REL="NEXT"
TITLE="Samba as an NT4 or Win2k Primary Domain Controller"
HREF="samba-pdc.html"></HEAD
><BODY
CLASS="CHAPTER"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>SAMBA Project Documentation</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="servertype.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="samba-pdc.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="CHAPTER"
><H1
><A
NAME="SECURITYLEVELS"
></A
>Chapter 5. Samba as Stand-Alone server (User and Share security level)</H1
><P
>A SMB server tells the client at startup what "security level" it is
running. There are two options "share level" and "user level". Which
of these two the client receives affects the way the client then tries
to authenticate itself. It does not directly affect (to any great
extent) the way the Samba server does security. I know this is
strange, but it fits in with the client/server approach of SMB. In SMB
everything is initiated and controlled by the client, and the server
can only tell the client what is available and whether an action is
allowed. </P
><P
>I'll describe user level security first, as its simpler. In user level
security the client will send a "session setup" command directly after
the protocol negotiation. This contains a username and password. The
server can either accept or reject that username/password
combination. Note that at this stage the server has no idea what
share the client will eventually try to connect to, so it can't base
the "accept/reject" on anything other than:</P
><P
></P
><OL
TYPE="1"
><LI
><P
>the username/password</P
></LI
><LI
><P
>the machine that the client is coming from</P
></LI
></OL
><P
>If the server accepts the username/password then the client expects to
be able to mount any share (using a "tree connection") without
specifying a password. It expects that all access rights will be as
the username/password specified in the "session setup". </P
><P
>It is also possible for a client to send multiple "session setup"
requests. When the server responds it gives the client a "uid" to use
as an authentication tag for that username/password. The client can
maintain multiple authentication contexts in this way (WinDD is an
example of an application that does this)</P
><P
>Ok, now for share level security. In share level security the client
authenticates itself separately for each share. It will send a
password along with each "tree connection" (share mount). It does not
explicitly send a username with this operation. The client is
expecting a password to be associated with each share, independent of
the user. This means that samba has to work out what username the
client probably wants to use. It is never explicitly sent the
username. Some commercial SMB servers such as NT actually associate
passwords directly with shares in share level security, but samba
always uses the unix authentication scheme where it is a
username/password that is authenticated, not a "share/password".</P
><P
>Many clients send a "session setup" even if the server is in share
level security. They normally send a valid username but no
password. Samba records this username in a list of "possible
usernames". When the client then does a "tree connection" it also adds
to this list the name of the share they try to connect to (useful for
home directories) and any users listed in the "user =" smb.conf
line. The password is then checked in turn against these "possible
usernames". If a match is found then the client is authenticated as
that user.</P
><P
>Finally "server level" security. In server level security the samba
server reports to the client that it is in user level security. The
client then does a "session setup" as described earlier. The samba
server takes the username/password that the client sends and attempts
to login to the "password server" by sending exactly the same
username/password that it got from the client. If that server is in
user level security and accepts the password then samba accepts the
clients connection. This allows the samba server to use another SMB
server as the "password server". </P
><P
>You should also note that at the very start of all this, where the
server tells the client what security level it is in, it also tells
the client if it supports encryption. If it does then it supplies the
client with a random "cryptkey". The client will then send all
passwords in encrypted form. You have to compile samba with encryption
enabled to support this feature, and you have to maintain a separate
smbpasswd file with SMB style encrypted passwords. It is
cryptographically impossible to translate from unix style encryption
to SMB style encryption, although there are some fairly simple management
schemes by which the two could be kept in sync.</P
><P
>"security = server" means that Samba reports to clients that
it is running in "user mode" but actually passes off all authentication
requests to another "user mode" server. This requires an additional
parameter "password server =" that points to the real authentication server.
That real authentication server can be another Samba server or can be a
Windows NT server, the later natively capable of encrypted password support.</P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="servertype.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="samba-howto-collection.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="samba-pdc.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Nomenclature of Server Types</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="type.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Samba as an NT4 or Win2k Primary Domain Controller</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
|
