another conversion

(This used to be commit eda9d9ac044f9bc243b128c41927426742c71fc8)

1 files changed, 168 insertions, 0 deletions

diff --git a/docs/docbook/howto/DOMAIN_MEMBER.sgml b/docs/docbook/howto/DOMAIN_MEMBER.sgml
new file mode 100644
index 00000000000..bdb8fd86358
--- /dev/null
+++ b/docs/docbook/howto/DOMAIN_MEMBER.sgml
@@ -0,0 +1,168 @@
+<!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>&lt;NT DOMAIN NAME&gt;</replaceable>.
+	<replaceable>&lt;Samba Server Name&gt;</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>