<formalpara><title><emphasis>The Essence of Learning:</emphasis></title>
<para>
There are many who approach MS Windows networking with incredible misconceptions.
-That's OK, because it give the rest of us plenty of opportunity to be of assistance.
+That's OK, because it gives the rest of us plenty of opportunity to be of assistance.
Those who really want help would be well advised to become familiar with information
that is already available.
</para>
</simplelist>
<para>
-Do not be put off, on the surface of it MS Windows networking seems so simple that any fool
+Do not be put off; on the surface of it MS Windows networking seems so simple that any fool
can do it. In fact, it is not a good idea to set up an MS Windows network with
inadequate training and preparation. But let's get our first indelible principle out of the
way: <emphasis>It is perfectly OK to make mistakes!</emphasis> In the right place and at
</para>
<para>
-Where is the right place to make mistakes? Only out of harms' way! If you are going to
+Where is the right place to make mistakes? Only out of harm's way! If you are going to
make mistakes, then please do this on a test network, away from users and in such a way as
to not inflict pain on others. Do your learning on a test network.
</para>
</para>
<para>
-In a word, <emphasis>Single Sign On</emphasis>, or SSO for short. This to many is the holy
+In a word, <emphasis>Single Sign On</emphasis>, or SSO for short. To many, this is the holy
grail of MS Windows NT and beyond networking. SSO allows users in a well designed network
to log onto any workstation that is a member of the domain that their user account is in
(or in a domain that has an appropriate trust relationship with the domain they are visiting)
Network clients of an MS Windows Domain security environment must be Domain members to be
able to gain access to the advanced features provided. Domain membership involves more than just
setting the workgroup name to the Domain name. It requires the creation of a Domain trust account
-for the workstation (called a machine account). Please refer to the chapter on Domain Membership
-for more information.
+for the workstation (called a machine account). Please refer to the chapter on
+<link linkend="domain-member">Domain Membership</link> for more information.
</para></note>
<para>
<listitem><para>
Introduces replaceable and multiple user account (authentication)
- back ends. In the case where the back end is placed in an LDAP database
+ back ends. In the case where the back end is placed in an LDAP database,
Samba-3 confers the benefits of a back end that can be distributed, replicated,
- and highly scalable.
+ and is highly scalable.
</para></listitem>
<listitem><para>
Implements full Unicode support. This simplifies cross locale internationalisation
- support. It also opens up the use of protocols that samba-2.2.x had but could not use due
+ support. It also opens up the use of protocols that Samba-2.2.x had but could not use due
to the need to fully support Unicode.
</para></listitem>
</itemizedlist>
Active Directory Domain Control ability that is at this time
purely experimental <emphasis>AND</emphasis> that is certain
to change as it becomes a fully supported feature some time
- during the samba-3 (or later) life cycle.
+ during the Samba-3 (or later) life cycle.
</para></listitem>
</itemizedlist>
in this chapter. The protocol for support of Windows 9x / Me style network (domain) logons
is completely different from NT4 / Win2k type domain logons and has been officially supported
for some time. These clients use the old LanMan Network Logon facilities that are supported
-in Samba since approximately the samba-1.9.15 series.
+in Samba since approximately the Samba-1.9.15 series.
</para>
<para>
Samba-3 has an implementation of group mapping between Windows NT groups
-and Unix groups (this is really quite complicated to explain in a short space) this is
-discussed more fully in a chapter dedicated to this topic..
+and Unix groups (this is really quite complicated to explain in a short space). This is
+discussed more fully in the <link linkend="groupmapping">Group Mapping</link> chapter.
</para>
<para>
-A Samba-3, like an MS Windows NT4 PDC or a Windows 200x Active Directory, needs to store
+Samba-3, like an MS Windows NT4 PDC or a Windows 200x Active Directory, needs to store
user and machine trust account information in a suitable backend data store. With Samba-3
there can be multiple back-ends for this including:
</para>
<listitem><para>
<emphasis>tdbsam</emphasis> - a binary database backend that will be
stored in the <emphasis>private</emphasis> directory in a file called
- <emphasis>passwd.tdb</emphasis>. The key benefit of this binary format
+ <emphasis>passdb.tdb</emphasis>. The key benefit of this binary format
file is that it can store binary objects that can not be accomodated
in the traditional plain text smbpasswd file. These permit the extended
account controls that MS Windows NT4 and later also have.
<listitem><para>
<emphasis>ldapsam_compat</emphasis> - An LDAP back-end that maintains backwards
compatibility with the behaviour of samba-2.2.x. You should use this in the process
- of mirgrating from samba-2.2.x to samba-3 if you do not want to rebuild your LDAP
+ of migrating from samba-2.2.x to samba-3 if you do not want to rebuild your LDAP
database.
</para></listitem>
</itemizedlist>
<title>Basics of Domain Control</title>
<para>
-Over the years public perceptions of what Domain Control really is has taken on an
-almost mystical nature. Before we branch into a brief overview of Domain Control
+Over the years, public perceptions of what Domain Control really is has taken on an
+almost mystical nature. Before we branch into a brief overview of Domain Control,
there are three basic types of domain controllers:
</para>
The <emphasis>Primary Domain Controller</emphasis> or PDC plays an important role in the MS
Windows NT4 and Windows 200x Domain Control architecture, but not in the manner that so many
expect. There is folk lore that dictates that because of it's role in the MS Windows
-network that the PDC should be the most powerful and most capable machine in the network.
+network, the PDC should be the most powerful and most capable machine in the network.
As strange as it may seem to say this here, good over all network performance dictates that
the entire infrastructure needs to be balanced. It is advisable to invest more in the Backup
Domain Controllers and Stand-Alone (or Domain Member) servers than in the PDC.
</para>
<para>
-In the case of MS Windows NT4 style domaines it is the PDC seeds the Domain Control database,
-a part of the Windows registry called the SAM (Security Accounts Management). It plays a key
+In the case of MS Windows NT4 style domains, it is the PDC seeds the Domain Control database,
+a part of the Windows registry called the SAM (Security Account Manager). It plays a key
part in NT4 type domain user authentication and in synchronisation of the domain authentication
database with Backup Domain Controllers.
</para>
<para>
New to Samba-3 is the ability to use a back-end database that holds the same type of data as
the NT4 style SAM (Security Account Manager) database (one of the registry files).
-The samba-3 SAM can be specified via the smb.conf file parameter
+The Samba-3 SAM can be specified via the smb.conf file parameter
<parameter>passwd backend</parameter> and valid options include
<emphasis>smbpasswd, tdbsam, ldapsam, nisplussam, xmlsam, mysqlsam, guest</emphasis>.
</para>
authentication requests. The BDC is biased to answer logon requests in preference to the PDC.
On a network segment that has a BDC and a PDC the BDC will be most likely to service network
logon requests. The PDC will answer network logon requests when the BDC is too busy (high load).
-A BDC can be promoted to a PDC. If the PDC is on line at the time that the BDC is promoted to
-PDC the previous PDC is automatically demoted to a BDC. With Samba-3 this is NOT an automatic
-operation, the PDB and BDC must be manually configured and changes need to be made likewise.
+A BDC can be promoted to a PDC. If the PDC is on line at the time that a BDC is promoted to
+PDC, the previous PDC is automatically demoted to a BDC. With Samba-3 this is NOT an automatic
+operation; the PDB and BDC must be manually configured and changes need to be made likewise.
</para>
<para>
-With MS Windows NT4 it is an install time decision what type of machine the server will be.
+With MS Windows NT4, it is an install time decision what type of machine the server will be.
It is possible to change the promote a BDC to a PDC and vica versa only, but the only way
to convert a domain controller to a domain member server or a stand-alone server is to
reinstall it. The install time choices offered are:
<para>
New to Samba-3 is the ability to function fully as an MS Windows NT4 style Domain Controller,
excluding the SAM replication components. However, please be aware that Samba-3 support the
-MS Windows 200x domain control protcols also.
+MS Windows 200x domain control protocols also.
</para>
<para>
At this time any appearance that Samba-3 is capable of acting as an
<emphasis>ADS Domain Controller</emphasis> is limited and experimental in nature.
-This functionality should not be used until the samba-team offers formal support for it.
+This functionality should not be used until the Samba-Team offers formal support for it.
At such a time, the documentation will be revised to duly reflect all configuration and
management requirements.
</para>
<note><para>
When running a Domain all MS Windows NT / 200x / XP Professional clients should be configured
as full Domain Members - IF A SECURE NETWORK IS WANTED. If the machine is NOT made a member of the
-Domain, then it will operate like a workgroup (stand-alone) machine. Please refer to the chapter
-on Domain Membership for information regarding HOW to make your MS Windows clients Domain members.
+Domain, then it will operate like a workgroup (stand-alone) machine. Please refer the
+<link linkend="domain-member">Domain Membership</link> chapter for information regarding
+ HOW to make your MS Windows clients Domain members.
</para></note>
<para>
<simplelist>
<member>Configuration of basic TCP/IP and MS Windows Networking</member>
<member>Correct designation of the Server Role (<parameter>security = user</parameter>)</member>
- <member>Consistent configuration of Name Resolution (See <link linkend="NetworkBrowsing">chapter on Browsing</link> and on
+ <member>Consistent configuration of Name Resolution (See chapter on <link linkend="NetworkBrowsing">Browsing</link> and on
<link linkend="integrate-ms-networks">MS Windows network Integration</link>)</member>
<member>Domain logons for Windows NT4 / 200x / XP Professional clients</member>
<member>Configuration of Roaming Profiles or explicit configuration to force local profile usage</member>
<note><para>
Roaming Profiles and System/Network policies are advanced network administration topics
-that are covered separately in this document. However, these are not necessarily specific
+that are covered in the <link linkend="ProfileMgmt">Profile Management</link> and
+<link linkend="PolicyMgmt">Policy Management</link> chapters of this document. However, these are not necessarily specific
to a Samba PDC as much as they are related to Windows NT networking concepts.
</para></note>
<itemizedlist>
<listitem><para>
- Advertises and registers itself as a Domain Controller (Through NetBIOS broadcasts
+ Registers and advertises itself as a Domain Controller (through NetBIOS broadcasts
as well as by way of name registrations either by Mailslot Broadcasts over UDP broadcast,
to a WINS server over UDP unicast, or via DNS and Active Directory)
</para></listitem>
</itemizedlist>
<para>
-For samba to provide these is rather easy to configure. Each Samba Domain Controller must provide
-the NETLOGON service which samba calls the <emphasis>domain logons</emphasis> functionality
+For Samba to provide these is rather easy to configure. Each Samba Domain Controller must provide
+the NETLOGON service which Samba calls the <emphasis>domain logons</emphasis> functionality
(after the name of the parameter in the &smb.conf; file). Additionally, one (1) server in a Samba-3
Domain must advertise itself as the domain master browser. This causes the Primary Domain Controller
to claim domain specific NetBIOS name that identifies it as a domain master browser for its given
<para>
All Domain Controllers must run the netlogon service (<emphasis>domain logons</emphasis>
-in Samba. One Domain Controller must be configured with <parameter>domain master = Yes</parameter>
-(the Primary Domain Controller)
, on ALL Backup Domain Controllers <parameter>domain master = No</parameter>
+in Samba
). One Domain Controller must be configured with <parameter>domain master = Yes</parameter>
+(the Primary Domain Controller)
; on ALL Backup Domain Controllers <parameter>domain master = No</parameter>
must be set.
</para>
domain master = (Yes on PDC, No on BDCs)
[netlogon]
- comment = Network Logon Service
+ comment = Network Logon Service
path = /var/lib/samba/netlogon
guest ok = Yes
browseable = No
</para>
<para>
-When an SMB client in a domain wishes to logon it broadcast requests for a
+When an SMB client in a domain wishes to logon, it broadcasts 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
<listitem>
<para>
- The client then connects to the NetLogon share and searches for this
+ The client then connects to the NetLogon share and searches for said script
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.
</para>
<para>
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 then
+ response to the NetUserGetInfo request does not contain much more than
the user's home share, profiles for Win9X clients MUST reside in the user
home directory.
</para>
</itemizedlist>
<para>
-A Samba PDC will act as a Windows 9x logon server, after all it does provide the
+A Samba PDC will act as a Windows 9x logon server; after all, it does provide the
network logon services that MS Windows 9x / Me expect to find.
</para>
<sect2>
<title>I cannot include a '$' in a machine name</title>
<para>
-A 'machine name' in (typically) <filename>/etc/passwd</filename>
-of the machine name with a '$' appended. FreeBSD (and other BSD
+A 'machine account', (typically) stored in <filename>/etc/passwd</filename>,
+takes the form of the machine name with a '$' appended. FreeBSD (and other BSD
systems?) won't create a user with a '$' in their name.
</para>
<para>
The problem is only in the program used to make the entry. Once made, it works perfectly.
-Create a user without the '$' using <command>vipw</command> to edit the entry, adding
-the '$'. Or create the whole entry with vipw if you like, make sure you use a unique User ID!
+Create a user without the '$'. Then use <command>vipw</command> to edit the entry, adding
+the '$'. Or create the whole entry with vipw if you like; make sure you use a unique User ID!
</para>
</sect2>
<para>
This occurs when the domain SID stored in the secrets.tdb database
is changed. The most common cause of a change in domain SID is when
-the domain name and/or the server name (netbios name) is changed.
+the domain name and/or the server name (NetBIOS name) is changed.
The only way to correct the problem is to restore the original domain
SID or remove the domain client from the domain and rejoin. The domain
SID may be reset using either the net or rpcclient utilities.
The reset or change the domain SID you can use the net command as follows:
<screen>
-<prompt>$ </prompt><userinput>net getlocalsid 'OLDNAME'</userinput>
-<prompt>$ </prompt><userinput>net setlocalsid 'SID'</userinput>
+&rootprompt;<userinput>net getlocalsid 'OLDNAME'</userinput>
+&rootprompt;<userinput>net setlocalsid 'SID'</userinput>
</screen>
</para>
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
+in both /etc/passwd and the smbpasswd file.
+</para>
+
+<para>
+Some people have also reported
that inconsistent subnet masks between the Samba server and the NT
-client have caused this problem. Make sure that these are consistent
+client can cause this problem. Make sure that these are consistent
for both client and server.
</para>
</sect2>
<para>
Enable the user accounts with <userinput>smbpasswd -e <replaceable>username</replaceable>
-</userinput>, this is normally done, as an account is created.
+</userinput>, this is normally done as an account is created.
</para>
</sect2>
<sect2>
- <title>Until a few minutes after samba has started, clients get the error "Domain Controller Unavailable"</title>
+ <title>Until a few minutes after Samba has started, clients get the error "Domain Controller Unavailable"</title>
<para>
A domain controller has to announce on the network who it is. This usually takes a while.
</para>
git.samba.org / kai / samba.git / commitdiff