<!ENTITY ID-Samba-LDAP SYSTEM "samba-ldap-howto">
<!ENTITY ID-Diagnosis SYSTEM "diagnosis">
<!ENTITY ID-BUGS SYSTEM "bugreport">
-<!ENTITY ID-SECURITY-LEVEL SYSTEM "securitylevels">
+<!ENTITY ID-StandAloneServer SYSTEM "standaloneserver">
<!ENTITY ID-SPEED SYSTEM "speed">
<!ENTITY ID-NetworkBrowsing SYSTEM "network-browsing">
<!ENTITY ID-GROUP-MAPPING-HOWTO SYSTEM "groupmapping">
<!ENTITY ID-Portability SYSTEM "Portability">
<!ENTITY ID-Other-Clients SYSTEM "Other-Clients">
-<!ENTITY ID-ADS-HOWTO SYSTEM "ADS">
<!ENTITY ID-pdb-mysql SYSTEM "pdb-mysql">
<!ENTITY ID-pdb-xml SYSTEM "pdb-xml">
<!ENTITY ID-VFS SYSTEM "VFS">
+<!ENTITY ID-Further-Resources SYSTEM "further-resources">
<!ENTITY MANUALPAGES SYSTEM "manpages/manuals.xml">
<!ENTITY MAN-FINDSMB SYSTEM "manpages/findsmb.1.xml">
<!ENTITY MAN-WINBINDD SYSTEM "manpages/winbindd.8.xml">
-<!ENTITY ADS-HOWTO SYSTEM "projdoc/ADS-HOWTO.xml">
<!ENTITY AdvancedNetworkAdmin SYSTEM "projdoc/AdvancedNetworkAdmin.xml">
-<!ENTITY NetworkBrowsing SYSTEM "projdoc/NetworkBrowsing.xml">
<!ENTITY BUGS SYSTEM "projdoc/Bugs.xml">
<!ENTITY CUPS SYSTEM "projdoc/CUPS-printing.xml">
<!ENTITY CVS-Access SYSTEM "projdoc/CVS-Access.xml">
<!ENTITY DOMAIN-MEMBER SYSTEM "projdoc/DOMAIN_MEMBER.xml">
<!ENTITY Diagnosis SYSTEM "projdoc/Diagnosis.xml">
<!ENTITY ENCRYPTION SYSTEM "projdoc/ENCRYPTION.xml">
+<!ENTITY Further-Resources SYSTEM "projdoc/Further-Resources.xml">
<!ENTITY GROUP-MAPPING-HOWTO SYSTEM "projdoc/GROUP-MAPPING-HOWTO.xml">
<!ENTITY IntegratingWithWindows SYSTEM "projdoc/Integrating-with-Windows.xml">
<!ENTITY IntroSMB SYSTEM "projdoc/IntroSMB.xml">
-<!ENTITY locking SYSTEM "projdoc/locking.xml">
<!ENTITY MS-Dfs-Setup SYSTEM "projdoc/msdfs_setup.xml">
<!ENTITY NT-Security SYSTEM "projdoc/NT_Security.xml">
<!ENTITY NT4Migration SYSTEM "projdoc/NT4Migration.xml">
+<!ENTITY NetworkBrowsing SYSTEM "projdoc/NetworkBrowsing.xml">
<!ENTITY Other-Clients SYSTEM "projdoc/Other-Clients.xml">
<!ENTITY PRINTER-DRIVER2 SYSTEM "projdoc/printer_driver2.xml">
<!ENTITY Passdb SYSTEM "projdoc/passdb.xml">
<!ENTITY PolicyMgmt SYSTEM "projdoc/PolicyMgmt.xml">
<!ENTITY Portability SYSTEM "projdoc/Portability.xml">
<!ENTITY ProfileMgmt SYSTEM "projdoc/ProfileMgmt.xml">
-<!ENTITY SECURITY-LEVEL SYSTEM "projdoc/security_level.xml">
<!ENTITY SPEED SYSTEM "projdoc/Speed.xml">
<!ENTITY SWAT SYSTEM "projdoc/SWAT.xml">
<!ENTITY Samba-BDC-HOWTO SYSTEM "projdoc/Samba-BDC-HOWTO.xml">
<!ENTITY Samba-PDC-HOWTO SYSTEM "projdoc/Samba-PDC-HOWTO.xml">
<!ENTITY SecuringSamba SYSTEM "projdoc/securing-samba.xml">
<!ENTITY ServerType SYSTEM "projdoc/ServerType.xml">
+<!ENTITY StandAloneServer SYSTEM "projdoc/StandAloneServer.xml">
<!ENTITY Trusts SYSTEM "projdoc/InterdomainTrusts.xml">
<!ENTITY UNIX-INSTALL SYSTEM "projdoc/UNIX_INSTALL.xml">
<!ENTITY VFS SYSTEM "projdoc/VFS.xml">
<!ENTITY WINBIND SYSTEM "projdoc/winbind.xml">
+<!ENTITY locking SYSTEM "projdoc/locking.xml">
<!ENTITY pdb-mysql SYSTEM "projdoc/pdb_mysql.xml">
<!ENTITY pdb.xml SYSTEM "projdoc/pdb.xml.xml">
<!ENTITY problems SYSTEM "projdoc/Problems.xml">
+++ /dev/null
-<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>
<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>
</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.
<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>
others. This will not be covered in this document.
</para>
-</sect1>
-
-
-<sect1>
+<sect2>
<title>What qualifies a Domain Controller on the network?</title>
<para>
be on the same machine as the PDC.
</para>
+</sect2>
<sect2>
<title>How does a Workstation find its domain controller?</title>
</sect2>
+
<sect2>
<title>Can I do this all with LDAP?</title>
<para>The simple answer is YES. Samba's pdb_ldap code supports
<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
&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
</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>
</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>
complicated to explain in a short space).
</para>
-</sect1>
-
-
-<sect1>
+<sect2>
<title>Creating Machine Trust Accounts and Joining Clients to the Domain</title>
<para>
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>
directory (default is /usr/local/samba/lib/private or on linux /etc/samba).
</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
in the traditional plain text smbpasswd file.
</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>
<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
</itemizedlist>
-<sect2>
+<sect3>
<title>Manual Creation of Machine Trust Accounts</title>
<para>
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>
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
</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>
<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>
</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>
</para>
</warning>
+</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>
<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>
<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>
</para>
</partintro>
&ServerType;
-&SECURITY-LEVEL;
&Samba-PDC-HOWTO;
&Samba-BDC-HOWTO;
-&ADS-HOWTO;
&DOMAIN-MEMBER;
+&StandAloneServer;
</part>
<part id="optional">
</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>
+++ /dev/null
-<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>
git.samba.org / sfrench / samba-autobuild / .git / commitdiff