mirror of
https://github.com/samba-team/samba.git
synced 2025-03-12 20:58:37 +03:00
Updatting docs further. More to come.
(This used to be commit e1c6242dbc4c448de19d61d7a39b05f0444c4fbf)
This commit is contained in:
John Terpstra
parent
a5cc68290e
commit
722791b4f8
@ -20,14 +20,13 @@
|
||||
<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 help someone.
|
||||
Those who really want help would be well advised to not make too big a fool
|
||||
of themselves by not being informed when are where the information needed is in
|
||||
fact available.
|
||||
Those who really want help would be well advised to be informed of information that
|
||||
is in fact already available.
|
||||
</para>
|
||||
</formalpara>
|
||||
|
||||
<para>
|
||||
The reader is well advised NOT to tackle this section until having first understood
|
||||
The reader is well advised NOT to tackle this section without having first understood
|
||||
and mastered some basics. MS Windows networking is not particularly forgiving of
|
||||
misconfiguration. Users of MS Windows networking are likely to complain bitterly
|
||||
of persistent niggles that may be caused by broken network or system configuration.
|
||||
@ -53,7 +52,7 @@ networking problems:
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
Now, do not be put off too much, on the surface of it MS Windows networking seems so simple
|
||||
Do not be put off too much, on the surface of it MS Windows networking seems so simple
|
||||
that any fool can do it. In fact, only a fool would set up an MS Windows network with
|
||||
inadequate training and preparation. So 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
|
||||
@ -63,126 +62,13 @@ burden on an organisation.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
So 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 harms' 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>
|
||||
|
||||
<sect1>
|
||||
<title>Background</title>
|
||||
|
||||
<sect2>
|
||||
<title>Domain Controller</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
|
||||
there are three basic types of domain controllers:
|
||||
</para>
|
||||
|
||||
<sect3>
|
||||
<title>Domain Controller Types</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>Primary Domain Controller</para></listitem>
|
||||
<listitem><para>Backup Domain Controller</para></listitem>
|
||||
<listitem><para>ADS Domain Controller</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<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.
|
||||
</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
|
||||
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 file 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 "passwd backend" and
|
||||
valid options include <emphasis> smbpasswd tdbsam ldapsam nisplussam plugin unixsam</emphasis>.
|
||||
The smbpasswd, tdbsam and ldapsam options can have a "_nua" suffix to indicate that No Unix
|
||||
Accounts need to be created. In other words, the Samba SAM will be independant of Unix/Linux
|
||||
system accounts, provided a uid range is defined from which SAM accounts can be created.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <emphasis>Backup Domain Controller</emphasis> or BDC plays a key role in servicing network
|
||||
authentication requests. The BDC is biased to answer logon requests so that 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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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>
|
||||
|
||||
<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>Stand-Alone Server - One that plays NO part is SAM synchronisation</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
With MS Windows 2000 the configuration of domain control is done after the server has been
|
||||
installed. Samba-3 is capable of acting fully as a native member of a Windows 200x server
|
||||
Active Directory domain.
|
||||
</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.
|
||||
</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<para>
|
||||
This article outlines the steps necessary for configuring Samba-3 as an MS Windows NT4 style PDC.
|
||||
It is necessary to have a working Samba server prior to implementing the PDC functionality.
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
Domain logons for Windows NT 4.0 / 200x / XP Professional clients.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
Placing Windows 9x / Me clients in user level security
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
Retrieving a list of users and groups from a Samba PDC to
|
||||
Windows 9x / Me / NT / 200x / XP Professional clients
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
Roaming Profiles
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
Network/System Policies
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
Roaming Profiles and System/Network policies are advanced network administration topics
|
||||
that are covered separately in this document.
|
||||
</para>
|
||||
</note>
|
||||
<title><Features and Benefits</title
|
||||
|
||||
<para>
|
||||
The following functionalities are new to the Samba-3 release:
|
||||
@ -227,19 +113,193 @@ MS Windows XP Home edition is NOT able to join a domain and does not permit
|
||||
the use of domain logons.</emphasis>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Samba-3 offers a complete implementation of group mapping between Windows NT groups
|
||||
and Unix groups (this is really quite complicated to explain in a short space).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Implementing a Samba PDC can basically be divided into 3 broad
|
||||
A Samba-3 PDC also has to store machine trust account information
|
||||
in a suitable backend data store. With Samba-3 there can be multiple back-ends
|
||||
for this including:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
<emphasis>smbpasswd</emphasis> - the plain ascii file stored used by
|
||||
earlier versions of Samba. This file configuration option requires
|
||||
a Unix/Linux system account for EVERY entry (ie: both for user and for
|
||||
machine accounts). This file will be located in the <emphasis>private</emphasis>
|
||||
directory (default is /usr/local/samba/lib/private or on linux /etc/samba).
|
||||
</para></listitem>
|
||||
|
||||
<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
|
||||
file is that it can store binary objects that can not be accomodated
|
||||
in the traditional plain text smbpasswd file.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
<emphasis>ldapsam</emphasis> - An LDAP based back-end. Permits the
|
||||
LDAP server to be specified. eg: ldap://localhost or ldap://frodo.murphy.com
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Read the chapter about the <link linkend="passdb">User Database</link>
|
||||
for details.</para>
|
||||
|
||||
<note><para>
|
||||
The new tdbsam and ldapsam account backends store vastly more information than
|
||||
smbpasswd is capable of. The new backend database includes capacity to specify
|
||||
per user settings for many parameters, over-riding global settings given in the
|
||||
<filename>smb.conf</filename> file. eg: logon drive, logon home, logon path, etc.
|
||||
</para></note>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<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
|
||||
there are three basic types of domain controllers:
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
<title>Domain Controller Types</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>Primary Domain Controller</para></listitem>
|
||||
<listitem><para>Backup Domain Controller</para></listitem>
|
||||
<listitem><para>ADS Domain Controller</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<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 a form of 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.
|
||||
As corny as it may seem to say this here, where good over all network performance is desired
|
||||
the entire infrastructure needs to be balanced. It may be more 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
|
||||
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
|
||||
<emphasis>passwd backend</emphasis> and valid options include
|
||||
<emphasis>smbpasswd, tdbsam, ldapsam, nisplussam, xmlsam, mysqlsam, plugin, guest</emphasis>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <emphasis>Backup Domain Controller</emphasis> or BDC plays a key role in servicing network
|
||||
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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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>
|
||||
|
||||
<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>Stand-Alone Server - One that plays NO part is SAM synchronisation</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
With MS Windows 2000 the configuration of domain control is done after the server has been
|
||||
installed. Samba-3 is capable of acting fully as a native member of a Windows 200x server
|
||||
Active Directory domain.
|
||||
</para>
|
||||
|
||||
<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.
|
||||
</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.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Preparing for Domain Control<title>
|
||||
|
||||
<para>
|
||||
The following outlines the steps necessary for configuring Samba-3 as an MS Windows NT4 style PDC.
|
||||
It is necessary to have a working Samba server prior to implementing the PDC functionality.
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
Domain logons for Windows NT 4.0 / 200x / XP Professional clients.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
Placing Windows 9x / Me clients in user level security
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
Retrieving a list of users and groups from a Samba PDC to
|
||||
Windows 9x / Me / NT / 200x / XP Professional clients
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
Roaming Profiles
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
Network/System Policies
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
Roaming Profiles and System/Network policies are advanced network administration topics
|
||||
that are covered separately in this document.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<para>
|
||||
Implementing a Samba PDC can basically be divided into 4 broad
|
||||
steps.
|
||||
</para>
|
||||
|
||||
<orderedlist numeration="arabic">
|
||||
<listitem><para>
|
||||
Configuration of basic MS Windows Networking
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
Configuring the Samba PDC
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
Creating machine trust accounts and joining clients to the domain
|
||||
Creating machine trust accounts and joining machines to the domain
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
@ -248,15 +308,16 @@ steps.
|
||||
</orderedlist>
|
||||
|
||||
<para>
|
||||
There are other minor details such as user profiles, system policies, etc...
|
||||
There are other 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.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Configuring Samba NT4 Style Domain Control</title>
|
||||
<title>Domain Control - Example Configuration</title>
|
||||
|
||||
<para>
|
||||
The first step in creating a working Samba PDC is to understand the parameters necessary
|
||||
@ -355,20 +416,13 @@ There are a couple of points to emphasize in the above configuration.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
Samba 3.0 offers a complete implementation of group mapping
|
||||
between Windows NT groups and Unix groups (this is really quite
|
||||
complicated to explain in a short space).
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
<title>Creating Machine Trust Accounts and Joining Clients to the Domain</title>
|
||||
<title>Machine Trust Accounts and Domain Membership</title>
|
||||
|
||||
<para>
|
||||
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."</para>
|
||||
A machine trust account is an account that is used to authenticate a client machine
|
||||
(rather than a user) to the Domain Controller server. In Windows terminology,
|
||||
this is known as a "Computer Account."</para>
|
||||
|
||||
<para>
|
||||
The password of a machine trust account acts as the shared secret for
|
||||
@ -387,45 +441,6 @@ Registry. The introduction of MS Windows 2000 saw the introduction of Active Dir
|
||||
the new repository for machine trust accounts.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A Samba-3 PDC also has to store machine trust account information
|
||||
in a suitable backend data store. With Samba-3 there can be multiple back-ends
|
||||
for this including:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
<emphasis>smbpasswd</emphasis> - the plain ascii file stored used by
|
||||
earlier versions of Samba. This file configuration option requires
|
||||
a Unix/Linux system account for EVERY entry (ie: both for user and for
|
||||
machine accounts). This file will be located in the <emphasis>private</emphasis>
|
||||
directory (default is /usr/local/samba/lib/private or on linux /etc/samba).
|
||||
</para></listitem>
|
||||
|
||||
<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
|
||||
file is that it can store binary objects that can not be accomodated
|
||||
in the traditional plain text smbpasswd file.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
<emphasis>ldapsam</emphasis> - An LDAP based back-end. Permits the
|
||||
LDAP server to be specified. eg: ldap://localhost or ldap://frodo.murphy.com
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Read the chapter about the <link linkend="passdb">User Database</link>
|
||||
for details.</para>
|
||||
|
||||
<note><para>
|
||||
The new tdbsam and ldapsam account backends store vastly more information than
|
||||
smbpasswd is capable of. The new backend database includes capacity to specify
|
||||
per user settings for many parameters, over-riding global settings given in the
|
||||
<filename>smb.conf</filename> file. eg: logon drive, logon home, logon path, etc.
|
||||
</para></note>
|
||||
|
||||
<para>
|
||||
A Samba PDC, however, stores each machine trust account in two parts,
|
||||
as follows:
|
||||
@ -504,7 +519,6 @@ appended to the NetBIOS name of the client or Samba will not recognize
|
||||
this as a machine trust account.
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
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
|
||||
@ -558,7 +572,8 @@ be created manually.
|
||||
</para>
|
||||
|
||||
|
||||
<para>Below is an example for a RedHat 6.2 Linux system.
|
||||
<para>
|
||||
Below is an example for a RedHat Linux system.
|
||||
</para>
|
||||
|
||||
<para><programlisting>
|
||||
@ -573,8 +588,7 @@ be created manually.
|
||||
<sect3><title>Joining the Client to the Domain</title>
|
||||
|
||||
<para>
|
||||
The procedure for joining a client to the domain varies with the
|
||||
version of Windows.
|
||||
The procedure for joining a client to the domain varies with the version of Windows.
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
@ -11,14 +11,81 @@
|
||||
This chapter provides information regarding the types of server that Samba may be
|
||||
configured to be. A Microsoft network administrator who wishes to migrate to or to
|
||||
use Samba will want to know what within a Samba context, terms familiar to MS Windows
|
||||
adminstrator mean.
|
||||
adminstrator mean. This means that it is essential also to define how critical security
|
||||
contexts function BEFORE we get into the details of how to configure the server itself.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The chapter also provides an overview of the security modes of which Samba is capable
|
||||
The chapter provides an overview of the security modes of which Samba is capable
|
||||
and how these relate to MS Windows servers and clients.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Firstly we should recognise the question so often asked, "Why would I want to use Samba?"
|
||||
So, in those chapters where the answer may be important you will see a section that highlights
|
||||
features and benefits. These may be for or against Samba.
|
||||
</para>
|
||||
|
||||
<sect1>
|
||||
<title>Samba Features and Benefits</title>
|
||||
|
||||
<para>
|
||||
Two men were walking down a dusty road, when one suddenly kicked up a small red stone. It
|
||||
hurt his toe and lodged in his sandle. He took the stone out and cursed it with a passion
|
||||
and fury fitting his anguish. The other looked at the stone and said, that is a garnet - I
|
||||
can turn that into a precious gem and some day it will make a princess very happy!
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The moral of this tale: Two men, two very different perspectives regarding the same stone.
|
||||
Like it or not, Samba is like that stone. Treated the right way and it can bring great
|
||||
pleasure, but if you are forced upon it and have no time for it's secrets then it can be
|
||||
a source of discomfort.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Samba started out as a project that sought to provide interoperability for MS Windows 3.x
|
||||
clients with a Unix server. It has grown up a lot since it's humble beginnings and now provides
|
||||
features and functionality fit for large scale deployment. It also has some warts. In sections
|
||||
like this one we will tell of both.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
So now, what features are covered in this chapter?
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
X
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
X
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
X
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
X
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
X
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
X
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
X
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Server Types</title>
|
||||
|
||||
@ -173,92 +240,6 @@ with share mode security servers. You are strongly discouraged from use of this
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Server Level Security</title>
|
||||
|
||||
<para>
|
||||
Now to review <emphasis>server level</emphasis> security. In server level security the samba
|
||||
server reports to the client that it is in user level security. The client then does a
|
||||
<emphasis>session setup</emphasis> as described earlier. The samba server takes the
|
||||
username/password that the client sends and attempts to login to the
|
||||
<emphasis>password server</emphasis> by sending exactly the same username/password that
|
||||
it got from the client. If that server is in user level security and accepts the password
|
||||
then samba accepts the clients connection. This allows the samba server to use another SMB
|
||||
server as the <emphasis>password server</emphasis>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You should also note that at the very start of all this, where the server tells the client
|
||||
what security level it is in, it also tells the client if it supports encryption. If it
|
||||
does then it supplies the client with a random cryptkey. The client will then send all
|
||||
passwords in encrypted form. Samba supports this type of encryption by default.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The parameter <emphasis>security = server</emphasis> means that Samba reports to clients that
|
||||
it is running in <emphasis>user mode</emphasis> but actually passes off all authentication
|
||||
requests to another <emphasis>user mode</emphasis> server. This requires an additional
|
||||
parameter <emphasis>password server</emphasis> that points to the real authentication server.
|
||||
That real authentication server can be another Samba server or can be a Windows NT server,
|
||||
the later natively capable of encrypted password support.
|
||||
</para>
|
||||
|
||||
<note><para>
|
||||
When Samba is running in <emphasis>server level</emphasis> security it is essential that
|
||||
the parameter <emphasis>password server</emphasis> is set to the precise netbios machine
|
||||
name of the target authentication server. Samba can NOT determine this from NetBIOS name
|
||||
lookups because the choice of the target authentication server arbitrary and can not
|
||||
be determined from a domain name. In essence a samba server that is in
|
||||
<emphasis>server level</emphasis> security is operating in what used to be known as
|
||||
workgroup mode.
|
||||
</para></note>
|
||||
|
||||
<note><para>
|
||||
<emphasis>Server level</emphasis> security is incompatible with what is known as
|
||||
<emphasis>schannel</emphasis> or <emphasis>sign and seal</emphasis> protocols. This means that
|
||||
if you want to use <emphasis>server</emphasis> level security you must disable the use of
|
||||
<emphasis>sign and seal</emphasis> on all machines on your network.
|
||||
</para></note>
|
||||
|
||||
<sect3>
|
||||
<title>Example Configuration</title>
|
||||
<para><emphasis>
|
||||
Using MS Windows NT as an authentication server
|
||||
</emphasis></para>
|
||||
|
||||
<para>
|
||||
This method involves the additions of the following parameters in the &smb.conf; file:
|
||||
</para>
|
||||
|
||||
<para><programlisting>
|
||||
encrypt passwords = Yes
|
||||
security = server
|
||||
password server = "NetBIOS_name_of_a_DC"
|
||||
</programlisting></para>
|
||||
|
||||
|
||||
<para>
|
||||
There are two ways of identifying whether or not a username and password pair was valid
|
||||
or not. One uses the reply information provided as part of the authentication messaging
|
||||
process, the other uses just an error code.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The down-side of this mode of configuration is the fact that for security reasons Samba
|
||||
will send the password server a bogus username and a bogus password and if the remote
|
||||
server fails to reject the username and password pair then an alternative mode of
|
||||
identification of validation is used. Where a site uses password lock out after a
|
||||
certain number of failed authentication attempts this will result in user lockouts.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Use of this mode of authentication does require there to be a standard Unix account
|
||||
for the user, this account can be blocked to prevent logons by other than MS Windows clients.
|
||||
</para>
|
||||
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Domain Level Security</title>
|
||||
|
||||
@ -367,6 +348,107 @@ regarding this configuration option.
|
||||
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Server Level Security</title>
|
||||
|
||||
<para>
|
||||
Server level security is a left over from the time when Samba was not capable of acting
|
||||
as a domain member server. It is highly recommended NOT to use this feature. Server level
|
||||
security has many draw backs. The draw backs include:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>Potential Account Lockout on MS Windows NT4/200x password servers</para></listitem>
|
||||
<listitem><para>Lack of assurance that the password server is the one specified</para></listitem>
|
||||
<listitem><para>Does not work with Winbind, particularly needed when storing profiles remotely</para></listitem>
|
||||
<listitem><para>This mode may open connections to the password server, and keep them open for extended periods.</para></listitem>
|
||||
<listitem><para>Security on the samba server breaks badly when the remote password server suddenly shuts down</para></listitem>
|
||||
<listitem><para>With this mode there is NO security account in the domain that the password server belongs to for the samba server.</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
In server level security the samba server reports to the client that it is in user level
|
||||
security. The client then does a <emphasis>session setup</emphasis> as described earlier.
|
||||
The samba server takes the username/password that the client sends and attempts to login to the
|
||||
<emphasis>password server</emphasis> by sending exactly the same username/password that
|
||||
it got from the client. If that server is in user level security and accepts the password
|
||||
then samba accepts the clients connection. This allows the samba server to use another SMB
|
||||
server as the <emphasis>password server</emphasis>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You should also note that at the very start of all this, where the server tells the client
|
||||
what security level it is in, it also tells the client if it supports encryption. If it
|
||||
does then it supplies the client with a random cryptkey. The client will then send all
|
||||
passwords in encrypted form. Samba supports this type of encryption by default.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The parameter <emphasis>security = server</emphasis> means that Samba reports to clients that
|
||||
it is running in <emphasis>user mode</emphasis> but actually passes off all authentication
|
||||
requests to another <emphasis>user mode</emphasis> server. This requires an additional
|
||||
parameter <emphasis>password server</emphasis> that points to the real authentication server.
|
||||
That real authentication server can be another Samba server or can be a Windows NT server,
|
||||
the later natively capable of encrypted password support.
|
||||
</para>
|
||||
|
||||
<note><para>
|
||||
When Samba is running in <emphasis>server level</emphasis> security it is essential that
|
||||
the parameter <emphasis>password server</emphasis> is set to the precise netbios machine
|
||||
name of the target authentication server. Samba can NOT determine this from NetBIOS name
|
||||
lookups because the choice of the target authentication server arbitrary and can not
|
||||
be determined from a domain name. In essence a samba server that is in
|
||||
<emphasis>server level</emphasis> security is operating in what used to be known as
|
||||
workgroup mode.
|
||||
</para></note>
|
||||
|
||||
<note><para>
|
||||
<emphasis>Server level</emphasis> security is incompatible with what is known as
|
||||
<emphasis>schannel</emphasis> or <emphasis>sign and seal</emphasis> protocols. This means that
|
||||
if you want to use <emphasis>server</emphasis> level security you must disable the use of
|
||||
<emphasis>sign and seal</emphasis> on all machines on your network.
|
||||
</para></note>
|
||||
|
||||
<sect3>
|
||||
<title>Example Configuration</title>
|
||||
<para><emphasis>
|
||||
Using MS Windows NT as an authentication server
|
||||
</emphasis></para>
|
||||
|
||||
<para>
|
||||
This method involves the additions of the following parameters in the &smb.conf; file:
|
||||
</para>
|
||||
|
||||
<para><programlisting>
|
||||
encrypt passwords = Yes
|
||||
security = server
|
||||
password server = "NetBIOS_name_of_a_DC"
|
||||
</programlisting></para>
|
||||
|
||||
|
||||
<para>
|
||||
There are two ways of identifying whether or not a username and password pair was valid
|
||||
or not. One uses the reply information provided as part of the authentication messaging
|
||||
process, the other uses just an error code.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The down-side of this mode of configuration is the fact that for security reasons Samba
|
||||
will send the password server a bogus username and a bogus password and if the remote
|
||||
server fails to reject the username and password pair then an alternative mode of
|
||||
identification of validation is used. Where a site uses password lock out after a
|
||||
certain number of failed authentication attempts this will result in user lockouts.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Use of this mode of authentication does require there to be a standard Unix account
|
||||
for the user, this account can be blocked to prevent logons by other than MS Windows clients.
|
||||
</para>
|
||||
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
|
||||
@ -2,6 +2,7 @@
|
||||
<chapterinfo>
|
||||
&author.tridge;
|
||||
&author.jelmer;
|
||||
&author.jht;
|
||||
<author><firstname>Karl</firstname><surname>Auer</surname></author>
|
||||
<!-- Isn't some of this written by others as well? -->
|
||||
|
||||
@ -19,6 +20,12 @@
|
||||
|
||||
<para>If you need to compile samba from source, check the
|
||||
<link linkend="compiling">appropriate appendix chapter</link>.</para>
|
||||
|
||||
<para>If you have already installed samba, or if your operating system
|
||||
was pre-installed with samba, then you may not need to bother with this
|
||||
chapter. On the other hand, you may want to read this chapter anyhow
|
||||
for information about updating samba.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user