diff options
Diffstat (limited to 'docs/docbook/projdoc/DOMAIN_MEMBER.xml')
| -rw-r--r-- | docs/docbook/projdoc/DOMAIN_MEMBER.xml | 472 |
1 files changed, 144 insertions, 328 deletions
diff --git a/docs/docbook/projdoc/DOMAIN_MEMBER.xml b/docs/docbook/projdoc/DOMAIN_MEMBER.xml index 6a3ef28b55..a5921e8ce3 100644 --- a/docs/docbook/projdoc/DOMAIN_MEMBER.xml +++ b/docs/docbook/projdoc/DOMAIN_MEMBER.xml @@ -3,343 +3,159 @@ <chapterinfo> &author.jeremy; &author.jerry; - &author.jht; + <pubdate>16 Apr 2001</pubdate> </chapterinfo> -<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> - -</sect1> +<title>Samba as a NT4 or Win2k domain member</title> <sect1> -<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> + <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>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> + <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> </sect1> + </chapter> |