diff options
Diffstat (limited to 'docs/htmldocs/Samba3-HOWTO/samba-pdc.html')
| -rw-r--r-- | docs/htmldocs/Samba3-HOWTO/samba-pdc.html | 890 |
1 files changed, 890 insertions, 0 deletions
diff --git a/docs/htmldocs/Samba3-HOWTO/samba-pdc.html b/docs/htmldocs/Samba3-HOWTO/samba-pdc.html new file mode 100644 index 0000000000..4e3244dc77 --- /dev/null +++ b/docs/htmldocs/Samba3-HOWTO/samba-pdc.html @@ -0,0 +1,890 @@ +<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.71.0"><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#id327668">Features and Benefits</a></span></dt><dt><span class="sect1"><a href="samba-pdc.html#id328244">Single Sign-On and Domain Security</a></span></dt><dt><span class="sect1"><a href="samba-pdc.html#id328748">Basics of Domain Control</a></span></dt><dd><dl><dt><span class="sect2"><a href="samba-pdc.html#id328766">Domain Controller Types</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id329223">Preparing for Domain Control</a></span></dt></dl></dd><dt><span class="sect1"><a href="samba-pdc.html#id329677">Domain Control: Example Configuration</a></span></dt><dt><span class="sect1"><a href="samba-pdc.html#id330430">Samba ADS Domain Control</a></span></dt><dt><span class="sect1"><a href="samba-pdc.html#id330473">Domain and Network Logon Configuration</a></span></dt><dd><dl><dt><span class="sect2"><a href="samba-pdc.html#id330490">Domain Network Logon Service</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id331027">Security Mode and Master Browsers</a></span></dt></dl></dd><dt><span class="sect1"><a href="samba-pdc.html#id331242">Common Errors</a></span></dt><dd><dl><dt><span class="sect2"><a href="samba-pdc.html#id331248">“<span class="quote">$</span>” Cannot Be Included in Machine Name</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id331343">Joining Domain Fails Because of Existing Machine Account</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id331401">The System Cannot Log You On (C000019B)</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id331468">The Machine Trust Account Is Not Accessible</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id331569">Account Disabled</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id331595">Domain Controller Unavailable</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id331611">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="id327547"></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="figure-contents"><div class="mediaobject"><img src="images/domain.png" width="216" alt="An Example Domain."></div></div></div><br class="figure-break"><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="id327668"></a>Features and Benefits</h2></div></div></div><p> +<a class="indexterm" name="id327676"></a> +<span class="emphasis"><em>What is the key benefit of Microsoft Domain Security?</em></span> +</p><p> +<a class="indexterm" name="id327690"></a> +<a class="indexterm" name="id327698"></a> +<a class="indexterm" name="id327705"></a> +<a class="indexterm" name="id327712"></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="id327735"></a> +<a class="indexterm" name="id327742"></a> +<a class="indexterm" name="id327748"></a> +<a class="indexterm" name="id327757"></a> +<a class="indexterm" name="id327766"></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="id327780"></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="id327793"></a> +<a class="indexterm" name="id327799"></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="id327837"></a> +<a class="indexterm" name="id327846"></a> +<a class="indexterm" name="id327853"></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="id327882"></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="id327897"></a> + <a class="indexterm" name="id327904"></a> + <a class="indexterm" name="id327910"></a> + <a class="indexterm" name="id327917"></a> + <a class="indexterm" name="id327924"></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="id327937"></a> + <a class="indexterm" name="id327949"></a> + <a class="indexterm" name="id327958"></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="id327971"></a> + <a class="indexterm" name="id327978"></a> + <a class="indexterm" name="id327984"></a> + <a class="indexterm" name="id327991"></a> + <a class="indexterm" name="id328000"></a> + <a class="indexterm" name="id328010"></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="id328026"></a> + <a class="indexterm" name="id328032"></a> + <a class="indexterm" name="id328039"></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="id328052"></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="id328085"></a> + <a class="indexterm" name="id328092"></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="id328105"></a> + <a class="indexterm" name="id328112"></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="id328131"></a> + <a class="indexterm" name="id328138"></a> + <a class="indexterm" name="id328144"></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="id328160"></a> +<a class="indexterm" name="id328167"></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="id328180"></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 12. Group Mapping: MS Windows and UNIX">Group Mapping: MS +Windows and UNIX</a>. +</p><p> +<a class="indexterm" name="id328202"></a> +<a class="indexterm" name="id328208"></a> +<a class="indexterm" name="id328217"></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 11. 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="id328244"></a>Single Sign-On and Domain Security</h2></div></div></div><p> +<a class="indexterm" name="id328252"></a> +<a class="indexterm" name="id328260"></a> +<a class="indexterm" name="id328267"></a> +<a class="indexterm" name="id328274"></a> +<a class="indexterm" name="id328280"></a> +<a class="indexterm" name="id328287"></a> +<a class="indexterm" name="id328294"></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="id328311"></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="id328325"></a> +<a class="indexterm" name="id328332"></a> +<a class="indexterm" name="id328339"></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="id328355"></a> +<a class="indexterm" name="id328362"></a> +<a class="indexterm" name="id328371"></a> +<a class="indexterm" name="id328380"></a> +<a class="indexterm" name="id328387"></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="id328406"></a> +<a class="indexterm" name="id328413"></a> +<a class="indexterm" name="id328420"></a> +<a class="indexterm" name="id328427"></a> +<a class="indexterm" name="id328434"></a> +<a class="indexterm" name="id328441"></a> +<a class="indexterm" name="id328447"></a> +<a class="indexterm" name="id328454"></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="id328476"></a> +<a class="indexterm" name="id328485"></a> +<a class="indexterm" name="id328494"></a> +<a class="indexterm" name="id328504"></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="id328518"></a> +<a class="indexterm" name="id328527"></a> +<a class="indexterm" name="id328534"></a> +<a class="indexterm" name="id328541"></a> +<a class="indexterm" name="id328548"></a> +<a class="indexterm" name="id328553"></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="id328569"></a> +<a class="indexterm" name="id328576"></a> +<a class="indexterm" name="id328582"></a> +<a class="indexterm" name="id328589"></a> +<a class="indexterm" name="id328596"></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="id328614"></a> +<a class="indexterm" name="id328621"></a> +<a class="indexterm" name="id328628"></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="id328641"></a> +<a class="indexterm" name="id328648"></a> +<a class="indexterm" name="id328655"></a> +<a class="indexterm" name="id328662"></a> +<a class="indexterm" name="id328668"></a> +<a class="indexterm" name="id328675"></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 <code class="literal">ntlm_auth</code> utility, that does much to create +sustainable choice and competition in the FIM market place. +</p><p> +<a class="indexterm" name="id328696"></a> +<a class="indexterm" name="id328703"></a> +<a class="indexterm" name="id328709"></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="id328723"></a> +<a class="indexterm" name="id328730"></a> +<a class="indexterm" name="id328736"></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="id328748"></a>Basics of Domain Control</h2></div></div></div><p> +<a class="indexterm" name="id328756"></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="id328766"></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="id328790"></a> +<a class="indexterm" name="id328797"></a> +<a class="indexterm" name="id328804"></a> +<a class="indexterm" name="id328813"></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="id328836"></a> +<a class="indexterm" name="id328843"></a> +<a class="indexterm" name="id328849"></a> +<a class="indexterm" name="id328856"></a> +<a class="indexterm" name="id328863"></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="id328878"></a> +<a class="indexterm" name="id328890"></a> +<a class="indexterm" name="id328896"></a> +<a class="indexterm" name="id328906"></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="id328919"></a> +<a class="indexterm" name="id328926"></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="id328934" href="#ftn.id328934">1</a>]</sup> +</p><p> +<a class="indexterm" name="id328950"></a> +<a class="indexterm" name="id328956"></a> +<a class="indexterm" name="id328963"></a> +<a class="indexterm" name="id328970"></a> +<a class="indexterm" name="id328977"></a> +<a class="indexterm" name="id328983"></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="id329005"></a> +<a class="indexterm" name="id329012"></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="id329025"></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="id329088"></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="id329105"></a> +<a class="indexterm" name="id329117"></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="id329135"></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="id329150"></a> +<a class="indexterm" name="id329159"></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="id329173"></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="id329223"></a>Preparing for Domain Control</h3></div></div></div><p> +<a class="indexterm" name="id329231"></a> +<a class="indexterm" name="id329237"></a> +<a class="indexterm" name="id329244"></a> +<a class="indexterm" name="id329251"></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="id329274"></a> +<a class="indexterm" name="id329281"></a> +<a class="indexterm" name="id329290"></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="id329308"></a> +<a class="indexterm" name="id329315"></a> +<a class="indexterm" name="id329324"></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="id329339"></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="id329372"></a>security = user).</p></li><li><p>Consistent configuration of name resolution.<sup>[<a name="id329384" href="#ftn.id329384">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="id329444"></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="id329494"></a> +<a class="indexterm" name="id329500"></a> +Roaming profiles and system/network policies are advanced network administration topics +that are covered in <a href="ProfileMgmt.html" title="Chapter 27. Desktop Profile Management">Desktop Profile Management</a> and +<a href="PolicyMgmt.html" title="Chapter 26. 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="id329534"></a> + <a class="indexterm" name="id329542"></a> + <a class="indexterm" name="id329549"></a> + <a class="indexterm" name="id329556"></a> + <a class="indexterm" name="id329563"></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="id329576"></a> + <a class="indexterm" name="id329583"></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="id329600"></a> +<a class="indexterm" name="id329612"></a> +<a class="indexterm" name="id329624"></a> +<a class="indexterm" name="id329630"></a> +<a class="indexterm" name="id329637"></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="id329645"></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="id329659" href="#ftn.id329659">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="id329677"></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><div class="example-contents"><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="id329730"></a><em class="parameter"><code>netbios name</code></em></td></tr><tr><td><a class="indexterm" name="id329743"></a><em class="parameter"><code>workgroup</code></em></td></tr><tr><td><a class="indexterm" name="id329755"></a><em class="parameter"><code>passdb backend = tdbsam</code></em></td></tr><tr><td><a class="indexterm" name="id329768"></a><em class="parameter"><code>os level = 33</code></em></td></tr><tr><td><a class="indexterm" name="id329780"></a><em class="parameter"><code>preferred master = auto</code></em></td></tr><tr><td><a class="indexterm" name="id329793"></a><em class="parameter"><code>domain master = yes</code></em></td></tr><tr><td><a class="indexterm" name="id329805"></a><em class="parameter"><code>local master = yes</code></em></td></tr><tr><td><a class="indexterm" name="id329818"></a><em class="parameter"><code>security = user</code></em></td></tr><tr><td><a class="indexterm" name="id329830"></a><em class="parameter"><code>domain logons = yes</code></em></td></tr><tr><td><a class="indexterm" name="id329843"></a><em class="parameter"><code>logon path = \\%N\profiles\%U</code></em></td></tr><tr><td><a class="indexterm" name="id329856"></a><em class="parameter"><code>logon drive = H:</code></em></td></tr><tr><td><a class="indexterm" name="id329868"></a><em class="parameter"><code>logon home = \\homeserver\%U\winprofile</code></em></td></tr><tr><td><a class="indexterm" name="id329881"></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="id329902"></a><em class="parameter"><code>path = /var/lib/samba/netlogon</code></em></td></tr><tr><td><a class="indexterm" name="id329915"></a><em class="parameter"><code>read only = yes</code></em></td></tr><tr><td><a class="indexterm" name="id329928"></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="id329949"></a><em class="parameter"><code>path = /var/lib/samba/profiles</code></em></td></tr><tr><td><a class="indexterm" name="id329962"></a><em class="parameter"><code>read only = no</code></em></td></tr><tr><td><a class="indexterm" name="id329974"></a><em class="parameter"><code>create mask = 0600</code></em></td></tr><tr><td><a class="indexterm" name="id329987"></a><em class="parameter"><code>directory mask = 0700</code></em></td></tr></table></div></div><br class="example-break"><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="id330021"></a> + <a class="indexterm" name="id330030"></a> + <a class="indexterm" name="id330037"></a> + <a class="indexterm" name="id330044"></a> + <a class="indexterm" name="id330051"></a> + <a class="indexterm" name="id330057"></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="id330077"></a> + <a class="indexterm" name="id330084"></a> + <a class="indexterm" name="id330090"></a> + <a class="indexterm" name="id330097"></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="id330116"></a> + <a class="indexterm" name="id330123"></a> + <a class="indexterm" name="id330130"></a> + <a class="indexterm" name="id330136"></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="id330158"></a> + <a class="indexterm" name="id330164"></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 11. Account Information Databases">Account Information Databases</a>. + </p></dd><dt><span class="term">Environment Parameters </span></dt><dd><p> + <a class="indexterm" name="id330198"></a> + <a class="indexterm" name="id330205"></a> + <a class="indexterm" name="id330212"></a> + <a class="indexterm" name="id330218"></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="id330245"></a> + <a class="indexterm" name="id330252"></a> + <a class="indexterm" name="id330258"></a> + <a class="indexterm" name="id330265"></a> + <a class="indexterm" name="id330272"></a> + <a class="indexterm" name="id330279"></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="id330299"></a> + <a class="indexterm" name="id330305"></a> + <a class="indexterm" name="id330312"></a> + <a class="indexterm" name="id330319"></a> + <a class="indexterm" name="id330326"></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="id330361"></a><em class="parameter"><code>netbios name = BELERIAND</code></em></td></tr><tr><td><a class="indexterm" name="id330374"></a><em class="parameter"><code>workgroup = MIDEARTH</code></em></td></tr><tr><td><a class="indexterm" name="id330386"></a><em class="parameter"><code>domain logons = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id330399"></a><em class="parameter"><code>domain master = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id330411"></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="id330430"></a>Samba ADS Domain Control</h2></div></div></div><p> +<a class="indexterm" name="id330438"></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="id330454"></a> +<a class="indexterm" name="id330460"></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="id330473"></a>Domain and Network Logon Configuration</h2></div></div></div><p> +<a class="indexterm" name="id330481"></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="id330490"></a>Domain Network Logon Service</h3></div></div></div><p> +<a class="indexterm" name="id330498"></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="id330510"></a>domain master = Yes +(the PDC); on all BDCs set the parameter <a class="indexterm" name="id330517"></a>domain master = No. +</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id330525"></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><div class="example-contents"><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="id330554"></a><em class="parameter"><code>domain logons = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id330567"></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="id330588"></a><em class="parameter"><code>comment = Network Logon Service</code></em></td></tr><tr><td><a class="indexterm" name="id330601"></a><em class="parameter"><code>path = /var/lib/samba/netlogon</code></em></td></tr><tr><td><a class="indexterm" name="id330614"></a><em class="parameter"><code>guest ok = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id330626"></a><em class="parameter"><code>browseable = No</code></em></td></tr></table></div></div><br class="example-break"></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id330641"></a>The Special Case of MS Windows XP Home Edition</h4></div></div></div><p> +<a class="indexterm" name="id330649"></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="id330672"></a>The Special Case of Windows 9x/Me</h4></div></div></div><p> +<a class="indexterm" name="id330680"></a> +<a class="indexterm" name="id330687"></a> +<a class="indexterm" name="id330694"></a> +<a class="indexterm" name="id330700"></a> +<a class="indexterm" name="id330707"></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="id330721"></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="id330737"></a> +<a class="indexterm" name="id330744"></a> +<a class="indexterm" name="id330750"></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="id330763"></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="id330801"></a> + <a class="indexterm" name="id330807"></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="id330841"></a> + <a class="indexterm" name="id330847"></a> + <a class="indexterm" name="id330854"></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="id330869"></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="id330891"></a> + <a class="indexterm" name="id330898"></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="id330914"></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="id330935"></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="id330962"></a> + <a class="indexterm" name="id330971"></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 26. System and Account Policies">System and Account Policies</a>. + </p></li><li><p> + <a class="indexterm" name="id330992"></a> + Windows 9x/Me clients do not require and do not use Machine Trust Accounts. + </p></li></ul></div><p> +<a class="indexterm" name="id331003"></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="id331016"></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="id331027"></a>Security Mode and Master Browsers</h3></div></div></div><p> +<a class="indexterm" name="id331035"></a> +<a class="indexterm" name="id331042"></a> +<a class="indexterm" name="id331048"></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="id331062"></a> +<a class="indexterm" name="id331069"></a> +<a class="indexterm" name="id331076"></a> +<a class="indexterm" name="id331082"></a> +<a class="indexterm" name="id331089"></a> +<a class="indexterm" name="id331095"></a> +<a class="indexterm" name="id331102"></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 10. 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="id331143"></a> +<a class="indexterm" name="id331149"></a> +<a class="indexterm" name="id331156"></a> +<a class="indexterm" name="id331163"></a> +<a class="indexterm" name="id331170"></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="id331201"></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="id331209"></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="id331218"></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="id331231"></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="id331242"></a>Common Errors</h2></div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id331248"></a>“<span class="quote">$</span>” Cannot Be Included in Machine Name</h3></div></div></div><p> +<a class="indexterm" name="id331258"></a> +<a class="indexterm" name="id331264"></a> +<a class="indexterm" name="id331271"></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="id331296"></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 <code class="literal">vipw</code> 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 <code class="literal">vipw</code> 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="id331343"></a>Joining Domain Fails Because of Existing Machine Account</h3></div></div></div><p> +<a class="indexterm" name="id331351"></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="id331401"></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="id331419"></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="id331468"></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="id331488"></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="id331569"></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="id331595"></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="id331611"></a>Cannot Log onto Domain Member Workstation After Joining Domain</h3></div></div></div><p> +<a class="indexterm" name="id331619"></a> +<a class="indexterm" name="id331626"></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"> +<code class="literal">testparm -v | grep channel</code> 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.id328934" href="#id328934">1</a>] </sup>See also <a href="passdb.html" title="Chapter 11. Account Information Databases">Account Information +Databases</a>.</p>.</div><div class="footnote"><p><sup>[<a name="ftn.id329384" href="#id329384">2</a>] </sup>See <a href="NetworkBrowsing.html" title="Chapter 10. Network Browsing">Network Browsing</a>, and + <a href="integrate-ms-networks.html" title="Chapter 29. Integrating MS Windows Networks with Samba">Integrating MS Windows Networks with Samba</a>.</p></div><div class="footnote"><p><sup>[<a name="ftn.id329659" href="#id329659">3</a>] </sup>See <a href="NetworkBrowsing.html" title="Chapter 10. 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> |