diff options
Diffstat (limited to 'docs/htmldocs/securitylevels.html')
| -rw-r--r-- | docs/htmldocs/securitylevels.html | 212 |
1 files changed, 0 insertions, 212 deletions
diff --git a/docs/htmldocs/securitylevels.html b/docs/htmldocs/securitylevels.html deleted file mode 100644 index ddfb22536b..0000000000 --- a/docs/htmldocs/securitylevels.html +++ /dev/null @@ -1,212 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> -<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 4. Samba as Stand-Alone Server</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.59.1"><link rel="home" href="index.html" title="SAMBA Project Documentation"><link rel="up" href="type.html" title="Part II. Server Configuration Basics"><link rel="previous" href="ServerType.html" title="Chapter 3. Nomenclature of Server Types"><link rel="next" href="samba-pdc.html" title="Chapter 5. -Samba as an NT4 or Win2k Primary Domain Controller -"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 4. Samba as Stand-Alone Server</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ServerType.html">Prev</a> </td><th width="60%" align="center">Part II. Server Configuration Basics</th><td width="20%" align="right"> <a accesskey="n" href="samba-pdc.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><h2 class="title"><a name="securitylevels"></a>Chapter 4. Samba as Stand-Alone Server</h2></div><div><div class="author"><h3 class="author">Andrew Tridgell</h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt><<a href="mailto:tridge@samba.org">tridge@samba.org</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author">Jelmer R. Vernooij</h3><div class="affiliation"><span class="orgname">The Samba Team<br></span><div class="address"><p><tt><<a href="mailto:jelmer@samba.org">jelmer@samba.org</a>></tt></p></div></div></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><a href="securitylevels.html#id2807692">User and Share security level</a></dt><dd><dl><dt><a href="securitylevels.html#id2807727">User Level Security</a></dt><dt><a href="securitylevels.html#id2810322">Share Level Security</a></dt><dt><a href="securitylevels.html#id2812328">Server Level Security</a></dt><dt><a href="securitylevels.html#id2876991">Domain Level Security</a></dt><dt><a href="securitylevels.html#id2877129">ADS Level Security</a></dt></dl></dd></dl></div><p> -In this section the function and purpose of Samba's <span class="emphasis"><em>security</em></span> -modes are described. -</p><div class="sect1" lang="en"><div class="titlepage"><div><h2 class="title" style="clear: both"><a name="id2807692"></a>User and Share security level</h2></div></div><p> -A SMB server tells the client at startup what "security level" it is -running. There are two options "share level" and "user level". Which -of these two the client receives affects the way the client then tries -to authenticate itself. It does not directly affect (to any great -extent) the way the Samba server does security. I know this is -strange, but it fits in with the client/server approach of SMB. In SMB -everything is initiated and controlled by the client, and the server -can only tell the client what is available and whether an action is -allowed. -</p><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="id2807727"></a>User Level Security</h3></div></div><p> -I'll describe user level security first, as its simpler. In user level -security the client will send a "session setup" command directly after -the protocol negotiation. This contains a username and password. The -server can either accept or reject that username/password -combination. Note that at this stage the server has no idea what -share the client will eventually try to connect to, so it can't base -the "accept/reject" on anything other than: -</p><div class="orderedlist"><ol type="1"><li><p>the username/password</p></li><li><p>the machine that the client is coming from</p></li></ol></div><p> -If the server accepts the username/password then the client expects to -be able to mount any share (using a "tree connection") without -specifying a password. It expects that all access rights will be as -the username/password specified in the "session setup". -</p><p> -It is also possible for a client to send multiple "session setup" -requests. When the server responds it gives the client a "uid" to use -as an authentication tag for that username/password. The client can -maintain multiple authentication contexts in this way (WinDD is an -example of an application that does this) -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="id2810322"></a>Share Level Security</h3></div></div><p> -Ok, now for share level security. In share level security the client -authenticates itself separately for each share. It will send a -password along with each "tree connection" (share mount). It does not -explicitly send a username with this operation. The client is -expecting a password to be associated with each share, independent of -the user. This means that samba has to work out what username the -client probably wants to use. It is never explicitly sent the -username. Some commercial SMB servers such as NT actually associate -passwords directly with shares in share level security, but samba -always uses the unix authentication scheme where it is a -username/password that is authenticated, not a "share/password". -</p><p> -Many clients send a "session setup" even if the server is in share -level security. They normally send a valid username but no -password. Samba records this username in a list of "possible -usernames". When the client then does a "tree connection" it also adds -to this list the name of the share they try to connect to (useful for -home directories) and any users listed in the <b>user =</b> <tt>smb.conf</tt> -line. The password is then checked in turn against these "possible -usernames". If a match is found then the client is authenticated as -that user. -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="id2812328"></a>Server Level Security</h3></div></div><p> -Finally "server level" security. In server level security the samba -server reports to the client that it is in user level security. The -client then does a "session setup" as described earlier. The samba -server takes the username/password that the client sends and attempts -to login to the "password server" by sending exactly the same -username/password that it got from the client. If that server is in -user level security and accepts the password then samba accepts the -clients connection. This allows the samba server to use another SMB -server as the "password server". -</p><p> -You should also note that at the very start of all this, where the -server tells the client what security level it is in, it also tells -the client if it supports encryption. If it does then it supplies the -client with a random "cryptkey". The client will then send all -passwords in encrypted form. You have to compile samba with encryption -enabled to support this feature, and you have to maintain a separate -smbpasswd file with SMB style encrypted passwords. It is -cryptographically impossible to translate from unix style encryption -to SMB style encryption, although there are some fairly simple management -schemes by which the two could be kept in sync. -</p><p> -"security = server" means that Samba reports to clients that -it is running in "user mode" but actually passes off all authentication -requests to another "user mode" server. This requires an additional -parameter "password server =" that points to the real authentication server. -That real authentication server can be another Samba server or can be a -Windows NT server, the later natively capable of encrypted password support. -</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> -<span class="emphasis"><em>Server</em></span> level security is incompatible with what is known -as <span class="emphasis"><em>schannel</em></span> or "sign and seal" protocols. This means that -if you want to use <span class="emphasis"><em>server</em></span> level security you must disable -the use of "sign and seal" on all machines on your network. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><h4 class="title"><a name="id2876754"></a>Configuring Samba for Seemless Windows Network Integration</h4></div></div><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 request. -</p><p> -When encrypted passwords are used a password that has been entered by the user -is encrypted in two ways: -</p><div class="itemizedlist"><ul type="disc"><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></div><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, support was dropped 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 -service connection 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><pre class="programlisting"> - <a href="smb.conf.5.html#PASSWORDLEVEL" target="_top">passsword level</a> = <i><tt>integer</tt></i> - <a href="smb.conf.5.html#USERNAMELEVEL" target="_top">username level</a> = <i><tt>integer</tt></i> -</pre><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 <i><tt>username level</tt></i> parameter -is rarely needed. -</p><p> -However, passwords 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 <i><tt>password level</tt></i> -must be set to the maximum number of upper case letter which <span class="emphasis"><em>could</em></span> -appear is a password. Note that the server OS uses the traditional DES version -of crypt(), a <i><tt>password level</tt></i> of 8 will result in case -insensitive passwords as seen from Windows users. This will also result in longer -login times as Samba has 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><div class="sect3" lang="en"><div class="titlepage"><div><h4 class="title"><a name="id2876930"></a>Use MS Windows NT as an authentication server</h4></div></div><p> -This method involves the additions of the following parameters in the <tt>smb.conf</tt> file: -</p><pre class="programlisting"> - encrypt passwords = Yes - security = server - password server = "NetBIOS_name_of_PDC" -</pre><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 an 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><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="id2876991"></a>Domain Level Security</h3></div></div><p> -When samba is operating in <span class="emphasis"><em>security = domain</em></span> mode this means that -the Samba server has a domain security trust account (a machine account) and will cause -all authentication requests to be passed through to the domain controllers. -</p><div class="sect3" lang="en"><div class="titlepage"><div><h4 class="title"><a name="id2877011"></a>Samba as a member of an MS Windows NT security domain</h4></div></div><p> -This method involves addition of the following parameters in the <tt>smb.conf</tt> file: -</p><pre class="programlisting"> - encrypt passwords = Yes - security = domain - workgroup = "name of NT domain" - password server = * -</pre><p> -The use of the "*" argument to <b>password server</b> will cause samba to locate the -domain controller in a way analogous to the way this is done within MS Windows NT. -This is the default behaviour. -</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><div class="itemizedlist"><ul type="disc"><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>smbpasswd -r PDC_NAME -j DOMAIN_NAME</b> (samba 2.x) - - <b>net join -U administrator%password</b> (samba-3) - </p></li></ul></div><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 clients other than -MS Windows through things such as setting an invalid shell in the -<tt>/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" title="Chapter 15. Unified Logons between Windows NT and UNIX using Winbind">Winbind Overview</a> chapter -in this HOWTO collection. -</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="id2877129"></a>ADS Level Security</h3></div></div><p> -For information about the configuration option please refer to the entire section entitled -<span class="emphasis"><em>Samba as an ADS Domain Member.</em></span> -</p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ServerType.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="type.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="samba-pdc.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 3. Nomenclature of Server Types </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 5. -Samba as an NT4 or Win2k Primary Domain Controller -</td></tr></table></div></body></html> |