diff options
| author | Jelmer Vernooij <jelmer@samba.org> | 2003-09-23 21:24:11 +0000 |
|---|---|---|
| committer | Jelmer Vernooij <jelmer@samba.org> | 2003-09-23 21:24:11 +0000 |
| commit | 4d6b1b6836af6b8e46d03b2f0357a2d171a9c0cb (patch) | |
| tree | 1b410259a6201d72d936cf8b8281624ea887f19a /docs/htmldocs/samba-pdc.html | |
| parent | b222defc2743d7003f3eaa95864e93cbe5bbea66 (diff) | |
| download | samba-4d6b1b6836af6b8e46d03b2f0357a2d171a9c0cb.tar.gz samba-4d6b1b6836af6b8e46d03b2f0357a2d171a9c0cb.tar.bz2 samba-4d6b1b6836af6b8e46d03b2f0357a2d171a9c0cb.zip | |
regenerate
(This used to be commit bdee29ef5b45210c4d6477e5e764a8a298bebaa7)
Diffstat (limited to 'docs/htmldocs/samba-pdc.html')
| -rw-r--r-- | docs/htmldocs/samba-pdc.html | 530 |
1 files changed, 530 insertions, 0 deletions
diff --git a/docs/htmldocs/samba-pdc.html b/docs/htmldocs/samba-pdc.html new file mode 100644 index 0000000000..37c513efff --- /dev/null +++ b/docs/htmldocs/samba-pdc.html @@ -0,0 +1,530 @@ +<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 5. Domain Control</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.60.1"><link rel="home" href="index.html" title="SAMBA Project Documentation"><link rel="up" href="type.html" title="Part II. Server Configuration Basics"><link rel="previous" href="ServerType.html" title="Chapter 4. Server Types and Security Modes"><link rel="next" href="samba-bdc.html" title="Chapter 6. Backup Domain Control"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 5. Domain Control</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ServerType.html">Prev</a> </td><th width="60%" align="center">Part II. Server Configuration Basics</th><td width="20%" align="right"> <a accesskey="n" href="samba-bdc.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="samba-pdc"></a>Chapter 5. Domain Control</h2></div><div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="othername">H.</span> <span class="surname">Terpstra</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:jht@samba.org">jht@samba.org</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Gerald</span> <span class="othername">(Jerry)</span> <span class="surname">Carter</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:jerry@samba.org">jerry@samba.org</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">David</span> <span class="surname">Bannon</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:dbannon@samba.org">dbannon@samba.org</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Guenther</span> <span class="surname">Deschner</span></h3><span class="contrib">LDAP updates</span><div class="affiliation"><span class="orgname">SuSE<br></span><div class="address"><p><tt class="email"><<a href="mailto:gd@suse.de">gd@suse.de</a>></tt></p></div></div></div></div></div><div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><a href="samba-pdc.html#id2870050">Features and Benefits</a></dt><dt><a href="samba-pdc.html#id2870321">Basics of Domain Control</a></dt><dd><dl><dt><a href="samba-pdc.html#id2870336">Domain Controller Types</a></dt><dt><a href="samba-pdc.html#id2889080">Preparing for Domain Control</a></dt></dl></dd><dt><a href="samba-pdc.html#id2889458">Domain Control Example Configuration</a></dt><dt><a href="samba-pdc.html#id2889951">Samba ADS Domain Control</a></dt><dt><a href="samba-pdc.html#id2889989">Domain and Network Logon Configuration</a></dt><dd><dl><dt><a href="samba-pdc.html#id2890004">Domain Network Logon Service</a></dt><dt><a href="samba-pdc.html#id2890439">Security Mode and Master Browsers</a></dt></dl></dd><dt><a href="samba-pdc.html#id2890570">Common Errors</a></dt><dd><dl><dt><a href="samba-pdc.html#id2890577">$ Cannot Be Included in Machine Name</a></dt><dt><a href="samba-pdc.html#id2890661">Joining Domain Fails Because of Existing Machine Account</a></dt><dt><a href="samba-pdc.html#id2890722">The System Cannot Log You On (C000019B)</a></dt><dt><a href="samba-pdc.html#id2890822">The Machine Trust Account Is Not Accessible</a></dt><dt><a href="samba-pdc.html#id2890899">Account Disabled</a></dt><dt><a href="samba-pdc.html#id2890932">Domain Controller Unavailable</a></dt><dt><a href="samba-pdc.html#id2890954">Cannot Log onto Domain Member Workstation After Joining Domain</a></dt></dl></dd></dl></div><p> +There are many who approach MS Windows networking with incredible misconceptions. +That's okay, because it gives the rest of us plenty of opportunity to be of assistance. +Those who really want help would be well advised to become familiar with information +that is already available. +</p><p> +The reader is advised not to tackle this section without having first understood +and mastered some basics. MS Windows networking is not particularly forgiving of +misconfiguration. Users of MS Windows networking are likely to complain +of persistent niggles that may be caused by a broken network configuration. +To a great many people, however, MS Windows networking starts with a Domain Controller +that in some magical way is expected to solve all network operational ills. +</p><p> +The diagram in <link linkend="domain-example"> shows a typical MS Windows Domain Security +network environment. Workstations A, B and C are representative of many physical MS Windows +network clients. +</p><div class="figure"><a name="domain-example"></a><p class="title"><b>Figure 5.1. An Example Domain.</b></p><div class="mediaobject"><img src="projdoc/imagefiles/domain.png" width="270" alt="An Example Domain."></div></div><p> +From the Samba mailing list one can readily identify many common networking issues. +If you are not clear on the following subjects, then it will do much good to read the +sections of this HOWTO that deal with it. These are the most common causes of MS Windows +networking problems: +</p><div class="itemizedlist"><ul type="disc"><li><p>Basic TCP/IP configuration.</p></li><li><p>NetBIOS name resolution.</p></li><li><p>Authentication configuration.</p></li><li><p>User and group configuration.</p></li><li><p>Basic file and directory permission control in UNIX/Linux.</p></li><li><p>Understanding how MS Windows clients interoperate in a network + environment.</p></li></ul></div><p> +Do not be put off; on the surface of it MS Windows networking seems so simple that anyone +can do it. In fact, it is not a good idea to set up an MS Windows network with +inadequate training and preparation. But let's get our first indelible principle out of the +way: <span class="emphasis"><em>It is perfectly okay to make mistakes!</em></span> In the right place and at +the right time, mistakes are the essence of learning. It is very much not okay to make +mistakes that cause loss of productivity and impose an avoidable financial burden on an +organization. +</p><p> +Where is the right place to make mistakes? Only out of harm's way. If you are going to +make mistakes, then please do it on a test network, away from users and in such a way as +to not inflict pain on others. Do your learning on a test network. +</p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2870050"></a>Features and Benefits</h2></div></div><div></div></div><p> +<a class="indexterm" name="id2870061"></a> +<span class="emphasis"><em>What is the key benefit of Microsoft Domain Security?</em></span> +</p><p> +In a word, <span class="emphasis"><em>Single Sign On</em></span>, or SSO for short. To many, this is the Holy +Grail of MS Windows NT and beyond networking. SSO allows users in a well-designed network +to log onto any workstation that is a member of the domain that their user account is in +(or in a domain that has an appropriate trust relationship with the domain they are visiting) +and they will be able to log onto the network and access resources (shares, files and printers) +as if they are sitting at their home (personal) workstation. This is a feature of the Domain +Security protocols. +</p><p> +<a class="indexterm" name="id2870098"></a> +The benefits of Domain Security are available to those sites that deploy a Samba PDC. +A Domain provides a unique network security identifier (SID). Domain user and group security +identifiers are comprised of the network SID plus a relative identifier (RID) that is unique to +the account. User and Group SIDs (the network SID plus the RID) can be used to create Access Control +Lists (ACLs) attached to network resources to provide organizational access control. UNIX systems +recognize only local security identifiers. +</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> +Network clients of an MS Windows Domain Security Environment must be Domain Members to be +able to gain access to the advanced features provided. Domain Membership involves more than just +setting the workgroup name to the Domain name. It requires the creation of a Domain trust account +for the workstation (called a machine account). Refer to <link linkend="domain-member"> +for more information. +</p></div><p> +The following functionalities are new to the Samba-3 release: +</p><div class="itemizedlist"><ul type="disc"><li><p> + Windows NT4 domain trusts. + </p></li><li><p> + <a class="indexterm" name="id2870155"></a> + Adding users via the User Manager for Domains. This can be done on any MS Windows + client using the <tt class="filename">Nexus.exe</tt> toolkit that is available from Microsoft's Web site. + Samba-3 supports the use of the Microsoft Management Console for user management. + </p></li><li><p> + Introduces replaceable and multiple user account (authentication) + backends. In the case where the backend is placed in an LDAP database, + Samba-3 confers the benefits of a backend that can be distributed, replicated + and is highly scalable. + </p></li><li><p> + Implements full Unicode support. This simplifies cross locale internationalization + support. It also opens up the use of protocols that Samba-2.2.x had but could not use due + to the need to fully support Unicode. + </p></li></ul></div><p> +The following functionalities are not provided by Samba-3: +</p><div class="itemizedlist"><ul type="disc"><li><p> +<a class="indexterm" name="id2870209"></a> +<a class="indexterm" name="id2870218"></a> + SAM replication with Windows NT4 Domain Controllers + (i.e., a Samba PDC and a Windows NT BDC or vice versa). This means Samba + cannot operate as a BDC when the PDC is Microsoft-based or + replicate account data to Windows BDCs. + </p></li><li><p> + Acting as a Windows 2000 Domain Controller (i.e., Kerberos and + Active Directory). In point of fact, Samba-3 does have some + Active Directory Domain Control ability that is at this time + purely experimental that is certain to change as it becomes a + fully supported feature some time during the Samba-3 (or later) + life cycle. However, Active Directory is more then just SMB + it's also LDAP, Kerberos, DHCP, and other protocols (with proprietary + extensions, of course). + </p></li><li><p> + The Windows 200x/XP MMC (Computer Management) Console can not be used + to manage a Samba-3 server. For this you can use only the MS Windows NT4 + Domain Server manager and the MS Windows NT4 Domain User Manager. Both are + part of the SVRTOOLS.EXE package mentioned later. + </p></li></ul></div><p> +Windows 9x/Me/XP Home clients are not true members of a domain for reasons outlined +in this chapter. The protocol for support of Windows 9x/Me style network (domain) logons +is completely different from NT4/Windows 200x type domain logons and has been officially supported +for some time. These clients use the old LanMan Network Logon facilities that are supported +in Samba since approximately the Samba-1.9.15 series. +</p><p> +Samba-3 implements group mapping between Windows NT groups +and UNIX groups (this is really quite complicated to explain in a short space). This is +discussed more fully in <link linkend="groupmapping">. +</p><p> +<a class="indexterm" name="id2870290"></a> +Samba-3, like an MS Windows NT4 PDC or a Windows 200x Active Directory, needs to store +user and Machine Trust Account information in a suitable backend datastore. +Refer to <link linkend="machine-trust-accounts">. With Samba-3 there can be multiple +backends for this. A complete discussion of account database backends can be found in +<link linkend="passdb">. +</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2870321"></a>Basics of Domain Control</h2></div></div><div></div></div><p> +Over the years, public perceptions of what Domain Control really is has taken on an +almost mystical nature. Before we branch into a brief overview of Domain Control, +there are three basic types of Domain Controllers. +</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2870336"></a>Domain Controller Types</h3></div></div><div></div></div><div class="itemizedlist"><ul type="disc"><li><p>Primary Domain Controller</p></li><li><p>Backup Domain Controller</p></li><li><p>ADS Domain Controller</p></li></ul></div><p> +The <span class="emphasis"><em>Primary Domain Controller</em></span> or PDC plays an important role in MS +Windows NT4. In Windows 200x Domain Control architecture, this role is held by Domain Controllers. +Folklore dictates that because of its role in the MS Windows +network, the Domain Controller should be the most powerful and most capable machine in the network. +As strange as it may seem to say this here, good overall network performance dictates that +the entire infrastructure needs to be balanced. It is advisable to invest more in Stand-alone +(Domain Member) servers than in the Domain Controllers. +</p><p> +<a class="indexterm" name="id2870387"></a> +In the case of MS Windows NT4-style domains, it is the PDC that initiates a new Domain Control database. +This forms a part of the Windows registry called the Security Account Manager (SAM). It plays a key +part in NT4-type domain user authentication and in synchronization of the domain authentication +database with Backup Domain Controllers. +</p><p> +With MS Windows 200x Server-based Active Directory domains, one Domain Controller initiates a potential +hierarchy of Domain Controllers, each with their own area of delegated control. The master domain +controller has the ability to override any downstream controller, but a downline controller has +control only over its downline. With Samba-3, this functionality can be implemented using an +LDAP-based user and machine account backend. +</p><p> +New to Samba-3 is the ability to use a backend database that holds the same type of data as +the NT4-style SAM database (one of the registry files)<sup>[<a name="id2870421" href="#ftn.id2870421">1</a>]</sup>. +</p><p> +The <span class="emphasis"><em>Backup Domain Controller</em></span> or BDC plays a key role in servicing network +authentication requests. The BDC is biased to answer logon requests in preference to the PDC. +On a network segment that has a BDC and a PDC, the BDC will most likely service network +logon requests. The PDC will answer network logon requests when the BDC is too busy (high load). +A BDC can be promoted to a PDC. If the PDC is online at the time that a BDC is promoted to +PDC, the previous PDC is automatically demoted to a BDC. With Samba-3, this is not an automatic +operation; the PDC and BDC must be manually configured and changes also need to be made. +</p><p> +With MS Windows NT4, a decision is made at installation to determine what type of machine the server will be. +It is possible to promote a BDC to a PDC and vice versa. The only way +to convert a Domain Controller to a Domain Member server or a Stand-alone Server is to +reinstall it. The install time choices offered are: +</p><div class="itemizedlist"><ul type="disc"><li><p><span class="emphasis"><em>Primary Domain Controller</em></span> the one that seeds the domain SAM.</p></li><li><p><span class="emphasis"><em>Backup Domain Controller</em></span> one that obtains a copy of the domain SAM.</p></li><li><p><span class="emphasis"><em>Domain Member Server</em></span> one that has no copy of the domain SAM, rather it obtains authentication from a Domain Controller for all access controls.</p></li><li><p><span class="emphasis"><em>Stand-alone Server</em></span> one that plays no part is SAM synchronization, has its own authentication database and plays no role in Domain Security.</p></li></ul></div><p> +With MS Windows 2000, the configuration of Domain Control is done after the server has been +installed. Samba-3 is capable of acting fully as a native member of a Windows 200x server +Active Directory domain. +</p><p> +<a class="indexterm" name="id2889012"></a> +New to Samba-3 is the ability to function fully as an MS Windows NT4-style Domain Controller, +excluding the SAM replication components. However, please be aware that Samba-3 also supports the +MS Windows 200x Domain Control protocols. +</p><p> +At this time any appearance that Samba-3 is capable of acting as an +<span class="emphasis"><em>Domain Controller</em></span> in native ADS mode is limited and experimental in nature. +This functionality should not be used until the Samba Team offers formal support for it. +At such a time, the documentation will be revised to duly reflect all configuration and +management requirements. Samba can act as a NT4-style DC in a Windows 2000/XP +environment. However, there are certain compromises: + +</p><div class="itemizedlist"><ul type="disc"><li>No machine policy files.</li><li>No Group Policy Objects.</li><li>No synchronously executed AD logon scripts.</li><li>Can't use Active Directory management tools to manage users and machines.</li><li>Registry changes tattoo the main registry, while with AD they do not leave permanent changes in effect.</li><li>Without AD you cannot perform the function of exporting specific applications to specific users or groups.</li></ul></div><p> +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2889080"></a>Preparing for Domain Control</h3></div></div><div></div></div><p> +There are two ways that MS Windows machines may interact with each other, with other servers +and with Domain Controllers: either as <span class="emphasis"><em>Stand-alone</em></span> systems, more commonly +called <span class="emphasis"><em>Workgroup</em></span> members, or as full participants in a security system, +more commonly called <span class="emphasis"><em>Domain</em></span> members. +</p><p> +It should be noted that <span class="emphasis"><em>Workgroup</em></span> membership involves no special configuration +other than the machine being configured so the network configuration has a commonly used name +for its workgroup entry. It is not uncommon for the name WORKGROUP to be used for this. With this +mode of configurationi, there are no Machine Trust Accounts and any concept of membership as such +is limited to the fact that all machines appear in the network neighborhood to be logically +grouped together. Again, just to be clear: <span class="emphasis"><em>workgroup mode does not involve security machine +accounts</em></span>. +</p><p> +Domain Member machines have a machine account in the Domain accounts database. A special procedure +must be followed on each machine to effect Domain Membership. This procedure, which can be done +only by the local machine Administrator account, will create the Domain machine account (if it does +not exist), and then initializes that account. When the client first logs onto the +Domain it triggers a machine password change. +</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> +When Samba is configured as a Domain Controller, secure network operation demands that +all MS Windows NT4/200x/XP Professional clients should be configured as Domain Members. +If a machine is not made a member of the Domain, then it will operate like a workgroup +(Stand-alone) machine. Please refer to <link linkend="domain-member"> for +information regarding Domain Membership. +</p></div><p> +The following are necessary for configuring Samba-3 as an MS Windows NT4-style PDC for MS Windows +NT4/200x/XP clients: +</p><div class="itemizedlist"><ul type="disc"><li><p>Configuration of basic TCP/IP and MS Windows networking.</p></li><li><p>Correct designation of the Server Role (<a class="indexterm" name="id2889184"></a><i class="parameter"><tt>security</tt></i> = user).</p></li><li><p>Consistent configuration of Name Resolution<sup>[<a name="id2889204" href="#ftn.id2889204">2</a>]</sup>.</p></li><li><p>Domain logons for Windows NT4/200x/XP Professional clients.</p></li><li><p>Configuration of Roaming Profiles or explicit configuration to force local profile usage.</p></li><li><p>Configuration of network/system policies.</p></li><li><p>Adding and managing domain user accounts.</p></li><li><p>Configuring MS Windows client machines to become Domain Members.</p></li></ul></div><p> +The following provisions are required to serve MS Windows 9x/Me clients: +</p><div class="itemizedlist"><ul type="disc"><li><p>Configuration of basic TCP/IP and MS Windows networking.</p></li><li><p>Correct designation of the server role (<a class="indexterm" name="id2889279"></a><i class="parameter"><tt>security</tt></i> = user).</p></li><li><p>Network Logon Configuration (since Windows 9x/Me/XP Home are not technically domain + members, they do not really participate in the security aspects of Domain logons as such).</p></li><li><p>Roaming Profile Configuration.</p></li><li><p>Configuration of System Policy handling.</p></li><li><p>Installation of the network driver “<span class="quote">Client for MS Windows Networks</span>” and configuration + to log onto the domain.</p></li><li><p>Placing Windows 9x/Me clients in User Level Security if it is desired to allow + all client share access to be controlled according to domain user/group identities.</p></li><li><p>Adding and managing domain user accounts.</p></li></ul></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> +Roaming Profiles and System/Network policies are advanced network administration topics +that are covered in the <link linkend="ProfileMgmt"> and +<link linkend="PolicyMgmt"> chapters of this document. However, these are not +necessarily specific to a Samba PDC as much as they are related to Windows NT networking concepts. +</p></div><p> +A Domain Controller is an SMB/CIFS server that: +</p><div class="itemizedlist"><ul type="disc"><li><p> + Registers and advertises itself as a Domain Controller (through NetBIOS broadcasts + as well as by way of name registrations either by Mailslot Broadcasts over UDP broadcast, + to a WINS server over UDP unicast, or via DNS and Active Directory). + </p></li><li><p> + Provides the NETLOGON service. (This is actually a collection of services that runs over + mulitple protocols. These include the LanMan Logon service, the Netlogon service, + the Local Security Account service, and variations of them.) + </p></li><li><p> + Provides a share called NETLOGON. + </p></li></ul></div><p> +It is rather easy to configure Samba to provide these. Each Samba Domain Controller must provide +the NETLOGON service that Samba calls the <a class="indexterm" name="id2889409"></a><i class="parameter"><tt>domain logons</tt></i> functionality +(after the name of the parameter in the <tt class="filename">smb.conf</tt> file). Additionally, one server in a Samba-3 +Domain must advertise itself as the Domain Master Browser<sup>[<a name="id2889433" href="#ftn.id2889433">3</a>]</sup>. +This causes the Primary Domain Controller to claim a domain-specific NetBIOS name that identifies it as a +Domain Master Browser for its given domain or workgroup. Local master browsers in the same domain or workgroup on +broadcast-isolated subnets then ask for a complete copy of the browse list for the whole wide area network. +Browser clients will then contact their Local Master Browser, and will receive the domain-wide browse list, +instead of just the list for their broadcast-isolated subnet. +</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2889458"></a>Domain Control Example Configuration</h2></div></div><div></div></div><p> +The first step in creating a working Samba PDC is to understand the parameters necessary +in <tt class="filename">smb.conf</tt>. An example <tt class="filename">smb.conf</tt> for acting as a PDC can be found in <link linkend="pdc-example">. +</p><p> +</p><div class="example"><a name="pdc-example"></a><p class="title"><b>Example 5.1. smb.conf for being a PDC</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><i class="parameter"><tt>[global]</tt></i></td></tr><tr><td><i class="parameter"><tt>netbios name = BELERIAND</tt></i></td></tr><tr><td><i class="parameter"><tt>workgroup = MIDEARTH</tt></i></td></tr><tr><td><i class="parameter"><tt>passdb backend = tdbsam</tt></i></td></tr><tr><td><i class="parameter"><tt>os level = 33</tt></i></td></tr><tr><td><i class="parameter"><tt>preferred master = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>domain master = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>local master = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>security = user</tt></i></td></tr><tr><td><i class="parameter"><tt>domain logons = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>logon path = \\%N\profiles\%u</tt></i></td></tr><tr><td><i class="parameter"><tt>logon drive = H:</tt></i></td></tr><tr><td><i class="parameter"><tt>logon home = \\homeserver\%u\winprofile</tt></i></td></tr><tr><td><i class="parameter"><tt>logon script = logon.cmd</tt></i></td></tr><tr><td> </td></tr><tr><td><i class="parameter"><tt>[netlogon]</tt></i></td></tr><tr><td><i class="parameter"><tt>path = /var/lib/samba/netlogon</tt></i></td></tr><tr><td><i class="parameter"><tt>read only = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>write list = ntadmin</tt></i></td></tr><tr><td> </td></tr><tr><td><i class="parameter"><tt>[profiles]</tt></i></td></tr><tr><td><i class="parameter"><tt>path = /var/lib/samba/profiles</tt></i></td></tr><tr><td><i class="parameter"><tt>read only = no</tt></i></td></tr><tr><td><i class="parameter"><tt>create mask = 0600</tt></i></td></tr><tr><td><i class="parameter"><tt>directory mask = 0700</tt></i></td></tr></table></div><p> +</p><p> +The basic options shown in <link linkend="pdc-example"> are explained as follows: +</p><div class="variablelist"><dl><dt><span class="term">passdb backend </span></dt><dd><p> + This contains all the user and group account information. Acceptable values for a PDC + are: <span class="emphasis"><em>smbpasswd, tdbsam, and ldapsam</em></span>. The “<span class="quote">guest</span>” entry provides + default accounts and is included by default, there is no need to add it explicitly.</p><p> + Where use of backup Domain Controllers (BDCs) is intended, the only logical choice is + to use LDAP so the passdb backend can be distributed. The tdbsam and smbpasswd files + cannot effectively be distributed and therefore should not be used. + </p></dd><dt><span class="term">Domain Control Parameters </span></dt><dd><p> + The parameters <span class="emphasis"><em>os level, preferred master, domain master, security, + encrypt passwords, and domain logons</em></span> play a central role in assuring domain + control and network logon support.</p><p> + The <span class="emphasis"><em>os level</em></span> must be set at or above a value of 32. A Domain Controller + must be the Domain Master Browser, must be set in <span class="emphasis"><em>user</em></span> mode security, + must support Microsoft-compatible encrypted passwords, and must provide the network logon + service (domain logons). Encrypted passwords must be enabled. For more details on how + to do this, refer to <link linkend="passdb">. + </p></dd><dt><span class="term">Environment Parameters </span></dt><dd><p> + The parameters <span class="emphasis"><em>logon path, logon home, logon drive, and logon script</em></span> are + environment support settings that help to facilitate client logon operations and that help + to provide automated control facilities to ease network management overheads. Please refer + to the man page information for these parameters. + </p></dd><dt><span class="term">NETLOGON Share </span></dt><dd><p> + The NETLOGON share plays a central role in domain logon and Domain Membership support. + This share is provided on all Microsoft Domain Controllers. It is used to provide logon + scripts, to store Group Policy files (NTConfig.POL), as well as to locate other common + tools that may be needed for logon processing. This is an essential share on a Domain Controller. + </p></dd><dt><span class="term">PROFILE Share </span></dt><dd><p> + This share is used to store user desktop profiles. Each user must have a directory at the root + of this share. This directory must be write-enabled for the user and must be globally read-enabled. + Samba-3 has a VFS module called “<span class="quote">fake_permissions</span>” that may be installed on this share. This will + allow a Samba administrator to make the directory read-only to everyone. Of course this is useful + only after the profile has been properly created. + </p></dd></dl></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> +The above parameters make for a full set of parameters that may define the server's mode +of operation. The following <tt class="filename">smb.conf</tt> parameters are the essentials alone: +</p><p> +</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>netbios name = BELERIAND</tt></i></td></tr><tr><td><i class="parameter"><tt>workgroup = MIDEARTH</tt></i></td></tr><tr><td><i class="parameter"><tt>domain logons = Yes</tt></i></td></tr><tr><td><i class="parameter"><tt>domain master = Yes</tt></i></td></tr><tr><td><i class="parameter"><tt>security = User</tt></i></td></tr></table><p> +</p><p> +The additional parameters shown in the longer listing above just makes for +a more complete explanation. +</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2889951"></a>Samba ADS Domain Control</h2></div></div><div></div></div><p> +Samba-3 is not, and cannot act as, an Active Directory Server. It cannot truly function as +an Active Directory Primary Domain Controller. The protocols for some of the functionality +of Active Directory Domain Controllers has been partially implemented on an experimental +only basis. Please do not expect Samba-3 to support these protocols. Do not depend +on any such functionality either now or in the future. The Samba Team may remove these +experimental features or may change their behavior. This is mentioned for the benefit of those +who have discovered secret capabilities in Samba-3 and who have asked when this functionality will be +completed. The answer is maybe or maybe never! +</p><p> +To be sure, Samba-3 is designed to provide most of the functionality that Microsoft Windows NT4-style +Domain Controllers have. Samba-3 does not have all the capabilities of Windows NT4, but it does have +a number of features that Windows NT4 domain contollers do not have. In short, Samba-3 is not NT4 and it +is not Windows Server 200x, it is not an Active Directory server. We hope this is plain and simple +enough for all to understand. +</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2889989"></a>Domain and Network Logon Configuration</h2></div></div><div></div></div><p> +The subject of Network or Domain Logons is discussed here because it forms +an integral part of the essential functionality that is provided by a Domain Controller. +</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2890004"></a>Domain Network Logon Service</h3></div></div><div></div></div><p> +All Domain Controllers must run the netlogon service (<span class="emphasis"><em>domain logons</em></span> +in Samba). One Domain Controller must be configured with <a class="indexterm" name="id2890021"></a><i class="parameter"><tt>domain master</tt></i> = Yes +(the Primary Domain Controller); on all Backup Domain Controllers <a class="indexterm" name="id2890038"></a><i class="parameter"><tt>domain master</tt></i> = No +must be set. +</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2890053"></a>Example Configuration</h4></div></div><div></div></div><div class="example"><a name="PDC-config"></a><p class="title"><b>Example 5.2. smb.conf for being a PDC</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><i class="parameter"><tt>[global]</tt></i></td></tr><tr><td><i class="parameter"><tt>domain logons = Yes</tt></i></td></tr><tr><td><i class="parameter"><tt>domain master = (Yes on PDC, No on BDCs)</tt></i></td></tr><tr><td> </td></tr><tr><td><i class="parameter"><tt>[netlogon]</tt></i></td></tr><tr><td><i class="parameter"><tt>comment = Network Logon Service</tt></i></td></tr><tr><td><i class="parameter"><tt>path = /var/lib/samba/netlogon</tt></i></td></tr><tr><td><i class="parameter"><tt>guest ok = Yes</tt></i></td></tr><tr><td><i class="parameter"><tt>browseable = No</tt></i></td></tr></table></div></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2890149"></a>The Special Case of MS Windows XP Home Edition</h4></div></div><div></div></div><p> +To be completely clear: If you want MS Windows XP Home Edition to integrate with your +MS Windows NT4 or Active Directory Domain Security, understand it cannot be done. +The only option is to purchase the upgrade from MS Windows XP Home Edition to +MS Windows XP Professional. +</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> +MS Windows XP Home Edition does not have the ability to join any type of Domain +Security facility. Unlike MS Windows 9x/Me, MS Windows XP Home Edition also completely +lacks the ability to log onto a network. +</p></div><p> +Now that this has been said, please do not ask the mailing list or email any of the +Samba Team members with your questions asking how to make this work. It can't be done. +If it can be done, then to do so would violate your software license agreement with +Microsoft, and we recommend that you do not do that. +</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2890186"></a>The Special Case of Windows 9x/Me</h4></div></div><div></div></div><p> +A domain and a workgroup are exactly the same 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 as MS Windows NT/200x. +</p><p> +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. +</p><p> +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. +</p><p> +When an SMB client in a domain wishes to logon, it broadcasts 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 ill advised ) 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. +</p><p> +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. +</p><p><span class="emphasis"><em> +MS Windows XP Home edition is not able to join a domain and does not permit +the use of domain logons. +</em></span></p><p> +Before launching into the configuration instructions, it is +worthwhile to look at how a Windows 9x/Me client performs a logon: +</p><div class="orderedlist"><ol type="1"><li><p> + 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 + <tt class="filename">\\SERVER</tt>. + </p></li><li><p> + The client connects to that server, logs on (does an SMBsessetupX) and + then connects to the IPC$ share (using an SMBtconX). + </p></li><li><p> + The client does a NetWkstaUserLogon request, which retrieves the name + of the user's logon script. + </p></li><li><p> + The client then connects to the NetLogon share and searches for said script. + If it is found and can be read, it is retrieved and executed by the client. + After this, the client disconnects from the NetLogon share. + </p></li><li><p> + The client 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 than + the user's home share, profiles for Windows 9x clients must reside in the user + home directory. + </p></li><li><p> + The client 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, <tt class="filename">\\server\fred\.winprofile</tt>. + If the profiles are found, they are implemented. + </p></li><li><p> + The client then disconnects from the user's home share and reconnects to + the NetLogon share and looks for <tt class="filename">CONFIG.POL</tt>, the policies file. If this is + found, it is read and implemented. + </p></li></ol></div><p> +The main difference between a PDC and a Windows 9x/Me logon server configuration is: +</p><div class="itemizedlist"><ul type="disc"><li><p> + Password encryption is not required for a Windows 9x/Me logon server. But note + that beginning with MS Windows 98 the default setting is that plain-text + password support is disabled. It can be re-enabled with the registry + changes that are documented in <link linkend="PolicyMgmt">. + </p></li><li><p> + Windows 9x/Me clients do not require and do not use Machine Trust Accounts. + </p></li></ul></div><p> +A Samba PDC will act as a Windows 9x/Me logon server; after all, it does provide the +network logon services that MS Windows 9x/Me expect to find. +</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> +Use of plain-text passwords is strongly discouraged. Where used they are easily detected +using a sniffer tool to examine network traffic. +</p></div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2890439"></a>Security Mode and Master Browsers</h3></div></div><div></div></div><p> +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 it is okay to configure Samba as a Domain +Controller in security modes other than user. The only security mode that will +not work due to technical reasons is share-mode security. Domain and server mode +security are really just a variation on SMB User Level Security. +</p><p> +Actually, this issue is also closely tied to the debate on whether +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. +A DMB is a Domain Master Browser see <link linkend="DMB">. +For this reason, it is wise to configure the Samba DC as the DMB. +</p><p> +Now back to the issue of configuring a Samba DC to use a mode other than +<a class="indexterm" name="id2890493"></a><i class="parameter"><tt>security</tt></i> = user. If a Samba host is +configured to use another SMB server or DC in order to validate user connection requests, +it is a fact that some other machine on the network (the <a class="indexterm" name="id2890510"></a><i class="parameter"><tt>password server</tt></i>) +knows more about the user than the Samba host. About 99% of the time, this other host is +a Domain Controller. Now to operate in domain mode security, the <a class="indexterm" name="id2890527"></a><i class="parameter"><tt>workgroup</tt></i> +parameter must be set to the name of the Windows NT domain (which already has a Domain Controller). +If the domain does not already have a Domain Controller, you do not yet have a Domain. +</p><p> +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 and set <a class="indexterm" name="id2890552"></a><i class="parameter"><tt>security</tt></i> = user. +This is the only officially supported mode of operation. +</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2890570"></a>Common Errors</h2></div></div><div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2890577"></a>“<span class="quote">$</span>” Cannot Be Included in Machine Name</h3></div></div><div></div></div><p> +A machine account, typically stored in <tt class="filename">/etc/passwd</tt>, takes the form of the machine +name with a “<span class="quote">$</span>” appended. FreeBSD (and other BSD systems) will not create a user with a +“<span class="quote">$</span>” in the name. +</p><p> +The problem is only in the program used to make the entry. Once made, it works perfectly. +Create a user without the “<span class="quote">$</span>”. Then use <b class="command">vipw</b> to edit the entry, adding +the “<span class="quote">$</span>”. Or create the whole entry with vipw if you like; make sure you use a unique user login ID. +</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>The machine account must have the exact name that the workstation has.</div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> +The UNIX tool <b class="command">vipw</b> is a common tool for directly editing the <tt class="filename">/etc/passwd</tt> file. +</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2890661"></a>Joining Domain Fails Because of Existing Machine Account</h3></div></div><div></div></div><p> +“<span class="quote">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.</span>” +</p><p> +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: +</p><pre class="screen"> +<tt class="prompt">C:\> </tt><b class="userinput"><tt>net use * /d</tt></b> +</pre><p> +</p><p> +Further, if the machine is already a “<span class="quote">member of a workgroup</span>” 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. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2890722"></a>The System Cannot Log You On (C000019B)</h3></div></div><div></div></div><p>“<span class="quote">I joined the domain successfully but after upgrading +to a newer version of the Samba code I get the message, <span class="errorname">`The system +cannot log you on (C000019B), Please try again or consult your +system administrator</span> when attempting to logon.'</span>” +</p><p> +<a class="indexterm" name="id2890749"></a> +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. +</p><p> +To reset or change the domain SID you can use the net command as follows: + +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>net getlocalsid 'OLDNAME'</tt></b> +<tt class="prompt">root# </tt><b class="userinput"><tt>net setlocalsid 'SID'</tt></b> +</pre><p> +</p><p> +Workstation Machine Trust Accounts work only with the Domain (or network) SID. If this SID changes +Domain Members (workstations) will not be able to log onto the domain. The original Domain SID +can be recovered from the secrets.tdb file. The alternative is to visit each workstation to re-join +it to the domain. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2890822"></a>The Machine Trust Account Is Not Accessible</h3></div></div><div></div></div><p> +“<span class="quote">When I try to join the domain I get the message, <span class="errorname">`The machine account +for this computer either does not exist or is not accessible'</span>. What's +wrong?</span>” +</p><p> +This problem is caused by the PDC not having a suitable Machine Trust Account. +If you are using the <a class="indexterm" name="id2890849"></a><i class="parameter"><tt>add machine script</tt></i> method to create +accounts then this would indicate that it has not worked. Ensure the domain +admin user system is working. +</p><p> +Alternately, 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 <tt class="filename">smbpasswd</tt> 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 “<span class="quote">$</span>” appended to it (i.e., computer_name$). There must be an entry +in both /etc/passwd and the smbpasswd file. +</p><p> +Some people have also reported that inconsistent subnet masks between the Samba server and the NT +client can cause this problem. Make sure that these are consistent for both client and server. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2890899"></a>Account Disabled</h3></div></div><div></div></div><p>“<span class="quote">When I attempt to login to a Samba Domain from a NT4/W200x workstation, +I get a message about my account being disabled.</span>”</p><p> +Enable the user accounts with <b class="userinput"><tt>smbpasswd -e <i class="replaceable"><tt>username</tt></i> +</tt></b>. This is normally done as an account is created. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2890932"></a>Domain Controller Unavailable</h3></div></div><div></div></div><p>“<span class="quote">Until a few minutes after Samba has started, clients get the error `Domain Controller Unavailable'</span>”</p><p> +A Domain Controller has to announce its role on the network. This usually takes a while. Be patient for up to fifteen minutes, +then try again. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2890954"></a>Cannot Log onto Domain Member Workstation After Joining Domain</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2890966"></a> +<a class="indexterm" name="id2890975"></a> +After successfully joining the domain, user logons fail with one of two messages: one to the +effect that the Domain Controller cannot be found; the other claims that the account does not +exist in the domain or that the password is incorrect. This may be due to incompatible +settings between the Windows client and the Samba-3 server for <span class="emphasis"><em>schannel</em></span> +(secure channel) settings or <span class="emphasis"><em>smb signing</em></span> settings. Check your Samba +settings for <span class="emphasis"><em> client schannel, server schannel, client signing, server signing</em></span> +by executing: +</p><pre class="screen"> +<b class="command">testparm -v | more</b> and looking for the value of these parameters. +</pre><p> +</p><p> +Also use the Microsoft Management Console Local Security Settings. This tool is available from the +Control Panel. The Policy settings are found in the Local Policies/Securty Options area and are prefixed by +<span class="emphasis"><em>Secure Channel: ..., and Digitally sign ....</em></span>. +</p><p> +It is important that these be set consistently with the Samba-3 server settings. +</p></div></div><div class="footnotes"><br><hr width="100" align="left"><div class="footnote"><link linkend="passdb"></div><div class="footnote"><p><sup>[<a name="ftn.id2889204" href="#id2889204">2</a>] </sup>See <link linkend="NetworkBrowsing">, and + <link linkend="integrate-ms-networks">.</p></div><div class="footnote"><link linkend="NetworkBrowsing"></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ServerType.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="type.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="samba-bdc.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 4. Server Types and Security Modes </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 6. Backup Domain Control</td></tr></table></div></body></html> |