summaryrefslogtreecommitdiff
path: root/docs/smbdotconf/security/usernamemap.xml
diff options
context:
space:
mode:
authorJohn Terpstra <jht@samba.org>2005-10-22 00:04:38 +0000
committerGerald W. Carter <jerry@samba.org>2008-04-23 08:47:10 -0500
commitf88faa0105fdf47eccfa3212870ac3066ff8113c (patch)
tree3047258902356d4d4eff006087e3b8a3a1ad0659 /docs/smbdotconf/security/usernamemap.xml
parent90dd48edb48f0c3fdd52b2adcb206257a3de639a (diff)
downloadsamba-f88faa0105fdf47eccfa3212870ac3066ff8113c.tar.gz
samba-f88faa0105fdf47eccfa3212870ac3066ff8113c.tar.bz2
samba-f88faa0105fdf47eccfa3212870ac3066ff8113c.zip
Fixes and reformatting from Bug #3190, plus a clean-up.
(This used to be commit 8250e36fe34394938df16533f77869b93d3be761)
Diffstat (limited to 'docs/smbdotconf/security/usernamemap.xml')
-rw-r--r--docs/smbdotconf/security/usernamemap.xml166
1 files changed, 82 insertions, 84 deletions
diff --git a/docs/smbdotconf/security/usernamemap.xml b/docs/smbdotconf/security/usernamemap.xml
index c30e2327c5..59c0cdde7c 100644
--- a/docs/smbdotconf/security/usernamemap.xml
+++ b/docs/smbdotconf/security/usernamemap.xml
@@ -4,102 +4,102 @@
type="string"
xmlns:samba="http://www.samba.org/samba/DTD/samba-doc">
<description>
- <para>This option allows you to specify a file containing
- a mapping of usernames from the clients to the server. This can be
- used for several purposes. The most common is to map usernames
- that users use on DOS or Windows machines to those that the UNIX
- box uses. The other is to map multiple users to a single username
- so that they can more easily share files.</para>
-
- <para>Please note that for user or share mode security, the
- username map is applied prior to validating the user credentials.
- Domain member servers (domain or ads) apply the username map
- after the user has been successfully authenticated by the domain
- controller and require fully qualified enties in the map table
- (e.g. biddle = DOMAIN\foo).</para>
-
- <para>The map file is parsed line by line. Each line should
- contain a single UNIX username on the left then a '=' followed
- by a list of usernames on the right. The list of usernames on the
- right may contain names of the form @group in which case they
- will match any UNIX username in that group. The special client
- name '*' is a wildcard and matches any name. Each line of the
- map file may be up to 1023 characters long.</para>
-
- <para>The file is processed on each line by taking the
- supplied username and comparing it with each username on the right
- hand side of the '=' signs. If the supplied name matches any of
- the names on the right hand side then it is replaced with the name
- on the left. Processing then continues with the next line.</para>
-
- <para>If any line begins with a '#' or a ';' then it is ignored</para>
-
- <para>If any line begins with an '!' then the processing
- will stop after that line if a mapping was done by the line.
- Otherwise mapping continues with every line being processed.
- Using '!' is most useful when you have a wildcard mapping line
- later in the file.</para>
-
- <para>For example to map from the name <constant>admin</constant>
- or <constant>administrator</constant> to the UNIX name <constant>
- root</constant> you would use:</para>
-
- <para><command moreinfo="none">root = admin administrator</command></para>
+ <para>
+ This option allows you to specify a file containing a mapping of usernames from the clients to the server.
+ This can be used for several purposes. The most common is to map usernames that users use on DOS or Windows
+ machines to those that the UNIX box uses. The other is to map multiple users to a single username so that they
+ can more easily share files.
+ </para>
- <para>Or to map anyone in the UNIX group <constant>system</constant>
- to the UNIX name <constant>sys</constant> you would use:</para>
+ <para>
+ Please note that for user or share mode security, the username map is applied prior to validating the user
+ credentials. Domain member servers (domain or ads) apply the username map after the user has been
+ successfully authenticated by the domain controller and require fully qualified enties in the map table (e.g.
+ biddle = DOMAIN\foo).
+ </para>
+
+ <para>
+ The map file is parsed line by line. Each line should contain a single UNIX username on the left then a '='
+ followed by a list of usernames on the right. The list of usernames on the right may contain names of the form
+ @group in which case they will match any UNIX username in that group. The special client name '*' is a
+ wildcard and matches any name. Each line of the map file may be up to 1023 characters long.
+ </para>
- <para><command moreinfo="none">sys = @system</command></para>
+ <para>
+ The file is processed on each line by taking the supplied username and comparing it with each username on the
+ right hand side of the '=' signs. If the supplied name matches any of the names on the right hand side then it
+ is replaced with the name on the left. Processing then continues with the next line.
+ </para>
- <para>You can have as many mappings as you like in a username map file.</para>
+ <para>
+ If any line begins with a '#' or a ';' then it is ignored.
+ </para>
+ <para>
+ If any line begins with an '!' then the processing will stop after that line if a mapping was done by the
+ line. Otherwise mapping continues with every line being processed. Using '!' is most useful when you have a
+ wildcard mapping line later in the file.
+ </para>
- <para>If your system supports the NIS NETGROUP option then
- the netgroup database is checked before the <filename moreinfo="none">/etc/group
- </filename> database for matching groups.</para>
+ <para>
+ For example to map from the name <constant>admin</constant> or <constant>administrator</constant> to the UNIX
+ name <constant> root</constant> you would use:
+<programlisting>
+<command moreinfo="none">root = admin administrator</command>
+</programlisting>
+ Or to map anyone in the UNIX group <constant>system</constant> to the UNIX name <constant>sys</constant> you would use:
+<programlisting>
+<command moreinfo="none">sys = @system</command>
+</programlisting>
+ </para>
- <para>You can map Windows usernames that have spaces in them
- by using double quotes around the name. For example:</para>
+ <para>
+ You can have as many mappings as you like in a username map file.
+ </para>
- <para><command moreinfo="none">tridge = &quot;Andrew Tridgell&quot;</command></para>
- <para>would map the windows username &quot;Andrew Tridgell&quot; to the
- unix username &quot;tridge&quot;.</para>
+ <para>
+ If your system supports the NIS NETGROUP option then the netgroup database is checked before the <filename
+ moreinfo="none">/etc/group </filename> database for matching groups.
+ </para>
- <para>The following example would map mary and fred to the
- unix user sys, and map the rest to guest. Note the use of the
- '!' to tell Samba to stop processing if it gets a match on
- that line.</para>
+ <para>
+ You can map Windows usernames that have spaces in them by using double quotes around the name. For example:
+<programlisting>
+<command moreinfo="none">tridge = &quot;Andrew Tridgell&quot;</command>
+</programlisting>
+ would map the windows username &quot;Andrew Tridgell&quot; to the unix username &quot;tridge&quot;.
+ </para>
-<para><programlisting format="linespecific">
+ <para>
+ The following example would map mary and fred to the unix user sys, and map the rest to guest. Note the use of the
+ '!' to tell Samba to stop processing if it gets a match on that line:
+<programlisting format="linespecific">
!sys = mary fred
guest = *
-</programlisting></para>
+</programlisting>
+ </para>
<para>
- Note that the remapping is applied to all occurrences
- of usernames. Thus if you connect to \\server\fred and <constant>
- fred</constant> is remapped to <constant>mary</constant> then you
- will actually be connecting to \\server\mary and will need to
- supply a password suitable for <constant>mary</constant> not
- <constant>fred</constant>. The only exception to this is the
- username passed to the <smbconfoption name="password server"/>
- (if you have one). The password server will receive whatever
- username the client supplies without modification.
+ Note that the remapping is applied to all occurrences of usernames. Thus if you connect to \\server\fred and
+ <constant>fred</constant> is remapped to <constant>mary</constant> then you will actually be connecting to
+ \\server\mary and will need to supply a password suitable for <constant>mary</constant> not
+ <constant>fred</constant>. The only exception to this is the username passed to the <smbconfoption
+ name="password server"/> (if you have one). The password server will receive whatever username the client
+ supplies without modification.
</para>
- <para>Also note that no reverse mapping is done. The main effect
- this has is with printing. Users who have been mapped may have
- trouble deleting print jobs as PrintManager under WfWg will think
- they don't own the print job.</para>
+ <para>
+ Also note that no reverse mapping is done. The main effect this has is with printing. Users who have been
+ mapped may have trouble deleting print jobs as PrintManager under WfWg will think they don't own the print
+ job.
+ </para>
<para>
- Samba versions prior to 3.0.8 would only support reading the fully qualified
- username (e.g.: DOMAIN\user) from the username map when performing a
- kerberos login from a client. However, when looking up a map
- entry for a user authenticated by NTLM[SSP], only the login name would be
- used for matches. This resulted in inconsistent behavior sometimes
- even on the same server.
+ Samba versions prior to 3.0.8 would only support reading the fully qualified username (e.g.: DOMAIN\user) from
+ the username map when performing a kerberos login from a client. However, when looking up a map entry for a
+ user authenticated by NTLM[SSP], only the login name would be used for matches. This resulted in inconsistent
+ behavior sometimes even on the same server.
</para>
<para>
@@ -107,16 +107,13 @@ guest = *
</para>
<para>
- When performing local authentication, the username map is
- applied to the login name before attempting to authenticate
+ When performing local authentication, the username map is applied to the login name before attempting to authenticate
the connection.
</para>
<para>
- When relying upon a external domain controller for validating
- authentication requests, smbd will apply the username map
- to the fully qualified username (i.e. DOMAIN\user) only
- after the user has been successfully authenticated.
+ When relying upon a external domain controller for validating authentication requests, smbd will apply the username map
+ to the fully qualified username (i.e. DOMAIN\user) only after the user has been successfully authenticated.
</para>
<para>
@@ -125,6 +122,7 @@ guest = *
username map = /usr/local/samba/lib/users.map
</programlisting>
</para>
+
</description>
<value type="default"><comment>no username map</comment></value>