mirror of
https://github.com/samba-team/samba.git
synced 2024-12-24 21:34:56 +03:00
42a2365323
Thanks to Hermann Gausterer <git-samba-2012@mrq1.org> for reporting! Karolin Autobuild-User(master): Volker Lendecke <vl@samba.org> Autobuild-Date(master): Mon Dec 3 12:36:14 CET 2012 on sn-devel-104
1165 lines
58 KiB
XML
1165 lines
58 KiB
XML
<?xml version="1.0" encoding="iso-8859-1"?>
|
|
<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
|
|
<chapter id="samba-pdc">
|
|
|
|
<chapterinfo>
|
|
&author.jht;
|
|
&author.jerry;
|
|
&author.dbannon;
|
|
<author>&person.gd; <contrib>LDAP updates</contrib></author>
|
|
</chapterinfo>
|
|
|
|
<title>Domain Control</title>
|
|
|
|
<para>
|
|
There are many who approach MS Windows networking with incredible misconceptions.
|
|
That's okay, because it gives the rest of us plenty of opportunity to be of assistance.
|
|
Those who really want help are well advised to become familiar with information
|
|
that is already available.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>domain</primary><secondary>controller</secondary></indexterm>
|
|
You are 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
|
|
of persistent niggles that may be caused by a broken network configuration.
|
|
To a great many people, however, MS Windows networking starts with a domain controller
|
|
that in some magical way is expected to solve all network operational ills.
|
|
</para>
|
|
|
|
<para>
|
|
<link linkend="domain-example">The Example Domain Illustration</link> shows a typical MS Windows domain security
|
|
network environment. Workstations A, B, and C are representative of many physical MS Windows
|
|
network clients.
|
|
</para>
|
|
|
|
<figure id="domain-example">
|
|
<title>An Example Domain.</title>
|
|
<imagefile scale="40">domain</imagefile>
|
|
</figure>
|
|
|
|
<para>
|
|
From the Samba mailing list we can readily identify many common networking issues.
|
|
If you are not clear on the following subjects, then it will do much good to read the
|
|
sections of this HOWTO that deal with it. These are the most common causes of MS Windows
|
|
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 how MS Windows clients interoperate in a network environment.</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
Do not be put off; on the surface of it MS Windows networking seems so simple that anyone
|
|
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 okay to make mistakes!</emphasis> In the right place and at
|
|
the right time, mistakes are the essence of learning. It is very much not okay to make
|
|
mistakes that cause loss of productivity and impose an avoidable financial burden on an
|
|
organization.
|
|
</para>
|
|
|
|
<para>
|
|
Where is the right place to make mistakes? Only out of harms way. If you are going to
|
|
make mistakes, then please do it 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>Features and Benefits</title>
|
|
|
|
<para>
|
|
<indexterm><primary>domain security</primary></indexterm>
|
|
<emphasis>What is the key benefit of Microsoft Domain Security?</emphasis>
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>single sign-on</primary><see>SSO</see></indexterm>
|
|
<indexterm><primary>trust</primary></indexterm>
|
|
<indexterm><primary>account</primary></indexterm>
|
|
<indexterm><primary>domain</primary><secondary>security</secondary><tertiary>protocols</tertiary></indexterm>
|
|
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 contains their user account (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>
|
|
<indexterm><primary>SID</primary></indexterm>
|
|
<indexterm><primary>RID</primary></indexterm>
|
|
<indexterm><primary>relative identifier</primary><see>RID</see></indexterm>
|
|
<indexterm><primary>security identifier</primary><see>SID</see></indexterm>
|
|
<indexterm><primary>access control</primary></indexterm>
|
|
The benefits of domain security are available to those sites that deploy a Samba PDC. A domain provides a
|
|
unique network security identifier (SID). Domain user and group security identifiers are comprised of the
|
|
network SID plus a relative identifier (RID) that is unique to the account. User and group SIDs (the network
|
|
SID plus the RID) can be used to create access control lists (ACLs) attached to network resources to provide
|
|
organizational access control. UNIX systems recognize only local security identifiers.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>SID</primary></indexterm>
|
|
A SID represents a security context. For example, every Windows machine has local accounts within the security
|
|
context of the local machine which has a unique SID. Every domain (NT4, ADS, Samba) contains accounts that
|
|
exist within the domain security context which is defined by the domain SID.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>SID</primary></indexterm>
|
|
<indexterm><primary>RID</primary></indexterm>
|
|
A domain member server will have a SID that differs from the domain SID. The domain member server can be
|
|
configured to regard all domain users as local users. It can also be configured to recognize domain users and
|
|
groups as non-local. SIDs are persistent. A typical domain of user SID looks like this:
|
|
<screen>
|
|
S-1-5-21-726309263-4128913605-1168186429
|
|
</screen>
|
|
Every account (user, group, machine, trust, etc.) is assigned a RID. This is done automatically as an account
|
|
is created. Samba produces the RID algorithmically. The UNIX operating system uses a separate name space for
|
|
user and group identifiers (the UID and GID) but Windows allocates the RID from a single name space. A Windows
|
|
user and a Windows group can not have the same RID. Just as the UNIX user <literal>root</literal> has the
|
|
UID=0, the Windows Administrator has the well-known RID=500. The RID is catenated to the Windows domain SID,
|
|
so Administrator account for a domain that has the above SID will have the user SID
|
|
<screen>
|
|
S-1-5-21-726309263-4128913605-1168186429-500
|
|
</screen>
|
|
The result is that every account in the Windows networking world has a globally unique security identifier.
|
|
</para>
|
|
|
|
<note><para>
|
|
<indexterm><primary>domain</primary><secondary>member</secondary></indexterm>
|
|
<indexterm><primary>machine account</primary></indexterm>
|
|
<indexterm><primary>domain</primary><secondary>trust account</secondary></indexterm>
|
|
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). Refer to <link linkend="domain-member">Domain Membership</link> for more information.
|
|
</para></note>
|
|
|
|
<para>
|
|
The following functionalities are an overview of some of the features
|
|
in the Samba-4 release:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>
|
|
<indexterm><primary>account</primary><secondary>backend</secondary></indexterm>
|
|
Samba-4 supports the use of a choice of backends that may be used in which user, group and machine
|
|
accounts may be stored, but only when acting as a classic
|
|
(NT4) domain controller,
|
|
but not when it is acting as an Active Directory Domain Controller.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>LDAP</primary></indexterm>
|
|
<indexterm><primary>replicated</primary></indexterm>
|
|
<indexterm><primary>distributed</primary></indexterm>
|
|
<indexterm><primary>scalability</primary></indexterm>
|
|
<indexterm><primary>reliability</primary></indexterm>
|
|
An LDAP passdb backend confers the benefit that the account backend can be distributed and replicated,
|
|
which is of great value because it confers scalability and
|
|
provides a high degree of reliability. This may be used when
|
|
Samba-4 is acting as an classic (NT4-like) domain controller,
|
|
but not when it is acting as an Active Directory Domain Controller.
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
<indexterm><primary>interdomain</primary><secondary>trust</secondary><tertiary>account</tertiary></indexterm>
|
|
<indexterm><primary>trust account</primary><secondary>interdomain</secondary></indexterm>
|
|
<indexterm><primary>interoperability</primary></indexterm>
|
|
Windows NT4 domain trusts. Samba-4 supports workstation and server (machine) trust accounts. It also
|
|
supports Windows NT4 style interdomain trust accounts, which further assists in network scalability
|
|
and interoperability, but only when itself is an classic
|
|
(NT4-like) domain controller.
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
<indexterm><primary>NetBIOS</primary></indexterm>
|
|
<indexterm><primary>raw SMB</primary></indexterm>
|
|
<indexterm><primary>active directory</primary></indexterm>
|
|
<indexterm><primary>domain</primary><secondary>member server</secondary></indexterm>
|
|
<indexterm><primary>domain</primary><secondary>controller</secondary></indexterm>
|
|
<indexterm><primary>network</primary><secondary>browsing</secondary></indexterm>
|
|
Operation without NetBIOS over TCP/IP, rather using the raw SMB over TCP/IP. Note, this is feasible
|
|
only when operating as a Microsoft active directory domain
|
|
member server. When acting as a Samba classic (NT4-like) domain
|
|
controller the use of NetBIOS is necessary to provide network browsing support.
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
<indexterm><primary>WINS</primary></indexterm>
|
|
<indexterm><primary>TCP port</primary></indexterm>
|
|
<indexterm><primary>session services</primary></indexterm>
|
|
Samba-4 provides NetBIOS name services (WINS), NetBIOS over TCP/IP (TCP port 139) session services, SMB over
|
|
TCP/IP (TCP port 445) session services, and Microsoft compatible ONC DCE RPC services (TCP port 135)
|
|
services.
|
|
</para></listitem>
|
|
|
|
|
|
<listitem><para>
|
|
<indexterm><primary>kerberos</primary></indexterm>
|
|
<indexterm><primary>active directory</primary></indexterm>
|
|
Acting as a Windows 2000 active directory domain controller
|
|
(i.e., Kerberos and Active Directory).
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
<indexterm><primary>MMC</primary></indexterm>
|
|
<indexterm><primary>SVRTOOLS.EXE</primary></indexterm>
|
|
<indexterm><primary>Microsoft management console</primary><see>MMC</see></indexterm>
|
|
The Windows 200x/XP Microsoft Management Console (MMC) can be
|
|
used to manage a Samba-4 server, when it is an Active
|
|
Directory Domain Controller. When acting as a classic (NT4)
|
|
domain controller, you
|
|
can use only the MS Windows NT4 Domain Server Manager and the MS Windows NT4 Domain User Manager. Both are
|
|
part of the SVRTOOLS.EXE package mentioned later.
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
The following functionalities are not provided by Samba-4:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>
|
|
<indexterm><primary>SAM</primary></indexterm>
|
|
<indexterm><primary>replication</primary></indexterm>
|
|
SAM replication with Windows NT4 domain controllers (i.e., a Samba PDC and a Windows NT BDC, or vice versa).
|
|
This means Samba cannot operate as a BDC when the PDC is Microsoft-based Windows NT PDC. Samba-4 can not
|
|
participate in replication of account data to Windows PDCs and BDCs.
|
|
</para></listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
<indexterm><primary>group</primary><secondary>mapping</secondary></indexterm>
|
|
Samba-3 implements 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 <link linkend="groupmapping">Group Mapping: MS
|
|
Windows and UNIX</link>.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>machine trust account</primary></indexterm>
|
|
<indexterm><primary>trust account</primary><secondary>machine</secondary></indexterm>
|
|
<indexterm><primary>machine account</primary></indexterm>
|
|
Samba-4, 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. Refer to <link linkend="machine-trust-accounts">MS
|
|
Windows Workstation/Server Machine Trust Accounts</link>. A complete discussion of account database backends can be found in <link linkend="passdb">Account
|
|
Information Databases</link>.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Single Sign-On and Domain Security</title>
|
|
|
|
<para>
|
|
<indexterm><primary>single sign-on</primary><see>SSO</see></indexterm>
|
|
<indexterm><primary>SSO</primary></indexterm>
|
|
<indexterm><primary>active directory</primary></indexterm>
|
|
<indexterm><primary>authentication</primary></indexterm>
|
|
<indexterm><primary>validation</primary></indexterm>
|
|
<indexterm><primary>password uniqueness</primary></indexterm>
|
|
<indexterm><primary>password history</primary></indexterm>
|
|
When network administrators are asked to describe the benefits of Windows NT4 and active directory networking
|
|
the most often mentioned feature is that of single sign-on (SSO). Many companies have implemented SSO
|
|
solutions. The mode of implementation of a single sign-on solution is an important factor in the practice of
|
|
networking in general, and is critical in respect of Windows networking. A company may have a wide variety of
|
|
information systems, each of which requires a form of user authentication and validation, thus it is not
|
|
uncommon that users may need to remember more than ten login IDs and passwords. This problem is compounded
|
|
when the password for each system must be changed at regular intervals, and particularly so where password
|
|
uniqueness and history limits are applied.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>management overheads</primary></indexterm>
|
|
There is a broadly held perception that SSO is the answer to the problem of users having to deal with too many
|
|
information system access credentials (username/password pairs). Many elaborate schemes have been devised to
|
|
make it possible to deliver a user-friendly SSO solution. The trouble is that if this implementation is not
|
|
done correctly, the site may end up paying dearly by way of complexity and management overheads. Simply put,
|
|
many SSO solutions are an administrative nightmare.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>identity management</primary></indexterm>
|
|
<indexterm><primary>authentication system</primary></indexterm>
|
|
<indexterm><primary>SSO</primary></indexterm>
|
|
SSO implementations utilize centralization of all user account information. Depending on environmental
|
|
complexity and the age of the systems over which a SSO solution is implemented, it may not be possible to
|
|
change the solution architecture so as to accommodate a new identity management and user authentication system.
|
|
Many SSO solutions involving legacy systems consist of a new super-structure that handles authentication on
|
|
behalf of the user. The software that gets layered over the old system may simply implement a proxy
|
|
authentication system. This means that the addition of SSO increases over-all information systems complexity.
|
|
Ideally, the implementation of SSO should reduce complexity and reduce administative overheads.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>centralized identity management</primary></indexterm>
|
|
<indexterm><primary>identity management</primary><secondary>centralized</secondary></indexterm>
|
|
<indexterm><primary>centralized</primary><secondary>authentication</secondary></indexterm>
|
|
<indexterm><primary>legacy systems</primary></indexterm>
|
|
<indexterm><primary>access control</primary></indexterm>
|
|
The initial goal of many network administrators is often to create and use a centralized identity management
|
|
system. It is often assumed that such a centralized system will use a single authentication infrastructure
|
|
that can be used by all information systems. The Microsoft Windows NT4 security domain architecture and the
|
|
Microsoft active directory service are often put forward as the ideal foundation for such a system. It is
|
|
conceptually simple to install an external authentication agent on each of the disparate infromation systems
|
|
that can then use the Microsoft (NT4 domain or ads service) for user authentication and access control. The
|
|
wonderful dream of a single centralized authentication service is commonly broken when realities are realized.
|
|
The problem with legacy systems is often the inability to externalize the authentication and access control
|
|
system it uses because its implementation will be excessively invasive from a re-engineering perspective, or
|
|
because application software has built-in dependencies on particular elements of the way user authentication
|
|
and access control were designed and built.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>meta-directory</primary></indexterm>
|
|
<indexterm><primary>credentials</primary></indexterm>
|
|
<indexterm><primary>disparate information systems</primary></indexterm>
|
|
<indexterm><primary>management procedures</primary></indexterm>
|
|
<indexterm><primary>work-flow protocol</primary></indexterm>
|
|
<indexterm><primary>rights</primary></indexterm>
|
|
<indexterm><primary>privileges</primary></indexterm>
|
|
<indexterm><primary>provisioned</primary></indexterm>
|
|
Over the past decade an industry has been developed around the various methods that have been built to get
|
|
around the key limitations of legacy information technology systems. One approach that is often used involves
|
|
the use of a meta-directory. The meta-directory stores user credentials for all disparate information systems
|
|
in the format that is particular to each system. An elaborate set of management procedures is coupled with a
|
|
rigidly enforced work-flow protocol for managing user rights and privileges within the maze of systems that
|
|
are provisioned by the new infrastructure makes possible user access to all systems using a single set of user
|
|
credentials.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>Organization for the Advancement of Structured Information Standards</primary><see>OASIS</see></indexterm>
|
|
<indexterm><primary>Security Assertion Markup Language</primary><see>SAML</see></indexterm>
|
|
<indexterm><primary>Federated Identity Management</primary><see>FIM</see></indexterm>
|
|
<indexterm><primary>secure access</primary></indexterm>
|
|
The Organization for the Advancement of Structured Information Standards (OASIS) has developed the Security
|
|
Assertion Markup Language (SAML), a structured method for communication of authentication information. The
|
|
over-all umbrella name for the technologies and methods that deploy SAML is called Federated Identity
|
|
Management (FIM). FIM depends on each system in the complex maze of disparate information systems to
|
|
authenticate their respective users and vouch for secure access to the services each provides.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>Simple Object Access Protocol</primary><see>SOAP</see></indexterm>
|
|
<indexterm><primary>federated organizations</primary></indexterm>
|
|
<indexterm><primary>Liberty Alliance</primary></indexterm>
|
|
<indexterm><primary>federated-identity</primary></indexterm>
|
|
<indexterm><primary></primary></indexterm>
|
|
<indexterm><primary></primary></indexterm>
|
|
SAML documents can be wrapped in a Simple Object Access Protocol (SOAP) message for the computer-to-computer
|
|
communications needed for Web services. Or they may be passed between Web servers of federated organizations
|
|
that share live services. The Liberty Alliance, an industry group formed to promote federated-identity
|
|
standards, has adopted SAML 1.1 as part of its application framework. Microsoft and IBM have proposed an
|
|
alternative specification called WS-Security. Some believe that the competing technologies and methods may
|
|
converge when the SAML 2.0 standard is introduced. A few Web access-management products support SAML today,
|
|
but implementation of the technology mostly requires customization to integrate applications and develop user
|
|
interfaces. In a nutshell, that is why FIM is a big and growing industry.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>interoperability</primary></indexterm>
|
|
<indexterm><primary>ADS</primary></indexterm>
|
|
<indexterm><primary>LDAP</primary></indexterm>
|
|
<indexterm><primary>GSSAPI</primary></indexterm>
|
|
<indexterm><primary>general security service application programming interface</primary><see>GSSAPI</see></indexterm>
|
|
Ignoring the bigger picture, which is beyond the scope of this book, the migration of all user and group
|
|
management to a centralized system is a step in the right direction. It is essential for interoperability
|
|
reasons to locate the identity management system data in a directory such as Microsoft Active Directory
|
|
Service (ADS), or any proprietary or open source system that provides a standard protocol for information
|
|
access (such as LDAP) and that can be coupled with a flexible array of authentication mechanisms (such as
|
|
kerberos) that use the protocols that are defined by the various general security service application
|
|
programming interface (GSSAPI) services.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>OpenLDAP</primary></indexterm>
|
|
<indexterm><primary>ADS</primary></indexterm>
|
|
<indexterm><primary>authentication agents</primary></indexterm>
|
|
A growing number of companies provide authentication agents for disparate legacy platforms to permit the use
|
|
of LDAP systems. Thus the use of OpenLDAP, the dominant open source software implementation of the light
|
|
weight directory access protocol standard. This fact, means that by providing support in Samba for the use of
|
|
LDAP and Microsoft ADS make Samba a highly scalable and forward reaching organizational networking technology.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>ADS</primary></indexterm>
|
|
<indexterm><primary>LDAP</primary></indexterm>
|
|
<indexterm><primary>authentication architecture</primary></indexterm>
|
|
<indexterm><primary>ntlm_auth</primary></indexterm>
|
|
<indexterm><primary>SQUID</primary></indexterm>
|
|
<indexterm><primary>FIM</primary></indexterm>
|
|
Microsoft ADS provides purely proprietary services that, with limitation, can be extended to provide a
|
|
centralized authentication infrastructure. Samba plus LDAP provides a similar opportunity for extension of a
|
|
centralized authentication architecture, but it is the fact that the Samba Team are pro-active in introducing
|
|
the extension of authentication services, using LDAP or otherwise, to applications such as SQUID (the open
|
|
source proxy server) through tools such as the <command>ntlm_auth</command> utility, that does much to create
|
|
sustainable choice and competition in the FIM market place.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>LDAP</primary></indexterm>
|
|
<indexterm><primary>OpenLDAP</primary></indexterm>
|
|
<indexterm><primary>identity information</primary></indexterm>
|
|
Primary domain control, if it is to be scalable to meet the needs of large sites, must therefore be capable of
|
|
using LDAP. The rapid adoption of OpenLDAP, and Samba configurations that use it, is ample proof that the era
|
|
of the directory has started. Samba-3 does not demand the use of LDAP, but the demand for a mechanism by which
|
|
user and group identity information can be distributed makes it an an unavoidable option.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>BDC</primary></indexterm>
|
|
<indexterm><primary>LDAP</primary></indexterm>
|
|
<indexterm><primary>e-Directory</primary></indexterm>
|
|
At this time, the use of Samba based BDCs, necessitates the use of
|
|
either the Samba-4 Active Directory Domain controller or, for classic
|
|
(NT4-like)domains an LDAP backend. The most commonly used LDAP
|
|
implementation used by Samba sites is OpenLDAP. It is possible to use any standards compliant LDAP server.
|
|
Those known to work includes those manufactured by: IBM, CA, Novell (e-Directory), and others.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Basics of Domain Control</title>
|
|
|
|
<para>
|
|
<indexterm><primary>domain control</primary></indexterm>
|
|
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>NT4 style Primary Domain Controller</para></listitem>
|
|
<listitem><para>NT4 style Backup Domain Controller</para></listitem>
|
|
<listitem><para>ADS Domain Controller</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
<indexterm><primary>PDC</primary></indexterm>
|
|
<indexterm><primary>powerful</primary></indexterm>
|
|
<indexterm><primary>network</primary><secondary>performance</secondary></indexterm>
|
|
<indexterm><primary>domain</primary><secondary>member</secondary><tertiary>server</tertiary></indexterm>
|
|
The <emphasis>Primary Domain Controller</emphasis> or PDC plays an important role in MS Windows NT4. In
|
|
Windows 200x domain control architecture, this role is held by domain controllers. Folklore dictates that
|
|
because of its role in the MS Windows network, the domain controller should be the most powerful and most
|
|
capable machine in the network. As strange as it may seem to say this here, good overall network performance
|
|
dictates that the entire infrastructure needs to be balanced. It is advisable to invest more in standalone
|
|
(domain member) servers than in the domain controllers.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>SAM</primary></indexterm>
|
|
<indexterm><primary>BDC</primary></indexterm>
|
|
<indexterm><primary>authenticatior</primary></indexterm>
|
|
<indexterm><primary>synchronization</primary></indexterm>
|
|
<indexterm><primary>FSMO</primary></indexterm>
|
|
<indexterm><primary>Flexible Single Master Operator</primary><see>FSMO</see></indexterm>
|
|
<indexterm><primary>Security Account Manager</primary><see>SAM</see></indexterm>
|
|
In the case of MS Windows NT4-style domains, it is the PDC that initiates a new domain control database.
|
|
This forms a part of the Windows registry called the Security Account Manager (SAM). It plays a key
|
|
part in NT4-type domain user authentication and in synchronization of the domain authentication
|
|
database with BDCs. With Active Directory domains, while some servers
|
|
may be a Flexible Single Master Operator (FSMO) role owner (and
|
|
therefore hold the monopoly for certain operations), it is in general
|
|
a distributed, multi-master replicated directory.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>backend database</primary></indexterm>
|
|
<indexterm><primary>registry</primary></indexterm>
|
|
Samba-4 can use a backend database that holds the same type of data as the NT4-style SAM
|
|
database (one of the registry files). For BDC/BDC operations in a
|
|
classic domain, this functionality can be implemented using an
|
|
LDAP-based user and machine account backend. The Samba-4 Active
|
|
Directory Domain controller implements the required storage internally.<footnote><para>See also <link linkend="passdb">Account Information
|
|
Databases</link>.</para></footnote>
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>BDC</primary></indexterm>
|
|
<indexterm><primary>PDC</primary></indexterm>
|
|
<indexterm><primary>WINS</primary></indexterm>
|
|
<indexterm><primary>authentication</primary></indexterm>
|
|
<indexterm><primary>netlogon</primary></indexterm>
|
|
<indexterm><primary>name lookup</primary></indexterm>
|
|
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 most likely service network logon requests. The PDC will answer network logon
|
|
requests when the BDC is too busy (high load). When a user logs onto a Windows domain member client the
|
|
workstation will query the network to locate the nearest network logon server. Where a WINS server is used,
|
|
this is done via a query to the WINS server. If a netlogon server can not be found from the WINS query, or in
|
|
the absence of a WINS server, the workstation will perform a NetBIOS name lookup via a mailslot broadcast over
|
|
the UDP broadcast protocol. This means that the netlogon server that the windows client will use is influenced
|
|
by a number of variables, thus there is no simple determinant of whether a PDC or a BDC will serve a
|
|
particular logon authentication request.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>promote</primary></indexterm>
|
|
<indexterm><primary>demote</primary></indexterm>
|
|
A Windows NT4 BDC can be promoted to a PDC. If the PDC is online 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 PDC
|
|
and BDC must be manually configured, and other appropriate changes also need to be made.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>domain</primary><secondary>controller</secondary><tertiary>convert</tertiary></indexterm>
|
|
With MS Windows NT4, a decision is made at installation to determine what type of machine the server will be.
|
|
It is possible to promote a BDC to a PDC, and vice versa. The only method Microsoft provide to convert a
|
|
Windows NT4 domain controller to a domain member server or a standalone server is to reinstall it. The install
|
|
time choices offered are:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para><emphasis>Primary Domain Controller</emphasis> &smbmdash; the one that seeds the domain SAM.</para></listitem>
|
|
<listitem><para><emphasis>Backup Domain Controller</emphasis> &smbmdash; one that obtains a copy of the domain SAM.</para></listitem>
|
|
<listitem><para><emphasis>Domain Member Server</emphasis> &smbmdash; 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>Standalone Server</emphasis> &smbmdash; one that plays no part in SAM synchronization,
|
|
has its own authentication database, and plays no role in domain security.</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
<indexterm><primary>domain</primary><secondary>control</secondary><tertiary>role</tertiary></indexterm>
|
|
<indexterm><primary>native member</primary></indexterm>
|
|
Samba-3 servers can readily be converted to and from domain controller roles through simple changes to the
|
|
&smb.conf; file. Samba-3 is capable of acting fully as a native member of a Windows 200x server Active
|
|
Directory domain.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>convert</primary><secondary>domain member server</secondary></indexterm>
|
|
For the sake of providing a complete picture, MS Windows 2000 domain control configuration is done after the server has been
|
|
installed. Please refer to Microsoft documentation for the procedures that should be followed to convert a
|
|
domain member server to or from a domain control, and to install or remove active directory service support.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
|
|
<indexterm><primary>SAM</primary><secondary>replication</secondary></indexterm>
|
|
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 also supports the
|
|
MS Windows 200x domain control protocols.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Preparing for Domain Control</title>
|
|
|
|
<para>
|
|
<indexterm><primary>standalone</primary></indexterm>
|
|
<indexterm><primary>workgroup</primary></indexterm>
|
|
<indexterm><primary>member</primary></indexterm>
|
|
<indexterm><primary>security</primary></indexterm>
|
|
There are two ways that MS Windows machines may interact with each other, with other servers,
|
|
and with domain controllers: either as <emphasis>standalone</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>
|
|
<indexterm><primary>workgroup</primary></indexterm>
|
|
<indexterm><primary>workgroup</primary><secondary>membership</secondary></indexterm>
|
|
<indexterm><primary>machine trust account</primary></indexterm>
|
|
It should be noted that workgroup membership involves no special configuration other than the machine being
|
|
configured so the network configuration has a commonly used name for its 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 is limited to the fact that all machines appear in the network
|
|
neighborhood to be logically grouped together. Again, just to be clear: <emphasis>workgroup mode does not
|
|
involve security machine accounts</emphasis>.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>domain membership</primary></indexterm>
|
|
<indexterm><primary>machine trust account</primary><secondary>password</secondary></indexterm>
|
|
<indexterm><primary>trigger</primary></indexterm>
|
|
Domain member machines have a machine trust account in the domain accounts database. A special procedure
|
|
must be followed on each machine to effect domain membership. This procedure, which can be done
|
|
only by the local machine Administrator account, creates the domain machine account (if it does
|
|
not exist), and then initializes that account. When the client first logs onto the
|
|
domain, a machine trust account password change will be automatically triggered.
|
|
</para>
|
|
|
|
<note><para>
|
|
<indexterm><primary>domain member</primary></indexterm>
|
|
When Samba is configured as a domain controller, secure network operation demands that
|
|
all MS Windows NT4/200x/XP Professional clients should be configured as domain members.
|
|
If a machine is not made a member of the domain, then it will operate like a workgroup
|
|
(standalone) machine. Please refer to <link linkend="domain-member">Domain Membership</link>, for
|
|
information regarding domain membership.
|
|
</para></note>
|
|
|
|
<para>
|
|
The following are necessary for configuring Samba-3 as an MS Windows NT4-style PDC for MS Windows
|
|
NT4/200x/XP clients:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>Configuration of basic TCP/IP and MS Windows networking.</para></listitem>
|
|
<listitem><para>Correct designation of the server role (<smbconfoption name="security">user</smbconfoption>).</para></listitem>
|
|
<listitem><para>Consistent configuration of name resolution.<footnote><para>See <link linkend="NetworkBrowsing">Network Browsing</link>, and
|
|
<link linkend="integrate-ms-networks">Integrating MS Windows Networks with Samba</link>.</para></footnote></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>
|
|
<listitem><para>Adding and managing domain user accounts.</para></listitem>
|
|
<listitem><para>Configuring MS Windows NT4/2000 Professional and Windows XP Professional client machines to become domain members.</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<note><para>
|
|
<indexterm><primary>roaming profiles</primary></indexterm>
|
|
<indexterm><primary>account policies</primary></indexterm>
|
|
Roaming profiles and system/network policies are advanced network administration topics
|
|
that are covered in <link linkend="ProfileMgmt">Desktop Profile Management</link> and
|
|
<link linkend="PolicyMgmt">System and Account Policies</link> 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>
|
|
|
|
<para>
|
|
A domain controller is an SMB/CIFS server that:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>
|
|
<indexterm><primary>NetBIOS</primary><secondary>brooadcast</secondary></indexterm>
|
|
<indexterm><primary>WINS</primary></indexterm>
|
|
<indexterm><primary>UDP</primary></indexterm>
|
|
<indexterm><primary>DNS</primary></indexterm>
|
|
<indexterm><primary>active directory</primary></indexterm>
|
|
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>
|
|
|
|
<listitem><para>
|
|
<indexterm><primary>NETLOGON</primary></indexterm>
|
|
<indexterm><primary>LanMan logon service</primary></indexterm>
|
|
Provides the NETLOGON service. (This is actually a collection of services that runs over
|
|
multiple protocols. These include the LanMan logon service, the Netlogon service,
|
|
the Local Security Account service, and variations of them.)
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
Provides a share called NETLOGON.
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
<indexterm><primary>domain</primary><secondary>master</secondary><tertiary>browser</tertiary></indexterm>
|
|
<indexterm><primary>local</primary><secondary>master</secondary><tertiary>browser</tertiary></indexterm>
|
|
<indexterm><primary>DMB</primary></indexterm>
|
|
<indexterm><primary>LMB</primary></indexterm>
|
|
<indexterm><primary>browse list</primary></indexterm>
|
|
It is rather easy to configure Samba to provide these. Each Samba domain controller must provide the NETLOGON
|
|
service that Samba calls the <smbconfoption name="domain logons"/> functionality (after the name of the
|
|
parameter in the &smb.conf; file). Additionally, one server in a Samba-3 domain must advertise itself as the
|
|
domain master browser.<footnote><para>See <link linkend="NetworkBrowsing">Network
|
|
Browsing</link>.</para></footnote> This causes the PDC to claim a domain-specific NetBIOS name that identifies
|
|
it as a DMB for its given domain or workgroup. Local master browsers (LMBs) in the same domain or workgroup on
|
|
broadcast-isolated subnets then ask for a complete copy of the browse list for the whole wide-area network.
|
|
Browser clients then contact their LMB, and will receive the domain-wide browse list instead of just the list
|
|
for their broadcast-isolated subnet.
|
|
</para>
|
|
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Domain Control: Example Configuration</title>
|
|
|
|
<para>
|
|
The first step in creating a working Samba PDC is to understand the parameters necessary
|
|
in &smb.conf;. An example &smb.conf; for acting as a PDC can be found in <link linkend="pdc-example">the
|
|
smb.conf file for an example PDC</link>.
|
|
</para>
|
|
|
|
<example id="pdc-example">
|
|
<title>smb.conf for being a PDC</title>
|
|
<smbconfblock>
|
|
<smbconfsection name="[global]"/>
|
|
<smbconfoption name="netbios name"><replaceable>BELERIAND</replaceable></smbconfoption>
|
|
<smbconfoption name="workgroup"><replaceable>&example.workgroup;</replaceable></smbconfoption>
|
|
<smbconfoption name="passdb backend">tdbsam</smbconfoption>
|
|
<smbconfoption name="security">user</smbconfoption>
|
|
<smbconfoption name="domain logons">yes</smbconfoption>
|
|
<smbconfoption name="logon path">\\%N\profiles\%U</smbconfoption>
|
|
<smbconfoption name="logon drive">H:</smbconfoption>
|
|
<smbconfoption name="logon home">\\homeserver\%U\winprofile</smbconfoption>
|
|
<smbconfoption name="logon script">logon.cmd</smbconfoption>
|
|
|
|
<smbconfsection name="[netlogon]"/>
|
|
<smbconfoption name="path">/var/lib/samba/netlogon</smbconfoption>
|
|
<smbconfoption name="read only">yes</smbconfoption>
|
|
<smbconfoption name="write list"><replaceable>ntadmin</replaceable></smbconfoption>
|
|
|
|
<smbconfsection name="[profiles]"/>
|
|
<smbconfoption name="path">/var/lib/samba/profiles</smbconfoption>
|
|
<smbconfoption name="read only">no</smbconfoption>
|
|
<smbconfoption name="create mask">0600</smbconfoption>
|
|
<smbconfoption name="directory mask">0700</smbconfoption>
|
|
</smbconfblock>
|
|
</example>
|
|
|
|
<para>
|
|
The basic options shown in <link linkend="pdc-example">this example</link> are explained as follows:
|
|
</para>
|
|
|
|
<variablelist>
|
|
<varlistentry><term>passdb backend </term>
|
|
<listitem><para>
|
|
<indexterm><primary>group</primary><secondary>account</secondary></indexterm>
|
|
<indexterm><primary>smbpasswd</primary></indexterm>
|
|
<indexterm><primary>tdbsam</primary></indexterm>
|
|
<indexterm><primary>ldapsam</primary></indexterm>
|
|
<indexterm><primary>guest</primary></indexterm>
|
|
<indexterm><primary>default accounts</primary></indexterm>
|
|
This contains all the user and group account information. Acceptable values for a PDC
|
|
are: <emphasis>smbpasswd, tdbsam, and ldapsam</emphasis>. The <quote>guest</quote> entry provides
|
|
default accounts and is included by default; there is no need to add it explicitly.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>passdb backend</primary></indexterm>
|
|
<indexterm><primary>distributed</primary></indexterm>
|
|
<indexterm><primary>smbpasswd</primary></indexterm>
|
|
<indexterm><primary>tdbsam</primary></indexterm>
|
|
Where use of BDCs is intended, the only logical choice is
|
|
to use LDAP so the passdb backend can be distributed. The tdbsam and smbpasswd files
|
|
cannot effectively be distributed and therefore should not be used.
|
|
</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>Domain Control Parameters </term>
|
|
<listitem><para>
|
|
<indexterm><primary>network</primary><secondary>logon</secondary></indexterm>
|
|
The parameters <emphasis>domain logons</emphasis>
|
|
parameter is the key parameter indicating domain
|
|
control and network logon support.
|
|
</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>Environment Parameters </term>
|
|
<listitem><para>
|
|
<indexterm><primary>logon path</primary></indexterm>
|
|
<indexterm><primary>logon home</primary></indexterm>
|
|
<indexterm><primary>logon drive</primary></indexterm>
|
|
<indexterm><primary>logon script</primary></indexterm>
|
|
The parameters <emphasis>logon path, logon home, logon drive</emphasis>, and <emphasis>logon script</emphasis> are
|
|
environment support settings that help to facilitate client logon operations and that help
|
|
to provide automated control facilities to ease network management overheads. Please refer
|
|
to the man page information for these parameters.
|
|
</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>NETLOGON Share </term>
|
|
<listitem><para>
|
|
<indexterm><primary>NETLOGON</primary></indexterm>
|
|
<indexterm><primary>logon processing</primary></indexterm>
|
|
<indexterm><primary>domain logon</primary></indexterm>
|
|
<indexterm><primary>domain membership</primary></indexterm>
|
|
<indexterm><primary>group policy</primary></indexterm>
|
|
<indexterm><primary>NTConfig.POL</primary></indexterm>
|
|
The NETLOGON share plays a central role in domain logon and domain membership support.
|
|
This share is provided on all Microsoft domain controllers. It is used to provide logon
|
|
scripts, to store group policy files (NTConfig.POL), as well as to locate other common
|
|
tools that may be needed for logon processing. This is an essential share on a domain controller.
|
|
</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>PROFILE Share </term>
|
|
<listitem><para>
|
|
<indexterm><primary>desktop profile</primary></indexterm>
|
|
<indexterm><primary>VFS</primary></indexterm>
|
|
<indexterm><primary>fake_permissions</primary></indexterm>
|
|
<indexterm><primary>profile</primary></indexterm>
|
|
<indexterm><primary></primary></indexterm>
|
|
This share is used to store user desktop profiles. Each user must have a directory at the root
|
|
of this share. This directory must be write-enabled for the user and must be globally read-enabled.
|
|
Samba-3 has a VFS module called <quote>fake_permissions</quote> that may be installed on this share. This will
|
|
allow a Samba administrator to make the directory read-only to everyone. Of course this is useful
|
|
only after the profile has been properly created.
|
|
</para></listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<note><para>
|
|
The above parameters make for a full set of functionality that may define the server's mode
|
|
of operation. The following &smb.conf; parameters are the essentials alone:
|
|
</para>
|
|
|
|
<para>
|
|
<smbconfblock>
|
|
<smbconfoption name="netbios name">BELERIAND</smbconfoption>
|
|
<smbconfoption name="workgroup">&example.workgroup;</smbconfoption>
|
|
<smbconfoption name="domain logons">Yes</smbconfoption>
|
|
<smbconfoption name="security">User</smbconfoption>
|
|
</smbconfblock>
|
|
</para>
|
|
|
|
<para>
|
|
The additional parameters shown in the longer listing in this section just make for
|
|
a more complete explanation.
|
|
</para></note>
|
|
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Samba ADS Domain Control</title>
|
|
|
|
<para>
|
|
<indexterm><primary>active directory</primary></indexterm>
|
|
Samba-4 is also available as an Active Directory server. It can truly function as an Active Directory
|
|
PDC. The protocols for some of the functionality of Active Directory
|
|
domain controllers has been implemented.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>domain controllers</primary></indexterm>
|
|
<indexterm><primary>active directory</primary></indexterm>
|
|
<indexterm><primary>classic domain support</primary></indexterm>
|
|
To be sure, Samba-4 is also designed to provide most of the functionality that Microsoft Windows NT4-style
|
|
domain controllers have. Samba-4 does not have all the capabilities of Windows NT4, but it does have
|
|
a number of features that Windows NT4 domain controllers do not
|
|
have. We call it a <emphasis>classic domain</emphasis> controller for
|
|
this reason, as in short, Samba-4 when acting in this mode is not NT4,
|
|
and the Active Directory Domain Control aspect is a distinct capability.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Domain and Network Logon Configuration</title>
|
|
|
|
<para>
|
|
<indexterm><primary>domain logon</primary></indexterm>
|
|
The subject of network or domain logons is discussed here because it forms
|
|
an integral part of the essential functionality that is provided by a domain controller.
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>Domain Network Logon Service</title>
|
|
|
|
<para>
|
|
<indexterm><primary>domain logon</primary></indexterm>
|
|
All domain controllers must run the netlogon service (<emphasis>domain logons</emphasis>
|
|
in Samba). One domain controller must be configured without the
|
|
<smbconfoption name="domain master"></smbconfoption> parameter
|
|
(the PDC); on all BDCs set the parameter <smbconfoption name="domain master">No</smbconfoption>.
|
|
</para>
|
|
|
|
<sect3>
|
|
<title>Example Configuration</title>
|
|
|
|
<example id="PDC-config">
|
|
<title>smb.conf for being a PDC</title>
|
|
<smbconfblock>
|
|
<smbconfsection name="[global]"/>
|
|
<smbconfoption name="domain logons">Yes</smbconfoption>
|
|
<smbconfoption name="domain master">(omit on PDC, No on BDCs)</smbconfoption>
|
|
|
|
<smbconfsection name="[netlogon]"/>
|
|
<smbconfoption name="comment">Network Logon Service</smbconfoption>
|
|
<smbconfoption name="path">/var/lib/samba/netlogon</smbconfoption>
|
|
<smbconfoption name="guest ok">Yes</smbconfoption>
|
|
<smbconfoption name="browseable">No</smbconfoption>
|
|
</smbconfblock>
|
|
</example>
|
|
|
|
</sect3>
|
|
<sect3>
|
|
<title>The Special Case of MS Windows Home Editions</title>
|
|
|
|
<para>
|
|
<indexterm><primary>Windows Home editions</primary></indexterm>
|
|
To be completely clear: If you want MS Windows Home Editions to integrate with your
|
|
MS Windows NT4 or Active Directory domain security, understand it cannot be done.
|
|
The only option is to purchase the upgrade from MS Windows Home Edition to
|
|
a MS Windows Professional edition.
|
|
</para>
|
|
|
|
<note><para>
|
|
MS Windows Home Editions do not have the ability to join any type of domain
|
|
security facility. Unlike MS Windows 9x/Me, MS Windows Home Edition
|
|
deliberatly lacks the ability to log onto a network.
|
|
</para></note>
|
|
|
|
<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.
|
|
If it can be done, then to do so would violate your software license agreement with
|
|
Microsoft, and we recommend that you do not do that.
|
|
</para>
|
|
|
|
</sect3>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Security Mode and Master Browsers</title>
|
|
|
|
<para>
|
|
<indexterm><primary>security mode</primary></indexterm>
|
|
<indexterm><primary>user-mode security</primary></indexterm>
|
|
<indexterm><primary>share-mode security</primary></indexterm>
|
|
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 it is okay to configure Samba as a domain controller that operates with security mode other than
|
|
user-mode. The only security mode that will not work due to technical reasons is share-mode security. Domain
|
|
and server mode security are really just a variation on SMB user-level security.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>DOMAIN<1C></primary></indexterm>
|
|
<indexterm><primary>DOMAIN<1B></primary></indexterm>
|
|
<indexterm><primary>DMB</primary></indexterm>
|
|
<indexterm><primary>PDC</primary></indexterm>
|
|
<indexterm><primary>NetBIOS name</primary></indexterm>
|
|
<indexterm><primary>domain controller</primary></indexterm>
|
|
<indexterm><primary>election</primary></indexterm>
|
|
Actually, this issue is also closely tied to the debate on whether Samba must be the DMB for its workgroup
|
|
when operating as a domain controller. In a pure Microsoft Windows NT domain, the PDC wins the election to be
|
|
the DMB, and then registers the DOMAIN<1B> NetBIOS name. This is not the name used by Windows clients
|
|
to locate the domain controller, all domain controllers register the DOMAIN<1C> name and Windows clients
|
|
locate a network logon server by seraching for the DOMAIN<1C> name. A DMB is a Domain Master Browser
|
|
&smbmdash; see <link linkend="NetworkBrowsing">The Network Browsing Chapter</link>, <link
|
|
linkend="DMB">Configuring WORKGROUP Browsing</link>; Microsoft PDCs expect to win the election to become the
|
|
DMB, if it loses that election it will report a continuous and rapid sequence of warning messages to its
|
|
Windows event logger complaining that it has lost the election to become a DMB. For this reason, in networks
|
|
where a Samba server is the PDC it is wise to configure the Samba domain controller as the DMB.
|
|
</para>
|
|
|
|
<note><para>
|
|
<indexterm><primary>DOMAIN<1D></primary></indexterm>
|
|
<indexterm><primary>synchronization</primary></indexterm>
|
|
<indexterm><primary>domain control</primary></indexterm>
|
|
<indexterm><primary>browse list management</primary></indexterm>
|
|
<indexterm><primary>network</primary><secondary>logon</secondary><tertiary>service</tertiary></indexterm>
|
|
SMB/CIFS servers that register the DOMAIN<1C> name do so because they provide the network logon
|
|
service. Server that register the DOMAIN<1B> name are DMBs &smbmdash; meaning that they are responsible
|
|
for browse list synchronization across all machines that have registered the DOMAIN<1D> name. The later
|
|
are LMBs that have the responsibility to listen to all NetBIOS name registrations that occur locally to their
|
|
own network segment. The network logon service (NETLOGON) is germane to domain control and has nothing to do
|
|
with network browsing and browse list management. The 1C and 1B/1D name services are orthogonal to each
|
|
other.
|
|
</para></note>
|
|
|
|
<para>
|
|
Now back to the issue of configuring a Samba domain controller to use a mode other than <smbconfoption
|
|
name="security">user</smbconfoption>. If a Samba host is configured to use another SMB server or domain
|
|
controller in order to validate user connection requests, it is a fact that some other machine on the network
|
|
(the <smbconfoption name="password server"/>) knows more about the user than the Samba host. About 99 percent
|
|
of the time, this other host is a domain controller. Now to operate in domain mode security, the
|
|
<smbconfoption name="workgroup"/> parameter must be set to the name of the Windows NT domain (which already
|
|
has a domain controller). If the domain does not already have a domain controller, you do not yet have a
|
|
domain.
|
|
</para>
|
|
|
|
<para>
|
|
Configuring a Samba box as a domain controller for a domain that already by definition has a
|
|
PDC is asking for trouble. Therefore, you should always configure the Samba domain controller
|
|
to be the DMB for its domain and set <smbconfoption name="security">user</smbconfoption>.
|
|
This is the only officially supported mode of operation.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Common Errors</title>
|
|
|
|
<sect2>
|
|
<title><quote>$</quote> Cannot Be Included in Machine Name</title>
|
|
|
|
<para>
|
|
<indexterm><primary>BSD</primary></indexterm>
|
|
<indexterm><primary>FreeBSD</primary></indexterm>
|
|
<indexterm><primary>/etc/passwd</primary></indexterm>
|
|
A machine account, typically stored in <filename>/etc/passwd</filename>, takes the form of the machine
|
|
name with a <quote>$</quote> appended. Some BSD systems will not create a user with a <quote>$</quote> in the name.
|
|
Recent versions of FreeBSD have removed this limitation, but older releases are still in common use.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>vipw</primary></indexterm>
|
|
The problem is only in the program used to make the entry. Once made, it works perfectly. Create a user
|
|
without the <quote>$</quote>. Then use <command>vipw</command> to edit the entry, adding the <quote>$</quote>.
|
|
Or create the whole entry with vipw if you like; make sure you use a unique user login ID.
|
|
</para>
|
|
|
|
<note><para>The machine account must have the exact name that the workstation has.</para></note>
|
|
|
|
<note><para>
|
|
The UNIX tool <command>vipw</command> is a common tool for directly editing the <filename>/etc/passwd</filename> file.
|
|
The use of vipw will ensure that shadow files (where used) will remain current with the passwd file. This is
|
|
important for security reasons.
|
|
</para></note>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Joining Domain Fails Because of Existing Machine Account</title>
|
|
|
|
<para>
|
|
<indexterm><primary>join domain</primary></indexterm>
|
|
<quote>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.</quote>
|
|
</para>
|
|
|
|
<para>
|
|
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:
|
|
<screen>
|
|
&dosprompt;<userinput>net use * /d</userinput>
|
|
</screen>
|
|
This will break all network connections.
|
|
</para>
|
|
|
|
<para>
|
|
Further, if the machine is already a <quote>member of a workgroup</quote> 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 &smbmdash;
|
|
it does not matter what &smbmdash; reboot, and try again.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>The System Cannot Log You On (C000019B)</title>
|
|
|
|
<para><quote>
|
|
I joined the domain successfully but after upgrading to a newer version of the Samba code I get the message,
|
|
<errorname>`The system cannot log you on (C000019B). Please try again or consult your system
|
|
administrator</errorname> when attempting to logon.'</quote>
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>SID</primary></indexterm>
|
|
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 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.
|
|
</para>
|
|
|
|
<para>
|
|
To reset or change the domain SID you can use the net command as follows:
|
|
|
|
<screen>
|
|
&rootprompt;<userinput>net getlocalsid 'OLDNAME'</userinput>
|
|
&rootprompt;<userinput>net setlocalsid 'SID'</userinput>
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
Workstation Machine Trust Accounts work only with the domain (or network) SID. If this SID changes,
|
|
domain members (workstations) will not be able to log onto the domain. The original domain SID
|
|
can be recovered from the secrets.tdb file. The alternative is to visit each workstation to rejoin
|
|
it to the domain.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>The Machine Trust Account Is Not Accessible</title>
|
|
|
|
<para>
|
|
<quote>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?</quote>
|
|
</para>
|
|
|
|
<para>
|
|
This problem is caused by the PDC not having a suitable Machine Trust Account. If you are using the
|
|
<smbconfoption name="add machine script"/> method to create accounts, then this would indicate that it has not
|
|
worked. Ensure the domain admin user system is working.
|
|
</para>
|
|
|
|
<para>
|
|
Alternately, 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 <filename>smbpasswd</filename> 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 <quote>$</quote> appended to it (i.e.,
|
|
computer_name$). There must be an entry in both the POSIX UNIX system account backend as well as in the
|
|
SambaSAMAccount backend. The default backend for Samba-3 (i.e., the parameter <parameter>passdb
|
|
backend</parameter> is not specified in the &smb.conf; file, or if specified is set to
|
|
<literal>smbpasswd</literal>, are respectively the <filename>/etc/passwd</filename> and
|
|
<filename>/etc/samba/smbpasswd</filename> (or <filename>/usr/local/samba/lib/private/smbpasswd</filename> if
|
|
compiled using Samba Team default settings). The use of the <filename>/etc/passwd</filename> can be overridden
|
|
by alternative settings in the NSS <filename>/etc/nsswitch.conf</filename> file.
|
|
</para>
|
|
|
|
<para>
|
|
Some people have also reported that inconsistent subnet masks between the Samba server and the NT
|
|
client can cause this problem. Make sure that these are consistent for both client and server.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Account Disabled</title>
|
|
|
|
<para><quote>When I attempt to log in to a Samba domain from a NT4/W200x workstation,
|
|
I get a message about my account being disabled.</quote></para>
|
|
|
|
<para>
|
|
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>Domain Controller Unavailable</title>
|
|
|
|
<para><quote>Until a few minutes after Samba has started, clients get the error `Domain Controller Unavailable'</quote></para>
|
|
|
|
<para>
|
|
A domain controller has to announce its role on the network. This usually takes a while. Be patient for up to 15 minutes,
|
|
then try again.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Cannot Log onto Domain Member Workstation After Joining Domain</title>
|
|
|
|
<para>
|
|
<indexterm><primary>schannel</primary></indexterm>
|
|
<indexterm><primary>signing</primary></indexterm>
|
|
After successfully joining the domain, user logons fail with one of two messages: one to the
|
|
effect that the domain controller cannot be found; the other claims that the account does not
|
|
exist in the domain or that the password is incorrect. This may be due to incompatible
|
|
settings between the Windows client and the Samba-3 server for <emphasis>schannel</emphasis>
|
|
(secure channel) settings or <emphasis>smb signing</emphasis> settings. Check your Samba
|
|
settings for <emphasis>client schannel</emphasis>, <emphasis>server schannel</emphasis>,
|
|
<emphasis>client signing</emphasis>, <emphasis>server signing</emphasis> by executing:
|
|
<screen>
|
|
<command>testparm -v | grep channel</command> and looking for the value of these parameters.
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
Also use the MMC &smbmdash; Local Security Settings. This tool is available from the
|
|
Control Panel. The Policy settings are found in the Local Policies/Security Options area and are prefixed by
|
|
<emphasis>Secure Channel:..., and Digitally sign...</emphasis>.
|
|
</para>
|
|
|
|
<para>
|
|
It is important that these be set consistently with the Samba-3 server settings.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
</chapter>
|