Regenerate docs

(This used to be commit 20ee66b661e295cc9fb66f00b16de3b382a7e723)
author: Jelmer Vernooij <jelmer@samba.org> 2003-04-02 18:07:52 +0000
committer: Jelmer Vernooij <jelmer@samba.org> 2003-04-02 18:07:52 +0000
commit: d00b6f125fd98d1842cba57c7b509d52470c82d7 (patch)
tree: 3ba63acf2addf1e8fec8e41cd33f2b66f93d06b9 /docs/htmldocs/integrate-ms-networks.html
parent: 4f59ed8e91a749b84b21187f6c65180ada2b13f4 (diff)
download: samba-d00b6f125fd98d1842cba57c7b509d52470c82d7.tar.gz
samba-d00b6f125fd98d1842cba57c7b509d52470c82d7.tar.bz2
samba-d00b6f125fd98d1842cba57c7b509d52470c82d7.zip
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
author	Jelmer Vernooij <jelmer@samba.org>	2003-04-02 18:07:52 +0000
committer	Jelmer Vernooij <jelmer@samba.org>	2003-04-02 18:07:52 +0000
commit	d00b6f125fd98d1842cba57c7b509d52470c82d7 (patch)
tree	3ba63acf2addf1e8fec8e41cd33f2b66f93d06b9 /docs/htmldocs/integrate-ms-networks.html
parent	4f59ed8e91a749b84b21187f6c65180ada2b13f4 (diff)
download	samba-d00b6f125fd98d1842cba57c7b509d52470c82d7.tar.gz samba-d00b6f125fd98d1842cba57c7b509d52470c82d7.tar.bz2 samba-d00b6f125fd98d1842cba57c7b509d52470c82d7.zip