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, 0 insertions, 890 deletions
diff --git a/docs/htmldocs/Samba3-HOWTO/samba-pdc.html b/docs/htmldocs/Samba3-HOWTO/samba-pdc.html deleted file mode 100644 index b325e490f9..0000000000 --- a/docs/htmldocs/Samba3-HOWTO/samba-pdc.html +++ /dev/null @@ -1,890 +0,0 @@ -<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.75.2"><link rel="home" href="index.html" title="The Official Samba 3.5.x 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" title="Chapter 4. Domain Control"><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 class="email" 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 class="email" 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 class="email" 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">Samba Team<br></span><div class="address"><p><code class="email"><<a class="email" href="mailto:gd@samba.org">gd@samba.org</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#id332816">Features and Benefits</a></span></dt><dt><span class="sect1"><a href="samba-pdc.html#id333361">Single Sign-On and Domain Security</a></span></dt><dt><span class="sect1"><a href="samba-pdc.html#id333870">Basics of Domain Control</a></span></dt><dd><dl><dt><span class="sect2"><a href="samba-pdc.html#id333888">Domain Controller Types</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id334343">Preparing for Domain Control</a></span></dt></dl></dd><dt><span class="sect1"><a href="samba-pdc.html#id334811">Domain Control: Example Configuration</a></span></dt><dt><span class="sect1"><a href="samba-pdc.html#id335523">Samba ADS Domain Control</a></span></dt><dt><span class="sect1"><a href="samba-pdc.html#id335566">Domain and Network Logon Configuration</a></span></dt><dd><dl><dt><span class="sect2"><a href="samba-pdc.html#id335583">Domain Network Logon Service</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id336119">Security Mode and Master Browsers</a></span></dt></dl></dd><dt><span class="sect1"><a href="samba-pdc.html#id336354">Common Errors</a></span></dt><dd><dl><dt><span class="sect2"><a href="samba-pdc.html#id336359"><span class="quote">“<span class="quote">$</span>”</span> Cannot Be Included in Machine Name</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id336454">Joining Domain Fails Because of Existing Machine Account</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id336513">The System Cannot Log You On (C000019B)</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id336578">The Machine Trust Account Is Not Accessible</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id336685">Account Disabled</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id336710">Domain Controller Unavailable</a></span></dt><dt><span class="sect2"><a href="samba-pdc.html#id336727">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="id332704"></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 class="link" 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 class="itemizedlist" type="disc"><li class="listitem"><p>Basic TCP/IP configuration.</p></li><li class="listitem"><p>NetBIOS name resolution.</p></li><li class="listitem"><p>Authentication configuration.</p></li><li class="listitem"><p>User and group configuration.</p></li><li class="listitem"><p>Basic file and directory permission control in UNIX/Linux.</p></li><li class="listitem"><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" title="Features and Benefits"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id332816"></a>Features and Benefits</h2></div></div></div><p> -<a class="indexterm" name="id332824"></a> -<span class="emphasis"><em>What is the key benefit of Microsoft Domain Security?</em></span> -</p><p> -<a class="indexterm" name="id332836"></a> -<a class="indexterm" name="id332845"></a> -<a class="indexterm" name="id332851"></a> -<a class="indexterm" name="id332857"></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="id332879"></a> -<a class="indexterm" name="id332885"></a> -<a class="indexterm" name="id332891"></a> -<a class="indexterm" name="id332900"></a> -<a class="indexterm" name="id332908"></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="id332922"></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="id332934"></a> -<a class="indexterm" name="id332940"></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" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> -<a class="indexterm" name="id332976"></a> -<a class="indexterm" name="id332984"></a> -<a class="indexterm" name="id332990"></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 class="link" 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 class="itemizedlist" type="disc"><li class="listitem"><p> - <a class="indexterm" name="id333017"></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="id333031"></a> - <a class="indexterm" name="id333037"></a> - <a class="indexterm" name="id333043"></a> - <a class="indexterm" name="id333050"></a> - <a class="indexterm" name="id333056"></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 class="listitem"><p> - <a class="indexterm" name="id333068"></a> - <a class="indexterm" name="id333079"></a> - <a class="indexterm" name="id333087"></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 class="listitem"><p> - <a class="indexterm" name="id333100"></a> - <a class="indexterm" name="id333106"></a> - <a class="indexterm" name="id333112"></a> - <a class="indexterm" name="id333119"></a> - <a class="indexterm" name="id333127"></a> - <a class="indexterm" name="id333135"></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 class="listitem"><p> - <a class="indexterm" name="id333151"></a> - <a class="indexterm" name="id333157"></a> - <a class="indexterm" name="id333163"></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 class="listitem"><p> - <a class="indexterm" name="id333176"></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 class="listitem"><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 class="itemizedlist" type="disc"><li class="listitem"><p> - <a class="indexterm" name="id333207"></a> - <a class="indexterm" name="id333214"></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 class="listitem"><p> - <a class="indexterm" name="id333227"></a> - <a class="indexterm" name="id333233"></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 class="listitem"><p> - <a class="indexterm" name="id333249"></a> - <a class="indexterm" name="id333255"></a> - <a class="indexterm" name="id333262"></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="id333278"></a> -<a class="indexterm" name="id333284"></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="id333298"></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 class="link" 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="id333319"></a> -<a class="indexterm" name="id333326"></a> -<a class="indexterm" name="id333335"></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 class="link" 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 class="link" href="passdb.html" title="Chapter 11. Account Information Databases">Account -Information Databases</a>. -</p></div><div class="sect1" title="Single Sign-On and Domain Security"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id333361"></a>Single Sign-On and Domain Security</h2></div></div></div><p> -<a class="indexterm" name="id333369"></a> -<a class="indexterm" name="id333378"></a> -<a class="indexterm" name="id333384"></a> -<a class="indexterm" name="id333391"></a> -<a class="indexterm" name="id333398"></a> -<a class="indexterm" name="id333405"></a> -<a class="indexterm" name="id333411"></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="id333428"></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="id333442"></a> -<a class="indexterm" name="id333449"></a> -<a class="indexterm" name="id333456"></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 accommodate 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="id333472"></a> -<a class="indexterm" name="id333479"></a> -<a class="indexterm" name="id333488"></a> -<a class="indexterm" name="id333497"></a> -<a class="indexterm" name="id333504"></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="id333524"></a> -<a class="indexterm" name="id333531"></a> -<a class="indexterm" name="id333537"></a> -<a class="indexterm" name="id333544"></a> -<a class="indexterm" name="id333551"></a> -<a class="indexterm" name="id333558"></a> -<a class="indexterm" name="id333565"></a> -<a class="indexterm" name="id333572"></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="id333587"></a> -<a class="indexterm" name="id333597"></a> -<a class="indexterm" name="id333606"></a> -<a class="indexterm" name="id333615"></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="id333630"></a> -<a class="indexterm" name="id333639"></a> -<a class="indexterm" name="id333646"></a> -<a class="indexterm" name="id333653"></a> -<a class="indexterm" name="id333659"></a> -<a class="indexterm" name="id333665"></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 implementation of the technology mostly requires customization to integrate applications and develop user -interfaces. In a nutshell, that is why FIM is a big and growing industry. -</p><p> -<a class="indexterm" name="id333687"></a> -<a class="indexterm" name="id333694"></a> -<a class="indexterm" name="id333701"></a> -<a class="indexterm" name="id333708"></a> -<a class="indexterm" name="id333714"></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="id333733"></a> -<a class="indexterm" name="id333740"></a> -<a class="indexterm" name="id333746"></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="id333760"></a> -<a class="indexterm" name="id333766"></a> -<a class="indexterm" name="id333773"></a> -<a class="indexterm" name="id333780"></a> -<a class="indexterm" name="id333787"></a> -<a class="indexterm" name="id333794"></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="id333814"></a> -<a class="indexterm" name="id333821"></a> -<a class="indexterm" name="id333828"></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 directory 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="id333845"></a> -<a class="indexterm" name="id333852"></a> -<a class="indexterm" name="id333858"></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" title="Basics of Domain Control"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id333870"></a>Basics of Domain Control</h2></div></div></div><p> -<a class="indexterm" name="id333878"></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" title="Domain Controller Types"><div class="titlepage"><div><div><h3 class="title"><a name="id333888"></a>Domain Controller Types</h3></div></div></div><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>NT4 style Primary Domain Controller</p></li><li class="listitem"><p>NT4 style Backup Domain Controller</p></li><li class="listitem"><p>ADS Domain Controller</p></li></ul></div><p> -<a class="indexterm" name="id333913"></a> -<a class="indexterm" name="id333919"></a> -<a class="indexterm" name="id333926"></a> -<a class="indexterm" name="id333935"></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="id333958"></a> -<a class="indexterm" name="id333965"></a> -<a class="indexterm" name="id333972"></a> -<a class="indexterm" name="id333978"></a> -<a class="indexterm" name="id333985"></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="id334000"></a> -<a class="indexterm" name="id334012"></a> -<a class="indexterm" name="id334019"></a> -<a class="indexterm" name="id334028"></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="id334042"></a> -<a class="indexterm" name="id334048"></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="id334056" href="#ftn.id334056" class="footnote">1</a>]</sup> -</p><p> -<a class="indexterm" name="id334071"></a> -<a class="indexterm" name="id334078"></a> -<a class="indexterm" name="id334084"></a> -<a class="indexterm" name="id334091"></a> -<a class="indexterm" name="id334098"></a> -<a class="indexterm" name="id334104"></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="id334126"></a> -<a class="indexterm" name="id334133"></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="id334146"></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 class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>Primary Domain Controller</em></span> the one that seeds the domain SAM.</p></li><li class="listitem"><p><span class="emphasis"><em>Backup Domain Controller</em></span> one that obtains a copy of the domain SAM.</p></li><li class="listitem"><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 class="listitem"><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" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> -<a class="indexterm" name="id334209"></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 class="ulink" href="http://utools.com/UPromote.asp" target="_top">Algin</a> web site for further information. -</p></div><p> -<a class="indexterm" name="id334226"></a> -<a class="indexterm" name="id334238"></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="id334255"></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="id334271"></a> -<a class="indexterm" name="id334280"></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="id334294"></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 class="itemizedlist" type="disc"><li class="listitem"><p>No machine policy files.</p></li><li class="listitem"><p>No Group Policy Objects.</p></li><li class="listitem"><p>No synchronously executed Active Directory logon scripts.</p></li><li class="listitem"><p>Can't use Active Directory management tools to manage users and machines.</p></li><li class="listitem"><p>Registry changes tattoo the main registry, while with Active Directory they do not leave - permanent changes in effect.</p></li><li class="listitem"><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" title="Preparing for Domain Control"><div class="titlepage"><div><div><h3 class="title"><a name="id334343"></a>Preparing for Domain Control</h3></div></div></div><p> -<a class="indexterm" name="id334351"></a> -<a class="indexterm" name="id334358"></a> -<a class="indexterm" name="id334365"></a> -<a class="indexterm" name="id334372"></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="id334395"></a> -<a class="indexterm" name="id334402"></a> -<a class="indexterm" name="id334411"></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="id334429"></a> -<a class="indexterm" name="id334436"></a> -<a class="indexterm" name="id334445"></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" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> -<a class="indexterm" name="id334460"></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 class="link" 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 class="itemizedlist" type="disc"><li class="listitem"><p>Configuration of basic TCP/IP and MS Windows networking.</p></li><li class="listitem"><p>Correct designation of the server role (<a class="link" href="smb.conf.5.html#SECURITY" target="_top">security = user</a>).</p></li><li class="listitem"><p>Consistent configuration of name resolution.<sup>[<a name="id334510" href="#ftn.id334510" class="footnote">2</a>]</sup></p></li><li class="listitem"><p>Domain logons for Windows NT4/200x/XP Professional clients.</p></li><li class="listitem"><p>Configuration of roaming profiles or explicit configuration to force local profile usage.</p></li><li class="listitem"><p>Configuration of network/system policies.</p></li><li class="listitem"><p>Adding and managing domain user accounts.</p></li><li class="listitem"><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 class="itemizedlist" type="disc"><li class="listitem"><p>Configuration of basic TCP/IP and MS Windows networking.</p></li><li class="listitem"><p>Correct designation of the server role (<a class="link" href="smb.conf.5.html#SECURITY" target="_top">security = user</a>).</p></li><li class="listitem"><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 class="listitem"><p>Roaming profile configuration.</p></li><li class="listitem"><p>Configuration of system policy handling.</p></li><li class="listitem"><p>Installation of the network driver <span class="quote">“<span class="quote">Client for MS Windows Networks</span>”</span> and configuration - to log onto the domain.</p></li><li class="listitem"><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 class="listitem"><p>Adding and managing domain user accounts.</p></li></ul></div><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> -<a class="indexterm" name="id334622"></a> -<a class="indexterm" name="id334628"></a> -Roaming profiles and system/network policies are advanced network administration topics -that are covered in <a class="link" href="ProfileMgmt.html" title="Chapter 27. Desktop Profile Management">Desktop Profile Management</a> and -<a class="link" 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 class="itemizedlist" type="disc"><li class="listitem"><p> - <a class="indexterm" name="id334662"></a> - <a class="indexterm" name="id334671"></a> - <a class="indexterm" name="id334677"></a> - <a class="indexterm" name="id334684"></a> - <a class="indexterm" name="id334691"></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 class="listitem"><p> - <a class="indexterm" name="id334704"></a> - <a class="indexterm" name="id334711"></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 class="listitem"><p> - Provides a share called NETLOGON. - </p></li></ul></div><p> -<a class="indexterm" name="id334729"></a> -<a class="indexterm" name="id334741"></a> -<a class="indexterm" name="id334752"></a> -<a class="indexterm" name="id334759"></a> -<a class="indexterm" name="id334766"></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="link" href="smb.conf.5.html#DOMAINLOGONS" target="_top">domain logons</a> 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="id334793" href="#ftn.id334793" class="footnote">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" title="Domain Control: Example Configuration"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id334811"></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 class="link" 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 border="0" summary="Simple list" class="simplelist"><tr><td> </td></tr><tr><td><em class="parameter"><code>[global]</code></em></td></tr><tr><td><a class="indexterm" name="id334864"></a></td></tr><tr><td><a class="indexterm" name="id334871"></a></td></tr><tr><td><a class="indexterm" name="id334878"></a><em class="parameter"><code>passdb backend = tdbsam</code></em></td></tr><tr><td><a class="indexterm" name="id334889"></a><em class="parameter"><code>os level = 33</code></em></td></tr><tr><td><a class="indexterm" name="id334900"></a><em class="parameter"><code>preferred master = auto</code></em></td></tr><tr><td><a class="indexterm" name="id334912"></a><em class="parameter"><code>domain master = yes</code></em></td></tr><tr><td><a class="indexterm" name="id334923"></a><em class="parameter"><code>local master = yes</code></em></td></tr><tr><td><a class="indexterm" name="id334935"></a><em class="parameter"><code>security = user</code></em></td></tr><tr><td><a class="indexterm" name="id334946"></a><em class="parameter"><code>domain logons = yes</code></em></td></tr><tr><td><a class="indexterm" name="id334958"></a><em class="parameter"><code>logon path = \\%N\profiles\%U</code></em></td></tr><tr><td><a class="indexterm" name="id334969"></a><em class="parameter"><code>logon drive = H:</code></em></td></tr><tr><td><a class="indexterm" name="id334981"></a><em class="parameter"><code>logon home = \\homeserver\%U\winprofile</code></em></td></tr><tr><td><a class="indexterm" name="id334992"></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="id335013"></a><em class="parameter"><code>path = /var/lib/samba/netlogon</code></em></td></tr><tr><td><a class="indexterm" name="id335025"></a><em class="parameter"><code>read only = yes</code></em></td></tr><tr><td><a class="indexterm" name="id335036"></a></td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[profiles]</code></em></td></tr><tr><td><a class="indexterm" name="id335052"></a><em class="parameter"><code>path = /var/lib/samba/profiles</code></em></td></tr><tr><td><a class="indexterm" name="id335063"></a><em class="parameter"><code>read only = no</code></em></td></tr><tr><td><a class="indexterm" name="id335075"></a><em class="parameter"><code>create mask = 0600</code></em></td></tr><tr><td><a class="indexterm" name="id335086"></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 class="link" 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="id335119"></a> - <a class="indexterm" name="id335129"></a> - <a class="indexterm" name="id335135"></a> - <a class="indexterm" name="id335142"></a> - <a class="indexterm" name="id335149"></a> - <a class="indexterm" name="id335156"></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">“<span class="quote">guest</span>”</span> entry provides - default accounts and is included by default; there is no need to add it explicitly. - </p><p> - <a class="indexterm" name="id335175"></a> - <a class="indexterm" name="id335182"></a> - <a class="indexterm" name="id335189"></a> - <a class="indexterm" name="id335196"></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="id335214"></a> - <a class="indexterm" name="id335221"></a> - <a class="indexterm" name="id335228"></a> - <a class="indexterm" name="id335235"></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="id335256"></a> - <a class="indexterm" name="id335262"></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 class="link" 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="id335296"></a> - <a class="indexterm" name="id335303"></a> - <a class="indexterm" name="id335310"></a> - <a class="indexterm" name="id335317"></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="id335343"></a> - <a class="indexterm" name="id335350"></a> - <a class="indexterm" name="id335357"></a> - <a class="indexterm" name="id335364"></a> - <a class="indexterm" name="id335370"></a> - <a class="indexterm" name="id335377"></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="id335397"></a> - <a class="indexterm" name="id335404"></a> - <a class="indexterm" name="id335410"></a> - <a class="indexterm" name="id335417"></a> - <a class="indexterm" name="id335424"></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">“<span class="quote">fake_permissions</span>”</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" title="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 border="0" summary="Simple list" class="simplelist"><tr><td><a class="indexterm" name="id335459"></a><em class="parameter"><code>netbios name = BELERIAND</code></em></td></tr><tr><td><a class="indexterm" name="id335471"></a><em class="parameter"><code>workgroup = MIDEARTH</code></em></td></tr><tr><td><a class="indexterm" name="id335482"></a><em class="parameter"><code>domain logons = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id335494"></a><em class="parameter"><code>domain master = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id335505"></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" title="Samba ADS Domain Control"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id335523"></a>Samba ADS Domain Control</h2></div></div></div><p> -<a class="indexterm" name="id335531"></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="id335547"></a> -<a class="indexterm" name="id335554"></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" title="Domain and Network Logon Configuration"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id335566"></a>Domain and Network Logon Configuration</h2></div></div></div><p> -<a class="indexterm" name="id335574"></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" title="Domain Network Logon Service"><div class="titlepage"><div><div><h3 class="title"><a name="id335583"></a>Domain Network Logon Service</h3></div></div></div><p> -<a class="indexterm" name="id335591"></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="link" href="smb.conf.5.html#DOMAINMASTER" target="_top">domain master = Yes</a> -(the PDC); on all BDCs set the parameter <a class="link" href="smb.conf.5.html#DOMAINMASTER" target="_top">domain master = No</a>. -</p><div class="sect3" title="Example Configuration"><div class="titlepage"><div><div><h4 class="title"><a name="id335627"></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 border="0" summary="Simple list" class="simplelist"><tr><td> </td></tr><tr><td><em class="parameter"><code>[global]</code></em></td></tr><tr><td><a class="indexterm" name="id335656"></a><em class="parameter"><code>domain logons = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id335667"></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="id335688"></a><em class="parameter"><code>comment = Network Logon Service</code></em></td></tr><tr><td><a class="indexterm" name="id335700"></a><em class="parameter"><code>path = /var/lib/samba/netlogon</code></em></td></tr><tr><td><a class="indexterm" name="id335711"></a><em class="parameter"><code>guest ok = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id335723"></a><em class="parameter"><code>browseable = No</code></em></td></tr></table></div></div><br class="example-break"></div><div class="sect3" title="The Special Case of MS Windows XP Home Edition"><div class="titlepage"><div><div><h4 class="title"><a name="id335736"></a>The Special Case of MS Windows XP Home Edition</h4></div></div></div><p> -<a class="indexterm" name="id335744"></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" title="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" title="The Special Case of Windows 9x/Me"><div class="titlepage"><div><div><h4 class="title"><a name="id335768"></a>The Special Case of Windows 9x/Me</h4></div></div></div><p> -<a class="indexterm" name="id335775"></a> -<a class="indexterm" name="id335782"></a> -<a class="indexterm" name="id335789"></a> -<a class="indexterm" name="id335796"></a> -<a class="indexterm" name="id335803"></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="id335816"></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="id335829"></a> -<a class="indexterm" name="id335836"></a> -<a class="indexterm" name="id335843"></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="id335855"></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 class="orderedlist" type="1"><li class="listitem"><p> - <a class="indexterm" name="id335893"></a> - <a class="indexterm" name="id335900"></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 class="listitem"><p> - <a class="indexterm" name="id335933"></a> - <a class="indexterm" name="id335940"></a> - <a class="indexterm" name="id335946"></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 class="listitem"><p> - <a class="indexterm" name="id335961"></a> - The client does a NetWkstaUserLogon request, which retrieves the name - of the user's logon script. - </p></li><li class="listitem"><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 class="listitem"><p> - <a class="indexterm" name="id335983"></a> - <a class="indexterm" name="id335990"></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 class="listitem"><p> - <a class="indexterm" name="id336006"></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 class="listitem"><p> - <a class="indexterm" name="id336027"></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 class="itemizedlist" type="disc"><li class="listitem"><p> - <a class="indexterm" name="id336054"></a> - <a class="indexterm" name="id336063"></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 class="link" href="PolicyMgmt.html" title="Chapter 26. System and Account Policies">System and Account Policies</a>. - </p></li><li class="listitem"><p> - <a class="indexterm" name="id336084"></a> - Windows 9x/Me clients do not require and do not use Machine Trust Accounts. - </p></li></ul></div><p> -<a class="indexterm" name="id336095"></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" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> -<a class="indexterm" name="id336108"></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" title="Security Mode and Master Browsers"><div class="titlepage"><div><div><h3 class="title"><a name="id336119"></a>Security Mode and Master Browsers</h3></div></div></div><p> -<a class="indexterm" name="id336127"></a> -<a class="indexterm" name="id336134"></a> -<a class="indexterm" name="id336140"></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="id336157"></a> -<a class="indexterm" name="id336164"></a> -<a class="indexterm" name="id336171"></a> -<a class="indexterm" name="id336177"></a> -<a class="indexterm" name="id336184"></a> -<a class="indexterm" name="id336191"></a> -<a class="indexterm" name="id336198"></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 class="link" href="NetworkBrowsing.html" title="Chapter 10. Network Browsing">The Network Browsing Chapter</a>, <a class="link" 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" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> -<a class="indexterm" name="id336238"></a> -<a class="indexterm" name="id336245"></a> -<a class="indexterm" name="id336251"></a> -<a class="indexterm" name="id336258"></a> -<a class="indexterm" name="id336265"></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="link" href="smb.conf.5.html#SECURITY" target="_top">security = user</a>. 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="link" href="smb.conf.5.html#PASSWORDSERVER" target="_top">password server</a>) 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="link" href="smb.conf.5.html#WORKGROUP" target="_top">workgroup</a> 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="link" href="smb.conf.5.html#SECURITY" target="_top">security = user</a>. -This is the only officially supported mode of operation. -</p></div></div><div class="sect1" title="Common Errors"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id336354"></a>Common Errors</h2></div></div></div><div class="sect2" title="“$” Cannot Be Included in Machine Name"><div class="titlepage"><div><div><h3 class="title"><a name="id336359"></a><span class="quote">“<span class="quote">$</span>”</span> Cannot Be Included in Machine Name</h3></div></div></div><p> -<a class="indexterm" name="id336369"></a> -<a class="indexterm" name="id336376"></a> -<a class="indexterm" name="id336383"></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 class="quote">$</span>”</span> appended. Some BSD systems will not create a user with a <span class="quote">“<span class="quote">$</span>”</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="id336408"></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 class="quote">$</span>”</span>. Then use <code class="literal">vipw</code> to edit the entry, adding the <span class="quote">“<span class="quote">$</span>”</span>. -Or create the whole entry with vipw if you like; make sure you use a unique user login ID. -</p><div class="note" title="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" title="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" title="Joining Domain Fails Because of Existing Machine Account"><div class="titlepage"><div><div><h3 class="title"><a name="id336454"></a>Joining Domain Fails Because of Existing Machine Account</h3></div></div></div><p> -<a class="indexterm" name="id336462"></a> -<span class="quote">“<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>”</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">“<span class="quote">member of a workgroup</span>”</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" title="The System Cannot Log You On (C000019B)"><div class="titlepage"><div><div><h3 class="title"><a name="id336513"></a>The System Cannot Log You On (C000019B)</h3></div></div></div><p><span class="quote">“<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>”</span> -</p><p> -<a class="indexterm" name="id336530"></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" title="The Machine Trust Account Is Not Accessible"><div class="titlepage"><div><div><h3 class="title"><a name="id336578"></a>The Machine Trust Account Is Not Accessible</h3></div></div></div><p> -<span class="quote">“<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>”</span> -</p><p> -This problem is caused by the PDC not having a suitable Machine Trust Account. If you are using the -<a class="link" href="smb.conf.5.html#ADDMACHINESCRIPT" target="_top">add machine script</a> 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 class="quote">$</span>”</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" title="Account Disabled"><div class="titlepage"><div><div><h3 class="title"><a name="id336685"></a>Account Disabled</h3></div></div></div><p><span class="quote">“<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>”</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" title="Domain Controller Unavailable"><div class="titlepage"><div><div><h3 class="title"><a name="id336710"></a>Domain Controller Unavailable</h3></div></div></div><p><span class="quote">“<span class="quote">Until a few minutes after Samba has started, clients get the error `Domain Controller Unavailable'</span>”</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" title="Cannot Log onto Domain Member Workstation After Joining Domain"><div class="titlepage"><div><div><h3 class="title"><a name="id336727"></a>Cannot Log onto Domain Member Workstation After Joining Domain</h3></div></div></div><p> -<a class="indexterm" name="id336735"></a> -<a class="indexterm" name="id336742"></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.id334056" href="#id334056" class="para">1</a>] </sup>See also <a class="link" href="passdb.html" title="Chapter 11. Account Information Databases">Account Information -Databases</a>.</p></div><div class="footnote"><p><sup>[<a name="ftn.id334510" href="#id334510" class="para">2</a>] </sup>See <a class="link" href="NetworkBrowsing.html" title="Chapter 10. Network Browsing">Network Browsing</a>, and - <a class="link" 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.id334793" href="#id334793" class="para">3</a>] </sup>See <a class="link" 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> |