diff options
Diffstat (limited to 'docs/htmldocs/Samba-PDC-HOWTO.html')
| -rw-r--r-- | docs/htmldocs/Samba-PDC-HOWTO.html | 2284 |
1 files changed, 0 insertions, 2284 deletions
diff --git a/docs/htmldocs/Samba-PDC-HOWTO.html b/docs/htmldocs/Samba-PDC-HOWTO.html deleted file mode 100644 index 58f3989b4f0..00000000000 --- a/docs/htmldocs/Samba-PDC-HOWTO.html +++ /dev/null @@ -1,2284 +0,0 @@ -<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 |