diff options
Diffstat (limited to 'docs/htmldocs/Samba-PDC-HOWTO.html')
| -rw-r--r-- | docs/htmldocs/Samba-PDC-HOWTO.html | 2284 |
1 files changed, 2284 insertions, 0 deletions
diff --git a/docs/htmldocs/Samba-PDC-HOWTO.html b/docs/htmldocs/Samba-PDC-HOWTO.html new file mode 100644 index 0000000000..58f3989b4f --- /dev/null +++ b/docs/htmldocs/Samba-PDC-HOWTO.html @@ -0,0 +1,2284 @@ +<HTML +><HEAD +><TITLE +>How to Configure Samba 2.2 as a Primary Domain Controller</TITLE +><META +NAME="GENERATOR" +CONTENT="Modular DocBook HTML Stylesheet Version 1.57"></HEAD +><BODY +CLASS="ARTICLE" +BGCOLOR="#FFFFFF" +TEXT="#000000" +LINK="#0000FF" +VLINK="#840084" +ALINK="#0000FF" +><DIV +CLASS="ARTICLE" +><DIV +CLASS="TITLEPAGE" +><H1 +CLASS="TITLE" +><A +NAME="SAMBA-PDC" +>How to Configure Samba 2.2 as a Primary Domain Controller</A +></H1 +><HR></DIV +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN3" +>Prerequisite Reading</A +></H1 +><P +>Before you continue reading in this chapter, please make sure +that you are comfortable with configuring basic files services +in smb.conf and how to enable and administer password +encryption in Samba. Theses two topics are covered in the +<A +HREF="smb.conf.5.html" +TARGET="_top" +><TT +CLASS="FILENAME" +>smb.conf(5)</TT +></A +> +manpage and the <A +HREF="ENCRYPTION.html" +TARGET="_top" +>Encryption chapter</A +> +of this HOWTO Collection.</P +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN9" +>Background</A +></H1 +><DIV +CLASS="NOTE" +><BLOCKQUOTE +CLASS="NOTE" +><P +><B +>Note: </B +><I +CLASS="EMPHASIS" +>Author's Note:</I +> This document is a combination +of David Bannon's "Samba 2.2 PDC HOWTO" and "Samba NT Domain FAQ". +Both documents are superseded by this one.</P +></BLOCKQUOTE +></DIV +><P +>Versions of Samba prior to release 2.2 had marginal capabilities to act +as a Windows NT 4.0 Primary Domain Controller + +(PDC). With Samba 2.2.0, we are proud to announce official support for +Windows NT 4.0-style domain logons from Windows NT 4.0 and Windows +2000 clients. This article outlines the steps +necessary for configuring Samba as a PDC. It is necessary to have a +working Samba server prior to implementing the PDC functionality. If +you have not followed the steps outlined in <A +HREF="UNIX_INSTALL.html" +TARGET="_top" +> UNIX_INSTALL.html</A +>, please make sure +that your server is configured correctly before proceeding. Another +good resource in the <A +HREF="smb.conf.5.html" +TARGET="_top" +>smb.conf(5) man +page</A +>. The following functionality should work in 2.2:</P +><P +></P +><UL +><LI +><P +> domain logons for Windows NT 4.0/2000 clients. + </P +></LI +><LI +><P +> placing a Windows 9x client in user level security + </P +></LI +><LI +><P +> retrieving a list of users and groups from a Samba PDC to + Windows 9x/NT/2000 clients + </P +></LI +><LI +><P +> roving (roaming) user profiles + </P +></LI +><LI +><P +> Windows NT 4.0-style system policies + </P +></LI +></UL +><P +>The following pieces of functionality are not included in the 2.2 release:</P +><P +></P +><UL +><LI +><P +> Windows NT 4 domain trusts + </P +></LI +><LI +><P +> SAM replication with Windows NT 4.0 Domain Controllers + (i.e. a Samba PDC and a Windows NT BDC or vice versa) + </P +></LI +><LI +><P +> Adding users via the User Manager for Domains + </P +></LI +><LI +><P +> Acting as a Windows 2000 Domain Controller (i.e. Kerberos and + Active Directory) + </P +></LI +></UL +><P +>Please note that Windows 9x clients are not true members of a domain +for reasons outlined in this article. Therefore the protocol for +support Windows 9x-style domain logons is completely different +from NT4 domain logons and has been officially supported for some +time.</P +><P +>Implementing a Samba PDC can basically be divided into 2 broad +steps.</P +><P +></P +><OL +TYPE="1" +><LI +><P +> Configuring the Samba PDC + </P +></LI +><LI +><P +> Creating machine trust accounts and joining clients + to the domain + </P +></LI +></OL +><P +>There are other minor details such as user profiles, system +policies, etc... However, these are not necessarily specific +to a Samba PDC as much as they are related to Windows NT networking +concepts. They will be mentioned only briefly here.</P +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN48" +>Configuring the Samba Domain Controller</A +></H1 +><P +>The first step in creating a working Samba PDC is to +understand the parameters necessary in smb.conf. I will not +attempt to re-explain the parameters here as they are more that +adequately covered in <A +HREF="smb.conf.5.html" +TARGET="_top" +> the smb.conf +man page</A +>. For convenience, the parameters have been +linked with the actual smb.conf description.</P +><P +>Here is an example <TT +CLASS="FILENAME" +>smb.conf</TT +> for acting as a PDC:</P +><P +><PRE +CLASS="PROGRAMLISTING" +>[global] + ; Basic server settings + <A +HREF="smb.conf.5.html#NETBIOSNAME" +TARGET="_top" +>netbios name</A +> = <TT +CLASS="REPLACEABLE" +><I +>POGO</I +></TT +> + <A +HREF="smb.conf.5.html#WORKGROUP" +TARGET="_top" +>workgroup</A +> = <TT +CLASS="REPLACEABLE" +><I +>NARNIA</I +></TT +> + + ; we should act as the domain and local master browser + <A +HREF="smb.conf.5.html#OSLEVEL" +TARGET="_top" +>os level</A +> = 64 + <A +HREF="smb.conf.5.html#PERFERREDMASTER" +TARGET="_top" +>preferred master</A +> = yes + <A +HREF="smb.conf.5.html#DOMAINMASTER" +TARGET="_top" +>domain master</A +> = yes + <A +HREF="smb.conf.5.html#LOCALMASTER" +TARGET="_top" +>local master</A +> = yes + + ; security settings (must user security = user) + <A +HREF="smb.conf.5.html#SECURITYEQUALSUSER" +TARGET="_top" +>security</A +> = user + + ; encrypted passwords are a requirement for a PDC + <A +HREF="smb.conf.5.html#ENCRYPTPASSWORDS" +TARGET="_top" +>encrypt passwords</A +> = yes + + ; support domain logons + <A +HREF="smb.conf.5.html#DOMAINLOGONS" +TARGET="_top" +>domain logons</A +> = yes + + ; where to store user profiles? + <A +HREF="smb.conf.5.html#LOGONPATH" +TARGET="_top" +>logon path</A +> = \\%N\profiles\%u + + ; where is a user's home directory and where should it + ; be mounted at? + <A +HREF="smb.conf.5.html#LOGONDRIVE" +TARGET="_top" +>logon drive</A +> = H: + <A +HREF="smb.conf.5.html#LOGONHOME" +TARGET="_top" +>logon home</A +> = \\homeserver\%u + + ; specify a generic logon script for all users + ; this is a relative **DOS** path to the [netlogon] share + <A +HREF="smb.conf.5.html#LOGONSCRIPT" +TARGET="_top" +>logon script</A +> = logon.cmd + +; necessary share for domain controller +[netlogon] + <A +HREF="smb.conf.5.html#PATH" +TARGET="_top" +>path</A +> = /usr/local/samba/lib/netlogon + <A +HREF="smb.conf.5.html#READONLY" +TARGET="_top" +>read only</A +> = yes + <A +HREF="smb.conf.5.html#WRITELIST" +TARGET="_top" +>write list</A +> = <TT +CLASS="REPLACEABLE" +><I +>ntadmin</I +></TT +> + +; share for storing user profiles +[profiles] + <A +HREF="smb.conf.5.html#PATH" +TARGET="_top" +>path</A +> = /export/smb/ntprofile + <A +HREF="smb.conf.5.html#READONLY" +TARGET="_top" +>read only</A +> = no + <A +HREF="smb.conf.5.html#CREATEMASK" +TARGET="_top" +>create mask</A +> = 0600 + <A +HREF="smb.conf.5.html#DIRECTORYMASK" +TARGET="_top" +>directory mask</A +> = 0700</PRE +></P +><P +>There are a couple of points to emphasize in the above configuration.</P +><P +></P +><UL +><LI +><P +> Encrypted passwords must be enabled. For more details on how + to do this, refer to <A +HREF="ENCRYPTION.html" +TARGET="_top" +>ENCRYPTION.html</A +>. + </P +></LI +><LI +><P +> The server must support domain logons and a + <TT +CLASS="FILENAME" +>[netlogon]</TT +> share + </P +></LI +><LI +><P +> The server must be the domain master browser in order for Windows + client to locate the server as a DC. Please refer to the various + Network Browsing documentation included with this distribution for + details. + </P +></LI +></UL +><P +>As Samba 2.2 does not offer a complete implementation of group mapping +between Windows NT groups and Unix groups (this is really quite +complicated to explain in a short space), you should refer to the +<A +HREF="smb.conf.5.html#DOMAINADMINGROUP" +TARGET="_top" +>domain admin +group</A +> smb.conf parameter for information of creating "Domain +Admins" style accounts.</P +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN91" +>Creating Machine Trust Accounts and Joining Clients to the +Domain</A +></H1 +><P +>A machine trust account is a Samba account that is used to +authenticate a client machine (rather than a user) to the Samba +server. In Windows terminology, this is known as a "Computer +Account."</P +><P +>The password of a machine trust account acts as the shared secret for +secure communication with the Domain Controller. This is a security +feature to prevent an unauthorized machine with the same NetBIOS name +from joining the domain and gaining access to domain user/group +accounts. Windows NT and 2000 clients use machine trust accounts, but +Windows 9x clients do not. Hence, a Windows 9x client is never a true +member of a domain because it does not possess a machine trust +account, and thus has no shared secret with the domain controller.</P +><P +>A Windows PDC stores each machine trust account in the Windows +Registry. A Samba PDC, however, stores each machine trust account +in two parts, as follows: + +<P +></P +><UL +><LI +><P +>A Samba account, stored in the same location as user + LanMan and NT password hashes (currently + <TT +CLASS="FILENAME" +>smbpasswd</TT +>). The Samba account + possesses and uses only the NT password hash.</P +></LI +><LI +><P +>A corresponding Unix account, typically stored in + <TT +CLASS="FILENAME" +>/etc/passwd</TT +>. (Future releases will alleviate the need to + create <TT +CLASS="FILENAME" +>/etc/passwd</TT +> entries.) </P +></LI +></UL +></P +><P +>There are two ways to create machine trust accounts:</P +><P +></P +><UL +><LI +><P +> Manual creation. Both the Samba and corresponding + Unix account are created by hand.</P +></LI +><LI +><P +> "On-the-fly" creation. The Samba machine trust + account is automatically created by Samba at the time the client + is joined to the domain. (For security, this is the + recommended method.) The corresponding Unix account may be + created automatically or manually. </P +></LI +></UL +><DIV +CLASS="SECT2" +><HR><H2 +CLASS="SECT2" +><A +NAME="AEN110" +>Manual Creation of Machine Trust Accounts</A +></H2 +><P +>The first step in manually creating a machine trust account is to +manually create the corresponding Unix account in +<TT +CLASS="FILENAME" +>/etc/passwd</TT +>. This can be done using +<B +CLASS="COMMAND" +>vipw</B +> or other 'add user' command that is normally +used to create new Unix accounts. The following is an example for a +Linux based Samba server:</P +><P +> <TT +CLASS="PROMPT" +>root# </TT +><B +CLASS="COMMAND" +>/usr/sbin/useradd -g 100 -d /dev/null -c <TT +CLASS="REPLACEABLE" +><I +>"machine +nickname"</I +></TT +> -s /bin/false <TT +CLASS="REPLACEABLE" +><I +>machine_name</I +></TT +>$ </B +></P +><P +><TT +CLASS="PROMPT" +>root# </TT +><B +CLASS="COMMAND" +>passwd -l <TT +CLASS="REPLACEABLE" +><I +>machine_name</I +></TT +>$</B +></P +><P +>The <TT +CLASS="FILENAME" +>/etc/passwd</TT +> entry will list the machine name +with a "$" appended, won't have a password, will have a null shell and no +home directory. For example a machine named 'doppy' would have an +<TT +CLASS="FILENAME" +>/etc/passwd</TT +> entry like this:</P +><P +><PRE +CLASS="PROGRAMLISTING" +>doppy$:x:505:501:<TT +CLASS="REPLACEABLE" +><I +>machine_nickname</I +></TT +>:/dev/null:/bin/false</PRE +></P +><P +>Above, <TT +CLASS="REPLACEABLE" +><I +>machine_nickname</I +></TT +> can be any +descriptive name for the client, i.e., BasementComputer. +<TT +CLASS="REPLACEABLE" +><I +>machine_name</I +></TT +> absolutely must be the NetBIOS +name of the client to be joined to the domain. The "$" must be +appended to the NetBIOS name of the client or Samba will not recognize +this as a machine trust account.</P +><P +>Now that the corresponding Unix account has been created, the next step is to create +the Samba account for the client containing the well-known initial +machine trust account password. This can be done using the <A +HREF="smbpasswd.8.html" +TARGET="_top" +><B +CLASS="COMMAND" +>smbpasswd(8)</B +></A +> command +as shown here:</P +><P +><TT +CLASS="PROMPT" +>root# </TT +><B +CLASS="COMMAND" +>smbpasswd -a -m <TT +CLASS="REPLACEABLE" +><I +>machine_name</I +></TT +></B +></P +><P +>where <TT +CLASS="REPLACEABLE" +><I +>machine_name</I +></TT +> is the machine's NetBIOS +name. The RID of the new machine account is generated from the UID of +the corresponding Unix account.</P +><DIV +CLASS="WARNING" +><P +></P +><TABLE +CLASS="WARNING" +BORDER="1" +WIDTH="100%" +><TR +><TD +ALIGN="CENTER" +><B +>Join the client to the domain immediately</B +></TD +></TR +><TR +><TD +ALIGN="LEFT" +><P +> Manually creating a machine trust account using this method is the + equivalent of creating a machine trust account on a Windows NT PDC using + the "Server Manager". From the time at which the account is created + to the time which the client joins the domain and changes the password, + your domain is vulnerable to an intruder joining your domain using a + a machine with the same NetBIOS name. A PDC inherently trusts + members of the domain and will serve out a large degree of user + information to such clients. You have been warned! + </P +></TD +></TR +></TABLE +></DIV +></DIV +><DIV +CLASS="SECT2" +><HR><H2 +CLASS="SECT2" +><A +NAME="AEN145" +>"On-the-Fly" Creation of Machine Trust Accounts</A +></H2 +><P +>The second (and recommended) way of creating machine trust accounts is +simply to allow the Samba server to create them as needed when the client +is joined to the domain. </P +><P +>Since each Samba machine trust account requires a corresponding +Unix account, a method for automatically creating the +Unix account is usually supplied; this requires configuration of the +<A +HREF="smb.conf.5.html#ADDUSERSCRIPT" +TARGET="_top" +>add user script</A +> +option in <TT +CLASS="FILENAME" +>smb.conf</TT +>. This +method is not required, however; corresponding Unix accounts may also +be created manually.</P +><P +>Below is an example for a RedHat 6.2 Linux system.</P +><P +><PRE +CLASS="PROGRAMLISTING" +>[global] + # <...remainder of parameters...> + add user script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u </PRE +></P +></DIV +><DIV +CLASS="SECT2" +><HR><H2 +CLASS="SECT2" +><A +NAME="AEN154" +>Joining the Client to the Domain</A +></H2 +><P +>The procedure for joining a client to the domain varies with the +version of Windows.</P +><P +></P +><UL +><LI +><P +><I +CLASS="EMPHASIS" +>Windows 2000</I +></P +><P +> When the user elects to join the client to a domain, Windows prompts for + an account and password that is privileged to join the domain. A + Samba administrative account (i.e., a Samba account that has root + privileges on the Samba server) must be entered here; the + operation will fail if an ordinary user account is given. + The password for this account should be + set to a different password than the associated + <TT +CLASS="FILENAME" +>/etc/passwd</TT +> entry, for security + reasons. </P +><P +>The session key of the Samba administrative account acts as an + encryption key for setting the password of the machine trust + account. The machine trust account will be created on-the-fly, or + updated if it already exists.</P +></LI +><LI +><P +><I +CLASS="EMPHASIS" +>Windows NT</I +></P +><P +> If the machine trust account was created manually, on the + Identification Changes menu enter the domain name, but do not + check the box "Create a Computer Account in the Domain." In this case, + the existing machine trust account is used to join the machine to + the domain.</P +><P +> If the machine trust account is to be created + on-the-fly, on the Identification Changes menu enter the domain + name, and check the box "Create a Computer Account in the Domain." In + this case, joining the domain proceeds as above for Windows 2000 + (i.e., you must supply a Samba administrative account when + prompted).</P +></LI +></UL +></DIV +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN169" +>Common Problems and Errors</A +></H1 +><P +></P +><P +></P +><UL +><LI +><P +> <I +CLASS="EMPHASIS" +>I cannot include a '$' in a machine name.</I +> + </P +><P +> A 'machine name' in (typically) <TT +CLASS="FILENAME" +>/etc/passwd</TT +> + of the machine name with a '$' appended. FreeBSD (and other BSD + systems?) won't create a user with a '$' in their name. + </P +><P +> The problem is only in the program used to make the entry, once + made, it works perfectly. So create a user without the '$' and + use <B +CLASS="COMMAND" +>vipw</B +> to edit the entry, adding the '$'. Or create + the whole entry with vipw if you like, make sure you use a + unique User ID ! + </P +></LI +><LI +><P +> <I +CLASS="EMPHASIS" +>I get told "You already have a connection to the Domain...." + or "Cannot join domain, the credentials supplied conflict with an + existing set.." when creating a machine trust account.</I +> + </P +><P +> This happens if you try to create a machine trust account from the + machine itself and already have a connection (e.g. mapped drive) + to a share (or IPC$) on the Samba PDC. The following command + will remove all network drive connections: + </P +><P +> <TT +CLASS="PROMPT" +>C:\WINNT\></TT +> <B +CLASS="COMMAND" +>net use * /d</B +> + </P +><P +> Further, if the machine is a already a 'member of a workgroup' that + is the same name as the domain you are joining (bad idea) you will + get this message. Change the workgroup name to something else, it + does not matter what, reboot, and try again. + </P +></LI +><LI +><P +> <I +CLASS="EMPHASIS" +>The system can not log you on (C000019B)....</I +> + </P +><P +>I joined the domain successfully but after upgrading + to a newer version of the Samba code I get the message, "The system + can not log you on (C000019B), Please try a gain or consult your + system administrator" when attempting to logon. + </P +><P +> This occurs when the domain SID stored in + <TT +CLASS="FILENAME" +>private/WORKGROUP.SID</TT +> is + changed. For example, you remove the file and <B +CLASS="COMMAND" +>smbd</B +> automatically + creates a new one. Or you are swapping back and forth between + versions 2.0.7, TNG and the HEAD branch code (not recommended). The + only way to correct the problem is to restore the original domain + SID or remove the domain client from the domain and rejoin. + </P +></LI +><LI +><P +> <I +CLASS="EMPHASIS" +>The machine trust account for this computer either does not + exist or is not accessible.</I +> + </P +><P +> When I try to join the domain I get the message "The machine account + for this computer either does not exist or is not accessible". What's + wrong? + </P +><P +> This problem is caused by the PDC not having a suitable machine trust account. + If you are using the <TT +CLASS="PARAMETER" +><I +>add user script</I +></TT +> method to create + accounts then this would indicate that it has not worked. Ensure the domain + admin user system is working. + </P +><P +> Alternatively if you are creating account entries manually then they + have not been created correctly. Make sure that you have the entry + correct for the machine trust account in smbpasswd file on the Samba PDC. + If you added the account using an editor rather than using the smbpasswd + utility, make sure that the account name is the machine NetBIOS name + with a '$' appended to it ( i.e. computer_name$ ). There must be an entry + in both /etc/passwd and the smbpasswd file. Some people have reported + that inconsistent subnet masks between the Samba server and the NT + client have caused this problem. Make sure that these are consistent + for both client and server. + </P +></LI +><LI +><P +> <I +CLASS="EMPHASIS" +>When I attempt to login to a Samba Domain from a NT4/W2K workstation, + I get a message about my account being disabled.</I +> + </P +><P +> This problem is caused by a PAM related bug in Samba 2.2.0. This bug is + fixed in 2.2.1. Other symptoms could be unaccessible shares on + NT/W2K member servers in the domain or the following error in your smbd.log: + passdb/pampass.c:pam_account(268) PAM: UNKNOWN ERROR for User: %user% + </P +><P +> At first be ensure to enable the useraccounts with <B +CLASS="COMMAND" +>smbpasswd -e + %user%</B +>, this is normally done, when you create an account. + </P +><P +> In order to work around this problem in 2.2.0, configure the + <TT +CLASS="PARAMETER" +><I +>account</I +></TT +> control flag in + <TT +CLASS="FILENAME" +>/etc/pam.d/samba</TT +> file as follows: + </P +><P +><PRE +CLASS="PROGRAMLISTING" +> account required pam_permit.so + </PRE +></P +><P +> If you want to remain backward compatibility to samba 2.0.x use + <TT +CLASS="FILENAME" +>pam_permit.so</TT +>, it's also possible to use + <TT +CLASS="FILENAME" +>pam_pwdb.so</TT +>. There are some bugs if you try to + use <TT +CLASS="FILENAME" +>pam_unix.so</TT +>, if you need this, be ensure to use + the most recent version of this file. + </P +></LI +></UL +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN217" +>System Policies and Profiles</A +></H1 +><P +>Much of the information necessary to implement System Policies and +Roving User Profiles in a Samba domain is the same as that for +implementing these same items in a Windows NT 4.0 domain. +You should read the white paper <A +HREF="http://www.microsoft.com/ntserver/management/deployment/planguide/prof_policies.asp" +TARGET="_top" +>Implementing +Profiles and Policies in Windows NT 4.0</A +> available from Microsoft.</P +><P +>Here are some additional details:</P +><P +></P +><UL +><LI +><P +> <I +CLASS="EMPHASIS" +>What about Windows NT Policy Editor?</I +> + </P +><P +> To create or edit <TT +CLASS="FILENAME" +>ntconfig.pol</TT +> you must use + the NT Server Policy Editor, <B +CLASS="COMMAND" +>poledit.exe</B +> which + is included with NT Server but <I +CLASS="EMPHASIS" +>not NT Workstation</I +>. + There is a Policy Editor on a NTws + but it is not suitable for creating <I +CLASS="EMPHASIS" +>Domain Policies</I +>. + Further, although the Windows 95 + Policy Editor can be installed on an NT Workstation/Server, it will not + work with NT policies because the registry key that are set by the policy templates. + However, the files from the NT Server will run happily enough on an NTws. + You need <TT +CLASS="FILENAME" +>poledit.exe, common.adm</TT +> and <TT +CLASS="FILENAME" +>winnt.adm</TT +>. It is convenient + to put the two *.adm files in <TT +CLASS="FILENAME" +>c:\winnt\inf</TT +> which is where + the binary will look for them unless told otherwise. Note also that that + directory is 'hidden'. + </P +><P +> The Windows NT policy editor is also included with the Service Pack 3 (and + later) for Windows NT 4.0. Extract the files using <B +CLASS="COMMAND" +>servicepackname /x</B +>, + i.e. that's <B +CLASS="COMMAND" +>Nt4sp6ai.exe /x</B +> for service pack 6a. The policy editor, + <B +CLASS="COMMAND" +>poledit.exe</B +> and the associated template files (*.adm) should + be extracted as well. It is also possible to downloaded the policy template + files for Office97 and get a copy of the policy editor. Another possible + location is with the Zero Administration Kit available for download from Microsoft. + </P +></LI +><LI +><P +> <I +CLASS="EMPHASIS" +>Can Win95 do Policies?</I +> + </P +><P +> Install the group policy handler for Win9x to pick up group + policies. Look on the Win98 CD in <TT +CLASS="FILENAME" +>\tools\reskit\netadmin\poledit</TT +>. + Install group policies on a Win9x client by double-clicking + <TT +CLASS="FILENAME" +>grouppol.inf</TT +>. Log off and on again a couple of + times and see if Win98 picks up group policies. Unfortunately this needs + to be done on every Win9x machine that uses group policies.... + </P +><P +> If group policies don't work one reports suggests getting the updated + (read: working) grouppol.dll for Windows 9x. The group list is grabbed + from /etc/group. + </P +></LI +><LI +><P +> <I +CLASS="EMPHASIS" +>How do I get 'User Manager' and 'Server Manager'</I +> + </P +><P +> Since I don't need to buy an NT Server CD now, how do I get + the 'User Manager for Domains', the 'Server Manager'? + </P +><P +> Microsoft distributes a version of these tools called nexus for + installation on Windows 95 systems. The tools set includes + </P +><P +></P +><UL +><LI +><P +>Server Manager</P +></LI +><LI +><P +>User Manager for Domains</P +></LI +><LI +><P +>Event Viewer</P +></LI +></UL +><P +> Click here to download the archived file <A +HREF="ftp://ftp.microsoft.com/Softlib/MSLFILES/NEXUS.EXE" +TARGET="_top" +>ftp://ftp.microsoft.com/Softlib/MSLFILES/NEXUS.EXE</A +> + </P +><P +> The Windows NT 4.0 version of the 'User Manager for + Domains' and 'Server Manager' are available from Microsoft via ftp + from <A +HREF="ftp://ftp.microsoft.com/Softlib/MSLFILES/SRVTOOLS.EXE" +TARGET="_top" +>ftp://ftp.microsoft.com/Softlib/MSLFILES/SRVTOOLS.EXE</A +> + </P +></LI +></UL +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN261" +>What other help can I get?</A +></H1 +><P +>There are many sources of information available in the form +of mailing lists, RFC's and documentation. The docs that come +with the samba distribution contain very good explanations of +general SMB topics such as browsing.</P +><P +></P +><UL +><LI +><P +> <I +CLASS="EMPHASIS" +>What are some diagnostics tools I can use to debug the domain logon + process and where can I find them?</I +> + </P +><P +> One of the best diagnostic tools for debugging problems is Samba itself. + You can use the -d option for both smbd and nmbd to specify what + 'debug level' at which to run. See the man pages on smbd, nmbd and + smb.conf for more information on debugging options. The debug + level can range from 1 (the default) to 10 (100 for debugging passwords). + </P +><P +> Another helpful method of debugging is to compile samba using the + <B +CLASS="COMMAND" +>gcc -g </B +> flag. This will include debug + information in the binaries and allow you to attach gdb to the + running smbd / nmbd process. In order to attach gdb to an smbd + process for an NT workstation, first get the workstation to make the + connection. Pressing ctrl-alt-delete and going down to the domain box + is sufficient (at least, on the first time you join the domain) to + generate a 'LsaEnumTrustedDomains'. Thereafter, the workstation + maintains an open connection, and therefore there will be an smbd + process running (assuming that you haven't set a really short smbd + idle timeout) So, in between pressing ctrl alt delete, and actually + typing in your password, you can gdb attach and continue. + </P +><P +> Some useful samba commands worth investigating: + </P +><P +></P +><UL +><LI +><P +>testparam | more</P +></LI +><LI +><P +>smbclient -L //{netbios name of server}</P +></LI +></UL +><P +> An SMB enabled version of tcpdump is available from + <A +HREF="http://www.tcpdump.org/" +TARGET="_top" +>http://www.tcpdup.org/</A +>. + Ethereal, another good packet sniffer for Unix and Win32 + hosts, can be downloaded from <A +HREF="http://www.ethereal.com/" +TARGET="_top" +>http://www.ethereal.com</A +>. + </P +><P +> For tracing things on the Microsoft Windows NT, Network Monitor + (aka. netmon) is available on the Microsoft Developer Network CD's, + the Windows NT Server install CD and the SMS CD's. The version of + netmon that ships with SMS allows for dumping packets between any two + computers (i.e. placing the network interface in promiscuous mode). + The version on the NT Server install CD will only allow monitoring + of network traffic directed to the local NT box and broadcasts on the + local subnet. Be aware that Ethereal can read and write netmon + formatted files. + </P +></LI +><LI +><P +> <I +CLASS="EMPHASIS" +>How do I install 'Network Monitor' on an NT Workstation + or a Windows 9x box?</I +> + </P +><P +> Installing netmon on an NT workstation requires a couple + of steps. The following are for installing Netmon V4.00.349, which comes + with Microsoft Windows NT Server 4.0, on Microsoft Windows NT + Workstation 4.0. The process should be similar for other version of + Windows NT / Netmon. You will need both the Microsoft Windows + NT Server 4.0 Install CD and the Workstation 4.0 Install CD. + </P +><P +> Initially you will need to install 'Network Monitor Tools and Agent' + on the NT Server. To do this + </P +><P +></P +><UL +><LI +><P +>Goto Start - Settings - Control Panel - + Network - Services - Add </P +></LI +><LI +><P +>Select the 'Network Monitor Tools and Agent' and + click on 'OK'.</P +></LI +><LI +><P +>Click 'OK' on the Network Control Panel. + </P +></LI +><LI +><P +>Insert the Windows NT Server 4.0 install CD + when prompted.</P +></LI +></UL +><P +> At this point the Netmon files should exist in + <TT +CLASS="FILENAME" +>%SYSTEMROOT%\System32\netmon\*.*</TT +>. + Two subdirectories exist as well, <TT +CLASS="FILENAME" +>parsers\</TT +> + which contains the necessary DLL's for parsing the netmon packet + dump, and <TT +CLASS="FILENAME" +>captures\</TT +>. + </P +><P +> In order to install the Netmon tools on an NT Workstation, you will + first need to install the 'Network Monitor Agent' from the Workstation + install CD. + </P +><P +></P +><UL +><LI +><P +>Goto Start - Settings - Control Panel - + Network - Services - Add</P +></LI +><LI +><P +>Select the 'Network Monitor Agent' and click + on 'OK'.</P +></LI +><LI +><P +>Click 'OK' on the Network Control Panel. + </P +></LI +><LI +><P +>Insert the Windows NT Workstation 4.0 install + CD when prompted.</P +></LI +></UL +><P +> Now copy the files from the NT Server in %SYSTEMROOT%\System32\netmon\*.* + to %SYSTEMROOT%\System32\netmon\*.* on the Workstation and set + permissions as you deem appropriate for your site. You will need + administrative rights on the NT box to run netmon. + </P +><P +> To install Netmon on a Windows 9x box install the network monitor agent + from the Windows 9x CD (\admin\nettools\netmon). There is a readme + file located with the netmon driver files on the CD if you need + information on how to do this. Copy the files from a working + Netmon installation. + </P +></LI +><LI +><P +> The following is a list if helpful URLs and other links: + </P +><P +></P +><UL +><LI +><P +>Home of Samba site <A +HREF="http://samba.org" +TARGET="_top" +> http://samba.org</A +>. We have a mirror near you !</P +></LI +><LI +><P +> The <I +CLASS="EMPHASIS" +>Development</I +> document + on the Samba mirrors might mention your problem. If so, + it might mean that the developers are working on it.</P +></LI +><LI +><P +>See how Scott Merrill simulates a BDC behavior at + <A +HREF="http://www.skippy.net/linux/smb-howto.html" +TARGET="_top" +> http://www.skippy.net/linux/smb-howto.html</A +>. </P +></LI +><LI +><P +>Although 2.0.7 has almost had its day as a PDC, David Bannon will + keep the 2.0.7 PDC pages at <A +HREF="http://bioserve.latrobe.edu.au/samba" +TARGET="_top" +> http://bioserve.latrobe.edu.au/samba</A +> going for a while yet.</P +></LI +><LI +><P +>Misc links to CIFS information + <A +HREF="http://samba.org/cifs/" +TARGET="_top" +>http://samba.org/cifs/</A +></P +></LI +><LI +><P +>NT Domains for Unix <A +HREF="http://mailhost.cb1.com/~lkcl/ntdom/" +TARGET="_top" +> http://mailhost.cb1.com/~lkcl/ntdom/</A +></P +></LI +><LI +><P +>FTP site for older SMB specs: + <A +HREF="ftp://ftp.microsoft.com/developr/drg/CIFS/" +TARGET="_top" +> ftp://ftp.microsoft.com/developr/drg/CIFS/</A +></P +></LI +></UL +></LI +></UL +><P +></P +><UL +><LI +><P +> <I +CLASS="EMPHASIS" +>How do I get help from the mailing lists?</I +> + </P +><P +> There are a number of Samba related mailing lists. Go to <A +HREF="http://samba.org" +TARGET="_top" +>http://samba.org</A +>, click on your nearest mirror + and then click on <B +CLASS="COMMAND" +>Support</B +> and then click on <B +CLASS="COMMAND" +> Samba related mailing lists</B +>. + </P +><P +> For questions relating to Samba TNG go to + <A +HREF="http://www.samba-tng.org/" +TARGET="_top" +>http://www.samba-tng.org/</A +> + It has been requested that you don't post questions about Samba-TNG to the + main stream Samba lists.</P +><P +> If you post a message to one of the lists please observe the following guide lines : + </P +><P +></P +><UL +><LI +><P +> Always remember that the developers are volunteers, they are + not paid and they never guarantee to produce a particular feature at + a particular time. Any time lines are 'best guess' and nothing more. + </P +></LI +><LI +><P +> Always mention what version of samba you are using and what + operating system its running under. You should probably list the + relevant sections of your smb.conf file, at least the options + in [global] that affect PDC support.</P +></LI +><LI +><P +>In addition to the version, if you obtained Samba via + CVS mention the date when you last checked it out.</P +></LI +><LI +><P +> Try and make your question clear and brief, lots of long, + convoluted questions get deleted before they are completely read ! + Don't post html encoded messages (if you can select colour or font + size its html).</P +></LI +><LI +><P +> If you run one of those nifty 'I'm on holidays' things when + you are away, make sure its configured to not answer mailing lists. + </P +></LI +><LI +><P +> Don't cross post. Work out which is the best list to post to + and see what happens, i.e. don't post to both samba-ntdom and samba-technical. + Many people active on the lists subscribe to more + than one list and get annoyed to see the same message two or more times. + Often someone will see a message and thinking it would be better dealt + with on another, will forward it on for you.</P +></LI +><LI +><P +>You might include <I +CLASS="EMPHASIS" +>partial</I +> + log files written at a debug level set to as much as 20. + Please don't send the entire log but enough to give the context of the + error messages.</P +></LI +><LI +><P +>(Possibly) If you have a complete netmon trace ( from the opening of + the pipe to the error ) you can send the *.CAP file as well.</P +></LI +><LI +><P +>Please think carefully before attaching a document to an email. + Consider pasting the relevant parts into the body of the message. The samba + mailing lists go to a huge number of people, do they all need a copy of your + smb.conf in their attach directory?</P +></LI +></UL +></LI +><LI +><P +> <I +CLASS="EMPHASIS" +>How do I get off the mailing lists?</I +> + </P +><P +>To have your name removed from a samba mailing list, go to the + same place you went to to get on it. Go to <A +HREF="http://lists.samba.org/" +TARGET="_top" +>http://lists.samba.org</A +>, + click on your nearest mirror and then click on <B +CLASS="COMMAND" +>Support</B +> and + then click on <B +CLASS="COMMAND" +> Samba related mailing lists</B +>. Or perhaps see + <A +HREF="http://lists.samba.org/mailman/roster/samba-ntdom" +TARGET="_top" +>here</A +> + </P +><P +> Please don't post messages to the list asking to be removed, you will just + be referred to the above address (unless that process failed in some way...) + </P +></LI +></UL +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN375" +>Domain Control for Windows 9x/ME</A +></H1 +><DIV +CLASS="NOTE" +><BLOCKQUOTE +CLASS="NOTE" +><P +><B +>Note: </B +>The following section contains much of the original +DOMAIN.txt file previously included with Samba. Much of +the material is based on what went into the book <I +CLASS="EMPHASIS" +>Special +Edition, Using Samba</I +>, by Richard Sharpe.</P +></BLOCKQUOTE +></DIV +><P +>A domain and a workgroup are exactly the same thing in terms of network +browsing. The difference is that a distributable authentication +database is associated with a domain, for secure login access to a +network. Also, different access rights can be granted to users if they +successfully authenticate against a domain logon server (NT server and +other systems based on NT server support this, as does at least Samba TNG now).</P +><P +>The SMB client logging on to a domain has an expectation that every other +server in the domain should accept the same authentication information. +Network browsing functionality of domains and workgroups is +identical and is explained in BROWSING.txt. It should be noted, that browsing +is totally orthogonal to logon support.</P +><P +>Issues related to the single-logon network model are discussed in this +section. Samba supports domain logons, network logon scripts, and user +profiles for MS Windows for workgroups and MS Windows 9X/ME clients +which will be the focus of this section.</P +><P +>When an SMB client in a domain wishes to logon it broadcast requests for a +logon server. The first one to reply gets the job, and validates its +password using whatever mechanism the Samba administrator has installed. +It is possible (but very stupid) to create a domain where the user +database is not shared between servers, i.e. they are effectively workgroup +servers advertising themselves as participating in a domain. This +demonstrates how authentication is quite different from but closely +involved with domains.</P +><P +>Using these features you can make your clients verify their logon via +the Samba server; make clients run a batch file when they logon to +the network and download their preferences, desktop and start menu.</P +><P +>Before launching into the configuration instructions, it is +worthwhile lookingat how a Windows 9x/ME client performs a logon:</P +><P +></P +><OL +TYPE="1" +><LI +><P +> The client broadcasts (to the IP broadcast address of the subnet it is in) + a NetLogon request. This is sent to the NetBIOS name DOMAIN<1c> at the + NetBIOS layer. The client chooses the first response it receives, which + contains the NetBIOS name of the logon server to use in the format of + \\SERVER. + </P +></LI +><LI +><P +> The client then connects to that server, logs on (does an SMBsessetupX) and + then connects to the IPC$ share (using an SMBtconX). + </P +></LI +><LI +><P +> The client then does a NetWkstaUserLogon request, which retrieves the name + of the user's logon script. + </P +></LI +><LI +><P +> The client then connects to the NetLogon share and searches for this + and if it is found and can be read, is retrieved and executed by the client. + After this, the client disconnects from the NetLogon share. + </P +></LI +><LI +><P +> The client then sends a NetUserGetInfo request to the server, to retrieve + the user's home share, which is used to search for profiles. Since the + response to the NetUserGetInfo request does not contain much more + the user's home share, profiles for Win9X clients MUST reside in the user + home directory. + </P +></LI +><LI +><P +> The client then connects to the user's home share and searches for the + user's profile. As it turns out, you can specify the user's home share as + a sharename and path. For example, \\server\fred\.profile. + If the profiles are found, they are implemented. + </P +></LI +><LI +><P +> The client then disconnects from the user's home share, and reconnects to + the NetLogon share and looks for CONFIG.POL, the policies file. If this is + found, it is read and implemented. + </P +></LI +></OL +><DIV +CLASS="SECT2" +><HR><H2 +CLASS="SECT2" +><A +NAME="AEN401" +>Configuration Instructions: Network Logons</A +></H2 +><P +>The main difference between a PDC and a Windows 9x logon +server configuration is that</P +><P +></P +><UL +><LI +><P +>Password encryption is not required for a Windows 9x logon server.</P +></LI +><LI +><P +>Windows 9x/ME clients do not possess machine trust accounts.</P +></LI +></UL +><P +>Therefore, a Samba PDC will also act as a Windows 9x logon +server.</P +><DIV +CLASS="WARNING" +><P +></P +><TABLE +CLASS="WARNING" +BORDER="1" +WIDTH="100%" +><TR +><TD +ALIGN="CENTER" +><B +>security mode and master browsers</B +></TD +></TR +><TR +><TD +ALIGN="LEFT" +><P +>There are a few comments to make in order to tie up some +loose ends. There has been much debate over the issue of whether +or not it is ok to configure Samba as a Domain Controller in security +modes other than <TT +CLASS="CONSTANT" +>USER</TT +>. The only security mode +which will not work due to technical reasons is <TT +CLASS="CONSTANT" +>SHARE</TT +> +mode security. <TT +CLASS="CONSTANT" +>DOMAIN</TT +> and <TT +CLASS="CONSTANT" +>SERVER</TT +> +mode security is really just a variation on SMB user level security.</P +><P +>Actually, this issue is also closely tied to the debate on whether +or not Samba must be the domain master browser for its workgroup +when operating as a DC. While it may technically be possible +to configure a server as such (after all, browsing and domain logons +are two distinctly different functions), it is not a good idea to +so. You should remember that the DC must register the DOMAIN#1b NetBIOS +name. This is the name used by Windows clients to locate the DC. +Windows clients do not distinguish between the DC and the DMB. +For this reason, it is very wise to configure the Samba DC as the DMB.</P +><P +>Now back to the issue of configuring a Samba DC to use a mode other +than "security = user". If a Samba host is configured to use +another SMB server or DC in order to validate user connection +requests, then it is a fact that some other machine on the network +(the "password server") knows more about user than the Samba host. +99% of the time, this other host is a domain controller. Now +in order to operate in domain mode security, the "workgroup" parameter +must be set to the name of the Windows NT domain (which already +has a domain controller, right?)</P +><P +>Therefore configuring a Samba box as a DC for a domain that +already by definition has a PDC is asking for trouble. +Therefore, you should always configure the Samba DC to be the DMB +for its domain.</P +></TD +></TR +></TABLE +></DIV +></DIV +><DIV +CLASS="SECT2" +><HR><H2 +CLASS="SECT2" +><A +NAME="AEN420" +>Configuration Instructions: Setting up Roaming User Profiles</A +></H2 +><DIV +CLASS="WARNING" +><P +></P +><TABLE +CLASS="WARNING" +BORDER="1" +WIDTH="100%" +><TR +><TD +ALIGN="CENTER" +><B +>Warning</B +></TD +></TR +><TR +><TD +ALIGN="LEFT" +><P +><I +CLASS="EMPHASIS" +>NOTE!</I +> Roaming profiles support is different +for Win9X and WinNT.</P +></TD +></TR +></TABLE +></DIV +><P +>Before discussing how to configure roaming profiles, it is useful to see how +Win9X and WinNT clients implement these features.</P +><P +>Win9X clients send a NetUserGetInfo request to the server to get the user's +profiles location. However, the response does not have room for a separate +profiles location field, only the user's home share. This means that Win9X +profiles are restricted to being in the user's home directory.</P +><P +>WinNT clients send a NetSAMLogon RPC request, which contains many fields, +including a separate field for the location of the user's profiles. +This means that support for profiles is different for Win9X and WinNT.</P +><DIV +CLASS="SECT3" +><HR><H3 +CLASS="SECT3" +><A +NAME="AEN428" +>Windows NT Configuration</A +></H3 +><P +>To support WinNT clients, in the [global] section of smb.conf set the +following (for example):</P +><P +><PRE +CLASS="PROGRAMLISTING" +>logon path = \\profileserver\profileshare\profilepath\%U\moreprofilepath</PRE +></P +><P +>The default for this option is \\%N\%U\profile, namely +\\sambaserver\username\profile. The \\N%\%U service is created +automatically by the [homes] service. +If you are using a samba server for the profiles, you _must_ make the +share specified in the logon path browseable. </P +><DIV +CLASS="NOTE" +><BLOCKQUOTE +CLASS="NOTE" +><P +><B +>Note: </B +>[lkcl 26aug96 - we have discovered a problem where Windows clients can +maintain a connection to the [homes] share in between logins. The +[homes] share must NOT therefore be used in a profile path.]</P +></BLOCKQUOTE +></DIV +></DIV +><DIV +CLASS="SECT3" +><HR><H3 +CLASS="SECT3" +><A +NAME="AEN436" +>Windows 9X Configuration</A +></H3 +><P +>To support Win9X clients, you must use the "logon home" parameter. Samba has +now been fixed so that "net use/home" now works as well, and it, too, relies +on the "logon home" parameter.</P +><P +>By using the logon home parameter, you are restricted to putting Win9X +profiles in the user's home directory. But wait! There is a trick you +can use. If you set the following in the [global] section of your +smb.conf file:</P +><P +><PRE +CLASS="PROGRAMLISTING" +>logon home = \\%L\%U\.profiles</PRE +></P +><P +>then your Win9X clients will dutifully put their clients in a subdirectory +of your home directory called .profiles (thus making them hidden).</P +><P +>Not only that, but 'net use/home' will also work, because of a feature in +Win9X. It removes any directory stuff off the end of the home directory area +and only uses the server and share portion. That is, it looks like you +specified \\%L\%U for "logon home".</P +></DIV +><DIV +CLASS="SECT3" +><HR><H3 +CLASS="SECT3" +><A +NAME="AEN444" +>Win9X and WinNT Configuration</A +></H3 +><P +>You can support profiles for both Win9X and WinNT clients by setting both the +"logon home" and "logon path" parameters. For example:</P +><P +><PRE +CLASS="PROGRAMLISTING" +>logon home = \\%L\%U\.profiles +logon path = \\%L\profiles\%U</PRE +></P +><DIV +CLASS="NOTE" +><BLOCKQUOTE +CLASS="NOTE" +><P +><B +>Note: </B +>I have not checked what 'net use /home' does on NT when "logon home" is +set as above.</P +></BLOCKQUOTE +></DIV +></DIV +><DIV +CLASS="SECT3" +><HR><H3 +CLASS="SECT3" +><A +NAME="AEN451" +>Windows 9X Profile Setup</A +></H3 +><P +>When a user first logs in on Windows 9X, the file user.DAT is created, +as are folders "Start Menu", "Desktop", "Programs" and "Nethood". +These directories and their contents will be merged with the local +versions stored in c:\windows\profiles\username on subsequent logins, +taking the most recent from each. You will need to use the [global] +options "preserve case = yes", "short preserve case = yes" and +"case sensitive = no" in order to maintain capital letters in shortcuts +in any of the profile folders.</P +><P +>The user.DAT file contains all the user's preferences. If you wish to +enforce a set of preferences, rename their user.DAT file to user.MAN, +and deny them write access to this file.</P +><P +></P +><OL +TYPE="1" +><LI +><P +> On the Windows 95 machine, go to Control Panel | Passwords and + select the User Profiles tab. Select the required level of + roaming preferences. Press OK, but do _not_ allow the computer + to reboot. + </P +></LI +><LI +><P +> On the Windows 95 machine, go to Control Panel | Network | + Client for Microsoft Networks | Preferences. Select 'Log on to + NT Domain'. Then, ensure that the Primary Logon is 'Client for + Microsoft Networks'. Press OK, and this time allow the computer + to reboot. + </P +></LI +></OL +><P +>Under Windows 95, Profiles are downloaded from the Primary Logon. +If you have the Primary Logon as 'Client for Novell Networks', then +the profiles and logon script will be downloaded from your Novell +Server. If you have the Primary Logon as 'Windows Logon', then the +profiles will be loaded from the local machine - a bit against the +concept of roaming profiles, if you ask me.</P +><P +>You will now find that the Microsoft Networks Login box contains +[user, password, domain] instead of just [user, password]. Type in +the samba server's domain name (or any other domain known to exist, +but bear in mind that the user will be authenticated against this +domain and profiles downloaded from it, if that domain logon server +supports it), user name and user's password.</P +><P +>Once the user has been successfully validated, the Windows 95 machine +will inform you that 'The user has not logged on before' and asks you +if you wish to save the user's preferences? Select 'yes'.</P +><P +>Once the Windows 95 client comes up with the desktop, you should be able +to examine the contents of the directory specified in the "logon path" +on the samba server and verify that the "Desktop", "Start Menu", +"Programs" and "Nethood" folders have been created.</P +><P +>These folders will be cached locally on the client, and updated when +the user logs off (if you haven't made them read-only by then :-). +You will find that if the user creates further folders or short-cuts, +that the client will merge the profile contents downloaded with the +contents of the profile directory already on the local client, taking +the newest folders and short-cuts from each set.</P +><P +>If you have made the folders / files read-only on the samba server, +then you will get errors from the w95 machine on logon and logout, as +it attempts to merge the local and the remote profile. Basically, if +you have any errors reported by the w95 machine, check the Unix file +permissions and ownership rights on the profile directory contents, +on the samba server.</P +><P +>If you have problems creating user profiles, you can reset the user's +local desktop cache, as shown below. When this user then next logs in, +they will be told that they are logging in "for the first time".</P +><P +></P +><OL +TYPE="1" +><LI +><P +> instead of logging in under the [user, password, domain] dialog, + press escape. + </P +></LI +><LI +><P +> run the regedit.exe program, and look in: + </P +><P +> HKEY_LOCAL_MACHINE\Windows\CurrentVersion\ProfileList + </P +><P +> you will find an entry, for each user, of ProfilePath. Note the + contents of this key (likely to be c:\windows\profiles\username), + then delete the key ProfilePath for the required user. + </P +><P +> [Exit the registry editor]. + </P +></LI +><LI +><P +> <I +CLASS="EMPHASIS" +>WARNING</I +> - before deleting the contents of the + directory listed in + the ProfilePath (this is likely to be c:\windows\profiles\username), + ask them if they have any important files stored on their desktop + or in their start menu. delete the contents of the directory + ProfilePath (making a backup if any of the files are needed). + </P +><P +> This will have the effect of removing the local (read-only hidden + system file) user.DAT in their profile directory, as well as the + local "desktop", "nethood", "start menu" and "programs" folders. + </P +></LI +><LI +><P +> search for the user's .PWL password-caching file in the c:\windows + directory, and delete it. + </P +></LI +><LI +><P +> log off the windows 95 client. + </P +></LI +><LI +><P +> check the contents of the profile path (see "logon path" described + above), and delete the user.DAT or user.MAN file for the user, + making a backup if required. + </P +></LI +></OL +><P +>If all else fails, increase samba's debug log levels to between 3 and 10, +and / or run a packet trace program such as tcpdump or netmon.exe, and +look for any error reports.</P +><P +>If you have access to an NT server, then first set up roaming profiles +and / or netlogons on the NT server. Make a packet trace, or examine +the example packet traces provided with NT server, and see what the +differences are with the equivalent samba trace.</P +></DIV +><DIV +CLASS="SECT3" +><HR><H3 +CLASS="SECT3" +><A +NAME="AEN487" +>Windows NT Workstation 4.0</A +></H3 +><P +>When a user first logs in to a Windows NT Workstation, the profile +NTuser.DAT is created. The profile location can be now specified +through the "logon path" parameter. </P +><DIV +CLASS="NOTE" +><BLOCKQUOTE +CLASS="NOTE" +><P +><B +>Note: </B +>[lkcl 10aug97 - i tried setting the path to +\\samba-server\homes\profile, and discovered that this fails because +a background process maintains the connection to the [homes] share +which does _not_ close down in between user logins. you have to +have \\samba-server\%L\profile, where user is the username created +from the [homes] share].</P +></BLOCKQUOTE +></DIV +><P +>There is a parameter that is now available for use with NT Profiles: +"logon drive". This should be set to "h:" or any other drive, and +should be used in conjunction with the new "logon home" parameter.</P +><P +>The entry for the NT 4.0 profile is a _directory_ not a file. The NT +help on profiles mentions that a directory is also created with a .PDS +extension. The user, while logging in, must have write permission to +create the full profile path (and the folder with the .PDS extension) +[lkcl 10aug97 - i found that the creation of the .PDS directory failed, +and had to create these manually for each user, with a shell script. +also, i presume, but have not tested, that the full profile path must +be browseable just as it is for w95, due to the manner in which they +attempt to create the full profile path: test existence of each path +component; create path component].</P +><P +>In the profile directory, NT creates more folders than 95. It creates +"Application Data" and others, as well as "Desktop", "Nethood", +"Start Menu" and "Programs". The profile itself is stored in a file +NTuser.DAT. Nothing appears to be stored in the .PDS directory, and +its purpose is currently unknown.</P +><P +>You can use the System Control Panel to copy a local profile onto +a samba server (see NT Help on profiles: it is also capable of firing +up the correct location in the System Control Panel for you). The +NT Help file also mentions that renaming NTuser.DAT to NTuser.MAN +turns a profile into a mandatory one.</P +><DIV +CLASS="NOTE" +><BLOCKQUOTE +CLASS="NOTE" +><P +><B +>Note: </B +>[lkcl 10aug97 - i notice that NT Workstation tells me that it is +downloading a profile from a slow link. whether this is actually the +case, or whether there is some configuration issue, as yet unknown, +that makes NT Workstation _think_ that the link is a slow one is a +matter to be resolved].</P +><P +>[lkcl 20aug97 - after samba digest correspondence, one user found, and +another confirmed, that profiles cannot be loaded from a samba server +unless "security = user" and "encrypt passwords = yes" (see the file +ENCRYPTION.txt) or "security = server" and "password server = ip.address. +of.yourNTserver" are used. Either of these options will allow the NT +workstation to access the samba server using LAN manager encrypted +passwords, without the user intervention normally required by NT +workstation for clear-text passwords].</P +><P +>[lkcl 25aug97 - more comments received about NT profiles: the case of +the profile _matters_. the file _must_ be called NTuser.DAT or, for +a mandatory profile, NTuser.MAN].</P +></BLOCKQUOTE +></DIV +></DIV +><DIV +CLASS="SECT3" +><HR><H3 +CLASS="SECT3" +><A +NAME="AEN500" +>Windows NT Server</A +></H3 +><P +>There is nothing to stop you specifying any path that you like for the +location of users' profiles. Therefore, you could specify that the +profile be stored on a samba server, or any other SMB server, as long as +that SMB server supports encrypted passwords.</P +></DIV +><DIV +CLASS="SECT3" +><HR><H3 +CLASS="SECT3" +><A +NAME="AEN503" +>Sharing Profiles between W95 and NT Workstation 4.0</A +></H3 +><DIV +CLASS="WARNING" +><P +></P +><TABLE +CLASS="WARNING" +BORDER="1" +WIDTH="100%" +><TR +><TD +ALIGN="CENTER" +><B +>Potentially outdated or incorrect material follows</B +></TD +></TR +><TR +><TD +ALIGN="LEFT" +><P +>I think this is all bogus, but have not deleted it. (Richard Sharpe)</P +></TD +></TR +></TABLE +></DIV +><P +>The default logon path is \\%N\U%. NT Workstation will attempt to create +a directory "\\samba-server\username.PDS" if you specify the logon path +as "\\samba-server\username" with the NT User Manager. Therefore, you +will need to specify (for example) "\\samba-server\username\profile". +NT 4.0 will attempt to create "\\samba-server\username\profile.PDS", which +is more likely to succeed.</P +><P +>If you then want to share the same Start Menu / Desktop with W95, you will +need to specify "logon path = \\samba-server\username\profile" [lkcl 10aug97 +this has its drawbacks: i created a shortcut to telnet.exe, which attempts +to run from the c:\winnt\system32 directory. this directory is obviously +unlikely to exist on a Win95-only host].</P +><P +> If you have this set up correctly, you will find separate user.DAT and +NTuser.DAT files in the same profile directory.</P +><DIV +CLASS="NOTE" +><BLOCKQUOTE +CLASS="NOTE" +><P +><B +>Note: </B +>[lkcl 25aug97 - there are some issues to resolve with downloading of +NT profiles, probably to do with time/date stamps. i have found that +NTuser.DAT is never updated on the workstation after the first time that +it is copied to the local workstation profile directory. this is in +contrast to w95, where it _does_ transfer / update profiles correctly].</P +></BLOCKQUOTE +></DIV +></DIV +></DIV +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN513" +>DOMAIN_CONTROL.txt : Windows NT Domain Control & Samba</A +></H1 +><DIV +CLASS="WARNING" +><P +></P +><TABLE +CLASS="WARNING" +BORDER="1" +WIDTH="100%" +><TR +><TD +ALIGN="CENTER" +><B +>Possibly Outdated Material</B +></TD +></TR +><TR +><TD +ALIGN="LEFT" +><P +> This appendix was originally authored by John H Terpstra of + the Samba Team and is included here for posterity. + </P +></TD +></TR +></TABLE +></DIV +><P +><I +CLASS="EMPHASIS" +>NOTE :</I +> +The term "Domain Controller" and those related to it refer to one specific +method of authentication that can underly an SMB domain. Domain Controllers +prior to Windows NT Server 3.1 were sold by various companies and based on +private extensions to the LAN Manager 2.1 protocol. Windows NT introduced +Microsoft-specific ways of distributing the user authentication database. +See DOMAIN.txt for examples of how Samba can participate in or create +SMB domains based on shared authentication database schemes other than the +Windows NT SAM.</P +><P +>Windows NT Server can be installed as either a plain file and print server +(WORKGROUP workstation or server) or as a server that participates in Domain +Control (DOMAIN member, Primary Domain controller or Backup Domain controller). +The same is true for OS/2 Warp Server, Digital Pathworks and other similar +products, all of which can participate in Domain Control along with Windows NT.</P +><P +>To many people these terms can be confusing, so let's try to clear the air.</P +><P +>Every Windows NT system (workstation or server) has a registry database. +The registry contains entries that describe the initialization information +for all services (the equivalent of Unix Daemons) that run within the Windows +NT environment. The registry also contains entries that tell application +software where to find dynamically loadable libraries that they depend upon. +In fact, the registry contains entries that describes everything that anything +may need to know to interact with the rest of the system.</P +><P +>The registry files can be located on any Windows NT machine by opening a +command prompt and typing:</P +><P +><TT +CLASS="PROMPT" +>C:\WINNT\></TT +> dir %SystemRoot%\System32\config</P +><P +>The environment variable %SystemRoot% value can be obtained by typing:</P +><P +><TT +CLASS="PROMPT" +>C:\WINNT></TT +>echo %SystemRoot%</P +><P +>The active parts of the registry that you may want to be familiar with are +the files called: default, system, software, sam and security.</P +><P +>In a domain environment, Microsoft Windows NT domain controllers participate +in replication of the SAM and SECURITY files so that all controllers within +the domain have an exactly identical copy of each.</P +><P +>The Microsoft Windows NT system is structured within a security model that +says that all applications and services must authenticate themselves before +they can obtain permission from the security manager to do what they set out +to do.</P +><P +>The Windows NT User database also resides within the registry. This part of +the registry contains the user's security identifier, home directory, group +memberships, desktop profile, and so on.</P +><P +>Every Windows NT system (workstation as well as server) will have its own +registry. Windows NT Servers that participate in Domain Security control +have a database that they share in common - thus they do NOT own an +independent full registry database of their own, as do Workstations and +plain Servers.</P +><P +>The User database is called the SAM (Security Access Manager) database and +is used for all user authentication as well as for authentication of inter- +process authentication (i.e. to ensure that the service action a user has +requested is permitted within the limits of that user's privileges).</P +><P +>The Samba team have produced a utility that can dump the Windows NT SAM into +smbpasswd format: see ENCRYPTION.txt for information on smbpasswd and +/pub/samba/pwdump on your nearest Samba mirror for the utility. This +facility is useful but cannot be easily used to implement SAM replication +to Samba systems.</P +><P +>Windows for Workgroups, Windows 95, and Windows NT Workstations and Servers +can participate in a Domain security system that is controlled by Windows NT +servers that have been correctly configured. Almost every domain will have +ONE Primary Domain Controller (PDC). It is desirable that each domain will +have at least one Backup Domain Controller (BDC).</P +><P +>The PDC and BDCs then participate in replication of the SAM database so that +each Domain Controlling participant will have an up to date SAM component +within its registry.</P +></DIV +></DIV +></BODY +></HTML +>
\ No newline at end of file |