Moving docs tree to docs-xml to make room for generated docs in the release tarball.

(This used to be commit 9f672c26d63955f613088489c6efbdc08b5b2d14)

1 files changed, 602 insertions, 0 deletions

diff --git a/docs-xml/Samba3-HOWTO/TOSHARG-InterdomainTrusts.xml b/docs-xml/Samba3-HOWTO/TOSHARG-InterdomainTrusts.xml
new file mode 100644
index 0000000000..3ea527ba5e
--- /dev/null
+++ b/docs-xml/Samba3-HOWTO/TOSHARG-InterdomainTrusts.xml
@@ -0,0 +1,602 @@
+<?xml version="1.0" encoding="iso-8859-1"?>
+<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
+<chapter id="InterdomainTrusts">
+<chapterinfo>
+	&author.jht;
+	&author.mimir;
+	<author>&person.jelmer;<contrib>drawing</contrib></author>
+        <author>
+                <firstname>Stephen</firstname><surname>Langasek</surname>
+                <affiliation>
+                        <address><email>vorlon@netexpress.net</email></address>
+                </affiliation>
+        </author>
+	<pubdate>April 3, 2003</pubdate>
+</chapterinfo>
+
+<title>Interdomain Trust Relationships</title>
+
+
+<para>
+<indexterm><primary>Interdomain Trusts</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>trusts</primary></indexterm>
+<indexterm><primary>samba-to-samba trusts</primary></indexterm>
+<indexterm><primary>Active Directory</primary></indexterm>
+<indexterm><primary>NT4-style domain</primary></indexterm>
+<indexterm><primary>trust relationships</primary></indexterm>
+<indexterm><primary>ADS</primary></indexterm>
+<indexterm><primary>LDAP-based</primary></indexterm>
+Samba-3 supports NT4-style domain trust relationships. This is a feature that many sites
+will want to use if they migrate to Samba-3 from an NT4-style domain and do not want to
+adopt Active Directory or an LDAP-based authentication backend. This chapter explains
+some background information regarding trust relationships and how to create them. It is now
+possible for Samba-3 to trust NT4 (and vice versa), as well as to create Samba-to-Samba 
+trusts.
+</para>
+
+<para>
+<indexterm><primary>winbind</primary></indexterm>
+<indexterm><primary>UID range</primary></indexterm>
+<indexterm><primary>GID range</primary></indexterm>
+<indexterm><primary>daemon</primary></indexterm>
+<indexterm><primary>winbindd</primary></indexterm>
+The use of interdomain trusts requires use of <command>winbind</command>, so the
+<command>winbindd</command> daemon must be running. Winbind operation in this mode is
+dependent on the specification of a valid UID range and a valid GID range in the &smb.conf; file.
+These are specified respectively using:
+<smbconfblock>
+<smbconfoption name="idmap uid">10000-20000</smbconfoption>
+<smbconfoption name="idmap gid">10000-20000</smbconfoption>
+</smbconfblock>
+<indexterm><primary>passdb backend</primary></indexterm>
+<indexterm><primary>POSIX user accounts</primary></indexterm>
+<indexterm><primary>maximum value</primary></indexterm>
+<indexterm><primary>4294967295</primary></indexterm>
+The range of values specified must not overlap values used by the host operating system and must
+not overlap values used in the passdb backend for POSIX user accounts. The maximum value is
+limited by the upper-most value permitted by the host operating system. This is a UNIX kernel
+limited parameter. Linux kernel 2.6-based systems support a maximum value of 4294967295 
+(32-bit unsigned variable).
+</para>
+
+<note><para>
+<indexterm><primary>winbind</primary></indexterm>
+<indexterm><primary>trusting domain</primary></indexterm>
+<indexterm><primary>trusted domain</primary></indexterm>
+The use of winbind is necessary only when Samba is the trusting domain, not when it is the
+trusted domain.
+</para></note>
+
+<sect1>
+<title>Features and Benefits</title>
+
+<para>
+<indexterm><primary>scalability</primary></indexterm>
+<indexterm><primary>trust relationships</primary></indexterm>
+Samba-3 can participate in Samba-to-Samba as well as in Samba-to-MS Windows NT4-style
+trust relationships. This imparts to Samba scalability similar to that with MS Windows NT4.
+</para>
+
+<para>
+<indexterm><primary>scalable backend</primary></indexterm>
+<indexterm><primary>authentication database</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>interdomain trusts</primary></indexterm>
+<indexterm><primary>ADS</primary></indexterm>
+Given that Samba-3 can function with a scalable backend authentication database such as LDAP, and given its
+ability to run in primary as well as backup domain control modes, the administrator would be well-advised to
+consider alternatives to the use of interdomain trusts simply because, by the very nature of how trusts
+function, this system is fragile.  That was, after all, a key reason for the development and adoption of
+Microsoft Active Directory.
+</para>
+
+</sect1>
+
+<sect1>
+<title>Trust Relationship Background</title>
+
+<para>
+<indexterm><primary>security domains</primary></indexterm>
+<indexterm><primary>nonhierarchical</primary></indexterm>
+<indexterm><primary>security structure</primary></indexterm>
+<indexterm><primary>large organizations</primary></indexterm>
+<indexterm><primary>delegation</primary></indexterm>
+<indexterm><primary>administrative responsibilities</primary></indexterm>
+MS Windows NT3/4-type security domains employ a nonhierarchical security structure.
+The limitations of this architecture as it effects the scalability of MS Windows networking
+in large organizations is well known. Additionally, the flat namespace that results from
+this design significantly impacts the delegation of administrative responsibilities in
+large and diverse organizations.
+</para>
+
+<para>
+<indexterm><primary>ADS</primary></indexterm>
+<indexterm><primary>Kerberos</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>limitations</primary></indexterm>
+<indexterm><primary>domain security</primary></indexterm>
+Microsoft developed Active Directory Service (ADS), based on Kerberos and LDAP, as a means
+of circumventing the limitations of the older technologies. Not every organization is ready
+or willing to embrace ADS. For small companies the older NT4-style domain security paradigm
+is quite adequate, and so there remains an entrenched user base for whom there is no direct
+desire to go through a disruptive change to adopt ADS.
+</para>
+
+<para>
+<indexterm><primary>security domains</primary></indexterm>
+<indexterm><primary>access rights</primary></indexterm>
+<indexterm><primary>privileges</primary></indexterm>
+<indexterm><primary>trusts</primary></indexterm>
+<indexterm><primary>trusted domain</primary></indexterm>
+<indexterm><primary>trusting domain</primary></indexterm>
+<indexterm><primary>one direction</primary></indexterm>
+With Windows NT, Microsoft introduced the ability to allow different security domains
+to effect a mechanism so users from one domain may be given access rights and privileges
+in another domain. The language that describes this capability is couched in terms of
+<emphasis>trusts</emphasis>. Specifically, one domain will <emphasis>trust</emphasis> the users
+from another domain. The domain from which users can access another security domain is
+said to be a trusted domain. The domain in which those users have assigned rights and privileges
+is the trusting domain. With NT3.x/4.0 all trust relationships are always in one direction only,
+so if users in both domains are to have privileges and rights in each others' domain, then it is
+necessary to establish two relationships, one in each direction.
+</para>
+
+<para>
+<indexterm><primary>security domain</primary></indexterm>
+<indexterm><primary>nontransitive</primary></indexterm>
+<indexterm><primary>trust relationship</primary></indexterm>
+<indexterm><primary>transitive</primary></indexterm>
+<indexterm><primary>explicit trust</primary></indexterm>
+Further, in an NT4-style MS security domain, all trusts are nontransitive. This means that if there are three
+domains (let's call them red, white, and blue), where red and white have a trust relationship, and white and
+blue have a trust relationship, then it holds that there is no implied trust between the red and blue domains.
+Relationships are explicit and not transitive.
+</para>
+
+<para>
+<indexterm><primary>ADS</primary></indexterm>
+<indexterm><primary>security contexts</primary></indexterm>
+<indexterm><primary>trust relationships</primary></indexterm>
+<indexterm><primary>two-way trust</primary></indexterm>
+<indexterm><primary>Windows 2000</primary></indexterm>
+<indexterm><primary>security domains</primary></indexterm>
+<indexterm><primary>NT4-style domains</primary></indexterm>
+New to MS Windows 2000 ADS security contexts is the fact that trust relationships are two-way by default.
+Also, all inter-ADS domain trusts are transitive. In the case of the red, white, and blue domains, with
+Windows 2000 and ADS, the red and blue domains can trust each other. This is an inherent feature of ADS
+domains. Samba-3 implements MS Windows NT4-style interdomain trusts and interoperates with MS Windows 200x ADS
+security domains in similar manner to MS Windows NT4-style domains.
+</para>
+
+</sect1>
+
+<sect1>
+<title>Native MS Windows NT4 Trusts Configuration</title>
+
+<para>
+<indexterm><primary>Interdomain Trusts</primary><secondary>creating</secondary></indexterm>
+<indexterm><primary>two-way trust</primary></indexterm>
+<indexterm><primary>security credentials</primary></indexterm>
+There are two steps to creating an interdomain trust relationship. To effect a two-way trust
+relationship, it is necessary for each domain administrator to create a trust account for the 
+other domain to use in verifying security credentials.
+</para>
+
+
+<sect2>
+<title>Creating an NT4 Domain Trust</title>
+
+<para>
+<indexterm><primary>domain trust</primary></indexterm>
+<indexterm><primary>trust relationships</primary></indexterm>
+<indexterm><primary>>Domain User Manager</primary></indexterm>
+<indexterm><primary>remote domain</primary></indexterm>
+<indexterm><primary>standard confirmation</primary></indexterm>
+For MS Windows NT4, all domain trust relationships are configured using the 
+<application>Domain User Manager</application>. This is done from the Domain User Manager Policies
+entry on the menu bar. From the <guimenu>Policy</guimenu> menu, select
+<guimenuitem>Trust Relationships</guimenuitem>. Next to the lower box labeled
+<guilabel>Permitted to Trust this Domain</guilabel> are two buttons, <guibutton>Add</guibutton>
+and <guibutton>Remove</guibutton>. The <guibutton>Add</guibutton> button will open a panel in which
+to enter the name of the remote domain that will be able to assign access rights to users in 
+your domain. You will also need to enter a password for this trust relationship, which the 
+trusting domain will use when authenticating users from the trusted domain.
+The password needs to be typed twice (for standard confirmation).
+</para>
+
+</sect2>
+
+
+<sect2>
+<title>Completing an NT4 Domain Trust</title>
+
+<para>
+<indexterm><primary>trust relationship</primary></indexterm>
+<indexterm><primary>trusting domain</primary></indexterm>
+<indexterm><primary>trusted domain</primary></indexterm>
+<indexterm><primary>remote domain</primary></indexterm>
+<indexterm><primary>password assigned</primary></indexterm>
+<indexterm><primary>Interdomain Trusts</primary><secondary>Completing</secondary></indexterm>
+A trust relationship will work only when the other (trusting) domain makes the appropriate connections
+with the trusted domain. To consummate the trust relationship, the administrator launches the
+Domain User Manager from the menu selects <guilabel>Policies</guilabel>, then select
+<guilabel>Trust Relationships</guilabel>, and clicks on the <guibutton>Add</guibutton> button
+next to the box that is labeled <guilabel>Trusted Domains</guilabel>. A panel opens in which
+must be entered the name of the remote domain as well as the password assigned to that trust.
+</para>
+
+</sect2>
+
+<sect2>
+<title>Interdomain Trust Facilities</title>
+
+
+<para>
+<indexterm><primary>two-way trust</primary></indexterm>
+<indexterm><primary>trust relationship</primary></indexterm>
+<indexterm><primary>trust established</primary></indexterm>
+<indexterm><primary>one-way trust</primary></indexterm>
+<indexterm><primary>Windows NT4 domains</primary></indexterm>
+<indexterm><primary>Interdomain Trusts</primary><secondary>Facilities</secondary></indexterm>
+A two-way trust relationship is created when two one-way trusts are created, one in each direction.
+Where a one-way trust has been established between two MS Windows NT4 domains (let's call them
+DomA and DomB), the following facilities are created:
+</para>
+
+<figure id="trusts1">
+	<title>Trusts overview.</title>
+	<imagefile>trusts1</imagefile>
+</figure>
+
+<itemizedlist>
+	<listitem><para>
+	DomA (completes the trust connection) <parameter>Trusts</parameter> DomB.
+	</para></listitem>
+
+	<listitem><para>
+	DomA is the <parameter>Trusting</parameter> domain.
+	</para></listitem>
+
+	<listitem><para>
+	DomB is the <parameter>Trusted</parameter> domain (originates the trust account).
+	</para></listitem>
+
+	<listitem><para>
+	Users in DomB can access resources in DomA.
+	</para></listitem>
+
+	<listitem><para>
+	Users in DomA cannot access resources in DomB.
+	</para></listitem>
+
+	<listitem><para>
+	Global groups from DomB can be used in DomA.
+	</para></listitem>
+
+	<listitem><para>
+	Global groups from DomA cannot be used in DomB.
+	</para></listitem>
+
+	<listitem><para>
+	DomB does appear in the logon dialog box on client workstations in DomA.
+	</para></listitem>
+
+	<listitem><para>
+	DomA does not appear in the logon dialog box on client workstations in DomB.
+	</para></listitem>
+</itemizedlist>
+
+<itemizedlist>
+	<listitem><para>
+	Users and groups in a trusting domain cannot be granted rights, permissions, or access
+	to a trusted domain.
+	</para></listitem>
+
+	<listitem><para>
+	The trusting domain can access and use accounts (users/global groups) in the
+	trusted domain.
+	</para></listitem>
+
+	<listitem><para>
+	Administrators of the trusted domain can be granted administrative rights in the 
+	trusting domain.
+	</para></listitem>
+
+	<listitem><para>
+	Users in a trusted domain can be given rights and privileges in the trusting
+	domain.
+	</para></listitem>
+
+	<listitem><para>
+	Trusted domain global groups can be given rights and permissions in the trusting
+	domain.
+	</para></listitem>
+
+	<listitem><para>
+	Global groups from the trusted domain can be made members in local groups on
+	MS Windows domain member machines.
+	</para></listitem>
+</itemizedlist>
+
+</sect2>
+
+</sect1>
+
+<sect1>
+<title>Configuring Samba NT-Style Domain Trusts</title>
+
+<para>
+<indexterm><primary>interdomain trust</primary></indexterm>
+This description is meant to be a fairly short introduction about how to set up a Samba server so
+that it can participate in interdomain trust relationships. Trust relationship support in Samba
+is at an early stage, so do not be surprised if something does not function as it should.
+</para>
+
+<para>
+<indexterm><primary>peer domain</primary></indexterm>
+<indexterm><primary>trust relationship</primary></indexterm>
+<indexterm><primary>Windows NT4 Server</primary></indexterm>
+<indexterm><primary>between domains</primary></indexterm>
+Each of the procedures described next assumes the peer domain in the trust relationship is controlled by a
+Windows NT4 server. However, the remote end could just as well be another Samba-3  domain. It can be clearly
+seen, after reading this document, that combining Samba-specific parts of what's written in the following
+sections leads to trust between domains in a purely Samba environment.
+</para>
+
+<sect2 id="samba-trusted-domain">
+<title>Samba as the Trusted Domain</title>
+
+<para>
+<indexterm><primary>trusted party</primary></indexterm>
+<indexterm><primary>special account</primary></indexterm>
+<indexterm><primary>trusting party</primary></indexterm>
+<indexterm><primary>PDC</primary></indexterm>
+<indexterm><primary>smbpasswd</primary></indexterm>
+In order to set the Samba PDC to be the trusted party of the relationship, you first need
+to create a special account for the domain that will be the trusting party. To do that,
+you can use the <command>smbpasswd</command> utility. Creating the trusted domain account is 
+similar to creating a trusted machine account. Suppose, your domain is
+called SAMBA, and the remote domain is called RUMBA. The first step
+will be to issue this command from your favorite shell:
+</para>
+
+<para>
+<screen>
+&rootprompt; <userinput>smbpasswd -a -i rumba</userinput>
+New SMB password: <userinput>XXXXXXXX</userinput>
+Retype SMB password: <userinput>XXXXXXXX</userinput>
+Added user rumba$
+</screen>
+
+where <option>-a</option> means to add a new account into the
+passdb database and <option>-i</option> means to <quote>create this
+account with the Interdomain trust flag</quote>.
+</para>
+
+<para>
+<indexterm><primary>account name</primary></indexterm>
+<indexterm><primary>remote domain</primary></indexterm>
+<indexterm><primary>password database</primary></indexterm>
+<indexterm><primary>/etc/passwd</primary></indexterm>
+The account name will be <quote>rumba$</quote> (the name of the remote domain).
+If this fails, you should check that the trust account has been added to the system
+password database (<filename>/etc/passwd</filename>). If it has not been added, you
+can add it manually and then repeat the previous step.
+</para>
+
+<para>
+<indexterm><primary>password</primary></indexterm>
+<indexterm><primary>new account</primary></indexterm>
+<indexterm><primary>confirm the trust</primary></indexterm>
+<indexterm><primary>Windows NT Server</primary></indexterm>
+After issuing this command, you will be asked to enter the password for the account. You can use any password
+you want, but be aware that Windows NT will not change this password until 7 days following account creation.
+After the command returns successfully, you can look at the entry for the new account (in the standard way as
+appropriate for your configuration) and see that the account's name is really RUMBA$ and it has the
+<quote>I</quote> flag set in the flags field. Now you are ready to confirm the trust by establishing it from
+Windows NT Server.
+</para>
+
+
+<para>
+<indexterm><primary>User Manager</primary></indexterm>
+<indexterm><primary>trusted domain name</primary></indexterm>
+<indexterm><primary>relationship password</primary></indexterm>
+<indexterm><primary>remote domain</primary></indexterm>
+<indexterm><primary>established</primary></indexterm>
+Open <application>User Manager for Domains</application> and from the <guimenu>Policies</guimenu> menu, select
+<guimenuitem>Trust Relationships...</guimenuitem>.  Beside the <guilabel>Trusted domains</guilabel> list box,
+click the <guimenu>Add...</guimenu> button. You will be prompted for the trusted domain name and the
+relationship password. Type in SAMBA, as this is the name of the remote domain and the password used at the
+time of account creation.  Click on <guibutton>OK</guibutton> and, if everything went without incident, you
+will see the <computeroutput>Trusted domain relationship successfully established</computeroutput> message.
+</para>
+
+</sect2>
+<sect2>
+<title>Samba as the Trusting Domain</title>
+
+<para>
+<indexterm><primary>NT-controlled domain</primary></indexterm>
+<indexterm><primary>PDC</primary></indexterm>
+This time activities are somewhat reversed. Again, we'll assume that your domain
+controlled by the Samba PDC is called SAMBA and the NT-controlled domain is called RUMBA.
+</para>
+
+<para>
+The very first step is to add an account for the SAMBA domain on RUMBA's PDC.
+</para>
+
+
+<para>
+<indexterm><primary>User Manager</primary></indexterm>
+<indexterm><primary>trusted domain</primary></indexterm>
+<indexterm><primary>password</primary></indexterm>
+Launch the <application>Domain User Manager</application>, then from the menu select
+<guimenu>Policies</guimenu>, <guimenuitem>Trust Relationships</guimenuitem>.
+Now, next to the <guilabel>Trusting Domains</guilabel> box, press the <guibutton>Add</guibutton>
+button and type in the name of the trusted domain (SAMBA) and the password to use in securing
+the relationship.
+</para>
+
+<para>
+<indexterm><primary>password</primary></indexterm>
+<indexterm><primary>confirm the password</primary></indexterm>
+The password can be arbitrarily chosen. It is easy to change the password from the Samba server whenever you
+want. After you confirm the password, your account is ready for use. Now its Samba's turn.
+</para>
+
+<para>
+Using your favorite shell while logged in as root, issue this command:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>trustdom establish</tertiary></indexterm>
+</para>
+
+<para>
+&rootprompt;<userinput>net rpc trustdom establish rumba</userinput>
+</para>
+
+<para>
+<indexterm><primary>password</primary></indexterm>
+<indexterm><primary>interdomain connection</primary></indexterm>
+<indexterm><primary>ordinary connection</primary></indexterm>
+You will be prompted for the password you just typed on your Windows NT4 Server box.
+An error message, <literal>"NT_STATUS_NOLOGON_INTERDOMAIN_TRUST_ACCOUNT,"</literal>
+that may be reported periodically is of no concern and may safely be ignored.
+It means the password you gave is correct and the NT4 server says the account is ready for
+interdomain connection and not for ordinary connection.  After that, be patient;
+it can take a while (especially in large networks), but eventually you should see
+the <literal>Success</literal> message. Congratulations! Your trust
+relationship has just been established.
+</para>
+
+<note><para>
+You have to run this command as root because you must have write access to
+the <filename>secrets.tdb</filename> file.
+</para></note>
+
+</sect2>
+</sect1>
+
+<sect1>
+<title>NT4-Style Domain Trusts with Windows 2000</title>
+
+<para>
+<indexterm><primary>trust relationship</primary></indexterm>
+<indexterm><primary>Windows 2000 server</primary></indexterm>
+<indexterm><primary>NT4-style</primary></indexterm>
+<indexterm><primary>mixed mode</primary></indexterm>
+Although <application>Domain User Manager</application> is not present in Windows 2000, it is 
+also possible to establish an NT4-style trust relationship with a Windows 2000 domain 
+controller running in mixed mode as the trusting server. It should also be possible for 
+Samba to trust a Windows 2000 server; however, more testing is still needed in this area.
+</para>
+
+<para>
+<indexterm><primary>interdomain trust</primary></indexterm>
+<indexterm><primary>trust account</primary></indexterm>
+<indexterm><primary>not transitive</primary></indexterm>
+<indexterm><primary>ADS</primary></indexterm>
+After <link linkend="samba-trusted-domain">creating the interdomain trust account on the Samba server</link>
+as described previously, open <application>Active Directory Domains and Trusts</application> on the AD
+controller of the domain whose resources you wish Samba users to have access to. Remember that since NT4-style
+trusts are not transitive, if you want your users to have access to multiple mixed-mode domains in your AD
+forest, you will need to repeat this process for each of those domains. With <application>Active Directory
+domains and trusts</application> open, right-click on the name of the Active Directory domain that will trust
+our Samba domain and choose <guimenuitem>Properties</guimenuitem>, then click on the
+<guilabel>Trusts</guilabel> tab. In the upper part of the panel, you will see a list box labeled
+<guilabel>Domains trusted by this domain:</guilabel> and an <guilabel>Add...</guilabel> button next to it.
+Press this button and, just as with NT4, you will be prompted for the trusted domain name and the relationship
+password. Press <emphasis>OK</emphasis> and after a moment, Active Directory will respond with
+<computeroutput>The trusted domain has been added and the trust has been verified.</computeroutput> Your
+Samba users can now be granted access to resources in the AD domain.
+</para>
+</sect1>
+
+<sect1>
+<title>Common Errors</title>
+
+<para>
+Interdomain trust relationships should not be attempted on networks that are unstable
+or that suffer regular outages. Network stability and integrity are key concerns with
+distributed trusted domains.
+</para>
+
+<sect2>
+<title>Browsing of Trusted Domain Fails</title>
+
+<para>
+<emphasis>Browsing from a machine in a trusted Windows 200x domain to a Windows 200x member of
+a trusting Samba domain, I get the following error:</emphasis>
+<screen>
+The system detected a possible attempt to compromise security. Please
+ensure that you can contact the server that authenticated you.
+</screen>
+</para>
+
+<para>
+<emphasis>The event logs on the box I'm trying to connect to have entries regarding group
+policy not being applied because it is a member of a down-level domain.</emphasis>
+</para>
+
+<para>If there is a computer account in the Windows
+200x domain for the machine in question, and it is disabled, this problem can
+occur.  If there is no computer account (removed or never existed), or if that 
+account is still intact (i.e., you just joined it to another domain), everything 
+seems to be fine. By default, when you unjoin a domain (the Windows 200x 
+domain), the computer tries to automatically disable the computer account in 
+the domain.  If you are running as an account that has privileges to do this 
+when you unjoin the machine, it is done; otherwise it is not done.
+</para>
+
+</sect2>
+
+<sect2>
+<title>Problems with LDAP ldapsam and Older Versions of smbldap-tools</title>
+
+<para>
+If you use the <command>smbldap-useradd</command> script to create a trust
+account to set up interdomain trusts, the process of setting up the trust will
+fail. The account that was created in the LDAP database will have an account
+flags field that has <literal>[W          ]</literal>, when it must have
+<literal>[I          ]</literal> for interdomain trusts to work.
+</para>
+
+<para>Here is a simple solution.
+Create a machine account as follows:
+<screen>
+&rootprompt; smbldap-useradd -w domain_name
+</screen>
+Then set the desired trust account password as shown here:
+<screen>
+&rootprompt; smbldap-passwd domain_name\$
+</screen>
+Using a text editor, create the following file:
+<screen>
+dn: uid=domain_name$,ou=People,dc={your-domain},dc={your-top-level-domain}
+changetype: modify
+sambaAcctFlags: [I         ]
+</screen>
+Then apply the text file to the LDAP database as follows:
+<screen>
+&rootprompt; ldapmodify -x -h localhost \
+ -D "cn=Manager,dc={your-domain},dc={your-top-level-domain}" \
+ -W -f /path-to/foobar
+</screen>
+Create a single-sided trust under the NT4 Domain User Manager, then execute:
+<screen>
+&rootprompt; net rpc trustdom establish domain_name
+</screen>
+</para>
+
+<para>
+It works with Samba-3  and NT4 domains, and also with Samba-3 and Windows 200x ADS in mixed mode.
+Both domain controllers, Samba and NT must have the same WINS server; otherwise,
+the trust will never work. 
+</para>
+
+</sect2>
+
+</sect1>
+
+</chapter>