diff options
Diffstat (limited to 'docs-xml')
32 files changed, 481 insertions, 451 deletions
diff --git a/docs-xml/manpages-3/idmap_ad.8.xml b/docs-xml/manpages-3/idmap_ad.8.xml index 3ecb07e590c..fbadaf2d55c 100644 --- a/docs-xml/manpages-3/idmap_ad.8.xml +++ b/docs-xml/manpages-3/idmap_ad.8.xml @@ -34,7 +34,7 @@ to configure it separately for each domain for which one wants to use it, using disjoint ranges. One usually needs to configure a writeable default idmap range, using for example the - <parameter>tdb</parameter> or <parameter>ldap</parameter>) + <parameter>tdb</parameter> or <parameter>ldap</parameter> backend, in order to be able to map the BUILTIN sids and possibly other trusted domains. The writeable default config is also needed in order to be able to create group mappings. @@ -85,9 +85,8 @@ <programlisting> [global] - idmap backend = tdb - idmap uid = 1000000-1999999 - idmap gid = 1000000-1999999 + idmap config * : backend = tdb + idmap config * : range = 1000000-1999999 idmap config CORP : backend = ad idmap config CORP : range = 1000-999999 diff --git a/docs-xml/manpages-3/idmap_adex.8.xml b/docs-xml/manpages-3/idmap_adex.8.xml index 7349caa61e3..16d12cdbbc9 100644 --- a/docs-xml/manpages-3/idmap_adex.8.xml +++ b/docs-xml/manpages-3/idmap_adex.8.xml @@ -66,9 +66,8 @@ <programlisting> [global] - idmap backend = adex - idmap uid = 1000-4000000000 - idmap gid = 1000-4000000000 + idmap config * : backend = adex + idmap config * : range = 1000-4000000000 winbind nss info = adex winbind normalize names = yes diff --git a/docs-xml/manpages-3/idmap_autorid.8.xml b/docs-xml/manpages-3/idmap_autorid.8.xml index 38790ea2b04..b5a9bde2e66 100644 --- a/docs-xml/manpages-3/idmap_autorid.8.xml +++ b/docs-xml/manpages-3/idmap_autorid.8.xml @@ -88,9 +88,8 @@ workgroup = CUSTOMER realm = CUSTOMER.COM - idmap backend = autorid - idmap uid = 1000000-1999999 - idmap gid = 1000000-1999999 + idmap config * : backend = autorid + idmap config * : range = 1000000-1999999 </programlisting> @@ -98,7 +97,7 @@ This example shows how to configure idmap_autorid as default for all domains with a potentially large amount of users plus a specific configuration for a trusted domain - that uses the SFU mapping scheme. Please note that idmap uid/gid + that uses the SFU mapping scheme. Please note that idmap ranges and sfu ranges are not allowed to overlap. </para> @@ -108,10 +107,9 @@ workgroup = CUSTOMER realm = CUSTOMER.COM - idmap backend = autorid - autorid:rangesize = 1000000 - idmap uid = 1000000-19999999 - idmap gid = 1000000-19999999 + idmap config * : backend = autorid + idmap config * : range = 1000000-19999999 + idmap config * : rangesize = 1000000 idmap config TRUSTED : backend = ad idmap config TRUSTED : range = 50000 - 99999 diff --git a/docs-xml/manpages-3/idmap_hash.8.xml b/docs-xml/manpages-3/idmap_hash.8.xml index 2bbae713544..f3ec6a7bc25 100644 --- a/docs-xml/manpages-3/idmap_hash.8.xml +++ b/docs-xml/manpages-3/idmap_hash.8.xml @@ -52,9 +52,8 @@ <programlisting> [global] - idmap backend = hash - idmap uid = 1000-4000000000 - idmap gid = 1000-4000000000 + idmap config * : backend = hash + idmap config * : range = 1000-4000000000 winbind nss info = hash winbind normalize names = yes diff --git a/docs-xml/manpages-3/idmap_ldap.8.xml b/docs-xml/manpages-3/idmap_ldap.8.xml index e3588b95bcf..2c0fcfd17c6 100644 --- a/docs-xml/manpages-3/idmap_ldap.8.xml +++ b/docs-xml/manpages-3/idmap_ldap.8.xml @@ -27,26 +27,9 @@ <para> In contrast to read only backends like idmap_rid, it is an allocating backend: This means that it needs to allocate new user and group IDs in - order to create new mappings. The allocator can be provided by the - idmap_ldap backend itself or by any other allocating backend like - idmap_tdb or idmap_tdb2. This is configured with the - parameter <parameter>idmap alloc backend</parameter>. + order to create new mappings. </para> - <para> - Note that in order for this (or any other allocating) backend to - function at all, the default backend needs to be writeable. - The ranges used for uid and gid allocation are the default ranges - configured by "idmap uid" and "idmap gid". - </para> - - <para> - Furthermore, since there is only one global allocating backend - responsible for all domains using writeable idmap backends, - any explicitly configured domain with idmap backend ldap - should have the same range as the default range, since it needs - to use the global uid / gid allocator. See the example below. - </para> </refsynopsisdiv> <refsect1> @@ -56,7 +39,7 @@ <varlistentry> <term>ldap_base_dn = DN</term> <listitem><para> - Defines the directory base suffix to use when searching for + Defines the directory base suffix to use for SID/uid/gid mapping entries. If not defined, idmap_ldap will default to using the "ldap idmap suffix" option from smb.conf. </para></listitem> @@ -65,15 +48,21 @@ <varlistentry> <term>ldap_user_dn = DN</term> <listitem><para> - Defines the user DN to be used for authentication. If absent an - anonymous bind will be performed. + Defines the user DN to be used for authentication. + The secret for authenticating this user should be + stored with net idmap secret + (see <citerefentry><refentrytitle>net</refentrytitle> + <manvolnum>8</manvolnum></citerefentry>). + If absent, the ldap credentials from the ldap passdb configuration + are used, and if these are also absent, an anonymous + bind will be performed as last fallback. </para></listitem> </varlistentry> <varlistentry> <term>ldap_url = ldap://server/</term> <listitem><para> - Specifies the LDAP server to use when searching for existing + Specifies the LDAP server to use for SID/uid/gid map entries. If not defined, idmap_ldap will assume that ldap://localhost/ should be used. </para></listitem> @@ -84,64 +73,50 @@ <listitem><para> Defines the available matching uid and gid range for which the backend is authoritative. - If the parameter is absent, Winbind fails over to use the - "idmap uid" and "idmap gid" options - from smb.conf. </para></listitem> </varlistentry> </variablelist> </refsect1> <refsect1> - <title>IDMAP ALLOC OPTIONS</title> - - <variablelist> - <varlistentry> - <term>ldap_base_dn = DN</term> - <listitem><para> - Defines the directory base suffix under which new SID/uid/gid mapping - entries should be stored. If not defined, idmap_ldap will default - to using the "ldap idmap suffix" option from smb.conf. - </para></listitem> - </varlistentry> - - <varlistentry> - <term>ldap_user_dn = DN</term> - <listitem><para> - Defines the user DN to be used for authentication. If absent an - anonymous bind will be performed. - </para></listitem> - </varlistentry> - - <varlistentry> - <term>ldap_url = ldap://server/</term> - <listitem><para> - Specifies the LDAP server to which modify/add/delete requests should - be sent. If not defined, idmap_ldap will assume that ldap://localhost/ - should be used. - </para></listitem> - </varlistentry> - </variablelist> -</refsect1> - -<refsect1> <title>EXAMPLES</title> <para> - The follow sets of a LDAP configuration which uses two LDAP - directories, one for storing the ID mappings and one for retrieving - new IDs. + The following example shows how an ldap directory is used as the + default idmap backend. It also configures the idmap range and base + directory suffix. The secret for the ldap_user_dn has to be set with + "net idmap secret '*' password". </para> <programlisting> [global] - idmap backend = ldap:ldap://localhost/ - idmap uid = 1000000-1999999 - idmap gid = 1000000-1999999 + idmap config * : backend = ldap + idmap config * : range = 1000000-1999999 + idmap config * : ldap_url = ldap://localhost/ + idmap config * : ldap_base_dn = ou=idmap,dc=example,dc=com + idmap config * : ldap_user_dn = cn=idmap_admin,dc=example,dc=com + </programlisting> + + <para> + This example shows how ldap can be used as a readonly backend while + tdb is the default backend used to store the mappings. + It adds an explicit configuration for some domain DOM1, that + uses the ldap idmap backend. Note that a range disjoint from the + default range is used. + </para> - idmap alloc backend = ldap - idmap alloc config : ldap_url = ldap://id-master/ - idmap alloc config : ldap_base_dn = ou=idmap,dc=example,dc=com + <programlisting> + [global] + # "backend = tdb" is redundant here since it is the default + idmap config * : backend = tdb + idmap config * : range = 1000000-1999999 + + idmap config DOM1 : backend = ldap + idmap config DOM1 : range = 2000000-2999999 + idmap config DOM1 : read only = yes + idmap config DOM1 : ldap_url = ldap://server/ + idmap config DOM1 : ldap_base_dn = ou=idmap,dc=dom1,dc=example,dc=com + idmap config DOM1 : ldap_user_dn = cn=idmap_admin,dc=dom1,dc=example,dc=com </programlisting> </refsect1> diff --git a/docs-xml/manpages-3/idmap_nss.8.xml b/docs-xml/manpages-3/idmap_nss.8.xml index a7fdca033b1..576eef666a9 100644 --- a/docs-xml/manpages-3/idmap_nss.8.xml +++ b/docs-xml/manpages-3/idmap_nss.8.xml @@ -38,9 +38,8 @@ <programlisting> [global] - idmap backend = tdb - idmap uid = 1000000-1999999 - idmap gid = 1000000-1999999 + idmap config * : backend = tdb + idmap config * : range = 1000000-1999999 idmap config SAMBA : backend = nss idmap config SAMBA : range = 1000-999999 diff --git a/docs-xml/manpages-3/idmap_rid.8.xml b/docs-xml/manpages-3/idmap_rid.8.xml index a2a1c58a6f4..3f8735288ca 100644 --- a/docs-xml/manpages-3/idmap_rid.8.xml +++ b/docs-xml/manpages-3/idmap_rid.8.xml @@ -28,7 +28,7 @@ Currently, there should to be an explicit idmap configuration for each domain that should use the idmap_rid backend, using disjoint ranges. One usually needs to define a writeable default idmap range, using - a backent like <parameter>tdb</parameter> or <parameter>ldap</parameter> + a backend like <parameter>tdb</parameter> or <parameter>ldap</parameter> that can create unix ids, in order to be able to map the BUILTIN sids and other domains, and also in order to be able to create group mappings. See the example below. @@ -106,9 +106,8 @@ security = domain workgroup = MAIN - idmap backend = tdb - idmap uid = 1000000-1999999 - idmap gid = 1000000-1999999 + idmap config * : backend = tdb + idmap config * : range = 1000000-1999999 idmap config MAIN : backend = rid idmap config MAIN : range = 10000 - 49999 diff --git a/docs-xml/manpages-3/idmap_tdb.8.xml b/docs-xml/manpages-3/idmap_tdb.8.xml index 06a29679c85..c67d6cb9bc2 100644 --- a/docs-xml/manpages-3/idmap_tdb.8.xml +++ b/docs-xml/manpages-3/idmap_tdb.8.xml @@ -27,25 +27,7 @@ <para> In contrast to read only backends like idmap_rid, it is an allocating backend: This means that it needs to allocate new user and group IDs in - order to create new mappings. The allocator can be provided by the - idmap_tdb backend itself or by any other allocating backend like - idmap_ldap or idmap_tdb2. This is configured with the - parameter <parameter>idmap alloc backend</parameter>. - </para> - - <para> - Note that in order for this (or any other allocating) backend to - function at all, the default backend needs to be writeable. - The ranges used for uid and gid allocation are the default ranges - configured by "idmap uid" and "idmap gid". - </para> - - <para> - Furthermore, since there is only one global allocating backend - responsible for all domains using writeable idmap backends, - any explicitly configured domain with idmap backend tdb - should have the same range as the default range, since it needs - to use the global uid / gid allocator. See the example below. + order to create new mappings. </para> </refsynopsisdiv> @@ -58,9 +40,6 @@ <listitem><para> Defines the available matching uid and gid range for which the backend is authoritative. - If the parameter is absent, Winbind fails over to use - the "idmap uid" and "idmap gid" options - from smb.conf. </para></listitem> </varlistentry> </variablelist> @@ -71,38 +50,14 @@ <para> This example shows how tdb is used as a the default idmap backend. - It configures the idmap range through the global options for all - domains encountered. This same range is used for uid/gid allocation. - </para> - - <programlisting> - [global] - # "idmap backend = tdb" is redundant here since it is the default - idmap backend = tdb - idmap uid = 1000000-2000000 - idmap gid = 1000000-2000000 - </programlisting> - - <para> - This (rather theoretical) example shows how tdb can be used as the - allocating backend while ldap is the default backend used to store - the mappings. - It adds an explicit configuration for some domain DOM1, that - uses the tdb idmap backend. Note that the same range as the - default uid/gid range is used, since the allocator has to serve - both the default backend and the explicitly configured domain DOM1. + This configured range is used for uid and gid allocation. </para> <programlisting> [global] - idmap backend = ldap - idmap uid = 1000000-2000000 - idmap gid = 1000000-2000000 - # use a different uid/gid allocator: - idmap alloc backend = tdb - - idmap config DOM1 : backend = tdb - idmap config DOM1 : range = 1000000-2000000 + # "backend = tdb" is redundant here since it is the default + idmap config * : backend = tdb + idmap config * : range = 1000000-2000000 </programlisting> </refsect1> diff --git a/docs-xml/manpages-3/idmap_tdb2.8.xml b/docs-xml/manpages-3/idmap_tdb2.8.xml index a5d1080474e..980ffe6eff8 100644 --- a/docs-xml/manpages-3/idmap_tdb2.8.xml +++ b/docs-xml/manpages-3/idmap_tdb2.8.xml @@ -28,25 +28,7 @@ <para> In contrast to read only backends like idmap_rid, it is an allocating backend: This means that it needs to allocate new user and group IDs in - order to create new mappings. The allocator can be provided by the - idmap_tdb2 backend itself or by any other allocating backend like - idmap_tdb or idmap_ldap. This is configured with the - parameter <parameter>idmap alloc backend</parameter>. - </para> - - <para> - Note that in order for this (or any other allocating) backend to - function at all, the default backend needs to be writeable. - The ranges used for uid and gid allocation are the default ranges - configured by "idmap uid" and "idmap gid". - </para> - - <para> - Furthermore, since there is only one global allocating backend - responsible for all domains using writeable idmap backends, - any explicitly configured domain with idmap backend tdb2 - should have the same range as the default range, since it needs - to use the global uid / gid allocator. See the example below. + order to create new mappings. </para> </refsynopsisdiv> @@ -59,9 +41,6 @@ <listitem><para> Defines the available matching uid and gid range for which the backend is authoritative. - If the parameter is absent, Winbind fails over to use - the "idmap uid" and "idmap gid" options - from smb.conf. </para></listitem> </varlistentry> </variablelist> @@ -108,14 +87,13 @@ <para> This example shows how tdb2 is used as a the default idmap backend. It configures the idmap range through the global options for all - domains encountered. This same range is used for uid/gid allocation. + domains encountered. </para> <programlisting> [global] - idmap backend = tdb2 - idmap uid = 1000000-2000000 - idmap gid = 1000000-2000000 + idmap config * : backend = tdb2 + idmap config * : range = 1000000-2000000 </programlisting> </refsect1> diff --git a/docs-xml/manpages-3/net.8.xml b/docs-xml/manpages-3/net.8.xml index d69a3b72205..2c6c11ecf84 100644 --- a/docs-xml/manpages-3/net.8.xml +++ b/docs-xml/manpages-3/net.8.xml @@ -795,8 +795,122 @@ appear in your system. <para>List all interdomain trust relationships.</para> </refsect3> +</refsect2> + +<refsect2> +<title>RPC TRUST</title> + +<refsect3> +<title>RPC TRUST CREATE</title> + +<para>Create a trust object by calling lsaCreateTrustedDomainEx2. +The can be done on a single server or on two servers at once with the +possibility to use a random trust password.</para> + +<variablelist><title>Options:</title> +<varlistentry> +<term>otherserver</term> +<listitem><para>Domain controller of the second domain</para></listitem> +</varlistentry> + +<varlistentry> +<term>otheruser</term> +<listitem><para>Admin user in the second domain</para></listitem> +</varlistentry> + +<varlistentry> +<term>otherdomainsid</term> +<listitem><para>SID of the second domain</para></listitem> +</varlistentry> + +<varlistentry> +<term>other_netbios_domain</term> +<listitem><para>NetBIOS (short) name of the second domain</para></listitem> +</varlistentry> + +<varlistentry> +<term>otherdomain</term> +<listitem><para>DNS (full) name of the second domain</para></listitem> +</varlistentry> + +<varlistentry> +<term>trustpw</term> +<listitem><para>Trust password</para></listitem> +</varlistentry> +</variablelist> + +<variablelist><title>Examples:</title> +<varlistentry> +<term>Create a trust object on srv1.dom1.dom for the domain dom2</term> +<listitem><literallayout> +net rpc trust create \ + otherdomainsid=S-x-x-xx-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxx \ + other_netbios_domain=dom2 \ + otherdomain=dom2.dom \ + trustpw=12345678 \ + -S srv1.dom1.dom +</literallayout></listitem> +</varlistentry> +<varlistentry> +<term>Create a trust relationship between dom1 and dom2</term> +<listitem><literallayout> +net rpc trust create \ + otherserver=srv2.dom2.test \ + otheruser=dom2adm \ + -S srv1.dom1.dom +</literallayout></listitem> +</varlistentry> +</variablelist> +</refsect3> <refsect3> +<title>RPC TRUST DELETE</title> + +<para>Delete a trust trust object by calling lsaDeleteTrustedDomain. +The can be done on a single server or on two servers at once.</para> + +<variablelist><title>Options:</title> +<varlistentry> +<term>otherserver</term> +<listitem><para>Domain controller of the second domain</para></listitem> +</varlistentry> + +<varlistentry> +<term>otheruser</term> +<listitem><para>Admin user in the second domain</para></listitem> +</varlistentry> + +<varlistentry> +<term>otherdomainsid</term> +<listitem><para>SID of the second domain</para></listitem> +</varlistentry> +</variablelist> + +<variablelist><title>Examples:</title> +<varlistentry> +<term>Delete a trust object on srv1.dom1.dom for the domain dom2</term> +<listitem><literallayout> +net rpc trust delete \ + otherdomainsid=S-x-x-xx-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxx \ + -S srv1.dom1.dom +</literallayout></listitem> +</varlistentry> +<varlistentry> +<term>Delete a trust relationship between dom1 and dom2</term> +<listitem><literallayout> +net rpc trust delete \ + otherserver=srv2.dom2.test \ + otheruser=dom2adm \ + -S srv1.dom1.dom +</literallayout></listitem> +</varlistentry> +</variablelist> +</refsect3> + +</refsect2> + +<refsect2> +<refsect3> <title>RPC RIGHTS</title> <para>This subcommand is used to view and manage Samba's rights assignments (also @@ -1734,8 +1848,10 @@ Manipulate Samba's registry. <para>The registry commands are: <simplelist> <member>net registry enumerate - Enumerate registry keys and values.</member> +<member>net registry enumerate_recursive - Enumerate registry key and its subkeys.</member> <member>net registry createkey - Create a new registry key.</member> <member>net registry deletekey - Delete a registry key.</member> +<member>net registry deletekey_recursive - Delete a registry key with subkeys.</member> <member>net registry getvalue - Print a registry value.</member> <member>net registry getvalueraw - Print a registry value (raw format).</member> <member>net registry setvalue - Set a new registry value.</member> @@ -1758,7 +1874,13 @@ string.</member> <refsect3> <title>REGISTRY ENUMERATE <replaceable>key</replaceable> </title> - <para>Enumerate subkeys and values of <emphasis>key</emphasis> + <para>Enumerate subkeys and values of <emphasis>key</emphasis>. + </para> +</refsect3> + +<refsect3> + <title>REGISTRY ENUMERATE_RECURSIVE <replaceable>key</replaceable> </title> + <para>Enumerate values of <emphasis>key</emphasis> and its subkeys. </para> </refsect3> @@ -1770,6 +1892,13 @@ string.</member> <refsect3> <title>REGISTRY DELETEKEY <replaceable>key</replaceable> </title> + <para>Delete the given <emphasis>key</emphasis> and its + values from the registry, if it has no subkeys. + </para> +</refsect3> + +<refsect3> + <title>REGISTRY DELETEKEY_RECURSIVE <replaceable>key</replaceable> </title> <para>Delete the given <emphasis>key</emphasis> and all of its subkeys and values from the registry. </para> diff --git a/docs-xml/manpages-3/smb.conf.5.xml b/docs-xml/manpages-3/smb.conf.5.xml index 2b930654436..f5f252ba46d 100644 --- a/docs-xml/manpages-3/smb.conf.5.xml +++ b/docs-xml/manpages-3/smb.conf.5.xml @@ -503,12 +503,16 @@ chmod 1770 /usr/local/samba/lib/usershares <varlistentry> <term>%I</term> <listitem><para>the IP address of the client machine.</para> + <para>Before 3.6.0 it could contain IPv4 mapped IPv6 addresses, + now it only contains IPv4 or IPv6 addresses.</para> </listitem> </varlistentry> <varlistentry> <term>%i</term> <listitem><para>the local IP address to which a client connected.</para> + <para>Before 3.6.0 it could contain IPv4 mapped IPv6 addresses, + now it only contains IPv4 or IPv6 addresses.</para> </listitem> </varlistentry> diff --git a/docs-xml/manpages-3/vfs_gpfs.8.xml b/docs-xml/manpages-3/vfs_gpfs.8.xml index 5f89ffac779..a6b31240eea 100644 --- a/docs-xml/manpages-3/vfs_gpfs.8.xml +++ b/docs-xml/manpages-3/vfs_gpfs.8.xml @@ -276,6 +276,26 @@ </listitem> </varlistentry> + <varlistentry> + <term>gpfs:syncio = [yes|no]</term> + <listitem> + <para>This parameter makes Samba open all files with O_SYNC. + This triggers optimizations in GPFS for workloads that + heavily share files.</para> + + <para>Following is the behaviour of Samba for different + values: + </para> + <itemizedlist> + <listitem><para><command>yes</command>Open files with O_SYNC + </para></listitem> + <listitem><para><command>no (default)</command>Open files as + normal Samba would do + </para></listitem> + </itemizedlist> + </listitem> + </varlistentry> + </variablelist> </refsect1> diff --git a/docs-xml/manpages-3/vfs_smb_traffic_analyzer.8.xml b/docs-xml/manpages-3/vfs_smb_traffic_analyzer.8.xml index 882ee6af3f8..8df9751aa4d 100644 --- a/docs-xml/manpages-3/vfs_smb_traffic_analyzer.8.xml +++ b/docs-xml/manpages-3/vfs_smb_traffic_analyzer.8.xml @@ -45,6 +45,8 @@ protocol, supporting only a small list of VFS operations, and had several drawbacks. The protocol version 2 is a try to solve the problems version 1 had while at the same time adding new features. + With the release of Samba 3.6.0, the module will run protocol version 2 + by default. </para> </refsect1> @@ -77,6 +79,7 @@ <listitem><para><command>SHARE</command> - the name of the share on which the VFS operation occured</para></listitem> <listitem><para><command>FILENAME</command> - the name of the file that was used by the VFS operation</para></listitem> <listitem><para><command>TIMESTAMP</command> - a timestamp, formatted as "yyyy-mm-dd hh-mm-ss.ms" indicating when the VFS operation occured</para></listitem> + <listitem><para><command>IP</command> - The IP Address (v4 or v6) of the client machine that initiated the VFS operation.</para></listitem> </itemizedlist> </para> @@ -136,7 +139,7 @@ The module now can identify itself against the receiver with a sub-release number, where the receiver may run with a different sub-release number than the module. However, as long as both run on the V2.x protocol, the receiver will not crash, even if the module - uses features only implemented in the newer subrelease. Ultimativly, if the module uses + uses features only implemented in the newer subrelease. Ultimatively, if the module uses a new feature from a newer subrelease, and the receiver runs an older protocol, it is just ignoring the functionality. Of course it is best to have both the receiver and the module running the same subrelease of the protocol. @@ -150,7 +153,7 @@ </listitem> <listitem> <para> - The module now potientially has the ability to create data on every VFS function. As of + The module now potentially has the ability to create data on every VFS function. As of protocol V2.0, there is support for 8 VFS functions, namely write,read,pread,pwrite, rename,chdir,mkdir and rmdir. Supporting more VFS functions is one of the targets for the upcoming sub-releases. @@ -224,9 +227,9 @@ <varlistentry> <term>smb_traffic_analyzer:protocol_version = STRING</term> <listitem> - <para>If STRING matches to V1 or is not given at all, the module - will use version 1 of the protocol. If STRING matches to "V2" - the module will use version 2 of the protocol. + <para>If STRING matches to V1, the module will use version 1 of the + protocol. If STRING is not given, the module will use version 2 of the + protocol, which is the default. </para> </listitem> </varlistentry> @@ -241,7 +244,6 @@ <smbconfsection name="[example_share]"/> <smbconfoption name="path">/data/example</smbconfoption> <smbconfoption name="vfs_objects">smb_traffic_analyzer</smbconfoption> - <smbconfoption name="smb_traffic_analyzer:protocol_version">V2</smbconfoption> <smbconfoption name="smb_traffic_analyzer:host">examplehost</smbconfoption> <smbconfoption name="smb_traffic_analyzer:port">3491</smbconfoption> </programlisting> diff --git a/docs-xml/manpages-3/wbinfo.1.xml b/docs-xml/manpages-3/wbinfo.1.xml index c1b2c1f6278..0701d08a56d 100644 --- a/docs-xml/manpages-3/wbinfo.1.xml +++ b/docs-xml/manpages-3/wbinfo.1.xml @@ -423,7 +423,7 @@ <term>-U|--uid-to-sid <replaceable>uid</replaceable></term> <listitem><para>Try to convert a UNIX user id to a Windows NT SID. If the uid specified does not refer to one within - the idmap uid range then the operation will fail. </para></listitem> + the idmap range then the operation will fail. </para></listitem> </varlistentry> <varlistentry> diff --git a/docs-xml/manpages-3/winbindd.8.xml b/docs-xml/manpages-3/winbindd.8.xml index c9fd4d8e656..df44e4437d9 100644 --- a/docs-xml/manpages-3/winbindd.8.xml +++ b/docs-xml/manpages-3/winbindd.8.xml @@ -45,10 +45,9 @@ <para>Even if winbind is not used for nsswitch, it still provides a service to <command>smbd</command>, <command>ntlm_auth</command> and the <command>pam_winbind.so</command> PAM module, by managing connections to - domain controllers. In this configuraiton the - <smbconfoption name="idmap uid"/> and - <smbconfoption name="idmap gid"/> - parameters are not required. (This is known as `netlogon proxy only mode'.)</para> + domain controllers. In this configuration the + <smbconfoption name="idmap config * : range"/> + parameter is not required. (This is known as `netlogon proxy only mode'.)</para> <para> The Name Service Switch allows user and system information to be obtained from different databases @@ -246,11 +245,9 @@ hosts: files wins <listitem><para> <smbconfoption name="winbind separator"/></para></listitem> <listitem><para> - <smbconfoption name="idmap uid"/></para></listitem> + <smbconfoption name="idmap config * : range"/></para></listitem> <listitem><para> - <smbconfoption name="idmap gid"/></para></listitem> - <listitem><para> - <smbconfoption name="idmap backend"/></para></listitem> + <smbconfoption name="idmap config * : backend"/></para></listitem> <listitem><para> <smbconfoption name="winbind cache time"/></para></listitem> <listitem><para> @@ -340,8 +337,7 @@ auth required /lib/security/pam_unix.so \ winbind cache time = 10 template shell = /bin/bash template homedir = /home/%D/%U - idmap uid = 10000-20000 - idmap gid = 10000-20000 + idmap config * : range = 10000-20000 workgroup = DOMAIN security = domain password server = * @@ -374,7 +370,7 @@ auth required /lib/security/pam_unix.so \ <para>If more than one UNIX machine is running <command>winbindd</command>, then in general the user and groups ids allocated by winbindd will not be the same. The user and group ids will only be valid for the local - machine, unless a shared <smbconfoption name="idmap backend"/> is configured.</para> + machine, unless a shared <smbconfoption name="idmap config * : backend"/> is configured.</para> <para>If the the Windows NT SID to UNIX user and group id mapping file is damaged or destroyed then the mappings will be lost. </para> diff --git a/docs-xml/smbdotconf/logon/enableprivileges.xml b/docs-xml/smbdotconf/logon/enableprivileges.xml index 3e958e0ce9a..0fbc504c526 100644 --- a/docs-xml/smbdotconf/logon/enableprivileges.xml +++ b/docs-xml/smbdotconf/logon/enableprivileges.xml @@ -5,7 +5,7 @@ xmlns:samba="http://www.samba.org/samba/DTD/samba-doc"> <description> <para> - This parameter controls whether or not smbd will honor privileges assigned to specific SIDs via either + This deprecated parameter controls whether or not smbd will honor privileges assigned to specific SIDs via either <command>net rpc rights</command> or one of the Windows user and group manager tools. This parameter is enabled by default. It can be disabled to prevent members of the Domain Admins group from being able to assign privileges to users or groups which can then result in certain smbd operations running as root that diff --git a/docs-xml/smbdotconf/misc/asyncsmbechohandler.xml b/docs-xml/smbdotconf/misc/asyncsmbechohandler.xml new file mode 100644 index 00000000000..d10dac90b3e --- /dev/null +++ b/docs-xml/smbdotconf/misc/asyncsmbechohandler.xml @@ -0,0 +1,15 @@ +<samba:parameter name="async smb echo handler" + context="G" + type="boolean" + advanced="1" + xmlns:samba="http://www.samba.org/samba/DTD/samba-doc"> +<description> + <para>This parameter specifies whether Samba should fork the + async smb echo handler. It can be beneficial if your file + system can block syscalls for a very long time. In some + circumstances, it prolongs the timeout that Windows uses to + determine whether a connection is dead. + </para> +</description> +<value type="default">no</value> +</samba:parameter> diff --git a/docs-xml/smbdotconf/misc/ncalrpcdir.xml b/docs-xml/smbdotconf/misc/ncalrpcdir.xml new file mode 100644 index 00000000000..b53acef9e26 --- /dev/null +++ b/docs-xml/smbdotconf/misc/ncalrpcdir.xml @@ -0,0 +1,13 @@ +<samba:parameter name="ncalrpc dir" + context="G" + advanced="1" developer="1" + type="string" + xmlns:samba="http://www.samba.org/samba/DTD/samba-doc"> +<description> + <para>This directory will hold a series of named pipes to allow RPC over inter-process communication. </para>. + <para>This will allow Samba and other unix processes to interact over DCE/RPC without using TCP/IP. Additionally a sub-directory 'np' has restricted permissions, and allows a trusted communication channel between Samba processes</para> +</description> + +<value type="default">${prefix}/var/ncalrpc</value> +<value type="example">/var/run/samba/ncalrpc</value> +</samba:parameter> diff --git a/docs-xml/smbdotconf/misc/timeoffset.xml b/docs-xml/smbdotconf/misc/timeoffset.xml deleted file mode 100644 index 1afc514e60d..00000000000 --- a/docs-xml/smbdotconf/misc/timeoffset.xml +++ /dev/null @@ -1,15 +0,0 @@ -<samba:parameter name="time offset" - context="G" - type="integer" - advanced="1" developer="1" - xmlns:samba="http://www.samba.org/samba/DTD/samba-doc"> -<description> - <para>This parameter is a setting in minutes to add - to the normal GMT to local time conversion. This is useful if - you are serving a lot of PCs that have incorrect daylight - saving time handling.</para> -</description> - -<value type="default">0</value> -<value type="example">60</value> -</samba:parameter> diff --git a/docs-xml/smbdotconf/protocol/announceas.xml b/docs-xml/smbdotconf/protocol/announceas.xml deleted file mode 100644 index 88914961941..00000000000 --- a/docs-xml/smbdotconf/protocol/announceas.xml +++ /dev/null @@ -1,21 +0,0 @@ -<samba:parameter name="announce as" - context="G" - type="string" - developer="1" - xmlns:samba="http://www.samba.org/samba/DTD/samba-doc"> -<description> - <para>This specifies what type of server <citerefentry><refentrytitle>nmbd</refentrytitle> - <manvolnum>8</manvolnum></citerefentry> will announce itself as, to a network neighborhood browse - list. By default this is set to Windows NT. The valid options - are : "NT Server" (which can also be written as "NT"), - "NT Workstation", "Win95" or "WfW" meaning Windows NT Server, - Windows NT Workstation, Windows 95 and Windows for Workgroups - respectively. Do not change this parameter unless you have a - specific need to stop Samba appearing as an NT server as this - may prevent Samba servers from participating as browser servers - correctly.</para> -</description> - -<value type="default">NT Server</value> -<value type="example">Win95</value> -</samba:parameter> diff --git a/docs-xml/smbdotconf/protocol/announceversion.xml b/docs-xml/smbdotconf/protocol/announceversion.xml deleted file mode 100644 index ecdcd4c7349..00000000000 --- a/docs-xml/smbdotconf/protocol/announceversion.xml +++ /dev/null @@ -1,14 +0,0 @@ -<samba:parameter name="announce version" - context="G" - developer="1" - type="string" - xmlns:samba="http://www.samba.org/samba/DTD/samba-doc"> -<description> - <para>This specifies the major and minor version numbers - that nmbd will use when announcing itself as a server. The default - is 4.9. Do not change this parameter unless you have a specific - need to set a Samba server to be a downlevel server.</para> -</description> -<value type="default">4.9</value> -<value type="example">2.0</value> -</samba:parameter> diff --git a/docs-xml/smbdotconf/protocol/eventloglist.xml b/docs-xml/smbdotconf/protocol/eventloglist.xml index e98559bc179..101821ad12a 100644 --- a/docs-xml/smbdotconf/protocol/eventloglist.xml +++ b/docs-xml/smbdotconf/protocol/eventloglist.xml @@ -6,7 +6,7 @@ <para>This option defines a list of log names that Samba will report to the Microsoft EventViewer utility. The listed eventlogs will be associated with tdb file on disk in the - <filename>$(lockdir)/eventlog</filename>. + <filename>$(statedir)/eventlog</filename>. </para> <para> diff --git a/docs-xml/smbdotconf/protocol/usespnego.xml b/docs-xml/smbdotconf/protocol/usespnego.xml index 8fb559c1775..e16c7ce2be1 100644 --- a/docs-xml/smbdotconf/protocol/usespnego.xml +++ b/docs-xml/smbdotconf/protocol/usespnego.xml @@ -4,7 +4,7 @@ developer="1" xmlns:samba="http://www.samba.org/samba/DTD/samba-doc"> <description> - <para>This variable controls controls whether samba will try + <para>This deprecated variable controls controls whether samba will try to use Simple and Protected NEGOciation (as specified by rfc2478) with WindowsXP and Windows2000 clients to agree upon an authentication mechanism. </para> diff --git a/docs-xml/smbdotconf/security/passwordlevel.xml b/docs-xml/smbdotconf/security/passwordlevel.xml index 1da11e406bd..eee838f65c2 100644 --- a/docs-xml/smbdotconf/security/passwordlevel.xml +++ b/docs-xml/smbdotconf/security/passwordlevel.xml @@ -13,7 +13,7 @@ text passwords even when NT LM 0.12 selected by the protocol negotiation request/response.</para> - <para>This parameter defines the maximum number of characters + <para>This deprecated parameter defines the maximum number of characters that may be upper case in passwords.</para> <para>For example, say the password given was "FRED". If <parameter moreinfo="none"> diff --git a/docs-xml/smbdotconf/security/passwordserver.xml b/docs-xml/smbdotconf/security/passwordserver.xml index 0e92af9ebae..09d335c3ac0 100644 --- a/docs-xml/smbdotconf/security/passwordserver.xml +++ b/docs-xml/smbdotconf/security/passwordserver.xml @@ -10,54 +10,24 @@ it is possible to get Samba to do all its username/password validation using a specific remote server.</para> - <para>This option sets the name or IP address of the password server to use. - New syntax has been added to support defining the port to use when connecting - to the server the case of an ADS realm. To define a port other than the - default LDAP port of 389, add the port number using a colon after the - name or IP address (e.g. 192.168.1.100:389). If you do not specify a port, - Samba will use the standard LDAP port of tcp/389. Note that port numbers - have no effect on password servers for Windows NT 4.0 domains or netbios - connections.</para> - - <para>If parameter is a name, it is looked up using the - parameter <smbconfoption name="name resolve order"/> and so may resolved - by any method and order described in that parameter.</para> - - <para>The password server must be a machine capable of using - the "LM1.2X002" or the "NT LM 0.12" protocol, and it must be in - user level security mode.</para> - - <note><para>Using a password server means your UNIX box (running - Samba) is only as secure as your password server. <emphasis>DO NOT - CHOOSE A PASSWORD SERVER THAT YOU DON'T COMPLETELY TRUST</emphasis>. - </para></note> - - <para>Never point a Samba server at itself for password serving. - This will cause a loop and could lock up your Samba server!</para> - - <para>The name of the password server takes the standard - substitutions, but probably the only useful one is <parameter moreinfo="none">%m - </parameter>, which means the Samba server will use the incoming - client as the password server. If you use this then you better - trust your clients, and you had better restrict them with hosts allow!</para> - <para>If the <parameter moreinfo="none">security</parameter> parameter is set to - <constant>domain</constant> or <constant>ads</constant>, then the list of machines in this - option must be a list of Primary or Backup Domain controllers for the - Domain or the character '*', as the Samba server is effectively - in that domain, and will use cryptographically authenticated RPC calls - to authenticate the user logging on. The advantage of using <command moreinfo="none"> - security = domain</command> is that if you list several hosts in the - <parameter moreinfo="none">password server</parameter> option then <command moreinfo="none">smbd - </command> will try each in turn till it finds one that responds. This - is useful in case your primary server goes down.</para> + <constant>domain</constant> or <constant>ads</constant>, then this option + <emphasis>should not</emphasis> be used, as the default '*' indicates to Samba + to determine the best DC to contact dynamically, just as all other hosts in an + AD domain do. This allows the domain to be maintained without modification to + the smb.conf file. The cryptograpic protection on the authenticated RPC calls + used to verify passwords ensures that this default is safe.</para> - <para>If the <parameter moreinfo="none">password server</parameter> option is set - to the character '*', then Samba will attempt to auto-locate the - Primary or Backup Domain controllers to authenticate against by - doing a query for the name <constant>WORKGROUP<1C></constant> - and then contacting each server returned in the list of IP - addresses from the name resolution source. </para> + <para><emphasis>It is strongly recommended that you use the + default of '*'</emphasis>, however if in your particular + environment you have reason to specify a particular DC list, then + the list of machines in this option must be a list of names or IP + addresses of Domain controllers for the Domain. If you use the + default of '*', or list several hosts in the <parameter + moreinfo="none">password server</parameter> option then <command + moreinfo="none">smbd </command> will try each in turn till it + finds one that responds. This is useful in case your primary + server goes down.</para> <para>If the list of servers contains both names/IP's and the '*' character, the list is treated as a list of preferred @@ -65,10 +35,12 @@ will be added to the list as well. Samba will not attempt to optimize this list by locating the closest DC.</para> + <para>If parameter is a name, it is looked up using the + parameter <smbconfoption name="name resolve order"/> and so may resolved + by any method and order described in that parameter.</para> + <para>If the <parameter moreinfo="none">security</parameter> parameter is - set to <constant>server</constant>, then there are different - restrictions that <command moreinfo="none">security = domain</command> doesn't - suffer from:</para> + set to <constant>server</constant>, these additional restrictions apply:</para> <itemizedlist> <listitem> @@ -82,12 +54,34 @@ </listitem> <listitem> - <para>If you are using a Windows NT server as your - password server then you will have to ensure that your users + <para>You will have to ensure that your users are able to login from the Samba server, as when in <command moreinfo="none"> security = server</command> mode the network logon will appear to - come from there rather than from the users workstation.</para> + come from the Samba server rather than from the users workstation.</para> </listitem> + + <listitem> + <para>The client must not select NTLMv2 authentication.</para> + </listitem> + + <listitem> + <para>The password server must be a machine capable of using + the "LM1.2X002" or the "NT LM 0.12" protocol, and it must be in + user level security mode.</para> + </listitem> + + <listitem> + <para>Using a password server means your UNIX box (running + Samba) is only as secure as (a host masqurading as) your password server. <emphasis>DO NOT + CHOOSE A PASSWORD SERVER THAT YOU DON'T COMPLETELY TRUST</emphasis>. + </para> + </listitem> + + <listitem> + <para>Never point a Samba server at itself for password serving. + This will cause a loop and could lock up your Samba server!</para> + </listitem> + </itemizedlist> </description> diff --git a/docs-xml/smbdotconf/security/security.xml b/docs-xml/smbdotconf/security/security.xml index 514ea54e0ff..55e147e8dc4 100644 --- a/docs-xml/smbdotconf/security/security.xml +++ b/docs-xml/smbdotconf/security/security.xml @@ -22,32 +22,18 @@ the most common setting needed when talking to Windows 98 and Windows NT.</para> - <para>The alternatives are <command moreinfo="none">security = share</command>, - <command moreinfo="none">security = server</command> or <command moreinfo="none">security = domain - </command>.</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> - <para>There is a bug in WfWg that has relevance to this - setting. When in user or server level security a WfWg client - will totally ignore the username and password you type in the "connect - drive" dialog box. This makes it very difficult (if not impossible) - to connect to a Samba service as anyone except the user that - you are logged into WfWg as.</para> - - <para>If your PCs use usernames that are the same as their - usernames on the UNIX machine then you will want to use - <command moreinfo="none">security = user</command>. If you mostly use usernames - that don't exist on the UNIX box then use <command moreinfo="none">security = - share</command>.</para> - - <para>You should also use <command moreinfo="none">security = share</command> if you + <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. It is more difficult - to setup guest shares with <command moreinfo="none">security = user</command>, see - the <smbconfoption name="map to guest"/> parameter for details.</para> + 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 @@ -56,7 +42,62 @@ <para>The different settings will now be explained.</para> + <para><anchor id="SECURITYEQUALSUSER"/><emphasis>SECURITY = USER</emphasis></para> + + <para>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>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> + <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 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 @@ -135,63 +176,10 @@ <para>See also the section <link linkend="VALIDATIONSECT"> NOTE ABOUT USERNAME/PASSWORD VALIDATION</link>.</para> - <para><anchor id="SECURITYEQUALSUSER"/><emphasis>SECURITY = USER</emphasis></para> - - <para>This is the default security setting in Samba 3.0. - 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>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> - <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 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="SECURITYEQUALSSERVER"/><emphasis>SECURITY = SERVER</emphasis></para> <para> - In this mode Samba will try to validate the username/password by passing it to another SMB server, such as an + 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 @@ -203,19 +191,24 @@ <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 consuption on + 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 futher authentications to the + 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 diff --git a/docs-xml/smbdotconf/security/username.xml b/docs-xml/smbdotconf/security/username.xml index 3a45d4d72fc..19d8a2ecfd5 100644 --- a/docs-xml/smbdotconf/security/username.xml +++ b/docs-xml/smbdotconf/security/username.xml @@ -9,7 +9,7 @@ list, in which case the supplied password will be tested against each username in turn (left to right).</para> - <para>The <parameter moreinfo="none">username</parameter> line is needed only when + <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 diff --git a/docs-xml/smbdotconf/winbind/idmapallocconfig.xml b/docs-xml/smbdotconf/winbind/idmapallocconfig.xml deleted file mode 100644 index 013904122c0..00000000000 --- a/docs-xml/smbdotconf/winbind/idmapallocconfig.xml +++ /dev/null @@ -1,14 +0,0 @@ -<samba:parameter name="idmap alloc config" - context="G" - type="string" - advanced="1" developer="1" hide="1" - xmlns:samba="http://www.samba.org/samba/DTD/samba-doc"> -<description> - <para> - The idmap alloc config prefix provides a means of managing settings - for the backend defined by the <smbconfoption name="idmap alloc backend"/> - parameter. Refer to the man page for each idmap plugin regarding - specific configuration details. - </para> -</description> -</samba:parameter> diff --git a/docs-xml/smbdotconf/winbind/idmapbackend.xml b/docs-xml/smbdotconf/winbind/idmapbackend.xml index 824476f4548..bd96dfedd8a 100644 --- a/docs-xml/smbdotconf/winbind/idmapbackend.xml +++ b/docs-xml/smbdotconf/winbind/idmapbackend.xml @@ -11,39 +11,8 @@ <para> This option specifies the default backend that is used when no special - configuration set by <smbconfoption name="idmap config"/> matches the - specific request. - </para> - - <para> - This default backend also specifies the place where winbind-generated - idmap entries will be stored. So it is highly recommended that you - specify a writable backend like <citerefentry> - <refentrytitle>idmap_tdb</refentrytitle> <manvolnum>8</manvolnum> - </citerefentry> or <citerefentry> - <refentrytitle>idmap_ldap</refentrytitle> <manvolnum>8</manvolnum> - </citerefentry> as the idmap backend. The <citerefentry> - <refentrytitle>idmap_rid</refentrytitle> <manvolnum>8</manvolnum> - </citerefentry> and <citerefentry> - <refentrytitle>idmap_ad</refentrytitle> <manvolnum>8</manvolnum> - </citerefentry> backends are not writable and thus will generate - unexpected results if set as idmap backend. - </para> - - <para> - To use the rid and ad backends, please specify them via the - <smbconfoption name="idmap config"/> parameter, possibly also for the - domain your machine is member of, specified by <smbconfoption - name="workgroup"/>. - </para> - - <para>Examples of SID/uid/gid backends include tdb (<citerefentry> - <refentrytitle>idmap_tdb</refentrytitle><manvolnum>8</manvolnum></citerefentry>), - ldap (<citerefentry><refentrytitle>idmap_ldap</refentrytitle> - <manvolnum>8</manvolnum></citerefentry>), rid (<citerefentry> - <refentrytitle>idmap_rid</refentrytitle><manvolnum>8</manvolnum></citerefentry>), - and ad (<citerefentry><refentrytitle>idmap_ad</refentrytitle> - <manvolnum>8</manvolnum></citerefentry>). + configuration set, but it is now deprecated in favour of the new + spelling <smbconfoption name="idmap config * : backend"/>. </para> </description> diff --git a/docs-xml/smbdotconf/winbind/idmapconfig.xml b/docs-xml/smbdotconf/winbind/idmapconfig.xml index f6e97b9d97c..69bddf0ebf7 100644 --- a/docs-xml/smbdotconf/winbind/idmapconfig.xml +++ b/docs-xml/smbdotconf/winbind/idmapconfig.xml @@ -6,44 +6,108 @@ <description> <para> - The idmap config prefix provides a means of managing each trusted - domain separately. The idmap config prefix should be followed by the - name of the domain, a colon, and a setting specific to the chosen - backend. There are three options available for all domains: + ID mapping in Samba is the mapping between Windows SIDs and Unix user + and group IDs. This is performed by Winbindd with a configurable plugin + interface. Samba's ID mapping is configured by options starting with the + <smbconfoption name="idmap config"/> prefix. + An idmap option consists of the <smbconfoption name="idmap config"/> + prefix, followed by a domain name or the asterisk character (*), + a colon, and the name of an idmap setting for the chosen domain. </para> - <variablelist> + <para> + The idmap configuration is hence divided into groups, one group + for each domain to be configured, and one group with the the + asterisk instead of a proper domain name, which speifies the + default configuration that is used to catch all domains that do + not have an explicit idmap configuration of their own. + </para> + + <para> + There are three general options available: + </para> + + <variablelist> <varlistentry> <term>backend = backend_name</term> <listitem><para> - Specifies the name of the idmap plugin to use as the - SID/uid/gid backend for this domain. + This specifies the name of the idmap plugin to use as the + SID/uid/gid backend for this domain. The standard backends are + tdb + (<citerefentry><refentrytitle>idmap_tdb</refentrytitle> <manvolnum>8</manvolnum> </citerefentry>), + tdb2 + (<citerefentry><refentrytitle>idmap_tdb2</refentrytitle> <manvolnum>8</manvolnum></citerefentry>), + ldap + (<citerefentry><refentrytitle>idmap_ldap</refentrytitle> <manvolnum>8</manvolnum></citerefentry>), + , + rid + (<citerefentry><refentrytitle>idmap_rid</refentrytitle> <manvolnum>8</manvolnum></citerefentry>), + , + hash + (<citerefentry><refentrytitle>idmap_hash</refentrytitle> <manvolnum>8</manvolnum></citerefentry>), + , + autorid + (<citerefentry><refentrytitle>idmap_autorid</refentrytitle> <manvolnum>8</manvolnum></citerefentry>), + , + ad + (<citerefentry><refentrytitle>idmap_ad</refentrytitle> <manvolnum>8</manvolnum></citerefentry>), + , + adex + (<citerefentry><refentrytitle>idmap_adex</refentrytitle> <manvolnum>8</manvolnum></citerefentry>), + , + and nss. + (<citerefentry><refentrytitle>idmap_nss</refentrytitle> <manvolnum>8</manvolnum></citerefentry>), + The corresponding manual pages contain the details, but + here is a summary. + </para> + <para> + The first three of these create mappings of their own using + internal unixid counters and store the mappings in a database. + These are suitable for use in the default idmap configuration. + The rid and hash backends use a pure algorithmic calculation + to determine the unixid for a SID. The autorid module is a + mixture of the tdb and rid backend. It creates ranges for + each domain encountered and then uses the rid algorithm for each + of these automatically configured domains individually. + The ad and adex + backends both use unix IDs stored in Active Directory via + the standard schema extensions. The nss backend reverses + the standard winbindd setup and gets the unixids via names + from nsswitch which can be useful in an ldap setup. </para></listitem> </varlistentry> <varlistentry> <term>range = low - high</term> - <listitem><para> + <listitem><para> Defines the available matching uid and gid range for which the - backend is authoritative. Note that the range commonly - matches the allocation range due to the fact that the same - backend will store and retrieve SID/uid/gid mapping entries. - </para> + backend is authoritative. For allocating backends, this also + defines the start and the end of the range for allocating + new unid IDs. + </para> <para> winbind uses this parameter to find the backend that is - authoritative for a unix ID to SID mapping, so it must be set - for each individually configured domain, and it must be - disjoint from the ranges set via <smbconfoption name="idmap - uid"/> and <smbconfoption name="idmap gid"/>. + authoritative for a unix ID to SID mapping, so it must be set + for each individually configured domain and for the default + configuration. The configured ranges must be mutually disjoint. </para></listitem> + </varlistentry> + <varlistentry> + <term>read only = yes|no</term> + <listitem><para> + This option can be used to turn the writing backends + tdb, tdb2, and ldap into read only mode. This can be useful + e.g. in cases where a pre-filled database exists that should + not be extended automatically. + </para></listitem> </varlistentry> </variablelist> <para> The following example illustrates how to configure the <citerefentry> <refentrytitle>idmap_ad</refentrytitle> <manvolnum>8</manvolnum> - </citerefentry> for the CORP domain and the + </citerefentry> backend for the CORP domain and the <citerefentry><refentrytitle>idmap_tdb</refentrytitle> <manvolnum>8</manvolnum></citerefentry> backend for all other domains. This configuration assumes that the admin of CORP assigns @@ -53,9 +117,8 @@ </para> <programlisting> - idmap backend = tdb - idmap uid = 1000000-1999999 - idmap gid = 1000000-1999999 + idmap config * : backend = tdb + idmap config * : range = 1000000-1999999 idmap config CORP : backend = ad idmap config CORP : range = 1000-999999 diff --git a/docs-xml/smbdotconf/winbind/idmapgid.xml b/docs-xml/smbdotconf/winbind/idmapgid.xml index ef3ae4fde11..27648a253d9 100644 --- a/docs-xml/smbdotconf/winbind/idmapgid.xml +++ b/docs-xml/smbdotconf/winbind/idmapgid.xml @@ -5,16 +5,13 @@ xmlns:samba="http://www.samba.org/samba/DTD/samba-doc"> <synonym>winbind gid</synonym> <description> - <para>The idmap gid parameter specifies the range of group ids - that are allocated for the purpose of mapping UNX groups to NT group - SIDs. This range of group ids should have no - existing local or NIS groups within it as strange conflicts can - occur otherwise.</para> - - <para>See also the <smbconfoption name="idmap backend"/>, and - <smbconfoption name="idmap config"/> options. + <para> + The idmap gid parameter specifies the range of group ids + for the default idmap configuration. It is now deprecated + in favour of <smbconfoption name="idmap config * : range"/>. </para> + <para>See the <smbconfoption name="idmap config"/> option.</para> </description> <value type="default"></value> diff --git a/docs-xml/smbdotconf/winbind/idmapuid.xml b/docs-xml/smbdotconf/winbind/idmapuid.xml index 2c53817375e..ce5a4dea059 100644 --- a/docs-xml/smbdotconf/winbind/idmapuid.xml +++ b/docs-xml/smbdotconf/winbind/idmapuid.xml @@ -6,14 +6,12 @@ <synonym>winbind uid</synonym> <description> <para> - The idmap uid parameter specifies the range of user ids that are - allocated for use in mapping UNIX users to NT user SIDs. This - range of ids should have no existing local - or NIS users within it as strange conflicts can occur otherwise.</para> - - <para>See also the <smbconfoption name="idmap backend"/> and - <smbconfoption name="idmap config"/> options. + The idmap uid parameter specifies the range of user ids for + the default idmap configuration. It is now deprecated in favour + of <smbconfoption name="idmap config * : range"/>. </para> + + <para>See the <smbconfoption name="idmap config"/> option.</para> </description> <value type="default"></value> |