--- /dev/null
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+
+<book>
+
+<bookinfo>
+ <author><firstname>Jeremy</firstname><surname>Allison</surname></author>
+ <pubdate>7th Oct 1999</pubdate>
+</bookinfo>
+
+<sect1>
+
+ <title>Joining an NT Domain with Samba 2.2</emphasis></title>
+
+ <para>In order for a Samba-2 server to join an NT domain,
+ you must first add the NetBIOS name of the Samba server to the
+ NT domain on the PDC using Server Manager for Domains. This creates
+ the machine account in the domain (PDC) SAM. Note that you should
+ add the Samba server as a "Windows NT Workstation or Server",
+ <emphasis>NOT</emphasis> as a Primary or backup domain controller.</para>
+
+ <para>Assume you have a Samba-2 server with a NetBIOS name of
+ <constant>SERV1</constant> and are joining an NT domain called
+ <constant>DOM</constant>, which has a PDC with a NetBIOS name
+ of <constant>DOMPDC</constant> and two backup domain controllers
+ with NetBIOS names <constant>DOMBDC1</constant> and <constant>DOMBDC2
+ </constant>.</para>
+
+ <para>In order to join the domain, first stop all Samba daemons
+ and run the command:</para>
+
+ <para><prompt>root# </prompt><userinput>smbpasswd -j DOM -r DOMPDC
+ </userinput></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. If this is successful you will see the message:</para>
+
+ <para><computeroutput>smbpasswd: Joined domain DOM.</computeroutput>
+ </para>
+
+ <para>in your terminal window. See the <ulink url="smbpasswd.8.html">
+ smbpasswd(8)</ulink> man page for more details.</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</filename></para>
+
+ <para>In Samba 2.0.x, the filename looks like this:</para>
+
+ <para><filename><replaceable><NT DOMAIN NAME></replaceable>.
+ <replaceable><Samba Server Name></replaceable>.mac</filename></para>
+
+ <para>The <filename>.mac</filename> suffix stands for machine account
+ password file. So in our example above, the file would be called:</para>
+
+ <para><filename>DOM.SERV1.mac</filename></para>
+
+ <para>In Samba 2.2, this file has been replaced with a TDB
+ (Trivial Database) file named <filename>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>Now, before restarting the Samba daemons you must
+ edit your <ulink url="smb.conf.5.html"><filename>smb.conf(5)</filename>
+ </ulink> 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, which was introduced in Samba 2.0.6,
+ 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>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#SECURITYEQUALSERVER">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>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. All
+ this information will allow Samba to be extended in the future into
+ a mode the developers currently call appliance mode. In this mode,
+ no local Unix users will be necessary, and Samba will generate Unix
+ uids and gids from the information passed back from the PDC when a
+ user is authenticated, making a Samba server truly plug and play
+ in an NT domain environment. Watch for this code soon.</para>
+
+ <para><emphasis>NOTE:</emphasis> 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>
+
+</sect1>
+</book>
git.samba.org / ira / wip.git / commitdiff