--- /dev/null
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 6. Domain Membership</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.68.1"><link rel="start" href="index.html" title="The Official Samba-3 HOWTO and Reference Guide"><link rel="up" href="type.html" title="Part II. Server Configuration Basics"><link rel="prev" href="samba-bdc.html" title="Chapter 5. Backup Domain Control"><link rel="next" href="StandAloneServer.html" title="Chapter 7. Standalone 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 6. 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 6. 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><code class="email"><<a href="mailto:jht@samba.org">jht@samba.org</a>></code></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><code class="email"><<a href="mailto:jra@samba.org">jra@samba.org</a>></code></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><code class="email"><<a href="mailto:jerry@samba.org">jerry@samba.org</a>></code></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><code class="email"><<a href="mailto:tridge@samba.org">tridge@samba.org</a>></code></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><code class="email"><<a href="mailto:jelmer@samba.org">jelmer@samba.org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Guenther</span> <span class="surname">Deschner</span></h3><span class="contrib">LDAP updates</span><div class="affiliation"><span class="orgname">SuSE<br></span><div class="address"><p><code class="email"><<a href="mailto:gd@suse.de">gd@suse.de</a>></code></p></div></div></div></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="domain-member.html#id2536846">Features and Benefits</a></span></dt><dt><span class="sect1"><a href="domain-member.html#machine-trust-accounts">MS Windows Workstation/Server Machine Trust Accounts</a></span></dt><dd><dl><dt><span class="sect2"><a href="domain-member.html#id2537529">Manual Creation of Machine Trust Accounts</a></span></dt><dt><span class="sect2"><a href="domain-member.html#id2537965">Managing Domain Machine Accounts using NT4 Server Manager</a></span></dt><dt><span class="sect2"><a href="domain-member.html#id2538241">On-the-Fly Creation of Machine Trust Accounts</a></span></dt><dt><span class="sect2"><a href="domain-member.html#id2538348">Making an MS Windows Workstation or Server a Domain Member</a></span></dt></dl></dd><dt><span class="sect1"><a href="domain-member.html#domain-member-server">Domain Member Server</a></span></dt><dd><dl><dt><span class="sect2"><a href="domain-member.html#id2538809">Joining an NT4-type Domain with Samba-3</a></span></dt><dt><span class="sect2"><a href="domain-member.html#id2539532">Why Is This Better Than <em class="parameter"><code>security = server</code></em>?</a></span></dt></dl></dd><dt><span class="sect1"><a href="domain-member.html#ads-member">Samba ADS Domain Membership</a></span></dt><dd><dl><dt><span class="sect2"><a href="domain-member.html#id2539802">Configure <code class="filename">smb.conf</code></a></span></dt><dt><span class="sect2"><a href="domain-member.html#id2539989">Configure <code class="filename">/etc/krb5.conf</code></a></span></dt><dt><span class="sect2"><a href="domain-member.html#ads-create-machine-account">Create the Computer Account</a></span></dt><dt><span class="sect2"><a href="domain-member.html#ads-test-server">Testing Server Setup</a></span></dt><dt><span class="sect2"><a href="domain-member.html#ads-test-smbclient">Testing with <span class="application">smbclient</span></a></span></dt><dt><span class="sect2"><a href="domain-member.html#id2541086">Notes</a></span></dt></dl></dd><dt><span class="sect1"><a href="domain-member.html#id2541158">Sharing User ID Mappings between Samba Domain Members</a></span></dt><dt><span class="sect1"><a href="domain-member.html#id2541357">Common Errors</a></span></dt><dd><dl><dt><span class="sect2"><a href="domain-member.html#id2541397">Cannot Add Machine Back to Domain</a></span></dt><dt><span class="sect2"><a href="domain-member.html#id2541473">Adding Machine to Domain Fails</a></span></dt><dt><span class="sect2"><a href="domain-member.html#id2541695">I Can't Join a Windows 2003 PDC</a></span></dt></dl></dd></dl></div><p>
+<a class="indexterm" name="id2536794"></a>
+<a class="indexterm" name="id2536800"></a>
+<a class="indexterm" name="id2536808"></a>
+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 able to offer a viable option for many users.
+</p><p>
+<a class="indexterm" name="id2536823"></a>
+<a class="indexterm" name="id2536830"></a>
+This chapter covers background information pertaining to domain membership,
+the 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
+misinformation, incorrect understanding, and 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="id2536846"></a>Features and Benefits</h2></div></div></div><p>
+<a class="indexterm" name="id2536854"></a>
+<a class="indexterm" name="id2536861"></a>
+<a class="indexterm" name="id2536868"></a>
+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>
+<a class="indexterm" name="id2536900"></a>
+<a class="indexterm" name="id2536906"></a>
+<a class="indexterm" name="id2536913"></a>
+<a class="indexterm" name="id2536920"></a>
+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. Domain membership has many advantages:
+</p><div class="itemizedlist"><ul type="disc"><li><p>
+ <a class="indexterm" name="id2536939"></a>
+ MS Windows workstation users get the benefit of SSO.
+ </p></li><li><p>
+ <a class="indexterm" name="id2536951"></a>
+ <a class="indexterm" name="id2536958"></a>
+ <a class="indexterm" name="id2536965"></a>
+ <a class="indexterm" name="id2536972"></a>
+ Domain user access rights and file ownership/access controls can be set
+ from the single Domain Security Account Manager (SAM) database
+ (works with domain member servers as well as with MS Windows workstations
+ that are domain members).
+ </p></li><li><p>
+ <a class="indexterm" name="id2536987"></a>
+ <a class="indexterm" name="id2536994"></a>
+ 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>
+ <a class="indexterm" name="id2537013"></a>
+ <a class="indexterm" name="id2537020"></a>
+ <a class="indexterm" name="id2537027"></a>
+ <a class="indexterm" name="id2537034"></a>
+ Domain member workstations can be better controlled through the use of
+ policy files (<code class="filename">NTConfig.POL</code>) and desktop profiles.
+ </p></li><li><p>
+ <a class="indexterm" name="id2537053"></a>
+ <a class="indexterm" name="id2537060"></a>
+ <a class="indexterm" name="id2537067"></a>
+ Through the use of logon scripts, users can be given transparent access to network
+ applications that run off application servers.
+ </p></li><li><p>
+ <a class="indexterm" name="id2537080"></a>
+ <a class="indexterm" name="id2537087"></a>
+ <a class="indexterm" name="id2537094"></a>
+ <a class="indexterm" name="id2537101"></a>
+ 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 backend-ed 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><p>
+<a class="indexterm" name="id2537129"></a>
+<a class="indexterm" name="id2537136"></a>
+<a class="indexterm" name="id2537143"></a>
+<a class="indexterm" name="id2537150"></a>
+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 “<span class="quote">computer account.</span>” The
+purpose of the machine trust account is to prevent a rogue user and domain controller from colluding to gain
+access to a domain member workstation.
+</p><p>
+<a class="indexterm" name="id2537169"></a>
+<a class="indexterm" name="id2537178"></a>
+<a class="indexterm" name="id2537185"></a>
+<a class="indexterm" name="id2537192"></a>
+<a class="indexterm" name="id2537200"></a>
+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, participating in domain security operations, 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 class="indexterm" name="id2537220"></a>
+<a class="indexterm" name="id2537227"></a>
+<a class="indexterm" name="id2537234"></a>
+<a class="indexterm" name="id2537240"></a>
+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. A Samba PDC, however, stores
+each Machine Trust Account in two parts,
+as follows:
+
+</p><div class="itemizedlist"><ul type="disc"><li><p>
+ <a class="indexterm" name="id2537258"></a>
+ <a class="indexterm" name="id2537265"></a>
+ <a class="indexterm" name="id2537272"></a>
+ A domain security account (stored in the <a class="indexterm" name="id2537279"></a>passdb backend) that has been configured in
+ the <code class="filename">smb.conf</code> file. The precise nature of the account information that is stored depends on the type of
+ backend database that has been chosen.
+ </p><p>
+ <a class="indexterm" name="id2537299"></a>
+ <a class="indexterm" name="id2537305"></a>
+ <a class="indexterm" name="id2537312"></a>
+ <a class="indexterm" name="id2537319"></a>
+ <a class="indexterm" name="id2537326"></a>
+ <a class="indexterm" name="id2537333"></a>
+ The older format of this data is the <code class="filename">smbpasswd</code> database
+ that 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>
+ <a class="indexterm" name="id2537356"></a>
+ <a class="indexterm" name="id2537362"></a>
+ <a class="indexterm" name="id2537369"></a>
+ <a class="indexterm" name="id2537376"></a>
+ The two newer database types are called ldapsam and tdbsam. Both store considerably more data than the older
+ <code class="filename">smbpasswd</code> file did. The extra information enables new user account controls to be
+ implemented.
+ </p></li><li><p>
+ <a class="indexterm" name="id2537396"></a>
+ <a class="indexterm" name="id2537403"></a>
+ A corresponding UNIX account, typically stored in <code class="filename">/etc/passwd</code>. Work is in progress to
+ allow a simplified mode of operation that does not require UNIX user accounts, but this has not been a feature
+ of the early releases of Samba-3, and is not currently planned for release either.
+ </p></li></ul></div><p>
+</p><p>
+<a class="indexterm" name="id2537429"></a>
+There are three ways to create Machine Trust Accounts:
+</p><div class="itemizedlist"><ul type="disc"><li><p>
+ <a class="indexterm" name="id2537446"></a>
+ 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="id2537459"></a>
+ <a class="indexterm" name="id2537466"></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 as long as the user is
+ logged on as the administrator account.
+ </p></li><li><p>
+ <a class="indexterm" name="id2537482"></a>
+ <a class="indexterm" name="id2537489"></a>
+ “<span class="quote">On-the-fly</span>” 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><p>
+<a class="indexterm" name="id2537508"></a>
+<a class="indexterm" name="id2537515"></a>
+Neither MS Windows NT4/200x/XP Professional, nor Samba, provide any method for enforcing the method of machine
+trust account creation. This is a matter of the administrator's choice.
+</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2537529"></a>Manual Creation of Machine Trust Accounts</h3></div></div></div><p>
+<a class="indexterm" name="id2537537"></a>
+<a class="indexterm" name="id2537544"></a>
+<a class="indexterm" name="id2537549"></a>
+<a class="indexterm" name="id2537556"></a>
+The first step in manually creating a Machine Trust Account is to manually
+create the corresponding UNIX account in <code class="filename">/etc/passwd</code>.
+This can be done using <span><strong class="command">vipw</strong></span> or another “<span class="quote">adduser</span>” command
+that is normally used to create new UNIX accounts. The following is an example for
+a Linux-based Samba server:
+</p><pre class="screen">
+<code class="prompt">root# </code><strong class="userinput"><code>/usr/sbin/useradd -g machines -d /var/lib/nobody \
+ -c <em class="replaceable"><code>"machine nickname"</code></em> \
+ -s /bin/false <em class="replaceable"><code>machine_name</code></em>$ </code></strong>
+
+<code class="prompt">root# </code><strong class="userinput"><code>passwd -l <em class="replaceable"><code>machine_name</code></em>$</code></strong>
+</pre><p>
+</p><p>
+<a class="indexterm" name="id2537625"></a>
+<a class="indexterm" name="id2537632"></a>
+<a class="indexterm" name="id2537638"></a>
+In the example above there is an existing system group “<span class="quote">machines</span>” which is used
+as the primary group for all machine accounts. In the following examples the “<span class="quote">machines</span>” group
+numeric GID is 100.
+</p><p>
+<a class="indexterm" name="id2537658"></a>
+<a class="indexterm" name="id2537665"></a>
+On *BSD systems, this can be done using the <span><strong class="command">chpass</strong></span> utility:
+</p><pre class="screen">
+<code class="prompt">root# </code><strong class="userinput"><code>chpass -a \
+'<em class="replaceable"><code>machine_name</code></em>$:*:101:100::0:0:Windows <em class="replaceable"><code>machine_name</code></em>:/dev/null:/sbin/nologin'</code></strong>
+</pre><p>
+</p><p>
+<a class="indexterm" name="id2537706"></a>
+<a class="indexterm" name="id2537713"></a>
+<a class="indexterm" name="id2537720"></a>
+<a class="indexterm" name="id2537726"></a>
+The <code class="filename">/etc/passwd</code> entry will list the machine name
+with a “<span class="quote">$</span>” appended, and will not have a password, will have a null shell and no
+home directory. For example, a machine named “<span class="quote">doppy</span>” would have an
+<code class="filename">/etc/passwd</code> entry like this:
+</p><pre class="programlisting">
+doppy$:x:505:100:<em class="replaceable"><code>machine_nickname</code></em>:/dev/null:/bin/false
+</pre><p>
+</p><p>
+<a class="indexterm" name="id2537769"></a>
+<a class="indexterm" name="id2537776"></a>
+<a class="indexterm" name="id2537783"></a>
+in which <em class="replaceable"><code>machine_nickname</code></em> can be any
+descriptive name for the client, such as BasementComputer.
+<em class="replaceable"><code>machine_name</code></em> absolutely must be the NetBIOS
+name of the client to be joined to the domain. The “<span class="quote">$</span>” must be
+appended to the NetBIOS name of the client or Samba will not recognize
+this as a Machine Trust Account.
+</p><p>
+<a class="indexterm" name="id2537808"></a>
+<a class="indexterm" name="id2537815"></a>
+<a class="indexterm" name="id2537822"></a>
+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
+<span><strong class="command">smbpasswd</strong></span> command
+as shown here:
+</p><pre class="screen">
+<code class="prompt">root# </code><strong class="userinput"><code>smbpasswd -a -m <em class="replaceable"><code>machine_name</code></em></code></strong>
+</pre><p>
+</p><p>
+<a class="indexterm" name="id2537864"></a>
+<a class="indexterm" name="id2537871"></a>
+<a class="indexterm" name="id2537878"></a>
+<a class="indexterm" name="id2537884"></a>
+where <em class="replaceable"><code>machine_name</code></em> 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>
+<a class="indexterm" name="id2537906"></a>
+<a class="indexterm" name="id2537913"></a>
+<a class="indexterm" name="id2537920"></a>
+<a class="indexterm" name="id2537927"></a>
+<a class="indexterm" name="id2537934"></a>
+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="id2537943"></a>
+the <span class="application">Server Manager</span>. From the time at which the
+account is created to the time 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="id2537965"></a>Managing Domain Machine Accounts using NT4 Server Manager</h3></div></div></div><p>
+<a class="indexterm" name="id2537974"></a>
+<a class="indexterm" name="id2537981"></a>
+<a class="indexterm" name="id2537988"></a>
+A working <a class="indexterm" name="id2537995"></a>add machine script is essential
+for machine trust accounts to be automatically created. This applies no matter whether
+you use automatic account creation or the NT4 Domain Server Manager.
+</p><p>
+<a class="indexterm" name="id2538009"></a>
+<a class="indexterm" name="id2538016"></a>
+<a class="indexterm" name="id2538022"></a>
+<a class="indexterm" name="id2538029"></a>
+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>,
+the tool of choice is the package called <span><strong class="command">SRVTOOLS.EXE</strong></span>.
+When executed in the target directory it will unpack <span><strong class="command">SrvMgr.exe</strong></span>
+and <span><strong class="command">UsrMgr.exe</strong></span> (both are domain management tools for MS Windows NT4 workstation).
+</p><p>
+<a class="indexterm" name="id2538068"></a>
+<a class="indexterm" name="id2538075"></a>
+If your workstation is a <span class="application">Microsoft Windows 9x/Me</span> family product,
+ you should download the <span><strong class="command">Nexus.exe</strong></span> package from the Microsoft Web site.
+When executed from the target directory, it will unpack the same tools but for use on
+this platform.
+</p><p>
+Further information about these tools may be obtained from Knowledge Base articles
+<a href="http://support.microsoft.com/default.aspx?scid=kb;en-us;173673" target="_top">173673</a>, and
+<a href="http://support.microsoft.com/default.aspx?scid=kb;en-us;172540" target="_top">172540</a>
+</p><p>
+<a class="indexterm" name="id2538119"></a>
+<a class="indexterm" name="id2538126"></a>
+Launch the <span><strong class="command">srvmgr.exe</strong></span> (Server Manager for Domains) and follow these steps:
+</p><div class="procedure"><a name="id2538142"></a><p class="title"><b>Procedure 6.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 <span class="guimenuitem">Select Domain</span>.
+ </p></li><li><p>
+ Click 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 the radio button to
+ <span class="guilabel">Add NT Workstation of Server</span>, then
+ enter the machine name in the field provided, and 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="id2538241"></a>On-the-Fly Creation of Machine Trust Accounts</h3></div></div></div><p>
+<a class="indexterm" name="id2538250"></a>
+The third (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>
+<a class="indexterm" name="id2538265"></a>
+<a class="indexterm" name="id2538275"></a>
+<a class="indexterm" name="id2538282"></a>
+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 <code class="filename">smb.conf</code>. This method is not required; however, corresponding UNIX
+accounts may also be created manually.
+</p><p>
+<a class="indexterm" name="id2538303"></a>
+<a class="indexterm" name="id2538310"></a>
+Here is an example for a Red Hat Linux system:
+</p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><em class="parameter"><code>[global]</code></em></td></tr><tr><td><a class="indexterm" name="id2538332"></a><em class="parameter"><code>add machine script = /usr/sbin/useradd -d /var/lib/nobody -g 100 -s /bin/false -M %u</code></em></td></tr></table><p>
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2538348"></a>Making an MS Windows Workstation or Server a Domain Member</h3></div></div></div><p>
+The procedure for making an MS Windows workstation or 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="id2538359"></a>Windows 200x/XP Professional Client</h4></div></div></div><p>
+<a class="indexterm" name="id2538367"></a>
+<a class="indexterm" name="id2538374"></a>
+<a class="indexterm" name="id2538384"></a>
+<a class="indexterm" name="id2538390"></a>
+ 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 administrator account (i.e., a Samba account that has <code class="constant">root</code> privileges on the
+ Samba server) must be entered here; the operation will fail if an ordinary user
+ account is given.
+ </p><p>
+<a class="indexterm" name="id2538410"></a>
+<a class="indexterm" name="id2538417"></a>
+ For security reasons, the password for this administrator account should be set
+ to a password that is other than that used for the root user in <code class="filename">/etc/passwd</code>.
+ </p><p>
+<a class="indexterm" name="id2538435"></a>
+<a class="indexterm" name="id2538442"></a>
+<a class="indexterm" name="id2538449"></a>
+<a class="indexterm" name="id2538456"></a>
+ The name of the account that is used to create domain member machine trust accounts can be
+ anything the network administrator may choose. If it is other than <code class="constant">root</code>,
+ then this is easily mapped to <code class="constant">root</code> in the file named in the <code class="filename">smb.conf</code> parameter
+ <a class="indexterm" name="id2538480"></a>username map = /etc/samba/smbusers.
+ </p><p>
+<a class="indexterm" name="id2538491"></a>
+<a class="indexterm" name="id2538498"></a>
+<a class="indexterm" name="id2538505"></a>
+ The session key of the Samba administrator 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="id2538518"></a>Windows NT4 Client</h4></div></div></div><p>
+<a class="indexterm" name="id2538526"></a>
+<a class="indexterm" name="id2538533"></a>
+<a class="indexterm" name="id2538540"></a>
+ 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>
+<a class="indexterm" name="id2538560"></a>
+<a class="indexterm" name="id2538567"></a>
+<a class="indexterm" name="id2538574"></a>
+<a class="indexterm" name="id2538581"></a>
+ 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 administrator account when
+ prompted).
+ </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2538601"></a>Samba Client</h4></div></div></div><p>
+<a class="indexterm" name="id2538609"></a>
+ Joining a Samba client to a domain is documented in <a href="domain-member.html#domain-member-server" title="Domain Member Server">the next section</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><p>
+<a class="indexterm" name="id2538640"></a>
+<a class="indexterm" name="id2538647"></a>
+<a class="indexterm" name="id2538654"></a>
+<a class="indexterm" name="id2538661"></a>
+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>
+<a class="indexterm" name="id2538680"></a>
+<a class="indexterm" name="id2538690"></a>
+<a class="indexterm" name="id2538697"></a>
+<a class="indexterm" name="id2538703"></a>
+<a class="indexterm" name="id2538710"></a>
+<a class="indexterm" name="id2538717"></a>
+<a class="indexterm" name="id2538724"></a>
+<a class="indexterm" name="id2538730"></a>
+Of course it should be clear that the authentication backend itself could be
+from any distributed directory architecture server that is supported by Samba.
+This can be LDAP (from OpenLDAP), or Sun's iPlanet, or Novell e-Directory
+Server, and so on.
+</em></span>
+</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+<a class="indexterm" name="id2538747"></a>
+<a class="indexterm" name="id2538754"></a>
+<a class="indexterm" name="id2538760"></a>
+When Samba is configured to use an LDAP or other identity management and/or
+directory service, it is Samba that continues to perform user and machine
+authentication. It should be noted that the LDAP server does not perform
+authentication handling in place of what Samba is designed to do.
+</p></div><p>
+<a class="indexterm" name="id2538776"></a>
+<a class="indexterm" name="id2538783"></a>
+<a class="indexterm" name="id2538790"></a>
+Please refer to <a href="samba-pdc.html" title="Chapter 4. Domain Control">Domain Control</a>, for more information regarding
+how to create a domain machine account for a domain member server as well as for
+information on how to enable the Samba domain member machine to join the domain
+and be fully trusted by it.
+</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2538809"></a>Joining an NT4-type Domain with Samba-3</h3></div></div></div><p><a href="domain-member.html#assumptions" title="Table 6.1. Assumptions">Assumptions</a> lists names that are used in the remainder of this chapter.</p><div class="table"><a name="assumptions"></a><p class="title"><b>Table 6.1. Assumptions</b></p><table summary="Assumptions" border="1"><colgroup><col align="right"><col align="left"></colgroup><tbody><tr><td align="right">Samba DMS NetBIOS name:</td><td align="left">SERV1</td></tr><tr><td align="right">Windows 200x/NT domain name:</td><td align="left">MIDEARTH</td></tr><tr><td align="right">Domain's PDC NetBIOS name:</td><td align="left">DOMPDC</td></tr><tr><td align="right">Domain's BDC NetBIOS names:</td><td align="left">DOMBDC1 and DOMBDC2</td></tr></tbody></table></div><p>
+<a class="indexterm" name="id2538894"></a>
+First, you must edit your <code class="filename">smb.conf</code> file to tell Samba it should now use domain security.
+</p><p>
+<a class="indexterm" name="id2538910"></a>
+<a class="indexterm" name="id2538917"></a>
+<a class="indexterm" name="id2538924"></a>
+<a class="indexterm" name="id2538931"></a>
+Change (or add) your <a class="indexterm" name="id2538938"></a>security line in the [global] section
+of your <code class="filename">smb.conf</code> to read:
+</p><table class="simplelist" border="0" summary="Simple list"><tr><td><a class="indexterm" name="id2538957"></a><em class="parameter"><code>security = domain</code></em></td></tr></table><p>
+Note that if the parameter <em class="parameter"><code>security = user</code></em> is used, this machine would function as a
+standalone server and not as a domain member server. Domain security mode causes Samba to work within the
+domain security context.
+</p><p>
+Next change the <a class="indexterm" name="id2538983"></a>workgroup line in the <em class="parameter"><code>[global]</code></em>
+section to read:
+</p><table class="simplelist" border="0" summary="Simple list"><tr><td><a class="indexterm" name="id2539002"></a><em class="parameter"><code>workgroup = MIDEARTH</code></em></td></tr></table><p>
+This is the name of the domain we are joining.
+</p><p>
+<a class="indexterm" name="id2539019"></a>
+<a class="indexterm" name="id2539026"></a>
+You must also have the parameter <a class="indexterm" name="id2539033"></a>encrypt passwords
+set to <code class="constant">yes</code> in order for your users to authenticate to the NT PDC.
+This is the default setting if this parameter is not specified. There is no need to specify this
+parameter, but if it is specified in the <code class="filename">smb.conf</code> file, it must be set to <code class="constant">Yes</code>.
+</p><p>
+<a class="indexterm" name="id2539060"></a>
+<a class="indexterm" name="id2539066"></a>
+<a class="indexterm" name="id2539073"></a>
+<a class="indexterm" name="id2539080"></a>
+Finally, add (or modify) a <a class="indexterm" name="id2539087"></a>password server line in the [global]
+section to read:
+</p><table class="simplelist" border="0" summary="Simple list"><tr><td><a class="indexterm" name="id2539101"></a><em class="parameter"><code>password server = DOMPDC DOMBDC1 DOMBDC2</code></em></td></tr></table><p>
+These are the PDC and BDCs 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>
+<a class="indexterm" name="id2539122"></a>
+<a class="indexterm" name="id2539129"></a>
+<a class="indexterm" name="id2539136"></a>
+<a class="indexterm" name="id2539143"></a>
+Alternatively, if you want smbd to determine automatically the list of domain controllers to use for
+authentication, you may set this line to be:
+</p><table class="simplelist" border="0" summary="Simple list"><tr><td><a class="indexterm" name="id2539158"></a><em class="parameter"><code>password server = *</code></em></td></tr></table><p>
+<a class="indexterm" name="id2539171"></a>
+This method allows Samba to use exactly the same mechanism that NT does. The
+method either uses broadcast-based name resolution, performs a WINS database
+lookup in order to find a domain controller against which to authenticate,
+or locates the domain controller using DNS name resolution.
+</p><p>
+To join the domain, run this command:
+<a class="indexterm" name="id2539186"></a>
+</p><pre class="screen">
+<code class="prompt">root# </code><strong class="userinput"><code>net rpc join -S DOMPDC -U<em class="replaceable"><code>Administrator%password</code></em></code></strong>
+</pre><p>
+</p><p>
+<a class="indexterm" name="id2539220"></a>
+<a class="indexterm" name="id2539226"></a>
+<a class="indexterm" name="id2539233"></a>
+<a class="indexterm" name="id2539240"></a>
+If the <code class="option">-S DOMPDC</code> argument is not given, the domain name will be obtained from <code class="filename">smb.conf</code> and
+the NetBIOS name of the PDC will be obtained either using a WINS lookup or via NetBIOS broadcast based name
+look up.
+</p><p>
+<a class="indexterm" name="id2539263"></a>
+<a class="indexterm" name="id2539270"></a>
+<a class="indexterm" name="id2539276"></a>
+<a class="indexterm" name="id2539283"></a>
+The machine is joining the domain DOM, and the PDC for that domain (the only machine
+that has write access to the domain SAM database) is DOMPDC; therefore, use the <code class="option">-S</code>
+option. The <em class="replaceable"><code>Administrator%password</code></em> is the login name and
+password for an account that has the necessary privilege to add machines to the
+domain. If this is successful, you will see the following message in your terminal window.
+Where the older NT4-style domain architecture is used:
+</p><pre class="screen">
+<code class="computeroutput">Joined domain DOM.</code>
+</pre><p>
+</p><p>
+<a class="indexterm" name="id2539319"></a>
+<a class="indexterm" name="id2539330"></a>
+<a class="indexterm" name="id2539337"></a>
+Where Active Directory is used, the command used to join the ADS domain is:
+</p><pre class="screen">
+<code class="prompt">root# </code> net ads join -U<em class="replaceable"><code>Administrator%password</code></em>
+</pre><p>
+And the following output is indicative of a successful outcome:
+</p><pre class="screen">
+<code class="computeroutput">Joined SERV1 to realm MYREALM.</code>
+</pre><p>
+</p><p>
+Refer to the <span><strong class="command">net</strong></span> man page and to <a href="NetCommand.html" title="Chapter 12. Remote and Local Management: The Net Command">the chapter on remote
+administration</a> for further information.
+</p><p>
+<a class="indexterm" name="id2539394"></a>
+<a class="indexterm" name="id2539401"></a>
+<a class="indexterm" name="id2539408"></a>
+This process joins the server to the domain without separately having to create the machine
+trust account on the PDC beforehand.
+</p><p>
+<a class="indexterm" name="id2539420"></a>
+<a class="indexterm" name="id2539430"></a>
+<a class="indexterm" name="id2539437"></a>
+<a class="indexterm" name="id2539444"></a>
+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 a smbpasswd file would be
+normally stored. The trust account information that is needed by the DMS is written into the file
+<code class="filename">/usr/local/samba/private/secrets.tdb</code> or <code class="filename">/etc/samba/secrets.tdb</code>.
+</p><p>
+<a class="indexterm" name="id2539473"></a>
+<a class="indexterm" name="id2539480"></a>
+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>
+<a class="indexterm" name="id2539494"></a>
+<a class="indexterm" name="id2539500"></a>
+<a class="indexterm" name="id2539507"></a>
+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 the following will suffice:
+</p><pre class="screen">
+<code class="prompt">root# </code>/etc/init.d/samba restart
+</pre><p>
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2539532"></a>Why Is This Better Than <em class="parameter"><code>security = server</code></em>?</h3></div></div></div><p>
+<a class="indexterm" name="id2539546"></a>
+<a class="indexterm" name="id2539553"></a>
+<a class="indexterm" name="id2539560"></a>
+Currently, domain security in Samba does not free you from having to create local UNIX users to represent the
+users attaching to your server. This means that if domain user <code class="constant">DOM\fred</code> attaches to your
+domain security Samba server, there needs to be a local UNIX user fred to represent that user in the UNIX file
+system. This is similar to the older Samba security mode <a class="indexterm" name="id2539576"></a>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>
+<a class="indexterm" name="id2539589"></a>
+<a class="indexterm" name="id2539596"></a>
+<a class="indexterm" name="id2539602"></a>
+Please refer to <a href="winbind.html" title="Chapter 23. Winbind: Use of Domain Accounts">Winbind: Use of Domain Accounts</a>, for information on a system
+to automatically assign UNIX UIDs and GIDs to Windows NT domain users and groups.
+</p><p>
+<a class="indexterm" name="id2539622"></a>
+<a class="indexterm" name="id2539629"></a>
+<a class="indexterm" name="id2539636"></a>
+The advantage of 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>
+<a class="indexterm" name="id2539653"></a>
+<a class="indexterm" name="id2539660"></a>
+<a class="indexterm" name="id2539666"></a>
+In addition, with <a class="indexterm" name="id2539674"></a>security = 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="id2539685"></a>security = domain, however, the Samba daemons connect to the PDC or BDC
+only for as long as is necessary to authenticate the user and then drop the connection, thus conserving PDC
+connection resources.
+</p><p>
+<a class="indexterm" name="id2539699"></a>
+<a class="indexterm" name="id2539705"></a>
+<a class="indexterm" name="id2539712"></a>
+<a class="indexterm" name="id2539719"></a>
+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, and so on.
+</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"><span class="emphasis"><em>LinuxWorld</em></span></a> as the article <a href="http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.html" target="_top">http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.html</a>
+<span class="emphasis"><em>Doing the NIS/NT Samba</em></span>.
+</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><p>
+<a class="indexterm" name="id2539769"></a>
+<a class="indexterm" name="id2539776"></a>
+<a class="indexterm" name="id2539785"></a>
+<a class="indexterm" name="id2539792"></a>
+This is a rough guide to setting up Samba-3 with Kerberos authentication against a
+Windows 200x KDC. A familiarity with Kerberos is assumed.
+</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2539802"></a>Configure <code class="filename">smb.conf</code></h3></div></div></div><p>
+You must use at least the following three options in <code class="filename">smb.conf</code>:
+</p><table class="simplelist" border="0" summary="Simple list"><tr><td><a class="indexterm" name="id2539828"></a><em class="parameter"><code>realm = your.kerberos.REALM</code></em></td></tr><tr><td><a class="indexterm" name="id2539840"></a><em class="parameter"><code>security = ADS</code></em></td></tr><tr><td># The following parameter need only be specified if present.</td></tr><tr><td># The default setting if not present is Yes.</td></tr><tr><td><a class="indexterm" name="id2539862"></a><em class="parameter"><code>encrypt passwords = yes</code></em></td></tr></table><p>
+<a class="indexterm" name="id2539877"></a>
+<a class="indexterm" name="id2539883"></a>
+<a class="indexterm" name="id2539890"></a>
+<a class="indexterm" name="id2539897"></a>
+<a class="indexterm" name="id2539903"></a>
+In case samba cannot correctly identify the appropriate ADS server using the realm name, use the
+<a class="indexterm" name="id2539912"></a>password server option in <code class="filename">smb.conf</code>:
+</p><table class="simplelist" border="0" summary="Simple list"><tr><td><a class="indexterm" name="id2539931"></a><em class="parameter"><code>password server = your.kerberos.server</code></em></td></tr></table><p>
+The most common reason for which Samba may not be able to locate the ADS domain controller is a consequence of
+sites maintaining some DNS servers on UNIX systems without regard for the DNS requirements of the ADS
+infrastructure. There is no harm in specifying a preferred ADS domain controller using the <em class="parameter"><code>password
+server</code></em>.
+</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+<a class="indexterm" name="id2539959"></a>
+<a class="indexterm" name="id2539966"></a>
+You do <span class="emphasis"><em>not</em></span> need an smbpasswd file, and older clients will be authenticated as
+if <a class="indexterm" name="id2539978"></a>security = domain, although it will not do any harm and
+allows you to have local users not in the domain.
+</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2539989"></a>Configure <code class="filename">/etc/krb5.conf</code></h3></div></div></div><p>
+<a class="indexterm" name="id2540002"></a>
+<a class="indexterm" name="id2540008"></a>
+<a class="indexterm" name="id2540018"></a>
+<a class="indexterm" name="id2540025"></a>
+With both MIT and Heimdal Kerberos, it is unnecessary to configure the <code class="filename">/etc/krb5.conf</code>,
+and it may be detrimental.
+</p><p>
+<a class="indexterm" name="id2540043"></a>
+<a class="indexterm" name="id2540049"></a>
+<a class="indexterm" name="id2540056"></a>
+<a class="indexterm" name="id2540063"></a>
+<a class="indexterm" name="id2540069"></a>
+Microsoft ADS automatically create SRV records in the DNS zone
+<em class="parameter"><code>_kerberos._tcp.REALM.NAME</code></em> for each KDC in the realm. This is part
+of the installation and configuration process used to create an Active Directory domain.
+A KDC is a Kerberos Key Distribution Center and forms an integral part of the Microsoft
+active directory infrastructure.
+</p><p>
+<a class="indexterm" name="id2540091"></a>
+<a class="indexterm" name="id2540098"></a>
+<a class="indexterm" name="id2540105"></a>
+<a class="indexterm" name="id2540111"></a>
+<a class="indexterm" name="id2540118"></a>
+<a class="indexterm" name="id2540125"></a>
+UNIX systems can use kinit and the DES-CBC-MD5 or DES-CBC-CRC encryption types to authenticate to the Windows
+2000 KDC. For further information regarding Windows 2000 ADS kerberos interoperability please refer to the
+Microsoft Windows 2000 Kerberos <a href="http://www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asp" target="_top">Interoperability</a>
+guide. Another very useful document that may be referred to for general information regarding Kerberos
+interoperability is <a href="http://www.ietf.org/rfc/rfc1510.txt?number=1510" target="_top">RFC1510</a>. This RFC
+explains much of the magic behind the operation of Kerberos.
+</p><p>
+<a class="indexterm" name="id2540157"></a>
+<a class="indexterm" name="id2540163"></a>
+<a class="indexterm" name="id2540170"></a>
+<a class="indexterm" name="id2540177"></a>
+<a class="indexterm" name="id2540184"></a>
+<a class="indexterm" name="id2540190"></a>
+MIT's, as well as Heimdal's, recent KRB5 libraries default to checking for SRV records, so they will
+automatically find the KDCs. In addition, <code class="filename">krb5.conf</code> only allows specifying
+a single KDC, even there if there may be more than one. Using the DNS lookup allows the KRB5
+libraries to use whichever KDCs are available.
+</p><p>
+<a class="indexterm" name="id2540212"></a>
+When manually configuring <code class="filename">krb5.conf</code>, the minimal configuration is:
+</p><pre class="screen">
+[libdefaults]
+ default_realm = YOUR.KERBEROS.REALM
+
+[realms]
+ YOUR.KERBEROS.REALM = {
+ kdc = your.kerberos.server
+ }
+
+[domain_realms]
+ .kerberos.server = YOUR.KERBEROS.REALM
+</pre><p>
+</p><p>
+<a class="indexterm" name="id2540237"></a>
+When using Heimdal versions before 0.6, use the following configuration settings:
+</p><pre class="screen">
+[libdefaults]
+ default_realm = YOUR.KERBEROS.REALM
+ default_etypes = des-cbc-crc des-cbc-md5
+ default_etypes_des = des-cbc-crc des-cbc-md5
+
+[realms]
+ YOUR.KERBEROS.REALM = {
+ kdc = your.kerberos.server
+ }
+
+[domain_realms]
+ .kerberos.server = YOUR.KERBEROS.REALM
+</pre><p>
+</p><p>
+<a class="indexterm" name="id2540259"></a>
+<a class="indexterm" name="id2540266"></a>
+Test your config by doing a <strong class="userinput"><code>kinit
+<em class="replaceable"><code>USERNAME</code></em>@<em class="replaceable"><code>REALM</code></em></code></strong> and
+making sure that your password is accepted by the Win2000 KDC.
+</p><p>
+<a class="indexterm" name="id2540289"></a>
+<a class="indexterm" name="id2540296"></a>
+<a class="indexterm" name="id2540303"></a>
+<a class="indexterm" name="id2540309"></a>
+With Heimdal versions earlier than 0.6.x you can use only newly created accounts
+in ADS or accounts that have had the password changed once after migration, or
+in case of <code class="constant">Administrator</code> after installation. At the
+moment, a Windows 2003 KDC can only be used with Heimdal releases later than 0.6
+(and no default etypes in krb5.conf). Unfortunately, this whole area is still
+in a state of flux.
+</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+<a class="indexterm" name="id2540331"></a>
+<a class="indexterm" name="id2540338"></a>
+<a class="indexterm" name="id2540344"></a>
+The realm must be in uppercase or you will get a “<span class="quote"><span class="errorname">Cannot find KDC for
+requested realm while getting initial credentials</span></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>
+<a class="indexterm" name="id2540362"></a>
+<a class="indexterm" name="id2540369"></a>
+<a class="indexterm" name="id2540376"></a>
+<a class="indexterm" name="id2540383"></a>
+Time between the two servers must be synchronized. You will get a “<span class="quote"><span class="errorname">kinit(v5): Clock skew too
+great while getting initial credentials</span></span>” if the time difference (clock skew) is more than five minutes.
+</p></div><p>
+<a class="indexterm" name="id2540401"></a>
+<a class="indexterm" name="id2540408"></a>
+Clock skew limits are configurable in the Kerberos protocols. The default setting is five minutes.
+</p><p>
+<a class="indexterm" name="id2540420"></a>
+<a class="indexterm" name="id2540426"></a>
+<a class="indexterm" name="id2540433"></a>
+<a class="indexterm" name="id2540439"></a>
+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 (i.e., the hostname with no domain
+attached) or it can be the NetBIOS name followed by the realm.
+</p><p>
+<a class="indexterm" name="id2540454"></a>
+<a class="indexterm" name="id2540461"></a>
+<a class="indexterm" name="id2540468"></a>
+The easiest way to ensure you get this right is to add a <code class="filename">/etc/hosts</code> entry mapping the IP
+address of your KDC to its NetBIOS name. If you do not get this correct, then you will get a <span class="errorname">local
+error</span> when you try to join the realm.
+</p><p>
+<a class="indexterm" name="id2540490"></a>
+<a class="indexterm" name="id2540497"></a>
+<a class="indexterm" name="id2540504"></a>
+<a class="indexterm" name="id2540511"></a>
+If all you want is Kerberos support in <span class="application">smbclient</span>, then you can skip directly to <a href="domain-member.html#ads-test-smbclient" title="Testing with smbclient">Testing with <span class="application">smbclient</span></a> now. <a href="domain-member.html#ads-create-machine-account" title="Create the Computer Account">Create the Computer Account</a> and <a href="domain-member.html#ads-test-server" title="Testing Server Setup">Testing Server Setup</a> are needed only 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><p>
+<a class="indexterm" name="id2540583"></a>
+<a class="indexterm" name="id2540589"></a>
+<a class="indexterm" name="id2540596"></a>
+<a class="indexterm" name="id2540603"></a>
+As a user who has write permission on the Samba private directory (usually root), run:
+</p><pre class="screen">
+<code class="prompt">root# </code> <strong class="userinput"><code>net ads join -U Administrator%password</code></strong>
+</pre><p>
+The Administrator account can be any account that has been designated in the ADS domain security settings with
+permission to add machines to the ADS domain. It is, of course, a good idea to use an account other than Administrator.
+On the UNIX/Linux system, this command must be executed by an account that has UID=0 (root).
+</p><p>
+<a class="indexterm" name="id2540643"></a>
+<a class="indexterm" name="id2540650"></a>
+<a class="indexterm" name="id2540657"></a>
+<a class="indexterm" name="id2540664"></a>
+<a class="indexterm" name="id2540671"></a>
+<a class="indexterm" name="id2540677"></a>
+When making a Windows client a member of an ADS domain within a complex organization, you
+may want to create the machine trust account within a particular organizational unit. Samba-3 permits
+this to be done using the following syntax:
+</p><pre class="screen">
+<code class="prompt">root# </code> <strong class="userinput"><code>kinit Administrator@your.kerberos.REALM</code></strong>
+<code class="prompt">root# </code> <strong class="userinput"><code>net ads join "organizational_unit"</code></strong>
+</pre><p>
+Your ADS manager will be able to advise what should be specified for the "organizational_unit" parameter.
+</p><p>
+<a class="indexterm" name="id2540727"></a>
+<a class="indexterm" name="id2540734"></a>
+<a class="indexterm" name="id2540741"></a>
+<a class="indexterm" name="id2540748"></a>
+For example, you may want to create the machine trust account in a container called “<span class="quote">Servers</span>”
+under the organizational directory “<span class="quote">Computers\BusinessUnit\Department,</span>” like this:
+</p><pre class="screen">
+<code class="prompt">root# </code> <strong class="userinput"><code>net ads join "Computers\BusinessUnit\Department\Servers"</code></strong>
+</pre><p>
+This command will place the Samba server machine trust account in the container
+<code class="literal">Computers\BusinessUnit\Department\Servers</code>. The container should exist in the ADS directory
+before executing this command.
+</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2540793"></a>Possible Errors</h4></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>
+ <a class="indexterm" name="id2540812"></a>
+ <a class="indexterm" name="id2540819"></a>
+ <a class="indexterm" name="id2540826"></a>
+ Samba must be reconfigured (remove config.cache) and recompiled (make clean all install) after the
+ Kerberos libraries and headers files are installed.
+ </p></dd><dt><span class="term"><span class="errorname">net ads join prompts for user name</span></span></dt><dd><p>
+ <a class="indexterm" name="id2540846"></a>
+ <a class="indexterm" name="id2540852"></a>
+ You need to log in to the domain using <strong class="userinput"><code>kinit
+ <em class="replaceable"><code>USERNAME</code></em>@<em class="replaceable"><code>REALM</code></em></code></strong>.
+ <em class="replaceable"><code>USERNAME</code></em> must be a user who has rights to add a machine to the domain.
+ </p></dd><dt><span class="term">Unsupported encryption/or checksum types</span></dt><dd><p>
+ <a class="indexterm" name="id2540886"></a>
+ <a class="indexterm" name="id2540892"></a>
+ <a class="indexterm" name="id2540900"></a>
+ Make sure that the <code class="filename">/etc/krb5.conf</code> is correctly configured
+ for the type and version of Kerberos installed on the system.
+ </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>Testing Server Setup</h3></div></div></div><p>
+<a class="indexterm" name="id2540931"></a>
+<a class="indexterm" name="id2540938"></a>
+<a class="indexterm" name="id2540945"></a>
+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 “<span class="quote">Computers</span>”
+folder under Users and Computers.
+</p><p>
+<a class="indexterm" name="id2540961"></a>
+<a class="indexterm" name="id2540968"></a>
+<a class="indexterm" name="id2540977"></a>
+On a Windows 2000 client, try <strong class="userinput"><code>net use * \\server\share</code></strong>. You should
+be logged in with Kerberos without needing to know a password. If this fails, then run
+<strong class="userinput"><code>klist tickets</code></strong>. Did you get a ticket for the server? Does it have
+an encryption type of DES-CBC-MD5?
+</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+<a class="indexterm" name="id2541004"></a>
+<a class="indexterm" name="id2541011"></a>
+<a class="indexterm" name="id2541018"></a>
+Samba can use both DES-CBC-MD5 encryption as well as ARCFOUR-HMAC-MD5 encoding.
+</p></div></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><p>
+<a class="indexterm" name="id2541045"></a>
+<a class="indexterm" name="id2541052"></a>
+<a class="indexterm" name="id2541058"></a>
+On your Samba server try to log in to a Windows 2000 server or your Samba
+server using <span class="application">smbclient</span> and Kerberos. Use <span class="application">smbclient</span> as usual, but
+specify the <code class="option">-k</code> option to choose Kerberos authentication.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2541086"></a>Notes</h3></div></div></div><p>
+<a class="indexterm" name="id2541093"></a>
+<a class="indexterm" name="id2541100"></a>
+<a class="indexterm" name="id2541107"></a>
+You must change the administrator password at least once after installing a domain controller,
+to create the right encryption types.
+</p><p>
+<a class="indexterm" name="id2541120"></a>
+<a class="indexterm" name="id2541127"></a>
+<a class="indexterm" name="id2541134"></a>
+Windows 200x does not seem to create the <em class="parameter"><code>_kerberos._udp</code></em> and
+<em class="parameter"><code>_ldap._tcp</code></em> in the default DNS setup. Perhaps 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="id2541158"></a>Sharing User ID Mappings between Samba Domain Members</h2></div></div></div><p>
+<a class="indexterm" name="id2541166"></a>
+<a class="indexterm" name="id2541173"></a>
+<a class="indexterm" name="id2541180"></a>
+<a class="indexterm" name="id2541186"></a>
+Samba maps UNIX users and groups (identified by UIDs and GIDs) to Windows users and groups (identified by SIDs).
+These mappings are done by the <em class="parameter"><code>idmap</code></em> subsystem of Samba.
+</p><p>
+<a class="indexterm" name="id2541205"></a>
+<a class="indexterm" name="id2541212"></a>
+<a class="indexterm" name="id2541219"></a>
+In some cases it is useful to share these mappings between Samba domain members,
+so <span class="emphasis"><em>name->id</em></span> mapping is identical on all machines.
+This may be needed in particular when sharing files over both CIFS and NFS.
+</p><p>
+<a class="indexterm" name="id2541236"></a>
+<a class="indexterm" name="id2541243"></a>
+To use the <span class="emphasis"><em>LDAP</em></span> <em class="parameter"><code>ldap idmap suffix</code></em>, set:
+</p><table class="simplelist" border="0" summary="Simple list"><tr><td><a class="indexterm" name="id2541266"></a><em class="parameter"><code>ldap idmap suffix = ou=Idmap,dc=quenya,dc=org</code></em></td></tr></table><p>
+See the <code class="filename">smb.conf</code> man page entry for the <a class="indexterm" name="id2541288"></a>ldap idmap suffix
+parameter for further information.
+</p><p>
+<a class="indexterm" name="id2541299"></a>
+<a class="indexterm" name="id2541306"></a>
+<a class="indexterm" name="id2541313"></a>
+Do not forget to specify also the <a class="indexterm" name="id2541321"></a>ldap admin dn
+and to make certain to set the LDAP administrative password into the <code class="filename">secrets.tdb</code> using:
+</p><pre class="screen">
+<code class="prompt">root# </code> smbpasswd -w ldap-admin-password
+</pre><p>
+In place of <code class="literal">ldap-admin-password</code>, substitute the LDAP administration password for your
+system.
+</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2541357"></a>Common Errors</h2></div></div></div><p>
+<a class="indexterm" name="id2541365"></a>
+<a class="indexterm" name="id2541372"></a>
+In the process of adding/deleting/re-adding domain member machine trust accounts, there are
+many traps for the unwary player and 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 “<span class="quote">reinstall</span>”
+MS Windows on the machine. In truth, it is seldom necessary to reinstall because of this type
+of problem. The real solution is often quite simple, and with an understanding of how MS Windows
+networking functions, it is easy to overcome.
+</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2541397"></a>Cannot Add Machine Back to Domain</h3></div></div></div><p>
+<a class="indexterm" name="id2541405"></a>
+<a class="indexterm" name="id2541412"></a>
+“<span class="quote">A Windows workstation was reinstalled. The original domain machine trust
+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 does not. Why is this failing?</span>”
+</p><p>
+<a class="indexterm" name="id2541434"></a>
+<a class="indexterm" name="id2541440"></a>
+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 add the machine with a new name. Alternately, the name cache can be flushed and
+reloaded with current data using the <span><strong class="command">nbtstat</strong></span> command on the Windows client:
+</p><pre class="screen">
+<code class="prompt">C:\> </code> nbtstat -R
+</pre><p>
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2541473"></a>Adding Machine to Domain Fails</h3></div></div></div><p>
+<a class="indexterm" name="id2541481"></a>
+<a class="indexterm" name="id2541488"></a>
+“<span class="quote">Adding a Windows 200x or XP Professional machine to the Samba PDC Domain fails with a
+message that says, <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>
+<a class="indexterm" name="id2541508"></a>
+You should check that there is an <a class="indexterm" name="id2541515"></a>add machine script in your <code class="filename">smb.conf</code>
+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 its operation. Increase the <a class="indexterm" name="id2541531"></a>log level
+in the <code class="filename">smb.conf</code> 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>
+<a class="indexterm" name="id2541556"></a>
+<a class="indexterm" name="id2541563"></a>
+ The script does not actually exist, or could not be located in the path specified.
+ </p><p>
+<a class="indexterm" name="id2541575"></a>
+<a class="indexterm" name="id2541582"></a>
+ <span class="emphasis"><em>Corrective action:</em></span> Fix it. Make sure when run manually
+ that the script will add both the UNIX system account and the Samba SAM account.
+ </p></li><li><p>
+<a class="indexterm" name="id2541599"></a>
+<a class="indexterm" name="id2541606"></a>
+ The machine could not be added to the UNIX system accounts file <code class="filename">/etc/passwd</code>.
+ </p><p>
+<a class="indexterm" name="id2541623"></a>
+<a class="indexterm" name="id2541630"></a>
+ <span class="emphasis"><em>Corrective action:</em></span> Check that the machine name is a legal UNIX
+ system account name. If the UNIX utility <span><strong class="command">useradd</strong></span> is called,
+ then make sure that the machine name you are trying to add can be added using this
+ tool. <span><strong class="command">Useradd</strong></span> on some systems will not allow any uppercase characters
+ nor will it allow spaces in the name.
+ </p></li></ul></div><p>
+<a class="indexterm" name="id2541661"></a>
+<a class="indexterm" name="id2541668"></a>
+<a class="indexterm" name="id2541675"></a>
+The <a class="indexterm" name="id2541682"></a>add machine script does not create the
+machine account in the Samba backend database; it is there only to create a UNIX system
+account to which the Samba backend database account can be mapped.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2541695"></a>I Can't Join a Windows 2003 PDC</h3></div></div></div><p>
+<a class="indexterm" name="id2541703"></a>
+<a class="indexterm" name="id2541710"></a>
+<a class="indexterm" name="id2541716"></a>
+<a class="indexterm" name="id2541723"></a>
+ Windows 2003 requires SMB signing. Client-side SMB signing has been implemented in Samba-3.0.
+ Set <a class="indexterm" name="id2541732"></a>client use spnego = yes when communicating
+ with a Windows 2003 server. This will not interfere with other Windows clients that do not
+ support the more advanced security features of Windows 2003 because the client will simply
+ negotiate a protocol tha both it and the server suppport. This is a well-known fall-back facility
+ that is built into the SMB/CIFS protocols.
+ </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 5. Backup Domain Control </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 7. Standalone Servers</td></tr></table></div></body></html>
projects / samba / blobdiff