diff options
Diffstat (limited to 'docs/docbook/howto/DOMAIN_MEMBER.sgml')
| -rw-r--r-- | docs/docbook/howto/DOMAIN_MEMBER.sgml | 163 |
1 files changed, 0 insertions, 163 deletions
diff --git a/docs/docbook/howto/DOMAIN_MEMBER.sgml b/docs/docbook/howto/DOMAIN_MEMBER.sgml deleted file mode 100644 index 888b801742..0000000000 --- a/docs/docbook/howto/DOMAIN_MEMBER.sgml +++ /dev/null @@ -1,163 +0,0 @@ -<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.1//EN"> - -<article> - -<sect1> - - <title>Joining an NT Domain with Samba 2.2</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> -</article> |