merge from 2.2
[samba.git] / docs / docbook / projdoc / Samba-PDC-HOWTO.sgml
1 <chapter>
2
3
4 <chapterinfo>
5         <author>
6                 <firstname>Gerald (Jerry)</firstname><surname>Carter</surname>
7                 <affiliation>
8                         <orgname>VA Linux Systems/Samba Team</orgname>
9                         <address><email>jerry@samba.org</email></address>
10                 </affiliation>
11                 <firstname>David</firstname><surname>Bannon</surname>
12                 <affiliation>
13                         <orgname>Samba Team</orgname>
14                         <address><email>dbannon@samba.org</email></address>
15                 </affiliation>
16                 
17         </author>
18         <pubdate> (26 Apr 2001) </pubdate>
19 </chapterinfo>
20
21 <title>
22 How to Configure Samba 2.2 as a Primary Domain Controller
23 </title>
24
25
26 <!-- **********************************************************
27
28      Prerequisite Reading
29
30 *************************************************************** -->
31 <sect1>
32 <title>Prerequisite Reading</title>
33
34 <para>
35 Before you continue readingin this chapter, please make sure 
36 that you are comfortable with configuring basic files services
37 in smb.conf and how to enable and administrate password 
38 encryption in Samba.  Theses two topics are covered in the
39 <ulink url="smb.conf.5.html"><filename>smb.conf(5)</filename></ulink> 
40 manpage and the <ulink url="EMCRYPTION.html">Encryption chapter</ulink> 
41 of this HOWTO Collection.
42 </para>
43
44
45 </sect1>
46
47
48
49 <!-- **********************************************************
50
51      Background Information
52
53 *************************************************************** -->
54 <sect1>
55 <title>
56 Background
57 </title>
58
59 <note>
60 <para>
61 <emphasis>Author's Note :</emphasis> This document is a combination 
62 of David Bannon's Samba 2.2 PDC HOWTO and the Samba NT Domain FAQ. 
63 Both documents are superceeded by this one.
64 </para>
65 </note>
66
67 <para>
68 Version of Samba prior to release 2.2 had marginal capabilities to
69 act as a Windows NT 4.0 Primary Domain Controller (PDC).  Beginning with 
70 Samba 2.2.0, we are proud to announce official support for Windows NT 4.0 
71 style domain logons from Windows NT 4.0 (through SP6) and Windows 2000 (through 
72 SP1) clients.  This article outlines the steps necessary for configuring Samba 
73 as a PDC.  It is necessary to have a working Samba server prior to implementing the 
74 PDC functionality.  If you have not followed the steps outlined in 
75 <ulink url="UNIX_INSTALL.html"> UNIX_INSTALL.html</ulink>, please make sure 
76 that your server is configured correctly before proceeding.  Another good 
77 resource in the <ulink url="smb.conf.5.html">smb.conf(5) man 
78 page</ulink>. The following  functionality should work in 2.2:
79 </para>
80
81 <itemizedlist>
82         <listitem><para>
83         domain logons for Windows NT 4.0/2000 clients.
84         </para></listitem>
85         
86         <listitem><para>
87         placing a Windows 9x client in user level security
88         </para></listitem>
89         
90         <listitem><para>
91         retrieving a list of users and groups from a Samba PDC to
92         Windows 9x/NT/2000 clients
93         </para></listitem>
94         
95         <listitem><para>
96         roving (roaming) user profiles
97         </para></listitem>
98         
99         <listitem><para>
100         Windows NT 4.0 style system policies
101         </para></listitem>
102 </itemizedlist>
103
104 <warning>
105         <title>Windows 2000 Service Pack 2 Clients</title>
106         <para>
107         Samba 2.2.1 is required for PDC functionality when using Windows 2000 
108         SP2 clients. 
109         </para>
110 </warning>
111
112
113 <para>
114 The following pieces of functionality are not included in the 2.2 release:
115 </para>
116
117 <itemizedlist>
118         <listitem><para>
119         Windows NT 4 domain trusts
120         </para></listitem>
121         
122         <listitem><para>
123         SAM replication with Windows NT 4.0 Domain Controllers
124         (i.e. a Samba PDC and a Windows NT BDC or vice versa) 
125         </para></listitem>
126         
127         <listitem><para>
128         Adding users via the User Manager for Domains
129         </para></listitem>
130
131         <listitem><para>
132         Acting as a Windows 2000 Domain Controller (i.e. Kerberos and 
133         Active Directory)
134         </para></listitem>
135 </itemizedlist>
136
137 <para>
138 Please note that Windows 9x clients are not true members of a domain
139 for reasons outlined in this article.  Therefore the protocol for
140 support Windows 9x style domain logons is completely different
141 from NT4 domain logons and has been officially supported for some 
142 time.
143 </para>
144
145
146 <para>
147 Implementing a Samba PDC can basically be divided into 2 broad
148 steps.
149 </para>
150
151 <orderedlist numeration="Arabic">
152         <listitem><para>
153         Configuring the Samba PDC
154         </para></listitem>
155         
156         <listitem><para>
157         Creating machine trust accounts and joining clients 
158         to the domain
159         </para></listitem>
160 </orderedlist>
161
162 <para>
163 There are other minor details such as user profiles, system
164 policies, etc...  However, these are not necessarily specific
165 to a Samba PDC as much as they are related to Windows NT networking
166 concepts.  They will be mentioned only briefly here.
167 </para>
168
169 </sect1>
170
171
172 <!-- **********************************************************
173
174      Configuring the Samba PDC
175
176 *************************************************************** -->
177
178 <sect1>
179 <title>Configuring the Samba Domain Controller</title>
180
181 <para>
182 The first step in creating a working Samba PDC is to 
183 understand the parameters necessary in smb.conf.  I will not
184 attempt to re-explain the parameters here as they are more that
185 adequately covered in <ulink url="smb.conf.5.html"> the smb.conf
186 man page</ulink>.  For convenience, the parameters have been
187 linked with the actual smb.conf description.
188 </para>
189
190 <para>
191 Here is an example smb.conf for acting as a PDC:
192 </para>
193
194 <para><programlisting>
195 [global]
196     ; Basic server settings
197     <ulink url="smb.conf.5.html#NETBIOSNAME">netbios name</ulink> = <replaceable>POGO</replaceable>
198     <ulink url="smb.conf.5.html#WORKGROUP">workgroup</ulink> = <replaceable>NARNIA</replaceable>
199
200     ; we should act as the domain and local master browser
201     <ulink url="smb.conf.5.html#OSLEVEL">os level</ulink> = 64
202     <ulink url="smb.conf.5.html#PERFERREDMASTER">preferred master</ulink> = yes
203     <ulink url="smb.conf.5.html#DOMAINMASTER">domain master</ulink> = yes
204     <ulink url="smb.conf.5.html#LOCALMASTER">local master</ulink> = yes
205     
206     ; security settings (must user security = user)
207     <ulink url="smb.conf.5.html#SECURITYEQUALSUSER">security</ulink> = user
208     
209     ; encrypted passwords are a requirement for a PDC
210     <ulink url="smb.conf.5.html#ENCRYPTPASSWORDS">encrypt passwords</ulink> = yes
211     
212     ; support domain logons
213     <ulink url="smb.conf.5.html#DOMAINLOGONS">domain logons</ulink> = yes
214     
215     ; where to store user profiles?
216     <ulink url="smb.conf.5.html#LOGONPATH">logon path</ulink> = \\%N\profiles\%u
217     
218     ; where is a user's home directory and where should it
219     ; be mounted at?
220     <ulink url="smb.conf.5.html#LOGONDRIVE">logon drive</ulink> = H:
221     <ulink url="smb.conf.5.html#LOGONHOME">logon home</ulink> = \\homeserver\%u
222     
223     ; specify a generic logon script for all users
224     ; this is a relative **DOS** path to the [netlogon] share
225     <ulink url="smb.conf.5.html#LOGONSCRIPT">logon script</ulink> = logon.cmd
226
227 ; necessary share for domain controller
228 [netlogon]
229     <ulink url="smb.conf.5.html#PATH">path</ulink> = /usr/local/samba/lib/netlogon
230     <ulink url="smb.conf.5.html#WRITEABLE">writeable</ulink> = no
231     <ulink url="smb.conf.5.html#WRITELIST">write list</ulink> = <replaceable>ntadmin</replaceable>
232     
233 ; share for storing user profiles
234 [profiles]
235     <ulink url="smb.conf.5.html#PATH">path</ulink> = /export/smb/ntprofile
236     <ulink url="smb.conf.5.html#WRITEABLE">writeable</ulink> = yes
237     <ulink url="smb.conf.5.html#CREATEMASK">create mask</ulink> = 0600
238     <ulink url="smb.conf.5.html#DIRECTORYMASK">directory mask</ulink> = 0700
239 </programlisting></para>
240
241 <para>
242 There are a couple of points to emphasize in the above configuration.
243 </para>
244
245 <itemizedlist>
246         <listitem><para>
247         Encrypted passwords must be enabled.  For more details on how 
248         to do this, refer to <ulink url="ENCRYPTION.html">ENCRYPTION.html</ulink>.
249         </para></listitem>
250         
251         <listitem><para>
252         The server must support domain logons and a
253         <filename>[netlogon]</filename> share
254         </para></listitem>
255         
256         <listitem><para>
257         The server must be the domain master browser in order for Windows 
258         client to locate the server as a DC.  Please refer to the various 
259         Network Browsing documentation included with this distribution for 
260         details.
261         </para></listitem>
262 </itemizedlist>    
263
264 <para>
265 As Samba 2.2 does not offer a complete implementation of group mapping between 
266 Windows NT groups and UNIX groups (this is really quite complicated to explain 
267 in a short space), you should refer to the <ulink url="smb.conf.5.html#DOMAINADMINUSERS">domain 
268 admin users</ulink> and <ulink url="smb.conf.5.html#DOMAINADMINGROUP">domain 
269 admin group</ulink> smb.conf parameters for information of creating a Domain Admins 
270 style accounts.
271 </para>
272
273 </sect1>
274
275
276 <sect1>
277 <title>Creating Machine Trust Accounts and Joining Clients 
278 to the Domain</title>
279
280 <para>
281 A machine trust account is a samba user account owned by a computer.  
282 The account password acts as the shared secret for secure 
283 communication with the Domain Controller.  This is a security feature
284 to prevent an unauthorized machine with the same netbios name from 
285 joining the domain and gaining access to domain user/group accounts.  
286 Hence a Windows 9x host is never a true member of a domain because it does 
287 not posses a machine trust account, and thus has no shared secret with the DC.
288 </para>
289
290 <para>
291 On a Windows NT PDC, these machine trust account passwords are stored
292 in the registry.  A Samba PDC stores these accounts in the same location
293 as user LanMan and NT password hashes (currently <filename>smbpasswd</filename>).
294 However, machine trust accounts only possess and use the NT password hash.
295 </para>
296
297 <para>
298 Because Samba requires machine accounts to possess a UNIX uid from
299 which an Windows NT SID can be generated, all of these accounts
300 must have an entry in <filename>/etc/passwd</filename> and smbpasswd.  
301 Future releases will alleviate the need to create 
302 <filename>/etc/passwd</filename> entries.  
303 </para>
304
305 <para>
306 There are two means of creating machine trust accounts.
307 </para>
308
309 <itemizedlist>
310         <listitem><para>
311         Manual creation before joining the client to the domain.  In this case, 
312         the password is set to a known value -- the lower case of the 
313         machine's netbios name.
314         </para></listitem>
315         
316         <listitem><para>
317         Creation of the account at the time of joining the domain.  In 
318         this case, the session key of the administrative account used to join 
319         the client to the domain acts as an encryption key for setting the 
320         password to a random value (This is the recommended method).
321         </para></listitem>
322 </itemizedlist>
323
324 <sect2>
325 <title>Manually creating machine trust accounts</title>
326
327 <para>
328 The first step in creating a machine trust account by hand is to 
329 create an entry for the machine in /etc/passwd.  This can be done 
330 using <command>vipw</command> or any 'add userr' command which is normally 
331 used to create new UNIX accounts.  The following is an example for a Linux 
332 based Samba server:
333 </para>
334
335 <para>
336 <prompt>root# </prompt>/usr/sbin/useradd -g 100 -d /dev/null -c <replaceable>
337 machine_nickname</replaceable> -m -s /bin/false <replaceable>machine_name</replaceable>$
338 </para>
339
340 <para>
341 The <filename>/etc/passwd</filename> entry will list the machine name 
342 with a $ appended, won't have a passwd, will have a null shell and no 
343 home directory. For example a machine called 'doppy' would have an 
344 <filename>/etc/passwd</filename> entry like this :
345 </para>
346
347 <para><programlisting>
348 doppy$:x:505:501:<replaceable>machine_nickname</replaceable>:/dev/null:/bin/false
349 </programlisting></para>
350
351 <para>
352 Above, <replaceable>machine_nickname</replaceable> can be any descriptive name for the
353 pc i.e. BasementComputer. The <replaceable>machine_name</replaceable> absolutely must be 
354 the netbios name of the pc to be added to the domain.  The "$" must append the netbios
355 name of the pc or samba will not recognize this as a machine account
356 </para>
357
358
359 <para>
360 Now that the UNIX account has been created, the next step is to create 
361 the smbpasswd entry for the machine containing the well known initial 
362 trust account password.  This can be done using the <ulink 
363 url="smbpasswd.6.html"><command>smbpasswd(8)</command></ulink> command 
364 as shown here:
365 </para>
366
367 <para>
368 <prompt>root# </prompt> smbpasswd -a -m <replaceable>machine_name</replaceable>
369 </para>
370
371 <para>
372 where <replaceable>machine_name</replaceable> is the machine's netbios
373 name. 
374 </para>
375
376 <warning>
377         <title>Join the client to the domain immediately</title>
378
379         <para>
380         Manually creating a machine trust account using this method is the 
381         equivalent of creating a machine account on a Windows NT PDC using 
382         the "Server Manager".  From the time at which the account is created
383         to the time which th client joins the domain and changes the password,
384         your domain is vulnerable to an intruder joining your domain using a
385         a machine with the same netbios name.  A PDC inherently trusts
386         members of the domain and will serve out a large degree of user 
387         information to such clients.  You have been warned!
388         </para>
389 </warning>
390 </sect2>
391
392
393 <sect2>
394 <title>Creating machine trust accounts "on the fly"</title>
395
396 <para>
397 The second, and most recommended way of creating machine trust accounts 
398 is to create them as needed at the time the client is joined to 
399 the domain.  You will need to include a value for the <ulink 
400 url="smb.conf.5.html#ADDUSERSCRIPT">add user script</ulink>
401 parameter.  Below is an example from a RedHat 6.2 Linux system.
402 </para>
403
404 <para><programlisting>
405 add user script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u 
406 </programlisting></para>
407
408 <para>
409 In Samba 2.2.1, <emphasis>only the root account</emphasis> can be used to create
410 machine accounts like this.  Therefore, it is required to create 
411 an entry in smbpasswd for <emphasis>root</emphasis>.  The password 
412 <emphasis>SHOULD</emphasis> be set to s different password that the 
413 associated <filename>/etc/passwd</filename> entry for security reasons.
414 </para>
415 </sect2>
416 </sect1>
417
418 <!-- **********************************************************
419
420      Common Problems
421
422 *************************************************************** -->
423
424 <sect1>
425 <title>Common Problems and Errors</title>
426
427 <para>
428 </para>
429 <itemizedlist>
430 <listitem>
431         <para>
432         <emphasis>I cannot include a '$' in a machine name.</emphasis>
433         </para>
434     
435         <para>
436         A 'machine name' in (typically) <filename>/etc/passwd</>        
437         of the machine name with a '$' appended. FreeBSD (and other BSD 
438         systems ?) won't create a user with a '$' in their name.
439         </para>
440
441         <para>
442         The problem is only in the program used to make the entry, once 
443         made, it works perfectly. So create a user without the '$' and 
444         use <command>vipw</> to edit the entry, adding the '$'. Or create 
445         the whole entry with vipw if you like, make sure you use a 
446         unique uid !
447         </para>
448 </listitem>
449   
450 <listitem>
451         <para>
452         <emphasis>I get told "You already have a connection to the Domain...." 
453         or "Cannot join domain, the credentials supplied conflict with an 
454         existing set.." when creating a machine account.</emphasis>
455         </para>
456
457         <para>
458         This happens if you try to create a machine account from the 
459         machine itself and already have a connection (e.g. mapped drive) 
460         to a share (or IPC$) on the Samba PDC.  The following command
461         will remove all network drive connections:
462         </para>
463
464         <para>
465         <prompt>C:\WINNT\></prompt> <command>net use * /d</command>
466         </para>
467
468         <para>
469         Further, if the machine is a already a 'member of a workgroup' that 
470         is the same name as the domain you are joining (bad idea) you will 
471         get this message.  Change the workgroup name to something else, it 
472         does not matter what, reboot, and try again.
473         </para>
474 </listitem>
475
476 <listitem>
477         <para>
478         <emphasis>The system can not log you on (C000019B)....</emphasis>
479         </para>
480
481         <para>I joined the domain successfully but after upgrading 
482         to a newer version of the Samba code I get the message, "The system 
483         can not log you on (C000019B), Please try a gain or consult your 
484         system administrator" when attempting to logon.
485         </para>
486
487         <para>
488         This occurs when the domain SID stored in 
489         <filename>private/WORKGROUP.SID</filename> is 
490         changed.  For example, you remove the file and <command>smbd</command> automatically 
491         creates a new one.  Or you are swapping back and forth between 
492         versions 2.0.7, TNG and the HEAD branch code (not recommended).  The 
493         only way to correct the problem is to restore the original domain 
494         SID or remove the domain client from the domain and rejoin.
495         </para>
496 </listitem>
497
498 <listitem>
499         <para>
500         <emphasis>The machine account for this computer either does not 
501         exist or is not accessible.</emphasis>
502         </para>
503
504         <para>
505         When I try to join the domain I get the message "The machine account 
506         for this computer either does not exist or is not accessible". Whats 
507         wrong?
508         </para>
509
510         <para>
511         This problem is caused by the PDC not having a suitable machine account. 
512         If you are using the <parameter>add user script</parameter> method to create 
513         accounts then this would indicate that it has not worked. Ensure the domain 
514         admin user system is working.
515         </para>
516
517         <para>
518         Alternatively if you are creating account entries manually then they 
519         have not been created correctly. Make sure that you have the entry 
520         correct for the machine account in smbpasswd file on the Samba PDC. 
521         If you added the account using an editor rather than using the smbpasswd 
522         utility, make sure that the account name is the machine netbios name 
523         with a '$' appended to it ( ie. computer_name$ ). There must be an entry 
524         in both /etc/passwd and the smbpasswd file. Some people have reported 
525         that inconsistent subnet masks between the Samba server and the NT 
526         client have caused this problem.   Make sure that these are consistent 
527         for both client and server.
528         </para>
529 </listitem>
530
531 <listitem>
532         <para>
533         <emphasis>When I attempt to login to a Samba Domain from a NT4/W2K workstation,
534         I get a message about my account being disabled.</emphasis>
535         </para>
536
537         <para>
538         This problem is caused by a PAM related bug in Samba 2.2.0.  This bug is 
539         fixed in 2.2.1.  Other symptoms could be unaccessible shares on 
540         NT/W2K member servers in the domain or the following error in your smbd.log:
541         passdb/pampass.c:pam_account(268) PAM: UNKNOWN ERROR for User: %user%
542         </para>
543  
544         <para>
545         At first be ensure to enable the useraccounts with <command>smbpasswd -e 
546         %user%</command>, this is normaly done, when you create an account.
547         </para>
548
549         <para>
550         In order to work around this problem in 2.2.0, configure the 
551         <parameter>account</parameter> control flag in 
552         <filename>/etc/pam.d/samba</filename> file as follows:
553         </para> 
554
555         <para><programlisting>
556         account required        pam_permit.so
557         </programlisting></para>
558
559         <para>
560         If you want to remain backward compatibility to samba 2.0.x use
561         <filename>pam_permit.so</filename>, it's also possible to use 
562         <filename>pam_pwdb.so</filename>. There are some bugs if you try to 
563         use <filename>pam_unix.so</filename>, if you need this, be ensure to use
564         the most recent version of this file.
565         </para>
566 </listitem>
567 </itemizedlist>
568
569 </sect1>
570
571
572
573 <!-- **********************************************************
574
575      Policies and Profiles
576
577 *************************************************************** -->
578
579 <sect1>
580 <title>
581 System Policies and Profiles
582 </title>
583
584 <para>
585 Much of the information necessary to implement System Policies and
586 Roving User Profiles in a Samba domain is the same as that for 
587 implementing these same items in a Windows NT 4.0 domain. 
588 You should read the white paper <ulink url="http://www.microsoft.com/ntserver/management/deployment/planguide/prof_policies.asp">Implementing
589 Profiles and Policies in Windows NT 4.0</ulink> available from Microsoft.
590 </para>
591
592 <para>
593 Here are some additional details:
594 </para>
595
596 <itemizedlist>
597
598 <listitem>
599         <para>
600         <emphasis>What about Windows NT Policy Editor ?</emphasis>
601         </para>
602
603         <para>
604         To create or edit <filename>ntconfig.pol</filename> you must use 
605         the NT Server Policy Editor, <command>poledit.exe</command>     which 
606         is included with NT Server but <emphasis>not NT Workstation</emphasis>. 
607         There is a Policy Editor on a NTws 
608         but it is not suitable for creating <emphasis>Domain Policies</emphasis>. 
609         Further, although the Windows 95 
610         Policy Editor can be installed on an NT Workstation/Server, it will not
611         work with NT policies because the registry key that are set by the policy templates. 
612         However, the files from the NT Server will run happily enough on an NTws.       
613         You need <filename>poledit.exe, common.adm</> and <filename>winnt.adm</>. It is convenient
614         to put the two *.adm files in <filename>c:\winnt\inf</> which is where
615         the binary will look for them unless told otherwise. Note also that that 
616         directory is 'hidden'.
617         </para>
618
619         <para>
620         The Windows NT policy editor is also included with the Service Pack 3 (and 
621         later) for Windows NT 4.0. Extract the files using <command>servicepackname /x</command>, 
622         ie thats <command>Nt4sp6ai.exe /x</command> for service pack 6a.  The policy editor, 
623         <command>poledit.exe</command> and the associated template files (*.adm) should
624         be extracted as well.  It is also possible to downloaded the policy template 
625         files for Office97 and get a copy of the policy editor.  Another possible 
626         location is with the Zero Administration Kit available for download from Microsoft.
627         </para>
628 </listitem>
629
630
631 <listitem>
632         <para>
633         <emphasis>Can Win95 do Policies ?</emphasis>
634         </para>
635
636         <para>
637         Install the group policy handler for Win9x to pick up group 
638         policies.   Look on the Win98 CD in <filename>\tools\reskit\netadmin\poledit</filename>. 
639         Install group policies on a Win9x client by double-clicking 
640         <filename>grouppol.inf</filename>. Log off and on again a couple of 
641         times and see if Win98 picks up group policies.  Unfortunately this needs 
642         to be done on every Win9x machine that uses group policies....
643         </para> 
644
645         <para>
646         If group policies don't work one reports suggests getting the updated 
647         (read: working) grouppol.dll for Windows 9x. The group list is grabbed 
648         from /etc/group.
649         </para>
650 </listitem>
651
652
653 <listitem>
654         <para>
655         <emphasis>How do I get 'User Manager' and 'Server Manager'</emphasis>
656         </para>
657
658         <para>
659         Since I don't need to buy an NT Server CD now, how do I get 
660         the 'User Manager for Domains', the 'Server Manager' ?
661         </para>
662
663         <para>
664         Microsoft distributes a version of these tools called nexus for 
665         installation on Windows 95 systems.  The tools set includes
666         </para>
667         
668         <itemizedlist>
669                 <listitem><para>Server Manager</para></listitem> 
670                 
671                 <listitem><para>User Manager for Domains</para></listitem> 
672
673                 <listitem><para>Event Viewer</para></listitem> 
674         </itemizedlist>
675
676         <para>
677         Click here to download the archived file <ulink 
678         url="ftp://ftp.microsoft.com/Softlib/MSLFILES/NEXUS.EXE">ftp://ftp.microsoft.com/Softlib/MSLFILES/NEXUS.EXE</ulink>
679         </para>
680
681         <para>
682         The Windows NT 4.0 version of the 'User Manager for 
683         Domains' and 'Server Manager' are available from Microsoft via ftp 
684         from <ulink url="ftp://ftp.microsoft.com/Softlib/MSLFILES/SRVTOOLS.EXE">ftp://ftp.microsoft.com/Softlib/MSLFILES/SRVTOOLS.EXE</ulink>
685         </para>
686 </listitem>
687 </itemizedlist>
688
689 </sect1>
690
691
692
693 <!-- **********************************************************
694
695      Getting Help
696
697 *************************************************************** -->
698
699
700 <sect1>
701 <title>What other help can I get ? </title>
702
703 <para>
704 There are many sources of information available in the form 
705 of mailing lists, RFC's and documentation.  The docs that come 
706 with the samba distribution contain very good explanations of 
707 general SMB topics such as browsing.</para> 
708
709 <itemizedlist>
710 <listitem>
711         <para>
712         <emphasis>What are some diagnostics tools I can use to debug the domain logon 
713         process and where can I find them?</emphasis>
714         </para>
715
716    <para>
717         One of the best diagnostic tools for debugging problems is Samba itself.  
718         You can use the -d option for both smbd and nmbd to specifiy what 
719         'debug level' at which to run.  See the man pages on smbd, nmbd  and 
720         smb.conf for more information on debugging options.  The debug 
721         level can range from 1 (the default) to 10 (100 for debugging passwords).
722         </para>
723         
724         <para>
725         Another helpful method of debugging is to compile samba using the 
726         <command>gcc -g </command> flag.   This will include debug 
727         information in the binaries and allow you to attach gdb to the 
728         running smbd / nmbd process.  In order to attach gdb to an smbd 
729         process for an NT workstation, first get the workstation to make the 
730         connection. Pressing ctrl-alt-delete and going down to the domain box 
731         is sufficient (at least, on the first time you join the domain) to 
732         generate a 'LsaEnumTrustedDomains'. Thereafter, the workstation 
733         maintains an open connection, and therefore there will be an smbd 
734         process running (assuming that you haven't set a really short smbd 
735         idle timeout)  So, in between pressing ctrl alt delete, and actually 
736         typing in your password, you can gdb attach and continue.
737         </para>
738
739         <para>
740         Some useful samba commands worth investigating:
741         </para>
742         
743         <itemizedlist>
744                 <listitem><para>testparam | more</para></listitem>
745                 <listitem><para>smbclient -L //{netbios name of server}</para></listitem>
746         </itemizedlist>
747     
748         <para>
749         An SMB enabled version of tcpdump is available from 
750         <ulink url="http://www.tcpdump.org/">http://www.tcpdup.org/</ulink>.
751         Ethereal, another good packet sniffer for UNIX and Win32
752         hosts, can be downloaded from <ulink 
753         url="http://www.ethereal.com/">http://www.ethereal.com</ulink>.
754         </para>
755         
756         <para>
757         For tracing things on the Microsoft Windows NT, Network Monitor 
758         (aka. netmon) is available on the Microsoft Developer Network CD's, 
759         the Windows NT Server install CD and the SMS CD's.  The version of 
760         netmon that ships with SMS allows for dumping packets between any two 
761         computers (ie. placing the network interface in promiscuous mode).  
762         The version on the NT Server install CD will only allow monitoring 
763         of network traffic directed to the local NT box and broadcasts on the 
764         local subnet.  Be aware that Ethereal can read and write netmon 
765         formatted files.
766         </para>
767 </listitem>
768
769
770 <listitem>
771         <para>
772         <emphasis>How do I install 'Network Monitor' on an NT Workstation 
773         or a Windows 9x box?</emphasis>
774         </para>
775
776         <para>
777         Installing netmon on an NT workstation requires a couple 
778         of steps.  The following are for installing Netmon V4.00.349, which comes 
779         with Microsoft Windows NT Server 4.0, on Microsoft Windows NT 
780         Workstation 4.0.  The process should be similar for other version of 
781         Windows NT / Netmon.  You will need both the Microsoft Windows 
782         NT Server 4.0 Install CD and the Workstation 4.0 Install CD.
783         </para> 
784
785         <para>
786         Initially you will need to install 'Network Monitor Tools and Agent' 
787         on the NT Server.  To do this 
788         </para>
789
790         <itemizedlist>
791                 <listitem><para>Goto Start - Settings - Control Panel - 
792                 Network - Services - Add </para></listitem>
793                 
794                 <listitem><para>Select the 'Network Monitor Tools and Agent' and 
795                 click on 'OK'.</para></listitem> 
796                 
797                 <listitem><para>Click 'OK' on the Network Control Panel.
798                 </para></listitem> 
799                 
800                 <listitem><para>Insert the Windows NT Server 4.0 install CD 
801                 when prompted.</para></listitem> 
802         </itemizedlist>
803
804         <para>
805         At this point the Netmon files should exist in 
806         <filename>%SYSTEMROOT%\System32\netmon\*.*</filename>.    
807         Two subdirectories exist as well, <filename>parsers\</filename> 
808         which contains the necessary DLL's for parsing the netmon packet 
809         dump, and <filename>captures\</filename>.
810         </para>
811
812         <para>
813         In order to install the Netmon tools on an NT Workstation, you will 
814         first need to install the 'Network  Monitor Agent' from the Workstation 
815         install CD.
816         </para>
817
818         <itemizedlist>
819                 <listitem><para>Goto Start - Settings - Control Panel - 
820                 Network - Services - Add</para></listitem> 
821
822                 <listitem><para>Select the 'Network Monitor Agent' and click 
823                 on 'OK'.</para></listitem> 
824                 
825                 <listitem><para>Click 'OK' on the Network Control Panel.
826                 </para></listitem> 
827                 
828                 <listitem><para>Insert the Windows NT Workstation 4.0 install 
829                 CD when prompted.</para></listitem> 
830         </itemizedlist>
831
832
833         <para>
834         Now copy the files from the NT Server in %SYSTEMROOT%\System32\netmon\*.* 
835         to %SYSTEMROOT%\System32\netmon\*.* on the Workstation and set 
836         permissions as  you deem appropriate for your site. You will need 
837         administrative rights on the NT box to run netmon.
838         </para>
839
840         <para>
841         To install Netmon on a Windows 9x box install the network monitor agent 
842         from the Windows 9x CD (\admin\nettools\netmon).  There is a readme 
843         file located with the netmon driver files on the CD if you need 
844         information on how to do this.  Copy the files from a working 
845         Netmon installation.
846         </para> 
847 </listitem>
848
849
850
851
852 <listitem>
853         <para>
854         The following is a list if helpful URLs and other links:
855         </para>
856
857         <itemizedlist>
858
859         <listitem><para>Home of Samba site <ulink url="http://samba.org">
860         http://samba.org</ulink>. We have a mirror near you !</para></listitem>
861
862         <listitem><para> The <emphasis>Development</emphasis> document 
863         on the Samba mirrors might mention your problem. If so,
864         it might mean that the developers are working on it.</para></listitem>
865  
866         <listitem><para>See how Scott Merrill simulates a BDC behavior at 
867         <ulink url="http://www.skippy.net/linux/smb-howto.html">
868         http://www.skippy.net/linux/smb-howto.html</>. </para></listitem>
869
870         <listitem><para>Although 2.0.7 has almost had its day as a PDC, David Bannon will
871         keep the 2.0.7 PDC pages at <ulink url="http://bioserve.latrobe.edu.au/samba">
872         http://bioserve.latrobe.edu.au/samba</ulink> going for a while yet.</para></listitem>
873
874         <listitem><para>Misc links to CIFS information 
875         <ulink url="http://samba.org/cifs/">http://samba.org/cifs/</ulink></para></listitem>
876
877         <listitem><para>NT Domains for Unix <ulink url="http://mailhost.cb1.com/~lkcl/ntdom/">
878         http://mailhost.cb1.com/~lkcl/ntdom/</ulink></para></listitem>
879
880         <listitem><para>FTP site for older SMB specs: 
881         <ulink url="ftp://ftp.microsoft.com/developr/drg/CIFS/">
882         ftp://ftp.microsoft.com/developr/drg/CIFS/</ulink></para></listitem>
883
884         </itemizedlist>
885 </listitem>
886 </itemizedlist>
887
888
889 <itemizedlist>
890 <listitem>
891         <para>
892         <emphasis>How do I get help from the mailing lists ?</emphasis>
893         </para>
894
895         <para>
896         There are a number of Samba related mailing lists. Go to <ulink 
897         url="http://samba.org">http://samba.org</ulink>, click on your nearest mirror
898         and then click on <command>Support</> and then click on <command>
899         Samba related mailing lists</>.
900         </para>
901
902         <para>
903         For questions relating to Samba TNG go to
904         <ulink url="http://www.samba-tng.org/">http://www.samba-tng.org/</ulink> 
905         It has been requested that you don't post questions about Samba-TNG to the
906         main stream Samba lists.</para>
907          
908         <para>
909         If you post a message to one of the lists please observe the following guide lines :
910         </para>
911
912         <itemizedlist>
913
914         <listitem><para> Always remember that the developers are volunteers, they are 
915                 not paid and they never guarantee to produce a particular feature at 
916                 a particular time. Any time lines are 'best guess' and nothing more.
917                 </para></listitem>
918
919         <listitem><para> Always mention what version of samba you are using and what 
920                 operating system its running under. You should probably list the
921         relevant sections of your smb.conf file, at least the options 
922         in [global] that affect PDC support.</para></listitem>
923
924     <listitem><para>In addition to the version, if you obtained Samba via
925         CVS mention the date when you last checked it out.</para></listitem>
926
927         <listitem><para> Try and make your question clear and brief, lots of long, 
928                 convoluted questions get deleted before they are completely read ! 
929                 Don't post html encoded messages (if you can select colour or font 
930                 size its html).</para></listitem>
931
932         <listitem><para> If you run one of those nifty 'I'm on holidays' things when 
933                 you are away, make sure its configured  to not answer mailing lists.
934                 </para></listitem> 
935
936         <listitem><para> Don't cross post. Work out which is the best list to post to 
937                 and see what happens, ie don't post to both samba-ntdom and samba-technical.
938         Many people active on the lists subscribe to more 
939                 than one list and get annoyed to see the same message two or more times. 
940                 Often someone will see a message and thinking it would be better dealt 
941                 with on another, will forward it on for you.</para></listitem>
942
943     <listitem><para>You might include <emphasis>partial</emphasis>
944         log files written at a debug level set to as much as 20.  
945         Please don't send the entire log but enough to give the context of the 
946         error messages.</para></listitem>
947
948     <listitem><para>(Possibly) If you have a complete netmon trace ( from the opening of 
949         the pipe to the error ) you can send the *.CAP file as well.</para></listitem> 
950
951     <listitem><para>Please think carefully before attaching a document to an email.
952         Consider pasting the relevant parts into the body of the message. The samba
953         mailing lists go to a huge number of people, do they all need a copy of your 
954         smb.conf in their attach directory ?</para></listitem>
955
956         </itemizedlist>
957 </listitem>
958
959
960 <listitem>
961         <para>
962         <emphasis>How do I get off the mailing lists ?</emphasis>
963         </para>
964
965         <para>To have your name removed from a samba mailing list, go to the
966         same place you went to to get on it. Go to <ulink 
967         url="http://lists.samba.org/">http://lists.samba.org</ulink>, 
968         click on your nearest mirror and then click on <command>Support</> and 
969         then click on <command> Samba related mailing lists</>. Or perhaps see 
970         <ulink url="http://lists.samba.org/mailman/roster/samba-ntdom">here</ulink>
971         </para>
972
973         <para>
974         Please don't post messages to the list asking to be removed, you will just
975         be referred to the above address (unless that process failed in some way...)
976         </para>
977 </listitem>
978 </itemizedlist>
979
980 </sect1>
981
982
983 <!-- **********************************************************
984
985      Windows 9x domain control
986
987 *************************************************************** -->
988 <sect1>
989 <title>Domain Control for Windows 9x/ME</title>
990
991 <note>
992 <para>
993 The following section contains much of the original 
994 DOMAIN.txt file previously included with Samba.  Much of 
995 the material is based on what went into the book Special 
996 Edition, Using Samba. (Richard Sharpe)
997 </para>
998 </note>
999
1000 <para>
1001 A domain and a workgroup are exactly the same thing in terms of network
1002 browsing.  The difference is that a distributable authentication
1003 database is associated with a domain, for secure login access to a
1004 network.  Also, different access rights can be granted to users if they
1005 successfully authenticate against a domain logon server (NT server and 
1006 other systems based on NT server support this, as does at least Samba TNG now).
1007 </para>
1008
1009 <para>
1010 The SMB client logging on to a domain has an expectation that every other
1011 server in the domain should accept the same authentication information.
1012 Network browsing functionality of domains and workgroups is
1013 identical and is explained in BROWSING.txt. It should be noted, that browsing
1014 is total orthogonal to logon support.
1015 </para>
1016
1017 <para>
1018 Issues related to the single-logon network model are discussed in this
1019 document.  Samba supports domain logons, network logon scripts, and user
1020 profiles for MS Windows for workgroups and MS Windows 9X clients.
1021 </para>
1022
1023
1024 <para>
1025 When an SMB client in a domain wishes to logon it broadcast requests for a
1026 logon server.  The first one to reply gets the job, and validates its
1027 password using whatever mechanism the Samba administrator has installed.
1028 It is possible (but very stupid) to create a domain where the user
1029 database is not shared between servers, ie they are effectively workgroup
1030 servers advertising themselves as participating in a domain.  This
1031 demonstrates how authentication is quite different from but closely
1032 involved with domains.
1033 </para>
1034
1035 <para>
1036 Another thing commonly associated with single-logon domains is remote
1037 administration over the SMB protocol.  Again, there is no reason why this
1038 cannot be implemented with an underlying username database which is
1039 different from the Windows NT SAM.  Support for the Remote Administration
1040 Protocol is planned for a future release of Samba.
1041 </para>
1042
1043 <para>
1044 Network logon support as discussed in this section is aimed at Window for
1045 Workgroups, and Windows 9X clients. 
1046 </para>
1047
1048 <para>
1049 Support for profiles is confirmed as working for Win95, NT 4.0 and NT 3.51.
1050 It is possible to specify: the profile location; script file to be loaded
1051 on login; the user's home directory; and for NT a kick-off time could also
1052 now easily be supported. However, there are some differences between Win9X
1053 profile support and WinNT profile support. These are discussed below.
1054 </para>
1055
1056 <para>
1057 With NT Workstations, all this does not require the use or intervention of
1058 an NT 4.0 or NT 3.51 server: Samba can now replace the logon services
1059 provided by an NT server, to a limited and experimental degree (for example,
1060 running "User Manager for Domains" will not provide you with access to
1061 a domain created by a Samba Server).
1062 </para>
1063
1064 <para>
1065 With Win95, the help of an NT server can be enlisted, both for profile storage
1066 and for user authentication.  For details on user authentication, see
1067 security_level.txt.  For details on profile storage, see below.
1068 </para>
1069
1070 <para>
1071 Using these features you can make your clients verify their logon via
1072 the Samba server; make clients run a batch file when they logon to
1073 the network and download their preferences, desktop and start menu.
1074 </para>
1075
1076 <para>
1077 Before launching into the configuration instructions, it is worthwhile looking
1078 at how a Win9X client performs a logon:
1079 </para>
1080
1081 <orderedlist>
1082 <listitem>
1083         <para>
1084         The client broadcasts (to the IP broadcast address of the subnet it is in)
1085         a NetLogon request. This is sent to the NetBIOS address DOMAIN<00> at the
1086         NetBIOS layer.  The client chooses the first response it receives, which
1087         contains the NetBIOS name of the logon server to use in the format of 
1088         \\SERVER.
1089         </para>
1090 </listitem>
1091
1092 <listitem>
1093         <para>
1094         The client then connects to that server, logs on (does an SMBsessetupX) and
1095         then connects to the IPC$ share (using an SMBtconX).
1096         </para>
1097 </listitem>
1098
1099 <listitem>
1100         <para>
1101         The client then does a NetWkstaUserLogon request, which retrieves the name
1102         of the user's logon script. 
1103         </para>
1104 </listitem>
1105
1106 <listitem>
1107         <para>
1108         The client then connects to the NetLogon share and searches for this    
1109         and if it is found and can be read, is retrieved and executed by the client.
1110         After this, the client disconnects from the NetLogon share.
1111         </para>
1112 </listitem>
1113
1114 <listitem>
1115         <para>
1116         The client then sends a NetUserGetInfo request to the server, to retrieve
1117         the user's home share, which is used to search for profiles. Since the
1118         response to the NetUserGetInfo request does not contain much more       
1119         the user's home share, profiles for Win9X clients MUST reside in the user
1120         home directory.
1121         </para>
1122 </listitem>
1123
1124 <listitem>
1125         <para>
1126         The client then connects to the user's home share and searches for the 
1127         user's profile. As it turns out, you can specify the users home share as
1128         a sharename and path. For example, \\server\fred\.profile.
1129         If the profiles are found, they are implemented.
1130         </para>
1131 </listitem>
1132
1133 <listitem>
1134         <para>
1135         The client then disconnects from the user's home share, and reconnects to
1136         the NetLogon share and looks for CONFIG.POL, the policies file. If this is
1137         found, it is read and implemented.
1138         </para>
1139 </listitem>
1140 </orderedlist>
1141
1142
1143 <sect2>
1144 <title>Configuration Instructions:      Network Logons</title>
1145
1146 <para>
1147 To use domain logons and profiles you need to do the following:
1148 </para>
1149
1150
1151 <orderedlist>
1152 <listitem>
1153         <para>
1154         Create a share called [netlogon] in your smb.conf. This share should
1155         be readable by all users, and probably should not be writeable. This
1156         share will hold your network logon scripts, and the CONFIG.POL file
1157         (Note: for details on the CONFIG.POL file, how to use it, what it is,
1158         refer to the Microsoft Windows NT Administration documentation.
1159         The format of these files is not known, so you will need to use
1160         Microsoft tools).
1161         </para>
1162
1163         <para>
1164         For example I have used:
1165         </para>
1166         
1167         <para><programlisting>
1168 [netlogon]
1169      path = /data/dos/netlogon
1170      writeable = no
1171      guest ok = no
1172 </programlisting></para>
1173
1174         <para>
1175         Note that it is important that this share is not writeable by ordinary
1176         users, in a secure environment: ordinary users should not be allowed
1177         to modify or add files that another user's computer would then download
1178         when they log in.
1179         </para>
1180 </listitem>
1181
1182
1183
1184 <listitem>
1185         <para>
1186         in the [global] section of smb.conf set the following:
1187         </para>
1188         
1189         <para><programlisting>
1190 domain logons = yes
1191 logon script = %U.bat
1192         </programlisting></para>
1193
1194         <para>
1195         The choice of batch file is, of course, up to you. The above would
1196         give each user a separate batch file as the %U will be changed to
1197         their username automatically. The other standard % macros may also be
1198         used. You can make the batch files come from a subdirectory by using
1199         something like:
1200         </para>
1201
1202         <para><programlisting>
1203 logon script = scripts\%U.bat
1204         </programlisting></para>
1205 </listitem>
1206
1207 <listitem>
1208         <para>
1209         create the batch files to be run when the user logs in. If the batch
1210         file doesn't exist then no batch file will be run. 
1211         </para>
1212
1213         <para>
1214         In the batch files you need to be careful to use DOS style cr/lf line
1215         endings. If you don't then DOS may get confused. I suggest you use a
1216         DOS editor to remotely edit the files if you don't know how to produce
1217         DOS style files under unix.
1218         </para>
1219 </listitem>
1220
1221
1222 <listitem>
1223         <para>
1224         Use smbclient with the -U option for some users to make sure that
1225         the \\server\NETLOGON share is available, the batch files are
1226         visible and they are readable by the users.
1227         </para>
1228 </listitem>
1229
1230 <listitem>
1231         <para>
1232         you will probabaly find that your clients automatically mount the
1233         \\SERVER\NETLOGON share as drive z: while logging in. You can put
1234         some useful programs there to execute from the batch files.
1235         </para>
1236 </listitem>
1237 </orderedlist>
1238
1239 <warning>
1240 <title>security mode and master browsers</title>
1241
1242 <para>
1243 There are a few comments to make in order to tie up some 
1244 loose ends.  There has been much debate over the issue of whether
1245 or not it is ok to configure Samba as a Domain Controller in security
1246 modes other than <constant>USER</constant>.  The only security mode 
1247 which  will not work due to technical reasons is <constant>SHARE</constant>
1248 mode security.  <constant>DOMAIN</constant> and <constant>SERVER</constant>
1249 mode security is really just a variation on SMB user level security.
1250 </para>
1251
1252 <para>
1253 Actually, this issue is also closer tied to the debate on whether 
1254 or not Samba must be the domain master browser for its workgroup
1255 when operating as a DC.  While it may technically be possible
1256 to configure a server as such (after all, browsing and domain logons
1257 are two distinctly different functions), it is not a good idea to
1258 so.  You should remember that the DC must register the DOMAIN#1b netbios 
1259 name.  This is the name used by Windows clients to locate the DC.
1260 Windows clients do not distinguish between the DC and the DMB.
1261 For this reason, it is very wise to configure the Samba DC as the DMB.
1262 </para>
1263
1264 <para>
1265 Now back to the issue of configuring a Samba DC to use a mode other
1266 than "security = user".  If a Samba host is configured to use 
1267 another SMB server or DC in order to validate user connection 
1268 requests, then it is a fact that some other machine on the network 
1269 (the "password server") knows more about user than the Samba host.
1270 99% of the time, this other host is a domain controller.  Now 
1271 in order to operate in domain mode security, the "workgroup" parameter
1272 must be set to the name of the Windows NT domain (which already 
1273 has a domain controller, right?)
1274 </para>
1275
1276 <para>
1277 Therefore configuring a Samba box as a DC for a domain that 
1278 already by definition has a PDC is asking for trouble.
1279 Therefore, you should always configure the Samba DC to be the DMB
1280 for its domain.
1281 </para>
1282 </warning>
1283
1284 </sect2>
1285
1286
1287 <sect2>
1288 <title>Configuration Instructions:      Setting up Roaming User Profiles</title>
1289
1290 <warning>
1291 <para>
1292 <emphasis>NOTE!</emphasis> Roaming profiles support is different 
1293 for Win9X and WinNT.
1294 </para>
1295 </warning>
1296
1297 <para>
1298 Before discussing how to configure roaming profiles, it is useful to see how
1299 Win9X and WinNT clients implement these features.
1300 </para>
1301
1302 <para>
1303 Win9X clients send a NetUserGetInfo request to the server to get the user's
1304 profiles location. However, the response does not have room for a separate 
1305 profiles location field, only the users home share. This means that Win9X 
1306 profiles are restricted to being in the user's home directory.
1307 </para>
1308
1309
1310 <para>
1311 WinNT clients send a NetSAMLogon RPC request, which contains many fields, 
1312 including a separate field for the location of the user's profiles. 
1313 This means that support for profiles is different for Win9X and WinNT.
1314 </para>
1315
1316
1317
1318 <sect3>
1319 <title>Windows NT Configuration</title>
1320
1321 <para>
1322 To support WinNT clients, inn the [global] section of smb.conf set the
1323 following (for example):
1324 </para>
1325
1326 <para><programlisting>
1327 logon path = \\profileserver\profileshare\profilepath\%U\moreprofilepath
1328 </programlisting></para>
1329
1330 <para>
1331 The default for this option is \\%N\%U\profile, namely
1332 \\sambaserver\username\profile.  The \\N%\%U service is created
1333 automatically by the [homes] service.
1334 If you are using a samba server for the profiles, you _must_ make the
1335 share specified in the logon path browseable. 
1336 </para>
1337
1338 <note>
1339 <para>
1340 [lkcl 26aug96 - we have discovered a problem where Windows clients can
1341 maintain a connection to the [homes] share in between logins.  The
1342 [homes] share must NOT therefore be used in a profile path.]
1343 </para>
1344 </note>
1345
1346 </sect3>
1347
1348
1349 <sect3>
1350 <title>Windows 9X Configuration</title>
1351
1352 <para>
1353 To support Win9X clients, you must use the "logon home" parameter. Samba has
1354 now been fixed so that "net use/home" now works as well, and it, too, relies
1355 on the "logon home" parameter.
1356 </para>
1357
1358 <para>
1359 By using the logon home parameter, you are restricted to putting Win9X 
1360 profiles in the user's home directory.   But wait! There is a trick you 
1361 can use. If you set the following in the [global] section of your 
1362 smb.conf file:
1363 </para>
1364
1365 <para><programlisting>
1366 logon home = \\%L\%U\.profiles
1367 </programlisting></para>
1368
1369 <para>
1370 then your Win9X clients will dutifully put their clients in a subdirectory
1371 of your home directory called .profiles (thus making them hidden).
1372 </para>
1373
1374 <para>
1375 Not only that, but 'net use/home' will also work, because of a feature in 
1376 Win9X. It removes any directory stuff off the end of the home directory area
1377 and only uses the server and share portion. That is, it looks like you
1378 specified \\%L\%U for "logon home".
1379 </para>
1380
1381
1382 </sect3>
1383
1384
1385 <sect3>
1386 <title>Win9X and WinNT Configuration</title>
1387
1388 <para>
1389 You can support profiles for both Win9X and WinNT clients by setting both the
1390 "logon home" and "logon path" parameters. For example:
1391 </para>
1392
1393 <para><programlisting>
1394 logon home = \\%L\%U\.profiles
1395 logon path = \\%L\profiles\%U
1396 </programlisting></para>
1397
1398 <note>
1399 <para>
1400 I have not checked what 'net use /home' does on NT when "logon home" is
1401 set as above.
1402 </para>
1403 </note>
1404 </sect3>
1405
1406
1407
1408 <sect3>
1409 <title>Windows 9X Profile Setup</title>
1410
1411 <para>
1412 When a user first logs in on Windows 9X, the file user.DAT is created,
1413 as are folders "Start Menu", "Desktop", "Programs" and "Nethood".  
1414 These directories and their contents will be merged with the local
1415 versions stored in c:\windows\profiles\username on subsequent logins,
1416 taking the most recent from each.  You will need to use the [global]
1417 options "preserve case = yes", "short case preserve = yes" and
1418 "case sensitive = no" in order to maintain capital letters in shortcuts
1419 in any of the profile folders.
1420 </para>
1421
1422
1423 <para>
1424 The user.DAT file contains all the user's preferences.  If you wish to
1425 enforce a set of preferences, rename their user.DAT file to user.MAN,
1426 and deny them write access to this file.
1427 </para>
1428
1429 <orderedlist>
1430 <listitem>
1431         <para>
1432         On the Windows 95 machine, go to Control Panel | Passwords and
1433         select the User Profiles tab.  Select the required level of
1434         roaming preferences.  Press OK, but do _not_ allow the computer
1435         to reboot.
1436         </para>
1437 </listitem>
1438
1439
1440 <listitem>
1441         <para>
1442         On the Windows 95 machine, go to Control Panel | Network |
1443         Client for Microsoft Networks | Preferences.  Select 'Log on to
1444         NT Domain'.  Then, ensure that the Primary Logon is 'Client for
1445         Microsoft Networks'.  Press OK, and this time allow the computer
1446         to reboot.
1447         </para>
1448 </listitem>
1449
1450 </orderedlist>
1451
1452 <para>
1453 Under Windows 95, Profiles are downloaded from the Primary Logon.
1454 If you have the Primary Logon as 'Client for Novell Networks', then
1455 the profiles and logon script will be downloaded from your Novell
1456 Server.  If you have the Primary Logon as 'Windows Logon', then the
1457 profiles will be loaded from the local machine - a bit against the
1458 concept of roaming profiles, if you ask me.
1459 </para>
1460
1461 <para>
1462 You will now find that the Microsoft Networks Login box contains
1463 [user, password, domain] instead of just [user, password].  Type in
1464 the samba server's domain name (or any other domain known to exist,
1465 but bear in mind that the user will be authenticated against this
1466 domain and profiles downloaded from it, if that domain logon server
1467 supports it), user name and user's password.
1468 </para>
1469
1470 <para>
1471 Once the user has been successfully validated, the Windows 95 machine
1472 will inform you that 'The user has not logged on before' and asks you
1473 if you wish to save the user's preferences?  Select 'yes'.
1474 </para>
1475
1476 <para>
1477 Once the Windows 95 client comes up with the desktop, you should be able
1478 to examine the contents of the directory specified in the "logon path"
1479 on the samba server and verify that the "Desktop", "Start Menu",
1480 "Programs" and "Nethood" folders have been created.
1481 </para>
1482
1483 <para>
1484 These folders will be cached locally on the client, and updated when
1485 the user logs off (if you haven't made them read-only by then :-).
1486 You will find that if the user creates further folders or short-cuts,
1487 that the client will merge the profile contents downloaded with the
1488 contents of the profile directory already on the local client, taking
1489 the newest folders and short-cuts from each set.
1490 </para>
1491
1492 <para>
1493 If you have made the folders / files read-only on the samba server,
1494 then you will get errors from the w95 machine on logon and logout, as
1495 it attempts to merge the local and the remote profile.  Basically, if
1496 you have any errors reported by the w95 machine, check the unix file
1497 permissions and ownership rights on the profile directory contents,
1498 on the samba server.
1499 </para>
1500
1501 <para>
1502 If you have problems creating user profiles, you can reset the user's
1503 local desktop cache, as shown below.  When this user then next logs in,
1504 they will be told that they are logging in "for the first time".
1505 </para>
1506
1507 <orderedlist>
1508 <listitem>
1509         <para>
1510         instead of logging in under the [user, password, domain] dialog,
1511         press escape.
1512         </para>
1513 </listitem>
1514
1515 <listitem>
1516         <para>
1517         run the regedit.exe program, and look in:
1518         </para>
1519         
1520         <para>
1521         HKEY_LOCAL_MACHINE\Windows\CurrentVersion\ProfileList
1522         </para>
1523
1524         <para>
1525         you will find an entry, for each user, of ProfilePath.  Note the
1526         contents of this key (likely to be c:\windows\profiles\username),
1527         then delete the key ProfilePath for the required user.
1528         </para>
1529
1530         <para>
1531         [Exit the registry editor].
1532         </para>
1533 </listitem>
1534
1535 <listitem>
1536         <para>
1537         <emphasis>WARNING</emphasis> - before deleting the contents of the 
1538         directory listed in
1539    the ProfilePath (this is likely to be c:\windows\profiles\username),
1540    ask them if they have any important files stored on their desktop
1541    or in their start menu.  delete the contents of the directory
1542    ProfilePath (making a backup if any of the files are needed).
1543         </para>
1544
1545         <para>
1546    This will have the effect of removing the local (read-only hidden
1547    system file) user.DAT in their profile directory, as well as the
1548    local "desktop", "nethood", "start menu" and "programs" folders.
1549         </para>
1550 </listitem>
1551
1552 <listitem>
1553         <para>
1554         search for the user's .PWL password-cacheing file in the c:\windows
1555         directory, and delete it.
1556         </para>
1557 </listitem>
1558
1559
1560 <listitem>
1561         <para>
1562         log off the windows 95 client.
1563         </para>
1564 </listitem>
1565
1566 <listitem>
1567         <para>
1568         check the contents of the profile path (see "logon path" described
1569         above), and delete the user.DAT or user.MAN file for the user,
1570         making a backup if required.  
1571         </para>
1572 </listitem>
1573
1574 </orderedlist>
1575
1576 <para>
1577 If all else fails, increase samba's debug log levels to between 3 and 10,
1578 and / or run a packet trace program such as tcpdump or netmon.exe, and
1579 look for any error reports.
1580 </para>
1581
1582 <para>
1583 If you have access to an NT server, then first set up roaming profiles
1584 and / or netlogons on the NT server.  Make a packet trace, or examine
1585 the example packet traces provided with NT server, and see what the
1586 differences are with the equivalent samba trace.
1587 </para>
1588
1589 </sect3>
1590
1591
1592 <sect3>
1593 <title>Windows NT Workstation 4.0</title>
1594
1595 <para>
1596 When a user first logs in to a Windows NT Workstation, the profile
1597 NTuser.DAT is created.  The profile location can be now specified
1598 through the "logon path" parameter.  
1599 </para>
1600
1601 <note>
1602 <para>
1603 [lkcl 10aug97 - i tried setting the path to
1604 \\samba-server\homes\profile, and discovered that this fails because
1605 a background process maintains the connection to the [homes] share
1606 which does _not_ close down in between user logins.  you have to
1607 have \\samba-server\%L\profile, where user is the username created
1608 from the [homes] share].
1609 </para>
1610 </note>
1611
1612 <para>
1613 There is a parameter that is now available for use with NT Profiles:
1614 "logon drive".  This should be set to "h:" or any other drive, and
1615 should be used in conjunction with the new "logon home" parameter.
1616 </para>
1617
1618 <para>
1619 The entry for the NT 4.0 profile is a _directory_ not a file.  The NT
1620 help on profiles mentions that a directory is also created with a .PDS
1621 extension.  The user, while logging in, must have write permission to
1622 create the full profile path (and the folder with the .PDS extension)
1623 [lkcl 10aug97 - i found that the creation of the .PDS directory failed,
1624 and had to create these manually for each user, with a shell script.
1625 also, i presume, but have not tested, that the full profile path must
1626 be browseable just as it is for w95, due to the manner in which they
1627 attempt to create the full profile path: test existence of each path
1628 component; create path component].
1629 </para>
1630
1631 <para>
1632 In the profile directory, NT creates more folders than 95.  It creates
1633 "Application Data" and others, as well as "Desktop", "Nethood",
1634 "Start Menu" and "Programs".  The profile itself is stored in a file
1635 NTuser.DAT.  Nothing appears to be stored in the .PDS directory, and
1636 its purpose is currently unknown.
1637 </para>
1638
1639 <para>
1640 You can use the System Control Panel to copy a local profile onto
1641 a samba server (see NT Help on profiles: it is also capable of firing
1642 up the correct location in the System Control Panel for you).  The
1643 NT Help file also mentions that renaming NTuser.DAT to NTuser.MAN
1644 turns a profile into a mandatory one.
1645 </para>
1646
1647 <note>
1648 <para>
1649 [lkcl 10aug97 - i notice that NT Workstation tells me that it is
1650 downloading a profile from a slow link.  whether this is actually the
1651 case, or whether there is some configuration issue, as yet unknown,
1652 that makes NT Workstation _think_ that the link is a slow one is a
1653 matter to be resolved].
1654 </para>
1655
1656 <para>
1657 [lkcl 20aug97 - after samba digest correspondance, one user found, and
1658 another confirmed, that profiles cannot be loaded from a samba server
1659 unless "security = user" and "encrypt passwords = yes" (see the file
1660 ENCRYPTION.txt) or "security = server" and "password server = ip.address.
1661 of.yourNTserver" are used.  either of these options will allow the NT
1662 workstation to access the samba server using LAN manager encrypted
1663 passwords, without the user intervention normally required by NT
1664 workstation for clear-text passwords].
1665 </para>
1666
1667 <para>
1668 [lkcl 25aug97 - more comments received about NT profiles: the case of
1669 the profile _matters_.  the file _must_ be called NTuser.DAT or, for
1670 a mandatory profile, NTuser.MAN].
1671 </para>
1672 </note>
1673
1674 </sect3>
1675
1676
1677 <sect3>
1678 <title>Windows NT Server</title>
1679
1680 <para>
1681 There is nothing to stop you specifying any path that you like for the
1682 location of users' profiles.  Therefore, you could specify that the
1683 profile be stored on a samba server, or any other SMB server, as long as
1684 that SMB server supports encrypted passwords.
1685 </para>
1686
1687 </sect3>
1688
1689
1690 <sect3>
1691 <title>Sharing Profiles between W95 and NT Workstation 4.0</title>
1692
1693 <warning>
1694 <title>Potentially outdated or incorrect material follows</title>
1695 <para>
1696 I think this is all bogus, but have not deleted it. (Richard Sharpe)
1697 </para>
1698 </warning>
1699
1700 <para>
1701 The default logon path is \\%N\U%.  NT Workstation will attempt to create
1702 a directory "\\samba-server\username.PDS" if you specify the logon path
1703 as "\\samba-server\username" with the NT User Manager.  Therefore, you
1704 will need to specify (for example) "\\samba-server\username\profile".
1705 NT 4.0 will attempt to create "\\samba-server\username\profile.PDS", which
1706 is more likely to succeed.
1707 </para>
1708
1709 <para>
1710 If you then want to share the same Start Menu / Desktop with W95, you will
1711 need to specify "logon path = \\samba-server\username\profile" [lkcl 10aug97
1712 this has its drawbacks: i created a shortcut to telnet.exe, which attempts
1713 to run from the c:\winnt\system32 directory.  this directory is obviously
1714 unlikely to exist on a Win95-only host].
1715 </para>
1716
1717 <para>
1718
1719 If you have this set up correctly, you will find separate user.DAT and
1720 NTuser.DAT files in the same profile directory.
1721 </para>
1722
1723 <note>
1724 <para>
1725 [lkcl 25aug97 - there are some issues to resolve with downloading of
1726 NT profiles, probably to do with time/date stamps.  i have found that
1727 NTuser.DAT is never updated on the workstation after the first time that
1728 it is copied to the local workstation profile directory.  this is in
1729 contrast to w95, where it _does_ transfer / update profiles correctly].
1730 </para>
1731 </note>
1732
1733 </sect3>
1734
1735 </sect2>
1736 </sect1>
1737
1738
1739 <!-- **********************************************************
1740
1741      Appendix - DOMAIN_CONTROL.txt
1742
1743 *************************************************************** -->
1744
1745 <sect1>
1746 <title>
1747 DOMAIN_CONTROL.txt : Windows NT Domain Control & Samba
1748 </title>
1749
1750 <warning>
1751         <title>Possibly Outdated Material</title>
1752
1753         <para>
1754         This appendix was originally authored by John H Terpstra of 
1755         the Samba Team and is included here for posterity.
1756         </para>
1757 </warning>
1758
1759
1760 <para>
1761 <emphasis>NOTE :</emphasis> 
1762 The term "Domain Controller" and those related to it refer to one specific
1763 method of authentication that can underly an SMB domain. Domain Controllers
1764 prior to Windows NT Server 3.1 were sold by various companies and based on 
1765 private extensions to the LAN Manager 2.1 protocol. Windows NT introduced
1766 Microsoft-specific ways of distributing the user authentication database.
1767 See DOMAIN.txt for examples of how Samba can participate in or create
1768 SMB domains based on shared authentication database schemes other than the 
1769 Windows NT SAM.
1770 </para>
1771
1772 <para>
1773 Windows NT Server can be installed as either a plain file and print server
1774 (WORKGROUP workstation or server) or as a server that participates in Domain
1775 Control (DOMAIN member, Primary Domain controller or Backup Domain controller).
1776 The same is true for OS/2 Warp Server, Digital Pathworks and other similar
1777 products, all of which can participate in Domain Control along with Windows NT.
1778 </para>
1779
1780 <para>
1781 To many people these terms can be confusing, so let's try to clear the air.
1782 </para>
1783
1784 <para>
1785 Every Windows NT system (workstation or server) has a registry database.
1786 The registry contains entries that describe the initialization information
1787 for all services (the equivalent of Unix Daemons) that run within the Windows
1788 NT environment. The registry also contains entries that tell application
1789 software where to find dynamically loadable libraries that they depend upon.
1790 In fact, the registry contains entries that describes everything that anything
1791 may need to know to interact with the rest of the system.
1792 </para>
1793
1794 <para>
1795 The registry files can be located on any Windows NT machine by opening a
1796 command prompt and typing:
1797 </para>
1798
1799 <para>
1800 <prompt>C:\WINNT\></prompt> dir %SystemRoot%\System32\config
1801 </para>
1802
1803 <para>
1804 The environment variable %SystemRoot% value can be obtained by typing:
1805 </para>
1806
1807 <para>
1808 <prompt>C:\WINNT></prompt>echo %SystemRoot%
1809 </para>
1810
1811 <para>
1812 The active parts of the registry that you may want to be familiar with are
1813 the files called: default, system, software, sam and security.
1814 </para>
1815
1816 <para>
1817 In a domain environment, Microsoft Windows NT domain controllers participate
1818 in replication of the SAM and SECURITY files so that all controllers within
1819 the domain have an exactly identical copy of each.
1820 </para>
1821
1822 <para>
1823 The Microsoft Windows NT system is structured within a security model that
1824 says that all applications and services must authenticate themselves before
1825 they can obtain permission from the security manager to do what they set out
1826 to do.
1827 </para>
1828
1829 <para>
1830 The Windows NT User database also resides within the registry. This part of
1831 the registry contains the user's security identifier, home directory, group
1832 memberships, desktop profile, and so on.
1833 </para>
1834
1835 <para>
1836 Every Windows NT system (workstation as well as server) will have its own
1837 registry. Windows NT Servers that participate in Domain Security control
1838 have a database that they share in common - thus they do NOT own an
1839 independent full registry database of their own, as do Workstations and
1840 plain Servers.
1841 </para>
1842
1843 <para>
1844 The User database is called the SAM (Security Access Manager) database and
1845 is used for all user authentication as well as for authentication of inter-
1846 process authentication (ie: to ensure that the service action a user has
1847 requested is permitted within the limits of that user's privileges).
1848 </para>
1849
1850 <para>
1851 The Samba team have produced a utility that can dump the Windows NT SAM into 
1852 smbpasswd format: see ENCRYPTION.txt for information on smbpasswd and
1853 /pub/samba/pwdump on your nearest Samba mirror for the utility. This 
1854 facility is useful but cannot be easily used to implement SAM replication
1855 to Samba systems.
1856 </para>
1857
1858 <para>
1859 Windows for Workgroups, Windows 95, and Windows NT Workstations and Servers
1860 can participate in a Domain security system that is controlled by Windows NT
1861 servers that have been correctly configured. At most every domain will have
1862 ONE Primary Domain Controller (PDC). It is desirable that each domain will
1863 have at least one Backup Domain Controller (BDC).
1864 </para>
1865
1866 <para>
1867 The PDC and BDCs then participate in replication of the SAM database so that
1868 each Domain Controlling participant will have an up to date SAM component
1869 within its registry.
1870 </para>
1871
1872 </sect1>
1873
1874 </chapter>