networking problems:
</para>
-<itemizedlist>
- <listitem><para>Basic TCP/IP configuration</para></listitem>
- <listitem><para>NetBIOS name resolution</para></listitem>
- <listitem><para>Authentication configuration</para></listitem>
- <listitem><para>User and Group configuration</para></listitem>
- <listitem><para>Basic File and Directory Permission Control in Unix/Linux</para></listitem>
- <listitem><para>Understanding of how MS Windows clients interoperate in a network
- environment</para></listitem>
-</itemizedlist>
+<simplelist>
+ <member>Basic TCP/IP configuration</member>
+ <member>NetBIOS name resolution</member>
+ <member>Authentication configuration</member>
+ <member>User and Group configuration</member>
+ <member>Basic File and Directory Permission Control in Unix/Linux</member>
+ <member>Understanding of how MS Windows clients interoperate in a network
+ environment</member>
+</simplelist>
<para>
Do not be put off, on the surface of it MS Windows networking seems so simple that any fool
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
the right time, mistakes are the essence of learning. It is <emphasis>very much</emphasis>
-not Ok to make mistakes that cause loss of productivity and impose an avoidable financial
+not ok to make mistakes that cause loss of productivity and impose an avoidable financial
burden on an organisation.
</para>
<sect1>
<title>Features and Benefits</title>
+<para>
+<emphasis>What is the key benefit of Microsoft Domain security?</emphasis>
+</para>
+
+<para>
+In a word, <emphasis>Single Sign On</emphasis>, or SSO for short. This to many 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)
+and they will be able to log onto the network and access resources (shares, files, and printers)
+as if they are sitting at their home (personal) workstation. This is a feature of the Domain
+security protocols.
+</para>
+
+<para>
+The benefits of Domain security are fully available to those sites that deploy a Samba PDC.
+</para>
+
+<note><para>
+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.
+</para></note>
+
<para>
The following functionalities are new to the Samba-3 release:
</para>
</para></listitem>
<listitem><para>
- Adding users via the User Manager for Domains or via the Windows 200x Microsoft
- Management Console.
+ Adding users via the User Manager for Domains. This can be done on any MS Windows
+ client using the Nexus toolkit that is available from Microsoft's web site.
+ At some later date Samba-3 may get support for the use of the Microsoft Management
+ Console for user management.
</para></listitem>
<listitem><para>
there can be multiple back-ends for this including:
</para>
+<!-- FIXME: Doesn't this belong in passdb.xml ? -->
+
<itemizedlist>
<listitem><para>
<emphasis>smbpasswd</emphasis> - the plain ascii file stored used by
</itemizedlist>
<para>
-Read the chapter about the <link linkend="passdb">User Database</link> for details
+Read the chapter about <link linkend="passdb">Account Information Database</link> for details
regarding the choices available and how to configure them.
</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
-<emphasis>passwd backend</emphasis> and valid options include
-<emphasis>smbpasswd, tdbsam, ldapsam, nisplussam, xmlsam, mysqlsam, plugin, guest</emphasis>.
+<parameter>passwd backend</parameter> and valid options include
+<emphasis>smbpasswd, tdbsam, ldapsam, nisplussam, xmlsam, mysqlsam, guest</emphasis>.
</para>
<para>
</para>
<itemizedlist>
- <listitem><para>Primary Domain Controller - The one that seeds the domain SAM</para></listitem>
- <listitem><para>Backup Domain Controller - One that obtains a copy of the domain SAM</para></listitem>
- <listitem><para>Domain Member Server - One that has NO copy of the domain SAM, rather it obtains authentication from a Domain Controller for all access controls.</para></listitem>
- <listitem><para>Stand-Alone Server - One that plays NO part is SAM synchronisation, has it's own authentication database and plays no role in Domain security.</para></listitem>
+ <listitem><para><emphasis>Primary Domain Controller</emphasis> - The one that seeds the domain SAM</para></listitem>
+ <listitem><para><emphasis>Backup Domain Controller</emphasis> - One that obtains a copy of the domain SAM</para></listitem>
+ <listitem><para><emphasis>Domain Member Server</emphasis> - One that has NO copy of the domain SAM, rather it obtains authentication from a Domain Controller for all access controls.</para></listitem>
+ <listitem><para><emphasis>Stand-Alone Server</emphasis> - One that plays NO part is SAM synchronisation, has it's own authentication database and plays no role in Domain security.</para></listitem>
</itemizedlist>
<para>
</para>
<para>
-At this time Samba-3 is capable of acting as an <emphasis>ADS Domain Controller</emphasis> but
-in only a limited and experimental manner. This functionality should not be depended upon
-until the samba-team offers formal support for it. At such a time, the documentation will
-be revised to duely reflect all configuration and management requirements.
+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.
+At such a time, the documentation will be revised to duely reflect all configuration and
+management requirements.
</para>
</sect2>
<para>
There are two ways that MS Windows machines may interact with each other, with other servers,
-and with Domain Controllers: Either as <empahsis>Stand-Alone</emphasis> systems, more commonly
-called <empasis>Workgroup members</emphasis>, or as full participants in a security system,
-more commonly called <emphasis>Domain Members</emphasis>.
+and with Domain Controllers: Either as <emphasis>Stand-Alone</emphasis> systems, more commonly
+called <emphasis>Workgroup</emphasis> members, or as full participants in a security system,
+more commonly called <emphasis>Domain</emphasis> members.
</para>
<para>
-It should be noted that <emphasis>Workgroup membership</emphasis> involve no special configuration
+It should be noted that <emphasis>Workgroup</emphasis> membership involve no special configuration
other than the machine being configured so that the network configuration has a commonly used name
for it's workgroup entry. It is not uncommon for the name WORKGROUP to be used for this. With this
-mode of configuration there are NO machine trust accounts and any concept of "membership" as such
+mode of configuration there are NO machine trust accounts and any concept of membership as such
is limited to the fact that all machines appear in the network neighbourhood to be logically
-groupped together.
+groupped together. Again, just to be clear: <strong>workgroup mode does not involve any security machine
+accounts</strong>.
</para>
<para>
-The following are necessary for configuring Samba-3 as an MS Windows NT4 style PDC for MS Windows
-NT4 / 200x / XP clients.
+Domain member machines have a machine account in the Domain accounts database. A special procedure
+must be followed on each machine to affect Domain membership. This procedure, which can be done
+only by the local machine Administrator account, will create the Domain machine account (if
+if does not exist), and then initializes that account. When the client first logs onto the
+Domain it triggers a machine password change.
</para>
-<orderedlist numeration="arabic">
- <listitem><para>
- Configuration of basic TCP/IP and MS Windows Networking
- </para></listitem>
-
- <listitem><para>
- Correct designation of the Server Role (<emphasis>security = user</emphasis>)
- </para></listitem>
-
- <listitem><para>
- Consistent configuration of Name Resolution (See chapter on Browsing and on
- MS Windows network Integration)
- </para></listitem>
-
- <listitem><para>
- Domain logons for Windows NT4 / 200x / XP Professional clients
- </para></listitem>
-
- <listitem><para>
- Configuration of Roaming Profiles or explicit configuration to force local profile usage
- </para></listitem>
-
- <listitem><para>
- Configuration of Network/System Policies
- </para></listitem>
+<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.
+</para></note>
- <listitem><para>
- Adding and managing domain user accounts
- </para></listitem>
+<para>
+The following are necessary for configuring Samba-3 as an MS Windows NT4 style PDC for MS Windows
+NT4 / 200x / XP clients.
+</para>
- <listitem><para>
- Configuring MS Windows client machines to become domain members
- </para></listitem>
-</orderedlist>
+<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
+ <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>
+ <member>Configuration of Network/System Policies</member>
+ <member>Adding and managing domain user accounts</member>
+ <member>Configuring MS Windows client machines to become domain members</member>
+</simplelist>
<para>
The following provisions are required to serve MS Windows 9x / Me Clients:
</para>
-<orderedlist>
- <listitem><para>
- Configuration of basic TCP/IP and MS Windows Networking
- </para></listitem>
-
- <listitem><para>
- Correct designation of the Server Role (<emphasis>security = user</emphasis>)
- </para></listitem>
-
- <listitem><para>
- Network Logon Configuration (Since Windows 9x / XP Home are not technically domain
- members, they do not really particpate in the security aspects of Domain logons as such)
- </para></listitem>
-
- <listitem><para>
- Roaming Profile Configuration
- </para></listitem>
-
- <listitem><para>
- Configuration of System Policy handling
- </para></listitem>
-
- <listitem><para>
- Installation of the Network driver "Client for MS Windows Networks" and configuration
- to log onto the domain
- </para></listitem>
-
- <listitem><para>
- Placing Windows 9x / Me clients in user level security - if it is desired to allow
- all client share access to be controlled according to domain user / group identities.
- </para></listitem>
-
- <listitem><para>
- Adding and managing domain user accounts
- </para></listitem>
-</orderedlist>
+<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>Network Logon Configuration (Since Windows 9x / XP Home are not technically domain
+ members, they do not really particpate in the security aspects of Domain logons as such)</member>
+ <member>Roaming Profile Configuration</member>
+ <member>Configuration of System Policy handling</member>
+ <member>Installation of the Network driver "Client for MS Windows Networks" and configuration
+ to log onto the domain</member>
+ <member>Placing Windows 9x / Me clients in user level security - if it is desired to allow
+ all client share access to be controlled according to domain user / group identities.</member>
+ <member>Adding and managing domain user accounts</member>
+</simplelist>
<note><para>
Roaming Profiles and System/Network policies are advanced network administration topics
; security settings (must user security = user)
<ulink url="smb.conf.5.html#SECURITYEQUALSUSER">security</ulink> = user
- ; encrypted passwords are a requirement for a PDC
+ ; encrypted passwords are a requirement for a PDC (default = Yes)
<ulink url="smb.conf.5.html#ENCRYPTPASSWORDS">encrypt passwords</ulink> = yes
; support domain logons
<itemizedlist>
<listitem><para>
Encrypted passwords must be enabled. For more details on how
- to do this, refer to <link linkend="passdb">the User Database chapter</link>.
+ to do this, refer to <link linkend="passdb">Account Information Database chapter</link>.
</para></listitem>
<listitem><para>
The server must support domain logons and have a
- <filename>[netlogon]</filename> share
+ <parameter>[netlogon]</parameter> share
</para></listitem>
<listitem><para>
<title>Samba ADS Domain Control</title>
<para>
-Samba-3 can behave and appear to MS Windows 200x and XP clients as an Active Directory Server.
-To do this, Configure samba as a Primary Domain Controller, use LDAP as the passdb backend,
-and configure Kerberos5. The problem with doing this is that samba-3 is NOT, despite this
-configuration, and Active Directory server and does NOT yet fully support all protocols needed
-to make this a possibility.
-</para>
-
-<para>
-The best advice we can give at this time is - DO NOT DO THIS yet as it is NOT ready for
-production deployment.
+Samba-3 is not and can not act as an Active Directory Server. It can not truely function as
+an Active Directory Primary Domain Controller. The protocols for some of the functionality
+the Active Directory Domain Controllers is have been partially implemented on an experiemental
+only basis. Please do NOT expect Samba-3 to support these protocols - nor should you depend
+on any such functionality either now or in the future. The Samba-Team may well remove such
+experiemental features or may change their behaviour.
</para>
</sect1>
<para>
All Domain Controllers must run the netlogon service (<emphasis>domain logons</emphasis>
-in Samba. One Domain Controller must be configured with <emphasis>domain master = Yes</emphasis>
-(the Primary Domain Controller), on ALL Backup Domain Controllers <emphasis>domain master = No</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>
must be set.
</para>
+<sect3>
<title>Example Configuration</title>
<programlisting>
-<title> A minimal configuration to support Domain Logons</title>
-<para>
[globals]
domain logons = Yes
domain master = (Yes on PDC, No on BDCs)
path = /var/lib/samba/netlogon
guest ok = Yes
browseable = No
-</para>
</programlisting>
+</sect3>
<sect3>
-<title>The Special Case of Windows 9x / Me / XP Home</title>
+<title>The Special Case of MS Windows XP Home Edition</title>
+
+<note><para>
+MS Windows XP Home Edition does not have the ability to join any type of Domain
+security facility. Unlike, MS Windows 9x / Me, MS Windows XP Home Edition also completely
+lacks the ability to log onto a network.
+</para></note>
+
+<para>
+To be completely clear: If you want MS Windows XP Home Edition to integrate with your
+MS Windows NT4 or Active Directory Domain security understand - IT CAN NOT BE DONE.
+Your only choice is to buy the upgrade pack from MS Windows XP Home Edition to
+MS Windows XP Professional.
+</para>
+
+<para>
+Now that this has been said, please do NOT ask the mailing list, or email any of the
+Samba-Team members with your questions asking how to make this work. It can't be done.
+</para>
+
+</sect3>
+
+<sect3>
+<title>The Special Case of Windows 9x / Me</title>
<para>
A domain and a workgroup are exactly the same thing in terms of network
<listitem>
<para>
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
+ 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.
+ <filename>\\SERVER</filename>.
</para>
</listitem>
<para>
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\.winprofile.
+ a sharename and path. For example, <filename>\\server\fred\.winprofile</filename>.
If the profiles are found, they are implemented.
</para>
</listitem>
<listitem>
<para>
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
+ the NetLogon share and looks for <filename>CONFIG.POL</filename>, the policies file. If this is
found, it is read and implemented.
</para>
</listitem>
<itemizedlist>
<listitem><para>
- Password encryption is not required for a Windows 9x logon server.
+ Password encryption is not required for a Windows 9x logon server. But note
+ that beginning with MS Windows 98 the default setting is that plain-text
+ password support has been disabled. It can be re-enabled with the registry
+ changes that are documented in the chapter on Policies.
</para></listitem>
<listitem><para>
- Windows 9x/ME clients do not possess machine trust accounts.
+ Windows 9x/ME clients do not require and do not use machine trust accounts.
</para></listitem>
</itemizedlist>
<para>
-A Samba PDC will also act as a Windows 9x logon server.
+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>
</sect3>
modes other than <constant>USER</constant>. The only security mode
which will not work due to technical reasons is <constant>SHARE</constant>
mode security. <constant>DOMAIN</constant> and <constant>SERVER</constant>
-mode security is really just a variation on SMB user level security.
+mode security are really just a variation on SMB user level security.
</para>
<para>
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 do
-so. You should remember that the DC must register the DOMAIN#1b NetBIOS
+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.
<para>
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
+than <parameter>security = user</parameter>. 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 the user than the Samba host.
+(the <parameter>password server</parameter>) knows more about the 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
+in order to operate in domain mode security, the <parameter>workgroup</parameter> parameter
must be set to the name of the Windows NT domain (which already
-has a domain controller, right?)
+has a domain controller). If the domain does NOT already have a Domain Controller
+then you do not yet have a Domain!
</para>
<para>
-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 and set <emphasis>security = user</emphasis>. This is the only
-officially supported mode of operation.
+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 and set <parameter>security = user</parameter>.
+This is the only officially supported mode of operation.
</para>
</sect2>
will remove all network drive connections:
</para>
-<para>
-<prompt>C:\WINNT\></prompt> <command>net use * /d</command>
-</para>
+<screen>
+ <prompt>C:\WINNT\></prompt> <userinput>net use * /d</userinput>
+</screen>
<para>
Further, if the machine is already a 'member of a workgroup' that
<title>The system can not log you on (C000019B)....</title>
<para>I joined the domain successfully but after upgrading
-to a newer version of the Samba code I get the message, "The system
+to a newer version of the Samba code I get the message, <errorname>The system
can not log you on (C000019B), Please try again or consult your
-system administrator" when attempting to logon.
+system administrator</errorname> when attempting to logon.
</para>
<para>
<para>
The reset or change the domain SID you can use the net command as follows:
-<programlisting>
- net getlocalsid 'OLDNAME'
- net setlocalsid 'SID'
-</programlisting>
+<screen>
+<prompt>$ </prompt><userinput>net getlocalsid 'OLDNAME'</userinput>
+<prompt>$ </prompt><userinput>net setlocalsid 'SID'</userinput>
+</screen>
</para>
</sect2>
exist or is not accessible.</title>
<para>
-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
+When I try to join the domain I get the message <errorname>The machine account
+for this computer either does not exist or is not accessible</errorname>. What's
wrong?
</para>
I get a message about my account being disabled.</title>
<para>
-At first be ensure to enable the useraccounts with <command>smbpasswd -e
-%user%</command>, this is normally done, when you create an account.
+Enable the user accounts with <userinput>smbpasswd -e <replaceable>username</replaceable>
+</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>
+ <para>
+ A domain controller has to announce on the network who it is. This usually takes a while.
+ </para>
+</sect2>
+
</sect1>
</chapter>
git.samba.org / sfrench / samba-autobuild / .git / blobdiff