diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/docbook/projdoc/DOMAIN_MEMBER.xml | 229 | ||||
| -rw-r--r-- | docs/docbook/projdoc/StandAloneServer.xml | 101 |
2 files changed, 298 insertions, 32 deletions
diff --git a/docs/docbook/projdoc/DOMAIN_MEMBER.xml b/docs/docbook/projdoc/DOMAIN_MEMBER.xml index de4a8510c0..ecb8a3afb3 100644 --- a/docs/docbook/projdoc/DOMAIN_MEMBER.xml +++ b/docs/docbook/projdoc/DOMAIN_MEMBER.xml @@ -1,9 +1,9 @@ <chapter id="domain-member"> <chapterinfo> + &author.jht; &author.jeremy; &author.jerry; - &author.jht; </chapterinfo> <title>Domain Membership</title> @@ -40,6 +40,44 @@ Samba-3 can join an MS Windows NT4 style domain as a native member server, an MS Active Directory Domain as a native member server, or a Samba Domain Control network. </para> +<para> +Domain membership has many advantages: +</para> + +<itemizedlist> + <listitem><para> + MS Windows workstation users get the benefit of SSO + </para></listitem> + + <listitem><para> + Domain user access rights and file ownership / access controls can be set from + the single Domain SAM (Security Accounts Management) database (works with Domain member + servers as well as with MS Windows workstations that are domain members) + </para></listitem> + + <listitem><para> + Only MS Windows NT4 / 200x / XP Professional workstations that are Domain members + can use network logon facilities + </para></listitem> + + <listitem><para> + Domain Member workstations can be better controlled through the use of Policy files + (NTConfig.POL) and Desktop Profiles. + </para></listitem> + + <listitem><para> + Through the use of logon scripts users can be given transparent access to network + applications that run off application servers + </para></listitem> + + <listitem><para> + Network administrators gain better application and user access management abilities + because there is no need to maintain user accounts on any network client or server, + other than the central Domain database (either NT4/Samba SAM style Domain, NT4 Domain + that is back ended with an LDAP directory, or via an Active Directory infrastructure) + </para></listitem> +</itemizedlist> + </sect1> <sect1> @@ -64,8 +102,8 @@ shared secret with the domain controller. </para> <para> -A Windows NT4 PDC stores each machine trust account in the Windows -Registry. The introduction of MS Windows 2000 saw the introduction of Active Directory, +A Windows NT4 PDC stores each machine trust account in the Windows Registry. +The introduction of MS Windows 2000 saw the introduction of Active Directory, the new repository for machine trust accounts. </para> @@ -103,12 +141,19 @@ as follows: </para> <para> -There are two ways to create machine trust accounts: +There are three ways to create machine trust accounts: </para> <itemizedlist> <listitem><para> - Manual creation. Both the Samba and corresponding Unix account are created by hand. + Manual creation from the Unix/Linux command line. Here, both the Samba and corresponding + Unix account are created by hand. + </para></listitem> + + <listitem><para> + Using the MS Windows NT4 Server Manager (either from an NT4 Domain member server, or using + the Nexus toolkit available from the Microsoft web site. This tool can be run from any + MS Windows machine so long as the user is logged on as the administrator account. </para></listitem> <listitem><para> @@ -200,6 +245,56 @@ the corresponding Unix account. </warning> </sect2> +<sect2> +<title>Using NT4 Server Manager to Add Machine Accounts to the Domain</title> + +<para> +If the machine from which you are trying to manage the domain is an MS Windows NT4 workstation +then the tool of choice is the package called SRVTOOLS.EXE. When executed in the target directory +this will unpack SrvMge.exe and UsrMgr.exe (both are Domain Management tools for MS Windows NT4 +workstation. +</para> + +<para> +If your workstation is any other MS Windows product you should download the Nexus.exe package +from the Microsoft web site. When executed from the target directory this will unpack the same +tools but for use on MS Windows 9x/Me/200x/XP. +</para> + +<para> +Launch the <command>srvmgr.exe</command> (Server Manager for Domains) and follow these steps: +</para> + +<procedure> +<title>Server Manager Account Machine Account Management</title> + <step><para> + From the menu select Computer + </para></step> + + <step><para> + Click on "Select Domain" + </para></step> + + <step><para> + Click on the name of the domain you wish to administer in the "Select Domain" panel + and then Click OK. + </para></step> + + <step><para> + Again from the menu select Computer + </para></step> + + <step><para> + Select "Add to Domain" + </para></step> + + <step><para> + In the dialog box, click on the radio button to "Add NT Workstation of Server", then + enter the machine name in the field provided, then Click the "Add" button. + </para></step> +</procedure> + +</sect2> <sect2> <title>"On-the-Fly" Creation of Machine Trust Accounts</title> @@ -210,13 +305,11 @@ simply to allow the Samba server to create them as needed when the client is joined to the domain. </para> -<para>Since each Samba machine trust account requires a corresponding -Unix account, a method for automatically creating the -Unix account is usually supplied; this requires configuration of the -<ulink url="smb.conf.5.html#ADDMACHINESCRIPT">add machine script</ulink> -option in <filename>smb.conf</filename>. This -method is not required, however; corresponding Unix accounts may also -be created manually. +<para>Since each Samba machine trust account requires a corresponding Unix account, a method +for automatically creating the Unix account is usually supplied; this requires configuration of the +<ulink url="smb.conf.5.html#ADDMACHINESCRIPT">add machine script</ulink> option in +<filename>smb.conf</filename>. This method is not required, however; corresponding Unix +accounts may also be created manually. </para> @@ -230,25 +323,39 @@ Below is an example for a RedHat Linux system. add machine script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u </programlisting></para> + </sect2> -<sect2><title>Joining the Client to the Domain</title> +<sect2><title>Making an MS Windows Workstation or Server a Domain Member</title> <para> -The procedure for joining a client to the domain varies with the version of Windows. +The procedure for making an MS Windows workstation of server a member of the domain varies +with the version of Windows: </para> <itemizedlist> - <listitem><para><emphasis>Windows 2000</emphasis></para> + <listitem><para><emphasis>Windows 200x XP Professional</emphasis></para> + + <para> + When the user elects to make the client a domain member, Windows 200x prompts for + an account and password that has privileges to create machine accounts in the domain. + A Samba administrative account (i.e., a Samba account that has root privileges on the + Samba server) must be entered here; the operation will fail if an ordinary user + account is given. + </para> + + <para> + Note: For security reasons the password for this administrative account should be set + to a password that is other than that used for the root user in the + <filename>/etc/passwd</filename>. + </para> <para> - When the user elects to join the client to a domain, Windows prompts for - an account and password that is privileged to join the domain. A Samba administrative - account (i.e., a Samba account that has root privileges on the Samba server) must be - entered here; the operation will fail if an ordinary user account is given. - The password for this account should be set to a different password than the associated - <filename>/etc/passwd</filename> entry, for security reasons. + The name of the account that is used to create domain member machine accounts can be + anything the network administrator may choose. If it is other than <command>root</command> + then this is easily mapped to root using the file pointed to be the &smb.conf; parameter + <emphasis>username map =</emphasis> <command>/etc/samba/smbusers</command>. </para> <para> @@ -258,7 +365,7 @@ The procedure for joining a client to the domain varies with the version of Wind updated if it already exists. </para></listitem> - <listitem><para><emphasis>Windows NT</emphasis></para> + <listitem><para><emphasis>Windows NT4</emphasis></para> <para> If the machine trust account was created manually, on the @@ -701,6 +808,84 @@ their defaults DNS setup. Maybe fixed in service packs? </para> </sect2> +</sect1> + +<sect1> +<title>Common Errors</title> + +<para> +In the process of adding / deleting / re-adding domain member machine accounts there are +many traps for the unwary player and there are many "little" things that can go wrong. +It is particularly interesting how often subscribers on the samba mailing list have concluded +after repeated failed attempts to add a machine account that it is necessary to "re-install" +MS Windows on t he machine. In truth, it is seldom necessary to reinstall because of this type +of problem. The real solution is often very simple, and with understanding of how MS Windows +networking functions. easily overcome. +</para> + +<sect2> +<title>Can Not Add Machine Back to Domain</title> + +<para> +<emphasis>Problem:</emphasis> A Windows workstation was reinstalled. The original domain machine +account was deleted and added immediately. The workstation will not join the domain if I use +the same machine name. Attempts to add the machine fail with a message that the machine already +exists on the network - I know it doen't. Why is this failing? +</para> + +<para> +The original name is still in the NetBIOS name cache and must expire after machine account +deletion BEFORE adding that same name as a domain member again. The best advice is to delete +the old account and then to add the machine with a new name. +</para> + +</sect2> + +<sect2> +<title>Adding Machine to Domain Fails</title> + +<para> +Adding a Windows 200x or XP Professional machine to the Samba PDC Domain fails with a +message that, "The machine could not be added at this time, there is a network problem. +Please try again later." Why? +</para> + +<para> +You should check that there is an <emphasis>add machine script</emphasis> in your &smb.conf; +file. If there is not, please add one that is appropriate for your OS platform. If a script +has been defined you will need to debug it's operation. Increase the <emphasis>log level</emphasis> +in the &smb.conf; file to level 10, then try to rejoin the domain. Check the logs to see which +operation is failing. +</para> + +<para> +Possible causes include: +</para> + +<itemizedlist> + <listitem><para> + The script does not actually exist, or could not be located in the path specified. + </para> + + <para> + <emphasis>Corrective Action:</emphasis> Fix it. Make sure that when run manually + that the script will add both the Unix system account _and_ the Samba SAM account. + </para></listitem> + + <listitem><para> + The machine could not be added to the Unix system accounts file <filename>/etc/passwd</filename> + </para> + + <para> + <emphasis>Corrective Action:</emphasis> Check that the machine name is a legal Unix + system account name. ie: If the Unix utility <command>useradd</command> is called + then make sure that the machine name you are trying to add can be added using this + tool. <command>Useradd</command> on some systems will not allow any upper case characters + nor will it allow spaces in the name. + </para></listitem> +</itemizedlist> + +</sect2> </sect1> </chapter> diff --git a/docs/docbook/projdoc/StandAloneServer.xml b/docs/docbook/projdoc/StandAloneServer.xml index c5b5c67250..1246ff0f3a 100644 --- a/docs/docbook/projdoc/StandAloneServer.xml +++ b/docs/docbook/projdoc/StandAloneServer.xml @@ -4,8 +4,42 @@ </chapterinfo> <title>Stand-Alone Servers</title> +<para> +Stand-Alone servers are independant of an Domain Controllers on the network. +They are NOT domain members and function more like workgroup servers. In many +cases a stand-alone server is configured with a minimum of security control +with the intent that all data served will be readilly accessible to all users. +</para> + +<sect1> +<title>Features and Benefits</title> + +<para> +Stand-Alone servers can be as secure or as insecure as needs dictate. They can +have simple or complex configurations. Above all, despite the hoopla about +Domain security they remain a very common installation. +</para> + +<para> +If all that is needed is a server for read-only files, or for +printers alone, it may not make sense to affect a complex installation. +For example: A drafting office needs to store old drawings and reference +standards. No-one can write files to the server as it is legislatively +important that all documents remain unaltered. A share mode read-only stand-alone +server is an ideal solution. +</para> + +<para> +Another situation that warrants simplicity is an office that has many printers +that are queued off a single central server. Everyone needs to be able to print +to the printers, there is no need to affect any access controls and no files will +be served from the print server. Again a share mode stand-alone server makes +a great solution. +</para> +</sect1> + <sect1> -<title>Stand Alone Server</title> +<title>Background</title> <para> The term <emphasis>stand alone server</emphasis> means that the server @@ -13,21 +47,22 @@ will provide local authentication and access control for all resources that are available from it. In general this means that there will be a local user database. In more technical terms, it means that resources on the machine will either be made available in either SHARE mode or in -USER mode. SHARE mode and USER mode security are documented under -discussions regarding "security mode". The smb.conf configuration parameters -that control security mode are: "security = user" and "security = share". +USER mode. </para> <para> No special action is needed other than to create user accounts. Stand-alone -servers do NOT provide network logon services, meaning that machines that -use this server do NOT perform a domain logon but instead make use only of -the MS Windows logon which is local to the MS Windows workstation/server. +servers do NOT provide network logon services. This means that machines that +use this server do NOT perform a domain log onto it. Whatever logon facility +the workstations are subject to is independant of this machine. It is however +necessary to accomodate any network user so that the logon name they use will +be translated (mapped) locally on the stand-alone server to a locally known +user name. There are several ways this cane be done. </para> <para> Samba tends to blur the distinction a little in respect of what is -a stand alone server. This is because the authentication database may be +a stand-alone server. This is because the authentication database may be local or on a remote server, even if from the samba protocol perspective the samba server is NOT a member of a domain security context. </para> @@ -38,10 +73,56 @@ Through the use of PAM (Pluggable Authentication Modules) and nsswitch another server. We would be inclined to call this the authentication server. This means that the samba server may use the local Unix/Linux system password database (/etc/passwd or /etc/shadow), may use a local smbpasswd -file (/etc/samba/smbpasswd or /usr/local/samba/lib/private/smbpasswd), or -may use an LDAP back end, or even via PAM and Winbind another CIFS/SMB +file, or may use an LDAP back end, or even via PAM and Winbind another CIFS/SMB server for authentication. </para> </sect1> + +<sect1> +<title>Example Configuration</title> + +<para> +The following examples are designed to inspire simplicity. It is too easy to +attempt a high level of creativity and to introduce too much complexity in +server and network design. +</para> + +<sect2> +<title>Reference Documentation Server</title> + +<para> +Put one here! +</para> + +</sect2> + +<sect2> +<title>Central Print Serving</title> + +<para> +Put one here! +</para> + +</sect2> + +<sect2> +<title>Legal Office Daily Work Server</title> + +<para> +Put one here! +</para> + +</sect2> + +</sect1> + +<sect1> +<title>Common Errors</title> + +<para> +Put stuff here. +</para> + +</sect1> </chapter> |