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
|
<samba:parameter name="security"
context="G"
type="enum"
basic="1" advanced="1" wizard="1" developer="1"
xmlns:samba="http://www.samba.org/samba/DTD/samba-doc">
<when_value value="security">
<requires option="encrypted passwords">/(yes|true)/</requires>
</when_value>
<description>
<para>This option affects how clients respond to
Samba and is one of the most important settings in the <filename moreinfo="none">
smb.conf</filename> file.</para>
<para>The default is <command moreinfo="none">security = user</command>, as this is
the most common setting, used for a standalone file server or a DC.</para>
<para>The alternatives are
<command moreinfo="none">security = ads</command> or <command moreinfo="none">security = domain
</command>, which support joining Samba to a Windows domain, along with <command moreinfo="none">security = server</command>, which is deprecated.</para>
<para>You should use <command moreinfo="none">security = user</command> and
<smbconfoption name="map to guest"/> if you
want to mainly setup shares without a password (guest shares). This
is commonly used for a shared printer server. </para>
<para>The different settings will now be explained.</para>
<para><anchor id="SECURITYEQUALSAUTO"/><emphasis>SECURITY = AUTO</emphasis></para>
<para>This is the default security setting in Samba, and causes Samba to consult
the <smbconfoption name="server role"/> parameter (if set) to determine the security mode.</para>
<para><anchor id="SECURITYEQUALSUSER"/><emphasis>SECURITY = USER</emphasis></para>
<para>If <smbconfoption name="server role"/> is not specified, this is the default security setting in Samba.
With user-level security a client must first "log-on" with a
valid username and password (which can be mapped using the <smbconfoption name="username map"/>
parameter). Encrypted passwords (see the <smbconfoption name="encrypted passwords"/> parameter) can also
be used in this security mode. Parameters such as <smbconfoption name="user"/> and <smbconfoption
name="guest only"/> if set are then applied and
may change the UNIX user to use on this connection, but only after
the user has been successfully authenticated.</para>
<para><emphasis>Note</emphasis> that the name of the resource being
requested is <emphasis>not</emphasis> sent to the server until after
the server has successfully authenticated the client. This is why
guest shares don't work in user level security without allowing
the server to automatically map unknown users into the <smbconfoption name="guest account"/>.
See the <smbconfoption name="map to guest"/> parameter for details on doing this.</para>
<para><anchor id="SECURITYEQUALSDOMAIN"/><emphasis>SECURITY = DOMAIN</emphasis></para>
<para>This mode will only work correctly if <citerefentry><refentrytitle>net</refentrytitle>
<manvolnum>8</manvolnum></citerefentry> has been used to add this
machine into a Windows NT Domain. It expects the <smbconfoption name="encrypted passwords"/>
parameter to be set to <constant>yes</constant>. In this
mode Samba will try to validate the username/password by passing
it to a Windows NT Primary or Backup Domain Controller, in exactly
the same way that a Windows NT Server would do.</para>
<para><emphasis>Note</emphasis> that a valid UNIX user must still
exist as well as the account on the Domain Controller to allow
Samba to have a valid UNIX account to map file access to.</para>
<para><emphasis>Note</emphasis> that from the client's point
of view <command moreinfo="none">security = domain</command> is the same
as <command moreinfo="none">security = user</command>. It only
affects how the server deals with the authentication,
it does not in any way affect what the client sees.</para>
<para><emphasis>Note</emphasis> that the name of the resource being
requested is <emphasis>not</emphasis> sent to the server until after
the server has successfully authenticated the client. This is why
guest shares don't work in user level security without allowing
the server to automatically map unknown users into the <smbconfoption name="guest account"/>.
See the <smbconfoption name="map to guest"/> parameter for details on doing this.</para>
<para>See also the <smbconfoption name="password server"/> parameter and
the <smbconfoption name="encrypted passwords"/> parameter.</para>
<para><anchor id="SECURITYEQUALSSERVER"/><emphasis>SECURITY = SERVER</emphasis></para>
<para>
In this depicted mode Samba will try to validate the username/password by passing it to another SMB server, such as an
NT box. If this fails it will revert to <command moreinfo="none">security = user</command>. It expects the
<smbconfoption name="encrypted passwords"/> parameter to be set to <constant>yes</constant>, unless the remote
server does not support them. However note that if encrypted passwords have been negotiated then Samba cannot
revert back to checking the UNIX password file, it must have a valid <filename
moreinfo="none">smbpasswd</filename> file to check users against. See the chapter about the User Database in
the Samba HOWTO Collection for details on how to set this up.
</para>
<note><para>This mode of operation has
significant pitfalls since it is more vulnerable to
man-in-the-middle attacks and server impersonation. In particular,
this mode of operation can cause significant resource consumption on
the PDC, as it must maintain an active connection for the duration
of the user's session. Furthermore, if this connection is lost,
there is no way to reestablish it, and further authentications to the
Samba server may fail (from a single client, till it disconnects).
</para></note>
<note><para>If the client selects NTLMv2 authentication, then this mode of operation <emphasis>will fail</emphasis>
</para></note>
<note><para>From the client's point of
view, <command moreinfo="none">security = server</command> is the
same as <command moreinfo="none">security = user</command>. It
only affects how the server deals with the authentication, it does
not in any way affect what the client sees.</para></note>
<note><para>This option is deprecated, and may be removed in future</para></note>
<para><emphasis>Note</emphasis> that the name of the resource being
requested is <emphasis>not</emphasis> sent to the server until after
the server has successfully authenticated the client. This is why
guest shares don't work in user level security without allowing
the server to automatically map unknown users into the <smbconfoption name="guest account"/>.
See the <smbconfoption name="map to guest"/> parameter for details on doing this.</para>
<para>See also the <smbconfoption name="password server"/> parameter and the
<smbconfoption name="encrypted passwords"/> parameter.</para>
<para><anchor id="SECURITYEQUALSADS"/><emphasis>SECURITY = ADS</emphasis></para>
<para>In this mode, Samba will act as a domain member in an ADS realm. To operate
in this mode, the machine running Samba will need to have Kerberos installed
and configured and Samba will need to be joined to the ADS realm using the
net utility. </para>
<para>Note that this mode does NOT make Samba operate as a Active Directory Domain
Controller. </para>
<para>Read the chapter about Domain Membership in the HOWTO for details.</para>
</description>
<related>realm</related>
<related>encrypt passwords</related>
<value type="default">USER</value>
<value type="example">DOMAIN</value>
</samba:parameter>
|
