summaryrefslogtreecommitdiff
path: root/docs/htmldocs/domain-member.html
diff options
context:
space:
mode:
authorGerald Carter <jerry@samba.org>2003-07-16 05:34:56 +0000
committerGerald Carter <jerry@samba.org>2003-07-16 05:34:56 +0000
commit4a090ba06a54f5da179ac02bb307cc03d08831bf (patch)
treeed652ef36be7f16682c358816334f969a22f1c27 /docs/htmldocs/domain-member.html
parent95fe82670032a3a43571b46d7bbf2c26bc8cdcd9 (diff)
downloadsamba-4a090ba06a54f5da179ac02bb307cc03d08831bf.tar.gz
samba-4a090ba06a54f5da179ac02bb307cc03d08831bf.tar.bz2
samba-4a090ba06a54f5da179ac02bb307cc03d08831bf.zip
trying to get HEAD building again. If you want the code
prior to this merge, checkout HEAD_PRE_3_0_0_BETA_3_MERGE (This used to be commit adb98e7b7cd0f025b52c570e4034eebf4047b1ad)
Diffstat (limited to 'docs/htmldocs/domain-member.html')
-rw-r--r--docs/htmldocs/domain-member.html607
1 files changed, 528 insertions, 79 deletions
diff --git a/docs/htmldocs/domain-member.html b/docs/htmldocs/domain-member.html
index 5be675a541..59040dfebc 100644
--- a/docs/htmldocs/domain-member.html
+++ b/docs/htmldocs/domain-member.html
@@ -1,79 +1,528 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 8. Samba as a NT4 or Win2k domain member</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.59.1"><link rel="home" href="index.html" title="SAMBA Project Documentation"><link rel="up" href="type.html" title="Part II. Server Configuration Basics"><link rel="previous" href="ADS.html" title="Chapter 7. Samba as a ADS domain member"><link rel="next" href="optional.html" title="Part III. Advanced Configuration"></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 8. Samba as a NT4 or Win2k domain member</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ADS.html">Prev</a> </td><th width="60%" align="center">Part II. Server Configuration Basics</th><td width="20%" align="right"> <a accesskey="n" href="optional.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><h2 class="title"><a name="domain-member"></a>Chapter 8. Samba as a NT4 or Win2k domain member</h2></div><div><div class="author"><h3 class="author">Jeremy Allison</h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt>&lt;<a href="mailto:jra@samba.org">jra@samba.org</a>&gt;</tt></p></div></div></div></div><div><div class="author"><h3 class="author">Gerald (Jerry) Carter</h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt>&lt;<a href="mailto:jerry@samba.org">jerry@samba.org</a>&gt;</tt></p></div></div></div></div><div><p class="pubdate">16 Apr 2001</p></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><a href="domain-member.html#id2879309">Joining an NT Domain with Samba 3.0</a></dt><dt><a href="domain-member.html#id2880214">Why is this better than security = server?</a></dt></dl></div><div class="sect1" lang="en"><div class="titlepage"><div><h2 class="title" style="clear: both"><a name="id2879309"></a>Joining an NT Domain with Samba 3.0</h2></div></div><p><span class="emphasis"><em>Assumptions:</em></span>
- </p><pre class="programlisting">
- NetBIOS name: SERV1
- Win2K/NT domain name: DOM
- Domain's PDC NetBIOS name: DOMPDC
- Domain's BDC NetBIOS names: DOMBDC1 and DOMBDC2
- </pre><p>
- </p><p>First, you must edit your <tt>smb.conf</tt> file to tell Samba it should
- now use domain security.</p><p>Change (or add) your <a href="smb.conf.5.html#SECURITY" target="_top">
- <i><tt>security =</tt></i></a> line in the [global] section
- of your <tt>smb.conf</tt> to read:</p><p><b>security = domain</b></p><p>Next change the <a href="smb.conf.5.html#WORKGROUP" target="_top"><i><tt>
- workgroup =</tt></i></a> line in the [global] section to read: </p><p><b>workgroup = DOM</b></p><p>as this is the name of the domain we are joining. </p><p>You must also have the parameter <a href="smb.conf.5.html#ENCRYPTPASSWORDS" target="_top">
- <i><tt>encrypt passwords</tt></i></a> set to <tt>yes
- </tt> in order for your users to authenticate to the NT PDC.</p><p>Finally, add (or modify) a <a href="smb.conf.5.html#PASSWORDSERVER" target="_top">
- <i><tt>password server =</tt></i></a> line in the [global]
- section to read: </p><p><b>password server = DOMPDC DOMBDC1 DOMBDC2</b></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><b>password server = *</b></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><tt>root# </tt><b><tt>net join -S DOMPDC
- -U<i><tt>Administrator%password</tt></i></tt></b></p><p>
- If the <b><tt>-S DOMPDC</tt></b> argument is not given then
- the domain name will be obtained from smb.conf.
- </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. The <i><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>Joined domain DOM.</tt>
- or <tt>Joined 'SERV1' to realm 'MYREALM'</tt>
- </p><p>in your terminal window. See the <a href="net.8.html" target="_top">
- net(8)</a> 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>/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!</p></div><div class="sect1" lang="en"><div class="titlepage"><div><h2 class="title" style="clear: both"><a name="id2880214"></a>Why is this better than security = server?</h2></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>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
- <a href="smb.conf.5.html#SECURITYEQUALSSERVER" target="_top">security = server</a>,
- 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 the <a href="winbind.html" target="_top">Winbind
- paper</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 <b>security = server</b> 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 <b>security = domain</b>,
- 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="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ADS.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="optional.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 7. Samba as a ADS domain member </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Part III. Advanced Configuration</td></tr></table></div></body></html>
+<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="index.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">&lt;<a href="mailto:jht@samba.org">jht@samba.org</a>&gt;</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">&lt;<a href="mailto:jra@samba.org">jra@samba.org</a>&gt;</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">&lt;<a href="mailto:jerry@samba.org">jerry@samba.org</a>&gt;</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">&lt;<a href="mailto:tridge@samba.org">tridge@samba.org</a>&gt;</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">&lt;<a href="mailto:jelmer@samba.org">jelmer@samba.org</a>&gt;</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#id2897897">Features and Benefits</a></dt><dt><a href="domain-member.html#id2898012">MS Windows Workstation/Server Machine Trust Accounts</a></dt><dd><dl><dt><a href="domain-member.html#id2898188">Manual Creation of Machine Trust Accounts</a></dt><dt><a href="domain-member.html#id2898440">Using NT4 Server Manager to Add Machine Accounts to the Domain</a></dt><dt><a href="domain-member.html#id2898636">&quot;On-the-Fly&quot; Creation of Machine Trust Accounts</a></dt><dt><a href="domain-member.html#id2898699">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#id2898901">Joining an NT4 type Domain with Samba-3</a></dt><dt><a href="domain-member.html#id2899283">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#id2899424">Setup your smb.conf</a></dt><dt><a href="domain-member.html#id2899508">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#id2899872">Notes</a></dt></dl></dd><dt><a href="domain-member.html#id2899892">Common Errors</a></dt><dd><dl><dt><a href="domain-member.html#id2899919">Can Not Add Machine Back to Domain</a></dt><dt><a href="domain-member.html#id2899951">Adding Machine to Domain Fails</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="id2897897"></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="id2898012"></a>MS Windows Workstation/Server Machine Trust Accounts</h2></div></div><div></div></div><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 &quot;Computer Account.&quot;
+</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
+ <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><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>
+ 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>
+ &quot;On-the-fly&quot; 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="id2898188"></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:
+</p><p>
+<tt class="prompt">root# </tt><b class="userinput"><tt>/usr/sbin/useradd -g 100 -d /dev/null -c <i class="replaceable"><tt>&quot;machine nickname&quot;</tt></i> -s /bin/false <i class="replaceable"><tt>machine_name</tt></i>$ </tt></b>
+</p><p>
+<tt class="prompt">root# </tt><b class="userinput"><tt>passwd -l <i class="replaceable"><tt>machine_name</tt></i>$</tt></b>
+</p><p>
+On *BSD systems, this can be done using the <b class="command">chpass</b> utility:
+</p><p>
+<tt class="prompt">root# </tt><b class="userinput"><tt>chpass -a &quot;<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&quot;</tt></b>
+</p><p>
+The <tt class="filename">/etc/passwd</tt> entry will list the machine name
+with a &quot;$&quot; 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:501:<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 &quot;$&quot; 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 <a href="smbpasswd.8.html" target="_top"><b class="command">smbpasswd(8)</b></a> 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
+ 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="id2898440"></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</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 any other MS Windows 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
+<span class="application">MS Windows 9x/Me/200x/XP</span>.
+</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="id2898636"></a>&quot;On-the-Fly&quot; 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
+<a href="smb.conf.5.html#ADDMACHINESCRIPT" target="_top">add machine script</a> 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><pre class="programlisting">
+[global]
+ # &lt;...remainder of parameters...&gt;
+ add machine script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u
+</pre></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2898699"></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="id2898711"></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
+ <i class="parameter"><tt>username map = /etc/samba/smbusers</tt></i>.
+ </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="id2898779"></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="id2898820"></a>Samba</h4></div></div><div></div></div><p>Joining a Samba client to a domain is documented in
+ the <a href="domain-member.html#domain-member-server" title="Domain Member Server">Domain Member Server</a> section of this chapter chapter.
+ </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 the <a href="samba-pdc.html" title="Chapter 5. Domain Control">Domain Control chapter</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="id2898901"></a>Joining an NT4 type Domain with Samba-3</h3></div></div><div></div></div><p>
+ </p><div class="table"><a name="id2898912"></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">DOM</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 href="smb.conf.5.html#SECURITY" target="_top">
+<i class="parameter"><tt>security</tt></i></a> line in the [global] section
+of your <tt class="filename">smb.conf</tt> to read:
+</p><p>
+</p><pre class="programlisting">
+security = domain
+</pre><p>
+</p><p>
+Next change the <a href="smb.conf.5.html#WORKGROUP" target="_top"><i class="parameter"><tt>
+workgroup</tt></i></a> line in the <i class="parameter"><tt>[global]</tt></i>
+section to read:
+</p><p>
+</p><pre class="programlisting">
+workgroup = DOM
+</pre><p>
+</p><p>
+as this is the name of the domain we are joining.
+</p><p>
+You must also have the parameter <a href="smb.conf.5.html#ENCRYPTPASSWORDS" target="_top">
+<i class="parameter"><tt>encrypt passwords</tt></i></a> 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 href="smb.conf.5.html#PASSWORDSERVER" target="_top">
+<i class="parameter"><tt>password server</tt></i></a> line in the [global]
+section to read:
+</p><p>
+</p><pre class="programlisting">
+password server = DOMPDC DOMBDC1 DOMBDC2
+</pre><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><pre class="programlisting">
+password server = *
+</pre><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 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 <a href="net.8.html" target="_top">
+net(8)</a> 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!
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2899283"></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
+<a href="smb.conf.5.html#SECURITYEQUALSSERVER" target="_top">security = server</a>,
+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 the <a href="winbind.html" title="Chapter 21. Integrated Logon Support using Winbind">Winbind</a> chapter
+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 <i class="parameter"><tt>security = server</tt></i> 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 <i class="parameter"><tt>security = domain</tt></i>,
+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><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="id2899424"></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><pre class="programlisting">
+ realm = your.kerberos.REALM
+ security = ADS
+ encrypt passwords = yes
+</pre><p>
+In case samba can't figure out your ads server using your realm name, use the
+<i class="parameter"><tt>ads server</tt></i> option in <tt class="filename">smb.conf</tt>:
+</p><pre class="programlisting">
+ ads server = your.kerberos.server
+</pre><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 <i class="parameter"><tt>security = domain</tt></i>, 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="id2899508"></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">
+ [realms]
+ YOUR.KERBEROS.REALM = {
+ kdc = your.kerberos.server
+ }
+</pre><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.
+</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="programlisting">
+ <tt class="prompt">root# </tt><b class="userinput"><tt>net join -U Administrator%password</tt></b>
+</pre><p>
+</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2899718"></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 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 &quot;Computers&quot;
+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><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 <i class="parameter"><tt>-k</tt></i> option to choose Kerberos authentication.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2899872"></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 fixed in service packs?
+</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2899892"></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 &#8220;<span class="quote">little</span>&#8221; 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 &quot;re-install&quot;
+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. easily overcome.
+</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2899919"></a>Can Not Add Machine Back to Domain</h3></div></div><div></div></div><p>
+<span class="emphasis"><em>Problem:</em></span> 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?
+</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="id2899951"></a>Adding Machine to Domain Fails</h3></div></div><div></div></div><p>
+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?
+</p><p>
+You should check that there is an <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 <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></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="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 8. Stand-Alone Servers</td></tr></table></div></body></html>