summaryrefslogtreecommitdiff
path: root/docs-xml/manpages-3
diff options
context:
space:
mode:
authorAndrew Bartlett <abartlet@samba.org>2012-02-03 18:03:10 +1100
committerAndrew Bartlett <abartlet@samba.org>2012-03-04 23:33:05 +0100
commitd7bb961859a3501aec4d28842bfffb6190d19a73 (patch)
treee472b543e1e88914fbcf7bf68a3e431ff7314afd /docs-xml/manpages-3
parentacfa107ec64ceb6bf3a28df14585cfb0ccc79f41 (diff)
downloadsamba-d7bb961859a3501aec4d28842bfffb6190d19a73.tar.gz
samba-d7bb961859a3501aec4d28842bfffb6190d19a73.tar.bz2
samba-d7bb961859a3501aec4d28842bfffb6190d19a73.zip
s3-auth: Remove security=share (depricated since 3.6).
This patch removes security=share, which Samba implemented by matching the per-share password provided by the client in the Tree Connect with a selection of usernames supplied by the client, the smb.conf or guessed from the environment. The rationale for the removal is that for the bulk of security=share users, we just we need a very simple way to run a 'trust the network' Samba server, where users mark shares as guest ok. This is still supported, and the smb.conf options are documented at https://wiki.samba.org/index.php/Public_Samba_Server At the same time, this closes the door on one of the most arcane areas of Samba authentication. Naturally, full user-name/password authentication remain available in security=user and above. This includes documentation updates for username and only user, which now only do a small amount of what they used to do. Andrew Bartlett -------------- / \ / REST \ / IN \ / PEACE \ / \ | SEC_SHARE | | security=share | | | | | | 5 March | | | | 2012 | *| * * * | * _________)/\\_//(\/(/\)/\//\/\///|_)_______
Diffstat (limited to 'docs-xml/manpages-3')
-rw-r--r--docs-xml/manpages-3/smb.conf.5.xml53
1 files changed, 0 insertions, 53 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>