summaryrefslogtreecommitdiff
path: root/docs-xml/Samba3-HOWTO
diff options
context:
space:
mode:
authorAndrew Bartlett <abartlet@samba.org>2012-09-23 04:55:20 +1000
committerAndrew Bartlett <abartlet@samba.org>2012-09-25 14:43:15 +1000
commite3f554a99f3871eabac35db1ba3236772ef58f64 (patch)
tree53638e1603c3724354d0db52a13405e70c985f77 /docs-xml/Samba3-HOWTO
parentf82affaa6defef52696f69f114143cfb80fee241 (diff)
downloadsamba-e3f554a99f3871eabac35db1ba3236772ef58f64.tar.gz
samba-e3f554a99f3871eabac35db1ba3236772ef58f64.tar.bz2
samba-e3f554a99f3871eabac35db1ba3236772ef58f64.zip
docs: Remove Win9X/WinMe mentions from TOSHARG-PDC
Diffstat (limited to 'docs-xml/Samba3-HOWTO')
-rw-r--r--docs-xml/Samba3-HOWTO/TOSHARG-PDC.xml166
1 files changed, 0 insertions, 166 deletions
diff --git a/docs-xml/Samba3-HOWTO/TOSHARG-PDC.xml b/docs-xml/Samba3-HOWTO/TOSHARG-PDC.xml
index 5c4428376c..0698ced821 100644
--- a/docs-xml/Samba3-HOWTO/TOSHARG-PDC.xml
+++ b/docs-xml/Samba3-HOWTO/TOSHARG-PDC.xml
@@ -907,172 +907,6 @@ Microsoft, and we recommend that you do not do that.
</sect3>
-<sect3>
-<title>The Special Case of Windows 9x/Me</title>
-
-<para>
-<indexterm><primary>domain</primary></indexterm>
-<indexterm><primary>workgroup</primary></indexterm>
-<indexterm><primary>authentication</primary></indexterm>
-<indexterm><primary>browsing</primary></indexterm>
-<indexterm><primary>rights</primary></indexterm>
-A domain and a workgroup are exactly the same in terms of network
-browsing. The difference is that a distributable authentication
-database is associated with a domain, for secure login access to a
-network. Also, different access rights can be granted to users if they
-successfully authenticate against a domain logon server. Samba-3 does this
-now in the same way as MS Windows NT/200x.
-</para>
-
-<para>
-<indexterm><primary>browsing</primary></indexterm>
-The SMB client logging on to a domain has an expectation that every other
-server in the domain should accept the same authentication information.
-Network browsing functionality of domains and workgroups is identical and
-is explained in this documentation under the browsing discussions.
-It should be noted that browsing is totally orthogonal to logon support.
-</para>
-
-<para>
-<indexterm><primary>single-logon</primary></indexterm>
-<indexterm><primary>domain logons</primary></indexterm>
-<indexterm><primary>network logon</primary></indexterm>
-Issues related to the single-logon network model are discussed in this
-section. Samba supports domain logons, network logon scripts, and user
-profiles for MS Windows for Workgroups and MS Windows 9x/Me clients,
-which are the focus of this section.
-</para>
-
-<para>
-<indexterm><primary>broadcast request</primary></indexterm>
-When an SMB client in a domain wishes to log on, it broadcasts requests for a logon server. The first one to
-reply gets the job and validates its password using whatever mechanism the Samba administrator has installed.
-It is possible (but ill advised) to create a domain where the user database is not shared between servers;
-that is, they are effectively workgroup servers advertising themselves as participating in a domain. This
-demonstrates how authentication is quite different from but closely involved with domains.
-</para>
-
-<para>
-Using these features, you can make your clients verify their logon via
-the Samba server, make clients run a batch file when they log on to
-the network and download their preferences, desktop, and start menu.
-</para>
-
-<para><emphasis>
-MS Windows XP Home edition is not able to join a domain and does not permit the use of domain logons.
-</emphasis></para>
-
-<para>
-Before launching into the configuration instructions, it is worthwhile to look at how a Windows 9x/Me client
-performs a logon:
-</para>
-
-<orderedlist>
-<listitem>
- <para>
- <indexterm><primary>DOMAIN&lt;1C&gt;</primary></indexterm>
- <indexterm><primary>logon server</primary></indexterm>
- The client broadcasts (to the IP broadcast address of the subnet it is in)
- a NetLogon request. This is sent to the NetBIOS name DOMAIN&lt;1C&gt; at the
- NetBIOS layer. The client chooses the first response it receives, which
- contains the NetBIOS name of the logon server to use in the format of
- <filename>\\SERVER</filename>. The <literal>1C</literal> name is the name
- type that is registered by domain controllers (SMB/CIFS servers that provide
- the netlogon service).
- </para>
-</listitem>
-
-<listitem>
- <para>
- <indexterm><primary>IPC$</primary></indexterm>
- <indexterm><primary>SMBsessetupX</primary></indexterm>
- <indexterm><primary>SMBtconX</primary></indexterm>
- The client connects to that server, logs on (does an SMBsessetupX) and
- then connects to the IPC$ share (using an SMBtconX).
- </para>
-</listitem>
-
-<listitem>
- <para>
- <indexterm><primary>NetWkstaUserLogon</primary></indexterm>
- The client does a NetWkstaUserLogon request, which retrieves the name
- of the user's logon script.
- </para>
-</listitem>
-
-<listitem>
- <para>
- The client then connects to the NetLogon share and searches for said script.
- If it is found and can be read, it is retrieved and executed by the client.
- After this, the client disconnects from the NetLogon share.
- </para>
-</listitem>
-
-<listitem>
- <para>
- <indexterm><primary>NetUserGetInfo</primary></indexterm>
- <indexterm><primary>profile</primary></indexterm>
- The client sends a NetUserGetInfo request to the server to retrieve
- the user's home share, which is used to search for profiles. Since the
- response to the NetUserGetInfo request does not contain much more than
- the user's home share, profiles for Windows 9x clients must reside in the user
- home directory.
- </para>
-</listitem>
-
-<listitem>
- <para>
- <indexterm><primary>profiles</primary></indexterm>
- The client connects to the user's home share and searches for the
- user's profile. As it turns out, you can specify the user's home share as
- a share name and path. For example, <filename>\\server\fred\.winprofile</filename>.
- If the profiles are found, they are implemented.
- </para>
-</listitem>
-
-<listitem>
- <para>
- <indexterm><primary>CONFIG.POL</primary></indexterm>
- The client then disconnects from the user's home share and reconnects to
- the NetLogon share and looks for <filename>CONFIG.POL</filename>, the policies file. If this is
- found, it is read and implemented.
- </para>
-</listitem>
-</orderedlist>
-
-<para>
-The main difference between a PDC and a Windows 9x/Me logon server configuration is:
-</para>
-
-<itemizedlist>
-<listitem><para>
- <indexterm><primary>password</primary><secondary>plaintext</secondary></indexterm>
- <indexterm><primary>plaintext password</primary></indexterm>
- Password encryption is not required for a Windows 9x/Me logon server. But note
- that beginning with MS Windows 98 the default setting is that plaintext
- password support is disabled. It can be re-enabled with the registry
- changes that are documented in <link linkend="PolicyMgmt">System and Account Policies</link>.
- </para></listitem>
-
- <listitem><para>
- <indexterm><primary>machine trust account</primary></indexterm>
- Windows 9x/Me clients do not require and do not use Machine Trust Accounts.
- </para></listitem>
-</itemizedlist>
-
-<para>
-<indexterm><primary>network logon services</primary></indexterm>
-A Samba PDC will act as a Windows 9x/Me logon server; after all, it does provide the
-network logon services that MS Windows 9x/Me expect to find.
-</para>
-
-<note><para>
-<indexterm><primary>sniffer</primary></indexterm>
-Use of plaintext passwords is strongly discouraged. Where used they are easily detected
-using a sniffer tool to examine network traffic.
-</para></note>
-
-</sect3>
</sect2>
<sect2>