1<?xml version="1.0" encoding="iso-8859-1"?> 2<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc"> 3<chapter id="InterdomainTrusts"> 4<chapterinfo> 5 &author.jht; 6 &author.mimir; 7 <author>&person.jelmer;<contrib>drawing</contrib></author> 8 <author> 9 <firstname>Stephen</firstname><surname>Langasek</surname> 10 <affiliation> 11 <address><email>vorlon@netexpress.net</email></address> 12 </affiliation> 13 </author> 14 <pubdate>April 3, 2003</pubdate> 15</chapterinfo> 16 17<title>Interdomain Trust Relationships</title> 18 19 20<para> 21<indexterm><primary>Interdomain Trusts</primary></indexterm> 22<indexterm><primary>LDAP</primary></indexterm> 23<indexterm><primary>trusts</primary></indexterm> 24<indexterm><primary>samba-to-samba trusts</primary></indexterm> 25<indexterm><primary>Active Directory</primary></indexterm> 26<indexterm><primary>NT4-style domain</primary></indexterm> 27<indexterm><primary>trust relationships</primary></indexterm> 28<indexterm><primary>ADS</primary></indexterm> 29<indexterm><primary>LDAP-based</primary></indexterm> 30Samba-3 supports NT4-style domain trust relationships. This is a feature that many sites 31will want to use if they migrate to Samba-3 from an NT4-style domain and do not want to 32adopt Active Directory or an LDAP-based authentication backend. This chapter explains 33some background information regarding trust relationships and how to create them. It is now 34possible for Samba-3 to trust NT4 (and vice versa), as well as to create Samba-to-Samba 35trusts. 36</para> 37 38<para> 39<indexterm><primary>winbind</primary></indexterm> 40<indexterm><primary>UID range</primary></indexterm> 41<indexterm><primary>GID range</primary></indexterm> 42<indexterm><primary>daemon</primary></indexterm> 43<indexterm><primary>winbindd</primary></indexterm> 44The use of interdomain trusts requires use of <command>winbind</command>, so the 45<command>winbindd</command> daemon must be running. Winbind operation in this mode is 46dependent on the specification of a valid UID range and a valid GID range in the &smb.conf; file. 47These are specified respectively using: 48<smbconfblock> 49<smbconfoption name="idmap uid">10000-20000</smbconfoption> 50<smbconfoption name="idmap gid">10000-20000</smbconfoption> 51</smbconfblock> 52<indexterm><primary>passdb backend</primary></indexterm> 53<indexterm><primary>POSIX user accounts</primary></indexterm> 54<indexterm><primary>maximum value</primary></indexterm> 55<indexterm><primary>4294967295</primary></indexterm> 56The range of values specified must not overlap values used by the host operating system and must 57not overlap values used in the passdb backend for POSIX user accounts. The maximum value is 58limited by the upper-most value permitted by the host operating system. This is a UNIX kernel 59limited parameter. Linux kernel 2.6-based systems support a maximum value of 4294967295 60(32-bit unsigned variable). 61</para> 62 63<note><para> 64<indexterm><primary>winbind</primary></indexterm> 65<indexterm><primary>trusting domain</primary></indexterm> 66<indexterm><primary>trusted domain</primary></indexterm> 67The use of winbind is necessary only when Samba is the trusting domain, not when it is the 68trusted domain. 69</para></note> 70 71<sect1> 72<title>Features and Benefits</title> 73 74<para> 75<indexterm><primary>scalability</primary></indexterm> 76<indexterm><primary>trust relationships</primary></indexterm> 77Samba-3 can participate in Samba-to-Samba as well as in Samba-to-MS Windows NT4-style 78trust relationships. This imparts to Samba scalability similar to that with MS Windows NT4. 79</para> 80 81<para> 82<indexterm><primary>scalable backend</primary></indexterm> 83<indexterm><primary>authentication database</primary></indexterm> 84<indexterm><primary>LDAP</primary></indexterm> 85<indexterm><primary>interdomain trusts</primary></indexterm> 86<indexterm><primary>ADS</primary></indexterm> 87Given that Samba-3 can function with a scalable backend authentication database such as LDAP, and given its 88ability to run in primary as well as backup domain control modes, the administrator would be well-advised to 89consider alternatives to the use of interdomain trusts simply because, by the very nature of how trusts 90function, this system is fragile. That was, after all, a key reason for the development and adoption of 91Microsoft Active Directory. 92</para> 93 94</sect1> 95 96<sect1> 97<title>Trust Relationship Background</title> 98 99<para> 100<indexterm><primary>security domains</primary></indexterm> 101<indexterm><primary>nonhierarchical</primary></indexterm> 102<indexterm><primary>security structure</primary></indexterm> 103<indexterm><primary>large organizations</primary></indexterm> 104<indexterm><primary>delegation</primary></indexterm> 105<indexterm><primary>administrative responsibilities</primary></indexterm> 106MS Windows NT3/4-type security domains employ a nonhierarchical security structure. 107The limitations of this architecture as it effects the scalability of MS Windows networking 108in large organizations is well known. Additionally, the flat namespace that results from 109this design significantly impacts the delegation of administrative responsibilities in 110large and diverse organizations. 111</para> 112 113<para> 114<indexterm><primary>ADS</primary></indexterm> 115<indexterm><primary>Kerberos</primary></indexterm> 116<indexterm><primary>LDAP</primary></indexterm> 117<indexterm><primary>limitations</primary></indexterm> 118<indexterm><primary>domain security</primary></indexterm> 119Microsoft developed Active Directory Service (ADS), based on Kerberos and LDAP, as a means 120of circumventing the limitations of the older technologies. Not every organization is ready 121or willing to embrace ADS. For small companies the older NT4-style domain security paradigm 122is quite adequate, and so there remains an entrenched user base for whom there is no direct 123desire to go through a disruptive change to adopt ADS. 124</para> 125 126<para> 127<indexterm><primary>security domains</primary></indexterm> 128<indexterm><primary>access rights</primary></indexterm> 129<indexterm><primary>privileges</primary></indexterm> 130<indexterm><primary>trusts</primary></indexterm> 131<indexterm><primary>trusted domain</primary></indexterm> 132<indexterm><primary>trusting domain</primary></indexterm> 133<indexterm><primary>one direction</primary></indexterm> 134With Windows NT, Microsoft introduced the ability to allow different security domains 135to effect a mechanism so users from one domain may be given access rights and privileges 136in another domain. The language that describes this capability is couched in terms of 137<emphasis>trusts</emphasis>. Specifically, one domain will <emphasis>trust</emphasis> the users 138from another domain. The domain from which users can access another security domain is 139said to be a trusted domain. The domain in which those users have assigned rights and privileges 140is the trusting domain. With NT3.x/4.0 all trust relationships are always in one direction only, 141so if users in both domains are to have privileges and rights in each others' domain, then it is 142necessary to establish two relationships, one in each direction. 143</para> 144 145<para> 146<indexterm><primary>security domain</primary></indexterm> 147<indexterm><primary>nontransitive</primary></indexterm> 148<indexterm><primary>trust relationship</primary></indexterm> 149<indexterm><primary>transitive</primary></indexterm> 150<indexterm><primary>explicit trust</primary></indexterm> 151Further, in an NT4-style MS security domain, all trusts are nontransitive. This means that if there are three 152domains (let's call them red, white, and blue), where red and white have a trust relationship, and white and 153blue have a trust relationship, then it holds that there is no implied trust between the red and blue domains. 154Relationships are explicit and not transitive. 155</para> 156 157<para> 158<indexterm><primary>ADS</primary></indexterm> 159<indexterm><primary>security contexts</primary></indexterm> 160<indexterm><primary>trust relationships</primary></indexterm> 161<indexterm><primary>two-way trust</primary></indexterm> 162<indexterm><primary>Windows 2000</primary></indexterm> 163<indexterm><primary>security domains</primary></indexterm> 164<indexterm><primary>NT4-style domains</primary></indexterm> 165New to MS Windows 2000 ADS security contexts is the fact that trust relationships are two-way by default. 166Also, all inter-ADS domain trusts are transitive. In the case of the red, white, and blue domains, with 167Windows 2000 and ADS, the red and blue domains can trust each other. This is an inherent feature of ADS 168domains. Samba-3 implements MS Windows NT4-style interdomain trusts and interoperates with MS Windows 200x ADS 169security domains in similar manner to MS Windows NT4-style domains. 170</para> 171 172</sect1> 173 174<sect1> 175<title>Native MS Windows NT4 Trusts Configuration</title> 176 177<para> 178<indexterm><primary>Interdomain Trusts</primary><secondary>creating</secondary></indexterm> 179<indexterm><primary>two-way trust</primary></indexterm> 180<indexterm><primary>security credentials</primary></indexterm> 181There are two steps to creating an interdomain trust relationship. To effect a two-way trust 182relationship, it is necessary for each domain administrator to create a trust account for the 183other domain to use in verifying security credentials. 184</para> 185 186 187<sect2> 188<title>Creating an NT4 Domain Trust</title> 189 190<para> 191<indexterm><primary>domain trust</primary></indexterm> 192<indexterm><primary>trust relationships</primary></indexterm> 193<indexterm><primary>>Domain User Manager</primary></indexterm> 194<indexterm><primary>remote domain</primary></indexterm> 195<indexterm><primary>standard confirmation</primary></indexterm> 196For MS Windows NT4, all domain trust relationships are configured using the 197<application>Domain User Manager</application>. This is done from the Domain User Manager Policies 198entry on the menu bar. From the <guimenu>Policy</guimenu> menu, select 199<guimenuitem>Trust Relationships</guimenuitem>. Next to the lower box labeled 200<guilabel>Permitted to Trust this Domain</guilabel> are two buttons, <guibutton>Add</guibutton> 201and <guibutton>Remove</guibutton>. The <guibutton>Add</guibutton> button will open a panel in which 202to enter the name of the remote domain that will be able to assign access rights to users in 203your domain. You will also need to enter a password for this trust relationship, which the 204trusting domain will use when authenticating users from the trusted domain. 205The password needs to be typed twice (for standard confirmation). 206</para> 207 208</sect2> 209 210 211<sect2> 212<title>Completing an NT4 Domain Trust</title> 213 214<para> 215<indexterm><primary>trust relationship</primary></indexterm> 216<indexterm><primary>trusting domain</primary></indexterm> 217<indexterm><primary>trusted domain</primary></indexterm> 218<indexterm><primary>remote domain</primary></indexterm> 219<indexterm><primary>password assigned</primary></indexterm> 220<indexterm><primary>Interdomain Trusts</primary><secondary>Completing</secondary></indexterm> 221A trust relationship will work only when the other (trusting) domain makes the appropriate connections 222with the trusted domain. To consummate the trust relationship, the administrator launches the 223Domain User Manager from the menu selects <guilabel>Policies</guilabel>, then select 224<guilabel>Trust Relationships</guilabel>, and clicks on the <guibutton>Add</guibutton> button 225next to the box that is labeled <guilabel>Trusted Domains</guilabel>. A panel opens in which 226must be entered the name of the remote domain as well as the password assigned to that trust. 227</para> 228 229</sect2> 230 231<sect2> 232<title>Interdomain Trust Facilities</title> 233 234 235<para> 236<indexterm><primary>two-way trust</primary></indexterm> 237<indexterm><primary>trust relationship</primary></indexterm> 238<indexterm><primary>trust established</primary></indexterm> 239<indexterm><primary>one-way trust</primary></indexterm> 240<indexterm><primary>Windows NT4 domains</primary></indexterm> 241<indexterm><primary>Interdomain Trusts</primary><secondary>Facilities</secondary></indexterm> 242A two-way trust relationship is created when two one-way trusts are created, one in each direction. 243Where a one-way trust has been established between two MS Windows NT4 domains (let's call them 244DomA and DomB), the following facilities are created: 245</para> 246 247<figure id="trusts1"> 248 <title>Trusts overview.</title> 249 <imagefile>trusts1</imagefile> 250</figure> 251 252<itemizedlist> 253 <listitem><para> 254 DomA (completes the trust connection) <parameter>Trusts</parameter> DomB. 255 </para></listitem> 256 257 <listitem><para> 258 DomA is the <parameter>Trusting</parameter> domain. 259 </para></listitem> 260 261 <listitem><para> 262 DomB is the <parameter>Trusted</parameter> domain (originates the trust account). 263 </para></listitem> 264 265 <listitem><para> 266 Users in DomB can access resources in DomA. 267 </para></listitem> 268 269 <listitem><para> 270 Users in DomA cannot access resources in DomB. 271 </para></listitem> 272 273 <listitem><para> 274 Global groups from DomB can be used in DomA. 275 </para></listitem> 276 277 <listitem><para> 278 Global groups from DomA cannot be used in DomB. 279 </para></listitem> 280 281 <listitem><para> 282 DomB does appear in the logon dialog box on client workstations in DomA. 283 </para></listitem> 284 285 <listitem><para> 286 DomA does not appear in the logon dialog box on client workstations in DomB. 287 </para></listitem> 288</itemizedlist> 289 290<itemizedlist> 291 <listitem><para> 292 Users and groups in a trusting domain cannot be granted rights, permissions, or access 293 to a trusted domain. 294 </para></listitem> 295 296 <listitem><para> 297 The trusting domain can access and use accounts (users/global groups) in the 298 trusted domain. 299 </para></listitem> 300 301 <listitem><para> 302 Administrators of the trusted domain can be granted administrative rights in the 303 trusting domain. 304 </para></listitem> 305 306 <listitem><para> 307 Users in a trusted domain can be given rights and privileges in the trusting 308 domain. 309 </para></listitem> 310 311 <listitem><para> 312 Trusted domain global groups can be given rights and permissions in the trusting 313 domain. 314 </para></listitem> 315 316 <listitem><para> 317 Global groups from the trusted domain can be made members in local groups on 318 MS Windows domain member machines. 319 </para></listitem> 320</itemizedlist> 321 322</sect2> 323 324</sect1> 325 326<sect1> 327<title>Configuring Samba NT-Style Domain Trusts</title> 328 329<para> 330<indexterm><primary>interdomain trust</primary></indexterm> 331This description is meant to be a fairly short introduction about how to set up a Samba server so 332that it can participate in interdomain trust relationships. Trust relationship support in Samba 333is at an early stage, so do not be surprised if something does not function as it should. 334</para> 335 336<para> 337<indexterm><primary>peer domain</primary></indexterm> 338<indexterm><primary>trust relationship</primary></indexterm> 339<indexterm><primary>Windows NT4 Server</primary></indexterm> 340<indexterm><primary>between domains</primary></indexterm> 341Each of the procedures described next assumes the peer domain in the trust relationship is controlled by a 342Windows NT4 server. However, the remote end could just as well be another Samba-3 domain. It can be clearly 343seen, after reading this document, that combining Samba-specific parts of what's written in the following 344sections leads to trust between domains in a purely Samba environment. 345</para> 346 347<sect2 id="samba-trusted-domain"> 348<title>Samba as the Trusted Domain</title> 349 350<para> 351<indexterm><primary>trusted party</primary></indexterm> 352<indexterm><primary>special account</primary></indexterm> 353<indexterm><primary>trusting party</primary></indexterm> 354<indexterm><primary>PDC</primary></indexterm> 355<indexterm><primary>smbpasswd</primary></indexterm> 356In order to set the Samba PDC to be the trusted party of the relationship, you first need 357to create a special account for the domain that will be the trusting party. To do that, 358you can use the <command>smbpasswd</command> utility. Creating the trusted domain account is 359similar to creating a trusted machine account. Suppose, your domain is 360called SAMBA, and the remote domain is called RUMBA. The first step 361will be to issue this command from your favorite shell: 362</para> 363 364<para> 365<screen> 366&rootprompt; <userinput>smbpasswd -a -i rumba</userinput> 367New SMB password: <userinput>XXXXXXXX</userinput> 368Retype SMB password: <userinput>XXXXXXXX</userinput> 369Added user rumba$ 370</screen> 371 372where <option>-a</option> means to add a new account into the 373passdb database and <option>-i</option> means to <quote>create this 374account with the Interdomain trust flag</quote>. 375</para> 376 377<para> 378<indexterm><primary>account name</primary></indexterm> 379<indexterm><primary>remote domain</primary></indexterm> 380<indexterm><primary>password database</primary></indexterm> 381<indexterm><primary>/etc/passwd</primary></indexterm> 382The account name will be <quote>rumba$</quote> (the name of the remote domain). 383If this fails, you should check that the trust account has been added to the system 384password database (<filename>/etc/passwd</filename>). If it has not been added, you 385can add it manually and then repeat the previous step. 386</para> 387 388<para> 389<indexterm><primary>password</primary></indexterm> 390<indexterm><primary>new account</primary></indexterm> 391<indexterm><primary>confirm the trust</primary></indexterm> 392<indexterm><primary>Windows NT Server</primary></indexterm> 393After issuing this command, you will be asked to enter the password for the account. You can use any password 394you want, but be aware that Windows NT will not change this password until 7 days following account creation. 395After the command returns successfully, you can look at the entry for the new account (in the standard way as 396appropriate for your configuration) and see that the account's name is really RUMBA$ and it has the 397<quote>I</quote> flag set in the flags field. Now you are ready to confirm the trust by establishing it from 398Windows NT Server. 399</para> 400 401 402<para> 403<indexterm><primary>User Manager</primary></indexterm> 404<indexterm><primary>trusted domain name</primary></indexterm> 405<indexterm><primary>relationship password</primary></indexterm> 406<indexterm><primary>remote domain</primary></indexterm> 407<indexterm><primary>established</primary></indexterm> 408Open <application>User Manager for Domains</application> and from the <guimenu>Policies</guimenu> menu, select 409<guimenuitem>Trust Relationships...</guimenuitem>. Beside the <guilabel>Trusted domains</guilabel> list box, 410click the <guimenu>Add...</guimenu> button. You will be prompted for the trusted domain name and the 411relationship password. Type in SAMBA, as this is the name of the remote domain and the password used at the 412time of account creation. Click on <guibutton>OK</guibutton> and, if everything went without incident, you 413will see the <computeroutput>Trusted domain relationship successfully established</computeroutput> message. 414</para> 415 416</sect2> 417<sect2> 418<title>Samba as the Trusting Domain</title> 419 420<para> 421<indexterm><primary>NT-controlled domain</primary></indexterm> 422<indexterm><primary>PDC</primary></indexterm> 423This time activities are somewhat reversed. Again, we'll assume that your domain 424controlled by the Samba PDC is called SAMBA and the NT-controlled domain is called RUMBA. 425</para> 426 427<para> 428The very first step is to add an account for the SAMBA domain on RUMBA's PDC. 429</para> 430 431 432<para> 433<indexterm><primary>User Manager</primary></indexterm> 434<indexterm><primary>trusted domain</primary></indexterm> 435<indexterm><primary>password</primary></indexterm> 436Launch the <application>Domain User Manager</application>, then from the menu select 437<guimenu>Policies</guimenu>, <guimenuitem>Trust Relationships</guimenuitem>. 438Now, next to the <guilabel>Trusting Domains</guilabel> box, press the <guibutton>Add</guibutton> 439button and type in the name of the trusted domain (SAMBA) and the password to use in securing 440the relationship. 441</para> 442 443<para> 444<indexterm><primary>password</primary></indexterm> 445<indexterm><primary>confirm the password</primary></indexterm> 446The password can be arbitrarily chosen. It is easy to change the password from the Samba server whenever you 447want. After you confirm the password, your account is ready for use. Now its Samba's turn. 448</para> 449 450<para> 451Using your favorite shell while logged in as root, issue this command: 452<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>trustdom establish</tertiary></indexterm> 453</para> 454 455<para> 456&rootprompt;<userinput>net rpc trustdom establish rumba</userinput> 457</para> 458 459<para> 460<indexterm><primary>password</primary></indexterm> 461<indexterm><primary>interdomain connection</primary></indexterm> 462<indexterm><primary>ordinary connection</primary></indexterm> 463You will be prompted for the password you just typed on your Windows NT4 Server box. 464An error message, <literal>"NT_STATUS_NOLOGON_INTERDOMAIN_TRUST_ACCOUNT,"</literal> 465that may be reported periodically is of no concern and may safely be ignored. 466It means the password you gave is correct and the NT4 server says the account is ready for 467interdomain connection and not for ordinary connection. After that, be patient; 468it can take a while (especially in large networks), but eventually you should see 469the <literal>Success</literal> message. Congratulations! Your trust 470relationship has just been established. 471</para> 472 473<note><para> 474You have to run this command as root because you must have write access to 475the <filename>secrets.tdb</filename> file. 476</para></note> 477 478</sect2> 479</sect1> 480 481<sect1> 482<title>NT4-Style Domain Trusts with Windows 2000</title> 483 484<para> 485<indexterm><primary>trust relationship</primary></indexterm> 486<indexterm><primary>Windows 2000 server</primary></indexterm> 487<indexterm><primary>NT4-style</primary></indexterm> 488<indexterm><primary>mixed mode</primary></indexterm> 489Although <application>Domain User Manager</application> is not present in Windows 2000, it is 490also possible to establish an NT4-style trust relationship with a Windows 2000 domain 491controller running in mixed mode as the trusting server. It should also be possible for 492Samba to trust a Windows 2000 server; however, more testing is still needed in this area. 493</para> 494 495<para> 496<indexterm><primary>interdomain trust</primary></indexterm> 497<indexterm><primary>trust account</primary></indexterm> 498<indexterm><primary>not transitive</primary></indexterm> 499<indexterm><primary>ADS</primary></indexterm> 500After <link linkend="samba-trusted-domain">creating the interdomain trust account on the Samba server</link> 501as described previously, open <application>Active Directory Domains and Trusts</application> on the AD 502controller of the domain whose resources you wish Samba users to have access to. Remember that since NT4-style 503trusts are not transitive, if you want your users to have access to multiple mixed-mode domains in your AD 504forest, you will need to repeat this process for each of those domains. With <application>Active Directory 505domains and trusts</application> open, right-click on the name of the Active Directory domain that will trust 506our Samba domain and choose <guimenuitem>Properties</guimenuitem>, then click on the 507<guilabel>Trusts</guilabel> tab. In the upper part of the panel, you will see a list box labeled 508<guilabel>Domains trusted by this domain:</guilabel> and an <guilabel>Add...</guilabel> button next to it. 509Press this button and, just as with NT4, you will be prompted for the trusted domain name and the relationship 510password. Press <emphasis>OK</emphasis> and after a moment, Active Directory will respond with 511<computeroutput>The trusted domain has been added and the trust has been verified.</computeroutput> Your 512Samba users can now be granted access to resources in the AD domain. 513</para> 514</sect1> 515 516<sect1> 517<title>Common Errors</title> 518 519<para> 520Interdomain trust relationships should not be attempted on networks that are unstable 521or that suffer regular outages. Network stability and integrity are key concerns with 522distributed trusted domains. 523</para> 524 525<sect2> 526<title>Browsing of Trusted Domain Fails</title> 527 528<para> 529<emphasis>Browsing from a machine in a trusted Windows 200x domain to a Windows 200x member of 530a trusting Samba domain, I get the following error:</emphasis> 531<screen> 532The system detected a possible attempt to compromise security. Please 533ensure that you can contact the server that authenticated you. 534</screen> 535</para> 536 537<para> 538<emphasis>The event logs on the box I'm trying to connect to have entries regarding group 539policy not being applied because it is a member of a down-level domain.</emphasis> 540</para> 541 542<para>If there is a computer account in the Windows 543200x domain for the machine in question, and it is disabled, this problem can 544occur. If there is no computer account (removed or never existed), or if that 545account is still intact (i.e., you just joined it to another domain), everything 546seems to be fine. By default, when you unjoin a domain (the Windows 200x 547domain), the computer tries to automatically disable the computer account in 548the domain. If you are running as an account that has privileges to do this 549when you unjoin the machine, it is done; otherwise it is not done. 550</para> 551 552</sect2> 553 554<sect2> 555<title>Problems with LDAP ldapsam and Older Versions of smbldap-tools</title> 556 557<para> 558If you use the <command>smbldap-useradd</command> script to create a trust 559account to set up interdomain trusts, the process of setting up the trust will 560fail. The account that was created in the LDAP database will have an account 561flags field that has <literal>[W ]</literal>, when it must have 562<literal>[I ]</literal> for interdomain trusts to work. 563</para> 564 565<para>Here is a simple solution. 566Create a machine account as follows: 567<screen> 568&rootprompt; smbldap-useradd -w domain_name 569</screen> 570Then set the desired trust account password as shown here: 571<screen> 572&rootprompt; smbldap-passwd domain_name\$ 573</screen> 574Using a text editor, create the following file: 575<screen> 576dn: uid=domain_name$,ou=People,dc={your-domain},dc={your-top-level-domain} 577changetype: modify 578sambaAcctFlags: [I ] 579</screen> 580Then apply the text file to the LDAP database as follows: 581<screen> 582&rootprompt; ldapmodify -x -h localhost \ 583 -D "cn=Manager,dc={your-domain},dc={your-top-level-domain}" \ 584 -W -f /path-to/foobar 585</screen> 586Create a single-sided trust under the NT4 Domain User Manager, then execute: 587<screen> 588&rootprompt; net rpc trustdom establish domain_name 589</screen> 590</para> 591 592<para> 593It works with Samba-3 and NT4 domains, and also with Samba-3 and Windows 200x ADS in mixed mode. 594Both domain controllers, Samba and NT must have the same WINS server; otherwise, 595the trust will never work. 596</para> 597 598</sect2> 599 600</sect1> 601 602</chapter> 603