← Back to branch summary

~ubuntu-branches/ubuntu/vivid/samba/vivid

« back to all changes in this revision

Viewing changes to docs-xml/smbdotconf/security/security.xml

  • Committer: Package Import Robot
  • Author(s): Chuck Short
  • Date: 2011-12-21 13:18:04 UTC
  • mfrom: (0.39.21 sid)
  • Revision ID: package-import@ubuntu.com-20111221131804-xtlr39wx6njehxxr
Tags: 2:3.6.1-3ubuntu1
* Merge from Debian testing.  Remaining changes:
  + debian/patches/VERSION.patch:
    - set SAMBA_VERSION_SUFFIX to Ubuntu.
  + debian/patches/error-trans.fix-276472:
    - Add the translation of Unix Error code -ENOTSUP to NT Error Code
    - NT_STATUS_NOT_SUPPORTED to prevent the Permission denied error.
  + debian/smb.conf:
    - add "(Samba, Ubuntu)" to server string.
    - comment out the default [homes] share, and add a comment about
      "valid users = %S" to show users how to restrict access to
      \\server\username to only username.
    - Set 'usershare allow guests', so that usershare admins are 
      allowed to create public shares in addition to authenticated
      ones.
    - add map to guest = Bad user, maps bad username to guest access.
  + debian/samba-common.config:
    - Do not change priority to high if dhclient3 is installed.
    - Use priority medium instead of high for the workgroup question.
  + debian/control:
    - Don't build against or suggest ctdb.
    - Add dependency on samba-common-bin to samba.
  + Add ufw integration:
    - Created debian/samba.ufw.profile
    - debian/rules, debian/samba.dirs, debian/samba.files: install
      profile
    - debian/control: have samba suggest ufw
  + Add apport hook:
    - Created debian/source_samba.py.
    - debian/rules, debian/samba.dirs, debian/samba-common-bin.files: install
  + Switch to upstart:
    - Add debian/samba.{nmbd,smbd}.upstart.
  + debian/samba.logrotate, debian/samba-common.dhcp, debian/samba.if-up:
    - Make them upstart compatible
  + debian/samba.postinst: 
    - Avoid scary pdbedit warnings on first import.
  + debian/samba-common.postinst: Add more informative error message for
    the case where smb.conf was manually deleted
  + debian/patches/fix-debuglevel-name-conflict.patch: don't use 'debug_level'
    as a global variable name in an NSS module 
  + Dropped:
    - debian/patches/error-trans.fix-276472
    - debian/patches/fix-debuglevel-name-conflict.patch

Show diffs side-by-side

added added

removed removed

Lines of Context:
docs-xml/smbdotconf/security/security.xml
22
22
    the most common setting needed when talking to Windows 98 and 
23
23
    Windows NT.</para>
24
24
 
25
 
    <para>The alternatives are <command moreinfo="none">security = share</command>,
26
 
    <command moreinfo="none">security = server</command> or <command moreinfo="none">security = domain
27
 
    </command>.</para>
 
25
    <para>The alternatives are
 
26
    <command moreinfo="none">security = ads</command> or <command moreinfo="none">security = domain
 
27
    </command>, which support joining Samba to a Windows domain, along with <command moreinfo="none">security = share</command> and <command moreinfo="none">security = server</command>, both of which are deprecated.</para>
28
28
 
29
29
    <para>In versions of Samba prior to 2.0.0, the default was 
30
30
    <command moreinfo="none">security = share</command> mainly because that was
31
31
    the only option at one stage.</para>
32
32
 
33
 
    <para>There is a bug in WfWg that has relevance to this 
34
 
    setting. When in user or server level security a WfWg client 
35
 
    will totally ignore the username and password you type in the &quot;connect 
36
 
    drive&quot; dialog box. This makes it very difficult (if not impossible) 
37
 
    to connect to a Samba service as anyone except the user that 
38
 
    you are logged into WfWg as.</para>
39
 
 
40
 
    <para>If your PCs use usernames that are the same as their 
41
 
    usernames on the UNIX machine then you will want to use 
42
 
    <command moreinfo="none">security = user</command>. If you mostly use usernames 
43
 
    that don't exist on the UNIX box then use <command moreinfo="none">security = 
44
 
    share</command>.</para>
45
 
 
46
 
    <para>You should also use <command moreinfo="none">security = share</command> if you 
 
33
    <para>You should use <command moreinfo="none">security = user</command> and
 
34
    <smbconfoption name="map to guest"/> if you
47
35
    want to mainly setup shares without a password (guest shares). This 
48
 
    is commonly used for a shared printer server. It is more difficult 
49
 
    to setup guest shares with <command moreinfo="none">security = user</command>, see 
50
 
    the <smbconfoption name="map to guest"/> parameter for details.</para>
 
36
    is commonly used for a shared printer server. </para>
51
37
                
52
38
    <para>It is possible to use <command moreinfo="none">smbd</command> in a <emphasis>
