</para>
<para>
-<indexterm>single sign-on<primary></primary><see>SSO</see></indexterm>
+<indexterm><primary>single sign-on</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>
</para></note>
<para>
-The following functionalities are new to the Samba-3 release:
+The following functionalities are an overview of some of the features
+in the Samba-4 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.
+ Samba-4 supports the use of a choice of backends that may be used in which user, group and machine
+ accounts may be stored, but only when acting as a classic
+ (NT4) domain controller,
+ but not when it is acting as an Active Directory Domain Controller.
</para>
<para>
<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.
+ which is of great value because it confers scalability and
+ provides a high degree of reliability. This may be used when
+ Samba-4 is acting as an classic (NT4-like) domain controller,
+ but not when it is acting as an Active Directory Domain Controller.
</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
+ Windows NT4 domain trusts. Samba-4 supports workstation and server (machine) trust accounts. It also
supports Windows NT4 style interdomain trust accounts, which further assists in network scalability
- and interoperability.
+ and interoperability, but only when itself is an classic
+ (NT4-like) domain controller.
</para></listitem>
<listitem><para>
<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
+ only when operating as a Microsoft active directory domain
+ member server. When acting as a Samba classic (NT4-like) domain
controller the use of NetBIOS is necessary to provide network browsing support.
</para></listitem>
<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
+ Samba-4 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.
+ <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).
</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.
+ <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) can be
+ used to manage a Samba-4 server, when it is an Active
+ Directory Domain Controller. When acting as a classic (NT4)
+ domain controller, 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>
-The following functionalities are not provided by Samba-3:
+The following functionalities are not provided by Samba-4:
</para>
<itemizedlist>
<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
+ This means Samba cannot operate as a BDC when the PDC is Microsoft-based Windows NT PDC. Samba-4 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
<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
+Samba-4, 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
+Windows Workstation/Server Machine Trust Accounts</link>. A complete discussion of account database backends can be found in <link linkend="passdb">Account
Information Databases</link>.
</para>
<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.
+change the solution architecture so as to accommodate a new identity management and user authentication system.
Many SSO solutions involving legacy systems consist of a new super-structure that handles authentication on
behalf of the user. The software that gets layered over the old system may simply implement a proxy
authentication system. This means that the addition of SSO increases over-all information systems complexity.
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
+Microsoft 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.
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.
+but implementation of the technology mostly requires customization to integrate applications and develop user
+interfaces. In a nutshell, that is why FIM is a big and growing industry.
</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
+At this time, the use of Samba based BDCs, necessitates the use of
+either the Samba-4 Active Directory Domain controller or, for classic
+(NT4-like)domains an LDAP backend. 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>
<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>
+<indexterm><primary>domain</primary><secondary>member</secondary><tertiary>server</tertiary></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
<indexterm><primary>BDC</primary></indexterm>
<indexterm><primary>authenticatior</primary></indexterm>
<indexterm><primary>synchronization</primary></indexterm>
+<indexterm><primary>FSMO</primary></indexterm>
+<indexterm><primary>Flexible Single Master Operator</primary><see>FSMO</see></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.
+database with BDCs. With Active Directory domains, while some servers
+may be a Flexible Single Master Operator (FSMO) role owner (and
+therefore hold the monopoly for certain operations), it is in general
+a distributed, multi-master replicated directory.
</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>
+Samba-4 can use a backend database that holds the same type of data as the NT4-style SAM
+database (one of the registry files). For BDC/BDC operations in a
+classic domain, this functionality can be implemented using an
+LDAP-based user and machine account backend. The Samba-4 Active
+Directory Domain controller implements the required storage internally.<footnote><para>See also <link linkend="passdb">Account Information
+Databases</link>.</para></footnote>
</para>
<para>
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>
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>
<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>
<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>
<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
+ The parameters <emphasis>domain logons</emphasis>
+ parameter is the key parameter indicating 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>
<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>
<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!
+Samba-4 is also available as an Active Directory server. It can truly function as an Active Directory
+PDC. The protocols for some of the functionality of Active Directory
+domain controllers has been implemented.
</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.
+<indexterm><primary>classic domain support</primary></indexterm>
+To be sure, Samba-4 is also designed to provide most of the functionality that Microsoft Windows NT4-style
+domain controllers have. Samba-4 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. We call it a <emphasis>classic domain</emphasis> controller for
+this reason, as in short, Samba-4 when acting in this mode is not NT4,
+and the Active Directory Domain Control aspect is a distinct capability.
</para>
</sect1>
<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>
+in Samba). One domain controller must be configured without the
+<smbconfoption name="domain master"></smbconfoption> parameter
(the PDC); on all BDCs set the parameter <smbconfoption name="domain master">No</smbconfoption>.
</para>
<smbconfblock>
<smbconfsection name="[global]"/>
<smbconfoption name="domain logons">Yes</smbconfoption>
-<smbconfoption name="domain master">(Yes on PDC, No on BDCs)</smbconfoption>
+<smbconfoption name="domain master">(omit on PDC, No on BDCs)</smbconfoption>
<smbconfsection name="[netlogon]"/>
<smbconfoption name="comment">Network Logon Service</smbconfoption>
</sect3>
<sect3>
-<title>The Special Case of MS Windows XP Home Edition</title>
+<title>The Special Case of MS Windows Home Editions</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
+<indexterm><primary>Windows Home editions</primary></indexterm>
+To be completely clear: If you want MS Windows Home Editions 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.
+The only option is to purchase the upgrade from MS Windows Home Edition to
+a MS Windows Professional edition.
</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.
+MS Windows Home Editions do not have the ability to join any type of domain
+security facility. Unlike MS Windows 9x/Me, MS Windows Home Edition
+deliberatly lacks the ability to log onto a network.
</para></note>
<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>
git.samba.org / kai / samba.git / blobdiff