summaryrefslogtreecommitdiff
path: root/docs/htmldocs/integrate-ms-networks.html
diff options
context:
space:
mode:
Diffstat (limited to 'docs/htmldocs/integrate-ms-networks.html')
-rw-r--r--docs/htmldocs/integrate-ms-networks.html602
1 files changed, 100 insertions, 502 deletions
diff --git a/docs/htmldocs/integrate-ms-networks.html b/docs/htmldocs/integrate-ms-networks.html
index 984f849f71..433fb5b50d 100644
--- a/docs/htmldocs/integrate-ms-networks.html
+++ b/docs/htmldocs/integrate-ms-networks.html
@@ -10,14 +10,14 @@ REL="HOME"
TITLE="SAMBA Project Documentation"
HREF="samba-howto-collection.html"><LINK
REL="UP"
-TITLE="Optional configuration"
+TITLE="Advanced Configuration"
HREF="optional.html"><LINK
REL="PREVIOUS"
-TITLE="Optional configuration"
-HREF="optional.html"><LINK
+TITLE="Unified Logons between Windows NT and UNIX using Winbind"
+HREF="winbind.html"><LINK
REL="NEXT"
-TITLE="UNIX Permission Bits and Windows NT Access Control Lists"
-HREF="unix-permissions.html"></HEAD
+TITLE="Improved browsing in samba"
+HREF="improved-browsing.html"></HEAD
><BODY
CLASS="CHAPTER"
BGCOLOR="#FFFFFF"
@@ -45,7 +45,7 @@ WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
-HREF="optional.html"
+HREF="winbind.html"
ACCESSKEY="P"
>Prev</A
></TD
@@ -59,7 +59,7 @@ WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
-HREF="unix-permissions.html"
+HREF="improved-browsing.html"
ACCESSKEY="N"
>Next</A
></TD
@@ -74,81 +74,89 @@ CLASS="CHAPTER"
><A
NAME="INTEGRATE-MS-NETWORKS"
></A
->Chapter 10. Integrating MS Windows networks with Samba</H1
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="AEN1517"
->10.1. Agenda</A
-></H1
+>Chapter 17. Integrating MS Windows networks with Samba</H1
><P
->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.</P
-><P
->We will examine:</P
+>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.</P
+><DIV
+CLASS="NOTE"
><P
></P
-><OL
-TYPE="1"
-><LI
-><P
->Name resolution in a pure Unix/Linux TCP/IP
- environment
- </P
-></LI
-><LI
-><P
->Name resolution as used within MS Windows
- networking
- </P
-></LI
-><LI
-><P
->How browsing functions and how to deploy stable
- and dependable browsing using Samba
- </P
-></LI
-><LI
+><TABLE
+CLASS="NOTE"
+WIDTH="100%"
+BORDER="0"
+><TR
+><TD
+WIDTH="25"
+ALIGN="CENTER"
+VALIGN="TOP"
+><IMG
+SRC="/usr/share/sgml/docbook/stylesheet/dsssl/modular/images/note.gif"
+HSPACE="5"
+ALT="Note"></TD
+><TD
+ALIGN="LEFT"
+VALIGN="TOP"
><P
->MS Windows security options and how to
- configure Samba for seemless integration
- </P
-></LI
-><LI
+> 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.</P
+></TD
+></TR
+></TABLE
+></DIV
><P
->Configuration of Samba as:</P
+>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.</P
+><DIV
+CLASS="NOTE"
><P
></P
-><OL
-TYPE="a"
-><LI
-><P
->A stand-alone server</P
-></LI
-><LI
-><P
->An MS Windows NT 3.x/4.0 security domain member
- </P
-></LI
-><LI
+><TABLE
+CLASS="NOTE"
+WIDTH="100%"
+BORDER="0"
+><TR
+><TD
+WIDTH="25"
+ALIGN="CENTER"
+VALIGN="TOP"
+><IMG
+SRC="/usr/share/sgml/docbook/stylesheet/dsssl/modular/images/note.gif"
+HSPACE="5"
+ALT="Note"></TD
+><TD
+ALIGN="LEFT"
+VALIGN="TOP"
><P
->An alternative to an MS Windows NT 3.x/4.0 Domain Controller
- </P
-></LI
-></OL
-></LI
-></OL
+>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).</P
+></TD
+></TR
+></TABLE
></DIV
+><P
+>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.</P
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
-NAME="AEN1539"
->10.2. Name Resolution in a pure Unix/Linux world</A
+NAME="AEN2932"
+>17.1. Name Resolution in a pure Unix/Linux world</A
></H1
><P
>The key configuration files covered in this section are:</P
@@ -189,8 +197,8 @@ CLASS="SECT2"
><H2
CLASS="SECT2"
><A
-NAME="AEN1555"
->10.2.1. <TT
+NAME="AEN2948"
+>17.1.1. <TT
CLASS="FILENAME"
>/etc/hosts</TT
></A
@@ -270,8 +278,8 @@ CLASS="SECT2"
><H2
CLASS="SECT2"
><A
-NAME="AEN1571"
->10.2.2. <TT
+NAME="AEN2964"
+>17.1.2. <TT
CLASS="FILENAME"
>/etc/resolv.conf</TT
></A
@@ -308,8 +316,8 @@ CLASS="SECT2"
><H2
CLASS="SECT2"
><A
-NAME="AEN1582"
->10.2.3. <TT
+NAME="AEN2975"
+>17.1.3. <TT
CLASS="FILENAME"
>/etc/host.conf</TT
></A
@@ -337,8 +345,8 @@ CLASS="SECT2"
><H2
CLASS="SECT2"
><A
-NAME="AEN1590"
->10.2.4. <TT
+NAME="AEN2983"
+>17.1.4. <TT
CLASS="FILENAME"
>/etc/nsswitch.conf</TT
></A
@@ -406,8 +414,8 @@ CLASS="SECT1"
><H1
CLASS="SECT1"
><A
-NAME="AEN1602"
->10.3. Name resolution as used within MS Windows networking</A
+NAME="AEN2995"
+>17.2. Name resolution as used within MS Windows networking</A
></H1
><P
>MS Windows networking is predicated about the name each machine
@@ -491,8 +499,8 @@ CLASS="SECT2"
><H2
CLASS="SECT2"
><A
-NAME="AEN1614"
->10.3.1. The NetBIOS Name Cache</A
+NAME="AEN3007"
+>17.2.1. The NetBIOS Name Cache</A
></H2
><P
>All MS Windows machines employ an in memory buffer in which is
@@ -518,8 +526,8 @@ CLASS="SECT2"
><H2
CLASS="SECT2"
><A
-NAME="AEN1619"
->10.3.2. The LMHOSTS file</A
+NAME="AEN3012"
+>17.2.2. The LMHOSTS file</A
></H2
><P
>This file is usually located in MS Windows NT 4.0 or
@@ -621,8 +629,8 @@ CLASS="SECT2"
><H2
CLASS="SECT2"
><A
-NAME="AEN1627"
->10.3.3. HOSTS file</A
+NAME="AEN3020"
+>17.2.3. HOSTS file</A
></H2
><P
>This file is usually located in MS Windows NT 4.0 or 2000 in
@@ -643,8 +651,8 @@ CLASS="SECT2"
><H2
CLASS="SECT2"
><A
-NAME="AEN1632"
->10.3.4. DNS Lookup</A
+NAME="AEN3025"
+>17.2.4. DNS Lookup</A
></H2
><P
>This capability is configured in the TCP/IP setup area in the network
@@ -663,8 +671,8 @@ CLASS="SECT2"
><H2
CLASS="SECT2"
><A
-NAME="AEN1635"
->10.3.5. WINS Lookup</A
+NAME="AEN3028"
+>17.2.5. WINS Lookup</A
></H2
><P
>A WINS (Windows Internet Name Server) service is the equivaent of the
@@ -699,416 +707,6 @@ CLASS="REPLACEABLE"
of the WINS server.</P
></DIV
></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="AEN1647"
->10.4. How browsing functions and how to deploy stable and
-dependable browsing using Samba</A
-></H1
-><P
->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.</P
-><P
->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).</P
-><P
->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.</P
-><P
->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.</P
-><P
->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. </P
-><P
->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.</P
-><P
->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, <TT
-CLASS="FILENAME"
->/etc/hosts</TT
->,
-and so on.</P
-></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="AEN1657"
->10.5. MS Windows security options and how to configure
-Samba for seemless integration</A
-></H1
-><P
->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.</P
-><P
->When encrypted passwords are used a password that has been
-entered by the user is encrypted in two ways:</P
-><P
-></P
-><UL
-><LI
-><P
->An MD4 hash of the UNICODE of the password
- string. This is known as the NT hash.
- </P
-></LI
-><LI
-><P
->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.
- </P
-></LI
-></UL
-><P
->You should refer to the <A
-HREF="ENCRYPTION.html"
-TARGET="_top"
->Password Encryption</A
-> chapter in this HOWTO collection
-for more details on the inner workings</P
-><P
->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.</P
-><P
->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.</P
-><P
->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.</P
-><P
->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.</P
-><P
-><PRE
-CLASS="PROGRAMLISTING"
-> <A
-HREF="smb.conf.5.html#PASSWORDLEVEL"
-TARGET="_top"
->passsword level</A
-> = <VAR
-CLASS="REPLACEABLE"
->integer</VAR
->
- <A
-HREF="smb.conf.5.html#USERNAMELEVEL"
-TARGET="_top"
->username level</A
-> = <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-></PRE
-></P
-><P
->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 <VAR
-CLASS="PARAMETER"
->username level</VAR
-> parameter
-is rarely even needed.</P
-><P
->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 <VAR
-CLASS="PARAMETER"
->password level</VAR
-> must be set to the maximum
-number of upper case letter which <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->could</I
-></SPAN
-> appear
-is a password. Note that is the server OS uses the traditional
-DES version of crypt(), then a <VAR
-CLASS="PARAMETER"
->password level</VAR
->
-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).</P
-><P
->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:</P
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN1685"
->10.5.1. Use MS Windows NT as an authentication server</A
-></H2
-><P
->This method involves the additions of the following parameters
-in the smb.conf file:</P
-><P
-><PRE
-CLASS="PROGRAMLISTING"
-> encrypt passwords = Yes
- security = server
- password server = "NetBIOS_name_of_PDC"</PRE
-></P
-><P
->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.</P
-><P
->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.</P
-><P
->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.</P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN1693"
->10.5.2. Make Samba a member of an MS Windows NT security domain</A
-></H2
-><P
->This method involves additon of the following paramters in the smb.conf file:</P
-><P
-><PRE
-CLASS="PROGRAMLISTING"
-> encrypt passwords = Yes
- security = domain
- workgroup = "name of NT domain"
- password server = *</PRE
-></P
-><P
->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.</P
-><P
->In order for this method to work the Samba server needs to join the
-MS Windows NT security domain. This is done as follows:</P
-><P
-></P
-><UL
-><LI
-><P
->On the MS Windows NT domain controller using
- the Server Manager add a machine account for the Samba server.
- </P
-></LI
-><LI
-><P
->Next, on the Linux system execute:
- <B
-CLASS="COMMAND"
->smbpasswd -r PDC_NAME -j DOMAIN_NAME</B
->
- </P
-></LI
-></UL
-><P
->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 <TT
-CLASS="FILENAME"
->/etc/passwd</TT
-> entry.</P
-><P
->An alternative to assigning UIDs to Windows users on a
-Samba member server is presented in the <A
-HREF="winbind.html"
-TARGET="_top"
->Winbind Overview</A
-> chapter in
-this HOWTO collection.</P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN1710"
->10.5.3. Configure Samba as an authentication server</A
-></H2
-><P
->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.</P
-><P
->This method involves addition of the following parameters to
-the smb.conf file:</P
-><P
-><PRE
-CLASS="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</PRE
-></P
-><P
->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.</P
-><DIV
-CLASS="SECT3"
-><H3
-CLASS="SECT3"
-><A
-NAME="AEN1717"
->10.5.3.1. Users</A
-></H3
-><P
->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.</P
-><P
-><PRE
-CLASS="PROGRAMLISTING"
-> # useradd -s /bin/bash -d /home/"userid" -m "userid"
- # passwd "userid"
- Enter Password: &#60;pw&#62;
-
- # smbpasswd -a "userid"
- Enter Password: &#60;pw&#62;</PRE
-></P
-></DIV
-><DIV
-CLASS="SECT3"
-><H3
-CLASS="SECT3"
-><A
-NAME="AEN1722"
->10.5.3.2. MS Windows NT Machine Accounts</A
-></H3
-><P
->These are required only when Samba is used as a domain
-controller. Refer to the Samba-PDC-HOWTO for more details.</P
-><P
-><PRE
-CLASS="PROGRAMLISTING"
-> # useradd -s /bin/false -d /dev/null "machine_name"\$
- # passwd -l "machine_name"\$
- # smbpasswd -a -m "machine_name"</PRE
-></P
-></DIV
-></DIV
-></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="AEN1727"
->10.6. Conclusions</A
-></H1
-><P
->Samba provides a flexible means to operate as...</P
-><P
-></P
-><UL
-><LI
-><P
->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.
- </P
-></LI
-><LI
-><P
->An MS Windows NT 3.x/4.0 security domain member.
- </P
-></LI
-><LI
-><P
->An alternative to an MS Windows NT 3.x/4.0
- Domain Controller.
- </P
-></LI
-></UL
-></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
@@ -1126,7 +724,7 @@ WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
-HREF="optional.html"
+HREF="winbind.html"
ACCESSKEY="P"
>Prev</A
></TD
@@ -1144,7 +742,7 @@ WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
-HREF="unix-permissions.html"
+HREF="improved-browsing.html"
ACCESSKEY="N"
>Next</A
></TD
@@ -1154,7 +752,7 @@ ACCESSKEY="N"
WIDTH="33%"
ALIGN="left"
VALIGN="top"
->Optional configuration</TD
+>Unified Logons between Windows NT and UNIX using Winbind</TD
><TD
WIDTH="34%"
ALIGN="center"
@@ -1168,7 +766,7 @@ ACCESSKEY="U"
WIDTH="33%"
ALIGN="right"
VALIGN="top"
->UNIX Permission Bits and Windows NT Access Control Lists</TD
+>Improved browsing in samba</TD
></TR
></TABLE
></DIV