diff options
author | Andrew Bartlett <abartlet@samba.org> | 2012-09-23 04:55:20 +1000 |
---|---|---|
committer | Andrew Bartlett <abartlet@samba.org> | 2012-09-25 14:43:15 +1000 |
commit | e3f554a99f3871eabac35db1ba3236772ef58f64 (patch) | |
tree | 53638e1603c3724354d0db52a13405e70c985f77 /docs-xml/Samba3-HOWTO | |
parent | f82affaa6defef52696f69f114143cfb80fee241 (diff) | |
download | samba-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.xml | 166 |
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<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> |