summaryrefslogtreecommitdiff
path: root/docs/docbook/projdoc/Integrating-with-Windows.sgml
diff options
context:
space:
mode:
Diffstat (limited to 'docs/docbook/projdoc/Integrating-with-Windows.sgml')
-rw-r--r--docs/docbook/projdoc/Integrating-with-Windows.sgml935
1 files changed, 935 insertions, 0 deletions
diff --git a/docs/docbook/projdoc/Integrating-with-Windows.sgml b/docs/docbook/projdoc/Integrating-with-Windows.sgml
new file mode 100644
index 0000000000..0b6abaf80f
--- /dev/null
+++ b/docs/docbook/projdoc/Integrating-with-Windows.sgml
@@ -0,0 +1,935 @@
+<chapter id="integrate-ms-networks">
+
+
+<chapterinfo>
+ <author>
+ <firstname>John</firstname><surname>Terpstra</surname>
+ <affiliation>
+ <orgname>Samba Team</orgname>
+ <address>
+ <email>jht@samba.org</email>
+ </address>
+ </affiliation>
+ </author>
+
+
+ <pubdate> (Jan 01 2001) </pubdate>
+</chapterinfo>
+
+<title>Integrating MS Windows networks with Samba</title>
+
+<sect1>
+<title>Agenda</title>
+
+<para>
+To identify the key functional mechanisms of MS Windows networking
+to enable the deployment of Samba as a means of extending and/or
+replacing MS Windows NT/2000 technology.
+</para>
+
+<para>
+We will examine:
+</para>
+
+<orderedlist>
+ <listitem><para>Name resolution in a pure Unix/Linux TCP/IP
+ environment
+ </para></listitem>
+
+ <listitem><para>Name resolution as used within MS Windows
+ networking
+ </para></listitem>
+
+ <listitem><para>How browsing functions and how to deploy stable
+ and dependable browsing using Samba
+ </para></listitem>
+
+ <listitem><para>MS Windows security options and how to
+ configure Samba for seemless integration
+ </para></listitem>
+
+ <listitem><para>Configuration of Samba as:</para>
+ <orderedlist>
+ <listitem><para>A stand-alone server</para></listitem>
+ <listitem><para>An MS Windows NT 3.x/4.0 security domain member
+ </para></listitem>
+ <listitem><para>An alternative to an MS Windows NT 3.x/4.0 Domain Controller
+ </para></listitem>
+ </orderedlist>
+ </listitem>
+</orderedlist>
+
+</sect1>
+
+
+<sect1>
+<title>Name Resolution in a pure Unix/Linux world</title>
+
+<para>
+The key configuration files covered in this section are:
+</para>
+
+<itemizedlist>
+ <listitem><para><filename>/etc/hosts</filename></para></listitem>
+ <listitem><para><filename>/etc/resolv.conf</filename></para></listitem>
+ <listitem><para><filename>/etc/host.conf</filename></para></listitem>
+ <listitem><para><filename>/etc/nsswitch.conf</filename></para></listitem>
+</itemizedlist>
+
+<sect2>
+<title><filename>/etc/hosts</filename></title>
+
+<para>
+Contains a static list of IP Addresses and names.
+eg:
+</para>
+<para><programlisting>
+ 127.0.0.1 localhost localhost.localdomain
+ 192.168.1.1 bigbox.caldera.com bigbox alias4box
+</programlisting></para>
+
+<para>
+The purpose of <filename>/etc/hosts</filename> is to provide a
+name resolution mechanism so that uses do not need to remember
+IP addresses.
+</para>
+
+
+<para>
+Network packets that are sent over the physical network transport
+layer communicate not via IP addresses but rather using the Media
+Access Control address, or MAC address. IP Addresses are currently
+32 bits in length and are typically presented as four (4) decimal
+numbers that are separated by a dot (or period). eg: 168.192.1.1
+</para>
+
+<para>
+MAC Addresses use 48 bits (or 6 bytes) and are typically represented
+as two digit hexadecimal numbers separated by colons. eg:
+40:8e:0a:12:34:56
+</para>
+
+<para>
+Every network interfrace must have an MAC address. Associated with
+a MAC address there may be one or more IP addresses. There is NO
+relationship between an IP address and a MAC address, all such assignments
+are arbitary or discretionary in nature. At the most basic level all
+network communications takes place using MAC addressing. Since MAC
+addresses must be globally unique, and generally remains fixed for
+any particular interface, the assignment of an IP address makes sense
+from a network management perspective. More than one IP address can
+be assigned per MAC address. One address must be the primary IP address,
+this is the address that will be returned in the ARP reply.
+</para>
+
+<para>
+When a user or a process wants to communicate with another machine
+the protocol implementation ensures that the "machine name" or "host
+name" is resolved to an IP address in a manner that is controlled
+by the TCP/IP configuration control files. The file
+<filename>/etc/hosts</filename> is one such file.
+</para>
+
+<para>
+When the IP address of the destination interface has been
+determined a protocol called ARP/RARP isused to identify
+the MAC address of the target interface. ARP stands for Address
+Resolution Protocol, and is a broadcast oriented method that
+uses UDP (User Datagram Protocol) to send a request to all
+interfaces on the local network segment using the all 1's MAC
+address. Network interfaces are programmed to respond to two
+MAC addresses only; their own unique address and the address
+ff:ff:ff:ff:ff:ff. The reply packet from an ARP request will
+contain the MAC address and the primary IP address for each
+interface.
+</para>
+
+<para>
+The <filename>/etc/hosts</filename> file is foundational to all
+Unix/Linux TCP/IP installations and as a minumum will contain
+the localhost and local network interface IP addresses and the
+primary names by which they are known within the local machine.
+This file helps to prime the pump so that a basic level of name
+resolution can exist before any other method of name resolution
+becomes available.
+</para>
+
+</sect2>
+
+
+<sect2>
+<title><filename>/etc/resolv.conf</filename></title>
+
+<para>
+This file tells the name resolution libraries:
+</para>
+
+<itemizedlist>
+ <listitem><para>The name of the domain to which the machine
+ belongs
+ </para></listitem>
+
+ <listitem><para>The name(s) of any domains that should be
+ automatically searched when trying to resolve unqualified
+ host names to their IP address
+ </para></listitem>
+
+ <listitem><para>The name or IP address of available Domain
+ Name Servers that may be asked to perform name to address
+ translation lookups
+ </para></listitem>
+</itemizedlist>
+
+</sect2>
+
+
+<sect2>
+<title><filename>/etc/host.conf</filename></title>
+
+
+<para>
+<filename>/etc/host.conf</filename> is the primary means by
+which the setting in /etc/resolv.conf may be affected. It is a
+critical configuration file. This file controls the order by
+which name resolution may procede. The typical structure is:
+</para>
+
+<para><programlisting>
+ order hosts,bind
+ multi on
+</programlisting></para>
+
+<para>
+then both addresses should be returned. Please refer to the
+man page for host.conf for further details.
+</para>
+
+
+</sect2>
+
+
+
+<sect2>
+<title><filename>/etc/nsswitch.conf</filename></title>
+
+<para>
+This file controls the actual name resolution targets. The
+file typically has resolver object specifications as follows:
+</para>
+
+
+<para><programlisting>
+ # /etc/nsswitch.conf
+ #
+ # Name Service Switch configuration file.
+ #
+
+ passwd: compat
+ # Alternative entries for password authentication are:
+ # passwd: compat files nis ldap winbind
+ shadow: compat
+ group: compat
+
+ hosts: files nis dns
+ # Alternative entries for host name resolution are:
+ # hosts: files dns nis nis+ hesoid db compat ldap wins
+ networks: nis files dns
+
+ ethers: nis files
+ protocols: nis files
+ rpc: nis files
+ services: nis files
+</programlisting></para>
+
+<para>
+Of course, each of these mechanisms requires that the appropriate
+facilities and/or services are correctly configured.
+</para>
+
+<para>
+It should be noted that unless a network request/message must be
+sent, TCP/IP networks are silent. All TCP/IP communications assumes a
+principal of speaking only when necessary.
+</para>
+
+<para>
+Samba version 2.2.0 will add Linux support for extensions to
+the name service switch infrastructure so that linux clients will
+be able to obtain resolution of MS Windows NetBIOS names to IP
+Addresses. To gain this functionality Samba needs to be compiled
+with appropriate arguments to the make command (ie: <command>make
+nsswitch/libnss_wins.so</command>). The resulting library should
+then be installed in the <filename>/lib</filename> directory and
+the "wins" parameter needs to be added to the "hosts:" line in
+the <filename>/etc/nsswitch.conf</filename> file. At this point it
+will be possible to ping any MS Windows machine by it's NetBIOS
+machine name, so long as that machine is within the workgroup to
+which both the samba machine and the MS Windows machine belong.
+</para>
+
+</sect2>
+</sect1>
+
+
+<sect1>
+<title>Name resolution as used within MS Windows networking</title>
+
+<para>
+MS Windows networking is predicated about the name each machine
+is given. This name is known variously (and inconsistently) as
+the "computer name", "machine name", "networking name", "netbios name",
+"SMB name". All terms mean the same thing with the exception of
+"netbios name" which can apply also to the name of the workgroup or the
+domain name. The terms "workgroup" and "domain" are really just a
+simply name with which the machine is associated. All NetBIOS names
+are exactly 16 characters in length. The 16th character is reserved.
+It is used to store a one byte value that indicates service level
+information for the NetBIOS name that is registered. A NetBIOS machine
+name is therefore registered for each service type that is provided by
+the client/server.
+</para>
+
+<para>
+The following are typical NetBIOS name/service type registrations:
+</para>
+
+<para><programlisting>
+ Unique NetBIOS Names:
+ MACHINENAME<00> = Server Service is running on MACHINENAME
+ MACHINENAME<03> = Generic Machine Name (NetBIOS name)
+ MACHINENAME<20> = LanMan Server service is running on MACHINENAME
+ WORKGROUP<1b> = Domain Master Browser
+
+ Group Names:
+ WORKGROUP<03> = Generic Name registered by all members of WORKGROUP
+ WORKGROUP<1c> = Domain Controllers / Netlogon Servers
+ WORKGROUP<1d> = Local Master Browsers
+ WORKGROUP<1e> = Internet Name Resolvers
+</programlisting></para>
+
+<para>
+It should be noted that all NetBIOS machines register their own
+names as per the above. This is in vast contrast to TCP/IP
+installations where traditionally the system administrator will
+determine in the /etc/hosts or in the DNS database what names
+are associated with each IP address.
+</para>
+
+<para>
+One further point of clarification should be noted, the <filename>/etc/hosts</filename>
+file and the DNS records do not provide the NetBIOS name type information
+that MS Windows clients depend on to locate the type of service that may
+be needed. An example of this is what happens when an MS Windows client
+wants to locate a domain logon server. It find this service and the IP
+address of a server that provides it by performing a lookup (via a
+NetBIOS broadcast) for enumeration of all machines that have
+registered the name type *<1c>. A logon request is then sent to each
+IP address that is returned in the enumerated list of IP addresses. Which
+ever machine first replies then ends up providing the logon services.
+</para>
+
+<para>
+The name "workgroup" or "domain" really can be confusing since these
+have the added significance of indicating what is the security
+architecture of the MS Windows network. The term "workgroup" indicates
+that the primary nature of the network environment is that of a
+peer-to-peer design. In a WORKGROUP all machines are responsible for
+their own security, and generally such security is limited to use of
+just a password (known as SHARE MORE security). In most situations
+with peer-to-peer networking the users who control their own machines
+will simply opt to have no security at all. It is possible to have
+USER MODE security in a WORKGROUP environment, thus requiring use
+of a user name and a matching password.
+</para>
+
+<para>
+MS Windows networking is thus predetermined to use machine names
+for all local and remote machine message passing. The protocol used is
+called Server Message Block (SMB) and this is implemented using
+the NetBIOS protocol (Network Basic Input Output System). NetBIOS can
+be encapsulated using LLC (Logical Link Control) protocol - in which case
+the resulting protocol is called NetBEUI (Network Basic Extended User
+Interface). NetBIOS can also be run over IPX (Internetworking Packet
+Exchange) protocol as used by Novell NetWare, and it can be run
+over TCP/IP protocols - in which case the resulting protocol is called
+NBT or NetBT, the NetBIOS over TCP/IP.
+</para>
+
+<para>
+MS Windows machines use a complex array of name resolution mechanisms.
+Since we are primarily concerned with TCP/IP this demonstration is
+limited to this area.
+</para>
+
+<sect2>
+<title>The NetBIOS Name Cache</title>
+
+<para>
+All MS Windows machines employ an in memory buffer in which is
+stored the NetBIOS names and their IP addresses for all external
+machines that that the local machine has communicated with over the
+past 10-15 minutes. It is more efficient to obtain an IP address
+for a machine from the local cache than it is to go through all the
+configured name resolution mechanisms.
+</para>
+
+<para>
+If a machine whose name is in the local name cache has been shut
+down before the name had been expired and flushed from the cache, then
+an attempt to exchange a message with that machine will be subject
+to time-out delays. ie: It's name is in the cache, so a name resolution
+lookup will succeed, but the machine can not respond. This can be
+frustrating for users - but it is a characteristic of the protocol.
+</para>
+
+<para>
+The MS Windows utility that allows examination of the NetBIOS
+name cache is called "nbtstat". The Samba equivalent of this
+is called "nmblookup".
+</para>
+
+</sect2>
+
+<sect2>
+<title>The LMHOSTS file</title>
+
+<para>
+This file is usually located in MS Windows NT 4.0 or
+2000 in <filename>C:\WINNT\SYSTEM32\DRIVERS\ETC</filename> and contains
+the IP Address and the machine name in matched pairs. The
+<filename>LMHOSTS</filename> file performs NetBIOS name
+to IP address mapping oriented.
+</para>
+
+<para>
+It typically looks like:
+</para>
+
+<para><programlisting>
+ # Copyright (c) 1998 Microsoft Corp.
+ #
+ # This is a sample LMHOSTS file used by the Microsoft Wins Client (NetBIOS
+ # over TCP/IP) stack for Windows98
+ #
+ # This file contains the mappings of IP addresses to NT computernames
+ # (NetBIOS) names. Each entry should be kept on an individual line.
+ # The IP address should be placed in the first column followed by the
+ # corresponding computername. The address and the comptername
+ # should be separated by at least one space or tab. The "#" character
+ # is generally used to denote the start of a comment (see the exceptions
+ # below).
+ #
+ # This file is compatible with Microsoft LAN Manager 2.x TCP/IP lmhosts
+ # files and offers the following extensions:
+ #
+ # #PRE
+ # #DOM:&lt;domain&gt;
+ # #INCLUDE &lt;filename&gt;
+ # #BEGIN_ALTERNATE
+ # #END_ALTERNATE
+ # \0xnn (non-printing character support)
+ #
+ # Following any entry in the file with the characters "#PRE" will cause
+ # the entry to be preloaded into the name cache. By default, entries are
+ # not preloaded, but are parsed only after dynamic name resolution fails.
+ #
+ # Following an entry with the "#DOM:&lt;domain&gt;" tag will associate the
+ # entry with the domain specified by &lt;domain&gt;. This affects how the
+ # browser and logon services behave in TCP/IP environments. To preload
+ # the host name associated with #DOM entry, it is necessary to also add a
+ # #PRE to the line. The &lt;domain&gt; is always preloaded although it will not
+ # be shown when the name cache is viewed.
+ #
+ # Specifying "#INCLUDE &lt;filename&gt;" will force the RFC NetBIOS (NBT)
+ # software to seek the specified &lt;filename&gt; and parse it as if it were
+ # local. &lt;filename&gt; is generally a UNC-based name, allowing a
+ # centralized lmhosts file to be maintained on a server.
+ # It is ALWAYS necessary to provide a mapping for the IP address of the
+ # server prior to the #INCLUDE. This mapping must use the #PRE directive.
+ # In addtion the share "public" in the example below must be in the
+ # LanManServer list of "NullSessionShares" in order for client machines to
+ # be able to read the lmhosts file successfully. This key is under
+ # \machine\system\currentcontrolset\services\lanmanserver\parameters\nullsessionshares
+ # in the registry. Simply add "public" to the list found there.
+ #
+ # The #BEGIN_ and #END_ALTERNATE keywords allow multiple #INCLUDE
+ # statements to be grouped together. Any single successful include
+ # will cause the group to succeed.
+ #
+ # Finally, non-printing characters can be embedded in mappings by
+ # first surrounding the NetBIOS name in quotations, then using the
+ # \0xnn notation to specify a hex value for a non-printing character.
+ #
+ # The following example illustrates all of these extensions:
+ #
+ # 102.54.94.97 rhino #PRE #DOM:networking #net group's DC
+ # 102.54.94.102 "appname \0x14" #special app server
+ # 102.54.94.123 popular #PRE #source server
+ # 102.54.94.117 localsrv #PRE #needed for the include
+ #
+ # #BEGIN_ALTERNATE
+ # #INCLUDE \\localsrv\public\lmhosts
+ # #INCLUDE \\rhino\public\lmhosts
+ # #END_ALTERNATE
+ #
+ # In the above example, the "appname" server contains a special
+ # character in its name, the "popular" and "localsrv" server names are
+ # preloaded, and the "rhino" server name is specified so it can be used
+ # to later #INCLUDE a centrally maintained lmhosts file if the "localsrv"
+ # system is unavailable.
+ #
+ # Note that the whole file is parsed including comments on each lookup,
+ # so keeping the number of comments to a minimum will improve performance.
+ # Therefore it is not advisable to simply add lmhosts file entries onto the
+ # end of this file.
+</programlisting></para>
+
+</sect2>
+
+<sect2>
+<title>HOSTS file</title>
+
+<para>
+This file is usually located in MS Windows NT 4.0 or 2000 in
+<filename>C:\WINNT\SYSTEM32\DRIVERS\ETC</filename> and contains
+the IP Address and the IP hostname in matched pairs. It can be
+used by the name resolution infrastructure in MS Windows, depending
+on how the TCP/IP environment is configured. This file is in
+every way the equivalent of the Unix/Linux <filename>/etc/hosts</filename> file.
+</para>
+</sect2>
+
+
+<sect2>
+<title>DNS Lookup</title>
+
+<para>
+This capability is configured in the TCP/IP setup area in the network
+configuration facility. If enabled an elaborate name resolution sequence
+is followed the precise nature of which isdependant on what the NetBIOS
+Node Type parameter is configured to. A Node Type of 0 means use
+NetBIOS broadcast (over UDP broadcast) is first used if the name
+that is the subject of a name lookup is not found in the NetBIOS name
+cache. If that fails then DNS, HOSTS and LMHOSTS are checked. If set to
+Node Type 8, then a NetBIOS Unicast (over UDP Unicast) is sent to the
+WINS Server to obtain a lookup before DNS, HOSTS, LMHOSTS, or broadcast
+lookup is used.
+</para>
+
+</sect2>
+
+<sect2>
+<title>WINS Lookup</title>
+
+<para>
+A WINS (Windows Internet Name Server) service is the equivaent of the
+rfc1001/1002 specified NBNS (NetBIOS Name Server). A WINS server stores
+the names and IP addresses that are registered by a Windows client
+if the TCP/IP setup has been given at least one WINS Server IP Address.
+</para>
+
+<para>
+To configure Samba to be a WINS server the following parameter needs
+to be added to the <filename>smb.conf</filename> file:
+</para>
+
+<para><programlisting>
+ wins support = Yes
+</programlisting></para>
+
+<para>
+To configure Samba to use a WINS server the following parameters are
+needed in the smb.conf file:
+</para>
+
+<para><programlisting>
+ wins support = No
+ wins server = xxx.xxx.xxx.xxx
+</programlisting></para>
+
+<para>
+where <replaceable>xxx.xxx.xxx.xxx</replaceable> is the IP address
+of the WINS server.
+</para>
+
+</sect2>
+</sect1>
+
+
+<sect1>
+<title>How browsing functions and how to deploy stable and
+dependable browsing using Samba</title>
+
+
+<para>
+As stated above, MS Windows machines register their NetBIOS names
+(ie: the machine name for each service type in operation) on start
+up. Also, as stated above, the exact method by which this name registration
+takes place is determined by whether or not the MS Windows client/server
+has been given a WINS server address, whether or not LMHOSTS lookup
+is enabled, or if DNS for NetBIOS name resolution is enabled, etc.
+</para>
+
+<para>
+In the case where there is no WINS server all name registrations as
+well as name lookups are done by UDP broadcast. This isolates name
+resolution to the local subnet, unless LMHOSTS is used to list all
+names and IP addresses. In such situations Samba provides a means by
+which the samba server name may be forcibly injected into the browse
+list of a remote MS Windows network (using the "remote announce" parameter).
+</para>
+
+<para>
+Where a WINS server is used, the MS Windows client will use UDP
+unicast to register with the WINS server. Such packets can be routed
+and thus WINS allows name resolution to function across routed networks.
+</para>
+
+<para>
+During the startup process an election will take place to create a
+local master browser if one does not already exist. On each NetBIOS network
+one machine will be elected to function as the domain master browser. This
+domain browsing has nothing to do with MS security domain control.
+Instead, the domain master browser serves the role of contacting each local
+master browser (found by asking WINS or from LMHOSTS) and exchanging browse
+list contents. This way every master browser will eventually obtain a complete
+list of all machines that are on the network. Every 11-15 minutes an election
+is held to determine which machine will be the master browser. By nature of
+the election criteria used, the machine with the highest uptime, or the
+most senior protocol version, or other criteria, will win the election
+as domain master browser.
+</para>
+
+<para>
+Clients wishing to browse the network make use of this list, but also depend
+on the availability of correct name resolution to the respective IP
+address/addresses.
+</para>
+
+<para>
+Any configuration that breaks name resolution and/or browsing intrinsics
+will annoy users because they will have to put up with protracted
+inability to use the network services.
+</para>
+
+<para>
+Samba supports a feature that allows forced synchonisation
+of browse lists across routed networks using the "remote
+browse sync" parameter in the smb.conf file. This causes Samba
+to contact the local master browser on a remote network and
+to request browse list synchronisation. This effectively bridges
+two networks that are separated by routers. The two remote
+networks may use either broadcast based name resolution or WINS
+based name resolution, but it should be noted that the "remote
+browse sync" parameter provides browse list synchronisation - and
+that is distinct from name to address resolution, in other
+words, for cross subnet browsing to function correctly it is
+essential that a name to address resolution mechanism be provided.
+This mechanism could be via DNS, <filename>/etc/hosts</filename>,
+and so on.
+</para>
+
+</sect1>
+
+<sect1>
+<title>MS Windows security options and how to configure
+Samba for seemless integration</title>
+
+<para>
+MS Windows clients may use encrypted passwords as part of a
+challenege/response authentication model (a.k.a. NTLMv1) or
+alone, or clear text strings for simple password based
+authentication. It should be realized that with the SMB
+protocol the password is passed over the network either
+in plain text or encrypted, but not both in the same
+authentication requets.
+</para>
+
+<para>
+When encrypted passwords are used a password that has been
+entered by the user is encrypted in two ways:
+</para>
+
+<itemizedlist>
+ <listitem><para>An MD4 hash of the UNICODE of the password
+ string. This is known as the NT hash.
+ </para></listitem>
+
+ <listitem><para>The password is converted to upper case,
+ and then padded or trucated to 14 bytes. This string is
+ then appended with 5 bytes of NULL characters and split to
+ form two 56 bit DES keys to encrypt a "magic" 8 byte value.
+ The resulting 16 bytes for the LanMan hash.
+ </para></listitem>
+</itemizedlist>
+
+<para>
+You should refer to the <ulink url="ENCRYPTION.html">
+Password Encryption</ulink> chapter in this HOWTO collection
+for more details on the inner workings
+</para>
+
+<para>
+MS Windows 95 pre-service pack 1, MS Windows NT versions 3.x
+and version 4.0 pre-service pack 3 will use either mode of
+password authentication. All versions of MS Windows that follow
+these versions no longer support plain text passwords by default.
+</para>
+
+<para>
+MS Windows clients have a habit of dropping network mappings that
+have been idle for 10 minutes or longer. When the user attempts to
+use the mapped drive connection that has been dropped the SMB protocol
+has a mechanism by which the connection can be re-established using
+a cached copy of the password.
+</para>
+
+<para>
+When Microsoft changed the default password mode, they dropped support for
+caching of the plain text password. This means that when the registry
+parameter is changed to re-enable use of plain text passwords it appears to
+work, but when a dropped mapping attempts to revalidate it will fail if
+the remote authentication server does not support encrypted passwords.
+This means that it is definitely not a good idea to re-enable plain text
+password support in such clients.
+</para>
+
+<para>
+The following parameters can be used to work around the
+issue of Windows 9x client upper casing usernames and
+password before transmitting them to the SMB server
+when using clear text authentication.
+</para>
+
+<para><programlisting>
+ <ulink url="smb.conf.5.html#PASSWORDLEVEL">passsword level</ulink> = <replaceable>integer</replaceable>
+ <ulink url="smb.conf.5.html#USERNAMELEVEL">username level</ulink> = <replaceable>integer</replaceable>
+</programlisting></para>
+
+<para>
+By default Samba will lower case the username before attempting
+to lookup the user in the database of local system accounts.
+Because UNIX usernames conventionally only contain lower case
+character, the <parameter>username level</parameter> parameter
+is rarely even needed.
+</para>
+
+<para>
+However, password on UNIX systems often make use of mixed case
+characters. This means that in order for a user on a Windows 9x
+client to connect to a Samba server using clear text authentication,
+the <parameter>password level</parameter> must be set to the maximum
+number of upper case letter which <emphasis>could</emphasis> appear
+is a password. Note that is the server OS uses the traditional
+DES version of crypt(), then a <parameter>password level</parameter>
+of 8 will result in case insensitive passwords as seen from Windows
+users. This will also result in longer login times as Samba
+hash to compute the permutations of the password string and
+try them one by one until a match is located (or all combinations fail).
+</para>
+
+<para>
+The best option to adopt is to enable support for encrypted passwords
+where ever Samba is used. There are three configuration possibilities
+for support of encrypted passwords:
+</para>
+
+
+<sect2>
+<title>Use MS Windows NT as an authentication server</title>
+
+<para>
+This method involves the additions of the following parameters
+in the smb.conf file:
+</para>
+
+<para><programlisting>
+ encrypt passwords = Yes
+ security = server
+ password server = "NetBIOS_name_of_PDC"
+</programlisting></para>
+
+
+<para>
+There are two ways of identifying whether or not a username and
+password pair was valid or not. One uses the reply information provided
+as part of the authentication messaging process, the other uses
+just and error code.
+</para>
+
+<para>
+The down-side of this mode of configuration is the fact that
+for security reasons Samba will send the password server a bogus
+username and a bogus password and if the remote server fails to
+reject the username and password pair then an alternative mode
+of identification of validation is used. Where a site uses password
+lock out after a certain number of failed authentication attempts
+this will result in user lockouts.
+</para>
+
+<para>
+Use of this mode of authentication does require there to be
+a standard Unix account for the user, this account can be blocked
+to prevent logons by other than MS Windows clients.
+</para>
+
+</sect2>
+
+<sect2>
+<title>Make Samba a member of an MS Windows NT security domain</title>
+
+<para>
+This method involves additon of the following paramters in the smb.conf file:
+</para>
+
+<para><programlisting>
+ encrypt passwords = Yes
+ security = domain
+ workgroup = "name of NT domain"
+ password server = *
+</programlisting></para>
+
+<para>
+The use of the "*" argument to "password server" will cause samba
+to locate the domain controller in a way analogous to the way
+this is done within MS Windows NT.
+</para>
+
+<para>
+In order for this method to work the Samba server needs to join the
+MS Windows NT security domain. This is done as follows:
+</para>
+
+<itemizedlist>
+ <listitem><para>On the MS Windows NT domain controller using
+ the Server Manager add a machine account for the Samba server.
+ </para></listitem>
+
+ <listitem><para>Next, on the Linux system execute:
+ <command>smbpasswd -r PDC_NAME -j DOMAIN_NAME</command>
+ </para></listitem>
+</itemizedlist>
+
+<para>
+Use of this mode of authentication does require there to be
+a standard Unix account for the user in order to assign
+a uid once the account has been authenticated by the remote
+Windows DC. This account can be blocked to prevent logons by
+other than MS Windows clients by things such as setting an invalid
+shell in the <filename>/etc/passwd</filename> entry.
+</para>
+
+<para>
+An alternative to assigning UIDs to Windows users on a
+Samba member server is presented in the <ulink
+url="winbind.html">Winbind Overview</ulink> chapter in
+this HOWTO collection.
+</para>
+
+
+</sect2>
+
+
+<sect2>
+<title>Configure Samba as an authentication server</title>
+
+<para>
+This mode of authentication demands that there be on the
+Unix/Linux system both a Unix style account as well as and
+smbpasswd entry for the user. The Unix system account can be
+locked if required as only the encrypted password will be
+used for SMB client authentication.
+</para>
+
+<para>
+This method involves addition of the following parameters to
+the smb.conf file:
+</para>
+
+<para><programlisting>
+## please refer to the Samba PDC HOWTO chapter later in
+## this collection for more details
+[global]
+ encrypt passwords = Yes
+ security = user
+ domain logons = Yes
+ ; an OS level of 33 or more is recommended
+ os level = 33
+
+[NETLOGON]
+ path = /somewhare/in/file/system
+ read only = yes
+</programlisting></para>
+
+<para>
+in order for this method to work a Unix system account needs
+to be created for each user, as well as for each MS Windows NT/2000
+machine. The following structure is required.
+</para>
+
+<sect3>
+<title>Users</title>
+
+<para>
+A user account that may provide a home directory should be
+created. The following Linux system commands are typical of
+the procedure for creating an account.
+</para>
+
+<para><programlisting>
+ # useradd -s /bin/bash -d /home/"userid" -m "userid"
+ # passwd "userid"
+ Enter Password: &lt;pw&gt;
+
+ # smbpasswd -a "userid"
+ Enter Password: &lt;pw&gt;
+</programlisting></para>
+</sect3>
+
+<sect3>
+<title>MS Windows NT Machine Accounts</title>
+
+<para>
+These are required only when Samba is used as a domain
+controller. Refer to the Samba-PDC-HOWTO for more details.
+</para>
+
+<para><programlisting>
+ # useradd -s /bin/false -d /dev/null "machine_name"\$
+ # passwd -l "machine_name"\$
+ # smbpasswd -a -m "machine_name"
+</programlisting></para>
+</sect3>
+</sect2>
+</sect1>
+
+
+<sect1>
+<title>Conclusions</title>
+
+<para>
+Samba provides a flexible means to operate as...
+</para>
+
+<itemizedlist>
+ <listitem><para>A Stand-alone server - No special action is needed
+ other than to create user accounts. Stand-alone servers do NOT
+ provide network logon services, meaning that machines that use this
+ server do NOT perform a domain logon but instead make use only of
+ the MS Windows logon which is local to the MS Windows
+ workstation/server.
+ </para></listitem>
+
+ <listitem><para>An MS Windows NT 3.x/4.0 security domain member.
+ </para></listitem>
+
+
+ <listitem><para>An alternative to an MS Windows NT 3.x/4.0
+ Domain Controller.
+ </para></listitem>
+
+</itemizedlist>
+
+</sect1>
+
+</chapter>