1<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter�19.�Interdomain Trust Relationships</title><link rel="stylesheet" href="../samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.74.0"><link rel="home" href="index.html" title="The Official Samba 3.5.x HOWTO and Reference Guide"><link rel="up" href="optional.html" title="Part�III.�Advanced Configuration"><link rel="prev" href="securing-samba.html" title="Chapter�18.�Securing Samba"><link rel="next" href="msdfs.html" title="Chapter�20.�Hosting a Microsoft Distributed File System Tree"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter�19.�Interdomain Trust Relationships</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="securing-samba.html">Prev</a>�</td><th width="60%" align="center">Part�III.�Advanced Configuration</th><td width="20%" align="right">�<a accesskey="n" href="msdfs.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="InterdomainTrusts"></a>Chapter�19.�Interdomain Trust Relationships</h2></div><div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="othername">H.</span> <span class="orgname">Samba Team</span> <span class="surname">Terpstra</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><code class="email"><<a class="email" href="mailto:jht@samba.org">jht@samba.org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Rafal</span> <span class="orgname">Samba Team</span> <span class="surname">Szczesniak</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><code class="email"><<a class="email" href="mailto:mimir@samba.org">mimir@samba.org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Jelmer</span> <span class="othername">R.</span> <span class="orgname">The Samba Team</span> <span class="surname">Vernooij</span></h3><span class="contrib">drawing</span>�<div class="affiliation"><span class="orgname">The Samba Team<br></span><div class="address"><p><code class="email"><<a class="email" href="mailto:jelmer@samba.org">jelmer@samba.org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Stephen</span> <span class="surname">Langasek</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:vorlon@netexpress.net">vorlon@netexpress.net</a>></code></p></div></div></div></div><div><p class="pubdate">April 3, 2003</p></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="InterdomainTrusts.html#id2619731">Features and Benefits</a></span></dt><dt><span class="sect1"><a href="InterdomainTrusts.html#id2619803">Trust Relationship Background</a></span></dt><dt><span class="sect1"><a href="InterdomainTrusts.html#id2620081">Native MS Windows NT4 Trusts Configuration</a></span></dt><dd><dl><dt><span class="sect2"><a href="InterdomainTrusts.html#id2620117">Creating an NT4 Domain Trust</a></span></dt><dt><span class="sect2"><a href="InterdomainTrusts.html#id2620214">Completing an NT4 Domain Trust</a></span></dt><dt><span class="sect2"><a href="InterdomainTrusts.html#id2620299">Interdomain Trust Facilities</a></span></dt></dl></dd><dt><span class="sect1"><a href="InterdomainTrusts.html#id2620508">Configuring Samba NT-Style Domain Trusts</a></span></dt><dd><dl><dt><span class="sect2"><a href="InterdomainTrusts.html#samba-trusted-domain">Samba as the Trusted Domain</a></span></dt><dt><span class="sect2"><a href="InterdomainTrusts.html#id2620849">Samba as the Trusting Domain</a></span></dt></dl></dd><dt><span class="sect1"><a href="InterdomainTrusts.html#id2621046">NT4-Style Domain Trusts with Windows 2000</a></span></dt><dt><span class="sect1"><a href="InterdomainTrusts.html#id2621195">Common Errors</a></span></dt><dd><dl><dt><span class="sect2"><a href="InterdomainTrusts.html#id2621208">Browsing of Trusted Domain Fails</a></span></dt><dt><span class="sect2"><a href="InterdomainTrusts.html#id2621254">Problems with LDAP ldapsam and Older Versions of smbldap-tools</a></span></dt></dl></dd></dl></div><p> 2<a class="indexterm" name="id2619511"></a> 3<a class="indexterm" name="id2619518"></a> 4<a class="indexterm" name="id2619525"></a> 5<a class="indexterm" name="id2619532"></a> 6<a class="indexterm" name="id2619539"></a> 7<a class="indexterm" name="id2619546"></a> 8<a class="indexterm" name="id2619552"></a> 9<a class="indexterm" name="id2619559"></a> 10<a class="indexterm" name="id2619566"></a> 11Samba-3 supports NT4-style domain trust relationships. This is a feature that many sites 12will want to use if they migrate to Samba-3 from an NT4-style domain and do not want to 13adopt Active Directory or an LDAP-based authentication backend. This chapter explains 14some background information regarding trust relationships and how to create them. It is now 15possible for Samba-3 to trust NT4 (and vice versa), as well as to create Samba-to-Samba 16trusts. 17</p><p> 18<a class="indexterm" name="id2619584"></a> 19<a class="indexterm" name="id2619590"></a> 20<a class="indexterm" name="id2619597"></a> 21<a class="indexterm" name="id2619604"></a> 22<a class="indexterm" name="id2619611"></a> 23The use of interdomain trusts requires use of <code class="literal">winbind</code>, so the 24<code class="literal">winbindd</code> daemon must be running. Winbind operation in this mode is 25dependent on the specification of a valid UID range and a valid GID range in the <code class="filename">smb.conf</code> file. 26These are specified respectively using: 27</p><table class="simplelist" border="0" summary="Simple list"><tr><td><a class="indexterm" name="id2619645"></a><em class="parameter"><code>idmap uid = 10000-20000</code></em></td></tr><tr><td><a class="indexterm" name="id2619657"></a><em class="parameter"><code>idmap gid = 10000-20000</code></em></td></tr></table><p> 28<a class="indexterm" name="id2619668"></a> 29<a class="indexterm" name="id2619675"></a> 30<a class="indexterm" name="id2619682"></a> 31<a class="indexterm" name="id2619689"></a> 32The range of values specified must not overlap values used by the host operating system and must 33not overlap values used in the passdb backend for POSIX user accounts. The maximum value is 34limited by the upper-most value permitted by the host operating system. This is a UNIX kernel 35limited parameter. Linux kernel 2.6-based systems support a maximum value of 4294967295 36(32-bit unsigned variable). 37</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> 38<a class="indexterm" name="id2619707"></a> 39<a class="indexterm" name="id2619714"></a> 40<a class="indexterm" name="id2619721"></a> 41The use of winbind is necessary only when Samba is the trusting domain, not when it is the 42trusted domain. 43</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2619731"></a>Features and Benefits</h2></div></div></div><p> 44<a class="indexterm" name="id2619739"></a> 45<a class="indexterm" name="id2619746"></a> 46Samba-3 can participate in Samba-to-Samba as well as in Samba-to-MS Windows NT4-style 47trust relationships. This imparts to Samba scalability similar to that with MS Windows NT4. 48</p><p> 49<a class="indexterm" name="id2619759"></a> 50<a class="indexterm" name="id2619766"></a> 51<a class="indexterm" name="id2619773"></a> 52<a class="indexterm" name="id2619780"></a> 53<a class="indexterm" name="id2619787"></a> 54Given that Samba-3 can function with a scalable backend authentication database such as LDAP, and given its 55ability to run in primary as well as backup domain control modes, the administrator would be well-advised to 56consider alternatives to the use of interdomain trusts simply because, by the very nature of how trusts 57function, this system is fragile. That was, after all, a key reason for the development and adoption of 58Microsoft Active Directory. 59</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2619803"></a>Trust Relationship Background</h2></div></div></div><p> 60<a class="indexterm" name="id2619811"></a> 61<a class="indexterm" name="id2619818"></a> 62<a class="indexterm" name="id2619825"></a> 63<a class="indexterm" name="id2619832"></a> 64<a class="indexterm" name="id2619839"></a> 65<a class="indexterm" name="id2619846"></a> 66MS Windows NT3/4-type security domains employ a nonhierarchical security structure. 67The limitations of this architecture as it effects the scalability of MS Windows networking 68in large organizations is well known. Additionally, the flat namespace that results from 69this design significantly impacts the delegation of administrative responsibilities in 70large and diverse organizations. 71</p><p> 72<a class="indexterm" name="id2619863"></a> 73<a class="indexterm" name="id2619869"></a> 74<a class="indexterm" name="id2619876"></a> 75<a class="indexterm" name="id2619883"></a> 76<a class="indexterm" name="id2619890"></a> 77Microsoft developed Active Directory Service (ADS), based on Kerberos and LDAP, as a means 78of circumventing the limitations of the older technologies. Not every organization is ready 79or willing to embrace ADS. For small companies the older NT4-style domain security paradigm 80is quite adequate, and so there remains an entrenched user base for whom there is no direct 81desire to go through a disruptive change to adopt ADS. 82</p><p> 83<a class="indexterm" name="id2619907"></a> 84<a class="indexterm" name="id2619914"></a> 85<a class="indexterm" name="id2619921"></a> 86<a class="indexterm" name="id2619928"></a> 87<a class="indexterm" name="id2619934"></a> 88<a class="indexterm" name="id2619941"></a> 89<a class="indexterm" name="id2619948"></a> 90With Windows NT, Microsoft introduced the ability to allow different security domains 91to effect a mechanism so users from one domain may be given access rights and privileges 92in another domain. The language that describes this capability is couched in terms of 93<span class="emphasis"><em>trusts</em></span>. Specifically, one domain will <span class="emphasis"><em>trust</em></span> the users 94from another domain. The domain from which users can access another security domain is 95said to be a trusted domain. The domain in which those users have assigned rights and privileges 96is the trusting domain. With NT3.x/4.0 all trust relationships are always in one direction only, 97so if users in both domains are to have privileges and rights in each others' domain, then it is 98necessary to establish two relationships, one in each direction. 99</p><p> 100<a class="indexterm" name="id2619978"></a> 101<a class="indexterm" name="id2619985"></a> 102<a class="indexterm" name="id2619992"></a> 103<a class="indexterm" name="id2619999"></a> 104<a class="indexterm" name="id2620006"></a> 105Further, in an NT4-style MS security domain, all trusts are nontransitive. This means that if there are three 106domains (let's call them red, white, and blue), where red and white have a trust relationship, and white and 107blue have a trust relationship, then it holds that there is no implied trust between the red and blue domains. 108Relationships are explicit and not transitive. 109</p><p> 110<a class="indexterm" name="id2620022"></a> 111<a class="indexterm" name="id2620029"></a> 112<a class="indexterm" name="id2620036"></a> 113<a class="indexterm" name="id2620043"></a> 114<a class="indexterm" name="id2620050"></a> 115<a class="indexterm" name="id2620057"></a> 116<a class="indexterm" name="id2620064"></a> 117New to MS Windows 2000 ADS security contexts is the fact that trust relationships are two-way by default. 118Also, all inter-ADS domain trusts are transitive. In the case of the red, white, and blue domains, with 119Windows 2000 and ADS, the red and blue domains can trust each other. This is an inherent feature of ADS 120domains. Samba-3 implements MS Windows NT4-style interdomain trusts and interoperates with MS Windows 200x ADS 121security domains in similar manner to MS Windows NT4-style domains. 122</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2620081"></a>Native MS Windows NT4 Trusts Configuration</h2></div></div></div><p> 123<a class="indexterm" name="id2620088"></a> 124<a class="indexterm" name="id2620098"></a> 125<a class="indexterm" name="id2620105"></a> 126There are two steps to creating an interdomain trust relationship. To effect a two-way trust 127relationship, it is necessary for each domain administrator to create a trust account for the 128other domain to use in verifying security credentials. 129</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2620117"></a>Creating an NT4 Domain Trust</h3></div></div></div><p> 130<a class="indexterm" name="id2620125"></a> 131<a class="indexterm" name="id2620132"></a> 132<a class="indexterm" name="id2620139"></a> 133<a class="indexterm" name="id2620146"></a> 134<a class="indexterm" name="id2620153"></a> 135For MS Windows NT4, all domain trust relationships are configured using the 136<span class="application">Domain User Manager</span>. This is done from the Domain User Manager Policies 137entry on the menu bar. From the <span class="guimenu">Policy</span> menu, select 138<span class="guimenuitem">Trust Relationships</span>. Next to the lower box labeled 139<span class="guilabel">Permitted to Trust this Domain</span> are two buttons, <span class="guibutton">Add</span> 140and <span class="guibutton">Remove</span>. The <span class="guibutton">Add</span> button will open a panel in which 141to enter the name of the remote domain that will be able to assign access rights to users in 142your domain. You will also need to enter a password for this trust relationship, which the 143trusting domain will use when authenticating users from the trusted domain. 144The password needs to be typed twice (for standard confirmation). 145</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2620214"></a>Completing an NT4 Domain Trust</h3></div></div></div><p> 146<a class="indexterm" name="id2620222"></a> 147<a class="indexterm" name="id2620229"></a> 148<a class="indexterm" name="id2620236"></a> 149<a class="indexterm" name="id2620243"></a> 150<a class="indexterm" name="id2620250"></a> 151<a class="indexterm" name="id2620257"></a> 152A trust relationship will work only when the other (trusting) domain makes the appropriate connections 153with the trusted domain. To consummate the trust relationship, the administrator launches the 154Domain User Manager from the menu selects <span class="guilabel">Policies</span>, then select 155<span class="guilabel">Trust Relationships</span>, and clicks on the <span class="guibutton">Add</span> button 156next to the box that is labeled <span class="guilabel">Trusted Domains</span>. A panel opens in which 157must be entered the name of the remote domain as well as the password assigned to that trust. 158</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2620299"></a>Interdomain Trust Facilities</h3></div></div></div><p> 159<a class="indexterm" name="id2620307"></a> 160<a class="indexterm" name="id2620314"></a> 161<a class="indexterm" name="id2620321"></a> 162<a class="indexterm" name="id2620328"></a> 163<a class="indexterm" name="id2620335"></a> 164<a class="indexterm" name="id2620342"></a> 165A two-way trust relationship is created when two one-way trusts are created, one in each direction. 166Where a one-way trust has been established between two MS Windows NT4 domains (let's call them 167DomA and DomB), the following facilities are created: 168</p><div class="figure"><a name="trusts1"></a><p class="title"><b>Figure�19.1.�Trusts overview.</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/trusts1.png" alt="Trusts overview."></div></div></div><br class="figure-break"><div class="itemizedlist"><ul type="disc"><li><p> 169 DomA (completes the trust connection) <em class="parameter"><code>Trusts</code></em> DomB. 170 </p></li><li><p> 171 DomA is the <em class="parameter"><code>Trusting</code></em> domain. 172 </p></li><li><p> 173 DomB is the <em class="parameter"><code>Trusted</code></em> domain (originates the trust account). 174 </p></li><li><p> 175 Users in DomB can access resources in DomA. 176 </p></li><li><p> 177 Users in DomA cannot access resources in DomB. 178 </p></li><li><p> 179 Global groups from DomB can be used in DomA. 180 </p></li><li><p> 181 Global groups from DomA cannot be used in DomB. 182 </p></li><li><p> 183 DomB does appear in the logon dialog box on client workstations in DomA. 184 </p></li><li><p> 185 DomA does not appear in the logon dialog box on client workstations in DomB. 186 </p></li></ul></div><div class="itemizedlist"><ul type="disc"><li><p> 187 Users and groups in a trusting domain cannot be granted rights, permissions, or access 188 to a trusted domain. 189 </p></li><li><p> 190 The trusting domain can access and use accounts (users/global groups) in the 191 trusted domain. 192 </p></li><li><p> 193 Administrators of the trusted domain can be granted administrative rights in the 194 trusting domain. 195 </p></li><li><p> 196 Users in a trusted domain can be given rights and privileges in the trusting 197 domain. 198 </p></li><li><p> 199 Trusted domain global groups can be given rights and permissions in the trusting 200 domain. 201 </p></li><li><p> 202 Global groups from the trusted domain can be made members in local groups on 203 MS Windows domain member machines. 204 </p></li></ul></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2620508"></a>Configuring Samba NT-Style Domain Trusts</h2></div></div></div><p> 205<a class="indexterm" name="id2620517"></a> 206This description is meant to be a fairly short introduction about how to set up a Samba server so 207that it can participate in interdomain trust relationships. Trust relationship support in Samba 208is at an early stage, so do not be surprised if something does not function as it should. 209</p><p> 210<a class="indexterm" name="id2620532"></a> 211<a class="indexterm" name="id2620538"></a> 212<a class="indexterm" name="id2620545"></a> 213<a class="indexterm" name="id2620552"></a> 214Each of the procedures described next assumes the peer domain in the trust relationship is controlled by a 215Windows NT4 server. However, the remote end could just as well be another Samba-3 domain. It can be clearly 216seen, after reading this document, that combining Samba-specific parts of what's written in the following 217sections leads to trust between domains in a purely Samba environment. 218</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="samba-trusted-domain"></a>Samba as the Trusted Domain</h3></div></div></div><p> 219<a class="indexterm" name="id2620580"></a> 220<a class="indexterm" name="id2620586"></a> 221<a class="indexterm" name="id2620593"></a> 222<a class="indexterm" name="id2620600"></a> 223<a class="indexterm" name="id2620607"></a> 224In order to set the Samba PDC to be the trusted party of the relationship, you first need 225to create a special account for the domain that will be the trusting party. To do that, 226you can use the <code class="literal">smbpasswd</code> utility. Creating the trusted domain account is 227similar to creating a trusted machine account. Suppose, your domain is 228called SAMBA, and the remote domain is called RUMBA. The first step 229will be to issue this command from your favorite shell: 230</p><p> 231</p><pre class="screen"> 232<code class="prompt">root# </code> <strong class="userinput"><code>smbpasswd -a -i rumba</code></strong> 233New SMB password: <strong class="userinput"><code>XXXXXXXX</code></strong> 234Retype SMB password: <strong class="userinput"><code>XXXXXXXX</code></strong> 235Added user rumba$ 236</pre><p> 237 238where <code class="option">-a</code> means to add a new account into the 239passdb database and <code class="option">-i</code> means to “<span class="quote">create this 240account with the Interdomain trust flag</span>”. 241</p><p> 242<a class="indexterm" name="id2620676"></a> 243<a class="indexterm" name="id2620683"></a> 244<a class="indexterm" name="id2620690"></a> 245<a class="indexterm" name="id2620697"></a> 246The account name will be “<span class="quote">rumba$</span>” (the name of the remote domain). 247If this fails, you should check that the trust account has been added to the system 248password database (<code class="filename">/etc/passwd</code>). If it has not been added, you 249can add it manually and then repeat the previous step. 250</p><p> 251<a class="indexterm" name="id2620721"></a> 252<a class="indexterm" name="id2620728"></a> 253<a class="indexterm" name="id2620735"></a> 254<a class="indexterm" name="id2620742"></a> 255After issuing this command, you will be asked to enter the password for the account. You can use any password 256you want, but be aware that Windows NT will not change this password until 7 days following account creation. 257After the command returns successfully, you can look at the entry for the new account (in the standard way as 258appropriate for your configuration) and see that the account's name is really RUMBA$ and it has the 259“<span class="quote">I</span>” flag set in the flags field. Now you are ready to confirm the trust by establishing it from 260Windows NT Server. 261</p><p> 262<a class="indexterm" name="id2620764"></a> 263<a class="indexterm" name="id2620771"></a> 264<a class="indexterm" name="id2620778"></a> 265<a class="indexterm" name="id2620785"></a> 266<a class="indexterm" name="id2620792"></a> 267Open <span class="application">User Manager for Domains</span> and from the <span class="guimenu">Policies</span> menu, select 268<span class="guimenuitem">Trust Relationships...</span>. Beside the <span class="guilabel">Trusted domains</span> list box, 269click the <span class="guimenu">Add...</span> button. You will be prompted for the trusted domain name and the 270relationship password. Type in SAMBA, as this is the name of the remote domain and the password used at the 271time of account creation. Click on <span class="guibutton">OK</span> and, if everything went without incident, you 272will see the <code class="computeroutput">Trusted domain relationship successfully established</code> message. 273</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2620849"></a>Samba as the Trusting Domain</h3></div></div></div><p> 274<a class="indexterm" name="id2620858"></a> 275<a class="indexterm" name="id2620865"></a> 276This time activities are somewhat reversed. Again, we'll assume that your domain 277controlled by the Samba PDC is called SAMBA and the NT-controlled domain is called RUMBA. 278</p><p> 279The very first step is to add an account for the SAMBA domain on RUMBA's PDC. 280</p><p> 281<a class="indexterm" name="id2620882"></a> 282<a class="indexterm" name="id2620889"></a> 283<a class="indexterm" name="id2620896"></a> 284Launch the <span class="application">Domain User Manager</span>, then from the menu select 285<span class="guimenu">Policies</span>, <span class="guimenuitem">Trust Relationships</span>. 286Now, next to the <span class="guilabel">Trusting Domains</span> box, press the <span class="guibutton">Add</span> 287button and type in the name of the trusted domain (SAMBA) and the password to use in securing 288the relationship. 289</p><p> 290<a class="indexterm" name="id2620939"></a> 291<a class="indexterm" name="id2620945"></a> 292The password can be arbitrarily chosen. It is easy to change the password from the Samba server whenever you 293want. After you confirm the password, your account is ready for use. Now its Samba's turn. 294</p><p> 295Using your favorite shell while logged in as root, issue this command: 296<a class="indexterm" name="id2620960"></a> 297</p><p> 298<code class="prompt">root# </code><strong class="userinput"><code>net rpc trustdom establish rumba</code></strong> 299</p><p> 300<a class="indexterm" name="id2620989"></a> 301<a class="indexterm" name="id2620996"></a> 302<a class="indexterm" name="id2621003"></a> 303You will be prompted for the password you just typed on your Windows NT4 Server box. 304An error message, <code class="literal">"NT_STATUS_NOLOGON_INTERDOMAIN_TRUST_ACCOUNT,"</code> 305that may be reported periodically is of no concern and may safely be ignored. 306It means the password you gave is correct and the NT4 server says the account is ready for 307interdomain connection and not for ordinary connection. After that, be patient; 308it can take a while (especially in large networks), but eventually you should see 309the <code class="literal">Success</code> message. Congratulations! Your trust 310relationship has just been established. 311</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> 312You have to run this command as root because you must have write access to 313the <code class="filename">secrets.tdb</code> file. 314</p></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2621046"></a>NT4-Style Domain Trusts with Windows 2000</h2></div></div></div><p> 315<a class="indexterm" name="id2621054"></a> 316<a class="indexterm" name="id2621061"></a> 317<a class="indexterm" name="id2621068"></a> 318<a class="indexterm" name="id2621075"></a> 319Although <span class="application">Domain User Manager</span> is not present in Windows 2000, it is 320also possible to establish an NT4-style trust relationship with a Windows 2000 domain 321controller running in mixed mode as the trusting server. It should also be possible for 322Samba to trust a Windows 2000 server; however, more testing is still needed in this area. 323</p><p> 324<a class="indexterm" name="id2621096"></a> 325<a class="indexterm" name="id2621103"></a> 326<a class="indexterm" name="id2621110"></a> 327<a class="indexterm" name="id2621117"></a> 328After <a class="link" href="InterdomainTrusts.html#samba-trusted-domain" title="Samba as the Trusted Domain">creating the interdomain trust account on the Samba server</a> 329as described previously, open <span class="application">Active Directory Domains and Trusts</span> on the AD 330controller of the domain whose resources you wish Samba users to have access to. Remember that since NT4-style 331trusts are not transitive, if you want your users to have access to multiple mixed-mode domains in your AD 332forest, you will need to repeat this process for each of those domains. With <span class="application">Active Directory 333domains and trusts</span> open, right-click on the name of the Active Directory domain that will trust 334our Samba domain and choose <span class="guimenuitem">Properties</span>, then click on the 335<span class="guilabel">Trusts</span> tab. In the upper part of the panel, you will see a list box labeled 336<span class="guilabel">Domains trusted by this domain:</span> and an <span class="guilabel">Add...</span> button next to it. 337Press this button and, just as with NT4, you will be prompted for the trusted domain name and the relationship 338password. Press <span class="emphasis"><em>OK</em></span> and after a moment, Active Directory will respond with 339<code class="computeroutput">The trusted domain has been added and the trust has been verified.</code> Your 340Samba users can now be granted access to resources in the AD domain. 341</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2621195"></a>Common Errors</h2></div></div></div><p> 342Interdomain trust relationships should not be attempted on networks that are unstable 343or that suffer regular outages. Network stability and integrity are key concerns with 344distributed trusted domains. 345</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2621208"></a>Browsing of Trusted Domain Fails</h3></div></div></div><p> 346<span class="emphasis"><em>Browsing from a machine in a trusted Windows 200x domain to a Windows 200x member of 347a trusting Samba domain, I get the following error:</em></span> 348</p><pre class="screen"> 349The system detected a possible attempt to compromise security. Please 350ensure that you can contact the server that authenticated you. 351</pre><p> 352</p><p> 353<span class="emphasis"><em>The event logs on the box I'm trying to connect to have entries regarding group 354policy not being applied because it is a member of a down-level domain.</em></span> 355</p><p>If there is a computer account in the Windows 356200x domain for the machine in question, and it is disabled, this problem can 357occur. If there is no computer account (removed or never existed), or if that 358account is still intact (i.e., you just joined it to another domain), everything 359seems to be fine. By default, when you unjoin a domain (the Windows 200x 360domain), the computer tries to automatically disable the computer account in 361the domain. If you are running as an account that has privileges to do this 362when you unjoin the machine, it is done; otherwise it is not done. 363</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2621254"></a>Problems with LDAP ldapsam and Older Versions of smbldap-tools</h3></div></div></div><p> 364If you use the <code class="literal">smbldap-useradd</code> script to create a trust 365account to set up interdomain trusts, the process of setting up the trust will 366fail. The account that was created in the LDAP database will have an account 367flags field that has <code class="literal">[W ]</code>, when it must have 368<code class="literal">[I ]</code> for interdomain trusts to work. 369</p><p>Here is a simple solution. 370Create a machine account as follows: 371</p><pre class="screen"> 372<code class="prompt">root# </code> smbldap-useradd -w domain_name 373</pre><p> 374Then set the desired trust account password as shown here: 375</p><pre class="screen"> 376<code class="prompt">root# </code> smbldap-passwd domain_name\$ 377</pre><p> 378Using a text editor, create the following file: 379</p><pre class="screen"> 380dn: uid=domain_name$,ou=People,dc={your-domain},dc={your-top-level-domain} 381changetype: modify 382sambaAcctFlags: [I ] 383</pre><p> 384Then apply the text file to the LDAP database as follows: 385</p><pre class="screen"> 386<code class="prompt">root# </code> ldapmodify -x -h localhost \ 387 -D "cn=Manager,dc={your-domain},dc={your-top-level-domain}" \ 388 -W -f /path-to/foobar 389</pre><p> 390Create a single-sided trust under the NT4 Domain User Manager, then execute: 391</p><pre class="screen"> 392<code class="prompt">root# </code> net rpc trustdom establish domain_name 393</pre><p> 394</p><p> 395It works with Samba-3 and NT4 domains, and also with Samba-3 and Windows 200x ADS in mixed mode. 396Both domain controllers, Samba and NT must have the same WINS server; otherwise, 397the trust will never work. 398</p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="securing-samba.html">Prev</a>�</td><td width="20%" align="center"><a accesskey="u" href="optional.html">Up</a></td><td width="40%" align="right">�<a accesskey="n" href="msdfs.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter�18.�Securing Samba�</td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top">�Chapter�20.�Hosting a Microsoft Distributed File System Tree</td></tr></table></div></body></html> 399
