diff options
Diffstat (limited to 'docs-xml/Samba3-HOWTO/TOSHARG-PDC.xml')
| -rw-r--r-- | docs-xml/Samba3-HOWTO/TOSHARG-PDC.xml | 1409 |
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<1C></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<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 + <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<1C></primary></indexterm> +<indexterm><primary>DOMAIN<1B></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<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 +&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<1D></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<1C> name do so because they provide the network logon +service. Server that register the DOMAIN<1B> name are DMBs &smbmdash; 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. +</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> |