diff options
Diffstat (limited to 'docs/htmldocs/integrate-ms-networks.html')
| -rw-r--r-- | docs/htmldocs/integrate-ms-networks.html | 626 |
1 files changed, 498 insertions, 128 deletions
diff --git a/docs/htmldocs/integrate-ms-networks.html b/docs/htmldocs/integrate-ms-networks.html index 5d9e1cdaec..ad6aa9e225 100644 --- a/docs/htmldocs/integrate-ms-networks.html +++ b/docs/htmldocs/integrate-ms-networks.html @@ -5,19 +5,20 @@ >Integrating MS Windows networks with Samba</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK +CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+ +"><LINK REL="HOME" TITLE="SAMBA Project Documentation" HREF="samba-howto-collection.html"><LINK REL="UP" -TITLE="Advanced Configuration" +TITLE="Optional configuration" HREF="optional.html"><LINK REL="PREVIOUS" -TITLE="Hosting a Microsoft Distributed File System tree on Samba" -HREF="msdfs.html"><LINK +TITLE="Optional configuration" +HREF="optional.html"><LINK REL="NEXT" -TITLE="Improved browsing in samba" -HREF="improved-browsing.html"></HEAD +TITLE="UNIX Permission Bits and Windows NT Access Control Lists" +HREF="unix-permissions.html"></HEAD ><BODY CLASS="CHAPTER" BGCOLOR="#FFFFFF" @@ -45,7 +46,7 @@ WIDTH="10%" ALIGN="left" VALIGN="bottom" ><A -HREF="msdfs.html" +HREF="optional.html" ACCESSKEY="P" >Prev</A ></TD @@ -59,7 +60,7 @@ WIDTH="10%" ALIGN="right" VALIGN="bottom" ><A -HREF="improved-browsing.html" +HREF="unix-permissions.html" ACCESSKEY="N" >Next</A ></TD @@ -72,92 +73,78 @@ WIDTH="100%"></DIV CLASS="CHAPTER" ><H1 ><A -NAME="INTEGRATE-MS-NETWORKS" -></A ->Chapter 22. Integrating MS Windows networks with Samba</H1 -><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 +NAME="INTEGRATE-MS-NETWORKS">Chapter 10. Integrating MS Windows networks with Samba</H1 ><DIV -CLASS="NOTE" +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN1374">10.1. Agenda</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 ><P ></P -><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" +><OL +TYPE="1" +><LI ><P -> 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 +>Name resolution in a pure Unix/Linux TCP/IP + environment + </P +></LI +><LI ><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" +>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 +><P +>MS Windows security options and how to + configure Samba for seemless integration + </P +></LI +><LI +><P +>Configuration of Samba as:</P ><P ></P -><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" +><OL +TYPE="a" +><LI ><P ->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 +>A stand-alone server</P +></LI +><LI +><P +>An MS Windows NT 3.x/4.0 security domain member + </P +></LI +><LI ><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 +>An alternative to an MS Windows NT 3.x/4.0 Domain Controller + </P +></LI +></OL +></LI +></OL +></DIV ><DIV CLASS="SECT1" ><H1 CLASS="SECT1" ><A -NAME="AEN3688" ->22.1. Name Resolution in a pure Unix/Linux world</A -></H1 +NAME="AEN1396">10.2. Name Resolution in a pure Unix/Linux world</H1 ><P >The key configuration files covered in this section are:</P ><P @@ -197,11 +184,9 @@ CLASS="SECT2" ><H2 CLASS="SECT2" ><A -NAME="AEN3704" ->22.1.1. <TT +NAME="AEN1412">10.2.1. <TT CLASS="FILENAME" >/etc/hosts</TT -></A ></H2 ><P >Contains a static list of IP Addresses and names. @@ -278,11 +263,9 @@ CLASS="SECT2" ><H2 CLASS="SECT2" ><A -NAME="AEN3720" ->22.1.2. <TT +NAME="AEN1428">10.2.2. <TT CLASS="FILENAME" >/etc/resolv.conf</TT -></A ></H2 ><P >This file tells the name resolution libraries:</P @@ -316,11 +299,9 @@ CLASS="SECT2" ><H2 CLASS="SECT2" ><A -NAME="AEN3731" ->22.1.3. <TT +NAME="AEN1439">10.2.3. <TT CLASS="FILENAME" >/etc/host.conf</TT -></A ></H2 ><P ><TT @@ -345,11 +326,9 @@ CLASS="SECT2" ><H2 CLASS="SECT2" ><A -NAME="AEN3739" ->22.1.4. <TT +NAME="AEN1447">10.2.4. <TT CLASS="FILENAME" >/etc/nsswitch.conf</TT -></A ></H2 ><P >This file controls the actual name resolution targets. The @@ -414,9 +393,7 @@ CLASS="SECT1" ><H1 CLASS="SECT1" ><A -NAME="AEN3751" ->22.2. Name resolution as used within MS Windows networking</A -></H1 +NAME="AEN1459">10.3. Name resolution as used within MS Windows networking</H1 ><P >MS Windows networking is predicated about the name each machine is given. This name is known variously (and inconsistently) as @@ -499,9 +476,7 @@ CLASS="SECT2" ><H2 CLASS="SECT2" ><A -NAME="AEN3763" ->22.2.1. The NetBIOS Name Cache</A -></H2 +NAME="AEN1471">10.3.1. The NetBIOS Name Cache</H2 ><P >All MS Windows machines employ an in memory buffer in which is stored the NetBIOS names and IP addresses for all external @@ -526,9 +501,7 @@ CLASS="SECT2" ><H2 CLASS="SECT2" ><A -NAME="AEN3768" ->22.2.2. The LMHOSTS file</A -></H2 +NAME="AEN1476">10.3.2. The LMHOSTS file</H2 ><P >This file is usually located in MS Windows NT 4.0 or 2000 in <TT @@ -563,8 +536,8 @@ CLASS="PROGRAMLISTING" # files and offers the following extensions: # # #PRE - # #DOM:<domain> - # #INCLUDE <filename> + # #DOM:<domain> + # #INCLUDE <filename> # #BEGIN_ALTERNATE # #END_ALTERNATE # \0xnn (non-printing character support) @@ -573,16 +546,16 @@ CLASS="PROGRAMLISTING" # 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:<domain>" tag will associate the - # entry with the domain specified by <domain>. This affects how the + # Following an entry with the "#DOM:<domain>" tag will associate the + # entry with the domain specified by <domain>. 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 <domain> is always preloaded although it will not + # #PRE to the line. The <domain> is always preloaded although it will not # be shown when the name cache is viewed. # - # Specifying "#INCLUDE <filename>" will force the RFC NetBIOS (NBT) - # software to seek the specified <filename> and parse it as if it were - # local. <filename> is generally a UNC-based name, allowing a + # Specifying "#INCLUDE <filename>" will force the RFC NetBIOS (NBT) + # software to seek the specified <filename> and parse it as if it were + # local. <filename> 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. @@ -629,9 +602,7 @@ CLASS="SECT2" ><H2 CLASS="SECT2" ><A -NAME="AEN3776" ->22.2.3. HOSTS file</A -></H2 +NAME="AEN1484">10.3.3. HOSTS file</H2 ><P >This file is usually located in MS Windows NT 4.0 or 2000 in <TT @@ -651,9 +622,7 @@ CLASS="SECT2" ><H2 CLASS="SECT2" ><A -NAME="AEN3781" ->22.2.4. DNS Lookup</A -></H2 +NAME="AEN1489">10.3.4. DNS Lookup</H2 ><P >This capability is configured in the TCP/IP setup area in the network configuration facility. If enabled an elaborate name resolution sequence @@ -671,9 +640,7 @@ CLASS="SECT2" ><H2 CLASS="SECT2" ><A -NAME="AEN3784" ->22.2.5. WINS Lookup</A -></H2 +NAME="AEN1492">10.3.5. WINS Lookup</H2 ><P >A WINS (Windows Internet Name Server) service is the equivaent of the rfc1001/1002 specified NBNS (NetBIOS Name Server). A WINS server stores @@ -692,10 +659,7 @@ CLASS="PROGRAMLISTING" ></P ><P >To configure Samba to use a WINS server the following parameters are -needed in the <TT -CLASS="FILENAME" ->smb.conf</TT -> file:</P +needed in the smb.conf file:</P ><P ><PRE CLASS="PROGRAMLISTING" @@ -703,13 +667,419 @@ CLASS="PROGRAMLISTING" wins server = xxx.xxx.xxx.xxx</PRE ></P ><P ->where <VAR +>where <TT CLASS="REPLACEABLE" ->xxx.xxx.xxx.xxx</VAR +><I +>xxx.xxx.xxx.xxx</I +></TT > is the IP address of the WINS server.</P ></DIV ></DIV +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN1504">10.4. How browsing functions and how to deploy stable and +dependable browsing using Samba</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="AEN1514">10.5. MS Windows security options and how to configure +Samba for seemless integration</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 +> = <TT +CLASS="REPLACEABLE" +><I +>integer</I +></TT +> + <A +HREF="smb.conf.5.html#USERNAMELEVEL" +TARGET="_top" +>username level</A +> = <TT +CLASS="REPLACEABLE" +><I +>integer</I +></TT +></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 <TT +CLASS="PARAMETER" +><I +>username level</I +></TT +> 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 <TT +CLASS="PARAMETER" +><I +>password level</I +></TT +> 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 <TT +CLASS="PARAMETER" +><I +>password level</I +></TT +> +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="AEN1542">10.5.1. Use MS Windows NT as an authentication server</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="AEN1550">10.5.2. Make Samba a member of an MS Windows NT security domain</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="AEN1567">10.5.3. Configure Samba as an authentication server</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="AEN1574">10.5.3.1. Users</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: <pw> + + # smbpasswd -a "userid" + Enter Password: <pw></PRE +></P +></DIV +><DIV +CLASS="SECT3" +><H3 +CLASS="SECT3" +><A +NAME="AEN1579">10.5.3.2. MS Windows NT Machine Accounts</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="AEN1584">10.6. Conclusions</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" @@ -727,7 +1097,7 @@ WIDTH="33%" ALIGN="left" VALIGN="top" ><A -HREF="msdfs.html" +HREF="optional.html" ACCESSKEY="P" >Prev</A ></TD @@ -745,7 +1115,7 @@ WIDTH="33%" ALIGN="right" VALIGN="top" ><A -HREF="improved-browsing.html" +HREF="unix-permissions.html" ACCESSKEY="N" >Next</A ></TD @@ -755,7 +1125,7 @@ ACCESSKEY="N" WIDTH="33%" ALIGN="left" VALIGN="top" ->Hosting a Microsoft Distributed File System tree on Samba</TD +>Optional configuration</TD ><TD WIDTH="34%" ALIGN="center" @@ -769,7 +1139,7 @@ ACCESSKEY="U" WIDTH="33%" ALIGN="right" VALIGN="top" ->Improved browsing in samba</TD +>UNIX Permission Bits and Windows NT Access Control Lists</TD ></TR ></TABLE ></DIV |