53
39
    hybrid mode</emphasis> where it is offers both user and share 
56
42
    <para>The different settings will now be explained.</para>
57
43
 
58
44
 
 
45
    <para><anchor id="SECURITYEQUALSUSER"/><emphasis>SECURITY = USER</emphasis></para>
 
46
 
 
47
    <para>This is the default security setting in Samba.
 
48
    With user-level security a client must first &quot;log-on&quot; with a
 
49
    valid username and password (which can be mapped using the <smbconfoption name="username map"/>
 
50
    parameter). Encrypted passwords (see the <smbconfoption name="encrypted passwords"/> parameter) can also
 
51
    be used in this security mode. Parameters such as <smbconfoption name="user"/> and <smbconfoption
 
52
        name="guest only"/> if set      are then applied and
 
53
    may change the UNIX user to use on this connection, but only after
 
54
    the user has been successfully authenticated.</para>
 
55
 
 
56
    <para><emphasis>Note</emphasis> that the name of the resource being
 
57
    requested is <emphasis>not</emphasis> sent to the server until after
 
58
    the server has successfully authenticated the client. This is why
 
59
    guest shares don't work in user level security without allowing
 
60
    the server to automatically map unknown users into the <smbconfoption name="guest account"/>.
 
61
    See the <smbconfoption name="map to guest"/> parameter for details on doing this.</para>
 
62
 
 
63
    <para>See also the section <link linkend="VALIDATIONSECT">NOTE ABOUT USERNAME/PASSWORD VALIDATION</link>.</para>
 
64
 
 
65
    <para><anchor id="SECURITYEQUALSDOMAIN"/><emphasis>SECURITY = DOMAIN</emphasis></para>
 
66
 
 
67
    <para>This mode will only work correctly if <citerefentry><refentrytitle>net</refentrytitle>
 
68
    <manvolnum>8</manvolnum></citerefentry> has been used to add this
 
69
    machine into a Windows NT Domain. It expects the <smbconfoption name="encrypted passwords"/>
 
70
        parameter to be set to <constant>yes</constant>. In this
 
71
    mode Samba will try to validate the username/password by passing
 
72
    it to a Windows NT Primary or Backup Domain Controller, in exactly
 
73
    the same way that a Windows NT Server would do.</para>
 
74
 
 
75
    <para><emphasis>Note</emphasis> that a valid UNIX user must still
 
76
    exist as well as the account on the Domain Controller to allow
 
77
    Samba to have a valid UNIX account to map file access to.</para>
 
78
 
 
79
    <para><emphasis>Note</emphasis> that from the client's point
 
80
    of view <command moreinfo="none">security = domain</command> is the same
 
81
    as <command moreinfo="none">security = user</command>. It only
 
82
    affects how the server deals with the authentication,
 
83
    it does not in any way affect what the client sees.</para>
 
84
 
 
85
    <para><emphasis>Note</emphasis> that the name of the resource being
 
86
    requested is <emphasis>not</emphasis> sent to the server until after
 
87
    the server has successfully authenticated the client. This is why
 
88
    guest shares don't work in user level security without allowing
 
89
    the server to automatically map unknown users into the <smbconfoption name="guest account"/>.
 
90
    See the <smbconfoption name="map to guest"/> parameter for details on doing this.</para>
 
91
 
 
92
    <para>See also the section <link linkend="VALIDATIONSECT">
 
93
    NOTE ABOUT USERNAME/PASSWORD VALIDATION</link>.</para>
 
94
 
 
95
    <para>See also the <smbconfoption name="password server"/> parameter and
 
96
         the <smbconfoption name="encrypted passwords"/> parameter.</para>
 
97
 
59
98
    <para><anchor id="SECURITYEQUALSSHARE"/><emphasis>SECURITY = SHARE</emphasis></para> 
 
99
 
 
100
    <note><para>This option is deprecated as it is incompatible with SMB2</para></note>
60
101
                
61
102
    <para>When clients connect to a share level security server, they 
62
103
    need not log onto the server with a valid username and password before 
135
176
    <para>See also the section <link linkend="VALIDATIONSECT">
136
177
    NOTE ABOUT USERNAME/PASSWORD VALIDATION</link>.</para>
137
178
 
138
 
    <para><anchor id="SECURITYEQUALSUSER"/><emphasis>SECURITY = USER</emphasis></para>
139
 
 
140
 
    <para>This is the default security setting in Samba 3.0. 
141
 
    With user-level security a client must first &quot;log-on&quot; with a 
142
 
    valid username and password (which can be mapped using the <smbconfoption name="username map"/> 
143
 
    parameter). Encrypted passwords (see the <smbconfoption name="encrypted passwords"/> parameter) can also
144
 
    be used in this security mode. Parameters such as <smbconfoption name="user"/> and <smbconfoption
145
 
        name="guest only"/> if set      are then applied and 
146
 
    may change the UNIX user to use on this connection, but only after 
