diff options
Diffstat (limited to 'docs/docbook/projdoc/Samba-PDC-HOWTO.sgml')
| -rw-r--r-- | docs/docbook/projdoc/Samba-PDC-HOWTO.sgml | 842 |
1 files changed, 0 insertions, 842 deletions
diff --git a/docs/docbook/projdoc/Samba-PDC-HOWTO.sgml b/docs/docbook/projdoc/Samba-PDC-HOWTO.sgml deleted file mode 100644 index 6a3bcacf17..0000000000 --- a/docs/docbook/projdoc/Samba-PDC-HOWTO.sgml +++ /dev/null @@ -1,842 +0,0 @@ -<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> |