--- /dev/null
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 4. Domain Control</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.68.1"><link rel="start" href="index.html" title="The Official Samba-3 HOWTO and Reference Guide"><link rel="up" href="type.html" title="Part II. Server Configuration Basics"><link rel="prev" href="ServerType.html" title="Chapter 3. Server Types and Security Modes"><link rel="next" href="samba-bdc.html" title="Chapter 5. 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 4. 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 4. 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><code class="email"><<a href="mailto:jht@samba.org">jht@samba.org</a>></code></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><code class="email"><<a href="mailto:jerry@samba.org">jerry@samba.org</a>></code></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><code class="email"><<a href="mailto:dbannon@samba.org">dbannon@samba.org</a>></code></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><code class="email"><<a href="mailto:gd@suse.de">gd@suse.de</a>></code></p></div></div></div></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="samba-pdc.html#id2529015">Features and Benefits</a></span></dt><dt><span class="sect1"><a href="samba-pdc.html#id2529649">Single Sign-On and Domain Security</a></span></dt><dt><span class="sect1"><a href="samba-pdc.html#id2530217">Basics of Domain Control</a></span></dt><dd><dl><dt><span class="sect2"><a href="samba-pdc.html#id2530237">Domain Controller Types</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id2530749">Preparing for Domain Control</a></span></dt></dl></dd><dt><span class="sect1"><a href="samba-pdc.html#id2531253">Domain Control: Example Configuration</a></span></dt><dt><span class="sect1"><a href="samba-pdc.html#id2532037">Samba ADS Domain Control</a></span></dt><dt><span class="sect1"><a href="samba-pdc.html#id2532090">Domain and Network Logon Configuration</a></span></dt><dd><dl><dt><span class="sect2"><a href="samba-pdc.html#id2532109">Domain Network Logon Service</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id2532698">Security Mode and Master Browsers</a></span></dt></dl></dd><dt><span class="sect1"><a href="samba-pdc.html#id2532953">Common Errors</a></span></dt><dd><dl><dt><span class="sect2"><a href="samba-pdc.html#id2532958">“<span class="quote">$</span>” Cannot Be Included in Machine Name</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id2533060">Joining Domain Fails Because of Existing Machine Account</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id2533124">The System Cannot Log You On (C000019B)</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id2533201">The Machine Trust Account Is Not Accessible</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id2533316">Account Disabled</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id2533343">Domain Controller Unavailable</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id2533362">Cannot Log onto Domain Member Workstation After Joining Domain</a></span></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 are well advised to become familiar with information
+that is already available.
+</p><p>
+<a class="indexterm" name="id2528877"></a>
+You are 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>
+<a href="samba-pdc.html#domain-example" title="Figure 4.1. An Example Domain.">The Example Domain Illustration</a> 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 4.1. An Example Domain.</b></p><div class="mediaobject"><img src="images/domain.png" width="216" alt="An Example Domain."></div></div><p>
+From the Samba mailing list we 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 harms 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="id2529015"></a>Features and Benefits</h2></div></div></div><p>
+<a class="indexterm" name="id2529023"></a>
+<span class="emphasis"><em>What is the key benefit of Microsoft Domain Security?</em></span>
+</p><p>
+<a class="indexterm" name="id2529038"></a>
+<a class="indexterm" name="id2529047"></a>
+<a class="indexterm" name="id2529054"></a>
+<a class="indexterm" name="id2529060"></a>
+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 contains their user account (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="id2529088"></a>
+<a class="indexterm" name="id2529095"></a>
+<a class="indexterm" name="id2529101"></a>
+<a class="indexterm" name="id2529110"></a>
+<a class="indexterm" name="id2529120"></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><p>
+<a class="indexterm" name="id2529138"></a>
+A SID represents a security context. For example, every Windows machine has local accounts within the security
+context of the local machine which has a unique SID. Every domain (NT4, ADS, Samba) contains accounts that
+exist within the domain security context which is defined by the domain SID.
+</p><p>
+<a class="indexterm" name="id2529153"></a>
+<a class="indexterm" name="id2529160"></a>
+A domain member server will have a SID that differs from the domain SID. The domain member server can be
+configured to regard all domain users as local users. It can also be configured to recognize domain users and
+groups as non-local. SIDs are persistent. A typical domain of user SID looks like this:
+</p><pre class="screen">
+S-1-5-21-726309263-4128913605-1168186429
+</pre><p>
+Every account (user, group, machine, trust, etc.) is assigned a RID. This is done automatically as an account
+is created. Samba produces the RID algorithmically. The UNIX operating system uses a separate name space for
+user and group identifiers (the UID and GID) but Windows allocates the RID from a single name space. A Windows
+user and a Windows group can not have the same RID. Just as the UNIX user <code class="literal">root</code> has the
+UID=0, the Windows Administrator has the well-known RID=500. The RID is catenated to the Windows domain SID,
+so Administrator account for a domain that has the above SID will have the user SID
+</p><pre class="screen">
+S-1-5-21-726309263-4128913605-1168186429-500
+</pre><p>
+The result is that every account in the Windows networking world has a globally unique security identifier.
+</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+<a class="indexterm" name="id2529207"></a>
+<a class="indexterm" name="id2529216"></a>
+<a class="indexterm" name="id2529223"></a>
+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 <a href="domain-member.html" title="Chapter 6. Domain Membership">Domain Membership</a> 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>
+ <a class="indexterm" name="id2529257"></a>
+ Samba-3 supports the use of a choice of backends that may be used in which user, group and machine
+ accounts may be stored. Multiple passwd backends can be used in combination, either as additive backend
+ data sets, or as fail-over data sets.
+ </p><p>
+ <a class="indexterm" name="id2529273"></a>
+ <a class="indexterm" name="id2529280"></a>
+ <a class="indexterm" name="id2529287"></a>
+ <a class="indexterm" name="id2529294"></a>
+ <a class="indexterm" name="id2529300"></a>
+ An LDAP passdb backend confers the benefit that the account backend can be distributed and replicated,
+ which is of great value because it confers scalability and provides a high degree of reliability.
+ </p></li><li><p>
+ <a class="indexterm" name="id2529315"></a>
+ <a class="indexterm" name="id2529327"></a>
+ <a class="indexterm" name="id2529336"></a>
+ Windows NT4 domain trusts. Samba-3 supports workstation and server (machine) trust accounts. It also
+ supports Windows NT4 style interdomain trust accounts, which further assists in network scalability
+ and interoperability.
+ </p></li><li><p>
+ <a class="indexterm" name="id2529351"></a>
+ <a class="indexterm" name="id2529358"></a>
+ <a class="indexterm" name="id2529365"></a>
+ <a class="indexterm" name="id2529372"></a>
+ <a class="indexterm" name="id2529381"></a>
+ <a class="indexterm" name="id2529390"></a>
+ Operation without NetBIOS over TCP/IP, rather using the raw SMB over TCP/IP. Note, this is feasible
+ only when operating as a Microsoft active directory domain member server. When acting as a Samba domain
+ controller the use of NetBIOS is necessary to provide network browsing support.
+ </p></li><li><p>
+ <a class="indexterm" name="id2529409"></a>
+ <a class="indexterm" name="id2529416"></a>
+ <a class="indexterm" name="id2529422"></a>
+ Samba-3 provides NetBIOS name services (WINS), NetBIOS over TCP/IP (TCP port 139) session services, SMB over
+ TCP/IP (TCP port 445) session services, and Microsoft compatible ONC DCE RPC services (TCP port 135)
+ services.
+ </p></li><li><p>
+ <a class="indexterm" name="id2529437"></a>
+ Management of users and groups via the User Manager for Domains. This can be done on any MS Windows client
+ using the <code class="filename">Nexus.exe</code> toolkit for Windows 9x/Me, or using the SRVTOOLS.EXE package for MS
+ Windows NT4/200x/XP platforms. These packages are available from Microsoft's Web site.
+ </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="id2529475"></a>
+ <a class="indexterm" name="id2529481"></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 Windows NT PDC. Samba-3 can not
+ participate in replication of account data to Windows PDCs and BDCs.
+ </p></li><li><p>
+ <a class="indexterm" name="id2529497"></a>
+ <a class="indexterm" name="id2529504"></a>
+ Acting as a Windows 2000 active directory 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.
+ Active directory domain control is one of the features that is being developed in Samba-4, the next
+ generation Samba release. At this time there are no plans to enable active directory domain control
+ support during the Samba-3 series life-cycle.
+ </p></li><li><p>
+ <a class="indexterm" name="id2529523"></a>
+ <a class="indexterm" name="id2529530"></a>
+ <a class="indexterm" name="id2529537"></a>
+ The Windows 200x/XP Microsoft Management Console (MMC) cannot 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>
+<a class="indexterm" name="id2529555"></a>
+<a class="indexterm" name="id2529562"></a>
+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>
+<a class="indexterm" name="id2529579"></a>
+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 <a href="groupmapping.html" title="Chapter 11. Group Mapping: MS Windows and UNIX">Group Mapping: MS
+Windows and UNIX</a>.
+</p><p>
+<a class="indexterm" name="id2529602"></a>
+<a class="indexterm" name="id2529609"></a>
+<a class="indexterm" name="id2529618"></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 data-store. Refer to <a href="domain-member.html#machine-trust-accounts" title="MS Windows Workstation/Server Machine Trust Accounts">MS
+Windows Workstation/Server Machine Trust Accounts</a>. With Samba-3 there can be multiple backends for
+this. A complete discussion of account database backends can be found in <a href="passdb.html" title="Chapter 10. Account Information Databases">Account
+Information Databases</a>.
+</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2529649"></a>Single Sign-On and Domain Security</h2></div></div></div><p>
+<a class="indexterm" name="id2529658"></a>
+<a class="indexterm" name="id2529666"></a>
+<a class="indexterm" name="id2529673"></a>
+<a class="indexterm" name="id2529680"></a>
+<a class="indexterm" name="id2529687"></a>
+<a class="indexterm" name="id2529694"></a>
+<a class="indexterm" name="id2529700"></a>
+When network administrators are asked to describe the benefits of Windows NT4 and active directory networking
+the most often mentioned feature is that of single sign-on (SSO). Many companies have implemented SSO
+solutions. The mode of implementation of a single sign-on solution is an important factor in the practice of
+networking in general, and is critical in respect of Windows networking. A company may have a wide variety of
+information systems, each of which requires a form of user authentication and validation, thus it is not
+uncommon that users may need to remember more than ten login IDs and passwords. This problem is compounded
+when the password for each system must be changed at regular intervals, and particularly so where password
+uniqueness and history limits are applied.
+</p><p>
+<a class="indexterm" name="id2529724"></a>
+There is a broadly held perception that SSO is the answer to the problem of users having to deal with too many
+information system access credentials (username/password pairs). Many elaborate schemes have been devised to
+make it possible to deliver a user-friendly SSO solution. The trouble is that if this implementation is not
+done correctly, the site may end up paying dearly by way of complexity and management overheads. Simply put,
+many SSO solutions are an administrative nightmare.
+</p><p>
+<a class="indexterm" name="id2529742"></a>
+<a class="indexterm" name="id2529749"></a>
+<a class="indexterm" name="id2529756"></a>
+SSO implementations utilize centralization of all user account information. Depending on environmental
+complexity and the age of the systems over which a SSO solution is implemented, it may not be possible to
+change the solution architecture so as to accomodate a new identity management and user authentication system.
+Many SSO solutions involving legacy systems consist of a new super-structure that handles authentication on
+behalf of the user. The software that gets layered over the old system may simply implement a proxy
+authentication system. This means that the addition of SSO increases over-all information systems complexity.
+Ideally, the implementation of SSO should reduce complexity and reduce administative overheads.
+</p><p>
+<a class="indexterm" name="id2529778"></a>
+<a class="indexterm" name="id2529785"></a>
+<a class="indexterm" name="id2529795"></a>
+<a class="indexterm" name="id2529804"></a>
+<a class="indexterm" name="id2529811"></a>
+The initial goal of many network administrators is often to create and use a centralized identity management
+system. It is often assumed that such a centralized system will use a single authentication infrastructure
+that can be used by all information systems. The Microsoft Windows NT4 security domain architecture and the
+Micrsoft active directory service are often put forward as the ideal foundation for such a system. It is
+conceptually simple to install an external authentication agent on each of the disparate infromation systems
+that can then use the Microsoft (NT4 domain or ads service) for user authentication and access control. The
+wonderful dream of a single centralized authentication service is commonly broken when realities are realized.
+The problem with legacy systems is often the inability to externalize the authentication and access control
+system it uses because its implementation will be excessively invasive from a re-engineering perspective, or
+because application software has built-in dependencies on particular elements of the way user authentication
+and access control were designed and built.
+</p><p>
+<a class="indexterm" name="id2529840"></a>
+<a class="indexterm" name="id2529847"></a>
+<a class="indexterm" name="id2529854"></a>
+<a class="indexterm" name="id2529861"></a>
+<a class="indexterm" name="id2529868"></a>
+<a class="indexterm" name="id2529875"></a>
+<a class="indexterm" name="id2529882"></a>
+<a class="indexterm" name="id2529888"></a>
+Over the past decade an industry has been developed around the various methods that have been built to get
+around the key limitations of legacy information technology systems. One approach that is often used involves
+the use of a meta-directory. The meta-directory stores user credentials for all disparate information systems
+in the format that is particular to each system. An elaborate set of management procedures is coupled with a
+rigidly enforced work-flow protocol for managing user rights and privileges within the maze of systems that
+are provisioned by the new infrastructure makes possible user access to all systems using a single set of user
+credentials.
+</p><p>
+<a class="indexterm" name="id2529910"></a>
+<a class="indexterm" name="id2529920"></a>
+<a class="indexterm" name="id2529930"></a>
+<a class="indexterm" name="id2529939"></a>
+The Organization for the Advancement of Structured Information Standards (OASIS) has developed the Security
+Assertion Markup Language (SAML), a structured method for communication of authentication information. The
+over-all umbrella name for the technologies and methods that deploy SAML is called Federated Identity
+Management (FIM). FIM depends on each system in the complex maze of disparate information systems to
+authenticate their respective users and vouch for secure access to the services each provides.
+</p><p>
+<a class="indexterm" name="id2529958"></a>
+<a class="indexterm" name="id2529967"></a>
+<a class="indexterm" name="id2529974"></a>
+<a class="indexterm" name="id2529981"></a>
+<a class="indexterm" name="id2529988"></a>
+<a class="indexterm" name="id2529994"></a>
+SAML documents can be wrapped in a Simple Object Access Protocol (SOAP) message for the computer-to-computer
+communications needed for Web services. Or they may be passed between Web servers of federated organizations
+that share live services. The Liberty Alliance, an industry group formed to promote federated-identity
+standards, has adopted SAML 1.1 as part of its application framework. Microsoft and IBM have proposed an
+alternative specification called WS-Security. Some believe that the competing technologies and methods may
+converge when the SAML 2.0 standard is introduced. A few Web access-management products support SAML today,
+but implemention of the technology mostly requires customization to integrate applications and develop user
+interfaces. In a nust-shell, that is why FIM is a big and growing industry.
+</p><p>
+<a class="indexterm" name="id2530016"></a>
+<a class="indexterm" name="id2530023"></a>
+<a class="indexterm" name="id2530030"></a>
+<a class="indexterm" name="id2530037"></a>
+<a class="indexterm" name="id2530043"></a>
+Ignoring the bigger picture, which is beyond the scope of this book, the migration of all user and group
+management to a centralized system is a step in the right direction. It is essential for interoperability
+reasons to locate the identity management system data in a directory such as Microsoft Active Directory
+Service (ADS), or any proprietary or open source system that provides a standard protocol for information
+access (such as LDAP) and that can be coupled with a flexible array of authentication mechanisms (such as
+kerberos) that use the protocols that are defined by the various general security service application
+programming interface (GSSAPI) services.
+</p><p>
+<a class="indexterm" name="id2530068"></a>
+<a class="indexterm" name="id2530075"></a>
+<a class="indexterm" name="id2530081"></a>
+A growing number of companies provide authentication agents for disparate legacy platforms to permit the use
+of LDAP systems. Thus the use of OpenLDAP, the dominant open source software implementation of the light
+weight directory access protocol standard. This fact, means that by providing support in Samba for the use of
+LDAP and Microsoft ADS make Samba a highly scalable and forward reaching organizational networking technology.
+</p><p>
+<a class="indexterm" name="id2530099"></a>
+<a class="indexterm" name="id2530106"></a>
+<a class="indexterm" name="id2530112"></a>
+<a class="indexterm" name="id2530119"></a>
+<a class="indexterm" name="id2530126"></a>
+<a class="indexterm" name="id2530133"></a>
+Microsoft ADS provides purely proprietary services that, with limitation, can be extended to provide a
+centralized authentication infrastructure. Samba plus LDAP provides a similar opportunity for extension of a
+centralized authentication architecture, but it is the fact that the Samba Team are pro-active in introducing
+the extension of authentication services, using LDAP or otherwise, to applications such as SQUID (the open
+source proxy server) through tools such as the <span><strong class="command">ntlm_auth</strong></span> utility, that does much to create
+sustainable choice and competition in the FIM market place.
+</p><p>
+<a class="indexterm" name="id2530158"></a>
+<a class="indexterm" name="id2530165"></a>
+<a class="indexterm" name="id2530172"></a>
+Primary domain control, if it is to be scalable to meet the needs of large sites, must therefore be capable of
+using LDAP. The rapid adoption of OpenLDAP, and Samba configurations that use it, is ample proof that the era
+of the directoy has started. Samba-3 does not demand the use of LDAP, but the demand for a mechanism by which
+user and group identity information can be distributed makes it an an unavoidable option.
+</p><p>
+<a class="indexterm" name="id2530189"></a>
+<a class="indexterm" name="id2530196"></a>
+<a class="indexterm" name="id2530203"></a>
+At this time, the use of Samba based BDCs, necessitates the use of LDAP. The most commonly used LDAP
+implementation used by Samba sites is OpenLDAP. It is possible to use any standards compliant LDAP server.
+Those known to work includes those manufactured by: IBM, CA, Novell (e-Directory), and others.
+</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2530217"></a>Basics of Domain Control</h2></div></div></div><p>
+<a class="indexterm" name="id2530225"></a>
+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="id2530237"></a>Domain Controller Types</h3></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>NT4 style Primary Domain Controller</p></li><li><p>NT4 style Backup Domain Controller</p></li><li><p>ADS Domain Controller</p></li></ul></div><p>
+<a class="indexterm" name="id2530262"></a>
+<a class="indexterm" name="id2530269"></a>
+<a class="indexterm" name="id2530276"></a>
+<a class="indexterm" name="id2530285"></a>
+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 standalone
+(domain member) servers than in the domain controllers.
+</p><p>
+<a class="indexterm" name="id2530313"></a>
+<a class="indexterm" name="id2530320"></a>
+<a class="indexterm" name="id2530326"></a>
+<a class="indexterm" name="id2530333"></a>
+<a class="indexterm" name="id2530340"></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 BDCs.
+</p><p>
+<a class="indexterm" name="id2530358"></a>
+<a class="indexterm" name="id2530369"></a>
+<a class="indexterm" name="id2530376"></a>
+<a class="indexterm" name="id2530385"></a>
+With MS Windows 200x Server-based Active Directory domains, one domain controller initiates a potential
+hierarchy of domain controllers, each with its 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>
+<a class="indexterm" name="id2530410"></a>
+<a class="indexterm" name="id2530417"></a>
+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="id2530426" href="#ftn.id2530426">1</a>]</sup>
+</p><p>
+<a class="indexterm" name="id2530443"></a>
+<a class="indexterm" name="id2530449"></a>
+<a class="indexterm" name="id2530455"></a>
+<a class="indexterm" name="id2530462"></a>
+<a class="indexterm" name="id2530469"></a>
+<a class="indexterm" name="id2530476"></a>
+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). When a user logs onto a Windows domain member client the
+workstation will query the network to locate the nearest network logon server. Where a WINS server is used,
+this is done via a query to the WINS server. If a netlogon server can not be found from the WINS query, or in
+the absence of a WINS server, the workstation will perform a NetBIOS name lookup via a mailslot broadcast over
+the UDP broadcast protocol. This means that the netlogon server that the windows client will use is influenced
+by a number of variables, thus there is no simple determinant of whether a PDC or a BDC will serve a
+particular logon authentication request.
+</p><p>
+<a class="indexterm" name="id2530506"></a>
+<a class="indexterm" name="id2530513"></a>
+A Windows NT4 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 other appropriate changes also need to be made.
+</p><p>
+<a class="indexterm" name="id2530528"></a>
+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 method Microsoft provide to convert a
+Windows NT4 domain controller to a domain member server or a standalone 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>Standalone Server</em></span> one that plays no part in SAM synchronization,
+ has its own authentication database, and plays no role in domain security.</p></li></ul></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+<a class="indexterm" name="id2530597"></a>
+Algin Technology LLC provide a commercial tool that makes it possible to promote a Windows NT4 standalone
+server to a PDC or a BDC, and also permits this process to be reversed. Refer to the <a href="http://utools.com/UPromote.asp" target="_top">Algin</a> web site for further information.
+</p></div><p>
+<a class="indexterm" name="id2530617"></a>
+<a class="indexterm" name="id2530629"></a>
+Samba-3 servers can readily be converted to and from domain controller roles through simple changes to the
+<code class="filename">smb.conf</code> file. 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="id2530648"></a>
+For the sake of providing a complete picture, MS Windows 2000 domain control configuration is done after the server has been
+installed. Please refer to Microsoft documentation for the procedures that should be followed to convert a
+domain member server to or from a domain control, and to install or remove active directory service support.
+</p><p>
+<a class="indexterm" name="id2530667"></a>
+<a class="indexterm" name="id2530676"></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>
+<a class="indexterm" name="id2530692"></a>
+At this time any appearance that Samba-3 is capable of acting as a <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 domain controller in a Windows 2000/XP
+environment. However, there are certain compromises:
+</p><div class="itemizedlist"><ul type="disc"><li><p>No machine policy files.</p></li><li><p>No Group Policy Objects.</p></li><li><p>No synchronously executed Active Directory logon scripts.</p></li><li><p>Can't use Active Directory management tools to manage users and machines.</p></li><li><p>Registry changes tattoo the main registry, while with Active Directory they do not leave
+ permanent changes in effect.</p></li><li><p>Without Active Directory you cannot perform the function of exporting specific
+ applications to specific users or groups.</p></li></ul></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2530749"></a>Preparing for Domain Control</h3></div></div></div><p>
+<a class="indexterm" name="id2530757"></a>
+<a class="indexterm" name="id2530764"></a>
+<a class="indexterm" name="id2530770"></a>
+<a class="indexterm" name="id2530777"></a>
+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>standalone</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>
+<a class="indexterm" name="id2530802"></a>
+<a class="indexterm" name="id2530809"></a>
+<a class="indexterm" name="id2530818"></a>
+It should be noted that workgroup 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 configuration, 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>
+<a class="indexterm" name="id2530850"></a>
+<a class="indexterm" name="id2530857"></a>
+<a class="indexterm" name="id2530866"></a>
+Domain member machines have a machine trust 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, creates the domain machine account (if it does
+not exist), and then initializes that account. When the client first logs onto the
+domain, a machine trust account password change will be automatically triggered.
+</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+<a class="indexterm" name="id2530885"></a>
+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
+(standalone) machine. Please refer to <a href="domain-member.html" title="Chapter 6. Domain Membership">Domain Membership</a>, 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="id2530923"></a>security = user).</p></li><li><p>Consistent configuration of name resolution.<sup>[<a name="id2530936" href="#ftn.id2530936">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 NT4/2000 Professional and Windows XP Professional 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="id2531000"></a>security = 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>
+<a class="indexterm" name="id2531055"></a>
+<a class="indexterm" name="id2531062"></a>
+Roaming profiles and system/network policies are advanced network administration topics
+that are covered in <a href="ProfileMgmt.html" title="Chapter 26. Desktop Profile Management">Desktop Profile Management</a> and
+<a href="PolicyMgmt.html" title="Chapter 25. System and Account Policies">System and Account Policies</a> 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>
+ <a class="indexterm" name="id2531098"></a>
+ <a class="indexterm" name="id2531106"></a>
+ <a class="indexterm" name="id2531113"></a>
+ <a class="indexterm" name="id2531120"></a>
+ <a class="indexterm" name="id2531127"></a>
+ 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>
+ <a class="indexterm" name="id2531142"></a>
+ <a class="indexterm" name="id2531149"></a>
+ Provides the NETLOGON service. (This is actually a collection of services that runs over
+ multiple 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>
+<a class="indexterm" name="id2531170"></a>
+<a class="indexterm" name="id2531181"></a>
+<a class="indexterm" name="id2531193"></a>
+<a class="indexterm" name="id2531199"></a>
+<a class="indexterm" name="id2531206"></a>
+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="id2531215"></a>domain logons functionality (after the name of the
+parameter in the <code class="filename">smb.conf</code> file). Additionally, one server in a Samba-3 domain must advertise itself as the
+domain master browser.<sup>[<a name="id2531231" href="#ftn.id2531231">3</a>]</sup> This causes the PDC to claim a domain-specific NetBIOS name that identifies
+it as a DMB for its given domain or workgroup. Local master browsers (LMBs) 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 then contact their LMB, 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="id2531253"></a>Domain Control: Example Configuration</h2></div></div></div><p>
+The first step in creating a working Samba PDC is to understand the parameters necessary
+in <code class="filename">smb.conf</code>. An example <code class="filename">smb.conf</code> for acting as a PDC can be found in <a href="samba-pdc.html#pdc-example" title="Example 4.1. smb.conf for being a PDC">the
+smb.conf file for an example PDC</a>.
+</p><div class="example"><a name="pdc-example"></a><p class="title"><b>Example 4.1. smb.conf for being a PDC</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><em class="parameter"><code>[global]</code></em></td></tr><tr><td><a class="indexterm" name="id2531308"></a><em class="parameter"><code>netbios name</code></em></td></tr><tr><td><a class="indexterm" name="id2531321"></a><em class="parameter"><code>workgroup</code></em></td></tr><tr><td><a class="indexterm" name="id2531334"></a><em class="parameter"><code>passdb backend = tdbsam</code></em></td></tr><tr><td><a class="indexterm" name="id2531347"></a><em class="parameter"><code>os level = 33</code></em></td></tr><tr><td><a class="indexterm" name="id2531359"></a><em class="parameter"><code>preferred master = auto</code></em></td></tr><tr><td><a class="indexterm" name="id2531372"></a><em class="parameter"><code>domain master = yes</code></em></td></tr><tr><td><a class="indexterm" name="id2531385"></a><em class="parameter"><code>local master = yes</code></em></td></tr><tr><td><a class="indexterm" name="id2531398"></a><em class="parameter"><code>security = user</code></em></td></tr><tr><td><a class="indexterm" name="id2531411"></a><em class="parameter"><code>domain logons = yes</code></em></td></tr><tr><td><a class="indexterm" name="id2531423"></a><em class="parameter"><code>logon path = \\%N\profiles\%U</code></em></td></tr><tr><td><a class="indexterm" name="id2531436"></a><em class="parameter"><code>logon drive = H:</code></em></td></tr><tr><td><a class="indexterm" name="id2531449"></a><em class="parameter"><code>logon home = \\homeserver\%U\winprofile</code></em></td></tr><tr><td><a class="indexterm" name="id2531462"></a><em class="parameter"><code>logon script = logon.cmd</code></em></td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[netlogon]</code></em></td></tr><tr><td><a class="indexterm" name="id2531484"></a><em class="parameter"><code>path = /var/lib/samba/netlogon</code></em></td></tr><tr><td><a class="indexterm" name="id2531497"></a><em class="parameter"><code>read only = yes</code></em></td></tr><tr><td><a class="indexterm" name="id2531510"></a><em class="parameter"><code>write list</code></em></td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[profiles]</code></em></td></tr><tr><td><a class="indexterm" name="id2531531"></a><em class="parameter"><code>path = /var/lib/samba/profiles</code></em></td></tr><tr><td><a class="indexterm" name="id2531544"></a><em class="parameter"><code>read only = no</code></em></td></tr><tr><td><a class="indexterm" name="id2531557"></a><em class="parameter"><code>create mask = 0600</code></em></td></tr><tr><td><a class="indexterm" name="id2531569"></a><em class="parameter"><code>directory mask = 0700</code></em></td></tr></table></div><p>
+The basic options shown in <a href="samba-pdc.html#pdc-example" title="Example 4.1. smb.conf for being a PDC">this example</a> are explained as follows:
+</p><div class="variablelist"><dl><dt><span class="term">passdb backend </span></dt><dd><p>
+ <a class="indexterm" name="id2531605"></a>
+ <a class="indexterm" name="id2531614"></a>
+ <a class="indexterm" name="id2531620"></a>
+ <a class="indexterm" name="id2531627"></a>
+ <a class="indexterm" name="id2531634"></a>
+ <a class="indexterm" name="id2531641"></a>
+ 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>
+ <a class="indexterm" name="id2531662"></a>
+ <a class="indexterm" name="id2531669"></a>
+ <a class="indexterm" name="id2531676"></a>
+ <a class="indexterm" name="id2531683"></a>
+ Where use of 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>
+ <a class="indexterm" name="id2531704"></a>
+ <a class="indexterm" name="id2531710"></a>
+ <a class="indexterm" name="id2531717"></a>
+ <a class="indexterm" name="id2531724"></a>
+ The parameters <span class="emphasis"><em>os level, preferred master, domain master, security,
+ encrypt passwords</em></span>, and <span class="emphasis"><em>domain logons</em></span> play a central role in assuring domain
+ control and network logon support.
+ </p><p>
+ <a class="indexterm" name="id2531747"></a>
+ <a class="indexterm" name="id2531753"></a>
+ 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 DMB, 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 <a href="passdb.html" title="Chapter 10. Account Information Databases">Account Information Databases</a>.
+ </p></dd><dt><span class="term">Environment Parameters </span></dt><dd><p>
+ <a class="indexterm" name="id2531791"></a>
+ <a class="indexterm" name="id2531797"></a>
+ <a class="indexterm" name="id2531804"></a>
+ <a class="indexterm" name="id2531811"></a>
+ The parameters <span class="emphasis"><em>logon path, logon home, logon drive</em></span>, and <span class="emphasis"><em>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>
+ <a class="indexterm" name="id2531840"></a>
+ <a class="indexterm" name="id2531847"></a>
+ <a class="indexterm" name="id2531854"></a>
+ <a class="indexterm" name="id2531861"></a>
+ <a class="indexterm" name="id2531868"></a>
+ <a class="indexterm" name="id2531875"></a>
+ 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>
+ <a class="indexterm" name="id2531898"></a>
+ <a class="indexterm" name="id2531905"></a>
+ <a class="indexterm" name="id2531912"></a>
+ <a class="indexterm" name="id2531918"></a>
+ <a class="indexterm" name="id2531925"></a>
+ 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 functionality that may define the server's mode
+of operation. The following <code class="filename">smb.conf</code> parameters are the essentials alone:
+</p><p>
+</p><table class="simplelist" border="0" summary="Simple list"><tr><td><a class="indexterm" name="id2531966"></a><em class="parameter"><code>netbios name = BELERIAND</code></em></td></tr><tr><td><a class="indexterm" name="id2531978"></a><em class="parameter"><code>workgroup = MIDEARTH</code></em></td></tr><tr><td><a class="indexterm" name="id2531991"></a><em class="parameter"><code>domain logons = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id2532004"></a><em class="parameter"><code>domain master = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id2532017"></a><em class="parameter"><code>security = User</code></em></td></tr></table><p>
+</p><p>
+The additional parameters shown in the longer listing in this section just make 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="id2532037"></a>Samba ADS Domain Control</h2></div></div></div><p>
+<a class="indexterm" name="id2532045"></a>
+Samba-3 is not, and cannot act as, an Active Directory server. It cannot truly function as an Active Directory
+PDC. 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
+someday or maybe never!
+</p><p>
+<a class="indexterm" name="id2532066"></a>
+<a class="indexterm" name="id2532073"></a>
+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 controllers 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="id2532090"></a>Domain and Network Logon Configuration</h2></div></div></div><p>
+<a class="indexterm" name="id2532098"></a>
+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="id2532109"></a>Domain Network Logon Service</h3></div></div></div><p>
+<a class="indexterm" name="id2532117"></a>
+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="id2532130"></a>domain master = Yes
+(the PDC); on all BDCs set the parameter <a class="indexterm" name="id2532138"></a>domain master = No.
+</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2532146"></a>Example Configuration</h4></div></div></div><div class="example"><a name="PDC-config"></a><p class="title"><b>Example 4.2. smb.conf for being a PDC</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><em class="parameter"><code>[global]</code></em></td></tr><tr><td><a class="indexterm" name="id2532176"></a><em class="parameter"><code>domain logons = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id2532189"></a><em class="parameter"><code>domain master = (Yes on PDC, No on BDCs)</code></em></td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[netlogon]</code></em></td></tr><tr><td><a class="indexterm" name="id2532211"></a><em class="parameter"><code>comment = Network Logon Service</code></em></td></tr><tr><td><a class="indexterm" name="id2532224"></a><em class="parameter"><code>path = /var/lib/samba/netlogon</code></em></td></tr><tr><td><a class="indexterm" name="id2532237"></a><em class="parameter"><code>guest ok = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id2532250"></a><em class="parameter"><code>browseable = No</code></em></td></tr></table></div></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2532264"></a>The Special Case of MS Windows XP Home Edition</h4></div></div></div><p>
+<a class="indexterm" name="id2532273"></a>
+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="id2532303"></a>The Special Case of Windows 9x/Me</h4></div></div></div><p>
+<a class="indexterm" name="id2532311"></a>
+<a class="indexterm" name="id2532318"></a>
+<a class="indexterm" name="id2532325"></a>
+<a class="indexterm" name="id2532332"></a>
+<a class="indexterm" name="id2532339"></a>
+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>
+<a class="indexterm" name="id2532355"></a>
+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>
+<a class="indexterm" name="id2532371"></a>
+<a class="indexterm" name="id2532378"></a>
+<a class="indexterm" name="id2532385"></a>
+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>
+<a class="indexterm" name="id2532400"></a>
+When an SMB client in a domain wishes to log on, 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;
+that is, 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 log on 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>
+ <a class="indexterm" name="id2532446"></a>
+ <a class="indexterm" name="id2532453"></a>
+ 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
+ <code class="filename">\\SERVER</code>. The <code class="literal">1C</code> name is the name
+ type that is registered by domain controllers (SMB/CIFS servers that provide
+ the netlogon service).
+ </p></li><li><p>
+ <a class="indexterm" name="id2532494"></a>
+ <a class="indexterm" name="id2532501"></a>
+ <a class="indexterm" name="id2532508"></a>
+ 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>
+ <a class="indexterm" name="id2532523"></a>
+ 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>
+ <a class="indexterm" name="id2532549"></a>
+ <a class="indexterm" name="id2532556"></a>
+ 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>
+ <a class="indexterm" name="id2532574"></a>
+ 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 share name and path. For example, <code class="filename">\\server\fred\.winprofile</code>.
+ If the profiles are found, they are implemented.
+ </p></li><li><p>
+ <a class="indexterm" name="id2532598"></a>
+ The client then disconnects from the user's home share and reconnects to
+ the NetLogon share and looks for <code class="filename">CONFIG.POL</code>, 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>
+ <a class="indexterm" name="id2532627"></a>
+ <a class="indexterm" name="id2532636"></a>
+ 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 plaintext
+ password support is disabled. It can be re-enabled with the registry
+ changes that are documented in <a href="PolicyMgmt.html" title="Chapter 25. System and Account Policies">System and Account Policies</a>.
+ </p></li><li><p>
+ <a class="indexterm" name="id2532659"></a>
+ Windows 9x/Me clients do not require and do not use Machine Trust Accounts.
+ </p></li></ul></div><p>
+<a class="indexterm" name="id2532671"></a>
+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>
+<a class="indexterm" name="id2532685"></a>
+Use of plaintext 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="id2532698"></a>Security Mode and Master Browsers</h3></div></div></div><p>
+<a class="indexterm" name="id2532706"></a>
+<a class="indexterm" name="id2532713"></a>
+<a class="indexterm" name="id2532720"></a>
+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 that operates with security mode other than
+user-mode. 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>
+<a class="indexterm" name="id2532737"></a>
+<a class="indexterm" name="id2532744"></a>
+<a class="indexterm" name="id2532751"></a>
+<a class="indexterm" name="id2532757"></a>
+<a class="indexterm" name="id2532764"></a>
+<a class="indexterm" name="id2532771"></a>
+<a class="indexterm" name="id2532778"></a>
+Actually, this issue is also closely tied to the debate on whether Samba must be the DMB for its workgroup
+when operating as a domain controller. In a pure Microsoft Windows NT domain, the PDC wins the election to be
+the DMB, and then registers the DOMAIN<1B> NetBIOS name. This is not the name used by Windows clients
+to locate the domain controller, all domain controllers register the DOMAIN<1C> name and Windows clients
+locate a network logon server by seraching for the DOMAIN<1C> name. A DMB is a Domain Master Browser
+ see <a href="NetworkBrowsing.html" title="Chapter 9. Network Browsing">The Network Browsing Chapter</a>, <a href="NetworkBrowsing.html#DMB" title="Configuring Workgroup Browsing">Configuring WORKGROUP Browsing</a>; Microsoft PDCs expect to win the election to become the
+DMB, if it loses that election it will report a continuous and rapid sequence of warning messages to its
+Windows event logger complaining that it has lost the election to become a DMB. For this reason, in networks
+where a Samba server is the PDC it is wise to configure the Samba domain controller as the DMB.
+</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+<a class="indexterm" name="id2532831"></a>
+<a class="indexterm" name="id2532838"></a>
+<a class="indexterm" name="id2532845"></a>
+<a class="indexterm" name="id2532852"></a>
+<a class="indexterm" name="id2532859"></a>
+SMB/CIFS servers that register the DOMAIN<1C> name do so because they provide the network logon
+service. Server that register the DOMAIN<1B> name are DMBs meaning that they are responsible
+for browse list synchronization across all machines that have registered the DOMAIN<1D> name. The later
+are LMBs that have the responsibility to listen to all NetBIOS name registrations that occur locally to their
+own network segment. The network logon service (NETLOGON) is germane to domain control and has nothing to do
+with network browsing and browse list management. The 1C and 1B/1D name services are orthogonal to each
+other.
+</p></div><p>
+Now back to the issue of configuring a Samba domain controller to use a mode other than <a class="indexterm" name="id2532904"></a>security = user. If a Samba host is configured to use another SMB server or domain
+controller in order to validate user connection requests, it is a fact that some other machine on the network
+(the <a class="indexterm" name="id2532914"></a>password server) knows more about the user than the Samba host. About 99 percent
+of the time, this other host is a domain controller. Now to operate in domain mode security, the
+<a class="indexterm" name="id2532924"></a>workgroup 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 domain controller for a domain that already by definition has a
+PDC is asking for trouble. Therefore, you should always configure the Samba domain controller
+to be the DMB for its domain and set <a class="indexterm" name="id2532941"></a>security = 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="id2532953"></a>Common Errors</h2></div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2532958"></a>“<span class="quote">$</span>” Cannot Be Included in Machine Name</h3></div></div></div><p>
+<a class="indexterm" name="id2532969"></a>
+<a class="indexterm" name="id2532975"></a>
+<a class="indexterm" name="id2532982"></a>
+A machine account, typically stored in <code class="filename">/etc/passwd</code>, takes the form of the machine
+name with a “<span class="quote">$</span>” appended. Some BSD systems will not create a user with a “<span class="quote">$</span>” in the name.
+Recent versions of FreeBSD have removed this limitation, but older releases are still in common use.
+</p><p>
+<a class="indexterm" name="id2533009"></a>
+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 <span><strong class="command">vipw</strong></span> 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><p>The machine account must have the exact name that the workstation has.</p></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+The UNIX tool <span><strong class="command">vipw</strong></span> is a common tool for directly editing the <code class="filename">/etc/passwd</code> file.
+The use of vipw will ensure that shadow files (where used) will remain current with the passwd file. This is
+important for security reasons.
+</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2533060"></a>Joining Domain Fails Because of Existing Machine Account</h3></div></div></div><p>
+<a class="indexterm" name="id2533068"></a>
+“<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">
+<code class="prompt">C:\> </code><strong class="userinput"><code>net use * /d</code></strong>
+</pre><p>
+This will break all network connections.
+</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="id2533124"></a>The System Cannot Log You On (C000019B)</h3></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="id2533145"></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">
+<code class="prompt">root# </code><strong class="userinput"><code>net getlocalsid 'OLDNAME'</code></strong>
+<code class="prompt">root# </code><strong class="userinput"><code>net setlocalsid 'SID'</code></strong>
+</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 rejoin
+it to the domain.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2533201"></a>The Machine Trust Account Is Not Accessible</h3></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="id2533224"></a>add machine script 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 <code class="filename">smbpasswd</code> 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 the POSIX UNIX system account backend as well as in the
+SambaSAMAccount backend. The default backend for Samba-3 (i.e., the parameter <em class="parameter"><code>passdb
+backend</code></em> is not specified in the <code class="filename">smb.conf</code> file, or if specified is set to
+<code class="literal">smbpasswd</code>, are respectively the <code class="filename">/etc/passwd</code> and
+<code class="filename">/etc/samba/smbpasswd</code> (or <code class="filename">/usr/local/samba/lib/private/smbpasswd</code> if
+compiled using Samba Team default settings). The use of the <code class="filename">/etc/passwd</code> can be overridden
+by alternative settings in the NSS <code class="filename">/etc/nsswitch.conf</code> 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="id2533316"></a>Account Disabled</h3></div></div></div><p>“<span class="quote">When I attempt to log in 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 <strong class="userinput"><code>smbpasswd -e <em class="replaceable"><code>username</code></em>
+</code></strong>. 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="id2533343"></a>Domain Controller Unavailable</h3></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 15 minutes,
+then try again.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2533362"></a>Cannot Log onto Domain Member Workstation After Joining Domain</h3></div></div></div><p>
+<a class="indexterm" name="id2533370"></a>
+<a class="indexterm" name="id2533377"></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</em></span>, <span class="emphasis"><em>server schannel</em></span>,
+<span class="emphasis"><em>client signing</em></span>, <span class="emphasis"><em>server signing</em></span> by executing:
+</p><pre class="screen">
+<span><strong class="command">testparm -v | grep channel</strong></span> and looking for the value of these parameters.
+</pre><p>
+</p><p>
+Also use the MMC Local Security Settings. This tool is available from the
+Control Panel. The Policy settings are found in the Local Policies/Security 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"><p><sup>[<a name="ftn.id2530426" href="#id2530426">1</a>] </sup>See also <a href="passdb.html" title="Chapter 10. Account Information Databases">Account Information
+Databases</a>.</p>.</div><div class="footnote"><p><sup>[<a name="ftn.id2530936" href="#id2530936">2</a>] </sup>See <a href="NetworkBrowsing.html" title="Chapter 9. Network Browsing">Network Browsing</a>, and
+ <a href="integrate-ms-networks.html" title="Chapter 28. Integrating MS Windows Networks with Samba">Integrating MS Windows Networks with Samba</a>.</p></div><div class="footnote"><p><sup>[<a name="ftn.id2531231" href="#id2531231">3</a>] </sup>See <a href="NetworkBrowsing.html" title="Chapter 9. Network Browsing">Network
+Browsing</a>.</p></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 3. 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 5. Backup Domain Control</td></tr></table></div></body></html>
projects / samba / blobdiff