147
 
    the user has been successfully authenticated.</para>
148
 
 
149
 
    <para><emphasis>Note</emphasis> that the name of the resource being 
150
 
    requested is <emphasis>not</emphasis> sent to the server until after 
151
 
    the server has successfully authenticated the client. This is why 
152
 
    guest shares don't work in user level security without allowing 
153
 
    the server to automatically map unknown users into the <smbconfoption name="guest account"/>. 
154
 
    See the <smbconfoption name="map to guest"/> parameter for details on doing this.</para>
155
 
 
156
 
    <para>See also the section <link linkend="VALIDATIONSECT">NOTE ABOUT USERNAME/PASSWORD VALIDATION</link>.</para>
157
 
 
158
 
    <para><anchor id="SECURITYEQUALSDOMAIN"/><emphasis>SECURITY = DOMAIN</emphasis></para>
159
 
 
160
 
    <para>This mode will only work correctly if <citerefentry><refentrytitle>net</refentrytitle>
161
 
    <manvolnum>8</manvolnum></citerefentry> has been used to add this
162
 
    machine into a Windows NT Domain. It expects the <smbconfoption name="encrypted passwords"/>
163
 
        parameter to be set to <constant>yes</constant>. In this 
164
 
    mode Samba will try to validate the username/password by passing
165
 
    it to a Windows NT Primary or Backup Domain Controller, in exactly 
166
 
    the same way that a Windows NT Server would do.</para>
167
 
 
168
 
    <para><emphasis>Note</emphasis> that a valid UNIX user must still 
169
 
    exist as well as the account on the Domain Controller to allow 
170
 
    Samba to have a valid UNIX account to map file access to.</para>
171
 
 
172
 
    <para><emphasis>Note</emphasis> that from the client's point 
173
 
    of view <command moreinfo="none">security = domain</command> is the same 
174
 
    as <command moreinfo="none">security = user</command>. It only 
175
 
    affects how the server deals with the authentication, 
176
 
    it does not in any way affect what the client sees.</para>
177
 
 
178
 
    <para><emphasis>Note</emphasis> that the name of the resource being 
179
 
    requested is <emphasis>not</emphasis> sent to the server until after 
180
 
    the server has successfully authenticated the client. This is why 
181
 
    guest shares don't work in user level security without allowing 
182
 
    the server to automatically map unknown users into the <smbconfoption name="guest account"/>. 
183
 
    See the <smbconfoption name="map to guest"/> parameter for details on doing this.</para>
184
 
 
185
 
    <para>See also the section <link linkend="VALIDATIONSECT">
186
 
    NOTE ABOUT USERNAME/PASSWORD VALIDATION</link>.</para>
187
 
 
188
 
    <para>See also the <smbconfoption name="password server"/> parameter and
189
 
         the <smbconfoption name="encrypted passwords"/> parameter.</para>
190
 
 
191
179
    <para><anchor id="SECURITYEQUALSSERVER"/><emphasis>SECURITY = SERVER</emphasis></para>
192
180
 
193
181
    <para>
194
 
        In this mode Samba will try to validate the username/password by passing it to another SMB server, such as an
 
182
        In this depicted mode Samba will try to validate the username/password by passing it to another SMB server, such as an
195
183
        NT box. If this fails it will revert to <command moreinfo="none">security = user</command>. It expects the
196
184
        <smbconfoption name="encrypted passwords"/> parameter to be set to <constant>yes</constant>, unless the remote
197
185
        server does not support them.  However note that if encrypted passwords have been negotiated then Samba cannot
203
191
        <note><para>This mode of operation has
204
192
    significant pitfalls since it is more vulnerable to
205
193
    man-in-the-middle attacks and server impersonation.  In particular,
206
 
    this mode of operation can cause significant resource consuption on
 
194
    this mode of operation can cause significant resource consumption on
207
195
    the PDC, as it must maintain an active connection for the duration
208
196
    of the user's session.  Furthermore, if this connection is lost,
209
 
    there is no way to reestablish it, and futher authentications to the
 
197
    there is no way to reestablish it, and further authentications to the
210
198
    Samba server may fail (from a single client, till it disconnects).
211
199
        </para></note>
212
200
 
 
201
        <note><para>If the client selects NTLMv2 authentication, then this mode of operation <emphasis>will fail</emphasis>
 
202
        </para></note>
 
203
 
213
204
        <note><para>From the client's point of 
214
205
    view, <command moreinfo="none">security = server</command> is the
215
206
    same as <command moreinfo="none">security = user</command>.  It
216
207
    only affects how the server deals  with the authentication, it does
217
208
        not in any way affect what the  client sees.</para></note>
218
209
 
 
210
    <note><para>This option is deprecated, and may be removed in future</para></note>
 
211
 
219
212
    <para><emphasis>Note</emphasis> that the name of the resource being 
220
213
    requested is <emphasis>not</emphasis> sent to the server until after 
221
214
    the server has successfully authenticated the client. This is why