Moving docs tree to docs-xml to make room for generated docs in the release tarball.

(This used to be commit 9f672c26d63955f613088489c6efbdc08b5b2d14)

1 files changed, 1409 insertions, 0 deletions

diff --git a/docs-xml/Samba3-HOWTO/TOSHARG-PDC.xml b/docs-xml/Samba3-HOWTO/TOSHARG-PDC.xml
new file mode 100644
index 0000000000..d37edbe17f
--- /dev/null
+++ b/docs-xml/Samba3-HOWTO/TOSHARG-PDC.xml
@@ -0,0 +1,1409 @@
+<?xml version="1.0" encoding="iso-8859-1"?>
+<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
+<chapter id="samba-pdc">
+
+<chapterinfo>
+	&author.jht;
+	&author.jerry;
+	&author.dbannon;
+	<author>&person.gd; <contrib>LDAP updates</contrib></author>
+</chapterinfo>
+
+<title>Domain Control</title>
+
+<para>
+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.
+</para>
+
+<para>
+<indexterm><primary>domain</primary><secondary>controller</secondary></indexterm>
+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.
+</para>
+
+<para>
+<link linkend="domain-example">The Example Domain Illustration</link> shows a typical MS Windows domain security
+network environment. Workstations A, B, and C are representative of many physical MS Windows
+network clients.
+</para>
+
+<figure id="domain-example">
+	<title>An Example Domain.</title>
+	<imagefile scale="40">domain</imagefile>
+</figure>
+
+<para>
+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:
+</para>
+
+<itemizedlist>
+	<listitem><para>Basic TCP/IP configuration.</para></listitem>
+	<listitem><para>NetBIOS name resolution.</para></listitem>
+	<listitem><para>Authentication configuration.</para></listitem>
+	<listitem><para>User and group configuration.</para></listitem>
+	<listitem><para>Basic file and directory permission control in UNIX/Linux.</para></listitem>
+	<listitem><para>Understanding how MS Windows clients interoperate in a network environment.</para></listitem>
+</itemizedlist>
+
+<para>
+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: <emphasis>It is perfectly okay to make mistakes!</emphasis> 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.
+</para>
+
+<para>
+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.
+</para>
+
+<sect1>
+<title>Features and Benefits</title>
+
+<para>
+<indexterm><primary>domain security</primary></indexterm>
+<emphasis>What is the key benefit of Microsoft Domain Security?</emphasis>
+</para>
+
+<para>
+<indexterm>single sign-on<primary></primary><see>SSO</see></indexterm>
+<indexterm><primary>trust</primary></indexterm>
+<indexterm><primary>account</primary></indexterm>
+<indexterm><primary>domain</primary><secondary>security</secondary><tertiary>protocols</tertiary></indexterm>
+In a word, <emphasis>single sign-on</emphasis>, 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.
+</para>
+
+<para>
+<indexterm><primary>SID</primary></indexterm>
+<indexterm><primary>RID</primary></indexterm>
+<indexterm><primary>relative identifier</primary><see>RID</see></indexterm>
+<indexterm><primary>security identifier</primary><see>SID</see></indexterm>
+<indexterm><primary>access control</primary></indexterm>
+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.
+</para>
+
+<para>
+<indexterm><primary>SID</primary></indexterm>
+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.
+</para>
+
+<para>
+<indexterm><primary>SID</primary></indexterm>
+<indexterm><primary>RID</primary></indexterm>
+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:
+<screen>
+S-1-5-21-726309263-4128913605-1168186429
+</screen>
+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 <literal>root</literal> 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
+<screen>
+S-1-5-21-726309263-4128913605-1168186429-500
+</screen>
+The result is that every account in the Windows networking world has a globally unique security identifier.
+</para>
+
+<note><para>
+<indexterm><primary>domain</primary><secondary>member</secondary></indexterm>
+<indexterm><primary>machine account</primary></indexterm>
+<indexterm><primary>domain</primary><secondary>trust account</secondary></indexterm>
+Network clients of an MS Windows domain security environment must be domain members to be able to gain access
+to the advanced features provided. Domain membership involves more than just setting the workgroup name to the
+domain name. It requires the creation of a domain trust account for the workstation (called a machine
+account). Refer to <link linkend="domain-member">Domain Membership</link> for more information.
+</para></note>
+
+<para>
+The following functionalities are new to the Samba-3 release:
+</para>
+
+<itemizedlist>
+	<listitem><para>
+	<indexterm><primary>account</primary><secondary>backend</secondary></indexterm>
+	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.
+	</para>
+
+	<para>
+	<indexterm><primary>LDAP</primary></indexterm>
+	<indexterm><primary>replicated</primary></indexterm>
+	<indexterm><primary>distributed</primary></indexterm>
+	<indexterm><primary>scalability</primary></indexterm>
+	<indexterm><primary>reliability</primary></indexterm>
+	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. 
+	</para></listitem>
+
+	<listitem><para>
+	<indexterm><primary>interdomain</primary><secondary>trust</secondary><tertiary>account</tertiary></indexterm>
+	<indexterm><primary>trust account</primary><secondary>interdomain</secondary></indexterm>
+	<indexterm><primary>interoperability</primary></indexterm>
+	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.
+	</para></listitem>
+	
+	<listitem><para>
+	<indexterm><primary>NetBIOS</primary></indexterm>
+	<indexterm><primary>raw SMB</primary></indexterm>
+	<indexterm><primary>active directory</primary></indexterm>
+	<indexterm><primary>domain</primary><secondary>member server</secondary></indexterm>
+	<indexterm><primary>domain</primary><secondary>controller</secondary></indexterm>
+	<indexterm><primary>network</primary><secondary>browsing</secondary></indexterm>
+	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.
+	</para></listitem>
+
+	<listitem><para>
+	<indexterm><primary>WINS</primary></indexterm>
+	<indexterm><primary>TCP port</primary></indexterm>
+	<indexterm><primary>session services</primary></indexterm>
+	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.
+	</para></listitem>
+
+	<listitem><para>
+	<indexterm><primary>Nexus.exe</primary></indexterm>
+	Management of users and groups via the User Manager for Domains. This can be done on any MS Windows client
+	using the <filename>Nexus.exe</filename> 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.
+	</para></listitem>
+
+	<listitem><para>
+	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.
+	</para></listitem>
+</itemizedlist>
+
+<para>
+The following functionalities are not provided by Samba-3:
+</para>
+
+<itemizedlist>
+	<listitem><para>
+	<indexterm><primary>SAM</primary></indexterm>
+	<indexterm><primary>replication</primary></indexterm>
+	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.
+	</para></listitem>
+	
+	<listitem><para>
+	<indexterm><primary>kerberos</primary></indexterm>
+	<indexterm><primary>active directory</primary></indexterm>
+	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.
+	</para></listitem>
+
+	<listitem><para>
+	<indexterm><primary>MMC</primary></indexterm>
+	<indexterm><primary>SVRTOOLS.EXE</primary></indexterm>
+	<indexterm><primary>Microsoft management console</primary><see>MMC</see></indexterm>
+	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.
+	</para></listitem>
+</itemizedlist>
+
+<para>
+<indexterm><primary>Windows XP Home edition</primary></indexterm>
+<indexterm><primary>LanMan</primary></indexterm>
+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.
+</para>
+
+<para>
+<indexterm><primary>group</primary><secondary>mapping</secondary></indexterm>
+Samba-3 implements group mapping between Windows NT groups and UNIX groups (this is really quite complicated
+to explain in a short space). This is discussed more fully in <link linkend="groupmapping">Group Mapping: MS
+Windows and UNIX</link>.
+</para>
+
+<para>
+<indexterm><primary>machine trust account</primary></indexterm>
+<indexterm><primary>trust account</primary><secondary>machine</secondary></indexterm>
+<indexterm><primary>machine account</primary></indexterm>
+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 <link linkend="machine-trust-accounts">MS
+Windows Workstation/Server Machine Trust Accounts</link>. With Samba-3 there can be multiple backends for
+this. A complete discussion of account database backends can be found in <link linkend="passdb">Account
+Information Databases</link>.
+</para>
+
+</sect1>
+
+<sect1>
+<title>Single Sign-On and Domain Security</title>
+
+<para>
+<indexterm><primary>single sign-on</primary><see>SSO</see></indexterm>
+<indexterm><primary>SSO</primary></indexterm>
+<indexterm><primary>active directory</primary></indexterm>
+<indexterm><primary>authentication</primary></indexterm>
+<indexterm><primary>validation</primary></indexterm>
+<indexterm><primary>password uniqueness</primary></indexterm>
+<indexterm><primary>password history</primary></indexterm>
+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.
+</para>
+
+<para>
+<indexterm><primary>management overheads</primary></indexterm>
+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.
+</para>
+
+<para>
+<indexterm><primary>identity management</primary></indexterm>
+<indexterm><primary>authentication system</primary></indexterm>
+<indexterm><primary>SSO</primary></indexterm>
+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.
+</para>
+
+<para>
+<indexterm><primary>centralized identity management</primary></indexterm>
+<indexterm><primary>identity management</primary><secondary>centralized</secondary></indexterm>
+<indexterm><primary>centralized</primary><secondary>authentication</secondary></indexterm>
+<indexterm><primary>legacy systems</primary></indexterm>
+<indexterm><primary>access control</primary></indexterm>
+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.
+</para>
+
+<para>
+<indexterm><primary>meta-directory</primary></indexterm>
+<indexterm><primary>credentials</primary></indexterm>
+<indexterm><primary>disparate information systems</primary></indexterm>
+<indexterm><primary>management procedures</primary></indexterm>
+<indexterm><primary>work-flow protocol</primary></indexterm>
+<indexterm><primary>rights</primary></indexterm>
+<indexterm><primary>privileges</primary></indexterm>
+<indexterm><primary>provisioned</primary></indexterm>
+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.
+</para>
+
+<para>
+<indexterm><primary>Organization for the Advancement of Structured Information Standards</primary><see>OASIS</see></indexterm>
+<indexterm><primary>Security Assertion Markup Language</primary><see>SAML</see></indexterm>
+<indexterm><primary>Federated Identity Management</primary><see>FIM</see></indexterm>
+<indexterm><primary>secure access</primary></indexterm>
+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.
+</para>
+
+<para>
+<indexterm><primary>Simple Object Access Protocol</primary><see>SOAP</see></indexterm>
+<indexterm><primary>federated organizations</primary></indexterm>
+<indexterm><primary>Liberty Alliance</primary></indexterm>
+<indexterm><primary>federated-identity</primary></indexterm>
+<indexterm><primary></primary></indexterm>
+<indexterm><primary></primary></indexterm>
+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.
+</para>
+
+<para>
+<indexterm><primary>interoperability</primary></indexterm>
+<indexterm><primary>ADS</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>GSSAPI</primary></indexterm>
+<indexterm><primary>general security service application programming interface</primary><see>GSSAPI</see></indexterm>
+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.
+</para>
+
+<para>
+<indexterm><primary>OpenLDAP</primary></indexterm>
+<indexterm><primary>ADS</primary></indexterm>
+<indexterm><primary>authentication agents</primary></indexterm>
+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.
+</para>
+
+<para>
+<indexterm><primary>ADS</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>authentication architecture</primary></indexterm>
+<indexterm><primary>ntlm_auth</primary></indexterm>
+<indexterm><primary>SQUID</primary></indexterm>
+<indexterm><primary>FIM</primary></indexterm>
+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 <command>ntlm_auth</command> utility, that does much to create
+sustainable choice and competition in the FIM market place.
+</para>
+
+<para>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>OpenLDAP</primary></indexterm>
+<indexterm><primary>identity information</primary></indexterm>
+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.
+</para>
+
+<para>
+<indexterm><primary>BDC</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>e-Directory</primary></indexterm>
+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.
+</para>
+
+</sect1>
+
+<sect1>
+<title>Basics of Domain Control</title>
+
+<para>
+<indexterm><primary>domain control</primary></indexterm>
+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.
+</para>
+
+<sect2>
+<title>Domain Controller Types</title>
+
+<itemizedlist>
+	<listitem><para>NT4 style Primary Domain Controller</para></listitem>
+	<listitem><para>NT4 style Backup Domain Controller</para></listitem>
+	<listitem><para>ADS Domain Controller</para></listitem>
+</itemizedlist>
+
+<para>
+<indexterm><primary>PDC</primary></indexterm>
+<indexterm><primary>powerful</primary></indexterm>
+<indexterm><primary>network</primary><secondary>performance</secondary></indexterm>
+<indexterm><primary>domain</primary><secondary>member</secondary><secondary>server</secondary></indexterm>
+The <emphasis>Primary Domain Controller</emphasis> 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.
+</para>
+
+<para>
+<indexterm><primary>SAM</primary></indexterm>
+<indexterm><primary>BDC</primary></indexterm>
+<indexterm><primary>authenticatior</primary></indexterm>
+<indexterm><primary>synchronization</primary></indexterm>
+<indexterm><primary>Security Account Manager</primary><see>SAM</see></indexterm>
+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. 
+</para>
+
+<para>
+<indexterm><primary>domain</primary><secondary>controller</secondary><tertiary>hierarchy</tertiary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm>account<primary></primary><secondary>backend</secondary></indexterm>
+<indexterm><primary>machine account</primary></indexterm>
+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.
+</para>
+
+<para>
+<indexterm><primary>backend database</primary></indexterm>
+<indexterm><primary>registry</primary></indexterm>
+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)<footnote><para>See also <link linkend="passdb">Account Information
+Databases</link>.</para>.</footnote>
+</para>
+
+<para>
+<indexterm><primary>BDC</primary></indexterm>
+<indexterm><primary>PDC</primary></indexterm>
+<indexterm><primary>WINS</primary></indexterm>
+<indexterm><primary>authentication</primary></indexterm>
+<indexterm><primary>netlogon</primary></indexterm>
+<indexterm><primary>name lookup</primary></indexterm>
+The <emphasis>Backup Domain Controller</emphasis> 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.
+</para>
+
+<para>
+<indexterm><primary>promote</primary></indexterm>
+<indexterm><primary>demote</primary></indexterm>
+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.
+</para>
+
+<para>
+<indexterm><primary>domain</primary><secondary>controller</secondary><tertiary>convert</tertiary></indexterm>
+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:
+</para>
+
+<itemizedlist>
+	<listitem><para><emphasis>Primary Domain Controller</emphasis> &smbmdash; the one that seeds the domain SAM.</para></listitem>
+	<listitem><para><emphasis>Backup Domain Controller</emphasis> &smbmdash; one that obtains a copy of the domain SAM.</para></listitem>
+	<listitem><para><emphasis>Domain Member Server</emphasis> &smbmdash; one that has no copy of the domain SAM; rather
+		it obtains authentication from a domain controller for all access controls.</para></listitem>
+	<listitem><para><emphasis>Standalone Server</emphasis> &smbmdash; one that plays no part in SAM synchronization,
+		has its own authentication database, and plays no role in domain security.</para></listitem>
+</itemizedlist>
+
+<note><para>
+<indexterm><primary>promote</primary></indexterm>
+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 <ulink
+url="http://utools.com/UPromote.asp">Algin</ulink> web site for further information.
+</para></note>
+
+<para>
+<indexterm><primary>domain</primary><secondary>control</secondary><tertiary>role</tertiary></indexterm>
+<indexterm><primary>native member</primary></indexterm>
+Samba-3 servers can readily be converted to and from domain controller roles through simple changes to the
+&smb.conf; file. Samba-3 is capable of acting fully as a native member of a Windows 200x server Active
+Directory domain.
+</para>
+
+<para>
+<indexterm><primary>convert</primary><secondary>domain member server</secondary></indexterm>
+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.
+</para>
+
+<para>
+<indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
+<indexterm><primary>SAM</primary><secondary>replication</secondary></indexterm>
+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.
+</para>
+
+<para>
+<indexterm><primary>ADS</primary></indexterm>
+At this time any appearance that Samba-3 is capable of acting as a <emphasis>domain controller</emphasis> 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:
+</para>
+
+<itemizedlist>
+	<listitem><para>No machine policy files.</para></listitem>
+	<listitem><para>No Group Policy Objects.</para></listitem>
+	<listitem><para>No synchronously executed Active Directory logon scripts.</para></listitem>
+	<listitem><para>Can't use Active Directory management tools to manage users and machines.</para></listitem>
+	<listitem><para>Registry changes tattoo the main registry, while with Active Directory they do not leave
+		permanent changes in effect.</para></listitem>
+	<listitem><para>Without Active Directory you cannot perform the function of exporting specific
+		applications to specific users or groups.</para></listitem>
+</itemizedlist>
+
+</sect2>
+
+<sect2>
+<title>Preparing for Domain Control</title>
+
+<para>
+<indexterm><primary>standalone</primary></indexterm>
+<indexterm><primary>workgroup</primary></indexterm>
+<indexterm><primary>member</primary></indexterm>
+<indexterm><primary>security</primary></indexterm>
+There are two ways that MS Windows machines may interact with each other, with other servers,
+and with domain controllers: either as <emphasis>standalone</emphasis> systems, more commonly
+called <emphasis>workgroup</emphasis> members, or as full participants in a security system,
+more commonly called <emphasis>domain</emphasis> members.
+</para>
+
+<para>
+<indexterm><primary>workgroup</primary></indexterm>
+<indexterm><primary>workgroup</primary><secondary>membership</secondary></indexterm>
+<indexterm><primary>machine trust account</primary></indexterm>
+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: <emphasis>workgroup mode does not
+involve security machine accounts</emphasis>.
+</para>
+
+<para>
+<indexterm><primary>domain membership</primary></indexterm>
+<indexterm><primary>machine trust account</primary><secondary>password</secondary></indexterm>
+<indexterm><primary>trigger</primary></indexterm>
+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.
+</para>
+
+<note><para>
+<indexterm><primary>domain member</primary></indexterm>
+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 <link linkend="domain-member">Domain Membership</link>, for
+information regarding domain membership.
+</para></note>
+
+<para>
+The following are necessary for configuring Samba-3 as an MS Windows NT4-style PDC for MS Windows
+NT4/200x/XP clients:
+</para>
+
+<itemizedlist>
+	<listitem><para>Configuration of basic TCP/IP and MS Windows networking.</para></listitem>
+	<listitem><para>Correct designation of the server role (<smbconfoption name="security">user</smbconfoption>).</para></listitem>
+	<listitem><para>Consistent configuration of name resolution.<footnote><para>See <link linkend="NetworkBrowsing">Network Browsing</link>, and 
+		<link linkend="integrate-ms-networks">Integrating MS Windows Networks with Samba</link>.</para></footnote></para></listitem>
+	<listitem><para>Domain logons for Windows NT4/200x/XP Professional clients.</para></listitem>
+	<listitem><para>Configuration of roaming profiles or explicit configuration to force local profile usage.</para></listitem>
+	<listitem><para>Configuration of network/system policies.</para></listitem>
+	<listitem><para>Adding and managing domain user accounts.</para></listitem>
+	<listitem><para>Configuring MS Windows NT4/2000 Professional and Windows XP Professional client machines to become domain members.</para></listitem>
+</itemizedlist>
+
+<para>
+The following provisions are required to serve MS Windows 9x/Me clients:
+</para>
+
+<itemizedlist>
+	<listitem><para>Configuration of basic TCP/IP and MS Windows networking.</para></listitem>
+	<listitem><para>Correct designation of the server role (<smbconfoption name="security">user</smbconfoption>).</para></listitem>
+	<listitem><para>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).</para></listitem>
+	<listitem><para>Roaming profile configuration.</para></listitem>
+	<listitem><para>Configuration of system policy handling.</para></listitem>
+	<listitem><para>Installation of the network driver <quote>Client for MS Windows Networks</quote> and configuration
+	to log onto the domain.</para></listitem>
+	<listitem><para>Placing Windows 9x/Me clients in user-level security &smbmdash; if it is desired to allow
+	all client-share access to be controlled according to domain user/group identities.</para></listitem>
+	<listitem><para>Adding and managing domain user accounts.</para></listitem>
+</itemizedlist>
+
+<note><para>
+<indexterm><primary>roaming profiles</primary></indexterm>
+<indexterm><primary>account policies</primary></indexterm>
+Roaming profiles and system/network policies are advanced network administration topics
+that are covered in <link linkend="ProfileMgmt">Desktop Profile Management</link> and
+<link linkend="PolicyMgmt">System and Account Policies</link> of this document. However, these are not
+necessarily specific to a Samba PDC as much as they are related to Windows NT networking concepts.
+</para></note>
+
+<para>
+A domain controller is an SMB/CIFS server that:
+</para>
+
+<itemizedlist>
+	<listitem><para>
+	<indexterm><primary>NetBIOS</primary><secondary>brooadcast</secondary></indexterm>
+	<indexterm><primary>WINS</primary></indexterm>
+	<indexterm><primary>UDP</primary></indexterm>
+	<indexterm><primary>DNS</primary></indexterm>
+	<indexterm><primary>active directory</primary></indexterm>
+	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).
+	</para></listitem>
+
+	<listitem><para>
+	<indexterm><primary>NETLOGON</primary></indexterm>
+	<indexterm><primary>LanMan logon service</primary></indexterm>
+	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.)
+	</para></listitem>
+
+	<listitem><para>
+	Provides a share called NETLOGON.
+	</para></listitem>
+</itemizedlist>
+
+<para>
+<indexterm><primary>domain</primary><secondary>master</secondary><tertiary>browser</tertiary></indexterm>
+<indexterm><primary>local</primary><secondary>master</secondary><tertiary>browser</tertiary></indexterm>
+<indexterm><primary>DMB</primary></indexterm>
+<indexterm><primary>LMB</primary></indexterm>
+<indexterm><primary>browse list</primary></indexterm>
+It is rather easy to configure Samba to provide these. Each Samba domain controller must provide the NETLOGON
+service that Samba calls the <smbconfoption name="domain logons"/> functionality (after the name of the
+parameter in the &smb.conf; file). Additionally, one server in a Samba-3 domain must advertise itself as the
+domain master browser.<footnote><para>See <link linkend="NetworkBrowsing">Network
+Browsing</link>.</para></footnote> 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.
+</para>
+
+</sect2>
+</sect1>
+
+<sect1>
+<title>Domain Control: Example Configuration</title>
+
+<para>
+The first step in creating a working Samba PDC is to understand the parameters necessary
+in &smb.conf;. An example &smb.conf; for acting as a PDC can be found in <link linkend="pdc-example">the
+smb.conf file for an example PDC</link>. 
+</para>
+
+<example id="pdc-example">
+<title>smb.conf for being a PDC</title>
+<smbconfblock>
+<smbconfsection name="[global]"/>
+<smbconfoption name="netbios name"><replaceable>BELERIAND</replaceable></smbconfoption>
+<smbconfoption name="workgroup"><replaceable>&example.workgroup;</replaceable></smbconfoption>
+<smbconfoption name="passdb backend">tdbsam</smbconfoption>
+<smbconfoption name="os level">33</smbconfoption>
+<smbconfoption name="preferred master">auto</smbconfoption>
+<smbconfoption name="domain master">yes</smbconfoption>
+<smbconfoption name="local master">yes</smbconfoption>
+<smbconfoption name="security">user</smbconfoption>
+<smbconfoption name="domain logons">yes</smbconfoption>
+<smbconfoption name="logon path">\\%N\profiles\%U</smbconfoption>
+<smbconfoption name="logon drive">H:</smbconfoption>
+<smbconfoption name="logon home">\\homeserver\%U\winprofile</smbconfoption>
+<smbconfoption name="logon script">logon.cmd</smbconfoption>
+
+<smbconfsection name="[netlogon]"/>
+<smbconfoption name="path">/var/lib/samba/netlogon</smbconfoption>
+<smbconfoption name="read only">yes</smbconfoption>
+<smbconfoption name="write list"><replaceable>ntadmin</replaceable></smbconfoption>
+
+<smbconfsection name="[profiles]"/>
+<smbconfoption name="path">/var/lib/samba/profiles</smbconfoption>
+<smbconfoption name="read only">no</smbconfoption>
+<smbconfoption name="create mask">0600</smbconfoption>
+<smbconfoption name="directory mask">0700</smbconfoption>
+</smbconfblock>
+</example>
+
+<para>
+The basic options shown in <link linkend="pdc-example">this example</link> are explained as follows:
+</para>
+
+<variablelist>
+	<varlistentry><term>passdb backend </term>
+		<listitem><para>
+		<indexterm><primary>group</primary><secondary>account</secondary></indexterm>
+		<indexterm><primary>smbpasswd</primary></indexterm>
+		<indexterm><primary>tdbsam</primary></indexterm>
+		<indexterm><primary>ldapsam</primary></indexterm>
+		<indexterm><primary>guest</primary></indexterm>
+		<indexterm><primary>default accounts</primary></indexterm>
+		This contains all the user and group account information. Acceptable values for a PDC
+		are: <emphasis>smbpasswd, tdbsam, and ldapsam</emphasis>. The <quote>guest</quote> entry provides
+		default accounts and is included by default; there is no need to add it explicitly.
+		</para>
+
+		<para>
+		<indexterm><primary>passdb backend</primary></indexterm>
+		<indexterm><primary>distributed</primary></indexterm>
+		<indexterm><primary>smbpasswd</primary></indexterm>
+		<indexterm><primary>tdbsam</primary></indexterm>
+		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.
+		</para></listitem>
+	</varlistentry>
+
+	<varlistentry><term>Domain Control Parameters </term>
+		<listitem><para>
+		<indexterm><primary>os level</primary></indexterm>
+		<indexterm><primary>preferred master</primary></indexterm>
+		<indexterm><primary>domain master</primary></indexterm>
+		<indexterm><primary>network</primary><secondary>logon</secondary></indexterm>
+		The parameters <emphasis>os level, preferred master, domain master, security, 
+		encrypt passwords</emphasis>, and <emphasis>domain logons</emphasis> play a central role in assuring domain
+		control and network logon support.
+		</para>
+
+		<para>
+		<indexterm><primary>DMB</primary></indexterm>
+		<indexterm><primary>encryped password</primary></indexterm>
+		The <emphasis>os level</emphasis> must be set at or above a value of 32. A domain controller
+		must be the DMB, must be set in <emphasis>user</emphasis> mode security,
+		must support Microsoft-compatible encrypted passwords, and must provide the network logon
+		service (domain logons). Encrypted passwords must be enabled. For more details on how 
+		to do this, refer to <link linkend="passdb">Account Information Databases</link>.
+		</para></listitem>
+	</varlistentry>
+
+	<varlistentry><term>Environment Parameters </term>
+		<listitem><para>
+		<indexterm><primary>logon path</primary></indexterm>
+		<indexterm><primary>logon home</primary></indexterm>
+		<indexterm><primary>logon drive</primary></indexterm>
+		<indexterm><primary>logon script</primary></indexterm>
+		The parameters <emphasis>logon path, logon home, logon drive</emphasis>, and <emphasis>logon script</emphasis> 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.
+		</para></listitem>
+	</varlistentry>
+
+	<varlistentry><term>NETLOGON Share </term>
+		<listitem><para>
+		<indexterm><primary>NETLOGON</primary></indexterm>
+		<indexterm><primary>logon processing</primary></indexterm>
+		<indexterm><primary>domain logon</primary></indexterm>
+		<indexterm><primary>domain membership</primary></indexterm>
+		<indexterm><primary>group policy</primary></indexterm>
+		<indexterm><primary>NTConfig.POL</primary></indexterm>
+		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.
+		</para></listitem>
+	</varlistentry>
+
+	<varlistentry><term>PROFILE Share </term>
+		<listitem><para>
+		<indexterm><primary>desktop profile</primary></indexterm>
+		<indexterm><primary>VFS</primary></indexterm>
+		<indexterm><primary>fake_permissions</primary></indexterm>
+		<indexterm><primary>profile</primary></indexterm>
+		<indexterm><primary></primary></indexterm>
+		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 <quote>fake_permissions</quote> 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.
+		</para></listitem>
+	</varlistentry>
+</variablelist>
+
+<note><para>
+The above parameters make for a full set of functionality that may define the server's mode
+of operation. The following &smb.conf; parameters are the essentials alone:
+</para>
+
+<para>
+<smbconfblock>
+<smbconfoption name="netbios name">BELERIAND</smbconfoption>
+<smbconfoption name="workgroup">&example.workgroup;</smbconfoption>
+<smbconfoption name="domain logons">Yes</smbconfoption>
+<smbconfoption name="domain master">Yes</smbconfoption>
+<smbconfoption name="security">User</smbconfoption>
+</smbconfblock>
+</para>
+
+<para>
+The additional parameters shown in the longer listing in this section just make for
+a more complete explanation.
+</para></note>
+
+</sect1>
+
+<sect1>
+<title>Samba ADS Domain Control</title>
+
+<para>
+<indexterm><primary>active directory</primary></indexterm>
+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!
+</para>
+
+<para>
+<indexterm><primary>domain controllers</primary></indexterm>
+<indexterm><primary>active directory</primary></indexterm>
+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.
+</para>
+
+</sect1>
+
+<sect1>
+<title>Domain and Network Logon Configuration</title>
+
+<para>
+<indexterm><primary>domain logon</primary></indexterm>
+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.
+</para>
+
+<sect2>
+<title>Domain Network Logon Service</title>
+
+<para>
+<indexterm><primary>domain logon</primary></indexterm>
+All domain controllers must run the netlogon service (<emphasis>domain logons</emphasis>
+in Samba). One domain controller must be configured with <smbconfoption name="domain master">Yes</smbconfoption>
+(the PDC); on all BDCs set the parameter <smbconfoption name="domain master">No</smbconfoption>.
+</para>
+
+<sect3>
+<title>Example Configuration</title>
+
+<example id="PDC-config">
+<title>smb.conf for being a PDC</title>
+<smbconfblock>
+<smbconfsection name="[global]"/>
+<smbconfoption name="domain logons">Yes</smbconfoption>
+<smbconfoption name="domain master">(Yes on PDC, No on BDCs)</smbconfoption>
+
+<smbconfsection name="[netlogon]"/>
+<smbconfoption name="comment">Network Logon Service</smbconfoption>
+<smbconfoption name="path">/var/lib/samba/netlogon</smbconfoption>
+<smbconfoption name="guest ok">Yes</smbconfoption>
+<smbconfoption name="browseable">No</smbconfoption>
+</smbconfblock>
+</example>
+
+</sect3>
+<sect3>
+<title>The Special Case of MS Windows XP Home Edition</title>
+
+<para>
+<indexterm><primary>Windows XP Home edition</primary></indexterm>
+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.
+</para>
+
+<note><para>
+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.
+</para></note>
+
+<para>
+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.
+</para>
+
+</sect3>
+
+<sect3>
+<title>The Special Case of Windows 9x/Me</title>
+
+<para>
+<indexterm><primary>domain</primary></indexterm>
+<indexterm><primary>workgroup</primary></indexterm>
+<indexterm><primary>authentication</primary></indexterm>
+<indexterm><primary>browsing</primary></indexterm>
+<indexterm><primary>rights</primary></indexterm>
+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.
+</para>
+
+<para>
+<indexterm><primary>browsing</primary></indexterm>
+The SMB client logging on to a domain has an expectation that every other
+server in the domain should accept the same authentication information.
+Network browsing functionality of domains and workgroups is identical and
+is explained in this documentation under the browsing discussions.
+It should be noted that browsing is totally orthogonal to logon support.
+</para>
+
+<para>
+<indexterm><primary>single-logon</primary></indexterm>
+<indexterm><primary>domain logons</primary></indexterm>
+<indexterm><primary>network logon</primary></indexterm>
+Issues related to the single-logon network model are discussed in this
+section. Samba supports domain logons, network logon scripts, and user
+profiles for MS Windows for Workgroups and MS Windows 9x/Me clients,
+which are the focus of this section.
+</para>
+
+<para>
+<indexterm><primary>broadcast request</primary></indexterm>
+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.
+</para>
+
+<para>
+Using these features, you can make your clients verify their logon via
+the Samba server, make clients run a batch file when they log on to
+the network and download their preferences, desktop, and start menu.
+</para>
+
+<para><emphasis>
+MS Windows XP Home edition is not able to join a domain and does not permit the use of domain logons.
+</emphasis></para>
+
+<para>
+Before launching into the configuration instructions, it is worthwhile to look at how a Windows 9x/Me client
+performs a logon:
+</para>
+
+<orderedlist>
+<listitem>
+	<para>
+	<indexterm><primary>DOMAIN&lt;1C&gt;</primary></indexterm>
+	<indexterm><primary>logon server</primary></indexterm>
+	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&lt;1C&gt; 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 
+	<filename>\\SERVER</filename>. The <literal>1C</literal> name is the name
+	type that is registered by domain controllers (SMB/CIFS servers that provide
+	the netlogon service).
+	</para>
+</listitem>
+
+<listitem>
+	<para>
+	<indexterm><primary>IPC$</primary></indexterm>
+	<indexterm><primary>SMBsessetupX</primary></indexterm>
+	<indexterm><primary>SMBtconX</primary></indexterm>
+	The client connects to that server, logs on (does an SMBsessetupX) and
+	then connects to the IPC$ share (using an SMBtconX).
+	</para>
+</listitem>
+
+<listitem>
+	<para>
+	<indexterm><primary>NetWkstaUserLogon</primary></indexterm>
+	The client does a NetWkstaUserLogon request, which retrieves the name
+	of the user's logon script. 
+	</para>
+</listitem>
+
+<listitem>
+	<para>
+	The client then connects to the NetLogon share and searches for 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.
+	</para>
+</listitem>
+
+<listitem>
+	<para>
+	<indexterm><primary>NetUserGetInfo</primary></indexterm>
+	<indexterm><primary>profile</primary></indexterm>
+	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.
+	</para>
+</listitem>
+
+<listitem>
+	<para>
+	<indexterm><primary>profiles</primary></indexterm>
+	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, <filename>\\server\fred\.winprofile</filename>.
+	If the profiles are found, they are implemented.
+	</para>
+</listitem>
+
+<listitem>
+	<para>
+	<indexterm><primary>CONFIG.POL</primary></indexterm>
+	The client then disconnects from the user's home share and reconnects to
+	the NetLogon share and looks for <filename>CONFIG.POL</filename>, the policies file. If this is
+	found, it is read and implemented.
+	</para>
+</listitem>
+</orderedlist>
+
+<para>
+The main difference between a PDC and a Windows 9x/Me logon server configuration is:
+</para>
+
+<itemizedlist>
+<listitem><para>
+	<indexterm><primary>password</primary><secondary>plaintext</secondary></indexterm>
+	<indexterm><primary>plaintext password</primary></indexterm>
+	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 <link linkend="PolicyMgmt">System and Account Policies</link>.
+	</para></listitem>
+
+	<listitem><para>
+	<indexterm><primary>machine trust account</primary></indexterm>
+	Windows 9x/Me clients do not require and do not use Machine Trust Accounts.
+	</para></listitem>
+</itemizedlist>
+
+<para>
+<indexterm><primary>network logon services</primary></indexterm>
+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.
+</para>
+
+<note><para>
+<indexterm><primary>sniffer</primary></indexterm>
+Use of plaintext passwords is strongly discouraged. Where used they are easily detected
+using a sniffer tool to examine network traffic.
+</para></note>
+
+</sect3>
+</sect2>
+
+<sect2>
+<title>Security Mode and Master Browsers</title>
+
+<para>
+<indexterm><primary>security mode</primary></indexterm>
+<indexterm><primary>user-mode security</primary></indexterm>
+<indexterm><primary>share-mode security</primary></indexterm>
+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.
+</para>
+
+<para>
+<indexterm><primary>DOMAIN&lt;1C&gt;</primary></indexterm>
+<indexterm><primary>DOMAIN&lt;1B&gt;</primary></indexterm>
+<indexterm><primary>DMB</primary></indexterm>
+<indexterm><primary>PDC</primary></indexterm>
+<indexterm><primary>NetBIOS name</primary></indexterm>
+<indexterm><primary>domain controller</primary></indexterm>
+<indexterm><primary>election</primary></indexterm>
+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&lt;1B&gt; NetBIOS name. This is not the name used by Windows clients
+to locate the domain controller, all domain controllers register the DOMAIN&lt;1C&gt; name and Windows clients
+locate a network logon server by seraching for the DOMAIN&lt;1C&gt; name.  A DMB is a Domain Master Browser
+&smbmdash; see <link linkend="NetworkBrowsing">The Network Browsing Chapter</link>, <link
+linkend="DMB">Configuring WORKGROUP Browsing</link>; 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.
+</para>
+
+<note><para>
+<indexterm><primary>DOMAIN&lt;1D&gt;</primary></indexterm>
+<indexterm><primary>synchronization</primary></indexterm>
+<indexterm><primary>domain control</primary></indexterm>
+<indexterm><primary>browse list management</primary></indexterm>
+<indexterm><primary>network</primary><secondary>logon</secondary><tertiary>service</tertiary></indexterm>
+SMB/CIFS servers that register the DOMAIN&lt;1C&gt; name do so because they provide the network logon
+service. Server that register the DOMAIN&lt;1B&gt; name are DMBs &smbmdash; meaning that they are responsible
+for browse list synchronization across all machines that have registered the DOMAIN&lt;1D&gt; 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.
+</para></note>
+
+<para>
+Now back to the issue of configuring a Samba domain controller to use a mode other than <smbconfoption
+name="security">user</smbconfoption>. 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 <smbconfoption name="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
+<smbconfoption name="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.
+</para>
+
+<para>
+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 <smbconfoption name="security">user</smbconfoption>.
+This is the only officially supported mode of operation.
+</para>
+
+</sect2>
+
+</sect1>
+
+<sect1>
+<title>Common Errors</title>
+
+<sect2>
+<title><quote>$</quote> Cannot Be Included in Machine Name</title>
+
+<para>
+<indexterm><primary>BSD</primary></indexterm>
+<indexterm><primary>FreeBSD</primary></indexterm>
+<indexterm><primary>/etc/passwd</primary></indexterm>
+A machine account, typically stored in <filename>/etc/passwd</filename>, takes the form of the machine
+name with a <quote>$</quote> appended. Some BSD systems will not create a user with a <quote>$</quote> in the name.
+Recent versions of FreeBSD have removed this limitation, but older releases are still in common use.
+</para>
+
+<para>
+<indexterm><primary>vipw</primary></indexterm>
+The problem is only in the program used to make the entry. Once made, it works perfectly.  Create a user
+without the <quote>$</quote>. Then use <command>vipw</command> to edit the entry, adding the <quote>$</quote>.
+Or create the whole entry with vipw if you like; make sure you use a unique user login ID.
+</para>
+
+<note><para>The machine account must have the exact name that the workstation has.</para></note>
+
+<note><para>
+The UNIX tool <command>vipw</command> is a common tool for directly editing the <filename>/etc/passwd</filename> 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.
+</para></note>
+
+</sect2>
+
+<sect2>
+<title>Joining Domain Fails Because of Existing Machine Account</title>
+		
+<para>
+<indexterm><primary>join domain</primary></indexterm>
+<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.</quote>
+</para>
+
+<para>
+This happens if you try to create a Machine Trust Account from the machine itself and already have a
+connection (e.g., mapped drive) to a share (or IPC$) on the Samba PDC. The following command will remove all
+network drive connections:
+<screen>
+&dosprompt;<userinput>net use * /d</userinput>
+</screen>
+This will break all network connections.
+</para>
+
+<para>
+Further, if the machine is already a <quote>member of a workgroup</quote> 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 &smbmdash;
+it does not matter what &smbmdash; reboot, and try again.
+</para>
+
+</sect2>
+
+<sect2>
+<title>The System Cannot Log You On (C000019B)</title>
+
+<para><quote>
+I joined the domain successfully but after upgrading to a newer version of the Samba code I get the message,
+<errorname>`The system cannot log you on (C000019B). Please try again or consult your system
+administrator</errorname> when attempting to logon.'</quote>
+</para>
+
+<para>
+<indexterm><primary>SID</primary></indexterm>
+This occurs when the domain SID stored in the secrets.tdb database is changed. The most common cause of a
+change in domain SID is when the domain name and/or the server name (NetBIOS name) is changed.  The only way
+to correct the problem is to restore the original domain SID or remove the domain client from the domain and
+rejoin. The domain SID may be reset using either the net or rpcclient utilities.
+</para>
+
+<para>
+To reset or change the domain SID you can use the net command as follows:
+
+<screen>
+&rootprompt;<userinput>net getlocalsid 'OLDNAME'</userinput>
+&rootprompt;<userinput>net setlocalsid 'SID'</userinput>
+</screen>
+</para>
+
+<para>
+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.
+</para>
+
+</sect2>
+
+<sect2>
+<title>The Machine Trust Account Is Not Accessible</title>
+
+<para>
+<quote>When I try to join the domain I get the message, <errorname>"The machine account 
+for this computer either does not exist or is not accessible</errorname>." What's wrong?</quote>
+</para>
+
+<para>
+This problem is caused by the PDC not having a suitable Machine Trust Account.  If you are using the
+<smbconfoption name="add machine script"/> method to create accounts, then this would indicate that it has not
+worked. Ensure the domain admin user system is working.
+</para>
+
+<para>
+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 <filename>smbpasswd</filename> 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 <quote>$</quote> 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 <parameter>passdb
+backend</parameter> is not specified in the &smb.conf; file, or if specified is set to
+<literal>smbpasswd</literal>, are respectively the <filename>/etc/passwd</filename> and
+<filename>/etc/samba/smbpasswd</filename> (or <filename>/usr/local/samba/lib/private/smbpasswd</filename> if
+compiled using Samba Team default settings). The use of the <filename>/etc/passwd</filename> can be overridden
+by alternative settings in the NSS <filename>/etc/nsswitch.conf</filename> file.
+</para>
+
+<para>
+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.
+</para>
+</sect2>
+
+<sect2>
+<title>Account Disabled</title>
+
+<para><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.</quote></para>
+
+<para>
+Enable the user accounts with <userinput>smbpasswd -e <replaceable>username</replaceable>
+</userinput>. This is normally done as an account is created.
+</para>
+
+</sect2>
+
+<sect2>
+<title>Domain Controller Unavailable</title>
+		
+<para><quote>Until a few minutes after Samba has started, clients get the error `Domain Controller Unavailable'</quote></para>
+
+<para>
+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.
+</para>
+</sect2>
+
+<sect2>
+<title>Cannot Log onto Domain Member Workstation After Joining Domain</title>
+
+<para>
+<indexterm><primary>schannel</primary></indexterm>
+<indexterm><primary>signing</primary></indexterm>
+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 <emphasis>schannel</emphasis>
+(secure channel) settings or <emphasis>smb signing</emphasis> settings. Check your Samba
+settings for <emphasis>client schannel</emphasis>, <emphasis>server schannel</emphasis>,
+<emphasis>client signing</emphasis>, <emphasis>server signing</emphasis> by executing:
+<screen>
+<command>testparm -v | grep channel</command> and looking for the value of these parameters.
+</screen>
+</para>
+
+<para>
+Also use the MMC &smbmdash; 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
+<emphasis>Secure Channel:..., and Digitally sign...</emphasis>.
+</para>
+
+<para>
+It is important that these be set consistently with the Samba-3 server settings.
+</para>
+
+</sect2>
+
+</sect1>
+</chapter>