summaryrefslogtreecommitdiff
path: root/docs/htmldocs/Samba-PDC-HOWTO.html
diff options
context:
space:
mode:
Diffstat (limited to 'docs/htmldocs/Samba-PDC-HOWTO.html')
-rw-r--r--docs/htmldocs/Samba-PDC-HOWTO.html2284
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 ae4f545800..0000000000
--- 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]
- # &#60;...remainder of parameters...&#62;
- 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\&#62;</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&#60;1c&#62; 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
->&#13;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 &#38; 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\&#62;</TT
-> dir %SystemRoot%\System32\config</P
-><P
->The environment variable %SystemRoot% value can be obtained by typing:</P
-><P
-><TT
-CLASS="PROMPT"
->C:\WINNT&#62;</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