diff options
Diffstat (limited to 'docs/docbook/projdoc/Integrating-with-Windows.sgml')
| -rw-r--r-- | docs/docbook/projdoc/Integrating-with-Windows.sgml | 443 |
1 files changed, 411 insertions, 32 deletions
diff --git a/docs/docbook/projdoc/Integrating-with-Windows.sgml b/docs/docbook/projdoc/Integrating-with-Windows.sgml index 8a5c0c40f2..a4e79fd42b 100644 --- a/docs/docbook/projdoc/Integrating-with-Windows.sgml +++ b/docs/docbook/projdoc/Integrating-with-Windows.sgml @@ -18,46 +18,48 @@ <title>Integrating MS Windows networks with Samba</title> -<para> -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> +<sect1> +<title>Agenda</title> -<note> <para> - 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. +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> -</note> <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. +We will examine: </para> -<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> +<orderedlist> + <listitem><para>Name resolution in a pure Unix/Linux TCP/IP + environment + </para></listitem> -<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> + <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> @@ -553,4 +555,381 @@ 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: <pw> + + # smbpasswd -a "userid" + Enter Password: <pw> +</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> |