diff options
Diffstat (limited to 'docs/docbook/projdoc/Samba-PDC-HOWTO.xml')
| -rw-r--r-- | docs/docbook/projdoc/Samba-PDC-HOWTO.xml | 842 |
1 files changed, 842 insertions, 0 deletions
diff --git a/docs/docbook/projdoc/Samba-PDC-HOWTO.xml b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml new file mode 100644 index 0000000000..6a3bcacf17 --- /dev/null +++ b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml @@ -0,0 +1,842 @@ +<chapter id="samba-pdc"> + + +<chapterinfo> + &author.jerry; + &author.jht; + <author> + <firstname>David</firstname><surname>Bannon</surname> + <affiliation> + <orgname>Samba Team</orgname> + <address><email>dbannon@samba.org</email></address> + </affiliation> + </author> + <pubdate> (26 Apr 2001) </pubdate> +</chapterinfo> + +<title> +Samba as an NT4 or Win2k Primary Domain Controller +</title> + + +<sect1> +<title>Prerequisite Reading</title> + +<para> +Before you continue reading in this chapter, please make sure +that you are comfortable with configuring basic files services +in smb.conf and how to enable and administer password +encryption in Samba. Theses two topics are covered in the +&smb.conf; manpage. +</para> + + +</sect1> + + + +<sect1> +<title> +Background +</title> + +<para> +This article outlines the steps necessary for configuring Samba as a PDC. +It is necessary to have a working Samba server prior to implementing the +PDC functionality. +</para> + +<itemizedlist> + <listitem><para> + Domain logons for Windows NT 4.0 / 200x / XP Professional clients. + </para></listitem> + + <listitem><para> + Placing Windows 9x / Me clients in user level security + </para></listitem> + + <listitem><para> + Retrieving a list of users and groups from a Samba PDC to + Windows 9x / Me / NT / 200x / XP Professional clients + </para></listitem> + + <listitem><para> + Roaming Profiles + </para></listitem> + + <listitem><para> + Network/System Policies + </para></listitem> +</itemizedlist> + +<note> +<para> +Roaming Profiles and System/Network policies are advanced network administration topics +that are covered separately in this document. +</para> +</note> + +<para> +The following functionalities are new to the Samba 3.0 release: +</para> + +<itemizedlist> + <listitem><para> + Windows NT 4 domain trusts + </para></listitem> + + <listitem><para> + Adding users via the User Manager for Domains + </para></listitem> +</itemizedlist> + +<para> +The following functionalities are NOT provided by Samba 3.0: +</para> + +<itemizedlist> + <listitem><para> + SAM replication with Windows NT 4.0 Domain Controllers + (i.e. a Samba PDC and a Windows NT BDC or vice versa) + </para></listitem> + + <listitem><para> + Acting as a Windows 2000 Domain Controller (i.e. Kerberos and + Active Directory) + </para></listitem> +</itemizedlist> + +<para> +Please note that Windows 9x / Me / XP Home clients are not true members of a domain +for reasons outlined in this article. Therefore the protocol for +support of Windows 9x-style domain logons is completely different +from NT4 / Win2k type domain logons and has been officially supported for some +time. +</para> + +<para><emphasis> +MS Windows XP Home edition is NOT able to join a domain and does not permit +the use of domain logons.</emphasis> +</para> + + +<para> +Implementing a Samba PDC can basically be divided into 3 broad +steps. +</para> + +<orderedlist numeration="arabic"> + <listitem><para> + Configuring the Samba PDC + </para></listitem> + + <listitem><para> + Creating machine trust accounts and joining clients to the domain + </para></listitem> + + <listitem><para> + Adding and managing domain user accounts + </para></listitem> +</orderedlist> + +<para> +There are other minor details such as user profiles, system +policies, etc... However, these are not necessarily specific +to a Samba PDC as much as they are related to Windows NT networking +concepts. +</para> + +</sect1> + + +<sect1> +<title>Configuring the Samba Domain Controller</title> + +<para> +The first step in creating a working Samba PDC is to +understand the parameters necessary in smb.conf. Here we +attempt to explain the parameters that are covered in +the &smb.conf; man page. +</para> + +<para> +Here is an example &smb.conf; for acting as a PDC: +</para> + +<para><programlisting> +[global] + ; Basic server settings + <ulink url="smb.conf.5.html#NETBIOSNAME">netbios name</ulink> = <replaceable>POGO</replaceable> + <ulink url="smb.conf.5.html#WORKGROUP">workgroup</ulink> = <replaceable>NARNIA</replaceable> + + ; User and Machine Account Backends + ; Choices are: tdbsam, tdbsam_nua, smbpasswd, smbpasswd_nua, ldapsam, ldapsam_nua, ... + ; mysqlsam, xmlsam, guest + <ulink url="smb.conf.5.html#PASSDBBACKEND">passdb backend</ulink> = ldapsam, guest + + ; we should act as the domain and local master browser + <ulink url="smb.conf.5.html#OSLEVEL">os level</ulink> = 64 + <ulink url="smb.conf.5.html#PERFERREDMASTER">preferred master</ulink> = yes + <ulink url="smb.conf.5.html#DOMAINMASTER">domain master</ulink> = yes + <ulink url="smb.conf.5.html#LOCALMASTER">local master</ulink> = yes + + ; security settings (must user security = user) + <ulink url="smb.conf.5.html#SECURITYEQUALSUSER">security</ulink> = user + + ; encrypted passwords are a requirement for a PDC + <ulink url="smb.conf.5.html#ENCRYPTPASSWORDS">encrypt passwords</ulink> = yes + + ; support domain logons + <ulink url="smb.conf.5.html#DOMAINLOGONS">domain logons</ulink> = yes + + ; where to store user profiles? + <ulink url="smb.conf.5.html#LOGONPATH">logon path</ulink> = \\%N\profiles\%u + + ; where is a user's home directory and where should it be mounted at? + <ulink url="smb.conf.5.html#LOGONDRIVE">logon drive</ulink> = H: + <ulink url="smb.conf.5.html#LOGONHOME">logon home</ulink> = \\homeserver\%u + + ; specify a generic logon script for all users + ; this is a relative **DOS** path to the [netlogon] share + <ulink url="smb.conf.5.html#LOGONSCRIPT">logon script</ulink> = logon.cmd + +; necessary share for domain controller +[netlogon] + <ulink url="smb.conf.5.html#PATH">path</ulink> = /usr/local/samba/lib/netlogon + <ulink url="smb.conf.5.html#READONLY">read only</ulink> = yes + <ulink url="smb.conf.5.html#WRITELIST">write list</ulink> = <replaceable>ntadmin</replaceable> + +; share for storing user profiles +[profiles] + <ulink url="smb.conf.5.html#PATH">path</ulink> = /export/smb/ntprofile + <ulink url="smb.conf.5.html#READONLY">read only</ulink> = no + <ulink url="smb.conf.5.html#CREATEMASK">create mask</ulink> = 0600 + <ulink url="smb.conf.5.html#DIRECTORYMASK">directory mask</ulink> = 0700 +</programlisting></para> + +<note><para> +The above parameters make for a full set of parameters that may define the server's mode +of operation. The following parameters are the essentials alone: + +<programlisting> + workgroup = NARNIA + domain logons = Yes + security = User +</programlisting> + +The additional parameters shown in the longer listing above just makes for a +more complete environment. +</para></note> + +<para> +There are a couple of points to emphasize in the above configuration. +</para> + +<itemizedlist> + <listitem><para> + Encrypted passwords must be enabled. For more details on how + to do this, refer to <link linkend="passdb">the User Database chapter</link>. + </para></listitem> + + <listitem><para> + The server must support domain logons and a + <filename>[netlogon]</filename> share + </para></listitem> + + <listitem><para> + The server must be the domain master browser in order for Windows + client to locate the server as a DC. Please refer to the various + Network Browsing documentation included with this distribution for + details. + </para></listitem> +</itemizedlist> + +<para> +Samba 3.0 offers a complete implementation of group mapping +between Windows NT groups and Unix groups (this is really quite +complicated to explain in a short space). +</para> + +</sect1> + + +<sect1> +<title>Creating Machine Trust Accounts and Joining Clients to the Domain</title> + +<para> +A machine trust account is a Samba account that is used to +authenticate a client machine (rather than a user) to the Samba +server. In Windows terminology, this is known as a "Computer +Account."</para> + +<para> +The password of a machine trust account acts as the shared secret for +secure communication with the Domain Controller. This is a security +feature to prevent an unauthorized machine with the same NetBIOS name +from joining the domain and gaining access to domain user/group +accounts. Windows NT, 200x, XP Professional clients use machine trust +accounts, but Windows 9x / Me / XP Home clients do not. Hence, a +Windows 9x / Me / XP Home client is never a true member of a domain +because it does not possess a machine trust account, and thus has no +shared secret with the domain controller. +</para> + +<para>A Windows PDC stores each machine trust account in the Windows +Registry. A Samba-3 PDC also has to store machine trust account information +in a suitable backend data store. With Samba-3 there can be multiple back-ends +for this including: +</para> + +<itemizedlist> + <listitem><para> + <emphasis>smbpasswd</emphasis> - the plain ascii file stored used by + earlier versions of Samba. This file configuration option requires + a Unix/Linux system account for EVERY entry (ie: both for user and for + machine accounts). This file will be located in the <emphasis>private</emphasis> + directory (default is /usr/local/samba/lib/private or on linux /etc/samba). + </para></listitem> + + <listitem><para> + <emphasis>smbpasswd_nua</emphasis> - This file is independant of the + system wide user accounts. The use of this back-end option requires + specification of the "non unix account range" option also. It is called + smbpasswd and will be located in the <filename>private</filename> directory. + </para></listitem> + + <listitem><para> + <emphasis>tdbsam</emphasis> - a binary database backend that will be + stored in the <emphasis>private</emphasis> directory in a file called + <emphasis>passwd.tdb</emphasis>. The key benefit of this binary format + file is that it can store binary objects that can not be accomodated + in the traditional plain text smbpasswd file. + </para></listitem> + + <listitem><para> + <emphasis>tdbsam_nua</emphasis> like the smbpasswd_nua option above, this + file allows the creation of arbitrary user and machine accounts without + requiring that account to be added to the system (/etc/passwd) file. It + too requires the specification of the "non unix account range" option + in the [globals] section of the &smb.conf; file. + </para></listitem> + + <listitem><para> + <emphasis>ldapsam</emphasis> - An LDAP based back-end. Permits the + LDAP server to be specified. eg: ldap://localhost or ldap://frodo.murphy.com + </para></listitem> + + <listitem><para> + <emphasis>ldapsam_nua</emphasis> - LDAP based back-end with no unix + account requirement, like smbpasswd_nua and tdbsam_nua above. + </para></listitem> +</itemizedlist> + +<para>Read the chapter about the <link linkend="passdb">User Database</link> +for details.</para> + +<note><para> +The new tdbsam and ldapsam account backends store vastly more information than +smbpasswd is capable of. The new backend database includes capacity to specify +per user settings for many parameters, over-riding global settings given in the +<filename>smb.conf</filename> file. eg: logon drive, logon home, logon path, etc. +</para></note> + +<para> +A Samba PDC, however, stores each machine trust account in two parts, +as follows: + +<itemizedlist> + <listitem><para>A Samba account, stored in the same location as user + LanMan and NT password hashes (currently + <filename>smbpasswd</filename>). The Samba account + possesses and uses only the NT password hash.</para></listitem> + + <listitem><para>A corresponding Unix account, typically stored in + <filename>/etc/passwd</filename>. (Future releases will alleviate the need to + create <filename>/etc/passwd</filename> entries.) </para></listitem> +</itemizedlist> +</para> + +<para> +There are two ways to create machine trust accounts: +</para> + +<itemizedlist> + <listitem><para> Manual creation. Both the Samba and corresponding + Unix account are created by hand.</para></listitem> + + <listitem><para> "On-the-fly" creation. The Samba machine trust + account is automatically created by Samba at the time the client + is joined to the domain. (For security, this is the + recommended method.) The corresponding Unix account may be + created automatically or manually. </para> + </listitem> + +</itemizedlist> + +<sect2> +<title>Manual Creation of Machine Trust Accounts</title> + +<para> +The first step in manually creating a machine trust account is to +manually create the corresponding Unix account in +<filename>/etc/passwd</filename>. This can be done using +<command>vipw</command> or other 'add user' command that is normally +used to create new Unix accounts. The following is an example for a +Linux based Samba server: +</para> + +<para> + <prompt>root# </prompt><command>/usr/sbin/useradd -g 100 -d /dev/null -c <replaceable>"machine +nickname"</replaceable> -s /bin/false <replaceable>machine_name</replaceable>$ </command> +</para> +<para> +<prompt>root# </prompt><command>passwd -l <replaceable>machine_name</replaceable>$</command> +</para> + +<para>On *BSD systems, this can be done using the 'chpass' utility:</para> + +<para> +<prompt>root# </prompt><command>chpass -a "<replaceable>machine_name</replaceable>$:*:101:100::0:0:Workstation <replaceable>machine_name</replaceable>:/dev/null:/sbin/nologin"</command> +</para> + +<para> +The <filename>/etc/passwd</filename> entry will list the machine name +with a "$" appended, won't have a password, will have a null shell and no +home directory. For example a machine named 'doppy' would have an +<filename>/etc/passwd</filename> entry like this: +</para> + +<para><programlisting> +doppy$:x:505:501:<replaceable>machine_nickname</replaceable>:/dev/null:/bin/false +</programlisting></para> + +<para> +Above, <replaceable>machine_nickname</replaceable> can be any +descriptive name for the client, i.e., BasementComputer. +<replaceable>machine_name</replaceable> absolutely must be the NetBIOS +name of the client to be joined to the domain. The "$" must be +appended to the NetBIOS name of the client or Samba will not recognize +this as a machine trust account. +</para> + + +<para> +Now that the corresponding Unix account has been created, the next step is to create +the Samba account for the client containing the well-known initial +machine trust account password. This can be done using the <ulink +url="smbpasswd.8.html"><command>smbpasswd(8)</command></ulink> command +as shown here: +</para> + +<para> +<prompt>root# </prompt><userinput>smbpasswd -a -m <replaceable>machine_name</replaceable></userinput> +</para> + +<para> +where <replaceable>machine_name</replaceable> is the machine's NetBIOS +name. The RID of the new machine account is generated from the UID of +the corresponding Unix account. +</para> + +<warning> + <title>Join the client to the domain immediately</title> + + <para> + Manually creating a machine trust account using this method is the + equivalent of creating a machine trust account on a Windows NT PDC using + the "Server Manager". From the time at which the account is created + to the time which the client joins the domain and changes the password, + your domain is vulnerable to an intruder joining your domain using + a machine with the same NetBIOS name. A PDC inherently trusts + members of the domain and will serve out a large degree of user + information to such clients. You have been warned! + </para> +</warning> +</sect2> + + +<sect2> +<title>"On-the-Fly" Creation of Machine Trust Accounts</title> + +<para> +The second (and recommended) way of creating machine trust accounts is +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#ADDUSERSCRIPT">add user script</ulink> +option in <filename>smb.conf</filename>. This +method is not required, however; corresponding Unix accounts may also +be created manually. +</para> + + +<para>Below is an example for a RedHat 6.2 Linux system. +</para> + +<para><programlisting> +[global] + # <...remainder of parameters...> + add user 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> + +<para> +The procedure for joining a client to the domain varies with the +version of Windows. +</para> + +<itemizedlist> +<listitem><para><emphasis>Windows 2000</emphasis></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. + </para> + + <para> + The session key of the Samba administrative account acts as an + encryption key for setting the password of the machine trust + account. The machine trust account will be created on-the-fly, or + updated if it already exists. + </para> + +</listitem> + +<listitem><para><emphasis>Windows NT</emphasis></para> + + <para> If the machine trust account was created manually, on the + Identification Changes menu enter the domain name, but do not + check the box "Create a Computer Account in the Domain." In this case, + the existing machine trust account is used to join the machine to + the domain.</para> + + <para> If the machine trust account is to be created + on-the-fly, on the Identification Changes menu enter the domain + name, and check the box "Create a Computer Account in the Domain." In + this case, joining the domain proceeds as above for Windows 2000 + (i.e., you must supply a Samba administrative account when + prompted).</para> +</listitem> + +<listitem><para><emphasis>Samba</emphasis></para> + <para>Joining a samba client to a domain is documented in + the <link linkend="domain-member">Domain Member</link> chapter. +</para></listitem> +</itemizedlist> + +</sect2> +</sect1> + +<sect1> +<title>Common Problems and Errors</title> + +<sect2> +<title>I cannot include a '$' in a machine name</title> +<para> +A 'machine name' in (typically) <filename>/etc/passwd</filename> +of the machine name with a '$' appended. FreeBSD (and other BSD +systems?) won't create a user with a '$' in their name. +</para> + +<para> +The problem is only in the program used to make the entry. Once made, it works perfectly. +Create a user without the '$' using <command>vipw</command> to edit the entry, adding +the '$'. Or create the whole entry with vipw if you like, make sure you use a unique User ID! +</para> +</sect2> + +<sect2> +<title>I get told "You already have a connection to the Domain...." +or "Cannot join domain, the credentials supplied conflict with an +existing set.." when creating a machine trust account.</title> + +<para> +This happens if you try to create a machine trust account from the +machine itself and already have a connection (e.g. mapped drive) +to a share (or IPC$) on the Samba PDC. The following command +will remove all network drive connections: +</para> + +<para> +<prompt>C:\WINNT\></prompt> <command>net use * /d</command> +</para> + +<para> +Further, if the machine is already a 'member of a workgroup' that +is the same name as the domain you are joining (bad idea) you will +get this message. Change the workgroup name to something else, it +does not matter what, reboot, and try again. +</para> +</sect2> + +<sect2> +<title>The system can not log you on (C000019B)....</title> + +<para>I joined the domain successfully but after upgrading +to a newer version of the Samba code I get the message, "The system +can not log you on (C000019B), Please try again or consult your +system administrator" when attempting to logon. +</para> + +<para> +This occurs when the domain SID stored in the secrets.tdb database +is changed. The most common cause of a change in domain SID is when +the domain name and/or the server name (netbios name) is changed. +The only way to correct the problem is to restore the original domain +SID or remove the domain client from the domain and rejoin. The domain +SID may be reset using either the net or rpcclient utilities. +</para> + +<para> +The reset or change the domain SID you can use the net command as follows: + +<programlisting> + net getlocalsid 'OLDNAME' + net setlocalsid 'SID' +</programlisting> +</para> + +</sect2> + +<sect2> +<title>The machine trust account for this computer either does not +exist or is not accessible.</title> + +<para> +When I try to join the domain I get the message "The machine account +for this computer either does not exist or is not accessible". What's +wrong? +</para> + +<para> +This problem is caused by the PDC not having a suitable machine trust account. +If you are using the <parameter>add user script</parameter> method to create +accounts then this would indicate that it has not worked. Ensure the domain +admin user system is working. +</para> + +<para> +Alternatively if you are creating account entries manually then they +have not been created correctly. Make sure that you have the entry +correct for the machine trust account in smbpasswd file on the Samba PDC. +If you added the account using an editor rather than using the smbpasswd +utility, make sure that the account name is the machine NetBIOS name +with a '$' appended to it ( i.e. computer_name$ ). There must be an entry +in both /etc/passwd and the smbpasswd file. Some people have reported +that inconsistent subnet masks between the Samba server and the NT +client have caused this problem. Make sure that these are consistent +for both client and server. +</para> +</sect2> + +<sect2> +<title>When I attempt to login to a Samba Domain from a NT4/W2K workstation, +I get a message about my account being disabled.</title> + +<para> +At first be ensure to enable the useraccounts with <command>smbpasswd -e +%user%</command>, this is normally done, when you create an account. +</para> + +</sect2> + +</sect1> + +<sect1> +<title>Domain Control for Windows 9x/ME</title> + +<para> +A domain and a workgroup are exactly the same thing in terms of network +browsing. The difference is that a distributable authentication +database is associated with a domain, for secure login access to a +network. Also, different access rights can be granted to users if they +successfully authenticate against a domain logon server. Samba-3 does this +now in the same way that MS Windows NT/2K. +</para> + +<para> +The SMB client logging on to a domain has an expectation that every other +server in the domain should accept the same authentication information. +Network browsing functionality of domains and workgroups is identical and +is explained in this documentation under the browsing discussions. +It should be noted, that browsing is totally orthogonal to logon support. +</para> + +<para> +Issues related to the single-logon network model are discussed in this +section. Samba supports domain logons, network logon scripts, and user +profiles for MS Windows for workgroups and MS Windows 9X/ME clients +which are the focus of this section. +</para> + + +<para> +When an SMB client in a domain wishes to logon it broadcast requests for a +logon server. The first one to reply gets the job, and validates its +password using whatever mechanism the Samba administrator has installed. +It is possible (but very stupid) to create a domain where the user +database is not shared between servers, i.e. they are effectively workgroup +servers advertising themselves as participating in a domain. This +demonstrates how authentication is quite different from but closely +involved with domains. +</para> + + +<para> +Using these features you can make your clients verify their logon via +the Samba server; make clients run a batch file when they logon to +the network and download their preferences, desktop and start menu. +</para> + +<para> +Before launching into the configuration instructions, it is +worthwhile to look at how a Windows 9x/ME client performs a logon: +</para> + +<orderedlist> +<listitem> + <para> + The client broadcasts (to the IP broadcast address of the subnet it is in) + a NetLogon request. This is sent to the NetBIOS name DOMAIN<1c> at the + NetBIOS layer. The client chooses the first response it receives, which + contains the NetBIOS name of the logon server to use in the format of + \\SERVER. + </para> +</listitem> + +<listitem> + <para> + The client then connects to that server, logs on (does an SMBsessetupX) and + then connects to the IPC$ share (using an SMBtconX). + </para> +</listitem> + +<listitem> + <para> + The client then does a NetWkstaUserLogon request, which retrieves the name + of the user's logon script. + </para> +</listitem> + +<listitem> + <para> + The client then connects to the NetLogon share and searches for this + and if it is found and can be read, is retrieved and executed by the client. + After this, the client disconnects from the NetLogon share. + </para> +</listitem> + +<listitem> + <para> + The client then sends a NetUserGetInfo request to the server, to retrieve + the user's home share, which is used to search for profiles. Since the + response to the NetUserGetInfo request does not contain much more then + the user's home share, profiles for Win9X clients MUST reside in the user + home directory. + </para> +</listitem> + +<listitem> + <para> + The client then connects to the user's home share and searches for the + user's profile. As it turns out, you can specify the user's home share as + a sharename and path. For example, \\server\fred\.profile. + If the profiles are found, they are implemented. + </para> +</listitem> + +<listitem> + <para> + The client then disconnects from the user's home share, and reconnects to + the NetLogon share and looks for CONFIG.POL, the policies file. If this is + found, it is read and implemented. + </para> +</listitem> +</orderedlist> + + +<sect2> +<title>Configuration Instructions: Network Logons</title> + +<para> +The main difference between a PDC and a Windows 9x logon +server configuration is that +</para> + +<itemizedlist> + +<listitem><para> +Password encryption is not required for a Windows 9x logon server. +</para></listitem> + +<listitem><para> +Windows 9x/ME clients do not possess machine trust accounts. +</para></listitem> + +</itemizedlist> + +<para> +Therefore, a Samba PDC will also act as a Windows 9x logon +server. +</para> + + +<warning> +<title>security mode and master browsers</title> + +<para> +There are a few comments to make in order to tie up some +loose ends. There has been much debate over the issue of whether +or not it is ok to configure Samba as a Domain Controller in security +modes other than <constant>USER</constant>. The only security mode +which will not work due to technical reasons is <constant>SHARE</constant> +mode security. <constant>DOMAIN</constant> and <constant>SERVER</constant> +mode security is really just a variation on SMB user level security. +</para> + +<para> +Actually, this issue is also closely tied to the debate on whether +or not Samba must be the domain master browser for its workgroup +when operating as a DC. While it may technically be possible +to configure a server as such (after all, browsing and domain logons +are two distinctly different functions), it is not a good idea to do +so. You should remember that the DC must register the DOMAIN#1b NetBIOS +name. This is the name used by Windows clients to locate the DC. +Windows clients do not distinguish between the DC and the DMB. +For this reason, it is very wise to configure the Samba DC as the DMB. +</para> + +<para> +Now back to the issue of configuring a Samba DC to use a mode other +than "security = user". If a Samba host is configured to use +another SMB server or DC in order to validate user connection +requests, then it is a fact that some other machine on the network +(the "password server") knows more about the user than the Samba host. +99% of the time, this other host is a domain controller. Now +in order to operate in domain mode security, the "workgroup" parameter +must be set to the name of the Windows NT domain (which already +has a domain controller, right?) +</para> + +<para> +Therefore configuring a Samba box as a DC for a domain that +already by definition has a PDC is asking for trouble. +Therefore, you should always configure the Samba DC to be the DMB +for its domain. +</para> +</warning> + +</sect2> +</sect1> +</chapter> |