summaryrefslogtreecommitdiff
path: root/docs/docbook/projdoc/Integrating-with-Windows.sgml
diff options
context:
space:
mode:
authorJohn Terpstra <jht@samba.org>2003-04-02 00:04:36 +0000
committerJohn Terpstra <jht@samba.org>2003-04-02 00:04:36 +0000
commit0dbf84b8666f053bcd1cef8d5389c7cb5ca7cbd6 (patch)
tree2f5ba88f1a5ac9a066f8c9ee51dffacc26b98cdd /docs/docbook/projdoc/Integrating-with-Windows.sgml
parenta4fe384f1d3ba07c4b91c7c5530e862b41355555 (diff)
downloadsamba-0dbf84b8666f053bcd1cef8d5389c7cb5ca7cbd6.tar.gz
samba-0dbf84b8666f053bcd1cef8d5389c7cb5ca7cbd6.tar.bz2
samba-0dbf84b8666f053bcd1cef8d5389c7cb5ca7cbd6.zip
More of the documentation overhaul. More to follow.
(This used to be commit 8333c4709e239a7b8bef6f7a5050a7f8a1ffbe7d)
Diffstat (limited to 'docs/docbook/projdoc/Integrating-with-Windows.sgml')
-rw-r--r--docs/docbook/projdoc/Integrating-with-Windows.sgml443
1 files changed, 32 insertions, 411 deletions
diff --git a/docs/docbook/projdoc/Integrating-with-Windows.sgml b/docs/docbook/projdoc/Integrating-with-Windows.sgml
index a4e79fd42b..8a5c0c40f2 100644
--- a/docs/docbook/projdoc/Integrating-with-Windows.sgml
+++ b/docs/docbook/projdoc/Integrating-with-Windows.sgml
@@ -18,48 +18,46 @@
<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.
+This section deals with NetBIOS over TCP/IP name to IP address resolution. If you
+your MS Windows clients are NOT configured to use NetBIOS over TCP/IP then this
+section does not apply to your installation. If your installation involves use of
+NetBIOS over TCP/IP then this section may help you to resolve networking problems.
</para>
+<note>
<para>
-We will examine:
+ NetBIOS over TCP/IP has nothing to do with NetBEUI. NetBEUI is NetBIOS
+ over Logical Link Control (LLC). On modern networks it is highly advised
+ to NOT run NetBEUI at all. Note also that there is NO such thing as
+ NetBEUI over TCP/IP - the existence of such a protocol is a complete
+ and utter mis-apprehension.
</para>
+</note>
-<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>
+<para>
+Since the introduction of MS Windows 2000 it is possible to run MS Windows networking
+without the use of NetBIOS over TCP/IP. NetBIOS over TCP/IP uses UDP port 137 for NetBIOS
+name resolution and uses TCP port 139 for NetBIOS session services. When NetBIOS over
+TCP/IP is disabled on MS Windows 2000 and later clients then only TCP port 445 will be
+used and UDP port 137 and TCP port 139 will not.
+</para>
- <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>
+<note>
+<para>
+When using Windows 2000 or later clients, if NetBIOS over TCP/IP is NOT disabled, then
+the client will use UDP port 137 (NetBIOS Name Service, also known as the Windows Internet
+Name Service or WINS), TCP port 139 AND TCP port 445 (for actual file and print traffic).
+</para>
+</note>
-</sect1>
+<para>
+When NetBIOS over TCP/IP is disabled the use of DNS is essential. Most installations that
+disable NetBIOS over TCP/IP today use MS Active Directory Service (ADS). ADS requires
+Dynamic DNS with Service Resource Records (SRV RR) and with Incremental Zone Transfers (IXFR).
+Use of DHCP with ADS is recommended as a further means of maintaining central control
+over client workstation network configuration.
+</para>
<sect1>
@@ -555,381 +553,4 @@ of the WINS server.
</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
-(i.e.: 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 the 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 client
-re-establishes the connection 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 an
-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>