summaryrefslogtreecommitdiff
path: root/docs-xml
diff options
context:
space:
mode:
Diffstat (limited to 'docs-xml')
-rw-r--r--docs-xml/manpages-3/smb.conf.5.xml53
-rw-r--r--docs-xml/smbdotconf/security/onlyuser.xml22
-rw-r--r--docs-xml/smbdotconf/security/security.xml109
-rw-r--r--docs-xml/smbdotconf/security/serverrole.xml3
-rw-r--r--docs-xml/smbdotconf/security/username.xml51
5 files changed, 16 insertions, 222 deletions
diff --git a/docs-xml/manpages-3/smb.conf.5.xml b/docs-xml/manpages-3/smb.conf.5.xml
index f5f252ba46..becea22531 100644
--- a/docs-xml/manpages-3/smb.conf.5.xml
+++ b/docs-xml/manpages-3/smb.conf.5.xml
@@ -670,59 +670,6 @@ chmod 1770 /usr/local/samba/lib/usershares
</refsect1>
-<refsect1 id="VALIDATIONSECT">
- <title>NOTE ABOUT USERNAME/PASSWORD VALIDATION</title>
-
- <para>
- There are a number of ways in which a user can connect to a service. The server uses the following steps
- in determining if it will allow a connection to a specified service. If all the steps fail, the connection
- request is rejected. However, if one of the steps succeeds, the following steps are not checked.
- </para>
-
- <para>
- If the service is marked <quote>guest only = yes</quote> and the server is running with share-level
- security (<quote>security = share</quote>, steps 1 to 5 are skipped.
- </para>
-
-
- <orderedlist continuation="restarts" inheritnum="ignore" numeration="arabic">
- <listitem><para>
- If the client has passed a username/password pair and that username/password pair is validated by the UNIX
- system's password programs, the connection is made as that username. This includes the
- <literal>\\server\service</literal>%<replaceable>username</replaceable> method of passing a username.
- </para></listitem>
-
- <listitem><para>
- If the client has previously registered a username with the system and now supplies a correct password for that
- username, the connection is allowed.
- </para></listitem>
-
- <listitem><para>
- The client's NetBIOS name and any previously used usernames are checked against the supplied password. If
- they match, the connection is allowed as the corresponding user.
- </para></listitem>
-
- <listitem><para>
- If the client has previously validated a username/password pair with the server and the client has passed
- the validation token, that username is used.
- </para></listitem>
-
- <listitem><para>
- If a <literal>user = </literal> field is given in the <filename moreinfo="none">smb.conf</filename> file for the
- service and the client has supplied a password, and that password matches (according to the UNIX system's
- password checking) with one of the usernames from the <literal>user =</literal> field, the connection is made as
- the username in the <literal>user =</literal> line. If one of the usernames in the <literal>user =</literal> list
- begins with a <literal>@</literal>, that name expands to a list of names in the group of the same name.
- </para></listitem>
-
- <listitem><para>
- If the service is a guest service, a connection is made as the username given in the <literal>guest account
- =</literal> for the service, irrespective of the supplied password.
- </para></listitem>
- </orderedlist>
-
-</refsect1>
-
<refsect1>
<title>REGISTRY-BASED CONFIGURATION</title>
diff --git a/docs-xml/smbdotconf/security/onlyuser.xml b/docs-xml/smbdotconf/security/onlyuser.xml
index b1ef1b7606..ed1bbd53e3 100644
--- a/docs-xml/smbdotconf/security/onlyuser.xml
+++ b/docs-xml/smbdotconf/security/onlyuser.xml
@@ -3,20 +3,16 @@
context="S"
xmlns:samba="http://www.samba.org/samba/DTD/samba-doc">
<description>
- <para>This is a boolean option that controls whether
- connections with usernames not in the <parameter moreinfo="none">user</parameter>
- list will be allowed. By default this option is disabled so that a
- client can supply a username to be used by the server. Enabling
- this parameter will force the server to only use the login
- names from the <parameter moreinfo="none">user</parameter> list and is only really
- useful in <smbconfoption name="security">share</smbconfoption> level security.</para>
+ <para>To restrict a service to a particular set of users you
+ can use the <smbconfoption name="valid users"/> parameter.</para>
+
+ <para>This parameter is deprecated</para>
+
+ <para>However, it currently operates only in conjunction with
+ <smbconfoption name="username"/>. The supported way to restrict
+ a service to a particular set of users is the
+ <smbconfoption name="valid users"/> parameter.</para>
- <para>Note that this also means Samba won't try to deduce
- usernames from the service name. This can be annoying for
- the [homes] section. To get around this you could use <command moreinfo="none">user =
- %S</command> which means your <parameter moreinfo="none">user</parameter> list
- will be just the service name, which for home directories is the
- name of the user.</para>
</description>
<related>user</related>
diff --git a/docs-xml/smbdotconf/security/security.xml b/docs-xml/smbdotconf/security/security.xml
index 74ea569b86..2575d77b99 100644
--- a/docs-xml/smbdotconf/security/security.xml
+++ b/docs-xml/smbdotconf/security/security.xml
@@ -11,34 +11,18 @@
Samba and is one of the most important settings in the <filename moreinfo="none">
smb.conf</filename> file.</para>
- <para>The option sets the &quot;security mode bit&quot; in replies to
- protocol negotiations with <citerefentry><refentrytitle>smbd</refentrytitle>
- <manvolnum>8</manvolnum></citerefentry> to turn share level security on or off. Clients decide
- based on this bit whether (and how) to transfer user and password
- information to the server.</para>
-
-
<para>The default is <command moreinfo="none">security = user</command>, as this is
- the most common setting needed when talking to Windows 98 and
- Windows NT.</para>
+ 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 = share</command> and <command moreinfo="none">security = server</command>, both of which are deprecated.</para>
-
- <para>In versions of Samba prior to 2.0.0, the default was
- <command moreinfo="none">security = share</command> mainly because that was
- the only option at one stage.</para>
+ </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>It is possible to use <command moreinfo="none">smbd</command> in a <emphasis>
- hybrid mode</emphasis> where it is offers both user and share
- level security under different <smbconfoption name="NetBIOS aliases"/>. </para>
-
<para>The different settings will now be explained.</para>
@@ -65,8 +49,6 @@
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 section <link linkend="VALIDATIONSECT">NOTE ABOUT USERNAME/PASSWORD VALIDATION</link>.</para>
-
<para><anchor id="SECURITYEQUALSDOMAIN"/><emphasis>SECURITY = DOMAIN</emphasis></para>
<para>This mode will only work correctly if <citerefentry><refentrytitle>net</refentrytitle>
@@ -94,93 +76,9 @@
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 section <link linkend="VALIDATIONSECT">
- NOTE ABOUT USERNAME/PASSWORD VALIDATION</link>.</para>
-
<para>See also the <smbconfoption name="password server"/> parameter and
the <smbconfoption name="encrypted passwords"/> parameter.</para>
- <para><anchor id="SECURITYEQUALSSHARE"/><emphasis>SECURITY = SHARE</emphasis></para>
-
- <note><para>This option is deprecated as it is incompatible with SMB2</para></note>
-
- <para>When clients connect to a share level security server, they
- need not log onto the server with a valid username and password before
- attempting to connect to a shared resource (although modern clients
- such as Windows 95/98 and Windows NT will send a logon request with
- a username but no password when talking to a <command moreinfo="none">security = share
- </command> server). Instead, the clients send authentication information
- (passwords) on a per-share basis, at the time they attempt to connect
- to that share.</para>
-
- <para>Note that <command moreinfo="none">smbd</command> <emphasis>ALWAYS</emphasis>
- uses a valid UNIX user to act on behalf of the client, even in
- <command moreinfo="none">security = share</command> level security.</para>
-
- <para>As clients are not required to send a username to the server
- in share level security, <command moreinfo="none">smbd</command> uses several
- techniques to determine the correct UNIX user to use on behalf
- of the client.</para>
-
- <para>A list of possible UNIX usernames to match with the given
- client password is constructed using the following methods :</para>
-
- <itemizedlist>
- <listitem>
- <para>If the <smbconfoption name="guest only"/> parameter is set, then all the other
- stages are missed and only the <smbconfoption name="guest account"/> username is checked.
- </para>
- </listitem>
-
- <listitem>
- <para>Is a username is sent with the share connection
- request, then this username (after mapping - see <smbconfoption name="username map"/>),
- is added as a potential username.
- </para>
- </listitem>
-
- <listitem>
- <para>If the client did a previous <emphasis>logon
- </emphasis> request (the SessionSetup SMB call) then the
- username sent in this SMB will be added as a potential username.
- </para>
- </listitem>
-
- <listitem>
- <para>The name of the service the client requested is
- added as a potential username.
- </para>
- </listitem>
-
- <listitem>
- <para>The NetBIOS name of the client is added to
- the list as a potential username.
- </para>
- </listitem>
-
- <listitem>
- <para>Any users on the <smbconfoption name="user"/> list are added as potential usernames.
- </para>
- </listitem>
- </itemizedlist>
-
- <para>If the <parameter moreinfo="none">guest only</parameter> parameter is
- not set, then this list is then tried with the supplied password.
- The first user for whom the password matches will be used as the
- UNIX user.</para>
-
- <para>If the <parameter moreinfo="none">guest only</parameter> parameter is
- set, or no username can be determined then if the share is marked
- as available to the <parameter moreinfo="none">guest account</parameter>, then this
- guest user will be used, otherwise access is denied.</para>
-
- <para>Note that it can be <emphasis>very</emphasis> confusing
- in share-level security as to which UNIX username will eventually
- be used in granting access.</para>
-
- <para>See also the section <link linkend="VALIDATIONSECT">
- NOTE ABOUT USERNAME/PASSWORD VALIDATION</link>.</para>
-
<para><anchor id="SECURITYEQUALSSERVER"/><emphasis>SECURITY = SERVER</emphasis></para>
<para>
@@ -221,9 +119,6 @@
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 section <link linkend="VALIDATIONSECT">
- NOTE ABOUT USERNAME/PASSWORD VALIDATION</link>.</para>
-
<para>See also the <smbconfoption name="password server"/> parameter and the
<smbconfoption name="encrypted passwords"/> parameter.</para>
diff --git a/docs-xml/smbdotconf/security/serverrole.xml b/docs-xml/smbdotconf/security/serverrole.xml
index 5832887040..e4e65c297b 100644
--- a/docs-xml/smbdotconf/security/serverrole.xml
+++ b/docs-xml/smbdotconf/security/serverrole.xml
@@ -51,9 +51,6 @@
exist as well as the account on the Domain Controller to allow
Samba to have a valid UNIX account to map file access to. Winbind can provide this.</para>
- <para>See also the section <link linkend="VALIDATIONSECT">
- NOTE ABOUT USERNAME/PASSWORD VALIDATION</link>.</para>
-
<para><anchor id="DC"/><emphasis>SERVER ROLE = DOMAIN CONTROLLER</emphasis></para>
<para>This mode of operation runs Samba as a domain controller, providing domain logon services to Windows and Samba clients of the domain. Clients must be joined to the domain to create a secure, trusted path across the network.</para>
diff --git a/docs-xml/smbdotconf/security/username.xml b/docs-xml/smbdotconf/security/username.xml
index 19d8a2ecfd..a85076c737 100644
--- a/docs-xml/smbdotconf/security/username.xml
+++ b/docs-xml/smbdotconf/security/username.xml
@@ -5,57 +5,16 @@
<synonym>user</synonym>
<synonym>users</synonym>
<description>
- <para>Multiple users may be specified in a comma-delimited
- list, in which case the supplied password will be tested against
- each username in turn (left to right).</para>
-
- <para>The deprecated <parameter moreinfo="none">username</parameter> line is needed only when
- the PC is unable to supply its own username. This is the case
- for the COREPLUS protocol or where your users have different WfWg
- usernames to UNIX usernames. In both these cases you may also be
- better using the \\server\share%user syntax instead.</para>
-
- <para>The <parameter moreinfo="none">username</parameter> line is not a great
- solution in many cases as it means Samba will try to validate
- the supplied password against each of the usernames in the
- <parameter moreinfo="none">username</parameter> line in turn. This is slow and
- a bad idea for lots of users in case of duplicate passwords.
- You may get timeouts or security breaches using this parameter
- unwisely.</para>
-
- <para>Samba relies on the underlying UNIX security. This
- parameter does not restrict who can login, it just offers hints
- to the Samba server as to what usernames might correspond to the
- supplied password. Users can login as whoever they please and
- they will be able to do no more damage than if they started a
- telnet session. The daemon runs as the user that they log in as,
- so they cannot do anything that user cannot do.</para>
-
<para>To restrict a service to a particular set of users you
can use the <smbconfoption name="valid users"/> parameter.</para>
- <para>If any of the usernames begin with a '@' then the name
- will be looked up first in the NIS netgroups list (if Samba
- is compiled with netgroup support), followed by a lookup in
- the UNIX groups database and will expand to a list of all users
- in the group of that name.</para>
-
- <para>If any of the usernames begin with a '+' then the name
- will be looked up only in the UNIX groups database and will
- expand to a list of all users in the group of that name.</para>
-
- <para>If any of the usernames begin with a '&amp;' then the name
- will be looked up only in the NIS netgroups database (if Samba
- is compiled with netgroup support) and will expand to a list
- of all users in the netgroup group of that name.</para>
+ <para>This parameter is deprecated</para>
- <para>Note that searching though a groups database can take
- quite some time, and some clients may time out during the
- search.</para>
+ <para>However, it currently operates only in conjunction with
+ <smbconfoption name="only user"/>. The supported way to restrict
+ a service to a particular set of users is the
+ <smbconfoption name="valid users"/> parameter.</para>
- <para>See the section <link linkend="VALIDATIONSECT">NOTE ABOUT
- USERNAME/PASSWORD VALIDATION</link> for more information on how
- this parameter determines access to the services.</para>
</description>
<value type="default"><comment>The guest account if a guest service,