summaryrefslogtreecommitdiff
path: root/docs/Samba-Guide/Chap09-AddingUNIXClients.xml
diff options
context:
space:
mode:
authorJelmer Vernooij <jelmer@samba.org>2004-06-20 12:43:16 +0000
committerGerald W. Carter <jerry@samba.org>2008-04-23 08:45:56 -0500
commit83a17815a7689f1f6f7ca57161a0e804277c75f9 (patch)
treee1cec10510da7038e843f71c9ba95a0e6bc5f494 /docs/Samba-Guide/Chap09-AddingUNIXClients.xml
parent9eb45e211cbc28bbd28837a17dcec3df29d6f455 (diff)
downloadsamba-83a17815a7689f1f6f7ca57161a0e804277c75f9.tar.gz
samba-83a17815a7689f1f6f7ca57161a0e804277c75f9.tar.bz2
samba-83a17815a7689f1f6f7ca57161a0e804277c75f9.zip
New structure for the docs:
- Same name for a doc everywhere (howto -> Samba-HOWTO-Collection, etc) - Shorter and more clearly structured Makefile - Make it possible to change the paths for the images (This used to be commit 96f6c05f25acc8a9bb1977b8bd5cc97ce511b6b1)
Diffstat (limited to 'docs/Samba-Guide/Chap09-AddingUNIXClients.xml')
-rw-r--r--docs/Samba-Guide/Chap09-AddingUNIXClients.xml2516
1 files changed, 2516 insertions, 0 deletions
diff --git a/docs/Samba-Guide/Chap09-AddingUNIXClients.xml b/docs/Samba-Guide/Chap09-AddingUNIXClients.xml
new file mode 100644
index 0000000000..e46fc22396
--- /dev/null
+++ b/docs/Samba-Guide/Chap09-AddingUNIXClients.xml
@@ -0,0 +1,2516 @@
+<?xml version="1.0" encoding="iso-8859-1"?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+
+ <!-- Stuff for xincludes -->
+ <!ENTITY % xinclude SYSTEM "../entities/xinclude.dtd">
+ %xinclude;
+
+ <!-- entities files to use -->
+ <!ENTITY % global_entities SYSTEM '../entities/global.entities'>
+ %global_entities;
+
+]>
+
+<chapter id="unixclients">
+ <title>Adding UNIX/LINUX 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 two 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 Open Magazine found
+ that of all respondents: 97% use Samba for file and print services, and 68% 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, as shown in
+ <link linkend="ch09openmag"/>.
+ </para>
+
+ <image id="ch09openmag">
+ <description>Open Magazine Samba Survey</description>
+ <imagefile scale="60">openmag.png</imagefile>
+ </image>
+
+ <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 Abmas and our good friends Bob Jordan and company.
+ </para>
+
+<sect1>
+ <title>Introduction</title>
+
+ <para><indexterm>
+ <primary>Linux desktop</primary>
+ </indexterm><indexterm>
+ <primary>Domain Member</primary>
+ <secondary>server</secondary>
+ </indexterm>
+ Bob Jordan looks back over the achievements of the past year or two. Daily events are rather straightforward
+ with not too many distractions or problems. Bob, 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 Soroka 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. Go on, walk the steps
+ with Stan and Company.
+ </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 six 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 can not only clearly comprehend
+ the immediate technical problem, but also 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:
+
+ <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>
+ contact 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</name><value>ldap:ldap://myserver.domain</value></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>
+
+ <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 above 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 enable local accounts</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 name service switch (NSS) facility, it is imperative to use the
+ <smbconfoption><name>winbind enable local accounts</name><value>Yes</value></smbconfoption>
+ in the &smb.conf; file. This parameter specifically applies only to Domain Controllers,
+ not 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 as well as 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, as 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</name><value>Yes</value></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 security identifiers (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/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 one of 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 NOT
+ 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 &smbmdash; it's just 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 as long as we could. It is not out of laziness or out of 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-3 Domain Controller has been 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>
+ One 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> &smbmdash; 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, while here 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 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. In this example, 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/from UIDs/GIDs. This means that you are running <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 our
+ own Domain). Foreign SIDs can come from any external Domain or from Windows clients that do not
+ belong to a Domain.
+ </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, then
+ it is not necessary to run <command>winbindd</command> as long as all users can be resolved
+ locally via the <command>getpwnam()</command> system call. On NSS-enabled systems, this condition
+ is met by having:
+ </para>
+
+ <itemizedlist>
+ <listitem><para><indexterm>
+ <primary>/etc/passwd</primary>
+ </indexterm><indexterm>
+ <primary>/etc/group</primary>
+ </indexterm>
+ All 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>compat</primary>
+ </indexterm><indexterm>
+ <primary>ldap</primary>
+ </indexterm><indexterm>
+ <primary>nis</primary>
+ </indexterm><indexterm>
+ <primary>nisplus</primary>
+ </indexterm><indexterm>
+ <primary>hesoid</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, compat, db, ldap,
+ nis, nisplus, hesoid.</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>
+
+ <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>
+
+<image id="ch9-sambadc">
+ <description>Samba Domain: Samba Member Server</description>
+ <imagefile scale="75">chap9-SambaDC.png</imagefile>
+</image>
+
+ <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 as shown in Chapters 6 and 7.
+ If your network does not have an LDAP slave server (i.e., Chapter 6 configuration), you
+ must change the target LDAP server from <constant>lapdc</constant> to <constant>massive.</constant>
+ </para>
+
+ <procedure>
+ <title>Configuration of 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. 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 name service switch (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. 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 as it results in
+ doubling up of group memberships and may break winbind under certain conditions.
+ </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 &lt; /etc/openldap/idmap.LDIF
+</screen>
+ Samba automatically populates this LDAP directory container when it needs to.
+ </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>
+net rpc join -U root%not24et
+Joined domain MEGANET2.
+</screen>
+ This indicates that the Domain join succeeded.
+ </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>
+
+<smbconfexample id="ch9-sdmsdc">
+<title>Samba Domain Member in Samba Domain Control Context &smbmdash; &smb.conf; File</title>
+<smbconfcomment>Global parameters</smbconfcomment>
+<smbconfsection>[global]</smbconfsection>
+<smbconfoption><name>unix charset</name><value>LOCALE</value></smbconfoption>
+<smbconfoption><name>workgroup</name><value>MEGANET2</value></smbconfoption>
+<smbconfoption><name>security</name><value>DOMAIN</value></smbconfoption>
+<smbconfoption><name>username map</name><value>/etc/samba/smbusers</value></smbconfoption>
+<smbconfoption><name>log level</name><value>10</value></smbconfoption>
+<smbconfoption><name>syslog</name><value>0</value></smbconfoption>
+<smbconfoption><name>log file</name><value>/var/log/samba/%m</value></smbconfoption>
+<smbconfoption><name>max log size</name><value>50</value></smbconfoption>
+<smbconfoption><name>smb ports</name><value>139 445</value></smbconfoption>
+<smbconfoption><name>name resolve order</name><value>wins bcast hosts</value></smbconfoption>
+<smbconfoption><name>printcap name</name><value>CUPS</value></smbconfoption>
+<smbconfoption><name>wins server</name><value>192.168.2.1</value></smbconfoption>
+<smbconfoption><name>ldap suffix</name><value>dc=abmas,dc=biz</value></smbconfoption>
+<smbconfoption><name>ldap machine suffix</name><value>ou=People</value></smbconfoption>
+<smbconfoption><name>ldap user suffix</name><value>ou=People</value></smbconfoption>
+<smbconfoption><name>ldap group suffix</name><value>ou=Groups</value></smbconfoption>
+<smbconfoption><name>ldap idmap suffix</name><value>ou=Idmap</value></smbconfoption>
+<smbconfoption><name>ldap admin dn</name><value>cn=Manager,dc=abmas,dc=biz</value></smbconfoption>
+<smbconfoption><name>idmap backend</name><value>ldap:ldap://lapdc.abmas.biz</value></smbconfoption>
+<smbconfoption><name>idmap uid</name><value>10000-20000</value></smbconfoption>
+<smbconfoption><name>idmap gid</name><value>10000-20000</value></smbconfoption>
+<smbconfoption><name>winbind trusted domains only</name><value>Yes</value></smbconfoption>
+<smbconfoption><name>printer admin</name><value>root</value></smbconfoption>
+<smbconfoption><name>printing</name><value>cups</value></smbconfoption>
+
+<smbconfsection>[homes]</smbconfsection>
+<smbconfoption><name>comment</name><value>Home Directories</value></smbconfoption>
+<smbconfoption><name>valid users</name><value>%S</value></smbconfoption>
+<smbconfoption><name>read only</name><value>No</value></smbconfoption>
+<smbconfoption><name>browseable</name><value>No</value></smbconfoption>
+
+<smbconfsection>[printers]</smbconfsection>
+<smbconfoption><name>comment</name><value>SMB Print Spool</value></smbconfoption>
+<smbconfoption><name>path</name><value>/var/spool/samba</value></smbconfoption>
+<smbconfoption><name>guest ok</name><value>Yes</value></smbconfoption>
+<smbconfoption><name>printable</name><value>Yes</value></smbconfoption>
+<smbconfoption><name>browseable</name><value>No</value></smbconfoption>
+
+<smbconfsection>[print$]</smbconfsection>
+<smbconfoption><name>comment</name><value>Printer Drivers</value></smbconfoption>
+<smbconfoption><name>path</name><value>/var/lib/samba/drivers</value></smbconfoption>
+<smbconfoption><name>admin users</name><value>root, Administrator</value></smbconfoption>
+<smbconfoption><name>write list</name><value>root</value></smbconfoption>
+</smbconfexample>
+
+<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: compat ldap
+group: compat 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 &smbmdash; Using 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.
+ </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, do 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 wide-area network 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-nsswbnd"/>.
+ </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%not24et
+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>
+
+<smbconfexample id="ch0-NT4DSDM">
+<title>Samba Domain Member Server &smb.conf; File for NT4 Domain</title>
+<smbconfcomment>Global parameters</smbconfcomment>
+<smbconfsection>[global]</smbconfsection>
+<smbconfoption><name>unix charset</name><value>LOCALE</value></smbconfoption>
+<smbconfoption><name>workgroup</name><value>MEGANET2</value></smbconfoption>
+<smbconfoption><name>security</name><value>DOMAIN</value></smbconfoption>
+<smbconfoption><name>username map</name><value>/etc/samba/smbusers</value></smbconfoption>
+<smbconfoption><name>log level</name><value>1</value></smbconfoption>
+<smbconfoption><name>syslog</name><value>0</value></smbconfoption>
+<smbconfoption><name>log file</name><value>/var/log/samba/%m</value></smbconfoption>
+<smbconfoption><name>max log size</name><value>0</value></smbconfoption>
+<smbconfoption><name>smb ports</name><value>139 445</value></smbconfoption>
+<smbconfoption><name>name resolve order</name><value>wins bcast hosts</value></smbconfoption>
+<smbconfoption><name>printcap name</name><value>CUPS</value></smbconfoption>
+<smbconfoption><name>wins server</name><value>192.168.2.1</value></smbconfoption>
+<smbconfoption><name>idmap uid</name><value>10000-20000</value></smbconfoption>
+<smbconfoption><name>idmap gid</name><value>10000-20000</value></smbconfoption>
+<smbconfoption><name>template primary group</name><value>"Domain Users"</value></smbconfoption>
+<smbconfoption><name>template shell</name><value>/bin/bash</value></smbconfoption>
+<smbconfoption><name>winbind separator</name><value>+</value></smbconfoption>
+<smbconfoption><name>printer admin</name><value>root</value></smbconfoption>
+<smbconfoption><name>hosts allow</name><value>192.168.2., 192.168.3., 127.</value></smbconfoption>
+<smbconfoption><name>printing</name><value>cups</value></smbconfoption>
+
+<smbconfsection>[homes]</smbconfsection>
+<smbconfoption><name>comment</name><value>Home Directories</value></smbconfoption>
+<smbconfoption><name>valid users</name><value>%S</value></smbconfoption>
+<smbconfoption><name>read only</name><value>No</value></smbconfoption>
+<smbconfoption><name>browseable</name><value>No</value></smbconfoption>
+
+<smbconfsection>[printers]</smbconfsection>
+<smbconfoption><name>comment</name><value>SMB Print Spool</value></smbconfoption>
+<smbconfoption><name>path</name><value>/var/spool/samba</value></smbconfoption>
+<smbconfoption><name>guest ok</name><value>Yes</value></smbconfoption>
+<smbconfoption><name>printable</name><value>Yes</value></smbconfoption>
+<smbconfoption><name>browseable</name><value>No</value></smbconfoption>
+
+<smbconfsection>[print$]</smbconfsection>
+<smbconfoption><name>comment</name><value>Printer Drivers</value></smbconfoption>
+<smbconfoption><name>path</name><value>/var/lib/samba/drivers</value></smbconfoption>
+<smbconfoption><name>admin users</name><value>root, Administrator</value></smbconfoption>
+<smbconfoption><name>write list</name><value>root</value></smbconfoption>
+</smbconfexample>
+
+<example id="ch9-nsswbnd">
+<title>Name Service Switch Control File: <filename>/etc/nsswitch.conf</filename></title>
+<screen>
+# /etc/nsswitch.conf
+
+passwd: compat winbind
+group: compat winbind
+
+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="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-3 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-3 can participate
+ in. For now, we simply focus on how a Samba-3 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-3 interfaces with
+ Microsoft Active Directory components. It should be noted that if Microsoft Windows Services
+ for UNIX has been installed and correctly configured, it is possible to use client LDAP
+ for Identity resolution just as can be done with Samba-3 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-3 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-3
+ 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-3 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 their 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>
+
+ <image id="ch9-adsdc">
+ <description>Active Directory Domain: Samba Member Server</description>
+ <imagefile scale="75">chap9-ADSDC.png</imagefile>
+ </image>
+
+ <procedure>
+ <step><para><indexterm>
+ <primary>smbd</primary>
+ </indexterm>
+ Before you try to use Samba-3, 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>
+ The above 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-3 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-3 build you are using has the
+ necessary capabilities. You can now configure Samba-3 and the name service
+ switcher (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-nsswbnd"/>.
+ </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-3 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 as follows:
+<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-3 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.2-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-3 ADS Domain Member Server
+ called <constant>FRAN</constant>, is able to communicate fully with the ADS
+ Domain Controllers.
+ </para></step>
+ </procedure>
+
+
+ <para>
+ Your Samba-3 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 those with you, has been put at ease.
+ May this server serve well all who happen upon it.
+ </para>
+
+<smbconfexample id="ch9-adssdm">
+<title>Samba Domain Member &smb.conf; File for Active Directory Membership</title>
+<smbconfcomment>Global parameters</smbconfcomment>
+<smbconfsection>[global]</smbconfsection>
+<smbconfoption><name>unix charset</name><value>LOCALE</value></smbconfoption>
+<smbconfoption><name>workgroup</name><value>LONDON</value></smbconfoption>
+<smbconfoption><name>realm</name><value>LONDON.ABMAS.BIZ</value></smbconfoption>
+<smbconfoption><name>server string</name><value>Samba 3.0.2</value></smbconfoption>
+<smbconfoption><name>security</name><value>ADS</value></smbconfoption>
+<smbconfoption><name>username map</name><value>/etc/samba/smbusers</value></smbconfoption>
+<smbconfoption><name>log level</name><value>1</value></smbconfoption>
+<smbconfoption><name>syslog</name><value>0</value></smbconfoption>
+<smbconfoption><name>log file</name><value>/var/log/samba/%m</value></smbconfoption>
+<smbconfoption><name>max log size</name><value>50</value></smbconfoption>
+<smbconfoption><name>printcap name</name><value>CUPS</value></smbconfoption>
+<smbconfoption><name>ldap ssl</name><value>no</value></smbconfoption>
+<smbconfoption><name>idmap uid</name><value>10000-20000</value></smbconfoption>
+<smbconfoption><name>idmap gid</name><value>10000-20000</value></smbconfoption>
+<smbconfoption><name>template primary group</name><value>"Domain Users"</value></smbconfoption>
+<smbconfoption><name>template shell</name><value>/bin/bash</value></smbconfoption>
+<smbconfoption><name>winbind separator</name><value>+</value></smbconfoption>
+<smbconfoption><name>printing</name><value>cups</value></smbconfoption>
+
+<smbconfsection>[homes]</smbconfsection>
+<smbconfoption><name>comment</name><value>Home Directories</value></smbconfoption>
+<smbconfoption><name>valid users</name><value>%S</value></smbconfoption>
+<smbconfoption><name>read only</name><value>No</value></smbconfoption>
+<smbconfoption><name>browseable</name><value>No</value></smbconfoption>
+
+<smbconfsection>[printers]</smbconfsection>
+<smbconfoption><name>comment</name><value>SMB Print Spool</value></smbconfoption>
+<smbconfoption><name>path</name><value>/var/spool/samba</value></smbconfoption>
+<smbconfoption><name>guest ok</name><value>Yes</value></smbconfoption>
+<smbconfoption><name>printable</name><value>Yes</value></smbconfoption>
+<smbconfoption><name>browseable</name><value>No</value></smbconfoption>
+
+<smbconfsection>[print$]</smbconfsection>
+<smbconfoption><name>comment</name><value>Printer Drivers</value></smbconfoption>
+<smbconfoption><name>path</name><value>/var/lib/samba/drivers</value></smbconfoption>
+<smbconfoption><name>admin users</name><value>root, Administrator</value></smbconfoption>
+<smbconfoption><name>write list</name><value>root</value></smbconfoption>
+</smbconfexample>
+
+ </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>SOS</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 (SOS) solution. SOS 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>
+ Meta-directory server solutions
+ </para></listitem>
+
+ <listitem><para>
+ Replacement authentication systems
+ </para></listitem>
+ </itemizedlist>
+
+ <para><indexterm>
+ <primary>Identity management</primary>
+ </indexterm>
+ There are really only three solutions that provide integrated authentication and
+ user Identity management facilities:
+ </para>
+
+ <itemizedlist>
+ <listitem><para>
+ Samba Winbind (free)
+ </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>
+ </itemizedlist>
+
+ <para>
+ The following guidelines are pertinent in respect of the deployment of winbind-based authentication
+ and Identity resolution with the express purpose of allowing users to log onto 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-3.
+ </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 (SUS) 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 onto 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 Domain (or Samba-3) 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 onto. 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 onto. 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 onto a UNIX/Linux client.
+ </para>
+
+ <para>
+ The following are key points noted:
+ </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 (user name 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 of the fact that
+ 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, 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 that needs to be addressed 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 onto 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. One may well argue that 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. One must take account of 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>winbind enable local accounts</primary>
+ </indexterm><indexterm>
+ <primary>/etc/passwd</primary>
+ </indexterm><indexterm>
+ <primary>options list</primary>
+ </indexterm><indexterm>
+ <primary>ACL</primary>
+ </indexterm><indexterm>
+ <primary>share</primary>
+ </indexterm>
+ In my &smb.conf; file, I enabled the parameter <parameter>winbind enable local accounts
+ </parameter> on all Domain Member servers, but it does not work. The accounts I put in
+ <filename>/etc/passwd</filename> do not show up in the options list when I try to set an
+ ACL on a share. What have I done wrong?
+ </para>
+
+ </question>
+ <answer>
+
+ <para><indexterm>
+ <primary>local users</primary>
+ </indexterm><indexterm>
+ <primary>local groups</primary>
+ </indexterm><indexterm>
+ <primary>UNIX account</primary>
+ </indexterm><indexterm>
+ <primary>getpwnam()</primary>
+ </indexterm><indexterm>
+ <primary>getgrgid()</primary>
+ </indexterm><indexterm>
+ <primary>Identity resolution</primary>
+ </indexterm><indexterm>
+ <primary>failure</primary>
+ </indexterm><indexterm>
+ <primary>Domain</primary>
+ </indexterm>
+ The manual page for this &smb.conf; file parameter clearly says, <quote>This parameter
+ controls whether or not winbindd will act as a stand in replacement for the various
+ account management hooks in smb.conf (for example, add user script). If enabled, winbindd
+ will support the creation of local users and groups as another source of UNIX account
+ information available via getpwnam() or getgrgid(), etc...</quote> By default this
+ parameter is already enabled; therefore, the action you are seeing is a result of a failure
+ of Identity resolution in the Domain.
+ </para>
+
+ <para><indexterm>
+ <primary>Domain logons</primary>
+ </indexterm><indexterm>
+ <primary>Identity resolution</primary>
+ </indexterm><indexterm>
+ <primary>Domain</primary>
+ <secondary>user</secondary>
+ </indexterm><indexterm>
+ <primary>Domain</primary>
+ <secondary>group</secondary>
+ </indexterm><indexterm>
+ <primary>UID</primary>
+ </indexterm><indexterm>
+ <primary>GID</primary>
+ </indexterm>
+ These are the accounts that are available for Windows network Domain logons. Providing
+ Identity resolution has been correctly configured on the Domain Controllers, as well as
+ on Domain Member servers. The Domain user and group identities automatically map
+ to a valid local UID and GID pair.
+ </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 would clearly suggest that you are trying
+ to use this parameter inappropriately.
+ </para>
+
+ <para><indexterm>
+ <primary>valid users</primary>
+ </indexterm>
+ A far better solution would be 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-3 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 host names 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 host name 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 auto-registers all locator records it needs with its own DNS
+ server/s.
+ </para>
+
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+
+ <para>
+ Our Windows 2003 Server Active Directory Domain runs with NetBIOS disabled. Can we
+ use Samba-3 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 <quote>net ads join</quote>, I got no output. It did not work, so
+ I think that it failed. I then executed <quote>net rpc join</quote> 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-3 client has joined the ADS Domain as
+ a Windows NT4 client, and Samba-3 will not be using Kerberos-based authentication.
+ </para>
+
+ </answer>
+ </qandaentry>
+
+ </qandaset>
+
+</sect1>
+
+</chapter>