diff options
Diffstat (limited to 'docs/docbook/projdoc/ServerType.xml')
| -rw-r--r-- | docs/docbook/projdoc/ServerType.xml | 646 |
1 files changed, 646 insertions, 0 deletions
diff --git a/docs/docbook/projdoc/ServerType.xml b/docs/docbook/projdoc/ServerType.xml new file mode 100644 index 0000000000..f400cdd647 --- /dev/null +++ b/docs/docbook/projdoc/ServerType.xml @@ -0,0 +1,646 @@ +<chapter id="ServerType"> +<chapterinfo> + &author.tridge; + &author.jelmer; + &author.jht; +</chapterinfo> + +<title>Server Types and Security Modes</title> + +<para> +This chapter provides information regarding the types of server that Samba may be +configured to be. A Microsoft network administrator who wishes to migrate to or +use Samba will want to know the meaning, within a Samba context, of terms familiar to MS Windows +administrator. This means that it is essential also to define how critical security +modes function before we get into the details of how to configure the server itself. +</para> + +<para> +The chapter provides an overview of the security modes of which Samba is capable +and how they relate to MS Windows servers and clients. +</para> + +<para> +A question often asked is, <quote>Why would I want to use Samba?</quote> Most chapters contain a section +that highlights features and benefits. We hope that the information provided will help to +answer this question. Be warned though, we want to be fair and reasonable, so not all +features are positive towards Samba. The benefit may be on the side of our competition. +</para> + +<sect1> +<title>Features and Benefits</title> + +<para> +Two men were walking down a dusty road, when one suddenly kicked up a small red stone. It +hurt his toe and lodged in his sandal. He took the stone out and cursed it with a passion +and fury befitting his anguish. The other looked at the stone and said, <quote>This is a garnet. +I can turn that into a precious gem and some day it will make a princess very happy!</quote> +</para> + +<para> +The moral of this tale: Two men, two very different perspectives regarding the same stone. +Like it or not, Samba is like that stone. Treat it the right way and it can bring great +pleasure, but if you are forced to use it and have no time for its secrets, then it can be +a source of discomfort. +</para> + +<para> +Samba started out as a project that sought to provide interoperability for MS Windows 3.x +clients with a UNIX server. It has grown up a lot since its humble beginnings and now provides +features and functionality fit for large scale deployment. It also has some warts. In sections +like this one we tell of both. +</para> + +<para> +So, what are the benefits of features mentioned in this chapter? +</para> + +<itemizedlist> + <listitem><para> + Samba-3 can replace an MS Windows NT4 Domain Controller. + </para></listitem> + + <listitem><para> + Samba-3 offers excellent interoperability with MS Windows NT4-style + domains as well as natively with Microsoft Active Directory domains. + </para></listitem> + + <listitem><para> + Samba-3 permits full NT4-style Interdomain Trusts. + </para></listitem> + + <listitem><para> + Samba has security modes that permit more flexible + authentication than is possible with MS Windows NT4 Domain Controllers. + </para></listitem> + + <listitem><para> + Samba-3 permits use of multiple account database backends. + </para></listitem> + + <listitem><para> + The account (password) database backends can be distributed + and replicated using multiple methods. This gives Samba-3 + greater flexibility than MS Windows NT4 and in many cases a + significantly higher utility than Active Directory domains + with MS Windows 200x. + </para></listitem> +</itemizedlist> + +</sect1> + +<sect1> +<title>Server Types</title> + + +<para> +<indexterm><primary>Server Type</primary></indexterm> +Administrators of Microsoft networks often refer to three +different type of servers:</para> + +<itemizedlist> + <listitem><para>Domain Controller</para> + <itemizedlist> + <listitem><para>Primary Domain Controller</para></listitem> + <listitem><para>Backup Domain Controller</para></listitem> + <listitem><para>ADS Domain Controller</para></listitem> + </itemizedlist> + </listitem> + <listitem><para>Domain Member Server</para> + <itemizedlist> + <listitem><para>Active Directory Domain Server</para></listitem> + <listitem><para>NT4 Style Domain Domain Server</para></listitem> + </itemizedlist> + </listitem> + <listitem><para>Stand-alone Server</para></listitem> +</itemizedlist> + +<para> +The chapters covering Domain Control, Backup Domain Control and Domain Membership provide +pertinent information regarding Samba configuration for each of these server roles. +The reader is strongly encouraged to become intimately familiar with the information +presented. +</para> + +</sect1> + +<sect1> +<title>Samba Security Modes</title> + + +<para> +<indexterm><primary>Security Mode</primary></indexterm> +<indexterm><primary>security</primary></indexterm> +In this section the function and purpose of Samba's security +modes are described. An accurate understanding of how Samba implements each security +mode as well as how to configure MS Windows clients for each mode will significantly +reduce user complaints and administrator heartache. +</para> + +<para> +In the SMB/CIFS networking world, there are only two types of security: <emphasis>User Level</emphasis> +and <emphasis>Share Level</emphasis>. We refer to these collectively as <emphasis>security levels</emphasis>. +In implementing these two security levels, Samba provides flexibilities +that are not available with Microsoft Windows NT4/200x servers. In actual fact, Samba implements +<emphasis>Share Level</emphasis> security only one way, but has four ways of implementing +<emphasis>User Level</emphasis> security. Collectively, we call the Samba implementations +<emphasis>Security Modes</emphasis>. They are known as: <emphasis>SHARE</emphasis>, <emphasis>USER</emphasis>, +<emphasis>DOMAIN</emphasis>, <emphasis>ADS</emphasis>, and <emphasis>SERVER</emphasis> modes. +They are documented in this chapter. +</para> + +<para> +An 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. This may sound 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. +</para> + +<sect2> +<title>User Level Security</title> + +<para> +We will describe User Level Security first, as its simpler. +In User Level Security, the client will send a +session setup request directly following protocol negotiation. +This request provides a username and password. The server can either accept or reject that +username/password combination. At this stage the server has no idea what +share the client will eventually try to connect to, so it can't base the +<emphasis>accept/reject</emphasis> on anything other than: +</para> + +<orderedlist> +<listitem><para>the username/password.</para></listitem> +<listitem><para>the name of the client machine.</para></listitem> +</orderedlist> + +<para> +If the server accepts the username/password then the client expects to be able to +mount shares (using a <emphasis>tree connection</emphasis>) without specifying a +password. It expects that all access rights will be as the username/password +specified in the <emphasis>session setup</emphasis>. +</para> + +<para> +It is also possible for a client to send multiple <emphasis>session setup</emphasis> +requests. When the server responds, it gives the client a <emphasis>uid</emphasis> 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). +</para> + +<sect3> +<title>Example Configuration</title> + +<para> +The &smb.conf; parameter that sets user level security is: +</para> + +<para><smbconfblock> +<smbconfoption><name>security</name><value>user</value></smbconfoption> +</smbconfblock></para> + +<para> +This is the default setting since Samba-2.2.x. +</para> + +</sect3> + +</sect2> +<sect2> +<title>Share Level Security</title> + +<para> +In Share Level security, the client authenticates +itself separately for each share. It sends a password along with each +tree connection (share mount). It does not explicitly send a +username with this operation. The client expects 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 pair that is authenticated, not a share/password pair. +</para> + +<para> +To understand the MS Windows networking parallels, one should think +in terms of MS Windows 9x/Me where one can create a shared folder that provides read-only +or full access, with or without a password. +</para> + +<para> +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 <smbconfoption><name>user</name></smbconfoption> parameter in the &smb.conf; file. +The password is then checked in turn against these possible usernames. If a match is found +then the client is authenticated as that user. +</para> + +<sect3> +<title>Example Configuration</title> + +<para> +The &smb.conf; parameter that sets Share Level security is: +</para> + +<para><smbconfblock> +<smbconfoption><name>security</name><value>share</value></smbconfoption> +</smbconfblock></para> + +<para> +There are reports that recent MS Windows clients do not like to work +with share mode security servers. You are strongly discouraged from using Share Level security. +</para> + +</sect3> +</sect2> + +<sect2> +<title>Domain Security Mode (User Level Security)</title> + +<para> +<indexterm><primary>Domain Member</primary></indexterm> +When Samba is operating in <smbconfoption><name>security</name><value>domain</value></smbconfoption> mode, +the Samba server has a domain security trust account (a machine account) and causes +all authentication requests to be passed through to the Domain Controllers. +In other words, this configuration makes the Samba server a Domain Member server. +</para> + +<sect3> +<title>Example Configuration</title> +<para><emphasis> +Samba as a Domain Member Server +</emphasis></para> + + +<para> +<indexterm><primary>Server Type</primary><secondary>Domain Member</secondary></indexterm> +This method involves addition of the following parameters in the &smb.conf; file: +</para> + +<para><smbconfblock> +<smbconfoption><name>security</name><value>domain</value></smbconfoption> +<smbconfoption><name>workgroup</name><value>&example.workgroup;</value></smbconfoption> +</smbconfblock></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: +<indexterm><primary>net</primary><secondary>rpc</secondary></indexterm> +<indexterm><primary>Domain Member</primary><secondary>joining</secondary></indexterm> +</para> + + +<procedure> + <step><para>On the MS Windows NT Domain Controller, using + the Server Manager, add a machine account for the Samba server. + </para></step> + + <step><para>On the UNIX/Linux system execute:</para> + + <para><screen>&rootprompt;<userinput>net rpc join -U administrator%password</userinput></screen></para> + </step> +</procedure> + +<note><para> +Samba-2.2.4 and later can auto-join a Windows NT4-style Domain just by executing: +<screen> +&rootprompt;<userinput>smbpasswd -j <replaceable>DOMAIN_NAME</replaceable> -r <replaceable>PDC_NAME</replaceable> \ + -U Administrator%<replaceable>password</replaceable></userinput> +</screen> + +Samba-3 can do the same by executing: +<screen> +&rootprompt;<userinput>net rpc join -U Administrator%<replaceable>password</replaceable></userinput> +</screen> +It is not necessary with Samba-3 to specify the <replaceable>DOMAIN_NAME</replaceable> or the +<replaceable>PDC_NAME</replaceable> as it figures this out from the &smb.conf; file settings. +</para></note> + +<para> +Use of this mode of authentication does require there to be a standard UNIX account +for each 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 means 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 <link linkend="winbind"></link>. +</para> + +<para> +For more information regarding Domain Membership, see <link linkend="domain-member"></link>. +</para> + +</sect3> +</sect2> + +<sect2> +<title>ADS Security Mode (User Level Security)</title> + +<para> +Both Samba-2.2, and Samba-3 can join an Active Directory domain. This is +possible if the domain is run in native mode. Active Directory in +native mode perfectly allows NT4-style Domain Members. This is contrary to +popular belief. Active Directory in native mode prohibits only the use of +Backup Domain Controllers running MS Windows NT4. +</para> + +<para> +If you are using Active Directory, starting with Samba-3 you can +join as a native AD member. Why would you want to do that? +Your security policy might prohibit the use of NT-compatible +authentication protocols. All your machines are running Windows 2000 +and above and all use Kerberos. In this case Samba as an NT4-style +domain would still require NT-compatible authentication data. Samba in +AD-member mode can accept Kerberos tickets. +</para> + +<sect3> +<title>Example Configuration</title> + +<para><smbconfblock> +<smbconfoption><name>realm</name><value>your.kerberos.REALM</value></smbconfoption> +<smbconfoption><name>security</name><value>ADS</value></smbconfoption> +</smbconfblock></para> + +<para> +The following parameter may be required: +</para> + +<para><smbconfblock> +<smbconfoption><name>password server</name><value>your.kerberos.server</value></smbconfoption> +</smbconfblock></para> + +<para> +Please refer to <link linkend="domain-member"></link> and <link linkend="ads-member"></link> +for more information regarding this configuration option. +</para> + +</sect3> +</sect2> + +<sect2> +<title>Server Security (User Level Security)</title> + +<para> +Server Security Mode is left over from the time when Samba was not capable of acting +as a Domain Member server. It is highly recommended not to use this feature. Server +security mode has many drawbacks that include: +</para> + +<itemizedlist> + <listitem><para>Potential Account Lockout on MS Windows NT4/200x password servers.</para></listitem> + <listitem><para>Lack of assurance that the password server is the one specified.</para></listitem> + <listitem><para>Does not work with Winbind, which is particularly needed when storing profiles remotely.</para></listitem> + <listitem><para>This mode may open connections to the password server, and keep them open for extended periods.</para></listitem> + <listitem><para>Security on the Samba server breaks badly when the remote password server suddenly shuts down.</para></listitem> + <listitem><para>With this mode there is NO security account in the domain that the password server belongs to for the Samba server.</para></listitem> +</itemizedlist> + +<para> +In Server Security Mode 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 +<smbconfoption><name>password server</name></smbconfoption> 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 client's connection. This allows the Samba server to use another SMB +server as the <smbconfoption><name>password server</name></smbconfoption>. +</para> + +<para> +You should also note that at the 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, it supplies the client with a random cryptkey. The client will then send all +passwords in encrypted form. Samba supports this type of encryption by default. +</para> + +<para> +The parameter <smbconfoption><name>security</name><value>server</value></smbconfoption> means that Samba reports to clients that +it is running in <emphasis>user mode</emphasis> but actually passes off all authentication +requests to another <emphasis>user mode</emphasis> server. This requires an additional +parameter <smbconfoption><name>password server</name></smbconfoption> that points to the real authentication server. +The real authentication server can be another Samba server, or it can be a Windows NT server, +the latter being natively capable of encrypted password support. +</para> + +<note><para> +When Samba is running in <emphasis>Server Security Mode</emphasis> it is essential that +the parameter <emphasis>password server</emphasis> is set to the precise NetBIOS machine +name of the target authentication server. Samba cannot determine this from NetBIOS name +lookups because the choice of the target authentication server is arbitrary and cannot +be determined from a domain name. In essence, a Samba server that is in +<emphasis>Server Security Mode</emphasis> is operating in what used to be known as +workgroup mode. +</para></note> + +<sect3> +<title>Example Configuration</title> +<para><emphasis> +Using MS Windows NT as an Authentication Server +</emphasis></para> + +<para> +This method involves the additions of the following parameters in the &smb.conf; file: +</para> + +<para><smbconfblock> +<smbconfoption><name>encrypt passwords</name><value>Yes</value></smbconfoption> +<smbconfoption><name>security</name><value>server</value></smbconfoption> +<smbconfoption><name>password server</name><value>"NetBIOS_name_of_a_DC"</value></smbconfoption> +</smbconfblock></para> + + +<para> +There are two ways of identifying whether or not a username and password pair is valid. +One uses the reply information provided as part of the authentication messaging +process, the other uses just an error code. +</para> + +<para> +The downside 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 requires a standard UNIX account for the user. +This account can be blocked to prevent logons by non-SMB/CIFS clients. +</para> + +</sect3> +</sect2> + +</sect1> + +<sect1> +<title>Password Checking</title> + +<para> +MS Windows clients may use encrypted passwords as part of a challenge/response +authentication model (a.k.a. NTLMv1 and NTLMv2) or alone, or cleartext 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. +</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 truncated 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 <quote>magic</quote> 8-byte value. + The resulting 16 bytes form the LanMan hash. + </para></listitem> +</itemizedlist> + +<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, 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, this will fail if the remote +authentication server does not support encrypted passwords. 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/Me clients +upper-casing usernames and passwords before transmitting them to the SMB server +when using cleartext authentication: +</para> + +<para><smbconfblock> +<smbconfoption><name>password level</name><value><replaceable>integer</replaceable></value></smbconfoption> +<smbconfoption><name>username level</name><value><replaceable>integer</replaceable></value></smbconfoption> +</smbconfblock></para> + +<para> +By default Samba will convert to 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 characters, the <smbconfoption><name>username level</name></smbconfoption> parameter +is rarely needed. +</para> + +<para> +However, passwords on UNIX systems often make use of mixed-case characters. +This means that in order for a user on a Windows 9x/Me client to connect to a Samba +server using cleartext authentication, the <smbconfoption><name>password level</name></smbconfoption> +must be set to the maximum number of upper case letters that <emphasis>could</emphasis> +appear in a password. Note that if the server OS uses the traditional DES version +of crypt(), a <smbconfoption><name>password level</name></smbconfoption> 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). +</para> + +<para> +The best option to adopt is to enable support for encrypted passwords wherever +Samba is used. Most attempts to apply the registry change to re-enable plain-text +passwords will eventually lead to user complaints and unhappiness. +</para> + +</sect1> + +<sect1> +<title>Common Errors</title> + +<para> +We all make mistakes. It is okay to make mistakes, as long as they are made in the right places +and at the right time. A mistake that causes lost productivity is seldom tolerated, however a mistake +made in a developmental test lab is expected. +</para> + +<para> +Here we look at common mistakes and misapprehensions that have been the subject of discussions +on the Samba mailing lists. Many of these are avoidable by doing your homework before attempting +a Samba implementation. Some are the result of a misunderstanding of the English language. The +English language, which has many phrases that are potentially vague and may be highly confusing +to those for whom English is not their native tongue. +</para> + +<sect2> +<title>What Makes Samba a Server?</title> + +<para> +To some the nature of the Samba <emphasis>security</emphasis> mode is obvious, but entirely +wrong all the same. It is assumed that <smbconfoption><name>security</name><value>server</value></smbconfoption> means that Samba +will act as a server. Not so! This setting means that Samba will <emphasis>try</emphasis> +to use another SMB server as its source for user authentication alone. +</para> + +</sect2> + +<sect2> +<title>What Makes Samba a Domain Controller?</title> + +<para> +The &smb.conf; parameter <smbconfoption><name>security</name><value>domain</value></smbconfoption> does not really make Samba behave +as a Domain Controller. This setting means we want Samba to be a Domain Member. +</para> + +</sect2> + +<sect2> +<title>What Makes Samba a Domain Member?</title> + +<para> +Guess! So many others do. But whatever you do, do not think that <smbconfoption><name>security</name><value>user</value></smbconfoption> +makes Samba act as a Domain Member. Read the manufacturer's manual before the warranty expires. See +<link linkend="domain-member"></link> for more information. +</para> + +</sect2> + + +<sect2> +<title>Constantly Losing Connections to Password Server</title> + +<para> + <quote> +Why does server_validate() simply give up rather than re-establish its connection to the +password server? Though I am not fluent in the SMB protocol, perhaps the cluster server +process passes along to its client workstation the session key it receives from the password +server, which means the password hashes submitted by the client would not work on a subsequent +connection whose session key would be different. So server_validate() must give up.</quote> +</para> + +<para> +Indeed. That's why <smbconfoption><name>security</name><value>server</value></smbconfoption> +is at best a nasty hack. Please use <smbconfoption><name>security</name><value>domain</value></smbconfoption>; +<smbconfoption><name>security</name><value>server</value></smbconfoption> mode is also known as pass-through authentication. +</para> + +</sect2> + +</sect1> + +</chapter> |