mirror of
https://github.com/samba-team/samba.git
synced 2024-12-23 17:34:34 +03:00
655cd95f00
References are kept where the version number makes sense in the context. Andrew Bartlett Signed-off-by: Andrew Bartlett <abartlet@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org>
2866 lines
113 KiB
XML
2866 lines
113 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="unixclients">
|
|
<title>Adding Domain Member Servers and Clients</title>
|
|
|
|
<para><indexterm>
|
|
<primary>Open Magazine</primary>
|
|
</indexterm><indexterm>
|
|
<primary>survey</primary>
|
|
</indexterm>
|
|
The most frequently discussed Samba subjects over the past 2 years have focused around domain control and printing.
|
|
It is well known that Samba is a file and print server. A recent survey conducted by <emphasis>Open Magazine</emphasis> found
|
|
that of all respondents, 97 percent use Samba for file and print services, and 68 percent use Samba for Domain Control. See the
|
|
<ulink url="http://www.open-mag.com/cgi-bin/opencgi/surveys/survey.cgi?survey_name=samba">Open-Mag</ulink>
|
|
Web site for current information. The survey results as found on January 14, 2004, are shown in
|
|
<link linkend="ch09openmag"/>.
|
|
</para>
|
|
|
|
<figure id="ch09openmag">
|
|
<title>Open Magazine Samba Survey</title>
|
|
<imagefile scale="60">openmag</imagefile>
|
|
</figure>
|
|
|
|
<para>
|
|
While domain control is an exciting subject, basic file and print sharing remains the staple bread-and-butter
|
|
function that Samba provides. Yet this book may give the appearance of having focused too much on more
|
|
exciting aspects of Samba deployment. This chapter directs your attention to provide important information on
|
|
the addition of Samba servers into your present Windows network &smbmdash; whatever the controlling technology
|
|
may be. So let's get back to our good friends at Abmas.
|
|
</para>
|
|
|
|
<sect1>
|
|
<title>Introduction</title>
|
|
|
|
<para><indexterm>
|
|
<primary>Linux desktop</primary>
|
|
</indexterm><indexterm>
|
|
<primary>Domain Member</primary>
|
|
<secondary>server</secondary>
|
|
</indexterm>
|
|
Looking back over the achievements of the past year or two, daily events at Abmas are rather straightforward
|
|
with not too many distractions or problems. Your team is doing well, but a number of employees
|
|
are asking for Linux desktop systems. Your network has grown and demands additional domain member servers. Let's
|
|
get on with this; Christine and Stan are ready to go.
|
|
</para>
|
|
|
|
<para><indexterm>
|
|
<primary>Domain Member</primary>
|
|
<secondary>desktop</secondary>
|
|
</indexterm>
|
|
Stan is firmly in control of the department of the future, while Christine is enjoying a stable and
|
|
predictable network environment. It is time to add more servers and to add Linux desktops. It is
|
|
time to meet the demands of future growth and endure trial by fire.
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>Assignment Tasks</title>
|
|
|
|
<para><indexterm>
|
|
<primary>Active Directory</primary>
|
|
</indexterm>
|
|
You must now add UNIX/Linux domain member servers to your network. You have a friend who has a Windows 2003
|
|
Active Directory domain network who wants to add a Samba/Linux server and has asked Christine to help him
|
|
out. Your real objective is to help Christine to see more of the way the Microsoft world lives and use
|
|
her help to get validation that Samba really does live up to expectations.
|
|
</para>
|
|
|
|
<para>
|
|
Over the past 6 months, you have hired several new staff who want Linux on their desktops. You must integrate
|
|
these systems to make sure that Abmas is not building islands of technology. You ask Christine to
|
|
do likewise at Swodniw Biz NL (your friend's company) to help them to evaluate a Linux desktop. You want to make
|
|
the right decision, don't you?
|
|
</para>
|
|
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Dissection and Discussion</title>
|
|
|
|
<para>
|
|
<indexterm><primary>winbind</primary></indexterm>
|
|
Recent Samba mailing-list activity is witness to how many sites are using winbind. Some have no trouble
|
|
at all with it, yet to others the problems seem insurmountable. Periodically there are complaints concerning
|
|
an inability to achieve identical user and group IDs between Windows and UNIX environments.
|
|
</para>
|
|
|
|
<para>
|
|
You provide step-by-step implementations of the various tools that can be used for identity
|
|
resolution. You also provide working examples of solutions for integrated authentication for
|
|
both UNIX/Linux and Windows environments.
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>Technical Issues</title>
|
|
|
|
<para>
|
|
One of the great challenges we face when people ask us, <quote>What is the best way to solve
|
|
this problem?</quote> is to get beyond the facts so we not only can clearly comprehend
|
|
the immediate technical problem, but also can understand how needs may change.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>integrate</primary></indexterm>
|
|
There are a few facts we should note when dealing with the question of how best to
|
|
integrate UNIX/Linux clients and servers into a Windows networking environment:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>
|
|
<indexterm><primary>Domain Controller</primary></indexterm>
|
|
<indexterm><primary>authoritative</primary></indexterm>
|
|
<indexterm><primary>accounts</primary><secondary>authoritative</secondary></indexterm>
|
|
<indexterm><primary>PDC</primary></indexterm>
|
|
<indexterm><primary>BDC</primary></indexterm>
|
|
A domain controller (PDC or BDC) is always authoritative for all accounts in its domain.
|
|
This means that a BDC must (of necessity) be able to resolve all account UIDs and GIDs
|
|
to the same values that the PDC resolved them to.
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
<indexterm><primary>local accounts</primary></indexterm>
|
|
<indexterm><primary>Domain Member</primary><secondary>authoritative</secondary><tertiary>local accounts</tertiary></indexterm>
|
|
<indexterm><primary>Domain accounts</primary></indexterm>
|
|
<indexterm><primary>winbindd</primary></indexterm>
|
|
A domain member can be authoritative for local accounts, but is never authoritative for
|
|
domain accounts. If a user is accessing a domain member server and that user's account
|
|
is not known locally, the domain member server must resolve the identity of that user
|
|
from the domain in which that user's account resides. It must then map that ID to a
|
|
UID/GID pair that it can use locally. This is handled by <command>winbindd</command>.
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
Samba, when running on a domain member server, can resolve user identities from a
|
|
number of sources:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>
|
|
<indexterm><primary>getpwnam</primary></indexterm>
|
|
<indexterm><primary>getgrnam</primary></indexterm>
|
|
<indexterm><primary>NSS</primary></indexterm>
|
|
<indexterm><primary>LDAP</primary></indexterm>
|
|
<indexterm><primary>NIS</primary></indexterm>
|
|
By executing a system <command>getpwnam()</command> or <command>getgrnam()</command> call.
|
|
On systems that support it, this utilizes the name service switch (NSS) facility to
|
|
resolve names according to the configuration of the <filename>/etc/nsswitch.conf</filename>
|
|
file. NSS can be configured to use LDAP, winbind, NIS, or local files.
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
<indexterm><primary>passdb backend</primary></indexterm>
|
|
<indexterm><primary>PADL</primary></indexterm>
|
|
<indexterm><primary>nss_ldap</primary></indexterm>
|
|
Performing, via NSS, a direct LDAP search (where an LDAP passdb backend has been configured).
|
|
This requires the use of the PADL nss_ldap tool (or equivalent).
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
<indexterm><primary>winbindd</primary></indexterm>
|
|
<indexterm><primary>SID</primary></indexterm>
|
|
<indexterm><primary>winbindd_idmap.tdb</primary></indexterm>
|
|
<indexterm><primary>winbindd_cache.tdb</primary></indexterm>
|
|
Directly by querying <command>winbindd</command>. The <command>winbindd</command>
|
|
contacts a domain controller to attempt to resolve the identity of the user or group. It
|
|
receives the Windows networking security identifier (SID) for that appropriate
|
|
account and then allocates a local UID or GID from the range of available IDs and
|
|
creates an entry in its <filename>winbindd_idmap.tdb</filename> and
|
|
<filename>winbindd_cache.tdb</filename> files.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>idmap backend</primary></indexterm>
|
|
<indexterm><primary>mapping</primary></indexterm>
|
|
If the parameter <smbconfoption name="idmap backend">ldap:ldap://myserver.domain</smbconfoption>
|
|
was specified and the LDAP server has been configured with a container in which it may
|
|
store the IDMAP entries, all domain members may share a common mapping.
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
Irrespective of how &smb.conf; is configured, winbind creates and caches a local copy of
|
|
the ID mapping database. It uses the <filename>winbindd_idmap.tdb</filename> and
|
|
<filename>winbindd_cache.tdb</filename> files to do this.
|
|
</para>
|
|
|
|
<para>
|
|
Which of the resolver methods is chosen is determined by the way that Samba is configured
|
|
in the &smb.conf; file. Some of the configuration options are rather less than obvious to the
|
|
casual user.
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
<indexterm><primary>winbind trusted domains only</primary></indexterm>
|
|
<indexterm><primary>domain member</primary><secondary>servers</secondary></indexterm>
|
|
<indexterm><primary>domain controllers</primary></indexterm>
|
|
If you wish to make use of accounts (users and/or groups) that are local to (i.e., capable
|
|
of being resolved using) the NSS facility, it is possible to use the
|
|
<smbconfoption name="winbind trusted domains only">Yes</smbconfoption>
|
|
in the &smb.conf; file. This parameter specifically applies to domain controllers,
|
|
and to domain member servers.
|
|
</para></listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
<indexterm><primary>Posix accounts</primary></indexterm>
|
|
<indexterm><primary>Samba accounts</primary></indexterm>
|
|
<indexterm><primary>LDAP</primary></indexterm>
|
|
For many administrators, it should be plain that the use of an LDAP-based repository for all network
|
|
accounts (both for POSIX accounts and for Samba accounts) provides the most elegant and
|
|
controllable facility. You eventually appreciate the decision to use LDAP.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>nss_ldap</primary></indexterm>
|
|
<indexterm><primary>identifiers</primary></indexterm>
|
|
<indexterm><primary>resolve</primary></indexterm>
|
|
If your network account information resides in an LDAP repository, you should use it ahead of any
|
|
alternative method. This means that if it is humanly possible to use the <command>nss_ldap</command>
|
|
tools to resolve UNIX account UIDs/GIDs via LDAP, this is the preferred solution, because it provides
|
|
a more readily controllable method for asserting the exact same user and group identifiers
|
|
throughout the network.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>Domain Member</primary><secondary>server</secondary></indexterm>
|
|
<indexterm><primary>winbind trusted domains only</primary></indexterm>
|
|
<indexterm><primary>getpwnam</primary></indexterm>
|
|
<indexterm><primary>smbd</primary></indexterm>
|
|
<indexterm><primary>Trusted Domains</primary></indexterm>
|
|
<indexterm><primary>External Domains</primary></indexterm>
|
|
In the situation where UNIX accounts are held on the domain member server itself, the only effective
|
|
way to use them involves the &smb.conf; entry
|
|
<smbconfoption name="winbind trusted domains only">Yes</smbconfoption>. This forces
|
|
Samba (<command>smbd</command>) to perform a <command>getpwnam()</command> system call that can
|
|
then be controlled via <filename>/etc/nsswitch.conf</filename> file settings. The use of this parameter
|
|
disables the use of Samba with trusted domains (i.e., external domains).
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>appliance mode</primary></indexterm>
|
|
<indexterm><primary>Domain Member</primary><secondary>server</secondary></indexterm>
|
|
<indexterm><primary>winbindd</primary></indexterm>
|
|
<indexterm><primary>automatically allocate</primary></indexterm>
|
|
Winbind can be used to create an appliance mode domain member server. In this capacity, <command>winbindd</command>
|
|
is configured to automatically allocate UIDs/GIDs from numeric ranges set in the &smb.conf; file. The allocation
|
|
is made for all accounts that connect to that domain member server, whether within its own domain or from
|
|
trusted domains. If not stored in an LDAP backend, each domain member maintains its own unique mapping database.
|
|
This means that it is almost certain that a given user who accesses two domain member servers does not have the
|
|
same UID/GID on both servers &smbmdash; however, this is transparent to the Windows network user. This data
|
|
is stored in the <filename>winbindd_idmap.tdb</filename> and <filename>winbindd_cache.tdb</filename> files.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>mapping</primary></indexterm>
|
|
The use of an LDAP backend for the Winbind IDMAP facility permits Windows domain SIDs
|
|
mappings to UIDs/GIDs to be stored centrally. The result is a consistent mapping across all domain member
|
|
servers so configured. This solves one of the major headaches for network administrators who need to copy
|
|
files between or across network file servers.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Political Issues</title>
|
|
|
|
<para>
|
|
<indexterm><primary>OpenLDAP</primary></indexterm>
|
|
<indexterm><primary>NIS</primary></indexterm>
|
|
<indexterm><primary>yellow pages</primary><see>NIS</see></indexterm>
|
|
<indexterm><primary>identity management</primary></indexterm>
|
|
One of the most fierce conflicts recently being waged is resistance to the adoption of LDAP, in
|
|
particular OpenLDAP, as a replacement for UNIX NIS (previously called Yellow Pages). Let's face it, LDAP
|
|
is different and requires a new approach to the need for a better identity management solution. The more
|
|
you work with LDAP, the more its power and flexibility emerges from its dark, cavernous chasm.
|
|
</para>
|
|
|
|
<para>
|
|
LDAP is a most suitable solution for heterogenous environments. If you need crypto, add Kerberos.
|
|
The reason these are preferable is because they are heterogenous. Windows solutions of this sort are <emphasis>not</emphasis>
|
|
heterogenous by design. This is fundamental &smbmdash; it isn't religious or political. This also doesn't say that
|
|
you can't use Windows Active Directory in a heterogenous environment &smbmdash; it can be done, it just requires
|
|
commercial integration products. But it's not what Active Directory was designed for.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>directory</primary></indexterm>
|
|
<indexterm><primary>management</primary></indexterm>
|
|
A number of long-term UNIX devotees have recently commented in various communications that the Samba Team
|
|
is the first application group to almost force network administrators to use LDAP. It should be pointed
|
|
out that we resisted this for as long as we could. It is not out of laziness or malice that LDAP has
|
|
finally emerged as the preferred identity management backend for Samba. We recommend LDAP for your total
|
|
organizational directory needs.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Implementation</title>
|
|
|
|
<para>
|
|
<indexterm><primary>Domain Member</primary><secondary>server</secondary></indexterm>
|
|
<indexterm><primary>Domain Member</primary><secondary>client</secondary></indexterm>
|
|
<indexterm><primary>Domain Controller</primary></indexterm>
|
|
The domain member server and the domain member client are at the center of focus in this chapter.
|
|
Configuration of Samba domain controller is covered in earlier chapters, so if your
|
|
interest is in domain controller configuration, you will not find that here. You will find good
|
|
oil that helps you to add domain member servers and clients.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>Domain Member</primary><secondary>workstations</secondary></indexterm>
|
|
In practice, domain member servers and domain member workstations are very different entities, but in
|
|
terms of technology they share similar core infrastructure. A technologist would argue that servers
|
|
and workstations are identical. Many users would argue otherwise, given that in a well-disciplined
|
|
environment a workstation (client) is a device from which a user creates documents and files that
|
|
are located on servers. A workstation is frequently viewed as a disposable (easy to replace) item,
|
|
but a server is viewed as a core component of the business.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>workstation</primary></indexterm>
|
|
We can look at this another way. If a workstation breaks down, one user is affected, but if a
|
|
server breaks down, hundreds of users may not be able to work. The services that a workstation
|
|
must provide are document- and file-production oriented; a server provides information storage
|
|
and is distribution oriented.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>authentication process</primary></indexterm>
|
|
<indexterm><primary>logon process</primary></indexterm>
|
|
<indexterm><primary>user identities</primary></indexterm>
|
|
<emphasis>Why is this important?</emphasis> For starters, we must identify what
|
|
components of the operating system and its environment must be configured. Also, it is necessary
|
|
to recognize where the interdependencies between the various services to be used are.
|
|
In particular, it is important to understand the operation of each critical part of the
|
|
authentication process, the logon process, and how user identities get resolved and applied
|
|
within the operating system and applications (like Samba) that depend on this and may
|
|
actually contribute to it.
|
|
</para>
|
|
|
|
<para>
|
|
So, in this chapter we demonstrate how to implement the technology. It is done within a context of
|
|
what type of service need must be fulfilled.
|
|
</para>
|
|
|
|
<sect2 id="sdcsdmldap">
|
|
<title>Samba Domain with Samba Domain Member Server &smbmdash; Using NSS LDAP</title>
|
|
|
|
<para>
|
|
<indexterm><primary>ldapsam</primary></indexterm>
|
|
<indexterm><primary>ldapsam backend</primary></indexterm>
|
|
<indexterm><primary>IDMAP</primary></indexterm>
|
|
<indexterm><primary>mapping</primary><secondary>consistent</secondary></indexterm>
|
|
<indexterm><primary>winbindd</primary></indexterm>
|
|
<indexterm><primary>foreign SID</primary></indexterm>
|
|
In this example, it is assumed that you have Samba PDC/BDC servers. This means you are using
|
|
an LDAP ldapsam backend. We are adding to the LDAP backend database (directory)
|
|
containers for use by the IDMAP facility. This makes it possible to have globally consistent
|
|
mapping of SIDs to and from UIDs and GIDs. This means that it is necessary to run
|
|
<command>winbindd</command> as part of your configuration. The primary purpose of running
|
|
<command>winbindd</command> (within this operational context) is to permit mapping of foreign
|
|
SIDs (those not originating from the the local Samba server). Foreign SIDs can come from any
|
|
domain member client or server, or from Windows clients that do not belong to a domain. Another
|
|
way to explain the necessity to run <command>winbindd</command> is that Samba can locally
|
|
resolve only accounts that belong to the security context of its own machine SID. Winbind
|
|
handles all non-local SIDs and maps them to a local UID/GID value. The UID and GID are allocated
|
|
from the parameter values set in the &smb.conf; file for the <parameter>idmap uid</parameter> and
|
|
<parameter>idmap gid</parameter> ranges. Where LDAP is used, the mappings can be stored in LDAP
|
|
so that all domain member servers can use a consistent mapping.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>winbindd</primary></indexterm>
|
|
<indexterm><primary>getpwnam</primary></indexterm>
|
|
<indexterm><primary>NSS</primary></indexterm>
|
|
If your installation is accessed only from clients that are members of your own domain, and all
|
|
user accounts are present in a local passdb backend then it is not necessary to run
|
|
<command>winbindd</command>. The local passdb backend can be in smbpasswd, tdbsam, or in ldapsam.
|
|
</para>
|
|
|
|
<para>
|
|
It is possible to use a local passdb backend with any convenient means of resolving the POSIX
|
|
user and group account information. The POSIX information is usually obtained using the
|
|
<command>getpwnam()</command> system call. On NSS-enabled systems, the actual POSIX account
|
|
source can be provided from
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>
|
|
<indexterm><primary>/etc/passwd</primary></indexterm>
|
|
<indexterm><primary>/etc/group</primary></indexterm>
|
|
Accounts in <filename>/etc/passwd</filename> or in <filename>/etc/group</filename>.
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
<indexterm><primary>NSS</primary></indexterm>
|
|
<indexterm><primary>compat</primary></indexterm>
|
|
<indexterm><primary>ldap</primary></indexterm>
|
|
<indexterm><primary>nis</primary></indexterm>
|
|
<indexterm><primary>nisplus</primary></indexterm>
|
|
<indexterm><primary>hesiod</primary></indexterm>
|
|
<indexterm><primary>ldap</primary></indexterm>
|
|
<indexterm><primary>nss_ldap</primary></indexterm>
|
|
<indexterm><primary>PADL Software</primary></indexterm>
|
|
Resolution via NSS. On NSS-enabled systems, there is usually a facility to resolve IDs
|
|
via multiple methods. The methods typically include <command>files</command>,
|
|
<command>compat</command>, <command>db</command>, <command>ldap</command>,
|
|
<command>nis</command>, <command>nisplus</command>, <command>hesiod.</command> When
|
|
correctly installed, Samba adds to this list the <command>winbindd</command> facility.
|
|
The ldap facility is frequently the nss_ldap tool provided by PADL Software.
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<note><para>
|
|
To advoid confusion the use of the term <literal>local passdb backend</literal> means that
|
|
the user account backend is not shared by any other Samba server &smbmdash; instead, it is
|
|
used only locally on the Samba domain member server under discussion.
|
|
</para></note>
|
|
|
|
<para>
|
|
<indexterm><primary>Identity resolution</primary></indexterm>
|
|
The diagram in <link linkend="ch9-sambadc"/> demonstrates the relationship of Samba and system
|
|
components that are involved in the identity resolution process where Samba is used as a domain
|
|
member server within a Samba domain control network.
|
|
</para>
|
|
|
|
<figure id="ch9-sambadc">
|
|
<title>Samba Domain: Samba Member Server</title>
|
|
<imagefile scale="60">chap9-SambaDC</imagefile>
|
|
</figure>
|
|
|
|
<para>
|
|
<indexterm><primary>IDMAP</primary></indexterm>
|
|
<indexterm><primary>foreign</primary></indexterm>
|
|
In this example configuration, Samba will directly search the LDAP-based passwd backend ldapsam
|
|
to obtain authentication and user identity information. The IDMAP information is stored in the LDAP
|
|
backend so that it can be shared by all domain member servers so that every user will have a
|
|
consistent UID and GID across all of them. The IDMAP facility will be used for all foreign
|
|
(i.e., not having the same SID as the domain it is a member of) domains. The configuration of
|
|
NSS will ensure that all UNIX processes will obtain a consistent UID/GID.
|
|
</para>
|
|
|
|
<para>
|
|
The instructions given here apply to the Samba environment shown in <link linkend="happy"/> and <link linkend="net2000users"/>.
|
|
If the network does not have an LDAP slave server (i.e., <link linkend="happy"/> configuration),
|
|
change the target LDAP server from <constant>lapdc</constant> to <constant>massive.</constant>
|
|
</para>
|
|
|
|
<procedure>
|
|
<title>Configuration of NSS_LDAP-Based Identity Resolution</title>
|
|
|
|
<step><para>
|
|
Create the &smb.conf; file as shown in <link linkend="ch9-sdmsdc"/>. Locate
|
|
this file in the directory <filename>/etc/samba</filename>.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
<indexterm><primary>ldap.conf</primary></indexterm>
|
|
Configure the file that will be used by <constant>nss_ldap</constant> to
|
|
locate and communicate with the LDAP server. This file is called <filename>ldap.conf</filename>.
|
|
If your implementation of <constant>nss_ldap</constant> is consistent with
|
|
the defaults suggested by PADL (the authors), it will be located in the
|
|
<filename>/etc</filename> directory. On some systems, the default location is
|
|
the <filename>/etc/openldap</filename> directory, however this file is intended
|
|
for use by the OpenLDAP utilities and should not really be used by the nss_ldap
|
|
utility since its content and structure serves the specific purpose of enabling
|
|
the resolution of user and group IDs via NSS.
|
|
</para>
|
|
|
|
<para>
|
|
Change the parameters inside the file that is located on your OS so it matches
|
|
<link linkend="ch9-sdmlcnf"/>. To find the correct location of this file, you
|
|
can obtain this from the library that will be used by executing the following:
|
|
<screen>
|
|
&rootprompt; strings /lib/libnss_ldap* | grep ldap.conf
|
|
/etc/ldap.conf
|
|
</screen>
|
|
</para></step>
|
|
|
|
<step><para>
|
|
Configure the NSS control file so it matches the one shown in
|
|
<link linkend="ch9-sdmnss"/>.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
<indexterm><primary>Identity resolution</primary></indexterm>
|
|
<indexterm><primary>getent</primary></indexterm>
|
|
Before proceeding to configure Samba, validate the operation of the NSS identity
|
|
resolution via LDAP by executing:
|
|
<screen>
|
|
&rootprompt; getent passwd
|
|
...
|
|
root:x:0:512:Netbios Domain Administrator:/root:/bin/false
|
|
nobody:x:999:514:nobody:/dev/null:/bin/false
|
|
bobj:x:1000:513:Robert Jordan:/home/bobj:/bin/bash
|
|
stans:x:1001:513:Stanley Soroka:/home/stans:/bin/bash
|
|
chrisr:x:1002:513:Christine Roberson:/home/chrisr:/bin/bash
|
|
maryv:x:1003:513:Mary Vortexis:/home/maryv:/bin/bash
|
|
jht:x:1004:513:John H Terpstra:/home/jht:/bin/bash
|
|
bldg1$:x:1006:553:bldg1$:/dev/null:/bin/false
|
|
temptation$:x:1009:553:temptation$:/dev/null:/bin/false
|
|
vaioboss$:x:1005:553:vaioboss$:/dev/null:/bin/false
|
|
fran$:x:1008:553:fran$:/dev/null:/bin/false
|
|
josephj:x:1007:513:Joseph James:/home/josephj:/bin/bash
|
|
</screen>
|
|
You should notice the location of the users' home directories. First, make certain that
|
|
the home directories exist on the domain member server; otherwise, the home directory
|
|
share is not available. The home directories could be mounted off a domain controller
|
|
using NFS or by any other suitable means. Second, the absence of the domain name in the
|
|
home directory path is indicative that identity resolution is not being done via winbind.
|
|
<screen>
|
|
&rootprompt; getent group
|
|
...
|
|
Domain Admins:x:512:root,jht
|
|
Domain Users:x:513:bobj,stans,chrisr,maryv,jht,josephj
|
|
Domain Guests:x:514:
|
|
Accounts:x:1000:
|
|
Finances:x:1001:
|
|
PIOps:x:1002:
|
|
sammy:x:4321:
|
|
</screen>
|
|
<indexterm><primary>secondary group</primary></indexterm>
|
|
<indexterm><primary>primary group</primary></indexterm>
|
|
<indexterm><primary>group membership</primary></indexterm>
|
|
This shows that all is working as it should be. Notice that in the LDAP database
|
|
the users' primary and secondary group memberships are identical. It is not
|
|
necessary to add secondary group memberships (in the group database) if the
|
|
user is already a member via primary group membership in the password database.
|
|
When using winbind, it is in fact undesirable to do this because it results in
|
|
doubling up of group memberships and may cause problems with winbind under certain
|
|
conditions. It is intended that these limitations with winbind will be resolved soon
|
|
after Samba-3.0.20 has been released.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
<indexterm><primary>slapcat</primary></indexterm>
|
|
The LDAP directory must have a container object for IDMAP data. There are several ways you can
|
|
check that your LDAP database is able to receive IDMAP information. One of the simplest is to
|
|
execute:
|
|
<screen>
|
|
&rootprompt; slapcat | grep -i idmap
|
|
dn: ou=Idmap,dc=abmas,dc=biz
|
|
ou: idmap
|
|
</screen>
|
|
<indexterm><primary>ldapadd</primary></indexterm>
|
|
If the execution of this command does not return IDMAP entries, you need to create an LDIF
|
|
template file (see <link linkend="ch9-ldifadd"/>). You can add the required entries using
|
|
the following command:
|
|
<screen>
|
|
&rootprompt; ldapadd -x -D "cn=Manager,dc=abmas,dc=biz" \
|
|
-w not24get < /etc/openldap/idmap.LDIF
|
|
</screen>
|
|
</para></step>
|
|
|
|
<step><para>
|
|
Samba automatically populates the LDAP directory container when it needs to. To permit Samba
|
|
write access to the LDAP directory it is necessary to set the LDAP administrative password
|
|
in the <filename>secrets.tdb</filename> file as shown here:
|
|
<screen>
|
|
&rootprompt; smbpasswd -w not24get
|
|
</screen>
|
|
</para></step>
|
|
|
|
<step><para>
|
|
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm>
|
|
<indexterm><primary>Domain join</primary></indexterm>
|
|
The system is ready to join the domain. Execute the following:
|
|
<screen>
|
|
&rootprompt; net rpc join -U root%not24get
|
|
Joined domain MEGANET2.
|
|
</screen>
|
|
This indicates that the domain join succeeded.
|
|
</para>
|
|
|
|
<para>
|
|
Failure to join the domain could be caused by any number of variables. The most common
|
|
causes of failure to join are:
|
|
</para>
|
|
|
|
<para>
|
|
<itemizedlist>
|
|
<listitem><para>Broken resolution of NetBIOS names to the respective IP address.</para></listitem>
|
|
<listitem><para>Incorrect username and password credentials.</para></listitem>
|
|
<listitem><para>The NT4 <parameter>restrict anonymous</parameter> is set to exclude anonymous
|
|
connections.</para></listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
<para>
|
|
The connection setup can be diagnosed by executing:
|
|
<screen>
|
|
&rootprompt; net rpc join -S 'pdc-name' -U administrator%password -d 5
|
|
</screen>
|
|
<indexterm><primary>failed</primary></indexterm>
|
|
<indexterm><primary>failed join</primary></indexterm>
|
|
<indexterm><primary>rejected</primary></indexterm>
|
|
<indexterm><primary>restrict anonymous</primary></indexterm>
|
|
Note: Use "root" for UNIX/Linux and Samba, use "Administrator" for Windows NT4/200X. If the cause of
|
|
the failure appears to be related to a rejected or failed NT_SESSION_SETUP* or an error message that
|
|
says NT_STATUS_ACCESS_DENIED immediately check the Windows registry setting that controls the
|
|
<constant>restrict anonymous</constant> setting. Set this to the value 0 so that an anonymous connection
|
|
can be sustained, then try again.
|
|
</para>
|
|
|
|
<para>
|
|
It is possible (perhaps even recommended) to use the following to validate the ability to connect
|
|
to an NT4 PDC/BDC:
|
|
<screen>
|
|
&rootprompt; net rpc info -S 'pdc-name' -U Administrator%not24get
|
|
Domain Name: MEGANET2
|
|
Domain SID: S-1-5-21-422319763-4138913805-7168186429
|
|
Sequence number: 1519909596
|
|
Num users: 7003
|
|
Num domain groups: 821
|
|
Num local groups: 8
|
|
|
|
&rootprompt; net rpc testjoin -S 'pdc-name' -U Administrator%not24get
|
|
Join to 'MEGANET2' is OK
|
|
</screen>
|
|
If for any reason the following response is obtained to the last command above,it is time to
|
|
call in the Networking Super-Snooper task force (i.e., start debugging):
|
|
<screen>
|
|
NT_STATUS_ACCESS_DENIED
|
|
Join to 'MEGANET2' failed.
|
|
</screen>
|
|
</para></step>
|
|
|
|
<step><para>
|
|
<indexterm><primary>wbinfo</primary></indexterm>
|
|
Just joining the domain is not quite enough; you must now provide a privileged set
|
|
of credentials through which <command>winbindd</command> can interact with the
|
|
domain servers. Execute the following to implant the necessary credentials:
|
|
<screen>
|
|
&rootprompt; wbinfo --set-auth-user=Administrator%not24get
|
|
</screen>
|
|
The configuration is now ready to obtain the Samba domain user and group information.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
You may now start Samba in the usual manner, and your Samba domain member server
|
|
is ready for use. Just add shares as required.
|
|
</para></step>
|
|
|
|
</procedure>
|
|
|
|
<example id="ch9-sdmsdc">
|
|
<title>Samba Domain Member in Samba Domain Using LDAP &smbmdash; &smb.conf; File</title>
|
|
<smbconfblock>
|
|
<smbconfcomment>Global parameters</smbconfcomment>
|
|
<smbconfsection name="[global]"/>
|
|
<smbconfoption name="unix charset">LOCALE</smbconfoption>
|
|
<smbconfoption name="workgroup">MEGANET2</smbconfoption>
|
|
<smbconfoption name="security">DOMAIN</smbconfoption>
|
|
<smbconfoption name="username map">/etc/samba/smbusers</smbconfoption>
|
|
<smbconfoption name="log level">10</smbconfoption>
|
|
<smbconfoption name="syslog">0</smbconfoption>
|
|
<smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
|
|
<smbconfoption name="max log size">50</smbconfoption>
|
|
<smbconfoption name="smb ports">139</smbconfoption>
|
|
<smbconfoption name="name resolve order">wins bcast hosts</smbconfoption>
|
|
<smbconfoption name="printcap name">CUPS</smbconfoption>
|
|
<smbconfoption name="wins server">192.168.2.1</smbconfoption>
|
|
<smbconfoption name="ldap suffix">dc=abmas,dc=biz</smbconfoption>
|
|
<smbconfoption name="ldap machine suffix">ou=People</smbconfoption>
|
|
<smbconfoption name="ldap user suffix">ou=People</smbconfoption>
|
|
<smbconfoption name="ldap group suffix">ou=Groups</smbconfoption>
|
|
<smbconfoption name="ldap idmap suffix">ou=Idmap</smbconfoption>
|
|
<smbconfoption name="ldap admin dn">cn=Manager,dc=abmas,dc=biz</smbconfoption>
|
|
<smbconfoption name="idmap backend">ldap:ldap://lapdc.abmas.biz</smbconfoption>
|
|
<smbconfoption name="idmap uid">10000-20000</smbconfoption>
|
|
<smbconfoption name="idmap gid">10000-20000</smbconfoption>
|
|
<smbconfoption name="winbind trusted domains only">Yes</smbconfoption>
|
|
<smbconfoption name="printing">cups</smbconfoption>
|
|
|
|
<smbconfsection name="[homes]"/>
|
|
<smbconfoption name="comment">Home Directories</smbconfoption>
|
|
<smbconfoption name="valid users">%S</smbconfoption>
|
|
<smbconfoption name="read only">No</smbconfoption>
|
|
<smbconfoption name="browseable">No</smbconfoption>
|
|
|
|
<smbconfsection name="[printers]"/>
|
|
<smbconfoption name="comment">SMB Print Spool</smbconfoption>
|
|
<smbconfoption name="path">/var/spool/samba</smbconfoption>
|
|
<smbconfoption name="guest ok">Yes</smbconfoption>
|
|
<smbconfoption name="printable">Yes</smbconfoption>
|
|
<smbconfoption name="browseable">No</smbconfoption>
|
|
|
|
<smbconfsection name="[print$]"/>
|
|
<smbconfoption name="comment">Printer Drivers</smbconfoption>
|
|
<smbconfoption name="path">/var/lib/samba/drivers</smbconfoption>
|
|
<smbconfoption name="admin users">root, Administrator</smbconfoption>
|
|
<smbconfoption name="write list">root</smbconfoption>
|
|
</smbconfblock>
|
|
</example>
|
|
|
|
<example id="ch9-ldifadd">
|
|
<title>LDIF IDMAP Add-On Load File &smbmdash; File: /etc/openldap/idmap.LDIF</title>
|
|
<screen>
|
|
dn: ou=Idmap,dc=abmas,dc=biz
|
|
objectClass: organizationalUnit
|
|
ou: idmap
|
|
structuralObjectClass: organizationalUnit
|
|
</screen>
|
|
</example>
|
|
|
|
<example id="ch9-sdmlcnf">
|
|
<title>Configuration File for NSS LDAP Support &smbmdash; <filename>/etc/ldap.conf</filename></title>
|
|
<screen>
|
|
URI ldap://massive.abmas.biz ldap://massive.abmas.biz:636
|
|
host 192.168.2.1
|
|
base dc=abmas,dc=biz
|
|
binddn cn=Manager,dc=abmas,dc=biz
|
|
bindpw not24get
|
|
|
|
pam_password exop
|
|
|
|
nss_base_passwd ou=People,dc=abmas,dc=biz?one
|
|
nss_base_shadow ou=People,dc=abmas,dc=biz?one
|
|
nss_base_group ou=Groups,dc=abmas,dc=biz?one
|
|
ssl no
|
|
</screen>
|
|
</example>
|
|
|
|
<example id="ch9-sdmnss">
|
|
<title>NSS using LDAP for Identity Resolution &smbmdash; File: <filename>/etc/nsswitch.conf</filename></title>
|
|
<screen>
|
|
passwd: files ldap
|
|
shadow: files ldap
|
|
group: files ldap
|
|
|
|
hosts: files dns wins
|
|
networks: files dns
|
|
|
|
services: files
|
|
protocols: files
|
|
rpc: files
|
|
ethers: files
|
|
netmasks: files
|
|
netgroup: files
|
|
publickey: files
|
|
|
|
bootparams: files
|
|
automount: files
|
|
aliases: files
|
|
</screen>
|
|
</example>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="wdcsdm">
|
|
<title>NT4/Samba Domain with Samba Domain Member Server: Using NSS and Winbind</title>
|
|
|
|
<para>
|
|
You need to use this method for creating a Samba domain member server if any of the following conditions
|
|
prevail:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>
|
|
LDAP support (client) is not installed on the system.
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
There are mitigating circumstances forcing a decision not to use LDAP.
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
The Samba domain member server must be part of a Windows NT4 Domain, or a Samba Domain.
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
<indexterm><primary>Windows ADS Domain</primary></indexterm>
|
|
<indexterm><primary>Samba Domain</primary></indexterm>
|
|
<indexterm><primary>LDAP</primary></indexterm>
|
|
Later in the chapter, you can see how to configure a Samba domain member server for a Windows ADS domain.
|
|
Right now your objective is to configure a Samba server that can be a member of a Windows NT4-style
|
|
domain and/or does not use LDAP.
|
|
</para>
|
|
|
|
<note><para>
|
|
<indexterm><primary>duplicate accounts</primary></indexterm>
|
|
If you use <command>winbind</command> for identity resolution, make sure that there are no
|
|
duplicate accounts.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>/etc/passwd</primary></indexterm>
|
|
For example, do not have more than one account that has UID=0 in the password database. If there
|
|
is an account called <constant>root</constant> in the <filename>/etc/passwd</filename> database,
|
|
it is okay to have an account called <constant>root</constant> in the LDAP ldapsam or in the
|
|
tdbsam. But if there are two accounts in the passdb backend that have the same UID, winbind will
|
|
break. This means that the <constant>Administrator</constant> account must be called
|
|
<constant>root</constant>.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>/etc/passwd</primary></indexterm>
|
|
<indexterm><primary>ldapsam</primary></indexterm>
|
|
<indexterm><primary>tdbsam</primary></indexterm>
|
|
Winbind will break if there is an account in <filename>/etc/passwd</filename> that has
|
|
the same UID as an account that is in LDAP ldapsam (or in tdbsam) but that differs in name only.
|
|
</para></note>
|
|
|
|
<para>
|
|
<indexterm><primary>credentials</primary></indexterm>
|
|
<indexterm><primary>traverse</primary></indexterm>
|
|
<indexterm><primary>wide-area</primary></indexterm>
|
|
<indexterm><primary>network</primary><secondary>wide-area</secondary></indexterm>
|
|
<indexterm><primary>tdbdump</primary></indexterm>
|
|
The following configuration uses CIFS/SMB protocols alone to obtain user and group credentials.
|
|
The winbind information is locally cached in the <filename>winbindd_cache.tdb winbindd_idmap.tdb</filename>
|
|
files. This provides considerable performance benefits compared with the LDAP solution, particularly
|
|
where the LDAP lookups must traverse WAN links. You may examine the contents of these
|
|
files using the tool <command>tdbdump</command>, though you may have to build this from the Samba
|
|
source code if it has not been supplied as part of a binary package distribution that you may be using.
|
|
</para>
|
|
|
|
<procedure>
|
|
<title>Configuration of Winbind-Based Identity Resolution</title>
|
|
|
|
<step><para>
|
|
Using your favorite text editor, create the &smb.conf; file so it has the contents
|
|
shown in <link linkend="ch0-NT4DSDM"/>.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
<indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
|
|
Edit the <filename>/etc/nsswitch.conf</filename> so it has the entries shown in
|
|
<link linkend="ch9-sdmnss"/>.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm>
|
|
The system is ready to join the domain. Execute the following:
|
|
<screen>
|
|
net rpc join -U root%not2g4et
|
|
Joined domain MEGANET2.
|
|
</screen>
|
|
This indicates that the domain join succeed.
|
|
|
|
</para></step>
|
|
|
|
<step><para>
|
|
<indexterm><primary>winbind</primary></indexterm>
|
|
<indexterm><primary>wbinfo</primary></indexterm>
|
|
Validate operation of <command>winbind</command> using the <command>wbinfo</command>
|
|
tool as follows:
|
|
<screen>
|
|
&rootprompt; wbinfo -u
|
|
MEGANET2+root
|
|
MEGANET2+nobody
|
|
MEGANET2+jht
|
|
MEGANET2+maryv
|
|
MEGANET2+billr
|
|
MEGANET2+jelliott
|
|
MEGANET2+dbrady
|
|
MEGANET2+joeg
|
|
MEGANET2+balap
|
|
</screen>
|
|
This shows that domain users have been listed correctly.
|
|
<screen>
|
|
&rootprompt; wbinfo -g
|
|
MEGANET2+Domain Admins
|
|
MEGANET2+Domain Users
|
|
MEGANET2+Domain Guests
|
|
MEGANET2+Accounts
|
|
MEGANET2+Finances
|
|
MEGANET2+PIOps
|
|
</screen>
|
|
This shows that domain groups have been correctly obtained also.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
<indexterm><primary>NSS</primary></indexterm>
|
|
<indexterm><primary>getent</primary></indexterm>
|
|
<indexterm><primary>winbind</primary></indexterm>
|
|
The next step verifies that NSS is able to obtain this information
|
|
correctly from <command>winbind</command> also.
|
|
<screen>
|
|
&rootprompt; getent passwd
|
|
...
|
|
MEGANET2+root:x:10000:10001:NetBIOS Domain Admin:
|
|
/home/MEGANET2/root:/bin/bash
|
|
MEGANET2+nobody:x:10001:10001:nobody:
|
|
/home/MEGANET2/nobody:/bin/bash
|
|
MEGANET2+jht:x:10002:10001:John H Terpstra:
|
|
/home/MEGANET2/jht:/bin/bash
|
|
MEGANET2+maryv:x:10003:10001:Mary Vortexis:
|
|
/home/MEGANET2/maryv:/bin/bash
|
|
MEGANET2+billr:x:10004:10001:William Randalph:
|
|
/home/MEGANET2/billr:/bin/bash
|
|
MEGANET2+jelliott:x:10005:10001:John G Elliott:
|
|
/home/MEGANET2/jelliott:/bin/bash
|
|
MEGANET2+dbrady:x:10006:10001:Darren Brady:
|
|
/home/MEGANET2/dbrady:/bin/bash
|
|
MEGANET2+joeg:x:10007:10001:Joe Green:
|
|
/home/MEGANET2/joeg:/bin/bash
|
|
MEGANET2+balap:x:10008:10001:Bala Pillay:
|
|
/home/MEGANET2/balap:/bin/bash
|
|
</screen>
|
|
The user account information has been correctly obtained. This information has
|
|
been merged with the winbind template information configured in the &smb.conf; file.
|
|
<screen>
|
|
&rootprompt;# getent group
|
|
...
|
|
MEGANET2+Domain Admins:x:10000:MEGANET2+root,MEGANET2+jht
|
|
MEGANET2+Domain Users:x:10001:MEGANET2+jht,MEGANET2+maryv,\
|
|
MEGANET2+billr,MEGANET2+jelliott,MEGANET2+dbrady,\
|
|
MEGANET2+joeg,MEGANET2+balap
|
|
MEGANET2+Domain Guests:x:10002:MEGANET2+nobody
|
|
MEGANET2+Accounts:x:10003:
|
|
MEGANET2+Finances:x:10004:
|
|
MEGANET2+PIOps:x:10005:
|
|
</screen>
|
|
</para></step>
|
|
|
|
<step><para>
|
|
The Samba member server of a Windows NT4 domain is ready for use.
|
|
</para></step>
|
|
|
|
</procedure>
|
|
|
|
<example id="ch0-NT4DSDM">
|
|
<title>Samba Domain Member Server Using Winbind &smb.conf; File for NT4 Domain</title>
|
|
<smbconfblock>
|
|
<smbconfcomment>Global parameters</smbconfcomment>
|
|
<smbconfsection name="[global]"/>
|
|
<smbconfoption name="unix charset">LOCALE</smbconfoption>
|
|
<smbconfoption name="workgroup">MEGANET2</smbconfoption>
|
|
<smbconfoption name="security">DOMAIN</smbconfoption>
|
|
<smbconfoption name="username map">/etc/samba/smbusers</smbconfoption>
|
|
<smbconfoption name="log level">1</smbconfoption>
|
|
<smbconfoption name="syslog">0</smbconfoption>
|
|
<smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
|
|
<smbconfoption name="max log size">0</smbconfoption>
|
|
<smbconfoption name="smb ports">139</smbconfoption>
|
|
<smbconfoption name="name resolve order">wins bcast hosts</smbconfoption>
|
|
<smbconfoption name="printcap name">CUPS</smbconfoption>
|
|
<smbconfoption name="wins server">192.168.2.1</smbconfoption>
|
|
<smbconfoption name="idmap uid">10000-20000</smbconfoption>
|
|
<smbconfoption name="idmap gid">10000-20000</smbconfoption>
|
|
<smbconfoption name="template primary group">"Domain Users"</smbconfoption>
|
|
<smbconfoption name="template shell">/bin/bash</smbconfoption>
|
|
<smbconfoption name="winbind separator">+</smbconfoption>
|
|
<smbconfoption name="hosts allow">192.168.2., 192.168.3., 127.</smbconfoption>
|
|
<smbconfoption name="printing">cups</smbconfoption>
|
|
|
|
<smbconfsection name="[homes]"/>
|
|
<smbconfoption name="comment">Home Directories</smbconfoption>
|
|
<smbconfoption name="valid users">%S</smbconfoption>
|
|
<smbconfoption name="read only">No</smbconfoption>
|
|
<smbconfoption name="browseable">No</smbconfoption>
|
|
|
|
<smbconfsection name="[printers]"/>
|
|
<smbconfoption name="comment">SMB Print Spool</smbconfoption>
|
|
<smbconfoption name="path">/var/spool/samba</smbconfoption>
|
|
<smbconfoption name="guest ok">Yes</smbconfoption>
|
|
<smbconfoption name="printable">Yes</smbconfoption>
|
|
<smbconfoption name="browseable">No</smbconfoption>
|
|
|
|
<smbconfsection name="[print$]"/>
|
|
<smbconfoption name="comment">Printer Drivers</smbconfoption>
|
|
<smbconfoption name="path">/var/lib/samba/drivers</smbconfoption>
|
|
<smbconfoption name="admin users">root, Administrator</smbconfoption>
|
|
<smbconfoption name="write list">root</smbconfoption>
|
|
</smbconfblock>
|
|
</example>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="dcwonss">
|
|
<title>NT4/Samba Domain with Samba Domain Member Server without NSS Support</title>
|
|
|
|
<para>
|
|
No matter how many UNIX/Linux administrators there may be who believe that a UNIX operating
|
|
system that does not have NSS and PAM support to be outdated, the fact is there
|
|
are still many such systems in use today. Samba can be used without NSS support, but this
|
|
does limit it to the use of local user and group accounts only.
|
|
</para>
|
|
|
|
<para>
|
|
The following steps may be followed to implement Samba with support for local accounts.
|
|
In this configuration Samba is made a domain member server. All incoming connections
|
|
to the Samba server will cause the look-up of the incoming username. If the account
|
|
is found, it is used. If the account is not found, one will be automatically created
|
|
on the local machine so that it can then be used for all access controls.
|
|
</para>
|
|
|
|
<procedure>
|
|
<title>Configuration Using Local Accounts Only</title>
|
|
|
|
<step><para>
|
|
Using your favorite text editor, create the &smb.conf; file so it has the contents
|
|
shown in <link linkend="ch0-NT4DSCM"/>.
|
|
</para></step>
|
|
|
|
<step>
|
|
<para><indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm>
|
|
The system is ready to join the domain. Execute the following:
|
|
<screen>
|
|
net rpc join -U root%not24get
|
|
Joined domain MEGANET2.
|
|
</screen>
|
|
This indicates that the domain join succeed.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
Be sure to run all three Samba daemons: <command>smbd</command>, <command>nmbd</command>, <command>winbindd</command>.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
The Samba member server of a Windows NT4 domain is ready for use.
|
|
</para></step>
|
|
</procedure>
|
|
|
|
<example id="ch0-NT4DSCM">
|
|
<title>Samba Domain Member Server Using Local Accounts &smb.conf; File for NT4 Domain</title>
|
|
<smbconfblock>
|
|
<smbconfcomment>Global parameters</smbconfcomment>
|
|
<smbconfsection name="[global]"/>
|
|
<smbconfoption name="unix charset">LOCALE</smbconfoption>
|
|
<smbconfoption name="workgroup">MEGANET3</smbconfoption>
|
|
<smbconfoption name="netbios name">BSDBOX</smbconfoption>
|
|
<smbconfoption name="security">DOMAIN</smbconfoption>
|
|
<smbconfoption name="username map">/etc/samba/smbusers</smbconfoption>
|
|
<smbconfoption name="log level">1</smbconfoption>
|
|
<smbconfoption name="syslog">0</smbconfoption>
|
|
<smbconfoption name="add user script">/usr/sbin/useradd -m '%u'</smbconfoption>
|
|
<smbconfoption name="add machine script">/usr/sbin/useradd -M '%u'</smbconfoption>
|
|
<smbconfoption name="add group script">/usr/sbin/groupadd '%g'</smbconfoption>
|
|
<smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
|
|
<smbconfoption name="max log size">0</smbconfoption>
|
|
<smbconfoption name="smb ports">139</smbconfoption>
|
|
<smbconfoption name="name resolve order">wins bcast hosts</smbconfoption>
|
|
<smbconfoption name="printcap name">CUPS</smbconfoption>
|
|
<smbconfoption name="wins server">192.168.2.1</smbconfoption>
|
|
<smbconfoption name="hosts allow">192.168.2., 192.168.3., 127.</smbconfoption>
|
|
<smbconfoption name="printing">cups</smbconfoption>
|
|
|
|
<smbconfsection name="[homes]"/>
|
|
<smbconfoption name="comment">Home Directories</smbconfoption>
|
|
<smbconfoption name="valid users">%S</smbconfoption>
|
|
<smbconfoption name="read only">No</smbconfoption>
|
|
<smbconfoption name="browseable">No</smbconfoption>
|
|
|
|
<smbconfsection name="[printers]"/>
|
|
<smbconfoption name="comment">SMB Print Spool</smbconfoption>
|
|
<smbconfoption name="path">/var/spool/samba</smbconfoption>
|
|
<smbconfoption name="guest ok">Yes</smbconfoption>
|
|
<smbconfoption name="printable">Yes</smbconfoption>
|
|
<smbconfoption name="browseable">No</smbconfoption>
|
|
|
|
<smbconfsection name="[print$]"/>
|
|
<smbconfoption name="comment">Printer Drivers</smbconfoption>
|
|
<smbconfoption name="path">/var/lib/samba/drivers</smbconfoption>
|
|
<smbconfoption name="admin users">root, Administrator</smbconfoption>
|
|
<smbconfoption name="write list">root</smbconfoption>
|
|
</smbconfblock>
|
|
</example>
|
|
</sect2>
|
|
|
|
<sect2 id="adssdm">
|
|
<title>Active Directory Domain with Samba Domain Member Server</title>
|
|
|
|
<para>
|
|
<indexterm><primary>Active Directory</primary><secondary>join</secondary></indexterm>
|
|
<indexterm><primary>Kerberos</primary></indexterm>
|
|
<indexterm><primary>Domain Member</primary><secondary>server</secondary></indexterm>
|
|
One of the much-sought-after features new to Samba is the ability to join an Active Directory
|
|
domain using Kerberos protocols. This makes it possible to operate an entire Windows network
|
|
without the need to run NetBIOS over TCP/IP and permits more secure networking in general. An
|
|
exhaustively complete discussion of the protocols is not possible in this book; perhaps a
|
|
later book may explore the intricacies of the NetBIOS-less operation that Samba can participate
|
|
in. For now, we simply focus on how a Samba server can be made a domain member server.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>Active Directory</primary></indexterm>
|
|
<indexterm><primary>LDAP</primary></indexterm>
|
|
<indexterm><primary>Identity resolution</primary></indexterm>
|
|
<indexterm><primary>Kerberos</primary></indexterm>
|
|
The diagram in <link linkend="ch9-adsdc"/> demonstrates how Samba interfaces with
|
|
Microsoft Active Directory components. It should be noted that if Microsoft Windows Services
|
|
for UNIX (SFU) has been installed and correctly configured, it is possible to use client LDAP
|
|
for identity resolution just as can be done with Samba when using an LDAP passdb backend.
|
|
The UNIX tool that you need for this, as in the case of LDAP on UNIX/Linux, is the PADL
|
|
Software nss_ldap tool-set. Compared with use of winbind and Kerberos, the use of
|
|
LDAP-based identity resolution is a little less secure. In view of the fact that this solution
|
|
requires additional software to be installed on the Windows 200x ADS domain controllers,
|
|
and that means more management overhead, it is likely that most Samba ADS client sites
|
|
may elect to use winbind.
|
|
</para>
|
|
|
|
<para>
|
|
Do not attempt to use this procedure if you are not 100 percent certain that the build of Samba
|
|
you are using has been compiled and linked with all the tools necessary for this to work.
|
|
Given the importance of this step, you must first validate that the Samba message block
|
|
daemon (<command>smbd</command>) has the necessary features.
|
|
</para>
|
|
|
|
<para>
|
|
The hypothetical domain you are using in this example assumes that the Abmas London office
|
|
decided to take its own lead (some would say this is a typical behavior in a global
|
|
corporate world; besides, a little divergence and conflict makes for an interesting life).
|
|
The Windows Server 2003 ADS domain is called <constant>london.abmas.biz</constant> and the
|
|
name of the server is <constant>W2K3S</constant>. In ADS realm terms, the domain controller
|
|
is known as <constant>w2k3s.london.abmas.biz</constant>. In NetBIOS nomenclature, the
|
|
domain name is <constant>LONDON</constant> and the server name is <constant>W2K3S</constant>.
|
|
</para>
|
|
|
|
<figure id="ch9-adsdc">
|
|
<title>Active Directory Domain: Samba Member Server</title>
|
|
<imagefile scale="60">chap9-ADSDC</imagefile>
|
|
</figure>
|
|
|
|
<procedure>
|
|
<title>Joining a Samba Server as an ADS Domain Member</title>
|
|
|
|
<step><para>
|
|
<indexterm><primary>smbd</primary></indexterm>
|
|
Before you try to use Samba, you want to know for certain that your executables have
|
|
support for Kerberos and for LDAP. Execute the following to identify whether or
|
|
not this build is perhaps suitable for use:
|
|
<screen>
|
|
&rootprompt; cd /usr/sbin
|
|
&rootprompt; smbd -b | grep KRB
|
|
HAVE_KRB5_H
|
|
HAVE_ADDR_TYPE_IN_KRB5_ADDRESS
|
|
HAVE_KRB5
|
|
HAVE_KRB5_AUTH_CON_SETKEY
|
|
HAVE_KRB5_GET_DEFAULT_IN_TKT_ETYPES
|
|
HAVE_KRB5_GET_PW_SALT
|
|
HAVE_KRB5_KEYBLOCK_KEYVALUE
|
|
HAVE_KRB5_KEYTAB_ENTRY_KEYBLOCK
|
|
HAVE_KRB5_MK_REQ_EXTENDED
|
|
HAVE_KRB5_PRINCIPAL_GET_COMP_STRING
|
|
HAVE_KRB5_SET_DEFAULT_IN_TKT_ETYPES
|
|
HAVE_KRB5_STRING_TO_KEY
|
|
HAVE_KRB5_STRING_TO_KEY_SALT
|
|
HAVE_LIBKRB5
|
|
</screen>
|
|
This output was obtained on a SUSE Linux system and shows the output for
|
|
Samba that has been compiled and linked with the Heimdal Kerberos libraries.
|
|
The following is a typical output that will be found on a Red Hat Linux system that
|
|
has been linked with the MIT Kerberos libraries:
|
|
<screen>
|
|
&rootprompt; cd /usr/sbin
|
|
&rootprompt; smbd -b | grep KRB
|
|
HAVE_KRB5_H
|
|
HAVE_ADDRTYPE_IN_KRB5_ADDRESS
|
|
HAVE_KRB5
|
|
HAVE_KRB5_AUTH_CON_SETUSERUSERKEY
|
|
HAVE_KRB5_ENCRYPT_DATA
|
|
HAVE_KRB5_FREE_DATA_CONTENTS
|
|
HAVE_KRB5_FREE_KTYPES
|
|
HAVE_KRB5_GET_PERMITTED_ENCTYPES
|
|
HAVE_KRB5_KEYTAB_ENTRY_KEY
|
|
HAVE_KRB5_LOCATE_KDC
|
|
HAVE_KRB5_MK_REQ_EXTENDED
|
|
HAVE_KRB5_PRINCIPAL2SALT
|
|
HAVE_KRB5_PRINC_COMPONENT
|
|
HAVE_KRB5_SET_DEFAULT_TGS_KTYPES
|
|
HAVE_KRB5_SET_REAL_TIME
|
|
HAVE_KRB5_STRING_TO_KEY
|
|
HAVE_KRB5_TKT_ENC_PART2
|
|
HAVE_KRB5_USE_ENCTYPE
|
|
HAVE_LIBGSSAPI_KRB5
|
|
HAVE_LIBKRB5
|
|
</screen>
|
|
You can validate that Samba has been compiled and linked with LDAP support
|
|
by executing:
|
|
<screen>
|
|
&rootprompt; smbd -b | grep LDAP
|
|
massive:/usr/sbin # smbd -b | grep LDAP
|
|
HAVE_LDAP_H
|
|
HAVE_LDAP
|
|
HAVE_LDAP_DOMAIN2HOSTLIST
|
|
HAVE_LDAP_INIT
|
|
HAVE_LDAP_INITIALIZE
|
|
HAVE_LDAP_SET_REBIND_PROC
|
|
HAVE_LIBLDAP
|
|
LDAP_SET_REBIND_PROC_ARGS
|
|
</screen>
|
|
This does look promising; <command>smbd</command> has been built with Kerberos and LDAP
|
|
support. You are relieved to know that it is safe to progress.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
<indexterm><primary>Kerberos</primary><secondary>libraries</secondary></indexterm>
|
|
<indexterm><primary>MIT Kerberos</primary></indexterm>
|
|
<indexterm><primary>Heimdal Kerberos</primary></indexterm>
|
|
<indexterm><primary>Kerberos</primary><secondary>MIT</secondary></indexterm>
|
|
<indexterm><primary>Kerberos</primary><secondary>Heimdal</secondary></indexterm>
|
|
<indexterm><primary>Red Hat Linux</primary></indexterm>
|
|
<indexterm><primary>SUSE Linux</primary></indexterm>
|
|
<indexterm><primary>SerNet</primary></indexterm>
|
|
<indexterm><primary>validated</primary></indexterm>
|
|
The next step is to identify which version of the Kerberos libraries have been used.
|
|
In order to permit Samba to interoperate with Windows 2003 Active Directory, it is
|
|
essential that it has been linked with either MIT Kerberos version 1.3.1 or later,
|
|
or that it has been linked with Heimdal Kerberos 0.6 plus specific patches. You may
|
|
identify what version of the MIT Kerberos libraries are installed on your system by
|
|
executing (on Red Hat Linux):
|
|
<screen>
|
|
&rootprompt; rpm -q krb5
|
|
</screen>
|
|
Or on SUSE Linux, execute:
|
|
<screen>
|
|
&rootprompt; rpm -q heimdal
|
|
</screen>
|
|
Please note that the RPMs provided by the Samba-Team are known to be working and have
|
|
been validated. Red Hat Linux RPMs may be obtained from the Samba FTP sites. SUSE
|
|
Linux RPMs may be obtained from <ulink url="ftp://ftp.sernet.de">Sernet</ulink> in
|
|
Germany.
|
|
</para>
|
|
|
|
<para>
|
|
From this point on, you are certain that the Samba build you are using has the
|
|
necessary capabilities. You can now configure Samba and the NSS.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
Using you favorite editor, configure the &smb.conf; file that is located in the
|
|
<filename>/etc/samba</filename> directory so that it has the contents shown
|
|
in <link linkend="ch9-adssdm"/>.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
Edit or create the NSS control file so it has the contents shown in <link linkend="ch9-sdmnss"/>.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
<indexterm><primary>/etc/samba/secrets.tdb</primary></indexterm>
|
|
Delete the file <filename>/etc/samba/secrets.tdb</filename> if it exists. Of course, you
|
|
do keep a backup, don't you?
|
|
</para></step>
|
|
|
|
<step><para>
|
|
Delete the tdb files that cache Samba information. You keep a backup of the old
|
|
files, of course. You also remove all files to ensure that nothing can pollute your
|
|
nice, new configuration. Execute the following (example is for SUSE Linux):
|
|
<screen>
|
|
&rootprompt; rm /var/lib/samba/*tdb
|
|
</screen>
|
|
</para></step>
|
|
|
|
<step><para>
|
|
<indexterm><primary>testparm</primary></indexterm>
|
|
Validate your &smb.conf; file using <command>testparm</command> (as you have
|
|
done previously). Correct all errors reported before proceeding. The command you
|
|
execute is:
|
|
<screen>
|
|
&rootprompt; testparm -s | less
|
|
</screen>
|
|
Now that you are satisfied that your Samba server is ready to join the Windows
|
|
ADS domain, let's move on.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
<indexterm><primary>net</primary><secondary>ads</secondary><tertiary>join</tertiary></indexterm>
|
|
<indexterm><primary>Kerberos</primary></indexterm>
|
|
This is a good time to double-check everything and then execute the following
|
|
command when everything you have done has checked out okay:
|
|
<screen>
|
|
&rootprompt; net ads join -UAdministrator%not24get
|
|
Using short domain name -- LONDON
|
|
Joined 'FRAN' to realm 'LONDON.ABMAS.BIZ'
|
|
</screen>
|
|
You have successfully made your Samba server a member of the ADS domain
|
|
using Kerberos protocols.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>silent return</primary></indexterm>
|
|
<indexterm><primary>failed join</primary></indexterm>
|
|
In the event that you receive no output messages, a silent return means that the
|
|
domain join failed. You should use <command>ethereal</command> to identify what
|
|
may be failing. Common causes of a failed join include:
|
|
|
|
<itemizedlist>
|
|
<listitem><para>
|
|
<indexterm><primary>name resolution</primary><secondary>Defective</secondary></indexterm>
|
|
Defective or misconfigured DNS name resolution.
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
<indexterm><primary>Restrictive security</primary></indexterm>
|
|
Restrictive security settings on the Windows 200x ADS domain controller
|
|
preventing needed communications protocols. You can check this by searching
|
|
the Windows Server 200x Event Viewer.
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
Incorrectly configured &smb.conf; file settings.
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
Lack of support of necessary Kerberos protocols because the version of MIT
|
|
Kerberos (or Heimdal) in use is not up to date enough to support the necessary
|
|
functionality.
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm>
|
|
<indexterm><primary>RPC</primary></indexterm>
|
|
<indexterm><primary>mixed mode</primary></indexterm>
|
|
In any case, never execute the <command>net rpc join</command> command in an attempt
|
|
to join the Samba server to the domain, unless you wish not to use the Kerberos
|
|
security protocols. Use of the older RPC-based domain join facility requires that
|
|
Windows Server 200x ADS has been configured appropriately for mixed mode operation.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
<indexterm><primary>tdbdump</primary></indexterm>
|
|
<indexterm><primary>/etc/samba/secrets.tdb</primary></indexterm>
|
|
If the <command>tdbdump</command> is installed on your system (not essential),
|
|
you can look inside the <filename>/etc/samba/secrets.tdb</filename> file. If
|
|
you wish to do this, execute:
|
|
<screen>
|
|
&rootprompt; tdbdump secrets.tdb
|
|
{
|
|
key = "SECRETS/SID/LONDON"
|
|
data = "\01\04\00\00\00\00\00\05\15\00\00\00\EBw\86\F1\ED\BD\
|
|
F6{\5C6\E5W\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\
|
|
00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\
|
|
00\00\00\00\00\00\00\00"
|
|
}
|
|
{
|
|
key = "SECRETS/MACHINE_PASSWORD/LONDON"
|
|
data = "le3Q5FPnN5.ueC\00"
|
|
}
|
|
{
|
|
key = "SECRETS/MACHINE_SEC_CHANNEL_TYPE/LONDON"
|
|
data = "\02\00\00\00"
|
|
}
|
|
{
|
|
key = "SECRETS/MACHINE_LAST_CHANGE_TIME/LONDON"
|
|
data = "E\89\F6?"
|
|
}
|
|
</screen>
|
|
This is given to demonstrate to the skeptics that this process truly does work.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
It is now time to start Samba in the usual way (as has been done many time before
|
|
in this book).
|
|
</para></step>
|
|
|
|
<step><para>
|
|
<indexterm><primary>wbinfo</primary></indexterm>
|
|
This is a good time to verify that everything is working. First, check that
|
|
winbind is able to obtain the list of users and groups from the ADS domain controller.
|
|
Execute the following:
|
|
<screen>
|
|
&rootprompt; wbinfo -u
|
|
LONDON+Administrator
|
|
LONDON+Guest
|
|
LONDON+SUPPORT_388945a0
|
|
LONDON+krbtgt
|
|
LONDON+jht
|
|
</screen>
|
|
Good, the list of users was obtained. Now do likewise for group accounts:
|
|
<screen>
|
|
&rootprompt; wbinfo -g
|
|
LONDON+Domain Computers
|
|
LONDON+Domain Controllers
|
|
LONDON+Schema Admins
|
|
LONDON+Enterprise Admins
|
|
LONDON+Domain Admins
|
|
LONDON+Domain Users
|
|
LONDON+Domain Guests
|
|
LONDON+Group Policy Creator Owners
|
|
LONDON+DnsUpdateProxy
|
|
</screen>
|
|
Excellent. That worked also, as expected.
|
|
</para></step>
|
|
|
|
<step><para><indexterm>
|
|
<primary>getent</primary>
|
|
</indexterm>
|
|
Now repeat this via NSS to validate that full identity resolution is
|
|
functional as required. Execute:
|
|
<screen>
|
|
&rootprompt; getent passwd
|
|
...
|
|
LONDON+Administrator:x:10000:10000:Administrator:
|
|
/home/LONDON/administrator:/bin/bash
|
|
LONDON+Guest:x:10001:10001:Guest:
|
|
/home/LONDON/guest:/bin/bash
|
|
LONDON+SUPPORT_388945a0:x:10002:10000:SUPPORT_388945a0:
|
|
/home/LONDON/support_388945a0:/bin/bash
|
|
LONDON+krbtgt:x:10003:10000:krbtgt:
|
|
/home/LONDON/krbtgt:/bin/bash
|
|
LONDON+jht:x:10004:10000:John H. Terpstra:
|
|
/home/LONDON/jht:/bin/bash
|
|
</screen>
|
|
Okay, ADS user accounts are being resolved. Now you try group resolution:
|
|
<screen>
|
|
&rootprompt; getent group
|
|
...
|
|
LONDON+Domain Computers:x:10002:
|
|
LONDON+Domain Controllers:x:10003:
|
|
LONDON+Schema Admins:x:10004:LONDON+Administrator
|
|
LONDON+Enterprise Admins:x:10005:LONDON+Administrator
|
|
LONDON+Domain Admins:x:10006:LONDON+jht,LONDON+Administrator
|
|
LONDON+Domain Users:x:10000:
|
|
LONDON+Domain Guests:x:10001:
|
|
LONDON+Group Policy Creator Owners:x:10007:LONDON+Administrator
|
|
LONDON+DnsUpdateProxy:x:10008:
|
|
</screen>
|
|
This is very pleasing. Everything works as expected.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
<indexterm><primary>net</primary><secondary>ads</secondary><tertiary>info</tertiary></indexterm>
|
|
<indexterm><primary>Active Directory</primary><secondary>server</secondary></indexterm>
|
|
<indexterm><primary>Kerberos</primary></indexterm>
|
|
You may now perform final verification that communications between Samba winbind and
|
|
the Active Directory server is using Kerberos protocols. Execute the following:
|
|
<screen>
|
|
&rootprompt; net ads info
|
|
LDAP server: 192.168.2.123
|
|
LDAP server name: w2k3s
|
|
Realm: LONDON.ABMAS.BIZ
|
|
Bind Path: dc=LONDON,dc=ABMAS,dc=BIZ
|
|
LDAP port: 389
|
|
Server time: Sat, 03 Jan 2004 02:44:44 GMT
|
|
KDC server: 192.168.2.123
|
|
Server time offset: 2
|
|
</screen>
|
|
It should be noted that Kerberos protocols are time-clock critical. You should
|
|
keep all server time clocks synchronized using the network time protocol (NTP).
|
|
In any case, the output we obtained confirms that all systems are operational.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
<indexterm><primary>net</primary><secondary>ads</secondary><tertiary>status</tertiary></indexterm>
|
|
There is one more action you elect to take, just because you are paranoid and disbelieving,
|
|
so you execute the following command:
|
|
<programlisting>
|
|
&rootprompt; net ads status -UAdministrator%not24get
|
|
objectClass: top
|
|
objectClass: person
|
|
objectClass: organizationalPerson
|
|
objectClass: user
|
|
objectClass: computer
|
|
cn: fran
|
|
distinguishedName: CN=fran,CN=Computers,DC=london,DC=abmas,DC=biz
|
|
instanceType: 4
|
|
whenCreated: 20040103092006.0Z
|
|
whenChanged: 20040103092006.0Z
|
|
uSNCreated: 28713
|
|
uSNChanged: 28717
|
|
name: fran
|
|
objectGUID: 58f89519-c467-49b9-acb0-f099d73696e
|
|
userAccountControl: 69632
|
|
badPwdCount: 0
|
|
codePage: 0
|
|
countryCode: 0
|
|
badPasswordTime: 0
|
|
lastLogoff: 0
|
|
lastLogon: 127175965783327936
|
|
localPolicyFlags: 0
|
|
pwdLastSet: 127175952062598496
|
|
primaryGroupID: 515
|
|
objectSid: S-1-5-21-4052121579-2079768045-1474639452-1109
|
|
accountExpires: 9223372036854775807
|
|
logonCount: 13
|
|
sAMAccountName: fran$
|
|
sAMAccountType: 805306369
|
|
operatingSystem: Samba
|
|
operatingSystemVersion: 3.0.20-SUSE
|
|
dNSHostName: fran
|
|
userPrincipalName: HOST/fran@LONDON.ABMAS.BIZ
|
|
servicePrincipalName: CIFS/fran.london.abmas.biz
|
|
servicePrincipalName: CIFS/fran
|
|
servicePrincipalName: HOST/fran.london.abmas.biz
|
|
servicePrincipalName: HOST/fran
|
|
objectCategory: CN=Computer,CN=Schema,CN=Configuration,
|
|
DC=london,DC=abmas,DC=biz
|
|
isCriticalSystemObject: FALSE
|
|
-------------- Security Descriptor (revision: 1, type: 0x8c14)
|
|
owner SID: S-1-5-21-4052121579-2079768045-1474639452-512
|
|
group SID: S-1-5-21-4052121579-2079768045-1474639452-513
|
|
------- (system) ACL (revision: 4, size: 120, number of ACEs: 2)
|
|
------- ACE (type: 0x07, flags: 0x5a, size: 0x38,
|
|
mask: 0x20, object flags: 0x3)
|
|
access SID: S-1-1-0
|
|
access type: AUDIT OBJECT
|
|
Permissions:
|
|
[Write All Properties]
|
|
------- ACE (type: 0x07, flags: 0x5a, size: 0x38,
|
|
mask: 0x20, object flags: 0x3)
|
|
access SID: S-1-1-0
|
|
access type: AUDIT OBJECT
|
|
Permissions:
|
|
[Write All Properties]
|
|
------- (user) ACL (revision: 4, size: 1944, number of ACEs: 40)
|
|
------- ACE (type: 0x00, flags: 0x00, size: 0x24, mask: 0xf01ff)
|
|
access SID: S-1-5-21-4052121579-2079768045-1474639452-512
|
|
access type: ALLOWED
|
|
Permissions: [Full Control]
|
|
------- ACE (type: 0x00, flags: 0x00, size: 0x18, mask: 0xf01ff)
|
|
access SID: S-1-5-32-548
|
|
...
|
|
------- ACE (type: 0x05, flags: 0x12, size: 0x38,
|
|
mask: 0x10, object flags: 0x3)
|
|
access SID: S-1-5-9
|
|
access type: ALLOWED OBJECT
|
|
Permissions:
|
|
[Read All Properties]
|
|
-------------- End Of Security Descriptor
|
|
</programlisting>
|
|
And now you have conclusive proof that your Samba ADS domain member server
|
|
called <constant>FRAN</constant> is able to communicate fully with the ADS
|
|
domain controllers.
|
|
</para></step>
|
|
|
|
</procedure>
|
|
|
|
|
|
<para>
|
|
Your Samba ADS domain member server is ready for use. During training sessions,
|
|
you may be asked what is inside the <filename>winbindd_cache.tdb and winbindd_idmap.tdb</filename>
|
|
files. Since curiosity just took hold of you, execute the following:
|
|
<programlisting>
|
|
&rootprompt; tdbdump /var/lib/samba/winbindd_idmap.tdb
|
|
{
|
|
key = "S-1-5-21-4052121579-2079768045-1474639452-501\00"
|
|
data = "UID 10001\00"
|
|
}
|
|
{
|
|
key = "UID 10005\00"
|
|
data = "S-1-5-21-4052121579-2079768045-1474639452-1111\00"
|
|
}
|
|
{
|
|
key = "GID 10004\00"
|
|
data = "S-1-5-21-4052121579-2079768045-1474639452-518\00"
|
|
}
|
|
{
|
|
key = "S-1-5-21-4052121579-2079768045-1474639452-502\00"
|
|
data = "UID 10003\00"
|
|
}
|
|
...
|
|
|
|
&rootprompt; tdbdump /var/lib/samba/winbindd_cache.tdb
|
|
{
|
|
key = "UL/LONDON"
|
|
data = "\00\00\00\00bp\00\00\06\00\00\00\0DAdministrator\0D
|
|
Administrator-S-1-5-21-4052121579-2079768045-1474639452-500-
|
|
S-1-5-21-4052121579-2079768045-1474639452-513\05Guest\05
|
|
Guest-S-1-5-21-4052121579-2079768045-1474639452-501-
|
|
S-1-5-21-4052121579-2079768045-1474639452-514\10
|
|
SUPPORT_388945a0\10SUPPORT_388945a0.
|
|
S-1-5-21-4052121579-2079768045-1474639452-1001-
|
|
S-1-5-21-4052121579-2079768045-1474639452-513\06krbtgt\06
|
|
krbtgt-S-1-5-21-4052121579-2079768045-1474639452-502-
|
|
S-1-5-21-4052121579-2079768045-1474639452-513\03jht\10
|
|
John H. Terpstra.S-1-5-21-4052121579-2079768045-1474639452-1110-
|
|
S-1-5-21-4052121579-2079768045-1474639452-513"
|
|
}
|
|
{
|
|
key = "GM/S-1-5-21-4052121579-2079768045-1474639452-512"
|
|
data = "\00\00\00\00bp\00\00\02\00\00\00.
|
|
S-1-5-21-4052121579-2079768045-1474639452-1110\03
|
|
jht\01\00\00\00-S-1-5-21-4052121579-2079768045-1474639452-500\0D
|
|
Administrator\01\00\00\00"
|
|
}
|
|
{
|
|
key = "SN/S-1-5-21-4052121579-2079768045-1474639452-513"
|
|
data = "\00\00\00\00xp\00\00\02\00\00\00\0CDomain Users"
|
|
}
|
|
{
|
|
key = "GM/S-1-5-21-4052121579-2079768045-1474639452-518"
|
|
data = "\00\00\00\00bp\00\00\01\00\00\00-
|
|
S-1-5-21-4052121579-2079768045-1474639452-500\0D
|
|
Administrator\01\00\00\00"
|
|
}
|
|
{
|
|
key = "SEQNUM/LONDON\00"
|
|
data = "xp\00\00C\92\F6?"
|
|
}
|
|
{
|
|
key = "U/S-1-5-21-4052121579-2079768045-1474639452-1110"
|
|
data = "\00\00\00\00xp\00\00\03jht\10John H. Terpstra.
|
|
S-1-5-21-4052121579-2079768045-1474639452-1110-
|
|
S-1-5-21-4052121579-2079768045-1474639452-513"
|
|
}
|
|
{
|
|
key = "NS/S-1-5-21-4052121579-2079768045-1474639452-502"
|
|
data = "\00\00\00\00bp\00\00-
|
|
S-1-5-21-4052121579-2079768045-1474639452-502"
|
|
}
|
|
{
|
|
key = "SN/S-1-5-21-4052121579-2079768045-1474639452-1001"
|
|
data = "\00\00\00\00bp\00\00\01\00\00\00\10SUPPORT_388945a0"
|
|
}
|
|
{
|
|
key = "SN/S-1-5-21-4052121579-2079768045-1474639452-500"
|
|
data = "\00\00\00\00bp\00\00\01\00\00\00\0DAdministrator"
|
|
}
|
|
{
|
|
key = "U/S-1-5-21-4052121579-2079768045-1474639452-502"
|
|
data = "\00\00\00\00bp\00\00\06krbtgt\06krbtgt-
|
|
S-1-5-21-4052121579-2079768045-1474639452-502-
|
|
S-1-5-21-4052121579-2079768045-1474639452-513"
|
|
}
|
|
....
|
|
</programlisting>
|
|
Now all is revealed. Your curiosity, as well as that of your team, has been put at ease.
|
|
May this server serve well all who happen upon it.
|
|
</para>
|
|
|
|
<example id="ch9-adssdm">
|
|
<title>Samba Domain Member &smb.conf; File for Active Directory Membership</title>
|
|
<smbconfblock>
|
|
<smbconfcomment>Global parameters</smbconfcomment>
|
|
<smbconfsection name="[global]"/>
|
|
<smbconfoption name="unix charset">LOCALE</smbconfoption>
|
|
<smbconfoption name="workgroup">LONDON</smbconfoption>
|
|
<smbconfoption name="realm">LONDON.ABMAS.BIZ</smbconfoption>
|
|
<smbconfoption name="server string">Samba 3.0.20</smbconfoption>
|
|
<smbconfoption name="security">ADS</smbconfoption>
|
|
<smbconfoption name="username map">/etc/samba/smbusers</smbconfoption>
|
|
<smbconfoption name="log level">1</smbconfoption>
|
|
<smbconfoption name="syslog">0</smbconfoption>
|
|
<smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
|
|
<smbconfoption name="max log size">50</smbconfoption>
|
|
<smbconfoption name="printcap name">CUPS</smbconfoption>
|
|
<smbconfoption name="ldap ssl">no</smbconfoption>
|
|
<smbconfoption name="idmap uid">10000-20000</smbconfoption>
|
|
<smbconfoption name="idmap gid">10000-20000</smbconfoption>
|
|
<smbconfoption name="template primary group">"Domain Users"</smbconfoption>
|
|
<smbconfoption name="template shell">/bin/bash</smbconfoption>
|
|
<smbconfoption name="winbind separator">+</smbconfoption>
|
|
<smbconfoption name="printing">cups</smbconfoption>
|
|
|
|
<smbconfsection name="[homes]"/>
|
|
<smbconfoption name="comment">Home Directories</smbconfoption>
|
|
<smbconfoption name="valid users">%S</smbconfoption>
|
|
<smbconfoption name="read only">No</smbconfoption>
|
|
<smbconfoption name="browseable">No</smbconfoption>
|
|
|
|
<smbconfsection name="[printers]"/>
|
|
<smbconfoption name="comment">SMB Print Spool</smbconfoption>
|
|
<smbconfoption name="path">/var/spool/samba</smbconfoption>
|
|
<smbconfoption name="guest ok">Yes</smbconfoption>
|
|
<smbconfoption name="printable">Yes</smbconfoption>
|
|
<smbconfoption name="browseable">No</smbconfoption>
|
|
|
|
<smbconfsection name="[print$]"/>
|
|
<smbconfoption name="comment">Printer Drivers</smbconfoption>
|
|
<smbconfoption name="path">/var/lib/samba/drivers</smbconfoption>
|
|
<smbconfoption name="admin users">root, Administrator</smbconfoption>
|
|
<smbconfoption name="write list">root</smbconfoption>
|
|
</smbconfblock>
|
|
</example>
|
|
|
|
<sect3>
|
|
<title>IDMAP_RID with Winbind</title>
|
|
|
|
<para>
|
|
<indexterm><primary>idmap_rid</primary></indexterm>
|
|
<indexterm><primary>SID</primary></indexterm>
|
|
<indexterm><primary>RID</primary></indexterm>
|
|
<indexterm><primary>IDMAP</primary></indexterm>
|
|
The <command>idmap_rid</command> facility is a new tool that, unlike native winbind, creates a
|
|
predictable mapping of MS Windows SIDs to UNIX UIDs and GIDs. The key benefit of this method
|
|
of implementing the Samba IDMAP facility is that it eliminates the need to store the IDMAP data
|
|
in a central place. The downside is that it can be used only within a single ADS domain and
|
|
is not compatible with trusted domain implementations.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>SID</primary></indexterm>
|
|
<indexterm><primary>allow trusted domains</primary></indexterm>
|
|
<indexterm><primary>idmap uid</primary></indexterm>
|
|
<indexterm><primary>idmap gid</primary></indexterm>
|
|
This alternate method of SID to UID/GID mapping can be achieved with the idmap_rid
|
|
plug-in. This plug-in uses the RID of the user SID to derive the UID and GID by adding the
|
|
RID to a base value specified. This utility requires that the parameter
|
|
<quote>allow trusted domains = No</quote> must be specified, as it is not compatible
|
|
with multiple domain environments. The <parameter>idmap uid</parameter> and
|
|
<parameter>idmap gid</parameter> ranges must be specified.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>idmap_rid</primary></indexterm>
|
|
<indexterm><primary>realm</primary></indexterm>
|
|
The idmap_rid facility can be used both for NT4/Samba-style domains as well as with Active Directory.
|
|
To use this with an NT4 domain, the <parameter>realm</parameter> is not used. Additionally the
|
|
method used to join the domain uses the <constant>net rpc join</constant> process.
|
|
</para>
|
|
|
|
<para>
|
|
An example &smb.conf; file for an ADS domain environment is shown in <link linkend="sbe-idmapridex"/>.
|
|
</para>
|
|
|
|
<example id="sbe-idmapridex">
|
|
<title>Example &smb.conf; File Using <constant>idmap_rid</constant></title>
|
|
<smbconfblock>
|
|
<smbconfcomment>Global parameters</smbconfcomment>
|
|
<smbconfsection name="[global]"/>
|
|
<smbconfoption name="workgroup">KPAK</smbconfoption>
|
|
<smbconfoption name="netbios name">BIGJOE</smbconfoption>
|
|
<smbconfoption name="realm">CORP.KPAK.COM</smbconfoption>
|
|
<smbconfoption name="server string">Office Server</smbconfoption>
|
|
<smbconfoption name="security">ADS</smbconfoption>
|
|
<smbconfoption name="allow trusted domains">No</smbconfoption>
|
|
<smbconfoption name="idmap backend">idmap_rid:KPAK=500-100000000</smbconfoption>
|
|
<smbconfoption name="idmap uid">500-100000000</smbconfoption>
|
|
<smbconfoption name="idmap gid">500-100000000</smbconfoption>
|
|
<smbconfoption name="template shell">/bin/bash</smbconfoption>
|
|
<smbconfoption name="winbind use default domain">Yes</smbconfoption>
|
|
<smbconfoption name="winbind enum users">No</smbconfoption>
|
|
<smbconfoption name="winbind enum groups">No</smbconfoption>
|
|
<smbconfoption name="winbind nested groups">Yes</smbconfoption>
|
|
</smbconfblock>
|
|
</example>
|
|
|
|
<para>
|
|
<indexterm><primary>large domain</primary></indexterm>
|
|
<indexterm><primary>Active Directory</primary></indexterm>
|
|
<indexterm><primary>response</primary></indexterm>
|
|
<indexterm><primary>getent</primary></indexterm>
|
|
In a large domain with many users, it is imperative to disable enumeration of users and groups.
|
|
For example, at a site that has 22,000 users in Active Directory the winbind-based user and
|
|
group resolution is unavailable for nearly 12 minutes following first start-up of
|
|
<command>winbind</command>. Disabling of such enumeration results in instantaneous response.
|
|
The disabling of user and group enumeration means that it will not be possible to list users
|
|
or groups using the <command>getent passwd</command> and <command>getent group</command>
|
|
commands. It will be possible to perform the lookup for individual users, as shown in the procedure
|
|
below.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>NSS</primary></indexterm>
|
|
<indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
|
|
The use of this tool requires configuration of NSS as per the native use of winbind. Edit the
|
|
<filename>/etc/nsswitch.conf</filename> so it has the following parameters:
|
|
<screen>
|
|
...
|
|
passwd: files winbind
|
|
shadow: files winbind
|
|
group: files winbind
|
|
...
|
|
hosts: files wins
|
|
...
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
The following procedure can be used to utilize the idmap_rid facility:
|
|
</para>
|
|
|
|
<procedure>
|
|
<step><para>
|
|
Create or install and &smb.conf; file with the above configuration.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
Edit the <filename>/etc/nsswitch.conf</filename> file as shown above.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
Execute:
|
|
<screen>
|
|
&rootprompt; net ads join -UAdministrator%password
|
|
Using short domain name -- KPAK
|
|
Joined 'BIGJOE' to realm 'CORP.KPAK.COM'
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>failed join</primary></indexterm>
|
|
An invalid or failed join can be detected by executing:
|
|
<screen>
|
|
&rootprompt; net ads testjoin
|
|
BIGJOE$@'s password:
|
|
[2004/11/05 16:53:03, 0] utils/net_ads.c:ads_startup(186)
|
|
ads_connect: No results returned
|
|
Join to domain is not valid
|
|
</screen>
|
|
The specific error message may differ from the above because it depends on the type of failure that
|
|
may have occurred. Increase the <parameter>log level</parameter> to 10, repeat the above test,
|
|
and then examine the log files produced to identify the nature of the failure.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
Start the <command>nmbd</command>, <command>winbind,</command> and <command>smbd</command> daemons in the order shown.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
Validate the operation of this configuration by executing:
|
|
<indexterm><primary></primary></indexterm>
|
|
<screen>
|
|
&rootprompt; getent passwd administrator
|
|
administrator:x:1000:1013:Administrator:/home/BE/administrator:/bin/bash
|
|
</screen>
|
|
</para></step>
|
|
</procedure>
|
|
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>IDMAP Storage in LDAP using Winbind</title>
|
|
|
|
<para>
|
|
<indexterm><primary>ADAM</primary></indexterm>
|
|
<indexterm><primary>ADS</primary></indexterm>
|
|
The storage of IDMAP information in LDAP can be used with both NT4/Samba-style domains as well as
|
|
with ADS domains. OpenLDAP is a commonly used LDAP server for this purpose, although any standards-compliant
|
|
LDAP server can be used. It is therefore possible to deploy this IDMAP configuration using
|
|
the Sun iPlanet LDAP server, Novell eDirectory, Microsoft ADS plus ADAM, and so on.
|
|
</para>
|
|
|
|
<para>
|
|
The example in <link linkend="sbeunxa"/> is for an ADS-style domain.
|
|
</para>
|
|
|
|
<example id="sbeunxa">
|
|
<title>Typical ADS Style Domain &smb.conf; File</title>
|
|
<smbconfblock>
|
|
<smbconfcomment>Global parameters</smbconfcomment>
|
|
<smbconfsection name="[global]"/>
|
|
<smbconfoption name="workgroup">SNOWSHOW</smbconfoption>
|
|
<smbconfoption name="netbios name">GOODELF</smbconfoption>
|
|
<smbconfoption name="realm">SNOWSHOW.COM</smbconfoption>
|
|
<smbconfoption name="server string">Samba Server</smbconfoption>
|
|
<smbconfoption name="security">ADS</smbconfoption>
|
|
<smbconfoption name="log level">1 ads:10 auth:10 sam:10 rpc:10</smbconfoption>
|
|
<smbconfoption name="ldap admin dn">cn=Manager,dc=SNOWSHOW,dc=COM</smbconfoption>
|
|
<smbconfoption name="ldap idmap suffix">ou=Idmap</smbconfoption>
|
|
<smbconfoption name="ldap suffix">dc=SNOWSHOW,dc=COM</smbconfoption>
|
|
<smbconfoption name="idmap backend">ldap:ldap://ldap.snowshow.com</smbconfoption>
|
|
<smbconfoption name="idmap uid">150000-550000</smbconfoption>
|
|
<smbconfoption name="idmap gid">150000-550000</smbconfoption>
|
|
<smbconfoption name="template shell">/bin/bash</smbconfoption>
|
|
<smbconfoption name="winbind use default domain">Yes</smbconfoption>
|
|
</smbconfblock>
|
|
</example>
|
|
|
|
<para>
|
|
<indexterm><primary>realm</primary></indexterm>
|
|
In the case of an NT4 or Samba-style domain the <parameter>realm</parameter> is not used, and the
|
|
command used to join the domain is <command>net rpc join</command>. The above example also demonstrates
|
|
advanced error reporting techniques that are documented in the chapter called "Reporting Bugs" in
|
|
<quote>The Official Samba HOWTO and Reference Guide, Second Edition</quote> (TOSHARG2).
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>MIT kerberos</primary></indexterm>
|
|
<indexterm><primary>Heimdal kerberos</primary></indexterm>
|
|
<indexterm><primary>/etc/krb5.conf</primary></indexterm>
|
|
Where MIT kerberos is installed (version 1.3.4 or later), edit the <filename>/etc/krb5.conf</filename>
|
|
file so it has the following contents:
|
|
<screen>
|
|
[logging]
|
|
default = FILE:/var/log/krb5libs.log
|
|
kdc = FILE:/var/log/krb5kdc.log
|
|
admin_server = FILE:/var/log/kadmind.log
|
|
|
|
[libdefaults]
|
|
default_realm = SNOWSHOW.COM
|
|
dns_lookup_realm = false
|
|
dns_lookup_kdc = true
|
|
|
|
[appdefaults]
|
|
pam = {
|
|
debug = false
|
|
ticket_lifetime = 36000
|
|
renew_lifetime = 36000
|
|
forwardable = true
|
|
krb4_convert = false
|
|
}
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
Where Heimdal kerberos is installed, edit the <filename>/etc/krb5.conf</filename>
|
|
file so it is either empty (i.e., no contents) or it has the following contents:
|
|
<screen>
|
|
[libdefaults]
|
|
default_realm = SNOWSHOW.COM
|
|
clockskew = 300
|
|
|
|
[realms]
|
|
SNOWSHOW.COM = {
|
|
kdc = ADSDC.SHOWSHOW.COM
|
|
}
|
|
|
|
[domain_realm]
|
|
.snowshow.com = SNOWSHOW.COM
|
|
</screen>
|
|
</para>
|
|
|
|
<note><para>
|
|
Samba cannot use the Heimdal libraries if there is no <filename>/etc/krb5.conf</filename> file.
|
|
So long as there is an empty file, the Heimdal kerberos libraries will be usable. There is no
|
|
need to specify any settings because Samba, using the Heimdal libraries, can figure this out automatically.
|
|
</para></note>
|
|
<para>
|
|
Edit the NSS control file <filename>/etc/nsswitch.conf</filename> so it has the following entries:
|
|
<screen>
|
|
...
|
|
passwd: files ldap
|
|
shadow: files ldap
|
|
group: files ldap
|
|
...
|
|
hosts: files wins
|
|
...
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>PADL</primary></indexterm>
|
|
<indexterm><primary>/etc/ldap.conf</primary></indexterm>
|
|
You will need the <ulink url="http://www.padl.com">PADL</ulink> <command>nss_ldap</command>
|
|
tool set for this solution. Configure the <filename>/etc/ldap.conf</filename> file so it has
|
|
the information needed. The following is an example of a working file:
|
|
<screen>
|
|
host 192.168.2.1
|
|
base dc=snowshow,dc=com
|
|
binddn cn=Manager,dc=snowshow,dc=com
|
|
bindpw not24get
|
|
|
|
pam_password exop
|
|
|
|
nss_base_passwd ou=People,dc=snowshow,dc=com?one
|
|
nss_base_shadow ou=People,dc=snowshow,dc=com?one
|
|
nss_base_group ou=Groups,dc=snowshow,dc=com?one
|
|
ssl no
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
The following procedure may be followed to affect a working configuration:
|
|
</para>
|
|
<procedure>
|
|
<step><para>
|
|
Configure the &smb.conf; file as shown above.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
Create the <filename>/etc/krb5.conf</filename> file following the indications above.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
Configure the <filename>/etc/nsswitch.conf</filename> file as shown above.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
Download, build, and install the PADL nss_ldap tool set. Configure the
|
|
<filename>/etc/ldap.conf</filename> file as shown above.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
Configure an LDAP server and initialize the directory with the top-level entries needed by IDMAP
|
|
as shown in the following LDIF file:
|
|
<screen>
|
|
dn: dc=snowshow,dc=com
|
|
objectClass: dcObject
|
|
objectClass: organization
|
|
dc: snowshow
|
|
o: The Greatest Snow Show in Singapore.
|
|
description: Posix and Samba LDAP Identity Database
|
|
|
|
dn: cn=Manager,dc=snowshow,dc=com
|
|
objectClass: organizationalRole
|
|
cn: Manager
|
|
description: Directory Manager
|
|
|
|
dn: ou=Idmap,dc=snowshow,dc=com
|
|
objectClass: organizationalUnit
|
|
ou: idmap
|
|
</screen>
|
|
</para></step>
|
|
|
|
<step><para>
|
|
Execute the command to join the Samba domain member server to the ADS domain as shown here:
|
|
<screen>
|
|
&rootprompt; net ads testjoin
|
|
Using short domain name -- SNOWSHOW
|
|
Joined 'GOODELF' to realm 'SNOWSHOW.COM'
|
|
</screen>
|
|
</para></step>
|
|
|
|
<step><para>
|
|
Store the LDAP server access password in the Samba <filename>secrets.tdb</filename> file as follows:
|
|
<screen>
|
|
&rootprompt; smbpasswd -w not24get
|
|
</screen>
|
|
</para></step>
|
|
|
|
<step><para>
|
|
Start the <command>nmbd</command>, <command>winbind</command>, and <command>smbd</command> daemons in the order shown.
|
|
</para></step>
|
|
</procedure>
|
|
|
|
|
|
<para>
|
|
<indexterm><primary>diagnostic</primary></indexterm>
|
|
Follow the diagnostic procedures shown earlier in this chapter to identify success or failure of the join.
|
|
In many cases a failure is indicated by a silent return to the command prompt with no indication of the
|
|
reason for failure.
|
|
</para>
|
|
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>IDMAP and NSS Using LDAP from ADS with RFC2307bis Schema Extension</title>
|
|
|
|
<para>
|
|
<indexterm><primary>rfc2307bis</primary></indexterm>
|
|
<indexterm><primary>schema</primary></indexterm>
|
|
The use of this method is messy. The information provided in this section is for guidance only
|
|
and is very definitely not complete. This method does work; it is used in a number of large sites
|
|
and has an acceptable level of performance.
|
|
</para>
|
|
|
|
<para>
|
|
An example &smb.conf; file is shown in <link linkend="sbewinbindex"/>.
|
|
</para>
|
|
|
|
<example id="sbewinbindex">
|
|
<title>ADS Membership Using RFC2307bis Identity Resolution &smb.conf; File</title>
|
|
<smbconfblock>
|
|
<smbconfcomment>Global parameters</smbconfcomment>
|
|
<smbconfsection name="[global]"/>
|
|
<smbconfoption name="workgroup">BUBBAH</smbconfoption>
|
|
<smbconfoption name="netbios name">MADMAX</smbconfoption>
|
|
<smbconfoption name="realm">BUBBAH.COM</smbconfoption>
|
|
<smbconfoption name="server string">Samba Server</smbconfoption>
|
|
<smbconfoption name="security">ADS</smbconfoption>
|
|
<smbconfoption name="idmap uid">150000-550000</smbconfoption>
|
|
<smbconfoption name="idmap gid">150000-550000</smbconfoption>
|
|
<smbconfoption name="template shell">/bin/bash</smbconfoption>
|
|
<smbconfoption name="winbind use default domain">Yes</smbconfoption>
|
|
<smbconfoption name="winbind trusted domains only">Yes</smbconfoption>
|
|
<smbconfoption name="winbind nested groups">Yes</smbconfoption>
|
|
</smbconfblock>
|
|
</example>
|
|
|
|
<para>
|
|
<indexterm><primary>nss_ldap</primary></indexterm>
|
|
The DMS must be joined to the domain using the usual procedure. Additionally, it is necessary
|
|
to build and install the PADL nss_ldap tool set. Be sure to build this tool set with the
|
|
following:
|
|
<screen>
|
|
./configure --enable-rfc2307bis --enable-schema-mapping
|
|
make install
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
|
|
The following <filename>/etc/nsswitch.conf</filename> file contents are required:
|
|
<screen>
|
|
...
|
|
passwd: files ldap
|
|
shadow: files ldap
|
|
group: files ldap
|
|
...
|
|
hosts: files wins
|
|
...
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>/etc/ldap.conf</primary></indexterm>
|
|
<indexterm><primary>nss_ldap</primary></indexterm>
|
|
The <filename>/etc/ldap.conf</filename> file must be configured also. Refer to the PADL documentation
|
|
and source code for nss_ldap instructions.
|
|
</para>
|
|
|
|
<para>
|
|
The next step involves preparation on the ADS schema. This is briefly discussed in the remaining
|
|
part of this chapter.
|
|
</para>
|
|
|
|
<sect4>
|
|
<title>IDMAP, Active Directory, and MS Services for UNIX 3.5</title>
|
|
|
|
<para>
|
|
<indexterm><primary>SFU</primary></indexterm>
|
|
The Microsoft Windows Service for UNIX version 3.5 is available for free
|
|
<ulink url="http://www.microsoft.com/windows/sfu/">download</ulink>
|
|
from the Microsoft Web site. You will need to download this tool and install it following
|
|
Microsoft instructions.
|
|
</para>
|
|
|
|
</sect4>
|
|
|
|
<sect4>
|
|
<title>IDMAP, Active Directory, and AD4UNIX</title>
|
|
|
|
<para>
|
|
Instructions for obtaining and installing the AD4UNIX tool set can be found from the
|
|
<ulink url="http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?LDAP01/An_Alternative_Approach">
|
|
Geekcomix</ulink> Web site.
|
|
</para>
|
|
|
|
</sect4>
|
|
|
|
</sect3>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>UNIX/Linux Client Domain Member</title>
|
|
|
|
<para><indexterm>
|
|
<primary>user credentials</primary>
|
|
</indexterm>
|
|
So far this chapter has been mainly concerned with the provision of file and print
|
|
services for domain member servers. However, an increasing number of UNIX/Linux
|
|
workstations are being installed that do not act as file or print servers to anyone
|
|
other than a single desktop user. The key demand for desktop systems is to be able
|
|
to log onto any UNIX/Linux or Windows desktop using the same network user credentials.
|
|
</para>
|
|
|
|
<para><indexterm>
|
|
<primary>Single Sign-On</primary>
|
|
<see>SSO</see>
|
|
</indexterm>
|
|
The ability to use a common set of user credential across a variety of network systems
|
|
is generally regarded as a single sign-on (SSO) solution. SSO systems are sold by a
|
|
large number of vendors and include a range of technologies such as:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>
|
|
Proxy sign-on
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
Federated directory provisioning
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
Metadirectory server solutions
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
Replacement authentication systems
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para><indexterm>
|
|
<primary>Identity management</primary>
|
|
</indexterm>
|
|
There are really four solutions that provide integrated authentication and
|
|
user identity management facilities:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>
|
|
Samba winbind (free). Samba-3.0.20 introduced a complete replacement for Winbind that now
|
|
provides a greater level of scalability in large ADS environments.
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
<ulink url="http://www.padl.com">PADL</ulink> PAM and LDAP tools (free).
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
<ulink url="http://www.vintela.com">Vintela</ulink> Authentication Services (commercial).
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
<ulink url="http://www.centrify.com">Centrify</ulink> DirectControl (commercial).
|
|
Centrify's commercial product allows UNIX and Linux systems to use Active Directory
|
|
security, directory and policy services. Enhancements include a centralized ID mapping that
|
|
allows Samba, DirectControl and Active Directory to seamlessly work together.
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
The following guidelines are pertinent to the deployment of winbind-based authentication
|
|
and identity resolution with the express purpose of allowing users to log on to UNIX/Linux desktops
|
|
using Windows network domain user credentials (username and password).
|
|
</para>
|
|
|
|
<para>
|
|
You should note that it is possible to use LDAP-based PAM and NSS tools to permit distributed
|
|
systems logons (SSO), providing user and group accounts are stored in an LDAP directory. This
|
|
provides logon services for UNIX/Linux users, while Windows users obtain their sign-on
|
|
support via Samba.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>Windows Services for UNIX</primary><see>SUS</see></indexterm>
|
|
On the other hand, if the authentication and identity resolution backend must be provided by
|
|
a Windows NT4-style domain or from an Active Directory Domain that does not have the Microsoft
|
|
Windows Services for UNIX installed, winbind is your best friend. Specific guidance for these
|
|
situations now follows.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>PAM</primary></indexterm>
|
|
<indexterm><primary>Identity resolution</primary></indexterm>
|
|
<indexterm><primary>NSS</primary></indexterm>
|
|
To permit users to log on to a Linux system using Windows network credentials, you need to
|
|
configure identity resolution (NSS) and PAM. This means that the basic steps include those
|
|
outlined above with the addition of PAM configuration. Given that most workstations (desktop/client)
|
|
usually do not need to provide file and print services to a group of users, the configuration
|
|
of shares and printers is generally less important. Often this allows the share specifications
|
|
to be entirely removed from the &smb.conf; file. That is obviously an administrator decision.
|
|
</para>
|
|
|
|
<sect3>
|
|
<title>NT4 Domain Member</title>
|
|
|
|
<para>
|
|
The following steps provide a Linux system that users can log onto using
|
|
Windows NT4 (or Samba) domain network credentials:
|
|
</para>
|
|
|
|
<procedure>
|
|
<step><para>
|
|
Follow the steps outlined in <link linkend="wdcsdm"/> and ensure that
|
|
all validation tests function as shown.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
Identify what services users must log on to. On Red Hat Linux, if it is
|
|
intended that the user shall be given access to all services, it may be
|
|
most expeditious to simply configure the file
|
|
<filename>/etc/pam.d/system-auth</filename>.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
Carefully make a backup copy of all PAM configuration files before you
|
|
begin making changes. If you break the PAM configuration, please note
|
|
that you may need to use an emergency boot process to recover your Linux
|
|
system. It is possible to break the ability to log into the system if
|
|
PAM files are incorrectly configured. The entire directory
|
|
<filename>/etc/pam.d</filename> should be backed up to a safe location.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
If you require only console login support, edit the <filename>/etc/pam.d/login</filename>
|
|
so it matches <link linkend="ch9-pamwnbdlogin"/>.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
To provide the ability to log onto the graphical desktop interface, you must edit
|
|
the files <filename>gdm</filename> and <filename>xdm</filename> in the
|
|
<filename>/etc/pam.d</filename> directory.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
Edit only one file at a time. Carefully validate its operation before attempting
|
|
to reboot the machine.
|
|
</para></step>
|
|
</procedure>
|
|
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>ADS Domain Member</title>
|
|
|
|
<para>
|
|
This procedure should be followed to permit a Linux network client (workstation/desktop)
|
|
to permit users to log on using Microsoft Active Directory-based user credentials.
|
|
</para>
|
|
|
|
<procedure>
|
|
<step><para>
|
|
Follow the steps outlined in <link linkend="adssdm"/> and ensure that
|
|
all validation tests function as shown.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
Identify what services users must log on to. On Red Hat Linux, if it is
|
|
intended that the user shall be given access to all services, it may be
|
|
most expeditious to simply configure the file
|
|
<filename>/etc/pam.d/system-auth</filename> as shown in <link linkend="ch9-rhsysauth"/>.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
Carefully make a backup copy of all PAM configuration files before you
|
|
begin making changes. If you break the PAM configuration, please note
|
|
that you may need to use an emergency boot process to recover your Linux
|
|
system. It is possible to break the ability to log into the system if
|
|
PAM files are incorrectly configured. The entire directory
|
|
<filename>/etc/pam.d</filename> should be backed up to a safe location.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
If you require only console login support, edit the <filename>/etc/pam.d/login</filename>
|
|
so it matches <link linkend="ch9-pamwnbdlogin"/>.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
To provide the ability to log onto the graphical desktop interface, you must edit
|
|
the files <filename>gdm</filename> and <filename>xdm</filename> in the
|
|
<filename>/etc/pam.d</filename> directory.
|
|
</para></step>
|
|
|
|
<step><para>
|
|
Edit only one file at a time. Carefully validate its operation before attempting
|
|
to reboot the machine.
|
|
</para></step>
|
|
</procedure>
|
|
|
|
</sect3>
|
|
|
|
<example id="ch9-pamwnbdlogin">
|
|
<title>SUSE: PAM <filename>login</filename> Module Using Winbind</title>
|
|
<screen>
|
|
# /etc/pam.d/login
|
|
|
|
#%PAM-1.0
|
|
auth sufficient pam_unix2.so nullok
|
|
auth sufficient pam_winbind.so use_first_pass use_authtok
|
|
auth required pam_securetty.so
|
|
auth required pam_nologin.so
|
|
auth required pam_env.so
|
|
auth required pam_mail.so
|
|
account sufficient pam_unix2.so
|
|
account sufficient pam_winbind.so user_first_pass use_authtok
|
|
password required pam_pwcheck.so nullok
|
|
password sufficient pam_unix2.so nullok use_first_pass use_authtok
|
|
password sufficient pam_winbind.so use_first_pass use_authtok
|
|
session sufficient pam_unix2.so none
|
|
session sufficient pam_winbind.so use_first_pass use_authtok
|
|
session required pam_limits.so
|
|
</screen>
|
|
</example>
|
|
|
|
<example id="ch9-pamwbndxdm">
|
|
<title>SUSE: PAM <filename>xdm</filename> Module Using Winbind</title>
|
|
<screen>
|
|
# /etc/pam.d/gdm (/etc/pam.d/xdm)
|
|
|
|
#%PAM-1.0
|
|
auth sufficient pam_unix2.so nullok
|
|
auth sufficient pam_winbind.so use_first_pass use_authtok
|
|
account sufficient pam_unix2.so
|
|
account sufficient pam_winbind.so use_first_pass use_authtok
|
|
password sufficient pam_unix2.so
|
|
password sufficient pam_winbind.so use_first_pass use_authtok
|
|
session sufficient pam_unix2.so
|
|
session sufficient pam_winbind.so use_first_pass use_authtok
|
|
session required pam_dev perm.so
|
|
session required pam_resmgr.so
|
|
</screen>
|
|
</example>
|
|
|
|
<example id="ch9-rhsysauth">
|
|
<title>Red Hat 9: PAM System Authentication File: <filename>/etc/pam.d/system-auth</filename> Module Using Winbind</title>
|
|
<screen>
|
|
#%PAM-1.0
|
|
auth required /lib/security/$ISA/pam_env.so
|
|
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
|
|
auth sufficient /lib/security/$ISA/pam_winbind.so use_first_pass
|
|
auth required /lib/security/$ISA/pam_deny.so
|
|
|
|
account required /lib/security/$ISA/pam_unix.so
|
|
account sufficient /lib/security/$ISA/pam_winbind.so use_first_pass
|
|
|
|
password required /lib/security/$ISA/pam_cracklib.so retry=3 type=
|
|
# Note: The above line is complete. There is nothing following the '='
|
|
password sufficient /lib/security/$ISA/pam_unix.so \
|
|
nullok use_authtok md5 shadow
|
|
password sufficient /lib/security/$ISA/pam_winbind.so use_first_pass
|
|
password required /lib/security/$ISA/pam_deny.so
|
|
|
|
session required /lib/security/$ISA/pam_limits.so
|
|
session sufficient /lib/security/$ISA/pam_unix.so
|
|
session sufficient /lib/security/$ISA/pam_winbind.so use_first_pass
|
|
</screen>
|
|
</example>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Key Points Learned</title>
|
|
|
|
<para>
|
|
The addition of UNIX/Linux Samba servers and clients is a common requirement. In this chapter, you
|
|
learned how to integrate such servers so that the UID/GID mappings they use can be consistent
|
|
across all domain member servers. You also discovered how to implement the ability to use Samba
|
|
or Windows domain account credentials to log on to a UNIX/Linux client.
|
|
</para>
|
|
|
|
<para>
|
|
The following are key points made in this chapter:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>
|
|
Domain controllers are always authoritative for the domain.
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
Domain members may have local accounts and must be able to resolve the identity of
|
|
domain user accounts. Domain user account identity must map to a local UID/GID. That
|
|
local UID/GID can be stored in LDAP. This way, it is possible to share the IDMAP data
|
|
across all domain member machines.
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
Resolution of user and group identities on domain member machines may be implemented
|
|
using direct LDAP services or using winbind.
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
On NSS/PAM enabled UNIX/Linux systems, NSS is responsible for identity management
|
|
and PAM is responsible for authentication of logon credentials (username and password).
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Questions and Answers</title>
|
|
|
|
<para>
|
|
The following questions were obtained from the mailing list and also from private discussions
|
|
with Windows network administrators.
|
|
</para>
|
|
|
|
<qandaset defaultlabel="chap09qa" type="number">
|
|
<qandaentry>
|
|
<question>
|
|
|
|
<para>
|
|
We use NIS for all UNIX accounts. Why do we need winbind?
|
|
</para>
|
|
|
|
</question>
|
|
<answer>
|
|
|
|
<para>
|
|
<indexterm><primary>NIS</primary></indexterm>
|
|
<indexterm><primary>encrypted passwords</primary></indexterm>
|
|
<indexterm><primary>smbpasswd</primary></indexterm>
|
|
<indexterm><primary>tdbsam</primary></indexterm>
|
|
<indexterm><primary>passdb backend</primary></indexterm>
|
|
<indexterm><primary>Winbind</primary></indexterm>
|
|
You can use NIS for your UNIX accounts. NIS does not store the Windows encrypted
|
|
passwords that need to be stored in one of the acceptable passdb backends.
|
|
Your choice of backend is limited to <parameter>smbpasswd</parameter> or
|
|
<parameter>tdbsam</parameter>. Winbind is needed to handle the resolution of
|
|
SIDs from trusted domains to local UID/GID values.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>winbind trusted domains only</primary></indexterm>
|
|
<indexterm><primary>getpwnam()</primary></indexterm>
|
|
On a domain member server, you effectively map Windows domain users to local users
|
|
that are in your NIS database by specifying the <parameter>winbind trusted domains
|
|
only</parameter>. This causes user and group account lookups to be routed via
|
|
the <command>getpwnam()</command> family of systems calls. On an NIS-enabled client,
|
|
this pushes the resolution of users and groups out through NIS.
|
|
</para>
|
|
|
|
<para>
|
|
As a general rule, it is always a good idea to run winbind on all Samba servers.
|
|
</para>
|
|
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
|
|
<para>
|
|
Our IT management people do not like LDAP but are looking at Microsoft Active Directory.
|
|
Which is better?<indexterm>
|
|
<primary>Active Directory</primary>
|
|
</indexterm>
|
|
</para>
|
|
|
|
</question>
|
|
<answer>
|
|
|
|
<para><indexterm>
|
|
<primary>LDAP</primary>
|
|
<secondary>server</secondary>
|
|
</indexterm><indexterm>
|
|
<primary>Kerberos</primary>
|
|
</indexterm><indexterm>
|
|
<primary>schema</primary>
|
|
</indexterm>
|
|
Microsoft Active Directory is an LDAP server that is intricately tied to a Kerberos
|
|
infrastructure. Most IT managers who object to LDAP do so because
|
|
an LDAP server is most often supplied as a raw tool that needs to be configured and
|
|
for which the administrator must create the schema, create the administration tools, and
|
|
devise the backup and recovery facilities in a site-dependent manner. LDAP servers
|
|
in general are seen as a high-energy, high-risk facility.
|
|
</para>
|
|
|
|
<para><indexterm>
|
|
<primary>management</primary>
|
|
</indexterm>
|
|
Microsoft Active Directory by comparison is easy to install and configure and
|
|
is supplied with all tools necessary to implement and manage the directory. For sites
|
|
that lack a lot of technical competence, Active Directory is a good choice. For sites
|
|
that have the technical competence to handle Active Directory well, LDAP is a good
|
|
alternative. The real issue is, What type of solution does
|
|
the site want? If management wants a choice to use an alternative, they may want to
|
|
consider the options. On the other hand, if management just wants a solution that works,
|
|
Microsoft Active Directory is a good solution.
|
|
</para>
|
|
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
|
|
<para>
|
|
We want to implement a Samba PDC, four Samba BDCs, and 10 Samba servers. Is it possible
|
|
to use NIS in place of LDAP?
|
|
</para>
|
|
|
|
</question>
|
|
<answer>
|
|
|
|
<para><indexterm>
|
|
<primary>NIS</primary>
|
|
</indexterm><indexterm>
|
|
<primary>LDAP</primary>
|
|
</indexterm><indexterm>
|
|
<primary>encrypted passwords</primary>
|
|
</indexterm><indexterm>
|
|
<primary>synchronized</primary>
|
|
</indexterm><indexterm>
|
|
<primary>secure account password</primary>
|
|
</indexterm><indexterm>
|
|
<primary>PDC</primary>
|
|
</indexterm><indexterm>
|
|
<primary>BDC</primary>
|
|
</indexterm>
|
|
Yes, it is possible to use NIS in place of LDAP, but there may be problems with keeping
|
|
the Windows (SMB) encrypted passwords database correctly synchronized across the entire
|
|
network. Workstations (Windows client machines) periodically change their domain
|
|
membership secure account password. How can you keep changes that are on remote BDCs
|
|
synchronized on the PDC?
|
|
</para>
|
|
|
|
<para><indexterm>
|
|
<primary>centralized storage</primary>
|
|
</indexterm><indexterm>
|
|
<primary>management</primary>
|
|
</indexterm><indexterm>
|
|
<primary>network Identities</primary>
|
|
</indexterm>
|
|
LDAP is a more elegant solution because it permits centralized storage and management
|
|
of all network identities (user, group, and machine accounts) together with all information
|
|
Samba needs to provide to network clients and their users.
|
|
</para>
|
|
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
|
|
<para>
|
|
Are you suggesting that users should not log on to a domain member server? If so, why?
|
|
</para>
|
|
|
|
</question>
|
|
<answer>
|
|
|
|
<para><indexterm>
|
|
<primary>security</primary>
|
|
</indexterm><indexterm>
|
|
<primary>data</primary>
|
|
<secondary>integrity</secondary>
|
|
</indexterm><indexterm>
|
|
<primary>mapped drives</primary>
|
|
</indexterm>
|
|
Many UNIX administrators mock the model that the personal computer industry has adopted
|
|
as normative since the early days of Novell NetWare. The old
|
|
perception of the necessity to keep users off file and print servers was a result of
|
|
fears concerning the security and integrity of data. It was a simple and generally
|
|
effective measure to keep users away from servers, except through mapped drives.
|
|
</para>
|
|
|
|
<para><indexterm>
|
|
<primary>user logins</primary>
|
|
</indexterm><indexterm>
|
|
<primary>risk</primary>
|
|
</indexterm><indexterm>
|
|
<primary>user errors</primary>
|
|
</indexterm><indexterm>
|
|
<primary>strategy</primary>
|
|
</indexterm><indexterm>
|
|
<primary>policy</primary>
|
|
</indexterm>
|
|
UNIX administrators are fully correct in asserting that UNIX servers and workstations
|
|
are identical in terms of the software that is installed. They correctly assert that
|
|
in a well-secured environment it is safe to store files on a system that has hundreds
|
|
of users. But all network administrators must factor into the decision to allow or
|
|
reject general user logins to a UNIX system that is principally a file and print
|
|
server the risk to operations through simple user errors.
|
|
Only then can one begin to appraise the best strategy and adopt a site-specific
|
|
policy that best protects the needs of users and of the organization alike.
|
|
</para>
|
|
|
|
<para><indexterm>
|
|
<primary>system level logins</primary>
|
|
</indexterm>
|
|
From experience, it is my recommendation to keep general system-level logins to a
|
|
practical minimum and to eliminate them if possible. This should not be taken as a
|
|
hard rule, though. The better question is, what works best for the site?
|
|
</para>
|
|
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
|
|
<para><indexterm>
|
|
<primary>trusted domains</primary>
|
|
</indexterm><indexterm>
|
|
<primary>domain</primary>
|
|
<secondary>trusted</secondary>
|
|
</indexterm><indexterm>
|
|
<primary>winbind trusted domains only</primary>
|
|
</indexterm><indexterm>
|
|
<primary>domain members</primary>
|
|
</indexterm>
|
|
We want to ensure that only users from our own domain plus from trusted domains can use our
|
|
Samba servers. In the &smb.conf; file on all servers, we have enabled the <parameter>winbind
|
|
trusted domains only</parameter> parameter. We now find that users from trusted domains
|
|
cannot access our servers, and users from Windows clients that are not domain members
|
|
can also access our servers. Is this a Samba bug?
|
|
</para>
|
|
|
|
</question>
|
|
<answer>
|
|
|
|
<para><indexterm>
|
|
<primary>distributed</primary>
|
|
</indexterm><indexterm>
|
|
<primary>NIS</primary>
|
|
</indexterm><indexterm>
|
|
<primary>rsync</primary>
|
|
</indexterm><indexterm>
|
|
<primary>LDAP</primary>
|
|
</indexterm><indexterm>
|
|
<primary>winbindd</primary>
|
|
</indexterm><indexterm>
|
|
<primary>/etc/passwd</primary>
|
|
</indexterm>
|
|
The manual page for this <parameter>winbind trusted domains only</parameter> parameter says,
|
|
<quote>This parameter is designed to allow Samba servers that are members of a Samba-controlled
|
|
domain to use UNIX accounts distributed vi NIS, rsync, or LDAP as the UIDs for winbindd users
|
|
in the hosts primary domain. Therefore, the user <constant>SAMBA\user1</constant> would be
|
|
mapped to the account <constant>user1</constant> in <filename>/etc/passwd</filename> instead
|
|
of allocating a new UID for him or her.</quote> This clearly suggests that you are trying
|
|
to use this parameter inappropriately.
|
|
</para>
|
|
|
|
<para><indexterm>
|
|
<primary>valid users</primary>
|
|
</indexterm>
|
|
A far better solution is to use the <parameter>valid users</parameter> by specifying
|
|
precisely the domain users and groups that should be permitted access to the shares. You could,
|
|
for example, set the following parameters:
|
|
<screen>
|
|
[demoshare]
|
|
path = /export/demodata
|
|
valid users = @"Domain Users", @"OTHERDOMAIN\Domain Users"
|
|
</screen>
|
|
</para>
|
|
|
|
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
|
|
<para>
|
|
What are the benefits of using LDAP for my domain member servers?
|
|
</para>
|
|
|
|
</question>
|
|
<answer>
|
|
|
|
<para><indexterm>
|
|
<primary>LDAP</primary>
|
|
</indexterm><indexterm>
|
|
<primary>benefit</primary>
|
|
</indexterm><indexterm>
|
|
<primary>UID</primary>
|
|
</indexterm><indexterm>
|
|
<primary>GID</primary>
|
|
</indexterm><indexterm>
|
|
<primary>Domain Controllers</primary>
|
|
</indexterm><indexterm>
|
|
<primary>Domain Member servers</primary>
|
|
</indexterm><indexterm>
|
|
<primary>copy</primary>
|
|
</indexterm><indexterm>
|
|
<primary>replicate</primary>
|
|
</indexterm><indexterm>
|
|
<primary>identity</primary>
|
|
</indexterm>
|
|
The key benefit of using LDAP is that the UID of all users and the GID of all groups
|
|
are globally consistent on domain controllers as well as on domain member servers.
|
|
This means that it is possible to copy/replicate files across servers without
|
|
loss of identity.
|
|
</para>
|
|
|
|
<para><indexterm>
|
|
<primary>Identity resolution</primary>
|
|
</indexterm><indexterm>
|
|
<primary>winbind</primary>
|
|
</indexterm><indexterm>
|
|
<primary>IDMAP backend</primary>
|
|
</indexterm><indexterm>
|
|
<primary>LDAP</primary>
|
|
</indexterm><indexterm>
|
|
<primary>Domain Controllers</primary>
|
|
</indexterm><indexterm>
|
|
<primary>Domain Member</primary>
|
|
<secondary>servers</secondary>
|
|
</indexterm><indexterm>
|
|
<primary>Posix</primary>
|
|
</indexterm><indexterm>
|
|
<primary>account information</primary>
|
|
</indexterm>
|
|
When use is made of account identity resolution via winbind, even when an IDMAP backend
|
|
is stored in LDAP, the UID/GID on domain member servers is consistent, but differs
|
|
from the ID that the user/group has on domain controllers. The winbind allocated UID/GID
|
|
that is stored in LDAP (or locally) will be in the numeric range specified in the <parameter>
|
|
idmap uid/gid</parameter> in the &smb.conf; file. On domain controllers, the UID/GID is
|
|
that of the POSIX value assigned in the LDAP directory as part of the POSIX account information.
|
|
</para>
|
|
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
|
|
<para>
|
|
Is proper DNS operation necessary for Samba plus LDAP? If so, what must I put into
|
|
my DNS configuration?
|
|
</para>
|
|
|
|
</question>
|
|
<answer>
|
|
|
|
<para><indexterm>
|
|
<primary>DNS</primary>
|
|
<secondary>configuration</secondary>
|
|
</indexterm><indexterm>
|
|
<primary>DNS</primary>
|
|
<secondary>lookup</secondary>
|
|
</indexterm><indexterm>
|
|
<primary>hosts</primary>
|
|
</indexterm><indexterm>
|
|
<primary>/etc/nsswitch.conf</primary>
|
|
</indexterm><indexterm>
|
|
<primary>NSS</primary>
|
|
</indexterm><indexterm>
|
|
<primary>/etc/hosts</primary>
|
|
</indexterm><indexterm>
|
|
<primary>WINS</primary>
|
|
<secondary>lookup</secondary>
|
|
</indexterm>
|
|
Samba depends on correctly functioning resolution of hostnames to their IP address. Samba
|
|
makes no direct DNS lookup calls, but rather redirects all name-to-address calls via the
|
|
<command>getXXXbyXXX()</command> function calls. The configuration of the <constant>hosts</constant>
|
|
entry in the NSS <filename>/etc/nsswitch.conf</filename> file determines how the underlying
|
|
resolution process is implemented. If the <constant>hosts</constant> entry in your NSS
|
|
control file says:
|
|
<screen>
|
|
hosts: files dns wins
|
|
</screen>
|
|
this means that a hostname lookup first tries the <filename>/etc/hosts</filename>.
|
|
If this fails to resolve, it attempts a DNS lookup, and if that fails, it tries a
|
|
WINS lookup.
|
|
</para>
|
|
|
|
<para><indexterm>
|
|
<primary>NetBIOS</primary>
|
|
</indexterm><indexterm>
|
|
<primary>TCP/IP</primary>
|
|
</indexterm><indexterm>
|
|
<primary>name resolution</primary>
|
|
</indexterm>
|
|
The addition of the WINS-based name lookup makes sense only if NetBIOS over TCP/IP has
|
|
been enabled on all Windows clients. Where NetBIOS over TCP/IP has been disabled, DNS
|
|
is the preferred name resolution technology. This usually makes most sense when Samba
|
|
is a client of an Active Directory domain, where NetBIOS use has been disabled. In this
|
|
case, the Windows 200x autoregisters all locator records it needs with its own DNS
|
|
server or servers.
|
|
</para>
|
|
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
|
|
<para>
|
|
Our Windows 2003 Server Active Directory domain runs with NetBIOS disabled. Can we
|
|
use Samba with that configuration?
|
|
</para>
|
|
|
|
</question>
|
|
<answer>
|
|
|
|
<para>
|
|
Yes.
|
|
</para>
|
|
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
|
|
<para><indexterm>
|
|
<primary>net</primary>
|
|
<secondary>ads</secondary>
|
|
<tertiary>join</tertiary>
|
|
</indexterm><indexterm>
|
|
<primary>net</primary>
|
|
<secondary>rpc</secondary>
|
|
<tertiary>join</tertiary>
|
|
</indexterm>
|
|
When I tried to execute net ads join, I got no output. It did not work, so
|
|
I think that it failed. I then executed net rpc join and that worked fine.
|
|
That is okay, isn't it?
|
|
</para>
|
|
|
|
</question>
|
|
<answer>
|
|
|
|
<para><indexterm>
|
|
<primary>Kerberos</primary>
|
|
</indexterm><indexterm>
|
|
<primary>authentication</primary>
|
|
</indexterm>
|
|
No. This is not okay. It means that your Samba client has joined the ADS domain as
|
|
a Windows NT4 client, and Samba will not be using Kerberos-based authentication.
|
|
</para>
|
|
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
</qandaset>
|
|
|
|
</sect1>
|
|
|
|
</chapter>
|