diff options
Diffstat (limited to 'docs/docbook/projdoc')
| -rw-r--r-- | docs/docbook/projdoc/ADS-HOWTO.xml | 167 | ||||
| -rw-r--r-- | docs/docbook/projdoc/DOMAIN_MEMBER.xml | 472 | ||||
| -rw-r--r-- | docs/docbook/projdoc/Other-Clients.xml | 2 | ||||
| -rw-r--r-- | docs/docbook/projdoc/Samba-BDC-HOWTO.xml | 20 | ||||
| -rw-r--r-- | docs/docbook/projdoc/Samba-PDC-HOWTO.xml | 455 | ||||
| -rw-r--r-- | docs/docbook/projdoc/ServerType.xml | 468 | ||||
| -rw-r--r-- | docs/docbook/projdoc/Speed.xml | 3 | ||||
| -rw-r--r-- | docs/docbook/projdoc/StandAloneServer.xml | 47 | ||||
| -rw-r--r-- | docs/docbook/projdoc/samba-doc.xml | 3 | ||||
| -rw-r--r-- | docs/docbook/projdoc/securing-samba.xml | 19 | ||||
| -rw-r--r-- | docs/docbook/projdoc/security_level.xml | 340 |
11 files changed, 1030 insertions, 966 deletions
diff --git a/docs/docbook/projdoc/ADS-HOWTO.xml b/docs/docbook/projdoc/ADS-HOWTO.xml deleted file mode 100644 index c89a0e4f87..0000000000 --- a/docs/docbook/projdoc/ADS-HOWTO.xml +++ /dev/null @@ -1,167 +0,0 @@ -<chapter id="ADS"> - -<chapterinfo> - &author.tridge; - &author.jelmer; - <pubdate>2002/2003</pubdate> -</chapterinfo> - -<title>Samba as a ADS domain member</title> - -<para> -This is a rough guide to setting up Samba 3.0 with kerberos authentication against a -Windows2000 KDC. -</para> - -<sect1> -<title>Setup your <filename>smb.conf</filename></title> - -<para>You must use at least the following 3 options in smb.conf:</para> - -<para><programlisting> - realm = YOUR.KERBEROS.REALM - security = ADS - encrypt passwords = yes -</programlisting></para> - -<para> -In case samba can't figure out your ads server using your realm name, use the -<command>ads server</command> option in <filename>smb.conf</filename>: -<programlisting> - ads server = your.kerberos.server -</programlisting> -</para> - -<note><para>You do *not* need a smbpasswd file, and older clients will - be authenticated as if <command>security = domain</command>, - although it won't do any harm - and allows you to have local users not in the domain. - I expect that the above required options will change soon when we get better - active directory integration.</para></note> - -</sect1> - -<sect1> -<title>Setup your <filename>/etc/krb5.conf</filename></title> - -<para>Note: you will need the krb5 workstation, devel, and libs installed</para> - -<para>The minimal configuration for <filename>krb5.conf</filename> is:</para> - -<para><programlisting> - [realms] - YOUR.KERBEROS.REALM = { - kdc = your.kerberos.server - } -</programlisting></para> - -<para>Test your config by doing a <userinput>kinit -<replaceable>USERNAME</replaceable>@<replaceable>REALM</replaceable></userinput> and -making sure that your password is accepted by the Win2000 KDC. -</para> - -<note><para>The realm must be uppercase or you will get "Cannot find KDC for requested -realm while getting initial credentials" error </para></note> - -<note><para>Time between the two servers must be synchronized. You will get a -"kinit(v5): Clock skew too great while getting initial credentials" if the time -difference is more than five minutes. </para></note> - -<para> -You also must ensure that you can do a reverse DNS lookup on the IP -address of your KDC. Also, the name that this reverse lookup maps to -must either be the netbios name of the KDC (ie. the hostname with no -domain attached) or it can alternatively be the netbios name -followed by the realm. -</para> - -<para> -The easiest way to ensure you get this right is to add a -<filename>/etc/hosts</filename> entry mapping the IP address of your KDC to -its netbios name. If you don't get this right then you will get a -"local error" when you try to join the realm. -</para> - -<para> -If all you want is kerberos support in &smbclient; then you can skip -straight to <link linkend="ads-test-smbclient">Test with &smbclient;</link> now. -<link linkend="ads-create-machine-account">Creating a computer account</link> -and <link linkend="ads-test-server">testing your servers</link> -is only needed if you want kerberos support for &smbd; and &winbindd;. -</para> - -</sect1> - -<sect1 id="ads-create-machine-account"> -<title>Create the computer account</title> - -<para> -As a user that has write permission on the Samba private directory -(usually root) run: -<programlisting> - <userinput>net join -U Administrator%password</userinput> -</programlisting> -</para> - -<sect2> -<title>Possible errors</title> - -<para> -<variablelist> - <varlistentry><term>"ADS support not compiled in"</term> - <listitem><para>Samba must be reconfigured (remove config.cache) and recompiled - (make clean all install) after the kerberos libs and headers are installed. - </para></listitem></varlistentry> - - <varlistentry><term>net join prompts for user name</term> - <listitem><para>You need to login to the domain using <userinput>kinit - <replaceable>USERNAME</replaceable>@<replaceable>REALM</replaceable></userinput>. - <replaceable>USERNAME</replaceable> must be a user who has rights to add a machine - to the domain. </para></listitem></varlistentry> -</variablelist> -</para> - -</sect2> - -</sect1> - -<sect1 id="ads-test-server"> -<title>Test your server setup</title> - -<para> -If the join was successful, you will see a new computer account with the -NetBIOS name of your Samba server in Active Directory (in the "Computers" -folder under Users and Computers. -</para> - -<para> -On a Windows 2000 client try <userinput>net use * \\server\share</userinput>. You should -be logged in with kerberos without needing to know a password. If -this fails then run <userinput>klist tickets</userinput>. Did you get a ticket for the -server? Does it have an encoding type of DES-CBC-MD5 ? -</para> - -</sect1> - -<sect1 id="ads-test-smbclient"> -<title>Testing with &smbclient;</title> - -<para> -On your Samba server try to login to a Win2000 server or your Samba -server using &smbclient; and kerberos. Use &smbclient; as usual, but -specify the <parameter>-k</parameter> option to choose kerberos authentication. -</para> - -</sect1> - -<sect1> -<title>Notes</title> - -<para>You must change administrator password at least once after DC -install, to create the right encoding types</para> - -<para>w2k doesn't seem to create the _kerberos._udp and _ldap._tcp in - their defaults DNS setup. Maybe fixed in service packs?</para> -</sect1> - -</chapter> diff --git a/docs/docbook/projdoc/DOMAIN_MEMBER.xml b/docs/docbook/projdoc/DOMAIN_MEMBER.xml index a5921e8ce3..6a3ef28b55 100644 --- a/docs/docbook/projdoc/DOMAIN_MEMBER.xml +++ b/docs/docbook/projdoc/DOMAIN_MEMBER.xml @@ -3,159 +3,343 @@ <chapterinfo> &author.jeremy; &author.jerry; - <pubdate>16 Apr 2001</pubdate> + &author.jht; </chapterinfo> - -<title>Samba as a NT4 or Win2k domain member</title> +<title>Domain Membership</title> <sect1> +<title>Domain Member Server</title> + +<para> +This mode of server operation involves the samba machine being made a member +of a domain security context. This means by definition that all user authentication +will be done from a centrally defined authentication regime. The authentication +regime may come from an NT3/4 style (old domain technology) server, or it may be +provided from an Active Directory server (ADS) running on MS Windows 2000 or later. +</para> + +<para><emphasis> +Of course it should be clear that the authentication back end itself could be from any +distributed directory architecture server that is supported by Samba. This can be +LDAP (from OpenLDAP), or Sun's iPlanet, of NetWare Directory Server, etc. +</emphasis></para> + +<para> +Please refer to the section on Howto configure Samba as a Primary Domain Controller +and for more information regarding how to create a domain machine account for a +domain member server as well as for information regarding how to enable the samba +domain member machine to join the domain and to be fully trusted by it. +</para> - <title>Joining an NT Domain with Samba 3.0</title> - <para><emphasis>Assumptions:</emphasis> - <programlisting> - NetBIOS name: SERV1 - Win2K/NT domain name: DOM - Domain's PDC NetBIOS name: DOMPDC - Domain's BDC NetBIOS names: DOMBDC1 and DOMBDC2 - </programlisting> - </para> - - <para>First, you must edit your &smb.conf; file to tell Samba it should - now use domain security.</para> - - <para>Change (or add) your <ulink url="smb.conf.5.html#SECURITY"> - <parameter>security =</parameter></ulink> line in the [global] section - of your &smb.conf; to read:</para> - - <para><command>security = domain</command></para> - - <para>Next change the <ulink url="smb.conf.5.html#WORKGROUP"><parameter> - workgroup =</parameter></ulink> line in the [global] section to read: </para> - - <para><command>workgroup = DOM</command></para> - - <para>as this is the name of the domain we are joining. </para> - - <para>You must also have the parameter <ulink url="smb.conf.5.html#ENCRYPTPASSWORDS"> - <parameter>encrypt passwords</parameter></ulink> set to <constant>yes - </constant> in order for your users to authenticate to the NT PDC.</para> - - <para>Finally, add (or modify) a <ulink url="smb.conf.5.html#PASSWORDSERVER"> - <parameter>password server =</parameter></ulink> line in the [global] - section to read: </para> - - <para><command>password server = DOMPDC DOMBDC1 DOMBDC2</command></para> - - <para>These are the primary and backup domain controllers Samba - will attempt to contact in order to authenticate users. Samba will - try to contact each of these servers in order, so you may want to - rearrange this list in order to spread out the authentication load - among domain controllers.</para> - - <para>Alternatively, if you want smbd to automatically determine - the list of Domain controllers to use for authentication, you may - set this line to be :</para> - - <para><command>password server = *</command></para> - - <para>This method, allows Samba to use exactly the same - mechanism that NT does. This - method either broadcasts or uses a WINS database in order to - find domain controllers to authenticate against.</para> - - <para>In order to actually join the domain, you must run this - command:</para> - - <para><prompt>root# </prompt><userinput>net join -S DOMPDC - -U<replaceable>Administrator%password</replaceable></userinput></para> - - <para> - If the <userinput>-S DOMPDC</userinput> argument is not given then - the domain name will be obtained from smb.conf. - </para> - - <para>as we are joining the domain DOM and the PDC for that domain - (the only machine that has write access to the domain SAM database) - is DOMPDC. The <replaceable>Administrator%password</replaceable> is - the login name and password for an account which has the necessary - privilege to add machines to the domain. If this is successful - you will see the message:</para> - - <para><computeroutput>Joined domain DOM.</computeroutput> - or <computeroutput>Joined 'SERV1' to realm 'MYREALM'</computeroutput> - </para> - - <para>in your terminal window. See the <ulink url="net.8.html"> - net(8)</ulink> man page for more details.</para> - - <para>This process joins the server to the domain - without having to create the machine trust account on the PDC - beforehand.</para> - - <para>This command goes through the machine account password - change protocol, then writes the new (random) machine account - password for this Samba server into a file in the same directory - in which an smbpasswd file would be stored - normally :</para> - - <para><filename>/usr/local/samba/private/secrets.tdb</filename></para> - - <para>This file is created and owned by root and is not - readable by any other user. It is the key to the domain-level - security for your system, and should be treated as carefully - as a shadow password file.</para> - - <para>Finally, restart your Samba daemons and get ready for - clients to begin using domain security!</para> </sect1> <sect1> - <title>Why is this better than security = server?</title> - - <para>Currently, domain security in Samba doesn't free you from - having to create local Unix users to represent the users attaching - to your server. This means that if domain user <constant>DOM\fred - </constant> attaches to your domain security Samba server, there needs - to be a local Unix user fred to represent that user in the Unix - filesystem. This is very similar to the older Samba security mode - <ulink url="smb.conf.5.html#SECURITYEQUALSSERVER">security = server</ulink>, - where Samba would pass through the authentication request to a Windows - NT server in the same way as a Windows 95 or Windows 98 server would. - </para> - - <para>Please refer to the <ulink url="winbind.html">Winbind - paper</ulink> for information on a system to automatically - assign UNIX uids and gids to Windows NT Domain users and groups. - </para> - - <para>The advantage to domain-level security is that the - authentication in domain-level security is passed down the authenticated - RPC channel in exactly the same way that an NT server would do it. This - means Samba servers now participate in domain trust relationships in - exactly the same way NT servers do (i.e., you can add Samba servers into - a resource domain and have the authentication passed on from a resource - domain PDC to an account domain PDC).</para> - - <para>In addition, with <command>security = server</command> every Samba - daemon on a server has to keep a connection open to the - authenticating server for as long as that daemon lasts. This can drain - the connection resources on a Microsoft NT server and cause it to run - out of available connections. With <command>security = domain</command>, - however, the Samba daemons connect to the PDC/BDC only for as long - as is necessary to authenticate the user, and then drop the connection, - thus conserving PDC connection resources.</para> - - <para>And finally, acting in the same manner as an NT server - authenticating to a PDC means that as part of the authentication - reply, the Samba server gets the user identification information such - as the user SID, the list of NT groups the user belongs to, etc. </para> - - <note><para> Much of the text of this document - was first published in the Web magazine <ulink url="http://www.linuxworld.com"> - LinuxWorld</ulink> as the article <ulink - url="http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.html">Doing - the NIS/NT Samba</ulink>.</para></note> +<title>Joining an NT4 type Domain with Samba-3</title> +<para><emphasis>Assumptions:</emphasis> +<programlisting> + NetBIOS name: SERV1 + Win2K/NT domain name: DOM + Domain's PDC NetBIOS name: DOMPDC + Domain's BDC NetBIOS names: DOMBDC1 and DOMBDC2 +</programlisting> +</para> + +<para>First, you must edit your &smb.conf; file to tell Samba it should +now use domain security.</para> + +<para>Change (or add) your <ulink url="smb.conf.5.html#SECURITY"> +<parameter>security =</parameter></ulink> line in the [global] section +of your &smb.conf; to read:</para> + +<para><command>security = domain</command></para> + +<para>Next change the <ulink url="smb.conf.5.html#WORKGROUP"><parameter> +workgroup =</parameter></ulink> line in the [global] section to read: </para> + +<para><command>workgroup = DOM</command></para> + +<para>as this is the name of the domain we are joining. </para> + +<para>You must also have the parameter <ulink url="smb.conf.5.html#ENCRYPTPASSWORDS"> +<parameter>encrypt passwords</parameter></ulink> set to <constant>yes +</constant> in order for your users to authenticate to the NT PDC.</para> + +<para>Finally, add (or modify) a <ulink url="smb.conf.5.html#PASSWORDSERVER"> +<parameter>password server =</parameter></ulink> line in the [global] +section to read: </para> + +<para><command>password server = DOMPDC DOMBDC1 DOMBDC2</command></para> + +<para>These are the primary and backup domain controllers Samba +will attempt to contact in order to authenticate users. Samba will +try to contact each of these servers in order, so you may want to +rearrange this list in order to spread out the authentication load +among domain controllers.</para> + +<para>Alternatively, if you want smbd to automatically determine +the list of Domain controllers to use for authentication, you may +set this line to be :</para> + +<para><command>password server = *</command></para> + +<para>This method, allows Samba to use exactly the same +mechanism that NT does. This +method either broadcasts or uses a WINS database in order to +find domain controllers to authenticate against.</para> + +<para>In order to actually join the domain, you must run this +command:</para> + +<para><prompt>root# </prompt><userinput>net join -S DOMPDC +-U<replaceable>Administrator%password</replaceable></userinput></para> + +<para> +If the <userinput>-S DOMPDC</userinput> argument is not given then +the domain name will be obtained from smb.conf. +</para> + +<para>as we are joining the domain DOM and the PDC for that domain +(the only machine that has write access to the domain SAM database) +is DOMPDC. The <replaceable>Administrator%password</replaceable> is +the login name and password for an account which has the necessary +privilege to add machines to the domain. If this is successful +you will see the message:</para> + +<para><computeroutput>Joined domain DOM.</computeroutput> +or <computeroutput>Joined 'SERV1' to realm 'MYREALM'</computeroutput> +</para> + +<para>in your terminal window. See the <ulink url="net.8.html"> +net(8)</ulink> man page for more details.</para> + +<para>This process joins the server to the domain +without having to create the machine trust account on the PDC +beforehand.</para> + +<para>This command goes through the machine account password +change protocol, then writes the new (random) machine account +password for this Samba server into a file in the same directory +in which an smbpasswd file would be stored - normally :</para> + +<para><filename>/usr/local/samba/private/secrets.tdb</filename></para> + +<para>This file is created and owned by root and is not +readable by any other user. It is the key to the domain-level +security for your system, and should be treated as carefully +as a shadow password file.</para> + +<para>Finally, restart your Samba daemons and get ready for +clients to begin using domain security!</para> + +<sect2> +<title>Why is this better than security = server?</title> + +<para>Currently, domain security in Samba doesn't free you from +having to create local Unix users to represent the users attaching +to your server. This means that if domain user <constant>DOM\fred +</constant> attaches to your domain security Samba server, there needs +to be a local Unix user fred to represent that user in the Unix +filesystem. This is very similar to the older Samba security mode +<ulink url="smb.conf.5.html#SECURITYEQUALSSERVER">security = server</ulink>, +where Samba would pass through the authentication request to a Windows +NT server in the same way as a Windows 95 or Windows 98 server would. +</para> + +<para>Please refer to the <ulink url="winbind.html">Winbind +paper</ulink> for information on a system to automatically +assign UNIX uids and gids to Windows NT Domain users and groups. +</para> + +<para>The advantage to domain-level security is that the +authentication in domain-level security is passed down the authenticated +RPC channel in exactly the same way that an NT server would do it. This +means Samba servers now participate in domain trust relationships in +exactly the same way NT servers do (i.e., you can add Samba servers into +a resource domain and have the authentication passed on from a resource +domain PDC to an account domain PDC).</para> + +<para>In addition, with <command>security = server</command> every Samba +daemon on a server has to keep a connection open to the +authenticating server for as long as that daemon lasts. This can drain +the connection resources on a Microsoft NT server and cause it to run +out of available connections. With <command>security = domain</command>, +however, the Samba daemons connect to the PDC/BDC only for as long +as is necessary to authenticate the user, and then drop the connection, +thus conserving PDC connection resources.</para> + +<para>And finally, acting in the same manner as an NT server +authenticating to a PDC means that as part of the authentication +reply, the Samba server gets the user identification information such +as the user SID, the list of NT groups the user belongs to, etc. </para> + +<note><para> Much of the text of this document +was first published in the Web magazine <ulink url="http://www.linuxworld.com"> +LinuxWorld</ulink> as the article <ulink +url="http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.html">Doing +the NIS/NT Samba</ulink>.</para></note> +</sect2> </sect1> +<sect1> +<title>Samba ADS Domain Membership</title> + +<para> +This is a rough guide to setting up Samba 3.0 with kerberos authentication against a +Windows2000 KDC. +</para> + +<sect2> +<title>Setup your <filename>smb.conf</filename></title> + +<para>You must use at least the following 3 options in smb.conf:</para> + +<para><programlisting> + realm = YOUR.KERBEROS.REALM + security = ADS + encrypt passwords = yes +</programlisting></para> + +<para> +In case samba can't figure out your ads server using your realm name, use the +<command>ads server</command> option in <filename>smb.conf</filename>: +<programlisting> + ads server = your.kerberos.server +</programlisting> +</para> + +<note><para>You do *not* need a smbpasswd file, and older clients will + be authenticated as if <command>security = domain</command>, + although it won't do any harm + and allows you to have local users not in the domain. + I expect that the above required options will change soon when we get better + active directory integration.</para></note> + +</sect2> + +<sect2> +<title>Setup your <filename>/etc/krb5.conf</filename></title> + +<para>Note: you will need the krb5 workstation, devel, and libs installed</para> + +<para>The minimal configuration for <filename>krb5.conf</filename> is:</para> + +<para><programlisting> + [realms] + YOUR.KERBEROS.REALM = { + kdc = your.kerberos.server + } +</programlisting></para> + +<para>Test your config by doing a <userinput>kinit +<replaceable>USERNAME</replaceable>@<replaceable>REALM</replaceable></userinput> and +making sure that your password is accepted by the Win2000 KDC. +</para> + +<note><para>The realm must be uppercase or you will get "Cannot find KDC for requested +realm while getting initial credentials" error </para></note> + +<note><para>Time between the two servers must be synchronized. You will get a +"kinit(v5): Clock skew too great while getting initial credentials" if the time +difference is more than five minutes. </para></note> + +<para> +You also must ensure that you can do a reverse DNS lookup on the IP +address of your KDC. Also, the name that this reverse lookup maps to +must either be the netbios name of the KDC (ie. the hostname with no +domain attached) or it can alternatively be the netbios name +followed by the realm. +</para> + +<para> +The easiest way to ensure you get this right is to add a +<filename>/etc/hosts</filename> entry mapping the IP address of your KDC to +its netbios name. If you don't get this right then you will get a +"local error" when you try to join the realm. +</para> + +<para> +If all you want is kerberos support in &smbclient; then you can skip +straight to <link linkend="ads-test-smbclient">Test with &smbclient;</link> now. +<link linkend="ads-create-machine-account">Creating a computer account</link> +and <link linkend="ads-test-server">testing your servers</link> +is only needed if you want kerberos support for &smbd; and &winbindd;. +</para> + +</sect2> + +<sect2 id="ads-create-machine-account"> +<title>Create the computer account</title> + +<para> +As a user that has write permission on the Samba private directory +(usually root) run: +<programlisting> + <userinput>net join -U Administrator%password</userinput> +</programlisting> +</para> + +<sect3> +<title>Possible errors</title> + +<para> +<variablelist> + <varlistentry><term>"ADS support not compiled in"</term> + <listitem><para>Samba must be reconfigured (remove config.cache) and recompiled + (make clean all install) after the kerberos libs and headers are installed. + </para></listitem></varlistentry> + + <varlistentry><term>net join prompts for user name</term> + <listitem><para>You need to login to the domain using <userinput>kinit + <replaceable>USERNAME</replaceable>@<replaceable>REALM</replaceable></userinput>. + <replaceable>USERNAME</replaceable> must be a user who has rights to add a machine + to the domain. </para></listitem></varlistentry> +</variablelist> +</para> + +</sect3> + +</sect2> + +<sect2 id="ads-test-server"> +<title>Test your server setup</title> + +<para> +If the join was successful, you will see a new computer account with the +NetBIOS name of your Samba server in Active Directory (in the "Computers" +folder under Users and Computers. +</para> + +<para> +On a Windows 2000 client try <userinput>net use * \\server\share</userinput>. You should +be logged in with kerberos without needing to know a password. If +this fails then run <userinput>klist tickets</userinput>. Did you get a ticket for the +server? Does it have an encoding type of DES-CBC-MD5 ? +</para> + +</sect2> + +<sect2 id="ads-test-smbclient"> +<title>Testing with &smbclient;</title> + +<para> +On your Samba server try to login to a Win2000 server or your Samba +server using &smbclient; and kerberos. Use &smbclient; as usual, but +specify the <parameter>-k</parameter> option to choose kerberos authentication. +</para> + +</sect2> + +<sect2> +<title>Notes</title> + +<para>You must change administrator password at least once after DC +install, to create the right encoding types</para> + +<para>w2k doesn't seem to create the _kerberos._udp and _ldap._tcp in + their defaults DNS setup. Maybe fixed in service packs?</para> +</sect2> + +</sect1> </chapter> diff --git a/docs/docbook/projdoc/Other-Clients.xml b/docs/docbook/projdoc/Other-Clients.xml index 068b9c0b32..b9f4cf3a93 100644 --- a/docs/docbook/projdoc/Other-Clients.xml +++ b/docs/docbook/projdoc/Other-Clients.xml @@ -310,7 +310,7 @@ likely occur if it is not. </para> <para> -In order to server profiles successfully to Windows 2000 SP2 +In order to serve profiles successfully to Windows 2000 SP2 clients (when not operating as a PDC), Samba must have <command>nt acl support = no</command> added to the file share which houses the roaming profiles. diff --git a/docs/docbook/projdoc/Samba-BDC-HOWTO.xml b/docs/docbook/projdoc/Samba-BDC-HOWTO.xml index 2f3b568471..cf5684feca 100644 --- a/docs/docbook/projdoc/Samba-BDC-HOWTO.xml +++ b/docs/docbook/projdoc/Samba-BDC-HOWTO.xml @@ -5,24 +5,15 @@ <pubdate> (26 Apr 2001) </pubdate> </chapterinfo> -<title> -Samba Backup Domain Controller to Samba Domain Control -</title> - -<sect1> -<title>Prerequisite Reading</title> +<title>Backup Domain Control</title> <para> -Before you continue reading in this chapter, please make sure +Before you continue reading in this section, please make sure that you are comfortable with configuring a Samba PDC as described in the <ulink url="Samba-PDC-HOWTO.html">Samba-PDC-HOWTO</ulink>. </para> - -</sect1> - <sect1> - <title>Background</title> <para> @@ -68,10 +59,7 @@ set along with settings for the profile path, the users home drive and others. This will not be covered in this document. </para> -</sect1> - - -<sect1> +<sect2> <title>What qualifies a Domain Controller on the network?</title> <para> @@ -85,6 +73,7 @@ Microsoft Domain implementation requires the domain master browser to be on the same machine as the PDC. </para> +</sect2> <sect2> <title>How does a Workstation find its domain controller?</title> @@ -236,6 +225,7 @@ password. </sect2> + <sect2> <title>Can I do this all with LDAP?</title> <para>The simple answer is YES. Samba's pdb_ldap code supports diff --git a/docs/docbook/projdoc/Samba-PDC-HOWTO.xml b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml index 0189b59f2e..9bbcb134b4 100644 --- a/docs/docbook/projdoc/Samba-PDC-HOWTO.xml +++ b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml @@ -14,13 +14,7 @@ <pubdate> (26 Apr 2001) </pubdate> </chapterinfo> -<title> -Samba as an NT4 or Win2k Primary Domain Controller -</title> - - -<sect1> -<title>Prerequisite Reading</title> +<title>Domain Control</title> <para> Before you continue reading in this chapter, please make sure @@ -30,16 +24,61 @@ encryption in Samba. Theses two topics are covered in the &smb.conf; manpage. </para> - -</sect1> - - - <sect1> <title> Background </title> +<sect2> +<title>Domain Controller</title> + +<para> +Over the years public perceptions of what Domain Control really is has taken on an +almost mystical nature. Before we branch into a brief overview of what Domain Control +is the following types of controller are known: +</para> + +<sect3> +<title>Domain Controller Types</title> + +<simplelist> + <member>Primary Domain Controller</member> + <member>Backup Domain Controller</member> + <member>ADS Domain Controller</member> +</simplelist> + +<para> +The <emphasis>Primary Domain Controller</emphasis> or PDC plays an important role in the MS +Windows NT3 and NT4 Domain Control architecture, but not in the manner that so many +expect. The PDC seeds the Domain Control database (a part of the Windows registry) and +it plays a key part in synchronisation of the domain authentication database. +</para> + +<para> +New to Samba-3.0.0 is the ability to use a back-end file that holds the same type of data as +the NT4 style SAM (Security Account Manager) database (one of the registry files). +The samba-3.0.0 SAM can be specified via the smb.conf file parameter "passwd backend" and +valid options include <emphasis> smbpasswd tdbsam ldapsam nisplussam plugin unixsam</emphasis>. +The smbpasswd, tdbsam and ldapsam options can have a "_nua" suffix to indicate that No Unix +Accounts need to be created. In other words, the Samba SAM will be independant of Unix/Linux +system accounts, provided a uid range is defined from which SAM accounts can be created. +</para> + +<para> +The <emphasis>Backup Domain Controller</emphasis> or BDC plays a key role in servicing network +authentication requests. The BDC is biased to answer logon requests so that on a network segment +that has a BDC and a PDC the BDC will be most likely to service network logon requests. The PDC will +answer network logon requests when the BDC is too busy (high load). A BDC can be promoted to +a PDC. If the PDC is on line at the time that the BDC is promoted to PDC the previous PDC is +automatically demoted to a BDC. +</para> + +<para> +At this time Samba is NOT capable of acting as an <emphasis>ADS Domain Controller</emphasis>. +</para> +</sect3> +</sect2> + <para> This article outlines the steps necessary for configuring Samba as a PDC. It is necessary to have a working Samba server prior to implementing the @@ -140,22 +179,19 @@ steps. </orderedlist> <para> -There are other minor details such as user profiles, system -policies, etc... However, these are not necessarily specific -to a Samba PDC as much as they are related to Windows NT networking -concepts. +There are other minor details such as user profiles, system policies, etc... +However, these are not necessarily specific to a Samba PDC as much as they are +related to Windows NT networking concepts. </para> </sect1> - <sect1> -<title>Configuring the Samba Domain Controller</title> +<title>Configuring Samba NT4 Style Domain Control</title> <para> -The first step in creating a working Samba PDC is to -understand the parameters necessary in smb.conf. Here we -attempt to explain the parameters that are covered in +The first step in creating a working Samba PDC is to understand the parameters necessary +in &smb.conf;. Here we attempt to explain the parameters that are covered in the &smb.conf; man page. </para> @@ -164,54 +200,53 @@ Here is an example &smb.conf; for acting as a PDC: </para> <para><programlisting> -[global] - ; Basic server settings - <ulink url="smb.conf.5.html#NETBIOSNAME">netbios name</ulink> = <replaceable>POGO</replaceable> - <ulink url="smb.conf.5.html#WORKGROUP">workgroup</ulink> = <replaceable>NARNIA</replaceable> - - ; User and Machine Account Backends - ; Choices are: tdbsam, tdbsam_nua, smbpasswd, smbpasswd_nua, ldapsam, ldapsam_nua, ... - ; mysqlsam, xmlsam, guest - <ulink url="smb.conf.5.html#PASSDBBACKEND">passdb backend</ulink> = ldapsam, guest - - ; we should act as the domain and local master browser - <ulink url="smb.conf.5.html#OSLEVEL">os level</ulink> = 64 - <ulink url="smb.conf.5.html#PERFERREDMASTER">preferred master</ulink> = yes - <ulink url="smb.conf.5.html#DOMAINMASTER">domain master</ulink> = yes - <ulink url="smb.conf.5.html#LOCALMASTER">local master</ulink> = yes - - ; security settings (must user security = user) - <ulink url="smb.conf.5.html#SECURITYEQUALSUSER">security</ulink> = user - - ; encrypted passwords are a requirement for a PDC - <ulink url="smb.conf.5.html#ENCRYPTPASSWORDS">encrypt passwords</ulink> = yes - - ; support domain logons - <ulink url="smb.conf.5.html#DOMAINLOGONS">domain logons</ulink> = yes - - ; where to store user profiles? - <ulink url="smb.conf.5.html#LOGONPATH">logon path</ulink> = \\%N\profiles\%u - - ; where is a user's home directory and where should it be mounted at? - <ulink url="smb.conf.5.html#LOGONDRIVE">logon drive</ulink> = H: - <ulink url="smb.conf.5.html#LOGONHOME">logon home</ulink> = \\homeserver\%u - - ; specify a generic logon script for all users - ; this is a relative **DOS** path to the [netlogon] share - <ulink url="smb.conf.5.html#LOGONSCRIPT">logon script</ulink> = logon.cmd - -; necessary share for domain controller -[netlogon] - <ulink url="smb.conf.5.html#PATH">path</ulink> = /usr/local/samba/lib/netlogon - <ulink url="smb.conf.5.html#READONLY">read only</ulink> = yes - <ulink url="smb.conf.5.html#WRITELIST">write list</ulink> = <replaceable>ntadmin</replaceable> - -; share for storing user profiles -[profiles] - <ulink url="smb.conf.5.html#PATH">path</ulink> = /export/smb/ntprofile - <ulink url="smb.conf.5.html#READONLY">read only</ulink> = no - <ulink url="smb.conf.5.html#CREATEMASK">create mask</ulink> = 0600 - <ulink url="smb.conf.5.html#DIRECTORYMASK">directory mask</ulink> = 0700 + [global] + ; Basic server settings + <ulink url="smb.conf.5.html#NETBIOSNAME">netbios name</ulink> = <replaceable>POGO</replaceable> + <ulink url="smb.conf.5.html#WORKGROUP">workgroup</ulink> = <replaceable>NARNIA</replaceable> + + ; User and Machine Account Backends + ; Choices are: tdbsam, smbpasswd, ldapsam, mysqlsam, xmlsam, guest + <ulink url="smb.conf.5.html#PASSDBBACKEND">passdb backend</ulink> = ldapsam, guest + + ; we should act as the domain and local master browser + <ulink url="smb.conf.5.html#OSLEVEL">os level</ulink> = 64 + <ulink url="smb.conf.5.html#PERFERREDMASTER">preferred master</ulink> = yes + <ulink url="smb.conf.5.html#DOMAINMASTER">domain master</ulink> = yes + <ulink url="smb.conf.5.html#LOCALMASTER">local master</ulink> = yes + + ; security settings (must user security = user) + <ulink url="smb.conf.5.html#SECURITYEQUALSUSER">security</ulink> = user + + ; encrypted passwords are a requirement for a PDC + <ulink url="smb.conf.5.html#ENCRYPTPASSWORDS">encrypt passwords</ulink> = yes + + ; support domain logons + <ulink url="smb.conf.5.html#DOMAINLOGONS">domain logons</ulink> = yes + + ; where to store user profiles? + <ulink url="smb.conf.5.html#LOGONPATH">logon path</ulink> = \\%N\profiles\%u + + ; where is a user's home directory and where should it be mounted at? + <ulink url="smb.conf.5.html#LOGONDRIVE">logon drive</ulink> = H: + <ulink url="smb.conf.5.html#LOGONHOME">logon home</ulink> = \\homeserver\%u + + ; specify a generic logon script for all users + ; this is a relative **DOS** path to the [netlogon] share + <ulink url="smb.conf.5.html#LOGONSCRIPT">logon script</ulink> = logon.cmd + + ; necessary share for domain controller + [netlogon] + <ulink url="smb.conf.5.html#PATH">path</ulink> = /usr/local/samba/lib/netlogon + <ulink url="smb.conf.5.html#READONLY">read only</ulink> = yes + <ulink url="smb.conf.5.html#WRITELIST">write list</ulink> = <replaceable>ntadmin</replaceable> + + ; share for storing user profiles + [profiles] + <ulink url="smb.conf.5.html#PATH">path</ulink> = /export/smb/ntprofile + <ulink url="smb.conf.5.html#READONLY">read only</ulink> = no + <ulink url="smb.conf.5.html#CREATEMASK">create mask</ulink> = 0600 + <ulink url="smb.conf.5.html#DIRECTORYMASK">directory mask</ulink> = 0700 </programlisting></para> <note><para> @@ -257,10 +292,7 @@ between Windows NT groups and Unix groups (this is really quite complicated to explain in a short space). </para> -</sect1> - - -<sect1> +<sect2> <title>Creating Machine Trust Accounts and Joining Clients to the Domain</title> <para> @@ -281,8 +313,13 @@ because it does not possess a machine trust account, and thus has no shared secret with the domain controller. </para> -<para>A Windows PDC stores each machine trust account in the Windows -Registry. A Samba-3 PDC also has to store machine trust account information +<para>A Windows NT4 PDC stores each machine trust account in the Windows +Registry. The introduction of MS Windows 2000 saw the introduction of Active Directory, +the new repository for machine trust accounts. +</para> + +<para> +A Samba-3 PDC also has to store machine trust account information in a suitable backend data store. With Samba-3 there can be multiple back-ends for this including: </para> @@ -297,13 +334,6 @@ for this including: </para></listitem> <listitem><para> - <emphasis>smbpasswd_nua</emphasis> - This file is independant of the - system wide user accounts. The use of this back-end option requires - specification of the "non unix account range" option also. It is called - smbpasswd and will be located in the <filename>private</filename> directory. - </para></listitem> - - <listitem><para> <emphasis>tdbsam</emphasis> - a binary database backend that will be stored in the <emphasis>private</emphasis> directory in a file called <emphasis>passwd.tdb</emphasis>. The key benefit of this binary format @@ -312,22 +342,9 @@ for this including: </para></listitem> <listitem><para> - <emphasis>tdbsam_nua</emphasis> like the smbpasswd_nua option above, this - file allows the creation of arbitrary user and machine accounts without - requiring that account to be added to the system (/etc/passwd) file. It - too requires the specification of the "non unix account range" option - in the [globals] section of the &smb.conf; file. - </para></listitem> - - <listitem><para> <emphasis>ldapsam</emphasis> - An LDAP based back-end. Permits the LDAP server to be specified. eg: ldap://localhost or ldap://frodo.murphy.com </para></listitem> - - <listitem><para> - <emphasis>ldapsam_nua</emphasis> - LDAP based back-end with no unix - account requirement, like smbpasswd_nua and tdbsam_nua above. - </para></listitem> </itemizedlist> <para>Read the chapter about the <link linkend="passdb">User Database</link> @@ -346,9 +363,8 @@ as follows: <itemizedlist> <listitem><para>A Samba account, stored in the same location as user - LanMan and NT password hashes (currently - <filename>smbpasswd</filename>). The Samba account - possesses and uses only the NT password hash.</para></listitem> + LanMan and NT password hashes (currently <filename>smbpasswd</filename>). + The Samba account possesses and uses only the NT password hash.</para></listitem> <listitem><para>A corresponding Unix account, typically stored in <filename>/etc/passwd</filename>. (Future releases will alleviate the need to @@ -373,7 +389,7 @@ There are two ways to create machine trust accounts: </itemizedlist> -<sect2> +<sect3> <title>Manual Creation of Machine Trust Accounts</title> <para> @@ -452,10 +468,10 @@ the corresponding Unix account. information to such clients. You have been warned! </para> </warning> -</sect2> +</sect3> -<sect2> +<sect3> <title>"On-the-Fly" Creation of Machine Trust Accounts</title> <para> @@ -482,10 +498,10 @@ be created manually. add machine script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u </programlisting></para> -</sect2> +</sect3> -<sect2><title>Joining the Client to the Domain</title> +<sect3><title>Joining the Client to the Domain</title> <para> The procedure for joining a client to the domain varies with the @@ -535,122 +551,17 @@ version of Windows. </para></listitem> </itemizedlist> +</sect3> </sect2> </sect1> <sect1> -<title>Common Problems and Errors</title> - -<sect2> -<title>I cannot include a '$' in a machine name</title> -<para> -A 'machine name' in (typically) <filename>/etc/passwd</filename> -of the machine name with a '$' appended. FreeBSD (and other BSD -systems?) won't create a user with a '$' in their name. -</para> - -<para> -The problem is only in the program used to make the entry. Once made, it works perfectly. -Create a user without the '$' using <command>vipw</command> to edit the entry, adding -the '$'. Or create the whole entry with vipw if you like, make sure you use a unique User ID! -</para> -</sect2> - -<sect2> -<title>I get told "You already have a connection to the Domain...." -or "Cannot join domain, the credentials supplied conflict with an -existing set.." when creating a machine trust account.</title> - -<para> -This happens if you try to create a machine trust account from the -machine itself and already have a connection (e.g. mapped drive) -to a share (or IPC$) on the Samba PDC. The following command -will remove all network drive connections: -</para> +<title>Samba ADS Domain Control</title> <para> -<prompt>C:\WINNT\></prompt> <command>net use * /d</command> +Not yet Freddie! </para> -<para> -Further, if the machine is already a 'member of a workgroup' that -is the same name as the domain you are joining (bad idea) you will -get this message. Change the workgroup name to something else, it -does not matter what, reboot, and try again. -</para> -</sect2> - -<sect2> -<title>The system can not log you on (C000019B)....</title> - -<para>I joined the domain successfully but after upgrading -to a newer version of the Samba code I get the message, "The system -can not log you on (C000019B), Please try again or consult your -system administrator" when attempting to logon. -</para> - -<para> -This occurs when the domain SID stored in the secrets.tdb database -is changed. The most common cause of a change in domain SID is when -the domain name and/or the server name (netbios name) is changed. -The only way to correct the problem is to restore the original domain -SID or remove the domain client from the domain and rejoin. The domain -SID may be reset using either the net or rpcclient utilities. -</para> - -<para> -The reset or change the domain SID you can use the net command as follows: - -<programlisting> - net getlocalsid 'OLDNAME' - net setlocalsid 'SID' -</programlisting> -</para> - -</sect2> - -<sect2> -<title>The machine trust account for this computer either does not -exist or is not accessible.</title> - -<para> -When I try to join the domain I get the message "The machine account -for this computer either does not exist or is not accessible". What's -wrong? -</para> - -<para> -This problem is caused by the PDC not having a suitable machine trust account. -If you are using the <parameter>add machine script</parameter> method to create -accounts then this would indicate that it has not worked. Ensure the domain -admin user system is working. -</para> - -<para> -Alternatively if you are creating account entries manually then they -have not been created correctly. Make sure that you have the entry -correct for the machine trust account in smbpasswd file on the Samba PDC. -If you added the account using an editor rather than using the smbpasswd -utility, make sure that the account name is the machine NetBIOS name -with a '$' appended to it ( i.e. computer_name$ ). There must be an entry -in both /etc/passwd and the smbpasswd file. Some people have reported -that inconsistent subnet masks between the Samba server and the NT -client have caused this problem. Make sure that these are consistent -for both client and server. -</para> -</sect2> - -<sect2> -<title>When I attempt to login to a Samba Domain from a NT4/W2K workstation, -I get a message about my account being disabled.</title> - -<para> -At first be ensure to enable the useraccounts with <command>smbpasswd -e -%user%</command>, this is normally done, when you create an account. -</para> - -</sect2> - </sect1> <sect1> @@ -767,11 +678,10 @@ worthwhile to look at how a Windows 9x/ME client performs a logon: <sect2> -<title>Configuration Instructions: Network Logons</title> +<title>Configuring Network Logon Capability</title> <para> -The main difference between a PDC and a Windows 9x logon -server configuration is that +The main difference between a PDC and a Windows 9x logon server configuration is that </para> <itemizedlist> @@ -787,8 +697,7 @@ Windows 9x/ME clients do not possess machine trust accounts. </itemizedlist> <para> -Therefore, a Samba PDC will also act as a Windows 9x logon -server. +Therefore, a Samba PDC will also act as a Windows 9x logon server. </para> @@ -839,4 +748,118 @@ for its domain. </sect2> </sect1> + +<sect1> +<title>Common Problems and Errors</title> + +<sect2> +<title>I cannot include a '$' in a machine name</title> +<para> +A 'machine name' in (typically) <filename>/etc/passwd</filename> +of the machine name with a '$' appended. FreeBSD (and other BSD +systems?) won't create a user with a '$' in their name. +</para> + +<para> +The problem is only in the program used to make the entry. Once made, it works perfectly. +Create a user without the '$' using <command>vipw</command> to edit the entry, adding +the '$'. Or create the whole entry with vipw if you like, make sure you use a unique User ID! +</para> +</sect2> + +<sect2> +<title>I get told "You already have a connection to the Domain...." +or "Cannot join domain, the credentials supplied conflict with an +existing set.." when creating a machine trust account.</title> + +<para> +This happens if you try to create a machine trust account from the +machine itself and already have a connection (e.g. mapped drive) +to a share (or IPC$) on the Samba PDC. The following command +will remove all network drive connections: +</para> + +<para> +<prompt>C:\WINNT\></prompt> <command>net use * /d</command> +</para> + +<para> +Further, if the machine is already a 'member of a workgroup' that +is the same name as the domain you are joining (bad idea) you will +get this message. Change the workgroup name to something else, it +does not matter what, reboot, and try again. +</para> +</sect2> + +<sect2> +<title>The system can not log you on (C000019B)....</title> + +<para>I joined the domain successfully but after upgrading +to a newer version of the Samba code I get the message, "The system +can not log you on (C000019B), Please try again or consult your +system administrator" when attempting to logon. +</para> + +<para> +This occurs when the domain SID stored in the secrets.tdb database +is changed. The most common cause of a change in domain SID is when +the domain name and/or the server name (netbios name) is changed. +The only way to correct the problem is to restore the original domain +SID or remove the domain client from the domain and rejoin. The domain +SID may be reset using either the net or rpcclient utilities. +</para> + +<para> +The reset or change the domain SID you can use the net command as follows: + +<programlisting> + net getlocalsid 'OLDNAME' + net setlocalsid 'SID' +</programlisting> +</para> + +</sect2> + +<sect2> +<title>The machine trust account for this computer either does not +exist or is not accessible.</title> + +<para> +When I try to join the domain I get the message "The machine account +for this computer either does not exist or is not accessible". What's +wrong? +</para> + +<para> +This problem is caused by the PDC not having a suitable machine trust account. +If you are using the <parameter>add machine script</parameter> method to create +accounts then this would indicate that it has not worked. Ensure the domain +admin user system is working. +</para> + +<para> +Alternatively if you are creating account entries manually then they +have not been created correctly. Make sure that you have the entry +correct for the machine trust account in smbpasswd file on the Samba PDC. +If you added the account using an editor rather than using the smbpasswd +utility, make sure that the account name is the machine NetBIOS name +with a '$' appended to it ( i.e. computer_name$ ). There must be an entry +in both /etc/passwd and the smbpasswd file. Some people have reported +that inconsistent subnet masks between the Samba server and the NT +client have caused this problem. Make sure that these are consistent +for both client and server. +</para> +</sect2> + +<sect2> +<title>When I attempt to login to a Samba Domain from a NT4/W2K workstation, +I get a message about my account being disabled.</title> + +<para> +At first be ensure to enable the useraccounts with <command>smbpasswd -e +%user%</command>, this is normally done, when you create an account. +</para> + +</sect2> +</sect1> </chapter> diff --git a/docs/docbook/projdoc/ServerType.xml b/docs/docbook/projdoc/ServerType.xml index 7229a50201..2a745733a6 100644 --- a/docs/docbook/projdoc/ServerType.xml +++ b/docs/docbook/projdoc/ServerType.xml @@ -1,16 +1,31 @@ <chapter id="ServerType"> <chapterinfo> + &author.tridge; + &author.jelmer; &author.jht; </chapterinfo> -<title>Nomenclature of Server Types</title> +<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 to +use Samba will want to know what within a Samba context, terms familiar to MS Windows +adminstrator mean. +</para> + +<para> +The chapter also provides an overview of the security modes of which Samba is capable +and how these relate to MS Windows servers and clients. +</para> + +<sect1> +<title>Server Types</title> <para>Adminstrators of Microsoft networks often refer to there being three different type of servers:</para> <itemizedlist> - <listitem><para>Stand Alone Server</para></listitem> - <listitem><para>Domain Member Server</para></listitem> <listitem><para>Domain Controller</para> <itemizedlist> <listitem><para>Primary Domain Controller</para></listitem> @@ -18,126 +33,423 @@ different type of servers:</para> <listitem><para>ADS Domain Controller</para></listitem> </itemizedlist> </listitem> + <listitem><para>Domain Member Server</para> + <itemizedlist> + <listitem><para>Active Directory Member Server</para></listitem> + <listitem><para>NT4 Style Domain Member Server</para></listitem> + </itemizedlist> + </listitem> + <listitem><para>Stand Alone Server</para></listitem> </itemizedlist> -<para>A network administrator who is familiar with these terms and who -wishes to migrate to or use Samba will want to know what these terms mean -within a Samba context.</para> +<para> +The chapters covering Domain Control, Backup Domain Control and Domain Membership provide +pertinent information regarding Samba-3 configuration for each of these server roles. +The reader is strongly encouraged to become intimately familiar with the information +presented. +</para> + +</sect1> <sect1> -<title>Stand Alone Server</title> +<title>Samba Security Modes</title> + +<para> +In this section the function and purpose of Samba's <emphasis>security</emphasis> +modes are described. An acurate 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> -The term <emphasis>stand alone server</emphasis> means that the server -will provide local authentication and access control for all resources -that are available from it. In general this means that there will be a -local user database. In more technical terms, it means that resources -on the machine will either be made available in either SHARE mode or in -USER mode. SHARE mode and USER mode security are documented under -discussions regarding "security mode". The smb.conf configuration parameters -that control security mode are: "security = user" and "security = share". +A SMB server tells the client at startup what <emphasis>security level</emphasis> +it is running. There are two options <emphasis>share level</emphasis> and +<emphasis>user level</emphasis>. 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> -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. +We will describe<emphasis>user level</emphasis> security first, as its simpler. +In <emphasis>user level</emphasis> security the client will send a +<emphasis>session setup</emphasis> 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 +<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> -Samba tends to blur the distinction a little in respect of what is -a stand alone server. This is because the authentication database may be -local or on a remote server, even if from the samba protocol perspective -the samba server is NOT a member of a domain security context. +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> -Through the use of PAM (Pluggable Authentication Modules) and nsswitch -(the name service switcher) the source of authentication may reside on -another server. We would be inclined to call this the authentication server. -This means that the samba server may use the local Unix/Linux system -password database (/etc/passwd or /etc/shadow), may use a local smbpasswd -file (/etc/samba/smbpasswd or /usr/local/samba/lib/private/smbpasswd), or -may use an LDAP back end, or even via PAM and Winbind another CIFS/SMB -server for authentication. +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> -</sect1> +<sect3> +<title>Example Configuration</title> -<sect1> -<title>Domain Member Server</title> +<para> +The &smb.conf; parameter that sets <emphasis>User Level Security</emphasis> is: +</para> + +<para><programlisting> + security = user +</programlisting></para> <para> -This mode of server operation involves the samba machine being made a member -of a domain security context. This means by definition that all user authentication -will be done from a centrally defined authentication regime. The authentication -regime may come from an NT3/4 style (old domain technology) server, or it may be -provided from an Active Directory server (ADS) running on MS Windows 2000 or later. +This is the default setting since samba-2.2.x. </para> -<para><emphasis> -Of course it should be clear that the authentication back end itself could be from any -distributed directory architecture server that is supported by Samba. This can be -LDAP (from OpenLDAP), or Sun's iPlanet, of NetWare Directory Server, etc. -</emphasis></para> +</sect3> + +</sect2> +<sect2> +<title>Share Level Security</title> <para> -Please refer to the section on Howto configure Samba as a Primary Domain Controller -and for more information regarding how to create a domain machine account for a -domain member server as well as for information regarding how to enable the samba -domain member machine to join the domain and to be fully trusted by it. +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 +<emphasis>tree connection</emphasis> (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 pair that is authenticated, not a share/password pair. </para> -</sect1> +<para> +To gain understanding of the MS Windows networking parallels to this, 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> -<sect1> -<title>Domain Controller</title> +<para> +Many clients send a <emphasis>session setup</emphasis> 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 <emphasis>possible usernames</emphasis>. When the client +then does a <emphasis>tree connection</emphasis> 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 <command>user =</command> &smb.conf; line. The password is then checked +in turn against these <emphasis>possible usernames</emphasis>. If a match is found +then the client is authenticated as that user. +</para> + +<sect3> +<title>Example Configuration</title> <para> -Over the years public perceptions of what Domain Control really is has taken on an -almost mystical nature. Before we branch into a brief overview of what Domain Control -is the following types of controller are known: +The &smb.conf; parameter that sets <emphasis>Share Level Security</emphasis> is: </para> +<para><programlisting> + security = share +</programlisting></para> + +<para> +Plese note that there are reports that recent MS Widows clients do not like to work +with share mode security servers. You are strongly discouraged from use of this parameter. +</para> + +</sect3> +</sect2> + <sect2> -<title>Domain Controller Types</title> +<title>Server Level Security</title> + +<para> +Now to review <emphasis>server level</emphasis> security. In server level security the samba +server reports to the client that it is in user level security. The client then does a +<emphasis>session setup</emphasis> as described earlier. The samba server takes the +username/password that the client sends and attempts to login to the +<emphasis>password server</emphasis> 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 <emphasis>password server</emphasis>. +</para> + +<para> +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. Samba supports this type of encryption by default. +</para> + +<para> +The parameter <emphasis>security = server</emphasis> 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 <emphasis>password server</emphasis> 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. +</para> + +<note><para> +When Samba is running in <emphasis>server level</emphasis> security it is essential that +the parameter <emphasis>password server</emphasis> is set to the precise netbios machine +name of the target authentication server. Samba can NOT determine this from NetBIOS name +lookups because the choice of the target authentication server arbitrary and can not +be determined from a domain name. In essence a samba server that is in +<emphasis>server level</emphasis> security is operating in what used to be known as +workgroup mode. +</para></note> -<simplelist> - <member>Primary Domain Controller</member> - <member>Backup Domain Controller</member> - <member>ADS Domain Controller</member> -</simplelist> +<note><para> +<emphasis>Server level</emphasis> security is incompatible with what is known as +<emphasis>schannel</emphasis> or <emphasis>sign and seal</emphasis> protocols. This means that +if you want to use <emphasis>server</emphasis> level security you must disable the use of +<emphasis>sign and seal</emphasis> on all machines on your network. +</para></note> + +<sect3> +<title>Example Configuration - Using MS Windows NT as an authentication server</title> <para> -The <emphasis>Primary Domain Controller</emphasis> or PDC plays an important role in the MS -Windows NT3 and NT4 Domain Control architecture, but not in the manner that so many -expect. The PDC seeds the Domain Control database (a part of the Windows registry) and -it plays a key part in synchronisation of the domain authentication database. +This method involves the additions of the following parameters in the &smb.conf; file: </para> +<para><programlisting> + encrypt passwords = Yes + security = server + password server = "NetBIOS_name_of_a_DC" +</programlisting></para> + + <para> -New to Samba-3.0.0 is the ability to use a back-end file that holds the same type of data as -the NT4 style SAM (Security Account Manager) database (one of the registry files). -The samba-3.0.0 SAM can be specified via the smb.conf file parameter "passwd backend" and -valid options include <emphasis> smbpasswd tdbsam ldapsam nisplussam plugin unixsam</emphasis>. -The smbpasswd, tdbsam and ldapsam options can have a "_nua" suffix to indicate that No Unix -Accounts need to be created. In other words, the Samba SAM will be independant of Unix/Linux -system accounts, provided a uid range is defined from which SAM accounts can be created. +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. </para> <para> -The <emphasis>Backup Domain Controller</emphasis> or BDC plays a key role in servicing network -authentication requests. The BDC is biased to answer logon requests so that on a network segment -that has a BDC and a PDC the BDC will be most likely to service network logon requests. The PDC will -answer network logon requests when the BDC is too busy (high load). A BDC can be promoted to -a PDC. If the PDC is on line at the time that the BDC is promoted to PDC the previous PDC is -automatically demoted to a BDC. +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. </para> <para> -At this time Samba is NOT capable of acting as an <emphasis>ADS Domain Controller</emphasis>. +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. </para> + +</sect3> </sect2> + +<sect2> +<title>Domain Level Security</title> + +<para> +When samba is operating in <emphasis>security = domain</emphasis> 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. +</para> + +<sect3> +<title>Example Configuration - Samba as a Domain Member Server</title> + +<para> +This method involves addition of the following parameters in the &smb.conf; file: +</para> + +<para><programlisting> + encrypt passwords = Yes + security = domain + workgroup = "name_of_NT_domain" + password server = * +</programlisting></para> + +<para> +The use of the "*" argument to <command>password server</command> 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. +</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: +</para> + +<itemizedlist> + <listitem><para>On the MS Windows NT domain controller using + the Server Manager add a machine account for the Samba server. + </para></listitem> + + <listitem><para>Next, on the Linux system execute:</para> + <para><programlisting> + <command>smbpasswd -r PDC_NAME -j DOMAIN_NAME</command> (samba 2.x) + + <command>net join -U administrator%password</command> (samba-3) + </programlisting> + </para> + </listitem> +</itemizedlist> + +<para> +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 +<filename>/etc/passwd</filename> entry. +</para> + +<para> +An alternative to assigning UIDs to Windows users on a Samba member server is +presented in the <link linkend="winbind">Winbind Overview</link> chapter +in this HOWTO collection. +</para> + +</sect3> +</sect2> + +<sect2> +<title>ADS Level Security</title> + +<para> +Samba-2.2.x could join and Active Directory domain so long as the Active Directory domain +controller is configured for mixed mode operation, and is running NetBIOS over TCP/IP. MS +Windows 2000 and later can be configured to run without NEtBIOS over TCP/IP, instead it +can run SMB natively over TCP/IP. +</para> + +<para> +The ability to natively join an Active Directory domain requires the use of Kerberos +based authentication. The Kerberos protocols have been extended by Microsoft so that +a plain MIT Kerberos, or a Heimdal client is not sufficient. Samba-3 now has the ability +to be a native Active Directory member server. +</para> + +<sect3> +<title>Example Configuration</title> + +<para> +<programlisting> + realm = your.kerberos.realm + security = ADS + encrypt passwords = Yes + +The following parameter may be required: + + ads server = your.kerberos.server +</programlisting> +</para> + +<para> +Please refer to the Domain Membership section, Active Directory Membership for more information +regarding this configuration option. +</para> + +</sect3> +</sect2> +</sect1> + +<sect1> +<title>Seamless Windows Network Integration</title> + +<para> +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. +</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 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. + </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 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. +</para> + +<para> +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. +</para> + +<para><programlisting> + <ulink url="smb.conf.5.html#PASSWORDLEVEL">passsword level</ulink> = <replaceable>integer</replaceable> + <ulink url="smb.conf.5.html#USERNAMELEVEL">username level</ulink> = <replaceable>integer</replaceable> +</programlisting></para> + +<para> +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 <parameter>username level</parameter> 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 client to connect to a Samba +server using clear text authentication, the <parameter>password level</parameter> +must be set to the maximum number of upper case letter which <emphasis>could</emphasis> +appear is a password. Note that the server OS uses the traditional DES version +of crypt(), a <parameter>password level</parameter> 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 where ever +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> </chapter> diff --git a/docs/docbook/projdoc/Speed.xml b/docs/docbook/projdoc/Speed.xml index 078f068bae..327aeff8c9 100644 --- a/docs/docbook/projdoc/Speed.xml +++ b/docs/docbook/projdoc/Speed.xml @@ -217,7 +217,4 @@ performance. Check the sections on the various clients in </sect1> -<sect1> -<title> - </chapter> diff --git a/docs/docbook/projdoc/StandAloneServer.xml b/docs/docbook/projdoc/StandAloneServer.xml new file mode 100644 index 0000000000..c5b5c67250 --- /dev/null +++ b/docs/docbook/projdoc/StandAloneServer.xml @@ -0,0 +1,47 @@ +<chapter id="StandAloneServer"> +<chapterinfo> + &author.jht; +</chapterinfo> +<title>Stand-Alone Servers</title> + +<sect1> +<title>Stand Alone Server</title> + +<para> +The term <emphasis>stand alone server</emphasis> means that the server +will provide local authentication and access control for all resources +that are available from it. In general this means that there will be a +local user database. In more technical terms, it means that resources +on the machine will either be made available in either SHARE mode or in +USER mode. SHARE mode and USER mode security are documented under +discussions regarding "security mode". The smb.conf configuration parameters +that control security mode are: "security = user" and "security = share". +</para> + +<para> +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. +</para> + +<para> +Samba tends to blur the distinction a little in respect of what is +a stand alone server. This is because the authentication database may be +local or on a remote server, even if from the samba protocol perspective +the samba server is NOT a member of a domain security context. +</para> + +<para> +Through the use of PAM (Pluggable Authentication Modules) and nsswitch +(the name service switcher) the source of authentication may reside on +another server. We would be inclined to call this the authentication server. +This means that the samba server may use the local Unix/Linux system +password database (/etc/passwd or /etc/shadow), may use a local smbpasswd +file (/etc/samba/smbpasswd or /usr/local/samba/lib/private/smbpasswd), or +may use an LDAP back end, or even via PAM and Winbind another CIFS/SMB +server for authentication. +</para> + +</sect1> +</chapter> diff --git a/docs/docbook/projdoc/samba-doc.xml b/docs/docbook/projdoc/samba-doc.xml index 8d910eaf0d..bf120d3c68 100644 --- a/docs/docbook/projdoc/samba-doc.xml +++ b/docs/docbook/projdoc/samba-doc.xml @@ -79,11 +79,10 @@ section carefully. </para> </partintro> &ServerType; -&SECURITY-LEVEL; &Samba-PDC-HOWTO; &Samba-BDC-HOWTO; -&ADS-HOWTO; &DOMAIN-MEMBER; +&StandAloneServer; </part> <part id="optional"> diff --git a/docs/docbook/projdoc/securing-samba.xml b/docs/docbook/projdoc/securing-samba.xml index d320767a77..204fceeb4a 100644 --- a/docs/docbook/projdoc/securing-samba.xml +++ b/docs/docbook/projdoc/securing-samba.xml @@ -52,6 +52,25 @@ as the client sends its first packet. The refusal will be marked as a </sect1> <sect1> +<title>User based protection</title> + +<para> +If you want to restrict access to your server to valid users only then the following +method may be of use. In the smb.conf [globals] section put: +</para> + +<para><programlisting> + valid users = @smbusers, jacko +</programlisting></para> + +<para> +What this does is, it restricts all server access to either the user <emphasis>jacko</emphasis> +or to members of the system group <emphasis>smbusers</emphasis>. +</para> + +</sect1> + +<sect1> <title>Using interface protection</title> diff --git a/docs/docbook/projdoc/security_level.xml b/docs/docbook/projdoc/security_level.xml deleted file mode 100644 index 528c87c52c..0000000000 --- a/docs/docbook/projdoc/security_level.xml +++ /dev/null @@ -1,340 +0,0 @@ -<chapter id="securitylevels"> -<chapterinfo> - &author.tridge; - &author.jelmer; -</chapterinfo> -<title>Samba as Stand-Alone Server</title> - -<para> -In this section the function and purpose of Samba's <emphasis>security</emphasis> -modes are described. -</para> - -<sect1> -<title>User and Share security level</title> - -<para> -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. -</para> - -<sect2> -<title>User Level Security</title> - -<para> -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: -</para> - -<orderedlist> -<listitem><para>the username/password</para></listitem> -<listitem><para>the machine that the client is coming from</para></listitem> -</orderedlist> - -<para> -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". -</para> - -<para> -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) -</para> - -</sect2> - -<sect2> -<title>Share Level Security</title> - -<para> -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". -</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 <command>user =</command> &smb.conf; -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. -</para> - -</sect2> - -<sect2> -<title>Server Level Security</title> - -<para> -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". -</para> - -<para> -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. -</para> - -<para> -"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. -</para> - -<note><para> -<emphasis>Server</emphasis> level security is incompatible with what is known -as <emphasis>schannel</emphasis> or "sign and seal" protocols. This means that -if you want to use <emphasis>server</emphasis> level security you must disable -the use of "sign and seal" on all machines on your network. -</para></note> - -<sect3> -<title>Configuring Samba for Seemless Windows Network Integration</title> - -<para> -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. -</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 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. - </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 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. -</para> - -<para> -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. -</para> - -<para><programlisting> - <ulink url="smb.conf.5.html#PASSWORDLEVEL">passsword level</ulink> = <replaceable>integer</replaceable> - <ulink url="smb.conf.5.html#USERNAMELEVEL">username level</ulink> = <replaceable>integer</replaceable> -</programlisting></para> - -<para> -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 <parameter>username level</parameter> 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 client to connect to a Samba -server using clear text authentication, the <parameter>password level</parameter> -must be set to the maximum number of upper case letter which <emphasis>could</emphasis> -appear is a password. Note that the server OS uses the traditional DES version -of crypt(), a <parameter>password level</parameter> 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 -where ever Samba is used. There are three configuration possibilities -for support of encrypted passwords: -</para> - -</sect3> -<sect3> -<title>Use MS Windows NT as an authentication server</title> - -<para> -This method involves the additions of the following parameters in the &smb.conf; file: -</para> - -<para><programlisting> - encrypt passwords = Yes - security = server - password server = "NetBIOS_name_of_PDC" -</programlisting></para> - - -<para> -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. -</para> - -<para> -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. -</para> - -<para> -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. -</para> - -</sect3> -</sect2> - -<sect2> -<title>Domain Level Security</title> - -<para> -When samba is operating in <emphasis>security = domain</emphasis> 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. -</para> - -<sect3> -<title>Samba as a member of an MS Windows NT security domain</title> - -<para> -This method involves addition of the following parameters in the &smb.conf; file: -</para> - -<para><programlisting> - encrypt passwords = Yes - security = domain - workgroup = "name of NT domain" - password server = * -</programlisting></para> - -<para> -The use of the "*" argument to <command>password server</command> 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. -</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: -</para> - -<itemizedlist> - <listitem><para>On the MS Windows NT domain controller using - the Server Manager add a machine account for the Samba server. - </para></listitem> - - <listitem><para>Next, on the Linux system execute: - <command>smbpasswd -r PDC_NAME -j DOMAIN_NAME</command> (samba 2.x) - - <command>net join -U administrator%password</command> (samba-3) - </para></listitem> -</itemizedlist> - -<para> -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 -<filename>/etc/passwd</filename> entry. -</para> - -<para> -An alternative to assigning UIDs to Windows users on a Samba member server is -presented in the <link linkend="winbind">Winbind Overview</link> chapter -in this HOWTO collection. -</para> - -</sect3> -</sect2> - -<sect2> -<title>ADS Level Security</title> - -<para> -For information about the configuration option please refer to the entire section entitled -<emphasis>Samba as an ADS Domain Member.</emphasis> -</para> - -</sect2> -</sect1> -</chapter> |