diff options
Diffstat (limited to 'docs/docbook/projdoc/InterdomainTrusts.xml')
| -rw-r--r-- | docs/docbook/projdoc/InterdomainTrusts.xml | 193 |
1 files changed, 95 insertions, 98 deletions
diff --git a/docs/docbook/projdoc/InterdomainTrusts.xml b/docs/docbook/projdoc/InterdomainTrusts.xml index 04efc6fda6..7cbd673643 100644 --- a/docs/docbook/projdoc/InterdomainTrusts.xml +++ b/docs/docbook/projdoc/InterdomainTrusts.xml @@ -14,14 +14,14 @@ <title>Interdomain Trust Relationships</title> -<indexterm><primary>Interdomain Trusts</primary></indexterm> <para> -Samba-3 supports NT4 style domain trust relationships. This is feature that many sites -will want to use if they migrate to Samba-3 from and NT4 style domain and do NOT want to -adopt Active Directory or an LDAP based authentication back end. This section explains +<indexterm><primary>Interdomain Trusts</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 section 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 Samba3-to-Samba3 +possible for Samba-3 to trust NT4 (and vice versa), as well as to create Samba-to-Samba trusts. </para> @@ -29,14 +29,13 @@ trusts. <title>Features and Benefits</title> <para> -Samba-3 can participate in Samba-to-Samba as well as in Samba-to-MS Windows NT4 style -trust relationships. This imparts to Samba similar scalability as is possible with -MS Windows NT4. +Samba-3 can participate in Samba-to-Samba as well as in Samba-to-MS Windows NT4-style +trust relationships. This imparts to Samba similar scalability as with MS Windows NT4. </para> <para> Given that Samba-3 has the capability to function with a scalable backend authentication -database such as LDAP, and given it's ability to run in Primary as well as Backup Domain control +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 this works it is fragile. That was, after all, a key reason for the development and adoption of Microsoft Active Directory. @@ -48,49 +47,47 @@ That was, after all, a key reason for the development and adoption of Microsoft <title>Trust Relationship Background</title> <para> -MS Windows NT3.x/4.0 type security domains employ a non-hierarchical security structure. -The limitations of this architecture as it affects the scalability of MS Windows networking -in large organisations is well known. Additionally, the flat namespace that results from +MS Windows NT3/4 type security domains employ a non-hierarchical 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 organisations. +large and diverse organizations. </para> <para> Microsoft developed Active Directory Service (ADS), based on Kerberos and LDAP, as a means -of circumventing the limitations of the older technologies. Not every organisation is ready -or willing to embrace ADS. For small companies the older NT4 style domain security paradigm -is quite adequate, there thus remains an entrenched user base for whom there is no direct +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, there remains an entrenched user base for whom there is no direct desire to go through a disruptive change to adopt ADS. </para> <para> -Microsoft introduced with MS Windows NT the ability to allow differing security domains -to affect a mechanism so that users from one domain may be given access rights and privileges +With MS Windows NT, Microsoft introduced the ability to allow differing 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 are available to 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, thus if users in both domains are to have privileges and rights in each others' domain, then it is -necessary to establish two (2) relationships, one in each direction. +necessary to establish two relationships, one in each direction. </para> <para> -In an NT4 style MS security domain, all trusts are non-transitive. This means that if there -are three (3) domains (let's call them RED, WHITE, and BLUE) where RED and WHITE have a trust +In an NT4-style MS security domain, all trusts are non-transitive. 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. ie: Relationships are explicit and not +implied trust between the RED and BLUE domains. Relationships are explicit and not transitive. </para> <para> -<!-- FIXME: What are these colors doing here - I can't find them ... Jelmer --> 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 above, 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. +domains above, 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> @@ -99,13 +96,13 @@ security domains in similar manner to MS Windows NT4 style domains. <title>Native MS Windows NT4 Trusts Configuration</title> <para> -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 +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. - <indexterm><primary>Interdomain Trusts</primary><secondary>creating</secondary></indexterm> </para> + <sect2> <title>Creating an NT4 Domain Trust</title> @@ -113,11 +110,11 @@ other domain to use in verifying security credentials. 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 labelled +<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 +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> @@ -129,13 +126,13 @@ The password needs to be typed twice (for standard confirmation). <title>Completing an NT4 Domain Trust</title> <para> -<indexterm><primary>Interdomain Trusts</primary><secondary>completing</secondary></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 will launch the -Domain User Manager, from the menu select Policies, then select Trust Relationships, then click on the -<guibutton>Add</guibutton> button that is next to the box that is labelled -<guilabel>Trusted Domains</guilabel>. A panel will open in which must be entered the name of the remote -domain as well as the password assigned to that trust. +with the trusted domain. To consummate the trust relationship, the administrator will launch the +Domain User Manager from the menu select <guilabel>Policies</guilabel>, then select +<guilabel>Trust Relationships</guilabel>, click on the <guibutton>Add</guibutton> button +next to the box that is labeled <guilabel>Trusted Domains</guilabel>. A panel will open in which +must be entered the name of the remote domain as well as the password assigned to that trust. </para> </sect2> @@ -143,83 +140,83 @@ domain as well as the password assigned to that trust. <sect2> <title>Inter-Domain Trust Facilities</title> -<indexterm><primary>Interdomain Trusts</primary><secondary>Facilities</secondary></indexterm> <para> +<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: +DomA and DomB), the following facilities are created: </para> -<image><imagefile>trusts1</imagefile><imagedescription>Trusts overview</imagedescription></image> +<image id="trusts1"><imagefile>trusts1</imagefile><imagedescription>Trusts overview.</imagedescription></image> <itemizedlist> <listitem><para> - DomA (completes the trust connection) Trusts DomB + DomA (completes the trust connection) <parameter>Trusts</parameter> DomB. </para></listitem> <listitem><para> - DomA is the Trusting domain + DomA is the <parameter>Trusting</parameter> domain. </para></listitem> <listitem><para> - DomB is the Trusted domain (originates the trust account) + DomB is the <parameter>Trusted</parameter> domain (originates the trust account). </para></listitem> <listitem><para> - Users in DomB can access resources in DomA + Users in DomB can access resources in DomA. </para></listitem> <listitem><para> - Users in DomA can NOT access resources in DomB + Users in DomA cannot access resources in DomB. </para></listitem> <listitem><para> - Global groups from DomB CAN be used in DomA + Global groups from DomB can be used in DomA. </para></listitem> <listitem><para> - Global groups from DomA can NOT be used in DomB + 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 + 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 + DomA does not appear in the logon dialog box on client workstations in DomB. </para></listitem> </itemizedlist> <itemizedlist> <listitem><para> - Users / Groups in a trusting domain can NOT be granted rights, permissions or access + Users/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 + 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 admininstrative rights in the + Administrators of the trusted domain can be granted admininstrative rights in the trusting domain. </para></listitem> <listitem><para> - Users in a trusted domain CAN be given rights and privileges in the trusting + 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 + 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. + Global Groups from the trusted domain can be made members in Local Groups on + MS Windows Domain Member machines. </para></listitem> </itemizedlist> @@ -228,17 +225,17 @@ DomA and DomB) the following facilities are created: </sect1> <sect1> -<title>Configuring Samba NT-style Domain Trusts</title> +<title>Configuring Samba NT-Style Domain Trusts</title> <para> This description is meant to be a fairly short introduction about how to set up a Samba server so -that it could participate in interdomain trust relationships. Trust relationship support in Samba -is in its early stage, so lot of things don't work yet. +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> Each of the procedures described below 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 +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 below leads to trust between domains in a purely Samba environment. @@ -248,12 +245,12 @@ environment. <title>Samba as the Trusted Domain</title> <para> -In order to set the Samba PDC to be the trusted party of the relationship you first need +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 'smbpasswd' utility. Creating the trusted domain account is very +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 favourite shell: +will be to issue this command from your favorite shell: </para> <para> @@ -265,35 +262,35 @@ Added user rumba$ </screen> where <option>-a</option> means to add a new account into the -passdb database and <option>-i</option> means: ''create this -account with the InterDomain trust flag'' +passdb database and <option>-i</option> means: <quote>create this +account with the InterDomain trust flag</quote>. </para> <para> -The account name will be 'rumba$' (the name of the remote domain) +The account name will be <quote>rumba$</quote> (the name of the remote domain). </para> <para> -After issuing this command you'll be asked to enter the password for +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. +not change this password until seven 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 account's name is -really RUMBA$ and it has the 'I' flag set in the flags field. Now you're ready to confirm +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> -<indexterm><primary>User Manager</primary></indexterm> <para> +<indexterm><primary>User Manager</primary></indexterm> Open <application>User Manager for Domains</application> and from the <guimenu>Policies</guimenu> menu, select <guimenuitem>Trust Relationships...</guimenuitem>. -Right beside the <guilabel>Trusted domains</guilabel> list box press the +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. -Press OK and, if everything went without incident, you will see -<computeroutput>Trusted domain relationship successfully +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> @@ -303,31 +300,31 @@ established</computeroutput> message. <para> This time activities are somewhat reversed. Again, we'll assume that your domain -controlled by the Samba PDC is called SAMBA and NT-controlled domain is called RUMBA. +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> -<indexterm><primary>User Manager</primary></indexterm> <para> +<indexterm><primary>User Manager</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>Trusted 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 +button and type in the name of the trusted domain (SAMBA) and the password to use in securing the relationship. </para> <para> The password can be arbitrarily chosen. It is easy to change the password from the Samba server whenever you want. After confirming the password your account is -ready for use. Now it's Samba's turn. +ready for use. Now its Samba's turn. </para> <para> -Using your favourite shell while being logged in as root, issue this command: +Using your favorite shell while being logged in as root, issue this command: </para> <para> @@ -336,17 +333,17 @@ Using your favourite shell while being logged in as root, issue this command: <para> You will be prompted for the password you just typed on your Windows NT4 Server box. -Do not worry if you see an error message that mentions a return code of -NT_STATUS_NOLOGON_INTERDOMAIN_TRUST_ACCOUNT. 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 <computeroutput>Success</computeroutput> message. -Congratulations! Your trust relationship has just been established. +An error message <errorname>`NT_STATUS_NOLOGON_INTERDOMAIN_TRUST_ACCOUNT'</errorname> +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 <computeroutput>Success</computeroutput> message. Congratulations! Your trust +relationship has just been established. </para> <note><para> -Note that you have to run this command as root because you must have write access to +You have to run this command as root because you must have write access to the <filename>secrets.tdb</filename> file. </para></note> @@ -354,11 +351,11 @@ the <filename>secrets.tdb</filename> file. </sect1> <sect1> -<title>NT4-style Domain Trusts with Windows 2000</title> +<title>NT4-Style Domain Trusts with Windows 2000</title> <para> 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 +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> @@ -366,15 +363,15 @@ Samba to trust a Windows 2000 server, however, more testing is still needed in t After <link linkend="samba-trusted-domain">creating the interdomain trust account on the Samba server</link> as described above, 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 +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 +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 -labelled <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 OK, and +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 OK 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 acess to resources in the AD domain. @@ -385,7 +382,7 @@ granted acess to resources in the AD domain. <title>Common Errors</title> <para> -Interdomain trust relationships should NOT be attempted on networks that are unstable +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> |