trying to get HEAD building again. If you want the code
[abartlet/samba.git/.git] / docs / htmldocs / domain-member.html
1 <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>
2 Domain Membership is a subject of vital concern, Samba must be able to
3 participate as a member server in a Microsoft Domain security context, and
4 Samba must be capable of providing Domain machine member trust accounts,
5 otherwise it would not be capable of offering a viable option for many users.
6 </p><p>
7 This chapter covers background information pertaining to domain membership,
8 Samba configuration for it, and MS Windows client procedures for joining a
9 domain.  Why is this necessary? Because both are areas in which there exists
10 within the current MS Windows networking world and particularly in the
11 Unix/Linux networking and administration world, a considerable level of
12 mis-information, incorrect understanding, and a lack of knowledge. Hopefully
13 this chapter will fill the voids.
14 </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>
15 MS Windows workstations and servers that want to participate in domain
16 security need to
17 be made Domain members. Participating in Domain security is often called 
18 <span class="emphasis"><em>Single Sign On</em></span> or <span class="acronym">SSO</span> for short. This
19 chapter describes the process that must be followed to make a workstation
20 (or another server - be it an <span class="application">MS Windows NT4 / 200x</span>
21 server) or a Samba server a member of an MS Windows Domain security context.
22 </p><p>
23 Samba-3 can join an MS Windows NT4 style domain as a native member server, an 
24 MS Windows Active Directory Domain as a native member server, or a Samba Domain
25 Control network.
26 </p><p>
27 Domain membership has many advantages:
28 </p><div class="itemizedlist"><ul type="disc"><li><p>
29         MS Windows workstation users get the benefit of SSO
30         </p></li><li><p>
31         Domain user access rights and file ownership / access controls can be set
32         from the single Domain SAM (Security Account Manager) database 
33         (works with Domain member servers as well as with MS Windows workstations
34         that are domain members)
35         </p></li><li><p>
36         Only <span class="application">MS Windows NT4 / 200x / XP Professional</span>
37         workstations that are Domain members
38         can use network logon facilities
39         </p></li><li><p>
40         Domain Member workstations can be better controlled through the use of
41         Policy files (<tt class="filename">NTConfig.POL</tt>) and Desktop Profiles.
42         </p></li><li><p>
43         Through the use of logon scripts, users can be given transparent access to network
44         applications that run off application servers
45         </p></li><li><p>
46         Network administrators gain better application and user access management
47         abilities because there is no need to maintain user accounts on any network
48         client or server, other than the central Domain database 
49         (either NT4/Samba SAM style Domain, NT4 Domain that is back ended with an
50         LDAP directory, or via an Active Directory infrastructure)
51         </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>
52 A machine trust account is an account that is used to authenticate a client
53 machine
54 (rather than a user) to the Domain Controller server.  In Windows terminology,
55 this is known as a &quot;Computer Account.&quot;
56 </p><p>
57 The password of a machine trust account acts as the shared secret for
58 secure communication with the Domain Controller.  This is a security
59 feature to prevent an unauthorized machine with the same NetBIOS name
60 from joining the domain and gaining access to domain user/group
61 accounts.  Windows NT, 200x, XP Professional clients use machine trust
62 accounts, but Windows 9x / Me / XP Home clients do not.  Hence, a
63 Windows 9x / Me / XP Home  client is never a true member of a domain
64 because it does not possess a machine trust account, and thus has no
65 shared secret with the domain controller.
66 </p><p>
67 A Windows NT4 PDC stores each machine trust account in the Windows Registry.
68 The introduction of MS Windows 2000 saw the introduction of Active Directory,
69 the new repository for machine trust accounts.
70 </p><p>
71 A Samba PDC, however, stores each machine trust account in two parts,
72 as follows:
73
74 </p><div class="itemizedlist"><ul type="disc"><li><p>
75         A Domain Security Account (stored in the 
76         <i class="parameter"><tt>passdb backend</tt></i> that has been configured in the
77         <tt class="filename">smb.conf</tt> file. The precise nature of the account information that is
78         stored depends on the type of backend database that has been chosen.
79         </p><p>
80         The older format of this data is the <tt class="filename">smbpasswd</tt> database
81         which contains the unix login ID, the Unix user identifier (UID), and the
82         LanMan and NT encrypted passwords. There is also some other information in
83         this file that we do not need to concern ourselves with here.
84         </p><p>
85         The two newer database types are called <span class="emphasis"><em>ldapsam</em></span>,
86         <span class="emphasis"><em>tdbsam</em></span>.  Both store considerably more data than the
87         older <tt class="filename">smbpasswd</tt> file did. The extra information
88         enables new user account controls to be used.
89         </p></li><li><p>
90         A corresponding Unix account, typically stored in
91         <tt class="filename">/etc/passwd</tt>.  Work is in progress to allow a
92         simplified mode of operation that does not require Unix user accounts, but
93         this may not be a feature of the early releases of Samba-3.
94         </p></li></ul></div><p>
95 </p><p>
96 There are three ways to create machine trust accounts:
97 </p><div class="itemizedlist"><ul type="disc"><li><p>
98         Manual creation from the Unix/Linux command line. Here, both the Samba and
99         corresponding Unix account are created by hand.
100         </p></li><li><p>
101         Using the MS Windows NT4 Server Manager (either from an NT4 Domain member
102         server, or using the Nexus toolkit available from the Microsoft web site.
103         This tool can be run from any MS Windows machine so long as the user is
104         logged on as the administrator account.
105         </p></li><li><p>
106         &quot;On-the-fly&quot; creation. The Samba machine trust account is automatically
107         created by Samba at the time the client is joined to the domain.
108         (For security, this is the recommended method.) The corresponding Unix
109         account may be created automatically or manually. 
110         </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>
111 The first step in manually creating a machine trust account is to manually
112 create the corresponding Unix account in <tt class="filename">/etc/passwd</tt>. 
113 This can be done using <b class="command">vipw</b> or another 'add user' command
114 that is normally used to create new Unix accounts.  The following is an example for a Linux based Samba server:
115 </p><p>
116 <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>
117 </p><p>
118 <tt class="prompt">root# </tt><b class="userinput"><tt>passwd -l <i class="replaceable"><tt>machine_name</tt></i>$</tt></b>
119 </p><p>
120 On *BSD systems, this can be done using the <b class="command">chpass</b> utility:
121 </p><p>
122 <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>
123 </p><p>
124 The <tt class="filename">/etc/passwd</tt> entry will list the machine name 
125 with a &quot;$&quot; appended, won't have a password, will have a null shell and no 
126 home directory. For example a machine named 'doppy' would have an 
127 <tt class="filename">/etc/passwd</tt> entry like this:
128 </p><pre class="programlisting">
129 doppy$:x:505:501:<i class="replaceable"><tt>machine_nickname</tt></i>:/dev/null:/bin/false
130 </pre><p>
131 Above, <i class="replaceable"><tt>machine_nickname</tt></i> can be any
132 descriptive name for the client, i.e., BasementComputer.
133 <i class="replaceable"><tt>machine_name</tt></i> absolutely must be the NetBIOS
134 name of the client to be joined to the domain.  The &quot;$&quot; must be
135 appended to the NetBIOS name of the client or Samba will not recognize
136 this as a machine trust account.
137 </p><p>
138 Now that the corresponding Unix account has been created, the next step is to create 
139 the Samba account for the client containing the well-known initial 
140 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 
141 as shown here:
142 </p><p>
143 </p><pre class="screen">
144 <tt class="prompt">root# </tt><b class="userinput"><tt>smbpasswd -a -m <i class="replaceable"><tt>machine_name</tt></i></tt></b>
145 </pre><p>
146 </p><p>
147 where <i class="replaceable"><tt>machine_name</tt></i> is the machine's NetBIOS
148 name.  The RID of the new machine account is generated from the UID of 
149 the corresponding Unix account.
150 </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>
151         Manually creating a machine trust account using this method is the 
152         equivalent of creating a machine trust account on a Windows NT PDC using 
153         the <span class="application">Server Manager</span>.  From the time at which the 
154         account is created to the time which the client joins the domain and 
155         changes the password, your domain is vulnerable to an intruder joining 
156         your domain using a machine with the same NetBIOS name.  A PDC inherently 
157         trusts members of the domain and will serve out a large degree of user 
158         information to such clients.  You have been warned!
159         </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>
160 If the machine from which you are trying to manage the domain is an 
161 <span class="application">MS Windows NT4 workstation</span>
162 then the tool of choice is the package called <b class="command">SRVTOOLS.EXE</b>. 
163 When executed in the target directory this will unpack 
164 <b class="command">SrvMge.exe</b> and <b class="command">UsrMgr.exe</b> (both are 
165 Domain Management tools for MS Windows NT4 workstation.
166 </p><p>
167 If your workstation is any other MS Windows product you should download the
168 <b class="command">Nexus.exe</b> package from the Microsoft web site. When executed 
169 from the target directory this will unpack the same tools but for use on 
170 <span class="application">MS Windows 9x/Me/200x/XP</span>.
171 </p><p>
172 Launch the <b class="command">srvmgr.exe</b> (Server Manager for Domains) and follow these steps:
173 </p><div class="procedure"><p class="title"><b>Procedure 7.1. Server Manager Account Machine Account Management</b></p><ol type="1"><li><p>
174         From the menu select <span class="guimenu">Computer</span>
175         </p></li><li><p>
176         Click on <span class="guimenuitem">Select Domain</span>
177         </p></li><li><p>
178         Click on the name of the domain you wish to administer in the
179         <span class="guilabel">Select Domain</span> panel and then click 
180         <span class="guibutton">OK</span>.
181         </p></li><li><p>
182         Again from the menu select <span class="guimenu">Computer</span>
183         </p></li><li><p>
184         Select <span class="guimenuitem">Add to Domain</span>
185         </p></li><li><p>
186         In the dialog box, click on the radio button to 
187         <span class="guilabel">Add NT Workstation of Server</span>, then
188         enter the machine name in the field provided, then click the 
189         <span class="guibutton">Add</span> button.
190         </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>
191 The second (and recommended) way of creating machine trust accounts is
192 simply to allow the Samba server to create them as needed when the client
193 is joined to the domain.
194 </p><p>Since each Samba machine trust account requires a corresponding Unix account, a method
195 for automatically creating the Unix account is usually supplied; this requires configuration of the
196 <a href="smb.conf.5.html#ADDMACHINESCRIPT" target="_top">add machine script</a> option in
197 <tt class="filename">smb.conf</tt>. This method is not required, however; corresponding Unix
198 accounts may also be created manually.
199 </p><p>
200 Below is an example for a RedHat Linux system.
201 </p><pre class="programlisting">
202 [global]
203    # &lt;...remainder of parameters...&gt;
204    add machine script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u 
205 </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>
206 The procedure for making an MS Windows workstation of server a member of the domain varies
207 with the version of Windows:
208 </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>
209         When the user elects to make the client a domain member, Windows 200x prompts for
210         an account and password that has privileges to create  machine accounts in the domain.
211         A Samba administrative account (i.e., a Samba account that has root privileges on the
212         Samba server) must be entered here; the operation will fail if an ordinary user
213         account is given. 
214         </p><p>
215         Note: For security reasons the password for this administrative account should be set
216         to a password that is other than that used for the root user in the
217         <tt class="filename">/etc/passwd</tt>.
218         </p><p>
219         The name of the account that is used to create domain member machine accounts can be
220         anything the network administrator may choose. If it is other than <span class="emphasis"><em>root</em></span>
221         then this is easily mapped to root using the file pointed to be the <tt class="filename">smb.conf</tt> parameter
222         <i class="parameter"><tt>username map = /etc/samba/smbusers</tt></i>.
223         </p><p>
224         The session key of the Samba administrative account acts as an
225         encryption key for setting the password of the machine trust
226         account. The machine trust account will be created on-the-fly, or
227         updated if it already exists.
228         </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>
229         If the machine trust account was created manually, on the
230         Identification Changes menu enter the domain name, but do not
231         check the box <span class="guilabel">Create a Computer Account in the Domain</span>.
232         In this case, the existing machine trust account is used to join the machine 
233         to the domain.
234         </p><p>
235         If the machine trust account is to be created
236         on-the-fly, on the Identification Changes menu enter the domain
237         name, and check the box <span class="guilabel">Create a Computer Account in the 
238         Domain</span>.  In this case, joining the domain proceeds as above
239         for Windows 2000 (i.e., you must supply a Samba administrative account when
240         prompted).
241         </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 
242         the <a href="domain-member.html#domain-member-server" title="Domain Member Server">Domain Member Server</a> section of this chapter chapter.
243         </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>
244 This mode of server operation involves the Samba machine being made a member
245 of a domain security context. This means by definition that all user
246 authentication will be done from a centrally defined authentication regime. 
247 The authentication regime may come from an NT3/4 style (old domain technology)
248 server, or it may be provided from an Active Directory server (ADS) running on
249 MS Windows 2000 or later.
250 </p><p>
251 <span class="emphasis"><em>
252 Of course it should be clear that the authentication back end itself could be
253 from any distributed directory architecture server that is supported by Samba.
254 This can be LDAP (from OpenLDAP), or Sun's iPlanet, of NetWare Directory
255 Server, etc.
256 </em></span>
257 </p><p>
258 Please refer to the <a href="samba-pdc.html" title="Chapter 5. Domain Control">Domain Control chapter</a>
259 for more information regarding how to create a domain
260 machine account for a domain member server as well as for information
261 regarding how to enable the Samba domain member machine to join the domain and
262 to be fully trusted by it.
263 </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>
264         </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>
265 </p><p>
266 First, you must edit your <tt class="filename">smb.conf</tt> file to tell Samba it should
267 now use domain security.
268 </p><p>
269 Change (or add) your <a href="smb.conf.5.html#SECURITY" target="_top">
270 <i class="parameter"><tt>security</tt></i></a> line in the [global] section 
271 of your <tt class="filename">smb.conf</tt> to read:
272 </p><p>
273 </p><pre class="programlisting">
274 security = domain
275 </pre><p>
276 </p><p>
277 Next change the <a href="smb.conf.5.html#WORKGROUP" target="_top"><i class="parameter"><tt>
278 workgroup</tt></i></a> line in the <i class="parameter"><tt>[global]</tt></i>
279 section to read: 
280 </p><p>
281 </p><pre class="programlisting">
282 workgroup = DOM
283 </pre><p>
284 </p><p>
285 as this is the name of the domain we are joining.
286 </p><p>
287 You must also have the parameter <a href="smb.conf.5.html#ENCRYPTPASSWORDS" target="_top">
288 <i class="parameter"><tt>encrypt passwords</tt></i></a> set to <tt class="constant">yes
289 </tt> in order for your users to authenticate to the NT PDC.
290 </p><p>
291 Finally, add (or modify) a <a href="smb.conf.5.html#PASSWORDSERVER" target="_top">
292 <i class="parameter"><tt>password server</tt></i></a> line in the [global]
293 section to read: 
294 </p><p>
295 </p><pre class="programlisting">
296 password server = DOMPDC DOMBDC1 DOMBDC2
297 </pre><p>
298 </p><p>
299 These are the primary and backup domain controllers Samba 
300 will attempt to contact in order to authenticate users. Samba will 
301 try to contact each of these servers in order, so you may want to 
302 rearrange this list in order to spread out the authentication load 
303 among domain controllers.
304 </p><p>
305 Alternatively, if you want smbd to automatically determine 
306 the list of Domain controllers to use for authentication, you may 
307 set this line to be:
308 </p><p>
309 </p><pre class="programlisting">
310 password server = *
311 </pre><p>
312 </p><p>
313 This method allows Samba to use exactly the same mechanism that NT does. This 
314 method either broadcasts or uses a WINS database in order to
315 find domain controllers to authenticate against.
316 </p><p>
317 In order to actually join the domain, you must run this command:
318 </p><p>
319 </p><pre class="screen">
320 <tt class="prompt">root# </tt><b class="userinput"><tt>net join -S DOMPDC -U<i class="replaceable"><tt>Administrator%password</tt></i></tt></b>
321 </pre><p>
322 </p><p>
323 If the <tt class="option">-S DOMPDC</tt> argument is not given then
324 the domain name will be obtained from <tt class="filename">smb.conf</tt>.
325 </p><p>
326 As we are joining the domain DOM and the PDC for that domain 
327 (the only machine that has write access to the domain SAM database) 
328 is DOMPDC, we use it for the <tt class="option">-S</tt> option. 
329 The <i class="replaceable"><tt>Administrator%password</tt></i> is 
330 the login name and password for an account which has the necessary 
331 privilege to add machines to the domain.  If this is successful 
332 you will see the message:
333 </p><p>
334 <tt class="computeroutput">Joined domain DOM.</tt>
335 or <tt class="computeroutput">Joined 'SERV1' to realm 'MYREALM'</tt>
336 </p><p>
337 in your terminal window. See the <a href="net.8.html" target="_top">
338 net(8)</a> man page for more details.
339 </p><p>
340 This process joins the server to the domain without having to create the machine
341 trust account on the PDC beforehand.
342 </p><p>
343 This command goes through the machine account password 
344 change protocol, then writes the new (random) machine account 
345 password for this Samba server into a file in the same directory 
346 in which an smbpasswd file would be stored - normally:
347 </p><p>
348 <tt class="filename">/usr/local/samba/private/secrets.tdb</tt>
349 </p><p>
350 This file is created and owned by root and is not 
351 readable by any other user. It is the key to the domain-level 
352 security for your system, and should be treated as carefully 
353 as a shadow password file.
354 </p><p>
355 Finally, restart your Samba daemons and get ready for 
356 clients to begin using domain security!
357 </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>
358 Currently, domain security in Samba doesn't free you from 
359 having to create local Unix users to represent the users attaching 
360 to your server. This means that if domain user <tt class="constant">DOM\fred
361 </tt> attaches to your domain security Samba server, there needs 
362 to be a local Unix user fred to represent that user in the Unix 
363 filesystem. This is very similar to the older Samba security mode 
364 <a href="smb.conf.5.html#SECURITYEQUALSSERVER" target="_top">security = server</a>, 
365 where Samba would pass through the authentication request to a Windows 
366 NT server in the same way as a Windows 95 or Windows 98 server would.
367 </p><p>
368 Please refer to the <a href="winbind.html" title="Chapter 21. Integrated Logon Support using Winbind">Winbind</a> chapter 
369 for information on a system to automatically
370 assign UNIX uids and gids to Windows NT Domain users and groups.
371 </p><p>
372 The advantage to domain-level security is that the 
373 authentication in domain-level security is passed down the authenticated 
374 RPC channel in exactly the same way that an NT server would do it. This 
375 means Samba servers now participate in domain trust relationships in 
376 exactly the same way NT servers do (i.e., you can add Samba servers into 
377 a resource domain and have the authentication passed on from a resource
378 domain PDC to an account domain PDC).
379 </p><p>
380 In addition, with <i class="parameter"><tt>security = server</tt></i> every Samba 
381 daemon on a server has to keep a connection open to the 
382 authenticating server for as long as that daemon lasts. This can drain 
383 the connection resources on a Microsoft NT server and cause it to run 
384 out of available connections. With <i class="parameter"><tt>security = domain</tt></i>, 
385 however, the Samba daemons connect to the PDC/BDC only for as long 
386 as is necessary to authenticate the user, and then drop the connection, 
387 thus conserving PDC connection resources.
388 </p><p>
389 And finally, acting in the same manner as an NT server 
390 authenticating to a PDC means that as part of the authentication 
391 reply, the Samba server gets the user identification information such 
392 as the user SID, the list of NT groups the user belongs to, etc. 
393 </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
394 Much of the text of this document 
395 was first published in the Web magazine 
396 <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 
397 the NIS/NT Samba</a>.
398 </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>
399 This is a rough guide to setting up Samba 3.0 with Kerberos authentication against a
400 Windows2000 KDC. A familiarity with Kerberos is assumed.
401 </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>
402 You must use at least the following 3 options in <tt class="filename">smb.conf</tt>:
403 </p><pre class="programlisting">
404         realm = your.kerberos.REALM
405         security = ADS
406         encrypt passwords = yes
407 </pre><p>
408 In case samba can't figure out your ads server using your realm name, use the 
409 <i class="parameter"><tt>ads server</tt></i> option in <tt class="filename">smb.conf</tt>:
410 </p><pre class="programlisting">
411         ads server = your.kerberos.server
412 </pre><p>
413 </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
414 You do <span class="emphasis"><em>not</em></span> need a smbpasswd file, and older clients will be authenticated as 
415 if <i class="parameter"><tt>security = domain</tt></i>, although it won't do any harm and 
416 allows you to have local users not in the domain. It is expected that the above 
417 required options will change soon when active directory integration will get 
418 better.
419 </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>
420 The minimal configuration for <tt class="filename">krb5.conf</tt> is:
421 </p><pre class="programlisting">
422         [realms]
423             YOUR.KERBEROS.REALM = {
424                 kdc = your.kerberos.server
425             }
426 </pre><p>
427 Test your config by doing a <b class="userinput"><tt>kinit
428 <i class="replaceable"><tt>USERNAME</tt></i>@<i class="replaceable"><tt>REALM</tt></i></tt></b> and
429 making sure that your password is accepted by the Win2000 KDC.
430 </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
431 The realm must be uppercase or you will get <span class="errorname">Cannot find KDC for
432 requested realm while getting initial credentials</span> error.
433 </p></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
434 Time between the two servers must be synchronized.  You will get a
435 <span class="errorname">kinit(v5): Clock skew too great while getting initial credentials</span>
436 if the time difference is more than five minutes. 
437 </p></div><p>
438 You also must ensure that you can do a reverse DNS lookup on the IP
439 address of your KDC. Also, the name that this reverse lookup maps to
440 must either be the NetBIOS name of the KDC (ie. the hostname with no
441 domain attached) or it can alternatively be the NetBIOS name
442 followed by the realm. 
443 </p><p>
444 The easiest way to ensure you get this right is to add a 
445 <tt class="filename">/etc/hosts</tt> entry mapping the IP address of your KDC to 
446 its NetBIOS name. If you don't get this right then you will get a 
447 <span class="errorname">local error</span> when you try to join the realm.
448 </p><p>
449 If all you want is Kerberos support in <span class="application">smbclient</span> then you can skip
450 straight to <a href="domain-member.html#ads-test-smbclient" title="Testing with smbclient">Test with <span class="application">smbclient</span></a> now. 
451 <a href="domain-member.html#ads-create-machine-account" title="Create the computer account">Creating a computer account</a> 
452 and <a href="domain-member.html#ads-test-server" title="Test your server setup">testing your servers</a>
453 is only needed if you want Kerberos support for <span class="application">smbd</span> and <span class="application">winbindd</span>.
454 </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>
455 As a user that has write permission on the Samba private directory
456 (usually root) run:
457 </p><pre class="programlisting">
458         <tt class="prompt">root# </tt><b class="userinput"><tt>net join -U Administrator%password</tt></b>
459 </pre><p>
460 </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>
461 </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
462         (make clean all install) after the Kerberos libs and headers are installed.
463         </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
464         <i class="replaceable"><tt>USERNAME</tt></i>@<i class="replaceable"><tt>REALM</tt></i></tt></b>.
465         <i class="replaceable"><tt>USERNAME</tt></i> must be a user who has rights to add a machine
466         to the domain.  </p></dd></dl></div><p>
467 </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>
468 If the join was successful, you will see a new computer account with the
469 NetBIOS name of your Samba server in Active Directory (in the &quot;Computers&quot;
470 folder under Users and Computers.
471 </p><p>
472 On a Windows 2000 client try <b class="userinput"><tt>net use * \\server\share</tt></b>. You should
473 be logged in with Kerberos without needing to know a password. If
474 this fails then run <b class="userinput"><tt>klist tickets</tt></b>. Did you get a ticket for the
475 server? Does it have an encoding type of DES-CBC-MD5 ? 
476 </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>
477 On your Samba server try to login to a Win2000 server or your Samba
478 server using <span class="application">smbclient</span> and Kerberos. Use <span class="application">smbclient</span> as usual, but
479 specify the <i class="parameter"><tt>-k</tt></i> option to choose Kerberos authentication.
480 </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>
481 You must change administrator password at least once after DC 
482 install, to create the right encoding types
483 </p><p>
484 W2k doesn't seem to create the _kerberos._udp and _ldap._tcp in
485 their defaults DNS setup. Maybe fixed in service packs?
486 </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>
487 In the process of adding / deleting / re-adding domain member machine accounts there are
488 many traps for the unwary player and there are many &#8220;<span class="quote">little</span>&#8221; things that can go wrong.
489 It is particularly interesting how often subscribers on the samba mailing list have concluded
490 after repeated failed attempts to add a machine account that it is necessary to &quot;re-install&quot;
491 MS Windows on t he machine. In truth, it is seldom necessary to reinstall because of this type
492 of problem. The real solution is often very simple, and with understanding of how MS Windows
493 networking functions. easily overcome.
494 </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>
495 <span class="emphasis"><em>Problem:</em></span> A Windows workstation was reinstalled. The original domain machine
496 account was deleted and added immediately. The workstation will not join the domain if I use 
497 the same machine name. Attempts to add the machine fail with a message that the machine already
498 exists on the network - I know it doesn't. Why is this failing?
499 </p><p>
500 The original name is still in the NetBIOS name cache and must expire after machine account
501 deletion BEFORE adding that same name as a domain member again. The best advice is to delete
502 the old account and then to add the machine with a new name.
503 </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>
504 Adding a Windows 200x or XP Professional machine to the Samba PDC Domain fails with a
505 message that, <span class="errorname">The machine could not be added at this time, there is a network problem.
506 Please try again later.</span> Why?
507 </p><p>
508 You should check that there is an <i class="parameter"><tt>add machine script</tt></i> in your <tt class="filename">smb.conf</tt>
509 file. If there is not, please add one that is appropriate for your OS platform. If a script
510 has been defined you will need to debug it's operation. Increase the <i class="parameter"><tt>log level</tt></i>
511 in the <tt class="filename">smb.conf</tt> file to level 10, then try to rejoin the domain. Check the logs to see which
512 operation is failing.
513 </p><p>
514 Possible causes include:
515 </p><div class="itemizedlist"><ul type="disc"><li><p>
516         The script does not actually exist, or could not be located in the path specified.
517         </p><p>
518         <span class="emphasis"><em>Corrective Action:</em></span> Fix it. Make sure that when run manually
519         that the script will add both the Unix system account _and_ the Samba SAM account.
520         </p></li><li><p>
521         The machine could not be added to the Unix system accounts file <tt class="filename">/etc/passwd</tt>
522         </p><p>
523         <span class="emphasis"><em>Corrective Action:</em></span> Check that the machine name is a legal Unix
524         system account name. ie: If the Unix utility <b class="command">useradd</b> is called
525         then make sure that the machine name you are trying to add can be added using this
526         tool. <b class="command">Useradd</b> on some systems will not allow any upper case characters
527         nor will it allow spaces in the name.
528         </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>