Add all the source files from the old CVS tree,
[Samba.git] / docs / howto / InterdomainTrusts.xml
blob22ccb2e7c3e5d13a59ec32118908674173d4fe85
1 <chapter id="InterdomainTrusts">
2 <chapterinfo>
3         &author.jht;
4         &author.mimir;
5         <author>&person.jelmer;<contrib>drawing</contrib></author>
6         <author>
7                 <firstname>Stephen</firstname><surname>Langasek</surname>
8                 <affiliation>
9                         <address><email>vorlon@netexpress.net</email></address>
10                 </affiliation>
11         </author>
12         <pubdate>April 3, 2003</pubdate>
13 </chapterinfo>
15 <title>Interdomain Trust Relationships</title>
18 <para>
19 <indexterm><primary>Interdomain Trusts</primary></indexterm>
20 Samba-3 supports NT4-style domain trust relationships. This is a feature that many sites
21 will want to use if they migrate to Samba-3 from an NT4-style domain and do not want to
22 adopt Active Directory or an LDAP-based authentication backend. This section explains
23 some background information regarding trust relationships and how to create them. It is now
24 possible for Samba-3 to trust NT4 (and vice versa), as well as to create Samba-to-Samba 
25 trusts.
26 </para>
28 <sect1>
29 <title>Features and Benefits</title>
31 <para>
32 Samba-3 can participate in Samba-to-Samba as well as in Samba-to-MS Windows NT4-style
33 trust relationships. This imparts to Samba similar scalability as with MS Windows NT4.
34 </para>
36 <para>
37 Given that Samba-3 has the capability to function with a scalable backend authentication
38 database such as LDAP, and given its ability to run in Primary as well as Backup Domain Control
39 modes, the administrator would be well advised to consider alternatives to the use of
40 Interdomain trusts simply because by the very nature of how this works it is fragile.
41 That was, after all, a key reason for the development and adoption of Microsoft Active Directory.
42 </para>
44 </sect1>
46 <sect1>
47 <title>Trust Relationship Background</title>
49 <para>
50 MS Windows NT3/4 type security domains employ a non-hierarchical security structure.
51 The limitations of this architecture as it effects the scalability of MS Windows networking
52 in large organizations is well known. Additionally, the flat namespace that results from
53 this design significantly impacts the delegation of administrative responsibilities in
54 large and diverse organizations.
55 </para>
57 <para>
58 Microsoft developed Active Directory Service (ADS), based on Kerberos and LDAP, as a means
59 of circumventing the limitations of the older technologies. Not every organization is ready
60 or willing to embrace ADS. For small companies the older NT4-style domain security paradigm
61 is quite adequate, there remains an entrenched user base for whom there is no direct
62 desire to go through a disruptive change to adopt ADS.
63 </para>
65 <para>
66 With MS Windows NT, Microsoft introduced the ability to allow differing security domains
67 to effect a mechanism so users from one domain may be given access rights and privileges
68 in another domain. The language that describes this capability is couched in terms of
69 <emphasis>Trusts</emphasis>. Specifically, one domain will <emphasis>trust</emphasis> the users
70 from another domain. The domain from which users are available to another security domain is
71 said to be a trusted domain. The domain in which those users have assigned rights and privileges
72 is the trusting domain. With NT3.x/4.0 all trust relationships are always in one direction only,
73 thus if users in both domains are to have privileges and rights in each others' domain, then it is
74 necessary to establish two relationships, one in each direction.
75 </para>
77 <para>
78 In an NT4-style MS security domain, all trusts are non-transitive. This means that if there
79 are three domains (let's call them RED, WHITE and BLUE) where RED and WHITE have a trust
80 relationship, and WHITE and BLUE have a trust relationship, then it holds that there is no
81 implied trust between the RED and BLUE domains. Relationships are explicit and not
82 transitive.
83 </para>
85 <para>
86 New to MS Windows 2000 ADS security contexts is the fact that trust relationships are two-way
87 by default. Also, all inter-ADS domain trusts are transitive. In the case of the RED, WHITE and BLUE
88 domains above, with Windows 2000 and ADS the RED and BLUE domains can trust each other. This is
89 an inherent feature of ADS domains. Samba-3 implements MS Windows NT4-style Interdomain trusts
90 and interoperates with MS Windows 200x ADS security domains in similar manner to MS Windows NT4-style domains.
91 </para>
93 </sect1>
95 <sect1>
96 <title>Native MS Windows NT4 Trusts Configuration</title>
98 <para>
99 There are two steps to creating an interdomain trust relationship. To effect a two-way trust
100 relationship, it is necessary for each domain administrator to create a trust account for the 
101 other domain to use in verifying security credentials.
102 <indexterm><primary>Interdomain Trusts</primary><secondary>creating</secondary></indexterm>
103 </para>
106 <sect2>
107 <title>Creating an NT4 Domain Trust</title>
109 <para>
110 For MS Windows NT4, all domain trust relationships are configured using the 
111 <application>Domain User Manager</application>. This is done from the Domain User Manager Policies
112 entry on the menu bar. From the <guimenu>Policy</guimenu> menu, select
113 <guimenuitem>Trust Relationships</guimenuitem>. Next to the lower box labeled
114 <guilabel>Permitted to Trust this Domain</guilabel> are two buttons, <guibutton>Add</guibutton>
115 and <guibutton>Remove</guibutton>. The <guibutton>Add</guibutton> button will open a panel in which
116 to enter the name of the remote domain that will be able to assign access rights to users in 
117 your domain. You will also need to enter a password for this trust relationship, which the 
118 trusting domain will use when authenticating users from the trusted domain.
119 The password needs to be typed twice (for standard confirmation).
120 </para>
122 </sect2>
125 <sect2>
126 <title>Completing an NT4 Domain Trust</title>
128 <para>
129 <indexterm><primary>Interdomain Trusts</primary><secondary>Completing</secondary></indexterm>
130 A trust relationship will work only when the other (trusting) domain makes the appropriate connections
131 with the trusted domain. To consummate the trust relationship, the administrator will launch the
132 Domain User Manager from the menu select <guilabel>Policies</guilabel>, then select
133 <guilabel>Trust Relationships</guilabel>, click on the <guibutton>Add</guibutton> button
134 next to the box that is labeled <guilabel>Trusted Domains</guilabel>. A panel will open in which
135 must be entered the name of the remote domain as well as the password assigned to that trust.
136 </para>
138 </sect2>
140 <sect2>
141 <title>Inter-Domain Trust Facilities</title>
144 <para>
145 <indexterm><primary>Interdomain Trusts</primary><secondary>Facilities</secondary></indexterm>
146 A two-way trust relationship is created when two one-way trusts are created, one in each direction.
147 Where a one-way trust has been established between two MS Windows NT4 domains (let's call them
148 DomA and DomB), the following facilities are created:
149 </para>
151 <image id="trusts1"><imagefile>trusts1</imagefile><imagedescription>Trusts overview.</imagedescription></image>
153 <itemizedlist>
154         <listitem><para>
155         DomA (completes the trust connection) <parameter>Trusts</parameter> DomB.
156         </para></listitem>
158         <listitem><para>
159         DomA is the <parameter>Trusting</parameter> domain.
160         </para></listitem>
162         <listitem><para>
163         DomB is the <parameter>Trusted</parameter> domain (originates the trust account).
164         </para></listitem>
166         <listitem><para>
167         Users in DomB can access resources in DomA.
168         </para></listitem>
170         <listitem><para>
171         Users in DomA cannot access resources in DomB.
172         </para></listitem>
174         <listitem><para>
175         Global groups from DomB can be used in DomA.
176         </para></listitem>
178         <listitem><para>
179         Global groups from DomA cannot be used in DomB.
180         </para></listitem>
182         <listitem><para>
183         DomB does appear in the logon dialog box on client workstations in DomA.
184         </para></listitem>
186         <listitem><para>
187         DomA does not appear in the logon dialog box on client workstations in DomB.
188         </para></listitem>
189 </itemizedlist>
191 <itemizedlist>
192         <listitem><para>
193         Users/Groups in a trusting domain cannot be granted rights, permissions or access
194         to a trusted domain.
195         </para></listitem>
197         <listitem><para>
198         The trusting domain can access and use accounts (Users/Global Groups) in the
199         trusted domain.
200         </para></listitem>
202         <listitem><para>
203         Administrators of the trusted domain can be granted administrative rights in the 
204         trusting domain.
205         </para></listitem>
207         <listitem><para>
208         Users in a trusted domain can be given rights and privileges in the trusting
209         domain.
210         </para></listitem>
212         <listitem><para>
213         Trusted domain Global Groups can be given rights and permissions in the trusting
214         domain.
215         </para></listitem>
217         <listitem><para>
218         Global Groups from the trusted domain can be made members in Local Groups on
219         MS Windows Domain Member machines.
220         </para></listitem>
221 </itemizedlist>
223 </sect2>
225 </sect1>
227 <sect1>
228 <title>Configuring Samba NT-Style Domain Trusts</title>
230 <para>
231 This description is meant to be a fairly short introduction about how to set up a Samba server so
232 that it can participate in interdomain trust relationships. Trust relationship support in Samba
233 is at an early stage, so do not be surprised if something does not function as it should.
234 </para>
236 <para>
237 Each of the procedures described below assumes the peer domain in the trust relationship is 
238 controlled by a Windows NT4 server. However, the remote end could just as well be another 
239 Samba-3  domain. It can be clearly seen, after reading this document, that combining 
240 Samba-specific parts of what's written below leads to trust between domains in a purely Samba 
241 environment.
242 </para>
244 <sect2 id="samba-trusted-domain">
245 <title>Samba as the Trusted Domain</title>
247 <para>
248 In order to set the Samba PDC to be the trusted party of the relationship, you first need
249 to create a special account for the domain that will be the trusting party. To do that,
250 you can use the <command>smbpasswd</command> utility. Creating the trusted domain account is 
251 similar to creating a trusted machine account. Suppose, your domain is
252 called SAMBA, and the remote domain is called RUMBA. The first step
253 will be to issue this command from your favorite shell:
254 </para>
256 <para>
257 <screen>
258 &rootprompt; <userinput>smbpasswd -a -i rumba</userinput>
259 New SMB password: <userinput>XXXXXXXX</userinput>
260 Retype SMB password: <userinput>XXXXXXXX</userinput>
261 Added user rumba$
262 </screen>
264 where <option>-a</option> means to add a new account into the
265 passdb database and <option>-i</option> means: <quote>create this
266 account with the Inter-Domain trust flag</quote>.
267 </para>
269 <para>
270 The account name will be <quote>rumba$</quote> (the name of the remote domain).
271 If this fails, you should check that the trust account has been added to the system
272 password database (<filename>/etc/passwd</filename>). If it has not been added, you
273 can add it manually and then repeat the step above.
274 </para>
276 <para>
277 After issuing this command, you will be asked to enter the password for
278 the account. You can use any password you want, but be aware that Windows NT will
279 not change this password until seven days following account creation.
280 After the command returns successfully, you can look at the entry for the new account
281 (in the standard way as appropriate for your configuration) and see that accounts name is
282 really RUMBA$ and it has the <quote>I</quote> flag set in the flags field. Now you are ready to confirm
283 the trust by establishing it from Windows NT Server.
284 </para>
287 <para>
288 <indexterm><primary>User Manager</primary></indexterm>
289 Open <application>User Manager for Domains</application> and from the
290 <guimenu>Policies</guimenu> menu, select <guimenuitem>Trust Relationships...</guimenuitem>.
291 Beside the <guilabel>Trusted domains</guilabel> list box click the
292 <guimenu>Add...</guimenu> button. You will be prompted for
293 the trusted domain name and the relationship password. Type in SAMBA, as this is
294 the name of the remote domain and the password used at the time of account creation.
295 Click on <guibutton>OK</guibutton> and, if everything went without incident, you will see 
296 the <computeroutput>Trusted domain relationship successfully 
297 established</computeroutput> message.
298 </para>
300 </sect2>
301 <sect2>
302 <title>Samba as the Trusting Domain</title>
304 <para>
305 This time activities are somewhat reversed. Again, we'll assume that your domain
306 controlled by the Samba PDC is called SAMBA and the NT-controlled domain is called RUMBA.
307 </para>
309 <para>
310 The very first step is to add an account for the SAMBA domain on RUMBA's PDC.
311 </para>
314 <para>
315 <indexterm><primary>User Manager</primary></indexterm>
316 Launch the <application>Domain User Manager</application>, then from the menu select
317 <guimenu>Policies</guimenu>, <guimenuitem>Trust Relationships</guimenuitem>.
318 Now, next to the <guilabel>Trusted Domains</guilabel> box press the <guibutton>Add</guibutton>
319 button and type in the name of the trusted domain (SAMBA) and the password to use in securing
320 the relationship.
321 </para>
323 <para>
324 The password can be arbitrarily chosen. It is easy to change the password
325 from the Samba server whenever you want. After confirming the password your account is
326 ready for use. Now its Samba's turn.
327 </para>
329 <para>
330 Using your favorite shell while being logged in as root, issue this command:
331 </para>
333 <para>
334 &rootprompt;<userinput>net rpc trustdom establish rumba</userinput>
335 </para>
337 <para>
338 You will be prompted for the password you just typed on your Windows NT4 Server box.
339 An error message <errorname>`NT_STATUS_NOLOGON_INTERDOMAIN_TRUST_ACCOUNT'</errorname>
340 that may be reported periodically is of no concern and may safely be ignored.
341 It means the password you gave is correct and the NT4 Server says the account is ready for
342 interdomain connection and not for ordinary connection.  After that, be patient;
343 it can take a while (especially in large networks), but eventually you should see
344 the <computeroutput>Success</computeroutput> message. Congratulations! Your trust
345 relationship has just been established.
346 </para>
348 <note><para>
349 You have to run this command as root because you must have write access to
350 the <filename>secrets.tdb</filename> file.
351 </para></note>
353 </sect2>
354 </sect1>
356 <sect1>
357 <title>NT4-Style Domain Trusts with Windows 2000</title>
358 <para>
359 Although <application>Domain User Manager</application> is not present in Windows 2000, it is 
360 also possible to establish an NT4-style trust relationship with a Windows 2000 domain 
361 controller running in mixed mode as the trusting server. It should also be possible for 
362 Samba to trust a Windows 2000 server, however, more testing is still needed in this area.
363 </para>
365 <para>
366 After <link linkend="samba-trusted-domain">creating the interdomain trust account on the 
367 Samba server</link> as described above, open <application>Active Directory Domains and 
368 Trusts</application> on the AD controller of the domain whose resources you wish Samba users 
369 to have access to. Remember that since NT4-style trusts are not transitive, if you want 
370 your users to have access to multiple mixed-mode domains in your AD forest, you will need to 
371 repeat this process for each of those domains. With <application>Active Directory Domains 
372 and Trusts</application> open, right-click on the name of the Active Directory domain that 
373 will trust our Samba domain and choose <guimenuitem>Properties</guimenuitem>, then click on
374 the <guilabel>Trusts</guilabel> tab. In the upper part of the panel, you will see a list box 
375 labeled <guilabel>Domains trusted by this domain:</guilabel>, and an 
376 <guilabel>Add...</guilabel> button next to it. Press this button and just as with NT4, you 
377 will be prompted for the trusted domain name and the relationship password. Press OK and 
378 after a moment, Active Directory will respond with <computeroutput>The trusted domain has 
379 been added and the trust has been verified.</computeroutput>  Your Samba users can now be 
380 granted access to resources in the AD domain.
381 </para>
382 </sect1>
384 <sect1>
385 <title>Common Errors</title>
387 <para>
388 Interdomain trust relationships should not be attempted on networks that are unstable
389 or that suffer regular outages. Network stability and integrity are key concerns with
390 distributed trusted domains.
391 </para>
393 <sect2>
394 <title>Browsing of Trusted Domain Fails</title>
396 <para>
397 Browsing from a machine in a trusted Windows 200x Domain to a Windows 200x member of
398 a trusting samba domain, I get the following error:
399 </para>
401 <formalpara><emphasis>
402 The system detected a possible attempt to compromise security. Please ensure that
403 you can contact the server that authenticated you.</emphasis>
404 </formalpara>
406 <para>
407 The event logs on the box I'm trying to connect to have entries regarding group
408 policy not being applied because it is a member of a down-level domain.
409 </para>
411 <para><emphasis>Answer: </emphasis> If there is a computer account in the Windows
412 200x Domain for the machine in question, and it is disabled, this problem can
413 occur.  If there is no computer account (removed or never existed), or if that 
414 account is still intact (i.e.: you just joined it to another domain) everything 
415 seems to be fine. By default, when you un-join a domain (the Windows 200x 
416 Domain), the computer tries to automatically disable the computer account in 
417 the domain.  If you are running as an account which has privileges to do this 
418 when you un-join the machine, it is done, otherwise it is not done.
419 </para>
421 </sect2>
423 <sect2>
424 <title>Problems With LDAP ldapsam And The smbldap-tools</title>
426 <para>
427 If you use the <command>smbldap-useradd.pl</command> script to create a trust
428 account to set up Interdomain trusts the process of setting up the trust will
429 fail. The account that was created in the LDAP database will have an account
430 flags field that has <constant>[W          ]</constant>, when it must have
431 <constant>[I          ]</constant> for Interdomain trusts to work.
432 </para>
434 <para><emphasis>Answer: </emphasis>Here is a simple solution.
435 Create a machine account as follows:
436 <screen>
437 &rootprompt; smbldap-useradd.pl -w domain_name
438 </screen>
439 Then set the desired trust account password as shown here:
440 <screen>
441 &rootprompt; smbldap-passwd.pl domain_name\$
442 </screen>
443 Using a text editor, create the following file:
444 <screen>
445 dn: uid=domain_name$,ou=People,dc={your-domain},dc={your-top-level-domain}
446 changetype: modify
447 sambaAcctFlags: [I         ]
448 </screen>
449 Then apply the text file to the LDAP database as follows:
450 <screen>
451 &rootprompt; ldapmodify -x -h localhost \
452  -D "cn=Manager,dc={your-domain},dc={your-top-level-domain}" \
453  -W -f /path-to/foobar
454 </screen>
455 Create a single-sided trust under the NT4 Domain User Manager, then execute:
456 <screen>
457 &rootprompt; net rpc trustdom establish domain_name
458 </screen>
459 </para>
461 <para>
462 It works with Samba-3  and NT4 Domains, and also with Samba-3 and Windows 200x ADS in mixed mode.
463 Both DC's, samba and NT, must have the same WINS server otherwise
464 the trust will never work. 
465 </para>
467 </sect2>
469 </sect1>
471 </chapter>