diff options
Diffstat (limited to 'docs/htmldocs/domain-member.html')
| -rw-r--r-- | docs/htmldocs/domain-member.html | 534 |
1 files changed, 534 insertions, 0 deletions
diff --git a/docs/htmldocs/domain-member.html b/docs/htmldocs/domain-member.html new file mode 100644 index 0000000000..313c6e0fc7 --- /dev/null +++ b/docs/htmldocs/domain-member.html @@ -0,0 +1,534 @@ +<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 7. Domain Membership</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.60.1"><link rel="home" href="samba-doc.html" title="SAMBA Project Documentation"><link rel="up" href="type.html" title="Part II. Server Configuration Basics"><link rel="previous" href="samba-bdc.html" title="Chapter 6. Backup Domain Control"><link rel="next" href="StandAloneServer.html" title="Chapter 8. Stand-Alone Servers"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 7. Domain Membership</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="samba-bdc.html">Prev</a> </td><th width="60%" align="center">Part II. Server Configuration Basics</th><td width="20%" align="right"> <a accesskey="n" href="StandAloneServer.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="domain-member"></a>Chapter 7. Domain Membership</h2></div><div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="othername">H.</span> <span class="surname">Terpstra</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:jht@samba.org">jht@samba.org</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Jeremy</span> <span class="surname">Allison</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:jra@samba.org">jra@samba.org</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Gerald</span> <span class="othername">(Jerry)</span> <span class="surname">Carter</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:jerry@samba.org">jerry@samba.org</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Andrew</span> <span class="surname">Tridgell</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:tridge@samba.org">tridge@samba.org</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Jelmer</span> <span class="othername">R.</span> <span class="surname">Vernooij</span></h3><div class="affiliation"><span class="orgname">The Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:jelmer@samba.org">jelmer@samba.org</a>></tt></p></div></div></div></div></div><div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><a href="domain-member.html#id2890490">Features and Benefits</a></dt><dt><a href="domain-member.html#machine-trust-accounts">MS Windows Workstation/Server Machine Trust Accounts</a></dt><dd><dl><dt><a href="domain-member.html#id2890821">Manual Creation of Machine Trust Accounts</a></dt><dt><a href="domain-member.html#id2891126">Using NT4 Server Manager to Add Machine Accounts to the Domain</a></dt><dt><a href="domain-member.html#id2891341">"On-the-Fly" Creation of Machine Trust Accounts</a></dt><dt><a href="domain-member.html#id2891414">Making an MS Windows Workstation or Server a Domain Member</a></dt></dl></dd><dt><a href="domain-member.html#domain-member-server">Domain Member Server</a></dt><dd><dl><dt><a href="domain-member.html#id2891624">Joining an NT4 type Domain with Samba-3</a></dt><dt><a href="domain-member.html#id2892061">Why is this better than security = server?</a></dt></dl></dd><dt><a href="domain-member.html#ads-member">Samba ADS Domain Membership</a></dt><dd><dl><dt><a href="domain-member.html#id2892246">Setup your smb.conf</a></dt><dt><a href="domain-member.html#id2892373">Setup your /etc/krb5.conf</a></dt><dt><a href="domain-member.html#ads-create-machine-account">Create the computer account</a></dt><dt><a href="domain-member.html#ads-test-server">Test your server setup</a></dt><dt><a href="domain-member.html#ads-test-smbclient">Testing with smbclient</a></dt><dt><a href="domain-member.html#id2892751">Notes</a></dt></dl></dd><dt><a href="domain-member.html#id2892773">Common Errors</a></dt><dd><dl><dt><a href="domain-member.html#id2892816">Can Not Add Machine Back to Domain</a></dt><dt><a href="domain-member.html#id2892848">Adding Machine to Domain Fails</a></dt><dt><a href="domain-member.html#id2892992">I can't join a Windows 2003 PDC</a></dt></dl></dd></dl></div><p> +Domain Membership is a subject of vital concern, Samba must be able to +participate as a member server in a Microsoft Domain security context, and +Samba must be capable of providing Domain machine member trust accounts, +otherwise it would not be capable of offering a viable option for many users. +</p><p> +This chapter covers background information pertaining to domain membership, +Samba configuration for it, and MS Windows client procedures for joining a +domain. Why is this necessary? Because both are areas in which there exists +within the current MS Windows networking world and particularly in the +UNIX/Linux networking and administration world, a considerable level of +mis-information, incorrect understanding, and a lack of knowledge. Hopefully +this chapter will fill the voids. +</p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2890490"></a>Features and Benefits</h2></div></div><div></div></div><p> +MS Windows workstations and servers that want to participate in domain security need to +be made Domain members. Participating in Domain security is often called +<span class="emphasis"><em>Single Sign On</em></span> or <span class="acronym">SSO</span> for short. This +chapter describes the process that must be followed to make a workstation +(or another server - be it an <span class="application">MS Windows NT4 / 200x</span> +server) or a Samba server a member of an MS Windows Domain security context. +</p><p> +Samba-3 can join an MS Windows NT4 style domain as a native member server, an +MS Windows Active Directory Domain as a native member server, or a Samba Domain +Control network. +</p><p> +Domain membership has many advantages: +</p><div class="itemizedlist"><ul type="disc"><li><p> + MS Windows workstation users get the benefit of SSO + </p></li><li><p> + Domain user access rights and file ownership / access controls can be set + from the single Domain SAM (Security Account Manager) database + (works with Domain member servers as well as with MS Windows workstations + that are domain members) + </p></li><li><p> + Only <span class="application">MS Windows NT4 / 200x / XP Professional</span> + workstations that are Domain members + can use network logon facilities + </p></li><li><p> + Domain Member workstations can be better controlled through the use of + Policy files (<tt class="filename">NTConfig.POL</tt>) and Desktop Profiles. + </p></li><li><p> + Through the use of logon scripts, users can be given transparent access to network + applications that run off application servers + </p></li><li><p> + Network administrators gain better application and user access management + abilities because there is no need to maintain user accounts on any network + client or server, other than the central Domain database + (either NT4/Samba SAM style Domain, NT4 Domain that is back ended with an + LDAP directory, or via an Active Directory infrastructure) + </p></li></ul></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="machine-trust-accounts"></a>MS Windows Workstation/Server Machine Trust Accounts</h2></div></div><div></div></div><a class="indexterm" name="id2890621"></a><p> +A machine trust account is an account that is used to authenticate a client +machine +(rather than a user) to the Domain Controller server. In Windows terminology, +this is known as a "Computer Account." +</p><p> +The password of a machine trust account acts as the shared secret for +secure communication with the Domain Controller. This is a security +feature to prevent an unauthorized machine with the same NetBIOS name +from joining the domain and gaining access to domain user/group +accounts. Windows NT, 200x, XP Professional clients use machine trust +accounts, but Windows 9x / Me / XP Home clients do not. Hence, a +Windows 9x / Me / XP Home client is never a true member of a domain +because it does not possess a machine trust account, and thus has no +shared secret with the domain controller. +</p><p> +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. +</p><p> +A Samba PDC, however, stores each machine trust account in two parts, +as follows: + +</p><div class="itemizedlist"><ul type="disc"><li><p> + A Domain Security Account (stored in the + <a class="indexterm" name="id2890675"></a><i class="parameter"><tt>passdb backend</tt></i> that has been configured in the + <tt class="filename">smb.conf</tt> file. The precise nature of the account information that is + stored depends on the type of backend database that has been chosen. + </p><p> + The older format of this data is the <tt class="filename">smbpasswd</tt> database + which contains the UNIX login ID, the UNIX user identifier (UID), and the + LanMan and NT encrypted passwords. There is also some other information in + this file that we do not need to concern ourselves with here. + </p><p> + The two newer database types are called <span class="emphasis"><em>ldapsam</em></span>, + <span class="emphasis"><em>tdbsam</em></span>. Both store considerably more data than the + older <tt class="filename">smbpasswd</tt> file did. The extra information + enables new user account controls to be used. + </p></li><li><p> + A corresponding UNIX account, typically stored in + <tt class="filename">/etc/passwd</tt>. Work is in progress to allow a + simplified mode of operation that does not require UNIX user accounts, but + this may not be a feature of the early releases of Samba-3. + </p></li></ul></div><p> +</p><a class="indexterm" name="id2890757"></a><p> +There are three ways to create machine trust accounts: +</p><div class="itemizedlist"><ul type="disc"><li><p> + Manual creation from the UNIX/Linux command line. Here, both the Samba and + corresponding UNIX account are created by hand. + </p></li><li><p> + <a class="indexterm" name="id2890790"></a> + Using the MS Windows NT4 Server Manager (either from an NT4 Domain member + server, or using the Nexus toolkit available from the Microsoft web site. + This tool can be run from any MS Windows machine so long as the user is + logged on as the administrator account. + </p></li><li><p> + "On-the-fly" creation. The Samba machine trust account is automatically + created by Samba at the time the client is joined to the domain. + (For security, this is the recommended method.) The corresponding UNIX + account may be created automatically or manually. + </p></li></ul></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2890821"></a>Manual Creation of Machine Trust Accounts</h3></div></div><div></div></div><p> +The first step in manually creating a machine trust account is to manually +create the corresponding UNIX account in <tt class="filename">/etc/passwd</tt>. +This can be done using <b class="command">vipw</b> or another 'add user' command +that is normally used to create new UNIX accounts. The following is an example for a Linux based Samba server: +<a class="indexterm" name="id2890851"></a> +<a class="indexterm" name="id2890859"></a> + + +</p><p> +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>/usr/sbin/useradd -g 100 -d /dev/null -c <i class="replaceable"><tt>"machine nickname"</tt></i> \ + -s /bin/false <i class="replaceable"><tt>machine_name</tt></i>$ </tt></b> + +<tt class="prompt">root# </tt><b class="userinput"><tt>passwd -l <i class="replaceable"><tt>machine_name</tt></i>$</tt></b> +</pre><p> +</p><p> +<a class="indexterm" name="id2890921"></a> +On *BSD systems, this can be done using the <b class="command">chpass</b> utility: +</p><p> +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>chpass -a \ + "<i class="replaceable"><tt>machine_name</tt></i>$:*:101:100::0:0:Workstation <i class="replaceable"><tt>machine_name</tt></i>:/dev/null:/sbin/nologin"</tt></b> +</pre><p> +</p><p> +The <tt class="filename">/etc/passwd</tt> entry will list the machine name +with a "$" appended, won't have a password, will have a null shell and no +home directory. For example a machine named 'doppy' would have an +<tt class="filename">/etc/passwd</tt> entry like this: +</p><pre class="programlisting"> +doppy$:x:505:100:<i class="replaceable"><tt>machine_nickname</tt></i>:/dev/null:/bin/false +</pre><p> +Above, <i class="replaceable"><tt>machine_nickname</tt></i> can be any +descriptive name for the client, i.e., BasementComputer. +<i class="replaceable"><tt>machine_name</tt></i> absolutely must be the NetBIOS +name of the client to be joined to the domain. The "$" must be +appended to the NetBIOS name of the client or Samba will not recognize +this as a machine trust account. +</p><p> +Now that the corresponding UNIX account has been created, the next step is to create +the Samba account for the client containing the well-known initial +machine trust account password. This can be done using the +<b class="command">smbpasswd</b> command +as shown here: +</p><p> +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>smbpasswd -a -m <i class="replaceable"><tt>machine_name</tt></i></tt></b> +</pre><p> +</p><p> +where <i class="replaceable"><tt>machine_name</tt></i> is the machine's NetBIOS +name. The RID of the new machine account is generated from the UID of +the corresponding UNIX account. +</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Join the client to the domain immediately</h3><p> + Manually creating a machine trust account using this method is the + equivalent of creating a machine trust account on a Windows NT PDC using + <a class="indexterm" name="id2891100"></a> + the <span class="application">Server Manager</span>. From the time at which the + account is created to the time which the client joins the domain and + changes the password, your domain is vulnerable to an intruder joining + your domain using a machine with the same NetBIOS name. A PDC inherently + trusts members of the domain and will serve out a large degree of user + information to such clients. You have been warned! + </p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2891126"></a>Using NT4 Server Manager to Add Machine Accounts to the Domain</h3></div></div><div></div></div><p> +If the machine from which you are trying to manage the domain is an +<span class="application">MS Windows NT4 workstation or MS Windows 200x / XP Professional</span> +then the tool of choice is the package called <b class="command">SRVTOOLS.EXE</b>. +When executed in the target directory this will unpack <b class="command">SrvMge.exe</b> +and <b class="command">UsrMgr.exe</b> (both are domain management tools for MS Windows NT4 workstation). +</p><p> +If your workstation is a <span class="application">Microsoft Windows 9x/Me</span> family product + you should download the <b class="command">Nexus.exe</b> package from the Microsoft web site. +When executed from the target directory this will unpack the same tools but for use on +this platform. +</p><p> +Further information about these tools may be obtained from the following locations: +<a href="http://support.microsoft.com/default.aspx?scid=kb;en-us;173673" target="_top">http://support.microsoft.com/default.aspx?scid=kb;en-us;173673</a> +<a href="http://support.microsoft.com/default.aspx?scid=kb;en-us;172540" target="_top">http://support.microsoft.com/default.aspx?scid=kb;en-us;172540</a> +</p><p> +Launch the <b class="command">srvmgr.exe</b> (Server Manager for Domains) and follow these steps: +</p><div class="procedure"><p class="title"><b>Procedure 7.1. Server Manager Account Machine Account Management</b></p><ol type="1"><li><p> + From the menu select <span class="guimenu">Computer</span> + </p></li><li><p> + Click on <span class="guimenuitem">Select Domain</span> + </p></li><li><p> + Click on the name of the domain you wish to administer in the + <span class="guilabel">Select Domain</span> panel and then click + <span class="guibutton">OK</span>. + </p></li><li><p> + Again from the menu select <span class="guimenu">Computer</span> + </p></li><li><p> + Select <span class="guimenuitem">Add to Domain</span> + </p></li><li><p> + In the dialog box, click on the radio button to + <span class="guilabel">Add NT Workstation of Server</span>, then + enter the machine name in the field provided, then click the + <span class="guibutton">Add</span> button. + </p></li></ol></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2891341"></a>"On-the-Fly" Creation of Machine Trust Accounts</h3></div></div><div></div></div><p> +The second (and recommended) way of creating machine trust accounts is +simply to allow the Samba server to create them as needed when the client +is joined to the domain. +</p><p>Since each Samba machine trust account requires a corresponding UNIX account, a method +for automatically creating the UNIX account is usually supplied; this requires configuration of the +add machine script option in +<tt class="filename">smb.conf</tt>. This method is not required, however; corresponding UNIX +accounts may also be created manually. +</p><p> +Below is an example for a RedHat Linux system. +</p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><i class="parameter"><tt>[global]</tt></i></td></tr><tr><td># <...remainder of parameters...></td></tr><tr><td><i class="parameter"><tt>add machine script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u </tt></i></td></tr></table></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2891414"></a>Making an MS Windows Workstation or Server a Domain Member</h3></div></div><div></div></div><p> +The procedure for making an MS Windows workstation of server a member of the domain varies +with the version of Windows: +</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2891426"></a>Windows 200x XP Professional</h4></div></div><div></div></div><p> + When the user elects to make the client a domain member, Windows 200x prompts for + an account and password that has privileges to create machine accounts in the domain. + A Samba administrative account (i.e., a Samba account that has root privileges on the + Samba server) must be entered here; the operation will fail if an ordinary user + account is given. + </p><p> + Note: For security reasons the password for this administrative account should be set + to a password that is other than that used for the root user in the + <tt class="filename">/etc/passwd</tt>. + </p><p> + The name of the account that is used to create domain member machine accounts can be + anything the network administrator may choose. If it is other than <span class="emphasis"><em>root</em></span> + then this is easily mapped to root using the file pointed to be the <tt class="filename">smb.conf</tt> parameter + <a class="indexterm" name="id2891478"></a><i class="parameter"><tt>username map</tt></i> = /etc/samba/smbusers. + </p><p> + The session key of the Samba administrative account acts as an + encryption key for setting the password of the machine trust + account. The machine trust account will be created on-the-fly, or + updated if it already exists. + </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2891503"></a>Windows NT4</h4></div></div><div></div></div><p> + If the machine trust account was created manually, on the + Identification Changes menu enter the domain name, but do not + check the box <span class="guilabel">Create a Computer Account in the Domain</span>. + In this case, the existing machine trust account is used to join the machine + to the domain. + </p><p> + If the machine trust account is to be created + on-the-fly, on the Identification Changes menu enter the domain + name, and check the box <span class="guilabel">Create a Computer Account in the + Domain</span>. In this case, joining the domain proceeds as above + for Windows 2000 (i.e., you must supply a Samba administrative account when + prompted). + </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2891543"></a>Samba</h4></div></div><div></div></div><p>Joining a Samba client to a domain is documented in + <a href="domain-member.html#domain-member-server" title="Domain Member Server">the domain member chapter</a>. + </p></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="domain-member-server"></a>Domain Member Server</h2></div></div><div></div></div><p> +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. +</p><p> +<span class="emphasis"><em> +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. +</em></span> +</p><p> +Please refer to <a href="samba-pdc.html" title="Chapter 5. Domain Control">the chapter on setting up a PDC</a> +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. +</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2891624"></a>Joining an NT4 type Domain with Samba-3</h3></div></div><div></div></div><p> + </p><div class="table"><a name="id2891635"></a><p class="title"><b>Table 7.1. Assumptions</b></p><table summary="Assumptions" border="1"><colgroup><col><col></colgroup><tbody><tr><td align="left">NetBIOS name:</td><td align="left">SERV1</td></tr><tr><td align="left">Win2K/NT domain name:</td><td align="left">MIDEARTH</td></tr><tr><td align="left">Domain's PDC NetBIOS name:</td><td align="left">DOMPDC</td></tr><tr><td align="left">Domain's BDC NetBIOS names:</td><td align="left">DOMBDC1 and DOMBDC2</td></tr></tbody></table></div><p> +</p><p> +First, you must edit your <tt class="filename">smb.conf</tt> file to tell Samba it should +now use domain security. +</p><p> + Change (or add) your + <a class="indexterm" name="id2891708"></a><i class="parameter"><tt>security</tt></i> line in the [global] section +of your <tt class="filename">smb.conf</tt> to read: +</p><p> +</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>security = domain</tt></i></td></tr></table><p> +</p><p> +Next change the <a class="indexterm" name="id2891752"></a><i class="parameter"><tt>workgroup</tt></i> line in the <i class="parameter"><tt>[global]</tt></i> +section to read: +</p><p> +</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>workgroup = MIDEARTH</tt></i></td></tr></table><p> +</p><p> +as this is the name of the domain we are joining. +</p><p> +You must also have the parameter +<a class="indexterm" name="id2891802"></a><i class="parameter"><tt>encrypt passwords</tt></i> set to <tt class="constant">yes +</tt> in order for your users to authenticate to the NT PDC. +</p><p> +Finally, add (or modify) a <a class="indexterm" name="id2891826"></a><i class="parameter"><tt>password server</tt></i> line in the [global] +section to read: +</p><p> +</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>password server = DOMPDC DOMBDC1 DOMBDC2</tt></i></td></tr></table><p> +</p><p> +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. +</p><p> +Alternatively, if you want smbd to automatically determine +the list of Domain controllers to use for authentication, you may +set this line to be: +</p><p> +</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>password server = *</tt></i></td></tr></table><p> +</p><p> +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. +</p><p> +In order to actually join the domain, you must run this command: +</p><p> +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>net rpc join -S DOMPDC -U<i class="replaceable"><tt>Administrator%password</tt></i></tt></b> +</pre><p> +</p><p> +If the <tt class="option">-S DOMPDC</tt> argument is not given then +the domain name will be obtained from <tt class="filename">smb.conf</tt>. +</p><p> +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, we use it for the <tt class="option">-S</tt> option. +The <i class="replaceable"><tt>Administrator%password</tt></i> 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: +</p><p> +<tt class="computeroutput">Joined domain DOM.</tt> +or <tt class="computeroutput">Joined 'SERV1' to realm 'MYREALM'</tt> +</p><p> +in your terminal window. See the +<b class="command">net</b> man page for more details. +</p><p> +This process joins the server to the domain without having to create the machine +trust account on the PDC beforehand. +</p><p> +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: +</p><p> +<tt class="filename">/usr/local/samba/private/secrets.tdb</tt> +</p><p> +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. +</p><p> +Finally, restart your Samba daemons and get ready for +clients to begin using domain security! The way you can restart your +samba daemons depends on your distribution, but in most cases running +</p><pre class="screen"> + <tt class="prompt">root# </tt>/etc/init.d/samba restart +</pre><p> +does the job. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2892061"></a>Why is this better than security = server?</h3></div></div><div></div></div><p> +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 <tt class="constant">DOM\fred +</tt> 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 +security = server, +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. +</p><p> + Please refer to <a href="winbind.html" title="Chapter 21. Winbind: Use of Domain Accounts">the chapter on winbind</a> for information on a system +to automatically assign UNIX uids and gids to Windows NT Domain users and groups. +</p><p> +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). +</p><p> +In addition, with <a class="indexterm" name="id2892116"></a><i class="parameter"><tt>security</tt></i> = server 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 <a class="indexterm" name="id2892135"></a><i class="parameter"><tt>security</tt></i> = domain, +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. +</p><p> +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. +</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> +Much of the text of this document +was first published in the Web magazine +<a href="http://www.linuxworld.com" target="_top">LinuxWorld</a> as the article <a href="http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.html" target="_top">Doing +the NIS/NT Samba</a>. +</p></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="ads-member"></a>Samba ADS Domain Membership</h2></div></div><div></div></div><a class="indexterm" name="id2892203"></a><a class="indexterm" name="id2892211"></a><a class="indexterm" name="id2892223"></a><a class="indexterm" name="id2892231"></a><p> +This is a rough guide to setting up Samba 3.0 with Kerberos authentication against a +Windows2000 KDC. A familiarity with Kerberos is assumed. +</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2892246"></a>Setup your <tt class="filename">smb.conf</tt></h3></div></div><div></div></div><p> +You must use at least the following 3 options in <tt class="filename">smb.conf</tt>: +</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>realm = your.kerberos.REALM</tt></i></td></tr><tr><td><i class="parameter"><tt>security = ADS</tt></i></td></tr><tr><td><i class="parameter"><tt>encrypt passwords = yes</tt></i></td></tr></table><p> +In case samba can't figure out your ads server using your realm name, use the +<a class="indexterm" name="id2892305"></a><i class="parameter"><tt>ads server</tt></i> option in <tt class="filename">smb.conf</tt>: +</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>ads server = your.kerberos.server</tt></i></td></tr></table><p> +</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> +You do <span class="emphasis"><em>not</em></span> need a smbpasswd file, and older clients will be authenticated as +if <a class="indexterm" name="id2892352"></a><i class="parameter"><tt>security</tt></i> = domain, although it won't do any harm and +allows you to have local users not in the domain. It is expected that the above +required options will change soon when active directory integration will get +better. +</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2892373"></a>Setup your <tt class="filename">/etc/krb5.conf</tt></h3></div></div><div></div></div><p> +The minimal configuration for <tt class="filename">krb5.conf</tt> is: +</p><pre class="programlisting"> +[libdefaults] + default_realm = YOUR.KERBEROS.REALM + + [realms] + YOUR.KERBEROS.REALM = { + kdc = your.kerberos.server + } +</pre><a class="indexterm" name="id2892409"></a><p> +Test your config by doing a <b class="userinput"><tt>kinit +<i class="replaceable"><tt>USERNAME</tt></i>@<i class="replaceable"><tt>REALM</tt></i></tt></b> and +making sure that your password is accepted by the Win2000 KDC. +</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> +The realm must be uppercase or you will get <span class="errorname">Cannot find KDC for +requested realm while getting initial credentials</span> error (Kerberos +is case-sensitive!). +</p></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> +Time between the two servers must be synchronized. You will get a +<span class="errorname">kinit(v5): Clock skew too great while getting initial credentials</span> +if the time difference is more than five minutes. +</p></div><p> +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. +</p><p> +The easiest way to ensure you get this right is to add a +<tt class="filename">/etc/hosts</tt> entry mapping the IP address of your KDC to +its NetBIOS name. If you don't get this right then you will get a +<span class="errorname">local error</span> when you try to join the realm. +</p><p> +If all you want is Kerberos support in <span class="application">smbclient</span> then you can skip +straight to <a href="domain-member.html#ads-test-smbclient" title="Testing with smbclient">Test with <span class="application">smbclient</span></a> now. +<a href="domain-member.html#ads-create-machine-account" title="Create the computer account">Creating a computer account</a> +and <a href="domain-member.html#ads-test-server" title="Test your server setup">testing your servers</a> +is only needed if you want Kerberos support for <span class="application">smbd</span> and <span class="application">winbindd</span>. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="ads-create-machine-account"></a>Create the computer account</h3></div></div><div></div></div><p> +As a user that has write permission on the Samba private directory +(usually root) run: +</p><pre class="screen"> +<tt class="prompt">root# </tt> <b class="userinput"><tt>net ads join -U Administrator%password</tt></b> +</pre><p> +</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2892592"></a>Possible errors</h4></div></div><div></div></div><p> +</p><div class="variablelist"><dl><dt><span class="term"><span class="errorname">ADS support not compiled in</span></span></dt><dd><p>Samba must be reconfigured (remove config.cache) and recompiled + (make clean all install) after the Kerberos libs and headers are installed. + </p></dd><dt><span class="term"><span class="errorname">net ads join prompts for user name</span></span></dt><dd><p>You need to login to the domain using <b class="userinput"><tt>kinit + <i class="replaceable"><tt>USERNAME</tt></i>@<i class="replaceable"><tt>REALM</tt></i></tt></b>. + <i class="replaceable"><tt>USERNAME</tt></i> must be a user who has rights to add a machine + to the domain. </p></dd></dl></div><p> +</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="ads-test-server"></a>Test your server setup</h3></div></div><div></div></div><p> +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. +</p><p> +On a Windows 2000 client try <b class="userinput"><tt>net use * \\server\share</tt></b>. You should +be logged in with Kerberos without needing to know a password. If +this fails then run <b class="userinput"><tt>klist tickets</tt></b>. Did you get a ticket for the +server? Does it have an encoding type of DES-CBC-MD5 ? +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="ads-test-smbclient"></a>Testing with <span class="application">smbclient</span></h3></div></div><div></div></div><a class="indexterm" name="id2892719"></a><p> +On your Samba server try to login to a Win2000 server or your Samba +server using <span class="application">smbclient</span> and Kerberos. Use <span class="application">smbclient</span> as usual, but +specify the <tt class="option">-k</tt> option to choose Kerberos authentication. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2892751"></a>Notes</h3></div></div><div></div></div><p> +You must change administrator password at least once after DC +install, to create the right encoding types +</p><p> +W2k doesn't seem to create the _kerberos._udp and _ldap._tcp in +their defaults DNS setup. Maybe this will be fixed later in service packs. +</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2892773"></a>Common Errors</h2></div></div><div></div></div><p> +In the process of adding / deleting / re-adding domain member machine accounts there are +many traps for the unwary player and there are many “<span class="quote">little</span>” things that can go wrong. +It is particularly interesting how often subscribers on the samba mailing list have concluded +after repeated failed attempts to add a machine account that it is necessary to "re-install" +MS Windows on t he machine. In truth, it is seldom necessary to reinstall because of this type +of problem. The real solution is often very simple, and with understanding of how MS Windows +networking functions easy to overcome. +</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2892816"></a>Can Not Add Machine Back to Domain</h3></div></div><div></div></div><p> +“<span class="quote"> A Windows workstation was reinstalled. The original domain machine +account was deleted and added immediately. The workstation will not join the domain if I use +the same machine name. Attempts to add the machine fail with a message that the machine already +exists on the network - I know it doesn't. Why is this failing?</span>” +</p><p> +The original name is still in the NetBIOS name cache and must expire after machine account +deletion BEFORE adding that same name as a domain member again. The best advice is to delete +the old account and then to add the machine with a new name. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2892848"></a>Adding Machine to Domain Fails</h3></div></div><div></div></div><p> + “<span class="quote">Adding a Windows 200x or XP Professional machine to the Samba PDC Domain fails with a +message that, <span class="errorname">The machine could not be added at this time, there is a network problem. + Please try again later.</span> Why?</span>” +</p><p> +You should check that there is an <a class="indexterm" name="id2892875"></a><i class="parameter"><tt>add machine script</tt></i> in your <tt class="filename">smb.conf</tt> +file. If there is not, please add one that is appropriate for your OS platform. If a script +has been defined you will need to debug it's operation. Increase the <a class="indexterm" name="id2892900"></a><i class="parameter"><tt>log level</tt></i> +in the <tt class="filename">smb.conf</tt> file to level 10, then try to rejoin the domain. Check the logs to see which +operation is failing. +</p><p> +Possible causes include: +</p><div class="itemizedlist"><ul type="disc"><li><p> + The script does not actually exist, or could not be located in the path specified. + </p><p> + <span class="emphasis"><em>Corrective Action:</em></span> Fix it. Make sure that when run manually + that the script will add both the UNIX system account _and_ the Samba SAM account. + </p></li><li><p> + The machine could not be added to the UNIX system accounts file <tt class="filename">/etc/passwd</tt> + </p><p> + <span class="emphasis"><em>Corrective Action:</em></span> Check that the machine name is a legal UNIX + system account name. ie: If the UNIX utility <b class="command">useradd</b> is called + then make sure that the machine name you are trying to add can be added using this + tool. <b class="command">Useradd</b> on some systems will not allow any upper case characters + nor will it allow spaces in the name. + </p></li></ul></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2892992"></a>I can't join a Windows 2003 PDC</h3></div></div><div></div></div><p>Windows 2003 requires SMB signing. Client side SMB signing has + only been implemented partially in Samba 3.0. Set <a class="indexterm" name="id2893004"></a><i class="parameter"><tt>client use spnego</tt></i> = no when communicating + with a windows 2003 server. </p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="samba-bdc.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="type.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="StandAloneServer.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 6. Backup Domain Control </td><td width="20%" align="center"><a accesskey="h" href="samba-doc.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 8. Stand-Alone Servers</td></tr></table></div></body></html> |