--- /dev/null
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 7. Adding Domain Member Servers and Clients</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.68.1"><link rel="start" href="index.html" title="Samba-3 by Example"><link rel="up" href="DMSMig.html" title="Part II. Domain Members, Updating Samba and Migration"><link rel="prev" href="DMSMig.html" title="Part II. Domain Members, Updating Samba and Migration"><link rel="next" href="upgrades.html" title="Chapter 8. Updating Samba-3"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 7. Adding Domain Member Servers and Clients</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="DMSMig.html">Prev</a> </td><th width="60%" align="center">Part II. Domain Members, Updating Samba and Migration</th><td width="20%" align="right"> <a accesskey="n" href="upgrades.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="unixclients"></a>Chapter 7. Adding Domain Member Servers and Clients</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="unixclients.html#id2557211">Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="unixclients.html#id2557265">Assignment Tasks</a></span></dt></dl></dd><dt><span class="sect1"><a href="unixclients.html#id2557300">Dissection and Discussion</a></span></dt><dd><dl><dt><span class="sect2"><a href="unixclients.html#id2557328">Technical Issues</a></span></dt><dt><span class="sect2"><a href="unixclients.html#id2557963">Political Issues</a></span></dt></dl></dd><dt><span class="sect1"><a href="unixclients.html#id2558056">Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="unixclients.html#sdcsdmldap">Samba Domain with Samba Domain Member Server Using NSS LDAP</a></span></dt><dt><span class="sect2"><a href="unixclients.html#wdcsdm">NT4/Samba Domain with Samba Domain Member Server: Using NSS and Winbind</a></span></dt><dt><span class="sect2"><a href="unixclients.html#dcwonss">NT4/Samba Domain with Samba Domain Member Server without NSS Support</a></span></dt><dt><span class="sect2"><a href="unixclients.html#adssdm">Active Directory Domain with Samba Domain Member Server</a></span></dt><dt><span class="sect2"><a href="unixclients.html#id2564417">UNIX/Linux Client Domain Member</a></span></dt><dt><span class="sect2"><a href="unixclients.html#id2564991">Key Points Learned</a></span></dt></dl></dd><dt><span class="sect1"><a href="unixclients.html#id2565045">Questions and Answers</a></span></dt></dl></div><p><a class="indexterm" name="id2557113"></a><a class="indexterm" name="id2557121"></a>
+ The most frequently discussed Samba subjects over the past 2 years have focused around domain control and printing.
+ It is well known that Samba is a file and print server. A recent survey conducted by <span class="emphasis"><em>Open Magazine</em></span> found
+ that of all respondents, 97 percent use Samba for file and print services, and 68 percent use Samba for Domain Control. See the
+ <a href="http://www.open-mag.com/cgi-bin/opencgi/surveys/survey.cgi?survey_name=samba" target="_top">Open-Mag</a>
+ Web site for current information. The survey results as found on January 14, 2004, are shown in
+ <a href="unixclients.html#ch09openmag" title="Figure 7.1. Open Magazine Samba Survey">???</a>.
+ </p><div class="figure"><a name="ch09openmag"></a><p class="title"><b>Figure 7.1. Open Magazine Samba Survey</b></p><div class="mediaobject"><img src="images/openmag.png" width="324" alt="Open Magazine Samba Survey"></div></div><p>
+ 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 whatever the controlling technology
+ may be. So let's get back to our good friends at Abmas.
+ </p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2557211"></a>Introduction</h2></div></div></div><p><a class="indexterm" name="id2557218"></a><a class="indexterm" name="id2557225"></a>
+ Looking back over the achievements of the past year or two, daily events at Abmas are rather straightforward
+ with not too many distractions or problems. Your team is doing well, but a number of employees
+ are asking for Linux desktop systems. Your network has grown and demands additional domain member servers. Let's
+ get on with this; Christine and Stan are ready to go.
+ </p><p><a class="indexterm" name="id2557246"></a>
+ Stan is firmly in control of the department of the future, while Christine is enjoying a stable and
+ predictable network environment. It is time to add more servers and to add Linux desktops. It is
+ time to meet the demands of future growth and endure trial by fire.
+ </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2557265"></a>Assignment Tasks</h3></div></div></div><p><a class="indexterm" name="id2557271"></a>
+ 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.
+ </p><p>
+ Over the past 6 months, you have hired several new staff who want Linux on their desktops. You must integrate
+ these systems to make sure that Abmas is not building islands of technology. You ask Christine to
+ do likewise at Swodniw Biz NL (your friend's company) to help them to evaluate a Linux desktop. You want to make
+ the right decision, don't you?
+ </p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2557300"></a>Dissection and Discussion</h2></div></div></div><p>
+ <a class="indexterm" name="id2557308"></a>
+ 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.
+ </p><p>
+ 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.
+ </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2557328"></a>Technical Issues</h3></div></div></div><p>
+ One of the great challenges we face when people ask us, “<span class="quote">What is the best way to solve
+ this problem?</span>” is to get beyond the facts so we not only can clearly comprehend
+ the immediate technical problem, but also can understand how needs may change.
+ </p><p>
+ <a class="indexterm" name="id2557347"></a>
+ 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:
+ </p><div class="itemizedlist"><ul type="disc"><li><p>
+ <a class="indexterm" name="id2557363"></a>
+ <a class="indexterm" name="id2557370"></a>
+ <a class="indexterm" name="id2557377"></a>
+ <a class="indexterm" name="id2557386"></a>
+ <a class="indexterm" name="id2557393"></a>
+ 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.
+ </p></li><li><p>
+ <a class="indexterm" name="id2557408"></a>
+ <a class="indexterm" name="id2557415"></a>
+ <a class="indexterm" name="id2557427"></a>
+ <a class="indexterm" name="id2557434"></a>
+ 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 <span><strong class="command">winbindd</strong></span>.
+ </p></li><li><p>
+ Samba, when running on a domain member server, can resolve user identities from a
+ number of sources:
+ </p><div class="itemizedlist"><ul type="circle"><li><p>
+ <a class="indexterm" name="id2557466"></a>
+ <a class="indexterm" name="id2557473"></a>
+ <a class="indexterm" name="id2557480"></a>
+ <a class="indexterm" name="id2557486"></a>
+ <a class="indexterm" name="id2557493"></a>
+ By executing a system <span><strong class="command">getpwnam()</strong></span> or <span><strong class="command">getgrnam()</strong></span> call.
+ On systems that support it, this utilizes the name service switch (NSS) facility to
+ resolve names according to the configuration of the <code class="filename">/etc/nsswitch.conf</code>
+ file. NSS can be configured to use LDAP, winbind, NIS, or local files.
+ </p></li><li><p>
+ <a class="indexterm" name="id2557526"></a>
+ <a class="indexterm" name="id2557533"></a>
+ <a class="indexterm" name="id2557540"></a>
+ 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).
+ </p></li><li><p>
+ <a class="indexterm" name="id2557554"></a>
+ <a class="indexterm" name="id2557561"></a>
+ <a class="indexterm" name="id2557568"></a>
+ <a class="indexterm" name="id2557574"></a>
+ Directly by querying <span><strong class="command">winbindd</strong></span>. The <span><strong class="command">winbindd</strong></span>
+ contacts a domain controller to attempt to resolve the identity of the user or group. It
+ receives the Windows networking security identifier (SID) for that appropriate
+ account and then allocates a local UID or GID from the range of available IDs and
+ creates an entry in its <code class="filename">winbindd_idmap.tdb</code> and
+ <code class="filename">winbindd_cache.tdb</code> files.
+ </p><p>
+ <a class="indexterm" name="id2557614"></a>
+ <a class="indexterm" name="id2557621"></a>
+ If the parameter <a class="indexterm" name="id2557628"></a>idmap backend = ldap:ldap://myserver.domain
+ 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.
+ </p></li></ul></div><p>
+ Irrespective of how <code class="filename">smb.conf</code> is configured, winbind creates and caches a local copy of
+ the ID mapping database. It uses the <code class="filename">winbindd_idmap.tdb</code> and
+ <code class="filename">winbindd_cache.tdb</code> files to do this.
+ </p><p>
+ Which of the resolver methods is chosen is determined by the way that Samba is configured
+ in the <code class="filename">smb.conf</code> file. Some of the configuration options are rather less than obvious to the
+ casual user.
+ </p></li><li><p>
+ <a class="indexterm" name="id2557681"></a>
+ <a class="indexterm" name="id2557688"></a>
+ <a class="indexterm" name="id2557698"></a>
+ If you wish to make use of accounts (users and/or groups) that are local to (i.e., capable
+ of being resolved using) the NSS facility, it is possible to use the
+ <a class="indexterm" name="id2557708"></a>winbind trusted domains only = Yes
+ in the <code class="filename">smb.conf</code> file. This parameter specifically applies to domain controllers,
+ and to domain member servers.
+ </p></li></ul></div><p>
+ <a class="indexterm" name="id2557728"></a>
+ <a class="indexterm" name="id2557735"></a>
+ <a class="indexterm" name="id2557742"></a>
+ For many administrators, it should be plain that the use of an LDAP-based repository for all network
+ accounts (both for POSIX accounts and for Samba accounts) provides the most elegant and
+ controllable facility. You eventually appreciate the decision to use LDAP.
+ </p><p>
+ <a class="indexterm" name="id2557756"></a>
+ <a class="indexterm" name="id2557763"></a>
+ <a class="indexterm" name="id2557770"></a>
+ 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 <span><strong class="command">nss_ldap</strong></span>
+ tools to resolve UNIX account UIDs/GIDs via LDAP, this is the preferred solution, because it provides
+ a more readily controllable method for asserting the exact same user and group identifiers
+ throughout the network.
+ </p><p>
+ <a class="indexterm" name="id2557792"></a>
+ <a class="indexterm" name="id2557802"></a>
+ <a class="indexterm" name="id2557809"></a>
+ <a class="indexterm" name="id2557816"></a>
+ <a class="indexterm" name="id2557823"></a>
+ <a class="indexterm" name="id2557830"></a>
+ In the situation where UNIX accounts are held on the domain member server itself, the only effective
+ way to use them involves the <code class="filename">smb.conf</code> entry
+ <a class="indexterm" name="id2557845"></a>winbind trusted domains only = Yes. This forces
+ Samba (<span><strong class="command">smbd</strong></span>) to perform a <span><strong class="command">getpwnam()</strong></span> system call that can
+ then be controlled via <code class="filename">/etc/nsswitch.conf</code> file settings. The use of this parameter
+ disables the use of Samba with trusted domains (i.e., external domains).
+ </p><p>
+ <a class="indexterm" name="id2557877"></a>
+ <a class="indexterm" name="id2557884"></a>
+ <a class="indexterm" name="id2557893"></a>
+ <a class="indexterm" name="id2557900"></a>
+ Winbind can be used to create an appliance mode domain member server. In this capacity, <span><strong class="command">winbindd</strong></span>
+ is configured to automatically allocate UIDs/GIDs from numeric ranges set in the <code class="filename">smb.conf</code> 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 however, this is transparent to the Windows network user. This data
+ is stored in the <code class="filename">winbindd_idmap.tdb</code> and <code class="filename">winbindd_cache.tdb</code> files.
+ </p><p>
+ <a class="indexterm" name="id2557948"></a>
+ The use of an LDAP backend for the Winbind IDMAP facility permits Windows domain SIDs
+ mappings to UIDs/GIDs to be stored centrally. The result is a consistent mapping across all domain member
+ servers so configured. This solves one of the major headaches for network administrators who need to copy
+ files between or across network file servers.
+ </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2557963"></a>Political Issues</h3></div></div></div><p>
+ <a class="indexterm" name="id2557971"></a>
+ <a class="indexterm" name="id2557978"></a>
+ <a class="indexterm" name="id2557984"></a>
+ <a class="indexterm" name="id2557993"></a>
+ One of the most fierce conflicts recently being waged is resistance to the adoption of LDAP, in
+ particular OpenLDAP, as a replacement for UNIX NIS (previously called Yellow Pages). Let's face it, LDAP
+ is different and requires a new approach to the need for a better identity management solution. The more
+ you work with LDAP, the more its power and flexibility emerges from its dark, cavernous chasm.
+ </p><p>
+ 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 <span class="emphasis"><em>not</em></span>
+ heterogenous by design. This is fundamental it isn't religious or political. This also doesn't say that
+ you can't use Windows Active Directory in a heterogenous environment it can be done, it just requires
+ commercial integration products. But it's not what Active Directory was designed for.
+ </p><p>
+ <a class="indexterm" name="id2558032"></a>
+ <a class="indexterm" name="id2558038"></a>
+ A number of long-term UNIX devotees have recently commented in various communications that the Samba Team
+ is the first application group to almost force network administrators to use LDAP. It should be pointed
+ out that we resisted this for as long as we could. It is not out of laziness or malice that LDAP has
+ finally emerged as the preferred identity management backend for Samba. We recommend LDAP for your total
+ organizational directory needs.
+ </p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2558056"></a>Implementation</h2></div></div></div><p>
+ <a class="indexterm" name="id2558064"></a>
+ <a class="indexterm" name="id2558073"></a>
+ <a class="indexterm" name="id2558082"></a>
+ The domain member server and the domain member client are at the center of focus in this chapter.
+ Configuration of Samba-3 domain controller is covered in earlier chapters, so if your
+ interest is in domain controller configuration, you will not find that here. You will find good
+ oil that helps you to add domain member servers and clients.
+ </p><p>
+ <a class="indexterm" name="id2558098"></a>
+ 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.
+ </p><p>
+ <a class="indexterm" name="id2558121"></a>
+ We can look at this another way. If a workstation breaks down, one user is affected, but if a
+ server breaks down, hundreds of users may not be able to work. The services that a workstation
+ must provide are document- and file-production oriented; a server provides information storage
+ and is distribution oriented.
+ </p><p>
+ <a class="indexterm" name="id2558136"></a>
+ <a class="indexterm" name="id2558143"></a>
+ <a class="indexterm" name="id2558150"></a>
+ <span class="emphasis"><em>Why is this important?</em></span> 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.
+ </p><p>
+ So, in this chapter we demonstrate how to implement the technology. It is done within a context of
+ what type of service need must be fulfilled.
+ </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="sdcsdmldap"></a>Samba Domain with Samba Domain Member Server Using NSS LDAP</h3></div></div></div><p>
+ <a class="indexterm" name="id2558192"></a>
+ <a class="indexterm" name="id2558198"></a>
+ <a class="indexterm" name="id2558205"></a>
+ <a class="indexterm" name="id2558212"></a>
+ <a class="indexterm" name="id2558221"></a>
+ <a class="indexterm" name="id2558228"></a>
+ In this example, it is assumed that you have Samba PDC/BDC servers. This means you are using
+ an LDAP ldapsam backend. We are adding to the LDAP backend database (directory)
+ containers for use by the IDMAP facility. This makes it possible to have globally consistent
+ mapping of SIDs to and from UIDs and GIDs. This means that it is necessary to run
+ <span><strong class="command">winbindd</strong></span> as part of your configuration. The primary purpose of running
+ <span><strong class="command">winbindd</strong></span> (within this operational context) is to permit mapping of foreign
+ SIDs (those not originating from the the local Samba server). Foreign SIDs can come from any
+ domain member client or server, or from Windows clients that do not belong to a domain. Another
+ way to explain the necessity to run <span><strong class="command">winbindd</strong></span> is that Samba can locally
+ resolve only accounts that belong to the security context of its own machine SID. Winbind
+ handles all non-local SIDs and maps them to a local UID/GID value. The UID and GID are allocated
+ from the parameter values set in the <code class="filename">smb.conf</code> file for the <em class="parameter"><code>idmap uid</code></em> and
+ <em class="parameter"><code>idmap gid</code></em> ranges. Where LDAP is used, the mappings can be stored in LDAP
+ so that all domain member servers can use a consistent mapping.
+ </p><p>
+ <a class="indexterm" name="id2558298"></a>
+ <a class="indexterm" name="id2558305"></a>
+ <a class="indexterm" name="id2558311"></a>
+ If your installation is accessed only from clients that are members of your own domain, and all
+ user accounts are present in a local passdb backend then it is not necessary to run
+ <span><strong class="command">winbindd</strong></span>. The local passdb backend can be in smbpasswd, tdbsam, or in ldapsam.
+ </p><p>
+ It is possible to use a local passdb backend with any convenient means of resolving the POSIX
+ user and group account information. The POSIX information is usually obtained using the
+ <span><strong class="command">getpwnam()</strong></span> system call. On NSS-enabled systems, the actual POSIX account
+ source can be provided from
+ </p><div class="itemizedlist"><ul type="disc"><li><p>
+ <a class="indexterm" name="id2558348"></a>
+ <a class="indexterm" name="id2558355"></a>
+ Accounts in <code class="filename">/etc/passwd</code> or in <code class="filename">/etc/group</code>.
+ </p></li><li><p>
+ <a class="indexterm" name="id2558379"></a>
+ <a class="indexterm" name="id2558385"></a>
+ <a class="indexterm" name="id2558392"></a>
+ <a class="indexterm" name="id2558399"></a>
+ <a class="indexterm" name="id2558406"></a>
+ <a class="indexterm" name="id2558413"></a>
+ <a class="indexterm" name="id2558419"></a>
+ <a class="indexterm" name="id2558426"></a>
+ <a class="indexterm" name="id2558433"></a>
+ Resolution via NSS. On NSS-enabled systems, there is usually a facility to resolve IDs
+ via multiple methods. The methods typically include <span><strong class="command">files</strong></span>,
+ <span><strong class="command">compat</strong></span>, <span><strong class="command">db</strong></span>, <span><strong class="command">ldap</strong></span>,
+ <span><strong class="command">nis</strong></span>, <span><strong class="command">nisplus</strong></span>, <span><strong class="command">hesiod.</strong></span> When
+ correctly installed, Samba adds to this list the <span><strong class="command">winbindd</strong></span> facility.
+ The ldap facility is frequently the nss_ldap tool provided by PADL Software.
+ </p></li></ul></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+ To advoid confusion the use of the term <code class="literal">local passdb backend</code> means that
+ the user account backend is not shared by any other Samba server instead, it is
+ used only locally on the Samba domain member server under discussion.
+ </p></div><p>
+ <a class="indexterm" name="id2558513"></a>
+ The diagram in <a href="unixclients.html#ch9-sambadc" title="Figure 7.2. Samba Domain: Samba Member Server">???</a> 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.
+ </p><div class="figure"><a name="ch9-sambadc"></a><p class="title"><b>Figure 7.2. Samba Domain: Samba Member Server</b></p><div class="mediaobject"><img src="images/chap9-SambaDC.png" width="324" alt="Samba Domain: Samba Member Server"></div></div><p>
+ <a class="indexterm" name="id2558574"></a>
+ <a class="indexterm" name="id2558581"></a>
+ 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.
+ </p><p>
+ The instructions given here apply to the Samba environment shown in <a href="happy.html" title="Chapter 5. Making Happy Users">???</a> and <a href="2000users.html" title="Chapter 6. A Distributed 2000-User Network">???</a>.
+ If the network does not have an LDAP slave server (i.e., <a href="happy.html" title="Chapter 5. Making Happy Users">???</a> configuration),
+ change the target LDAP server from <code class="constant">lapdc</code> to <code class="constant">massive.</code>
+ </p><div class="procedure"><a name="id2558629"></a><p class="title"><b>Procedure 7.1. Configuration of NSS_LDAP-Based Identity Resolution</b></p><ol type="1"><li><p>
+ Create the <code class="filename">smb.conf</code> file as shown in <a href="unixclients.html#ch9-sdmsdc" title="Example 7.1. Samba Domain Member in Samba Domain Using LDAP smb.conf File">???</a>. Locate
+ this file in the directory <code class="filename">/etc/samba</code>.
+ </p></li><li><p>
+ <a class="indexterm" name="id2558667"></a>
+ Configure the file that will be used by <code class="constant">nss_ldap</code> to
+ locate and communicate with the LDAP server. This file is called <code class="filename">ldap.conf</code>.
+ If your implementation of <code class="constant">nss_ldap</code> is consistent with
+ the defaults suggested by PADL (the authors), it will be located in the
+ <code class="filename">/etc</code> directory. On some systems, the default location is
+ the <code class="filename">/etc/openldap</code> directory, however this file is intended
+ for use by the OpenLDAP utilities and should not really be used by the nss_ldap
+ utility since its content and structure serves the specific purpose of enabling
+ the resolution of user and group IDs via NSS.
+ </p><p>
+ Change the parameters inside the file that is located on your OS so it matches
+ <a href="unixclients.html#ch9-sdmlcnf" title="Example 7.3. Configuration File for NSS LDAP Support /etc/ldap.conf">???</a>. To find the correct location of this file, you
+ can obtain this from the library that will be used by executing the following:
+</p><pre class="screen">
+<code class="prompt">root# </code> strings /lib/libnss_ldap* | grep ldap.conf
+/etc/ldap.conf
+</pre><p>
+ </p></li><li><p>
+ Configure the NSS control file so it matches the one shown in
+ <a href="unixclients.html#ch9-sdmnss" title="Example 7.4. NSS using LDAP for Identity Resolution File: /etc/nsswitch.conf">???</a>.
+ </p></li><li><p>
+ <a class="indexterm" name="id2558755"></a>
+ <a class="indexterm" name="id2558762"></a>
+ Before proceeding to configure Samba, validate the operation of the NSS identity
+ resolution via LDAP by executing:
+</p><pre class="screen">
+<code class="prompt">root# </code> 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
+</pre><p>
+ 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.
+</p><pre class="screen">
+<code class="prompt">root# </code> 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:
+</pre><p>
+ <a class="indexterm" name="id2558815"></a>
+ <a class="indexterm" name="id2558822"></a>
+ <a class="indexterm" name="id2558829"></a>
+ This shows that all is working as it should be. Notice that in the LDAP database
+ the users' primary and secondary group memberships are identical. It is not
+ necessary to add secondary group memberships (in the group database) if the
+ user is already a member via primary group membership in the password database.
+ When using winbind, it is in fact undesirable to do this because it results in
+ doubling up of group memberships and may cause problems with winbind under certain
+ conditions. It is intended that these limitations with winbind will be resolved soon
+ after Samba-3.0.20 has been released.
+ </p></li><li><p>
+ <a class="indexterm" name="id2558853"></a>
+ 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:
+</p><pre class="screen">
+<code class="prompt">root# </code> slapcat | grep -i idmap
+dn: ou=Idmap,dc=abmas,dc=biz
+ou: idmap
+</pre><p>
+ <a class="indexterm" name="id2558876"></a>
+ If the execution of this command does not return IDMAP entries, you need to create an LDIF
+ template file (see <a href="unixclients.html#ch9-ldifadd" title="Example 7.2. LDIF IDMAP Add-On Load File File: /etc/openldap/idmap.LDIF">???</a>). You can add the required entries using
+ the following command:
+</p><pre class="screen">
+<code class="prompt">root# </code> ldapadd -x -D "cn=Manager,dc=abmas,dc=biz" \
+ -w not24get < /etc/openldap/idmap.LDIF
+</pre><p>
+ </p></li><li><p>
+ Samba automatically populates the LDAP directory container when it needs to. To permit Samba
+ write access to the LDAP directory it is necessary to set the LDAP administrative password
+ in the <code class="filename">secrets.tdb</code> file as shown here:
+</p><pre class="screen">
+<code class="prompt">root# </code> smbpasswd -w not24get
+</pre><p>
+ </p></li><li><p>
+ <a class="indexterm" name="id2558940"></a>
+ <a class="indexterm" name="id2558951"></a>
+ The system is ready to join the domain. Execute the following:
+</p><pre class="screen">
+<code class="prompt">root# </code> net rpc join -U root%not24get
+Joined domain MEGANET2.
+</pre><p>
+ This indicates that the domain join succeeded.
+ </p><p>
+ Failure to join the domain could be caused by any number of variables. The most common
+ causes of failure to join are:
+ </p><p>
+ </p><div class="itemizedlist"><ul type="disc"><li><p>Broken resolution of NetBIOS names to the respective IP address.</p></li><li><p>Incorrect username and password credentials.</p></li><li><p>The NT4 <em class="parameter"><code>restrict anonymous</code></em> is set to exclude anonymous
+ connections.</p></li></ul></div><p>
+ </p><p>
+ The connection setup can be diagnosed by executing:
+</p><pre class="screen">
+<code class="prompt">root# </code> net rpc join -S 'pdc-name' -U administrator%password -d 5
+</pre><p>
+ <a class="indexterm" name="id2559023"></a>
+ <a class="indexterm" name="id2559030"></a>
+ <a class="indexterm" name="id2559037"></a>
+ <a class="indexterm" name="id2559044"></a>
+ Note: Use "root" for UNIX/Linux and Samba, use "Administrator" for Windows NT4/200X. If the cause of
+ the failure appears to be related to a rejected or failed NT_SESSION_SETUP* or an error message that
+ says NT_STATUS_ACCESS_DENIED immediately check the Windows registry setting that controls the
+ <code class="constant">restrict anonymous</code> setting. Set this to the value 0 so that an anonymous connection
+ can be sustained, then try again.
+ </p><p>
+ It is possible (perhaps even recommended) to use the following to validate the ability to connect
+ to an NT4 PDC/BDC:
+</p><pre class="screen">
+<code class="prompt">root# </code> net rpc info -S 'pdc-name' -U Administrator%not24get
+Domain Name: MEGANET2
+Domain SID: S-1-5-21-422319763-4138913805-7168186429
+Sequence number: 1519909596
+Num users: 7003
+Num domain groups: 821
+Num local groups: 8
+
+<code class="prompt">root# </code> net rpc testjoin -S 'pdc-name' -U Administrator%not24get
+Join to 'MEGANET2' is OK
+</pre><p>
+ If for any reason the following response is obtained to the last command above,it is time to
+ call in the Networking Super-Snooper task force (i.e., start debugging):
+</p><pre class="screen">
+NT_STATUS_ACCESS_DENIED
+Join to 'MEGANET2' failed.
+</pre><p>
+ </p></li><li><p>
+ <a class="indexterm" name="id2559105"></a>
+ Just joining the domain is not quite enough; you must now provide a privileged set
+ of credentials through which <span><strong class="command">winbindd</strong></span> can interact with the
+ domain servers. Execute the following to implant the necessary credentials:
+</p><pre class="screen">
+<code class="prompt">root# </code> wbinfo --set-auth-user=Administrator%not24get
+</pre><p>
+ The configuration is now ready to obtain the Samba domain user and group information.
+ </p></li><li><p>
+ You may now start Samba in the usual manner, and your Samba domain member server
+ is ready for use. Just add shares as required.
+ </p></li></ol></div><div class="example"><a name="ch9-sdmsdc"></a><p class="title"><b>Example 7.1. Samba Domain Member in Samba Domain Using LDAP <code class="filename">smb.conf</code> File</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td># Global parameters</td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[global]</code></em></td></tr><tr><td><a class="indexterm" name="id2559183"></a><em class="parameter"><code>unix charset = LOCALE</code></em></td></tr><tr><td><a class="indexterm" name="id2559196"></a><em class="parameter"><code>workgroup = MEGANET2</code></em></td></tr><tr><td><a class="indexterm" name="id2559209"></a><em class="parameter"><code>security = DOMAIN</code></em></td></tr><tr><td><a class="indexterm" name="id2559221"></a><em class="parameter"><code>username map = /etc/samba/smbusers</code></em></td></tr><tr><td><a class="indexterm" name="id2559234"></a><em class="parameter"><code>log level = 10</code></em></td></tr><tr><td><a class="indexterm" name="id2559247"></a><em class="parameter"><code>syslog = 0</code></em></td></tr><tr><td><a class="indexterm" name="id2559260"></a><em class="parameter"><code>log file = /var/log/samba/%m</code></em></td></tr><tr><td><a class="indexterm" name="id2559272"></a><em class="parameter"><code>max log size = 50</code></em></td></tr><tr><td><a class="indexterm" name="id2559285"></a><em class="parameter"><code>smb ports = 139</code></em></td></tr><tr><td><a class="indexterm" name="id2559298"></a><em class="parameter"><code>name resolve order = wins bcast hosts</code></em></td></tr><tr><td><a class="indexterm" name="id2559311"></a><em class="parameter"><code>printcap name = CUPS</code></em></td></tr><tr><td><a class="indexterm" name="id2559324"></a><em class="parameter"><code>wins server = 192.168.2.1</code></em></td></tr><tr><td><a class="indexterm" name="id2559337"></a><em class="parameter"><code>ldap suffix = dc=abmas,dc=biz</code></em></td></tr><tr><td><a class="indexterm" name="id2559350"></a><em class="parameter"><code>ldap machine suffix = ou=People</code></em></td></tr><tr><td><a class="indexterm" name="id2559363"></a><em class="parameter"><code>ldap user suffix = ou=People</code></em></td></tr><tr><td><a class="indexterm" name="id2559376"></a><em class="parameter"><code>ldap group suffix = ou=Groups</code></em></td></tr><tr><td><a class="indexterm" name="id2559389"></a><em class="parameter"><code>ldap idmap suffix = ou=Idmap</code></em></td></tr><tr><td><a class="indexterm" name="id2559402"></a><em class="parameter"><code>ldap admin dn = cn=Manager,dc=abmas,dc=biz</code></em></td></tr><tr><td><a class="indexterm" name="id2559415"></a><em class="parameter"><code>idmap backend = ldap:ldap://lapdc.abmas.biz</code></em></td></tr><tr><td><a class="indexterm" name="id2559428"></a><em class="parameter"><code>idmap uid = 10000-20000</code></em></td></tr><tr><td><a class="indexterm" name="id2559441"></a><em class="parameter"><code>idmap gid = 10000-20000</code></em></td></tr><tr><td><a class="indexterm" name="id2559454"></a><em class="parameter"><code>winbind trusted domains only = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id2559467"></a><em class="parameter"><code>printer admin = root</code></em></td></tr><tr><td><a class="indexterm" name="id2559480"></a><em class="parameter"><code>printing = cups</code></em></td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[homes]</code></em></td></tr><tr><td><a class="indexterm" name="id2559502"></a><em class="parameter"><code>comment = Home Directories</code></em></td></tr><tr><td><a class="indexterm" name="id2559515"></a><em class="parameter"><code>valid users = %S</code></em></td></tr><tr><td><a class="indexterm" name="id2559527"></a><em class="parameter"><code>read only = No</code></em></td></tr><tr><td><a class="indexterm" name="id2559540"></a><em class="parameter"><code>browseable = No</code></em></td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[printers]</code></em></td></tr><tr><td><a class="indexterm" name="id2559562"></a><em class="parameter"><code>comment = SMB Print Spool</code></em></td></tr><tr><td><a class="indexterm" name="id2559574"></a><em class="parameter"><code>path = /var/spool/samba</code></em></td></tr><tr><td><a class="indexterm" name="id2559587"></a><em class="parameter"><code>guest ok = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id2559600"></a><em class="parameter"><code>printable = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id2559613"></a><em class="parameter"><code>browseable = No</code></em></td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[print$]</code></em></td></tr><tr><td><a class="indexterm" name="id2559634"></a><em class="parameter"><code>comment = Printer Drivers</code></em></td></tr><tr><td><a class="indexterm" name="id2559647"></a><em class="parameter"><code>path = /var/lib/samba/drivers</code></em></td></tr><tr><td><a class="indexterm" name="id2559660"></a><em class="parameter"><code>admin users = root, Administrator</code></em></td></tr><tr><td><a class="indexterm" name="id2559673"></a><em class="parameter"><code>write list = root</code></em></td></tr></table></div><div class="example"><a name="ch9-ldifadd"></a><p class="title"><b>Example 7.2. LDIF IDMAP Add-On Load File File: /etc/openldap/idmap.LDIF</b></p><pre class="screen">
+dn: ou=Idmap,dc=abmas,dc=biz
+objectClass: organizationalUnit
+ou: idmap
+structuralObjectClass: organizationalUnit
+</pre></div><div class="example"><a name="ch9-sdmlcnf"></a><p class="title"><b>Example 7.3. Configuration File for NSS LDAP Support <code class="filename">/etc/ldap.conf</code></b></p><pre class="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
+</pre></div><div class="example"><a name="ch9-sdmnss"></a><p class="title"><b>Example 7.4. NSS using LDAP for Identity Resolution File: <code class="filename">/etc/nsswitch.conf</code></b></p><pre class="screen">
+passwd: files ldap
+shadow: files ldap
+group: files ldap
+
+hosts: files dns wins
+networks: files dns
+
+services: files
+protocols: files
+rpc: files
+ethers: files
+netmasks: files
+netgroup: files
+publickey: files
+
+bootparams: files
+automount: files
+aliases: files
+</pre></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="wdcsdm"></a>NT4/Samba Domain with Samba Domain Member Server: Using NSS and Winbind</h3></div></div></div><p>
+ You need to use this method for creating a Samba domain member server if any of the following conditions
+ prevail:
+ </p><div class="itemizedlist"><ul type="disc"><li><p>
+ LDAP support (client) is not installed on the system.
+ </p></li><li><p>
+ There are mitigating circumstances forcing a decision not to use LDAP.
+ </p></li><li><p>
+ The Samba domain member server must be part of a Windows NT4 Domain, or a Samba Domain.
+ </p></li></ul></div><p>
+ <a class="indexterm" name="id2559805"></a>
+ <a class="indexterm" name="id2559812"></a>
+ <a class="indexterm" name="id2559819"></a>
+ 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.
+ </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+ <a class="indexterm" name="id2559834"></a>
+ If you use <span><strong class="command">winbind</strong></span> for identity resolution, make sure that there are no
+ duplicate accounts.
+ </p><p>
+ <a class="indexterm" name="id2559852"></a>
+ For example, do not have more than one account that has UID=0 in the password database. If there
+ is an account called <code class="constant">root</code> in the <code class="filename">/etc/passwd</code> database,
+ it is okay to have an account called <code class="constant">root</code> 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 <code class="constant">Administrator</code> account must be called
+ <code class="constant">root</code>.
+ </p><p>
+ <a class="indexterm" name="id2559888"></a>
+ <a class="indexterm" name="id2559895"></a>
+ <a class="indexterm" name="id2559902"></a>
+ Winbind will break if there is an account in <code class="filename">/etc/passwd</code> that has
+ the same UID as an account that is in LDAP ldapsam (or in tdbsam) but that differs in name only.
+ </p></div><p>
+ <a class="indexterm" name="id2559921"></a>
+ <a class="indexterm" name="id2559928"></a>
+ <a class="indexterm" name="id2559934"></a>
+ <a class="indexterm" name="id2559941"></a>
+ <a class="indexterm" name="id2559950"></a>
+ The following configuration uses CIFS/SMB protocols alone to obtain user and group credentials.
+ The winbind information is locally cached in the <code class="filename">winbindd_cache.tdb winbindd_idmap.tdb</code>
+ files. This provides considerable performance benefits compared with the LDAP solution, particularly
+ where the LDAP lookups must traverse WAN links. You may examine the contents of these
+ files using the tool <span><strong class="command">tdbdump</strong></span>, 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.
+ </p><div class="procedure"><a name="id2559979"></a><p class="title"><b>Procedure 7.2. Configuration of Winbind-Based Identity Resolution</b></p><ol type="1"><li><p>
+ Using your favorite text editor, create the <code class="filename">smb.conf</code> file so it has the contents
+ shown in <a href="unixclients.html#ch0-NT4DSDM" title="Example 7.5. Samba Domain Member Server Using Winbind smb.conf File for NT4 Domain">???</a>.
+ </p></li><li><p>
+ <a class="indexterm" name="id2560012"></a>
+ Edit the <code class="filename">/etc/nsswitch.conf</code> so it has the entries shown in
+ <a href="unixclients.html#ch9-sdmnss" title="Example 7.4. NSS using LDAP for Identity Resolution File: /etc/nsswitch.conf">???</a>.
+ </p></li><li><p>
+ <a class="indexterm" name="id2560038"></a>
+ The system is ready to join the domain. Execute the following:
+</p><pre class="screen">
+net rpc join -U root%not2g4et
+Joined domain MEGANET2.
+</pre><p>
+ This indicates that the domain join succeed.
+
+ </p></li><li><p>
+ <a class="indexterm" name="id2560065"></a>
+ <a class="indexterm" name="id2560071"></a>
+ Validate operation of <span><strong class="command">winbind</strong></span> using the <span><strong class="command">wbinfo</strong></span>
+ tool as follows:
+</p><pre class="screen">
+<code class="prompt">root# </code> wbinfo -u
+MEGANET2+root
+MEGANET2+nobody
+MEGANET2+jht
+MEGANET2+maryv
+MEGANET2+billr
+MEGANET2+jelliott
+MEGANET2+dbrady
+MEGANET2+joeg
+MEGANET2+balap
+</pre><p>
+ This shows that domain users have been listed correctly.
+</p><pre class="screen">
+<code class="prompt">root# </code> wbinfo -g
+MEGANET2+Domain Admins
+MEGANET2+Domain Users
+MEGANET2+Domain Guests
+MEGANET2+Accounts
+MEGANET2+Finances
+MEGANET2+PIOps
+</pre><p>
+ This shows that domain groups have been correctly obtained also.
+ </p></li><li><p>
+ <a class="indexterm" name="id2560128"></a>
+ <a class="indexterm" name="id2560134"></a>
+ <a class="indexterm" name="id2560141"></a>
+ The next step verifies that NSS is able to obtain this information
+ correctly from <span><strong class="command">winbind</strong></span> also.
+</p><pre class="screen">
+<code class="prompt">root# </code> 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
+</pre><p>
+ The user account information has been correctly obtained. This information has
+ been merged with the winbind template information configured in the <code class="filename">smb.conf</code> file.
+</p><pre class="screen">
+<code class="prompt">root# </code># 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:
+</pre><p>
+ </p></li><li><p>
+ The Samba member server of a Windows NT4 domain is ready for use.
+ </p></li></ol></div><div class="example"><a name="ch0-NT4DSDM"></a><p class="title"><b>Example 7.5. Samba Domain Member Server Using Winbind <code class="filename">smb.conf</code> File for NT4 Domain</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td># Global parameters</td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[global]</code></em></td></tr><tr><td><a class="indexterm" name="id2560267"></a><em class="parameter"><code>unix charset = LOCALE</code></em></td></tr><tr><td><a class="indexterm" name="id2560280"></a><em class="parameter"><code>workgroup = MEGANET2</code></em></td></tr><tr><td><a class="indexterm" name="id2560292"></a><em class="parameter"><code>security = DOMAIN</code></em></td></tr><tr><td><a class="indexterm" name="id2560305"></a><em class="parameter"><code>username map = /etc/samba/smbusers</code></em></td></tr><tr><td><a class="indexterm" name="id2560318"></a><em class="parameter"><code>log level = 1</code></em></td></tr><tr><td><a class="indexterm" name="id2560331"></a><em class="parameter"><code>syslog = 0</code></em></td></tr><tr><td><a class="indexterm" name="id2560343"></a><em class="parameter"><code>log file = /var/log/samba/%m</code></em></td></tr><tr><td><a class="indexterm" name="id2560356"></a><em class="parameter"><code>max log size = 0</code></em></td></tr><tr><td><a class="indexterm" name="id2560369"></a><em class="parameter"><code>smb ports = 139</code></em></td></tr><tr><td><a class="indexterm" name="id2560382"></a><em class="parameter"><code>name resolve order = wins bcast hosts</code></em></td></tr><tr><td><a class="indexterm" name="id2560395"></a><em class="parameter"><code>printcap name = CUPS</code></em></td></tr><tr><td><a class="indexterm" name="id2560408"></a><em class="parameter"><code>wins server = 192.168.2.1</code></em></td></tr><tr><td><a class="indexterm" name="id2560421"></a><em class="parameter"><code>idmap uid = 10000-20000</code></em></td></tr><tr><td><a class="indexterm" name="id2560433"></a><em class="parameter"><code>idmap gid = 10000-20000</code></em></td></tr><tr><td><a class="indexterm" name="id2560446"></a><em class="parameter"><code>template primary group = "Domain Users"</code></em></td></tr><tr><td><a class="indexterm" name="id2560460"></a><em class="parameter"><code>template shell = /bin/bash</code></em></td></tr><tr><td><a class="indexterm" name="id2560472"></a><em class="parameter"><code>winbind separator = +</code></em></td></tr><tr><td><a class="indexterm" name="id2560485"></a><em class="parameter"><code>printer admin = root</code></em></td></tr><tr><td><a class="indexterm" name="id2560498"></a><em class="parameter"><code>hosts allow = 192.168.2., 192.168.3., 127.</code></em></td></tr><tr><td><a class="indexterm" name="id2560511"></a><em class="parameter"><code>printing = cups</code></em></td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[homes]</code></em></td></tr><tr><td><a class="indexterm" name="id2560533"></a><em class="parameter"><code>comment = Home Directories</code></em></td></tr><tr><td><a class="indexterm" name="id2560546"></a><em class="parameter"><code>valid users = %S</code></em></td></tr><tr><td><a class="indexterm" name="id2560558"></a><em class="parameter"><code>read only = No</code></em></td></tr><tr><td><a class="indexterm" name="id2560571"></a><em class="parameter"><code>browseable = No</code></em></td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[printers]</code></em></td></tr><tr><td><a class="indexterm" name="id2560593"></a><em class="parameter"><code>comment = SMB Print Spool</code></em></td></tr><tr><td><a class="indexterm" name="id2560606"></a><em class="parameter"><code>path = /var/spool/samba</code></em></td></tr><tr><td><a class="indexterm" name="id2560618"></a><em class="parameter"><code>guest ok = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id2560631"></a><em class="parameter"><code>printable = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id2560644"></a><em class="parameter"><code>browseable = No</code></em></td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[print$]</code></em></td></tr><tr><td><a class="indexterm" name="id2560665"></a><em class="parameter"><code>comment = Printer Drivers</code></em></td></tr><tr><td><a class="indexterm" name="id2560678"></a><em class="parameter"><code>path = /var/lib/samba/drivers</code></em></td></tr><tr><td><a class="indexterm" name="id2560691"></a><em class="parameter"><code>admin users = root, Administrator</code></em></td></tr><tr><td><a class="indexterm" name="id2560704"></a><em class="parameter"><code>write list = root</code></em></td></tr></table></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="dcwonss"></a>NT4/Samba Domain with Samba Domain Member Server without NSS Support</h3></div></div></div><p>
+ No matter how many UNIX/Linux administrators there may be who believe that a UNIX operating
+ system that does not have NSS and PAM support to be outdated, the fact is there
+ are still many such systems in use today. Samba can be used without NSS support, but this
+ does limit it to the use of local user and group accounts only.
+ </p><p>
+ The following steps may be followed to implement Samba with support for local accounts.
+ In this configuration Samba is made a domain member server. All incoming connections
+ to the Samba server will cause the look-up of the incoming username. If the account
+ is found, it is used. If the account is not found, one will be automatically created
+ on the local machine so that it can then be used for all access controls.
+ </p><div class="procedure"><a name="id2560748"></a><p class="title"><b>Procedure 7.3. Configuration Using Local Accounts Only</b></p><ol type="1"><li><p>
+ Using your favorite text editor, create the <code class="filename">smb.conf</code> file so it has the contents
+ shown in <a href="unixclients.html#ch0-NT4DSCM" title="Example 7.6. Samba Domain Member Server Using Local Accounts smb.conf File for NT4 Domain">???</a>.
+ </p></li><li><p><a class="indexterm" name="id2560780"></a>
+ The system is ready to join the domain. Execute the following:
+</p><pre class="screen">
+net rpc join -U root%not24get
+Joined domain MEGANET2.
+</pre><p>
+ This indicates that the domain join succeed.
+ </p></li><li><p>
+ Be sure to run all three Samba daemons: <span><strong class="command">smbd</strong></span>, <span><strong class="command">nmbd</strong></span>, <span><strong class="command">winbindd</strong></span>.
+ </p></li><li><p>
+ The Samba member server of a Windows NT4 domain is ready for use.
+ </p></li></ol></div><div class="example"><a name="ch0-NT4DSCM"></a><p class="title"><b>Example 7.6. Samba Domain Member Server Using Local Accounts <code class="filename">smb.conf</code> File for NT4 Domain</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td># Global parameters</td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[global]</code></em></td></tr><tr><td><a class="indexterm" name="id2560869"></a><em class="parameter"><code>unix charset = LOCALE</code></em></td></tr><tr><td><a class="indexterm" name="id2560882"></a><em class="parameter"><code>workgroup = MEGANET3</code></em></td></tr><tr><td><a class="indexterm" name="id2560895"></a><em class="parameter"><code>netbios name = BSDBOX</code></em></td></tr><tr><td><a class="indexterm" name="id2560908"></a><em class="parameter"><code>security = DOMAIN</code></em></td></tr><tr><td><a class="indexterm" name="id2560921"></a><em class="parameter"><code>username map = /etc/samba/smbusers</code></em></td></tr><tr><td><a class="indexterm" name="id2560934"></a><em class="parameter"><code>log level = 1</code></em></td></tr><tr><td><a class="indexterm" name="id2560946"></a><em class="parameter"><code>syslog = 0</code></em></td></tr><tr><td><a class="indexterm" name="id2560959"></a><em class="parameter"><code>add user script = /usr/sbin/useradd -m '%u'</code></em></td></tr><tr><td><a class="indexterm" name="id2560972"></a><em class="parameter"><code>add machine script = /usr/sbin/useradd -M '%u'</code></em></td></tr><tr><td><a class="indexterm" name="id2560985"></a><em class="parameter"><code>add group script = /usr/sbin/groupadd '%g'</code></em></td></tr><tr><td><a class="indexterm" name="id2560999"></a><em class="parameter"><code>log file = /var/log/samba/%m</code></em></td></tr><tr><td><a class="indexterm" name="id2561012"></a><em class="parameter"><code>max log size = 0</code></em></td></tr><tr><td><a class="indexterm" name="id2561024"></a><em class="parameter"><code>smb ports = 139</code></em></td></tr><tr><td><a class="indexterm" name="id2561037"></a><em class="parameter"><code>name resolve order = wins bcast hosts</code></em></td></tr><tr><td><a class="indexterm" name="id2561050"></a><em class="parameter"><code>printcap name = CUPS</code></em></td></tr><tr><td><a class="indexterm" name="id2561063"></a><em class="parameter"><code>wins server = 192.168.2.1</code></em></td></tr><tr><td><a class="indexterm" name="id2561076"></a><em class="parameter"><code>printer admin = root</code></em></td></tr><tr><td><a class="indexterm" name="id2561089"></a><em class="parameter"><code>hosts allow = 192.168.2., 192.168.3., 127.</code></em></td></tr><tr><td><a class="indexterm" name="id2561102"></a><em class="parameter"><code>printing = cups</code></em></td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[homes]</code></em></td></tr><tr><td><a class="indexterm" name="id2561124"></a><em class="parameter"><code>comment = Home Directories</code></em></td></tr><tr><td><a class="indexterm" name="id2561136"></a><em class="parameter"><code>valid users = %S</code></em></td></tr><tr><td><a class="indexterm" name="id2561149"></a><em class="parameter"><code>read only = No</code></em></td></tr><tr><td><a class="indexterm" name="id2561162"></a><em class="parameter"><code>browseable = No</code></em></td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[printers]</code></em></td></tr><tr><td><a class="indexterm" name="id2561183"></a><em class="parameter"><code>comment = SMB Print Spool</code></em></td></tr><tr><td><a class="indexterm" name="id2561196"></a><em class="parameter"><code>path = /var/spool/samba</code></em></td></tr><tr><td><a class="indexterm" name="id2561209"></a><em class="parameter"><code>guest ok = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id2561222"></a><em class="parameter"><code>printable = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id2561234"></a><em class="parameter"><code>browseable = No</code></em></td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[print$]</code></em></td></tr><tr><td><a class="indexterm" name="id2561256"></a><em class="parameter"><code>comment = Printer Drivers</code></em></td></tr><tr><td><a class="indexterm" name="id2561269"></a><em class="parameter"><code>path = /var/lib/samba/drivers</code></em></td></tr><tr><td><a class="indexterm" name="id2561282"></a><em class="parameter"><code>admin users = root, Administrator</code></em></td></tr><tr><td><a class="indexterm" name="id2561294"></a><em class="parameter"><code>write list = root</code></em></td></tr></table></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="adssdm"></a>Active Directory Domain with Samba Domain Member Server</h3></div></div></div><p>
+ <a class="indexterm" name="id2561321"></a>
+ <a class="indexterm" name="id2561330"></a>
+ <a class="indexterm" name="id2561337"></a>
+ 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.
+ </p><p>
+ <a class="indexterm" name="id2561359"></a>
+ <a class="indexterm" name="id2561366"></a>
+ <a class="indexterm" name="id2561373"></a>
+ <a class="indexterm" name="id2561380"></a>
+ The diagram in <a href="unixclients.html#ch9-adsdc" title="Figure 7.3. Active Directory Domain: Samba Member Server">???</a> demonstrates how Samba-3 interfaces with
+ Microsoft Active Directory components. It should be noted that if Microsoft Windows Services
+ for UNIX (SFU) has been installed and correctly configured, it is possible to use client LDAP
+ for identity resolution just as can be done with Samba-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.
+ </p><p>
+ 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 (<span><strong class="command">smbd</strong></span>) has the necessary features.
+ </p><p>
+ The hypothetical domain you are using in this example assumes that the Abmas London office
+ decided to take its own lead (some would say this is a typical behavior in a global
+ corporate world; besides, a little divergence and conflict makes for an interesting life).
+ The Windows Server 2003 ADS domain is called <code class="constant">london.abmas.biz</code> and the
+ name of the server is <code class="constant">W2K3S</code>. In ADS realm terms, the domain controller
+ is known as <code class="constant">w2k3s.london.abmas.biz</code>. In NetBIOS nomenclature, the
+ domain name is <code class="constant">LONDON</code> and the server name is <code class="constant">W2K3S</code>.
+ </p><div class="figure"><a name="ch9-adsdc"></a><p class="title"><b>Figure 7.3. Active Directory Domain: Samba Member Server</b></p><div class="mediaobject"><img src="images/chap9-ADSDC.png" width="324" alt="Active Directory Domain: Samba Member Server"></div></div><div class="procedure"><a name="id2561493"></a><p class="title"><b>Procedure 7.4. Joining a Samba Server as an ADS Domain Member</b></p><ol type="1"><li><p>
+ <a class="indexterm" name="id2561505"></a>
+ 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:
+</p><pre class="screen">
+<code class="prompt">root# </code> cd /usr/sbin
+<code class="prompt">root# </code> 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
+</pre><p>
+ This output was obtained on a SUSE Linux system and shows the output for
+ Samba that has been compiled and linked with the Heimdal Kerberos libraries.
+ The following is a typical output that will be found on a Red Hat Linux system that
+ has been linked with the MIT Kerberos libraries:
+</p><pre class="screen">
+<code class="prompt">root# </code> cd /usr/sbin
+<code class="prompt">root# </code> 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
+</pre><p>
+ You can validate that Samba has been compiled and linked with LDAP support
+ by executing:
+</p><pre class="screen">
+<code class="prompt">root# </code> 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
+</pre><p>
+ This does look promising; <span><strong class="command">smbd</strong></span> has been built with Kerberos and LDAP
+ support. You are relieved to know that it is safe to progress.
+ </p></li><li><p>
+ <a class="indexterm" name="id2561604"></a>
+ <a class="indexterm" name="id2561613"></a>
+ <a class="indexterm" name="id2561620"></a>
+ <a class="indexterm" name="id2561627"></a>
+ <a class="indexterm" name="id2561636"></a>
+ <a class="indexterm" name="id2561646"></a>
+ <a class="indexterm" name="id2561652"></a>
+ <a class="indexterm" name="id2561659"></a>
+ <a class="indexterm" name="id2561666"></a>
+ 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):
+</p><pre class="screen">
+<code class="prompt">root# </code> rpm -q krb5
+</pre><p>
+ Or on SUSE Linux, execute:
+</p><pre class="screen">
+<code class="prompt">root# </code> rpm -q heimdal
+</pre><p>
+ 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 <a href="ftp://ftp.sernet.de" target="_top">Sernet</a> in
+ Germany.
+ </p><p>
+ 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 NSS.
+ </p></li><li><p>
+ Using you favorite editor, configure the <code class="filename">smb.conf</code> file that is located in the
+ <code class="filename">/etc/samba</code> directory so that it has the contents shown
+ in <a href="unixclients.html#ch9-adssdm" title="Example 7.7. Samba Domain Member smb.conf File for Active Directory Membership">???</a>.
+ </p></li><li><p>
+ Edit or create the NSS control file so it has the contents shown in <a href="unixclients.html#ch9-sdmnss" title="Example 7.4. NSS using LDAP for Identity Resolution File: /etc/nsswitch.conf">???</a>.
+ </p></li><li><p>
+ <a class="indexterm" name="id2561768"></a>
+ Delete the file <code class="filename">/etc/samba/secrets.tdb</code> if it exists. Of course, you
+ do keep a backup, don't you?
+ </p></li><li><p>
+ 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):
+</p><pre class="screen">
+<code class="prompt">root# </code> rm /var/lib/samba/*tdb
+</pre><p>
+ </p></li><li><p>
+ <a class="indexterm" name="id2561812"></a>
+ Validate your <code class="filename">smb.conf</code> file using <span><strong class="command">testparm</strong></span> (as you have
+ done previously). Correct all errors reported before proceeding. The command you
+ execute is:
+</p><pre class="screen">
+<code class="prompt">root# </code> testparm -s | less
+</pre><p>
+ Now that you are satisfied that your Samba server is ready to join the Windows
+ ADS domain, let's move on.
+ </p></li><li><p>
+ <a class="indexterm" name="id2561853"></a>
+ <a class="indexterm" name="id2561864"></a>
+ This is a good time to double-check everything and then execute the following
+ command when everything you have done has checked out okay:
+</p><pre class="screen">
+<code class="prompt">root# </code> net ads join -UAdministrator%not24get
+Using short domain name -- LONDON
+Joined 'FRAN' to realm 'LONDON.ABMAS.BIZ'
+</pre><p>
+ You have successfully made your Samba-3 server a member of the ADS domain
+ using Kerberos protocols.
+ </p><p>
+ <a class="indexterm" name="id2561892"></a>
+ <a class="indexterm" name="id2561899"></a>
+ In the event that you receive no output messages, a silent return means that the
+ domain join failed. You should use <span><strong class="command">ethereal</strong></span> to identify what
+ may be failing. Common causes of a failed join include:
+
+ </p><div class="itemizedlist"><ul type="disc"><li><p>
+ <a class="indexterm" name="id2561920"></a>
+ Defective or misconfigured DNS name resolution.
+ </p></li><li><p>
+ <a class="indexterm" name="id2561935"></a>
+ 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.
+ </p></li><li><p>
+ Incorrectly configured <code class="filename">smb.conf</code> file settings.
+ </p></li><li><p>
+ 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.
+ </p></li></ul></div><p>
+
+ <a class="indexterm" name="id2561966"></a>
+ <a class="indexterm" name="id2561977"></a>
+ <a class="indexterm" name="id2561984"></a>
+ In any case, never execute the <span><strong class="command">net rpc join</strong></span> 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.
+ </p></li><li><p>
+ <a class="indexterm" name="id2562009"></a>
+ <a class="indexterm" name="id2562016"></a>
+ If the <span><strong class="command">tdbdump</strong></span> is installed on your system (not essential),
+ you can look inside the <code class="filename">/etc/samba/secrets.tdb</code> file. If
+ you wish to do this, execute:
+</p><pre class="screen">
+<code class="prompt">root# </code> 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?"
+}
+</pre><p>
+ This is given to demonstrate to the skeptics that this process truly does work.
+ </p></li><li><p>
+ It is now time to start Samba in the usual way (as has been done many time before
+ in this book).
+ </p></li><li><p>
+ <a class="indexterm" name="id2562073"></a>
+ 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:
+</p><pre class="screen">
+<code class="prompt">root# </code> wbinfo -u
+LONDON+Administrator
+LONDON+Guest
+LONDON+SUPPORT_388945a0
+LONDON+krbtgt
+LONDON+jht
+</pre><p>
+ Good, the list of users was obtained. Now do likewise for group accounts:
+</p><pre class="screen">
+<code class="prompt">root# </code> 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
+</pre><p>
+ Excellent. That worked also, as expected.
+ </p></li><li><p><a class="indexterm" name="id2562119"></a>
+ Now repeat this via NSS to validate that full identity resolution is
+ functional as required. Execute:
+</p><pre class="screen">
+<code class="prompt">root# </code> 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
+</pre><p>
+ Okay, ADS user accounts are being resolved. Now you try group resolution:
+</p><pre class="screen">
+<code class="prompt">root# </code> 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:
+</pre><p>
+ This is very pleasing. Everything works as expected.
+ </p></li><li><p>
+ <a class="indexterm" name="id2562176"></a>
+ <a class="indexterm" name="id2562188"></a>
+ <a class="indexterm" name="id2562197"></a>
+ You may now perform final verification that communications between Samba-3 winbind and
+ the Active Directory server is using Kerberos protocols. Execute the following:
+</p><pre class="screen">
+<code class="prompt">root# </code> 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
+</pre><p>
+ 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.
+ </p></li><li><p>
+ <a class="indexterm" name="id2562233"></a>
+ There is one more action you elect to take, just because you are paranoid and disbelieving,
+ so you execute the following command:
+</p><pre class="programlisting">
+<code class="prompt">root# </code> net ads status -UAdministrator%not24get
+objectClass: top
+objectClass: person
+objectClass: organizationalPerson
+objectClass: user
+objectClass: computer
+cn: fran
+distinguishedName: CN=fran,CN=Computers,DC=london,DC=abmas,DC=biz
+instanceType: 4
+whenCreated: 20040103092006.0Z
+whenChanged: 20040103092006.0Z
+uSNCreated: 28713
+uSNChanged: 28717
+name: fran
+objectGUID: 58f89519-c467-49b9-acb0-f099d73696e
+userAccountControl: 69632
+badPwdCount: 0
+codePage: 0
+countryCode: 0
+badPasswordTime: 0
+lastLogoff: 0
+lastLogon: 127175965783327936
+localPolicyFlags: 0
+pwdLastSet: 127175952062598496
+primaryGroupID: 515
+objectSid: S-1-5-21-4052121579-2079768045-1474639452-1109
+accountExpires: 9223372036854775807
+logonCount: 13
+sAMAccountName: fran$
+sAMAccountType: 805306369
+operatingSystem: Samba
+operatingSystemVersion: 3.0.20-SUSE
+dNSHostName: fran
+userPrincipalName: HOST/fran@LONDON.ABMAS.BIZ
+servicePrincipalName: CIFS/fran.london.abmas.biz
+servicePrincipalName: CIFS/fran
+servicePrincipalName: HOST/fran.london.abmas.biz
+servicePrincipalName: HOST/fran
+objectCategory: CN=Computer,CN=Schema,CN=Configuration,
+ DC=london,DC=abmas,DC=biz
+isCriticalSystemObject: FALSE
+-------------- Security Descriptor (revision: 1, type: 0x8c14)
+owner SID: S-1-5-21-4052121579-2079768045-1474639452-512
+group SID: S-1-5-21-4052121579-2079768045-1474639452-513
+------- (system) ACL (revision: 4, size: 120, number of ACEs: 2)
+------- ACE (type: 0x07, flags: 0x5a, size: 0x38,
+ mask: 0x20, object flags: 0x3)
+access SID: S-1-1-0
+access type: AUDIT OBJECT
+Permissions:
+ [Write All Properties]
+------- ACE (type: 0x07, flags: 0x5a, size: 0x38,
+ mask: 0x20, object flags: 0x3)
+access SID: S-1-1-0
+access type: AUDIT OBJECT
+Permissions:
+ [Write All Properties]
+------- (user) ACL (revision: 4, size: 1944, number of ACEs: 40)
+------- ACE (type: 0x00, flags: 0x00, size: 0x24, mask: 0xf01ff)
+access SID: S-1-5-21-4052121579-2079768045-1474639452-512
+access type: ALLOWED
+Permissions: [Full Control]
+------- ACE (type: 0x00, flags: 0x00, size: 0x18, mask: 0xf01ff)
+access SID: S-1-5-32-548
+...
+------- ACE (type: 0x05, flags: 0x12, size: 0x38,
+ mask: 0x10, object flags: 0x3)
+access SID: S-1-5-9
+access type: ALLOWED OBJECT
+Permissions:
+ [Read All Properties]
+-------------- End Of Security Descriptor
+</pre><p>
+ And now you have conclusive proof that your Samba-3 ADS domain member server
+ called <code class="constant">FRAN</code> is able to communicate fully with the ADS
+ domain controllers.
+ </p></li></ol></div><p>
+ Your Samba-3 ADS domain member server is ready for use. During training sessions,
+ you may be asked what is inside the <code class="filename">winbindd_cache.tdb and winbindd_idmap.tdb</code>
+ files. Since curiosity just took hold of you, execute the following:
+</p><pre class="programlisting">
+<code class="prompt">root# </code> 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"
+}
+...
+
+<code class="prompt">root# </code> 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"
+}
+....
+</pre><p>
+ Now all is revealed. Your curiosity, as well as that of your team, has been put at ease.
+ May this server serve well all who happen upon it.
+ </p><div class="example"><a name="ch9-adssdm"></a><p class="title"><b>Example 7.7. Samba Domain Member <code class="filename">smb.conf</code> File for Active Directory Membership</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td># Global parameters</td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[global]</code></em></td></tr><tr><td><a class="indexterm" name="id2562414"></a><em class="parameter"><code>unix charset = LOCALE</code></em></td></tr><tr><td><a class="indexterm" name="id2562427"></a><em class="parameter"><code>workgroup = LONDON</code></em></td></tr><tr><td><a class="indexterm" name="id2562440"></a><em class="parameter"><code>realm = LONDON.ABMAS.BIZ</code></em></td></tr><tr><td><a class="indexterm" name="id2562453"></a><em class="parameter"><code>server string = Samba 3.0.20</code></em></td></tr><tr><td><a class="indexterm" name="id2562466"></a><em class="parameter"><code>security = ADS</code></em></td></tr><tr><td><a class="indexterm" name="id2562479"></a><em class="parameter"><code>username map = /etc/samba/smbusers</code></em></td></tr><tr><td><a class="indexterm" name="id2562492"></a><em class="parameter"><code>log level = 1</code></em></td></tr><tr><td><a class="indexterm" name="id2562504"></a><em class="parameter"><code>syslog = 0</code></em></td></tr><tr><td><a class="indexterm" name="id2562517"></a><em class="parameter"><code>log file = /var/log/samba/%m</code></em></td></tr><tr><td><a class="indexterm" name="id2562530"></a><em class="parameter"><code>max log size = 50</code></em></td></tr><tr><td><a class="indexterm" name="id2562543"></a><em class="parameter"><code>printcap name = CUPS</code></em></td></tr><tr><td><a class="indexterm" name="id2562556"></a><em class="parameter"><code>ldap ssl = no</code></em></td></tr><tr><td><a class="indexterm" name="id2562568"></a><em class="parameter"><code>idmap uid = 10000-20000</code></em></td></tr><tr><td><a class="indexterm" name="id2562581"></a><em class="parameter"><code>idmap gid = 10000-20000</code></em></td></tr><tr><td><a class="indexterm" name="id2562594"></a><em class="parameter"><code>template primary group = "Domain Users"</code></em></td></tr><tr><td><a class="indexterm" name="id2562607"></a><em class="parameter"><code>template shell = /bin/bash</code></em></td></tr><tr><td><a class="indexterm" name="id2562620"></a><em class="parameter"><code>winbind separator = +</code></em></td></tr><tr><td><a class="indexterm" name="id2562633"></a><em class="parameter"><code>printing = cups</code></em></td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[homes]</code></em></td></tr><tr><td><a class="indexterm" name="id2562655"></a><em class="parameter"><code>comment = Home Directories</code></em></td></tr><tr><td><a class="indexterm" name="id2562667"></a><em class="parameter"><code>valid users = %S</code></em></td></tr><tr><td><a class="indexterm" name="id2562680"></a><em class="parameter"><code>read only = No</code></em></td></tr><tr><td><a class="indexterm" name="id2562693"></a><em class="parameter"><code>browseable = No</code></em></td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[printers]</code></em></td></tr><tr><td><a class="indexterm" name="id2562714"></a><em class="parameter"><code>comment = SMB Print Spool</code></em></td></tr><tr><td><a class="indexterm" name="id2562727"></a><em class="parameter"><code>path = /var/spool/samba</code></em></td></tr><tr><td><a class="indexterm" name="id2562740"></a><em class="parameter"><code>guest ok = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id2562753"></a><em class="parameter"><code>printable = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id2562765"></a><em class="parameter"><code>browseable = No</code></em></td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[print$]</code></em></td></tr><tr><td><a class="indexterm" name="id2562787"></a><em class="parameter"><code>comment = Printer Drivers</code></em></td></tr><tr><td><a class="indexterm" name="id2562800"></a><em class="parameter"><code>path = /var/lib/samba/drivers</code></em></td></tr><tr><td><a class="indexterm" name="id2562813"></a><em class="parameter"><code>admin users = root, Administrator</code></em></td></tr><tr><td><a class="indexterm" name="id2562826"></a><em class="parameter"><code>write list = root</code></em></td></tr></table></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2562839"></a>IDMAP_RID with Winbind</h4></div></div></div><p>
+ <a class="indexterm" name="id2562847"></a>
+ <a class="indexterm" name="id2562854"></a>
+ <a class="indexterm" name="id2562861"></a>
+ <a class="indexterm" name="id2562867"></a>
+ The <span><strong class="command">idmap_rid</strong></span> facility is a new tool that, unlike native winbind, creates a
+ predictable mapping of MS Windows SIDs to UNIX UIDs and GIDs. The key benefit of this method
+ of implementing the Samba IDMAP facility is that it eliminates the need to store the IDMAP data
+ in a central place. The downside is that it can be used only within a single ADS domain and
+ is not compatible with trusted domain implementations.
+ </p><p>
+ <a class="indexterm" name="id2562891"></a>
+ <a class="indexterm" name="id2562897"></a>
+ <a class="indexterm" name="id2562904"></a>
+ <a class="indexterm" name="id2562911"></a>
+ This alternate method of SID to UID/GID mapping can be achieved with the idmap_rid
+ plug-in. This plug-in uses the RID of the user SID to derive the UID and GID by adding the
+ RID to a base value specified. This utility requires that the parameter
+ “<span class="quote">allow trusted domains = No</span>” must be specified, as it is not compatible
+ with multiple domain environments. The <em class="parameter"><code>idmap uid</code></em> and
+ <em class="parameter"><code>idmap gid</code></em> ranges must be specified.
+ </p><p>
+ <a class="indexterm" name="id2562944"></a>
+ <a class="indexterm" name="id2562951"></a>
+ The idmap_rid facility can be used both for NT4/Samba-style domains as well as with Active Directory.
+ To use this with an NT4 domain, the <em class="parameter"><code>realm</code></em> is not used. Additionally the
+ method used to join the domain uses the <code class="constant">net rpc join</code> process.
+ </p><p>
+ An example <code class="filename">smb.conf</code> file for an ADS domain environment is shown in <a href="unixclients.html#sbe-idmapridex" title="Example 7.8. Example smb.conf File Using idmap_rid">???</a>.
+ </p><div class="example"><a name="sbe-idmapridex"></a><p class="title"><b>Example 7.8. Example <code class="filename">smb.conf</code> File Using <code class="constant">idmap_rid</code></b></p><table class="simplelist" border="0" summary="Simple list"><tr><td># Global parameters</td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[global]</code></em></td></tr><tr><td><a class="indexterm" name="id2563025"></a><em class="parameter"><code>workgroup = KPAK</code></em></td></tr><tr><td><a class="indexterm" name="id2563038"></a><em class="parameter"><code>netbios name = BIGJOE</code></em></td></tr><tr><td><a class="indexterm" name="id2563051"></a><em class="parameter"><code>realm = CORP.KPAK.COM</code></em></td></tr><tr><td><a class="indexterm" name="id2563063"></a><em class="parameter"><code>server string = Office Server</code></em></td></tr><tr><td><a class="indexterm" name="id2563076"></a><em class="parameter"><code>security = ADS</code></em></td></tr><tr><td><a class="indexterm" name="id2563089"></a><em class="parameter"><code>allow trusted domains = No</code></em></td></tr><tr><td><a class="indexterm" name="id2563102"></a><em class="parameter"><code>idmap backend = idmap_rid:KPAK=500-100000000</code></em></td></tr><tr><td><a class="indexterm" name="id2563116"></a><em class="parameter"><code>idmap uid = 500-100000000</code></em></td></tr><tr><td><a class="indexterm" name="id2563128"></a><em class="parameter"><code>idmap gid = 500-100000000</code></em></td></tr><tr><td><a class="indexterm" name="id2563141"></a><em class="parameter"><code>template shell = /bin/bash</code></em></td></tr><tr><td><a class="indexterm" name="id2563154"></a><em class="parameter"><code>winbind use default domain = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id2563167"></a><em class="parameter"><code>winbind enum users = No</code></em></td></tr><tr><td><a class="indexterm" name="id2563180"></a><em class="parameter"><code>winbind enum groups = No</code></em></td></tr><tr><td><a class="indexterm" name="id2563193"></a><em class="parameter"><code>winbind nested groups = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id2563206"></a><em class="parameter"><code>printer admin = "KPAK\Domain Admins"</code></em></td></tr></table></div><p>
+ <a class="indexterm" name="id2563223"></a>
+ <a class="indexterm" name="id2563230"></a>
+ <a class="indexterm" name="id2563236"></a>
+ <a class="indexterm" name="id2563243"></a>
+ In a large domain with many users, it is imperative to disable enumeration of users and groups.
+ For example, at a site that has 22,000 users in Active Directory the winbind-based user and
+ group resolution is unavailable for nearly 12 minutes following first start-up of
+ <span><strong class="command">winbind</strong></span>. Disabling of such enumeration results in instantaneous response.
+ The disabling of user and group enumeration means that it will not be possible to list users
+ or groups using the <span><strong class="command">getent passwd</strong></span> and <span><strong class="command">getent group</strong></span>
+ commands. It will be possible to perform the lookup for individual users, as shown in the procedure
+ below.
+ </p><p>
+ <a class="indexterm" name="id2563282"></a>
+ <a class="indexterm" name="id2563289"></a>
+ The use of this tool requires configuration of NSS as per the native use of winbind. Edit the
+ <code class="filename">/etc/nsswitch.conf</code> so it has the following parameters:
+</p><pre class="screen">
+...
+passwd: files winbind
+shadow: files winbind
+group: files winbind
+...
+hosts: files wins
+...
+</pre><p>
+ </p><p>
+ The following procedure can be used to utilize the idmap_rid facility:
+ </p><div class="procedure"><ol type="1"><li><p>
+ Create or install and <code class="filename">smb.conf</code> file with the above configuration.
+ </p></li><li><p>
+ Edit the <code class="filename">/etc/nsswitch.conf</code> file as shown above.
+ </p></li><li><p>
+ Execute:
+</p><pre class="screen">
+<code class="prompt">root# </code> net ads join -UAdministrator%password
+Using short domain name -- KPAK
+Joined 'BIGJOE' to realm 'CORP.KPAK.COM'
+</pre><p>
+ </p><p>
+ <a class="indexterm" name="id2563370"></a>
+ An invalid or failed join can be detected by executing:
+</p><pre class="screen">
+<code class="prompt">root# </code> net ads testjoin
+BIGJOE$@'s password:
+[2004/11/05 16:53:03, 0] utils/net_ads.c:ads_startup(186)
+ ads_connect: No results returned
+Join to domain is not valid
+</pre><p>
+ The specific error message may differ from the above because it depends on the type of failure that
+ may have occurred. Increase the <em class="parameter"><code>log level</code></em> to 10, repeat the above test,
+ and then examine the log files produced to identify the nature of the failure.
+ </p></li><li><p>
+ Start the <span><strong class="command">nmbd</strong></span>, <span><strong class="command">winbind,</strong></span> and <span><strong class="command">smbd</strong></span> daemons in the order shown.
+ </p></li><li><p>
+ Validate the operation of this configuration by executing:
+ <a class="indexterm" name="id2563437"></a>
+</p><pre class="screen">
+<code class="prompt">root# </code> getent passwd administrator
+administrator:x:1000:1013:Administrator:/home/BE/administrator:/bin/bash
+</pre><p>
+ </p></li></ol></div></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2563459"></a>IDMAP Storage in LDAP using Winbind</h4></div></div></div><p>
+ <a class="indexterm" name="id2563467"></a>
+ <a class="indexterm" name="id2563474"></a>
+ The storage of IDMAP information in LDAP can be used with both NT4/Samba-3-style domains as well as
+ with ADS domains. OpenLDAP is a commonly used LDAP server for this purpose, although any standards-compliant
+ LDAP server can be used. It is therefore possible to deploy this IDMAP configuration using
+ the Sun iPlanet LDAP server, Novell eDirectory, Microsoft ADS plus ADAM, and so on.
+ </p><p>
+ The example in <a href="unixclients.html#sbeunxa" title="Example 7.9. Typical ADS Style Domain smb.conf File">???</a> is for an ADS-style domain.
+ </p><div class="example"><a name="sbeunxa"></a><p class="title"><b>Example 7.9. Typical ADS Style Domain <code class="filename">smb.conf</code> File</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td># Global parameters</td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[global]</code></em></td></tr><tr><td><a class="indexterm" name="id2563534"></a><em class="parameter"><code>workgroup = SNOWSHOW</code></em></td></tr><tr><td><a class="indexterm" name="id2563546"></a><em class="parameter"><code>netbios name = GOODELF</code></em></td></tr><tr><td><a class="indexterm" name="id2563559"></a><em class="parameter"><code>realm = SNOWSHOW.COM</code></em></td></tr><tr><td><a class="indexterm" name="id2563572"></a><em class="parameter"><code>server string = Samba Server</code></em></td></tr><tr><td><a class="indexterm" name="id2563585"></a><em class="parameter"><code>security = ADS</code></em></td></tr><tr><td><a class="indexterm" name="id2563598"></a><em class="parameter"><code>log level = 1 ads:10 auth:10 sam:10 rpc:10</code></em></td></tr><tr><td><a class="indexterm" name="id2563611"></a><em class="parameter"><code>ldap admin dn = cn=Manager,dc=SNOWSHOW,dc=COM</code></em></td></tr><tr><td><a class="indexterm" name="id2563624"></a><em class="parameter"><code>ldap idmap suffix = ou=Idmap</code></em></td></tr><tr><td><a class="indexterm" name="id2563637"></a><em class="parameter"><code>ldap suffix = dc=SNOWSHOW,dc=COM</code></em></td></tr><tr><td><a class="indexterm" name="id2563650"></a><em class="parameter"><code>idmap backend = ldap:ldap://ldap.snowshow.com</code></em></td></tr><tr><td><a class="indexterm" name="id2563664"></a><em class="parameter"><code>idmap uid = 150000-550000</code></em></td></tr><tr><td><a class="indexterm" name="id2563676"></a><em class="parameter"><code>idmap gid = 150000-550000</code></em></td></tr><tr><td><a class="indexterm" name="id2563689"></a><em class="parameter"><code>template shell = /bin/bash</code></em></td></tr><tr><td><a class="indexterm" name="id2563702"></a><em class="parameter"><code>winbind use default domain = Yes</code></em></td></tr></table></div><p>
+ <a class="indexterm" name="id2563718"></a>
+ In the case of an NT4 or Samba-3-style domain the <em class="parameter"><code>realm</code></em> is not used, and the
+ command used to join the domain is <span><strong class="command">net rpc join</strong></span>. The above example also demonstrates
+ advanced error reporting techniques that are documented in the chapter called "Reporting Bugs" in
+ “<span class="quote">The Official Samba-3 HOWTO and Reference Guide, Second Edition</span>” (TOSHARG2).
+ </p><p>
+ <a class="indexterm" name="id2563750"></a>
+ <a class="indexterm" name="id2563757"></a>
+ <a class="indexterm" name="id2563764"></a>
+ Where MIT kerberos is installed (version 1.3.4 or later), edit the <code class="filename">/etc/krb5.conf</code>
+ file so it has the following contents:
+</p><pre class="screen">
+[logging]
+ default = FILE:/var/log/krb5libs.log
+ kdc = FILE:/var/log/krb5kdc.log
+ admin_server = FILE:/var/log/kadmind.log
+
+[libdefaults]
+ default_realm = SNOWSHOW.COM
+ dns_lookup_realm = false
+ dns_lookup_kdc = true
+
+[appdefaults]
+ pam = {
+ debug = false
+ ticket_lifetime = 36000
+ renew_lifetime = 36000
+ forwardable = true
+ krb4_convert = false
+ }
+</pre><p>
+ </p><p>
+ Where Heimdal kerberos is installed, edit the <code class="filename">/etc/krb5.conf</code>
+ file so it is either empty (i.e., no contents) or it has the following contents:
+</p><pre class="screen">
+[libdefaults]
+ default_realm = SNOWSHOW.COM
+ clockskew = 300
+
+[realms]
+ SNOWSHOW.COM = {
+ kdc = ADSDC.SHOWSHOW.COM
+ }
+
+[domain_realm]
+ .snowshow.com = SNOWSHOW.COM
+</pre><p>
+ </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+ Samba cannot use the Heimdal libraries if there is no <code class="filename">/etc/krb5.conf</code> file.
+ So long as there is an empty file, the Heimdal kerberos libraries will be usable. There is no
+ need to specify any settings because Samba, using the Heimdal libraries, can figure this out automatically.
+ </p></div><p>
+ Edit the NSS control file <code class="filename">/etc/nsswitch.conf</code> so it has the following entries:
+</p><pre class="screen">
+...
+passwd: files ldap
+shadow: files ldap
+group: files ldap
+...
+hosts: files wins
+...
+</pre><p>
+ </p><p>
+ <a class="indexterm" name="id2563848"></a>
+ <a class="indexterm" name="id2563855"></a>
+ You will need the <a href="http://www.padl.com" target="_top">PADL</a> <span><strong class="command">nss_ldap</strong></span>
+ tool set for this solution. Configure the <code class="filename">/etc/ldap.conf</code> file so it has
+ the information needed. The following is an example of a working file:
+</p><pre class="screen">
+host 192.168.2.1
+base dc=snowshow,dc=com
+binddn cn=Manager,dc=snowshow,dc=com
+bindpw not24get
+
+pam_password exop
+
+nss_base_passwd ou=People,dc=snowshow,dc=com?one
+nss_base_shadow ou=People,dc=snowshow,dc=com?one
+nss_base_group ou=Groups,dc=snowshow,dc=com?one
+ssl no
+</pre><p>
+ </p><p>
+ The following procedure may be followed to affect a working configuration:
+ </p><div class="procedure"><ol type="1"><li><p>
+ Configure the <code class="filename">smb.conf</code> file as shown above.
+ </p></li><li><p>
+ Create the <code class="filename">/etc/krb5.conf</code> file following the indications above.
+ </p></li><li><p>
+ Configure the <code class="filename">/etc/nsswitch.conf</code> file as shown above.
+ </p></li><li><p>
+ Download, build, and install the PADL nss_ldap tool set. Configure the
+ <code class="filename">/etc/ldap.conf</code> file as shown above.
+ </p></li><li><p>
+ Configure an LDAP server and initialize the directory with the top-level entries needed by IDMAP
+ as shown in the following LDIF file:
+</p><pre class="screen">
+dn: dc=snowshow,dc=com
+objectClass: dcObject
+objectClass: organization
+dc: snowshow
+o: The Greatest Snow Show in Singapore.
+description: Posix and Samba LDAP Identity Database
+
+dn: cn=Manager,dc=snowshow,dc=com
+objectClass: organizationalRole
+cn: Manager
+description: Directory Manager
+
+dn: ou=Idmap,dc=snowshow,dc=com
+objectClass: organizationalUnit
+ou: idmap
+</pre><p>
+ </p></li><li><p>
+ Execute the command to join the Samba domain member server to the ADS domain as shown here:
+</p><pre class="screen">
+<code class="prompt">root# </code> net ads testjoin
+Using short domain name -- SNOWSHOW
+Joined 'GOODELF' to realm 'SNOWSHOW.COM'
+</pre><p>
+ </p></li><li><p>
+ Store the LDAP server access password in the Samba <code class="filename">secrets.tdb</code> file as follows:
+</p><pre class="screen">
+<code class="prompt">root# </code> smbpasswd -w not24get
+</pre><p>
+ </p></li><li><p>
+ Start the <span><strong class="command">nmbd</strong></span>, <span><strong class="command">winbind</strong></span>, and <span><strong class="command">smbd</strong></span> daemons in the order shown.
+ </p></li></ol></div><p>
+ <a class="indexterm" name="id2564055"></a>
+ Follow the diagnostic procedures shown earlier in this chapter to identify success or failure of the join.
+ In many cases a failure is indicated by a silent return to the command prompt with no indication of the
+ reason for failure.
+ </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2564068"></a>IDMAP and NSS Using LDAP from ADS with RFC2307bis Schema Extension</h4></div></div></div><p>
+ <a class="indexterm" name="id2564077"></a>
+ <a class="indexterm" name="id2564084"></a>
+ The use of this method is messy. The information provided in this section is for guidance only
+ and is very definitely not complete. This method does work; it is used in a number of large sites
+ and has an acceptable level of performance.
+ </p><p>
+ An example <code class="filename">smb.conf</code> file is shown in <a href="unixclients.html#sbewinbindex" title="Example 7.10. ADS Membership Using RFC2307bis Identity Resolution smb.conf File">???</a>.
+ </p><div class="example"><a name="sbewinbindex"></a><p class="title"><b>Example 7.10. ADS Membership Using RFC2307bis Identity Resolution <code class="filename">smb.conf</code> File</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td># Global parameters</td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[global]</code></em></td></tr><tr><td><a class="indexterm" name="id2564147"></a><em class="parameter"><code>workgroup = BUBBAH</code></em></td></tr><tr><td><a class="indexterm" name="id2564159"></a><em class="parameter"><code>netbios name = MADMAX</code></em></td></tr><tr><td><a class="indexterm" name="id2564172"></a><em class="parameter"><code>realm = BUBBAH.COM</code></em></td></tr><tr><td><a class="indexterm" name="id2564185"></a><em class="parameter"><code>server string = Samba Server</code></em></td></tr><tr><td><a class="indexterm" name="id2564198"></a><em class="parameter"><code>security = ADS</code></em></td></tr><tr><td><a class="indexterm" name="id2564211"></a><em class="parameter"><code>idmap uid = 150000-550000</code></em></td></tr><tr><td><a class="indexterm" name="id2564224"></a><em class="parameter"><code>idmap gid = 150000-550000</code></em></td></tr><tr><td><a class="indexterm" name="id2564236"></a><em class="parameter"><code>template shell = /bin/bash</code></em></td></tr><tr><td><a class="indexterm" name="id2564249"></a><em class="parameter"><code>winbind use default domain = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id2564262"></a><em class="parameter"><code>winbind trusted domains only = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id2564276"></a><em class="parameter"><code>winbind nested groups = Yes</code></em></td></tr></table></div><p>
+ <a class="indexterm" name="id2564292"></a>
+ The DMS must be joined to the domain using the usual procedure. Additionally, it is necessary
+ to build and install the PADL nss_ldap tool set. Be sure to build this tool set with the
+ following:
+</p><pre class="screen">
+./configure --enable-rfc2307bis --enable-schema-mapping
+make install
+</pre><p>
+ </p><p>
+ <a class="indexterm" name="id2564313"></a>
+ The following <code class="filename">/etc/nsswitch.conf</code> file contents are required:
+</p><pre class="screen">
+...
+passwd: files ldap
+shadow: files ldap
+group: files ldap
+...
+hosts: files wins
+...
+</pre><p>
+ </p><p>
+ <a class="indexterm" name="id2564337"></a>
+ <a class="indexterm" name="id2564344"></a>
+ The <code class="filename">/etc/ldap.conf</code> file must be configured also. Refer to the PADL documentation
+ and source code for nss_ldap instructions.
+ </p><p>
+ The next step involves preparation on the ADS schema. This is briefly discussed in the remaining
+ part of this chapter.
+ </p><div class="sect4" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2564366"></a>IDMAP, Active Directory, and MS Services for UNIX 3.5</h5></div></div></div><p>
+ <a class="indexterm" name="id2564375"></a>
+ The Microsoft Windows Service for UNIX version 3.5 is available for free
+ <a href="http://www.microsoft.com/windows/sfu/" target="_top">download</a>
+ from the Microsoft Web site. You will need to download this tool and install it following
+ Microsoft instructions.
+ </p></div><div class="sect4" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2564394"></a>IDMAP, Active Directory, and AD4UNIX</h5></div></div></div><p>
+ Instructions for obtaining and installing the AD4UNIX tool set can be found from the
+ <a href="http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?LDAP01/An_Alternative_Approach" target="_top">
+ Geekcomix</a> Web site.
+ </p></div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2564417"></a>UNIX/Linux Client Domain Member</h3></div></div></div><p><a class="indexterm" name="id2564424"></a>
+ 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.
+ </p><p><a class="indexterm" name="id2564442"></a>
+ The ability to use a common set of user credential across a variety of network systems
+ is generally regarded as a single sign-on (SSO) solution. SSO systems are sold by a
+ large number of vendors and include a range of technologies such as:
+ </p><div class="itemizedlist"><ul type="disc"><li><p>
+ Proxy sign-on
+ </p></li><li><p>
+ Federated directory provisioning
+ </p></li><li><p>
+ Metadirectory server solutions
+ </p></li><li><p>
+ Replacement authentication systems
+ </p></li></ul></div><p><a class="indexterm" name="id2564484"></a>
+ There are really four solutions that provide integrated authentication and
+ user identity management facilities:
+ </p><div class="itemizedlist"><ul type="disc"><li><p>
+ Samba winbind (free). Samba-3.0.20 introduced a complete replacement for Winbind that now
+ provides a greater level of scalability in large ADS environments.
+ </p></li><li><p>
+ <a href="http://www.padl.com" target="_top">PADL</a> PAM and LDAP tools (free).
+ </p></li><li><p>
+ <a href="http://www.vintela.com" target="_top">Vintela</a> Authentication Services (commercial).
+ </p></li><li><p>
+ <a href="http://www.centrify.com" target="_top">Centrify</a> DirectControl (commercial).
+ Centrify's commercial product allows UNIX and Linux systems to use Active Directory
+ security, directory and policy services. Enhancements include a centralized ID mapping that
+ allows Samba, DirectControl and Active Directory to seamlessly work together.
+ </p></li></ul></div><p>
+ The following guidelines are pertinent to the deployment of winbind-based authentication
+ and identity resolution with the express purpose of allowing users to log on to UNIX/Linux desktops
+ using Windows network domain user credentials (username and password).
+ </p><p>
+ 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.
+ </p><p>
+ <a class="indexterm" name="id2564563"></a>
+ On the other hand, if the authentication and identity resolution backend must be provided by
+ a Windows NT4-style domain or from an Active Directory Domain that does not have the Microsoft
+ Windows Services for UNIX installed, winbind is your best friend. Specific guidance for these
+ situations now follows.
+ </p><p>
+ <a class="indexterm" name="id2564581"></a>
+ <a class="indexterm" name="id2564587"></a>
+ <a class="indexterm" name="id2564594"></a>
+ To permit users to log on to a Linux system using Windows network credentials, you need to
+ configure identity resolution (NSS) and PAM. This means that the basic steps include those
+ outlined above with the addition of PAM configuration. Given that most workstations (desktop/client)
+ usually do not need to provide file and print services to a group of users, the configuration
+ of shares and printers is generally less important. Often this allows the share specifications
+ to be entirely removed from the <code class="filename">smb.conf</code> file. That is obviously an administrator decision.
+ </p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2564617"></a>NT4 Domain Member</h4></div></div></div><p>
+ The following steps provide a Linux system that users can log onto using
+ Windows NT4 (or Samba-3) domain network credentials:
+ </p><div class="procedure"><ol type="1"><li><p>
+ Follow the steps outlined in <a href="unixclients.html#wdcsdm" title="NT4/Samba Domain with Samba Domain Member Server: Using NSS and Winbind">???</a> and ensure that
+ all validation tests function as shown.
+ </p></li><li><p>
+ Identify what services users must log on to. On Red Hat Linux, if it is
+ intended that the user shall be given access to all services, it may be
+ most expeditious to simply configure the file
+ <code class="filename">/etc/pam.d/system-auth</code>.
+ </p></li><li><p>
+ 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
+ <code class="filename">/etc/pam.d</code> should be backed up to a safe location.
+ </p></li><li><p>
+ If you require only console login support, edit the <code class="filename">/etc/pam.d/login</code>
+ so it matches <a href="unixclients.html#ch9-pamwnbdlogin" title="Example 7.11. SUSE: PAM login Module Using Winbind">???</a>.
+ </p></li><li><p>
+ To provide the ability to log onto the graphical desktop interface, you must edit
+ the files <code class="filename">gdm</code> and <code class="filename">xdm</code> in the
+ <code class="filename">/etc/pam.d</code> directory.
+ </p></li><li><p>
+ Edit only one file at a time. Carefully validate its operation before attempting
+ to reboot the machine.
+ </p></li></ol></div></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2564739"></a>ADS Domain Member</h4></div></div></div><p>
+ 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.
+ </p><div class="procedure"><ol type="1"><li><p>
+ Follow the steps outlined in <a href="unixclients.html#adssdm" title="Active Directory Domain with Samba Domain Member Server">???</a> and ensure that
+ all validation tests function as shown.
+ </p></li><li><p>
+ Identify what services users must log on to. On Red Hat Linux, if it is
+ intended that the user shall be given access to all services, it may be
+ most expeditious to simply configure the file
+ <code class="filename">/etc/pam.d/system-auth</code> as shown in <a href="unixclients.html#ch9-rhsysauth" title="Example 7.13. Red Hat 9: PAM System Authentication File: /etc/pam.d/system-auth Module Using Winbind">???</a>.
+ </p></li><li><p>
+ 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
+ <code class="filename">/etc/pam.d</code> should be backed up to a safe location.
+ </p></li><li><p>
+ If you require only console login support, edit the <code class="filename">/etc/pam.d/login</code>
+ so it matches <a href="unixclients.html#ch9-pamwnbdlogin" title="Example 7.11. SUSE: PAM login Module Using Winbind">???</a>.
+ </p></li><li><p>
+ To provide the ability to log onto the graphical desktop interface, you must edit
+ the files <code class="filename">gdm</code> and <code class="filename">xdm</code> in the
+ <code class="filename">/etc/pam.d</code> directory.
+ </p></li><li><p>
+ Edit only one file at a time. Carefully validate its operation before attempting
+ to reboot the machine.
+ </p></li></ol></div></div><div class="example"><a name="ch9-pamwnbdlogin"></a><p class="title"><b>Example 7.11. SUSE: PAM <code class="filename">login</code> Module Using Winbind</b></p><pre class="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
+</pre></div><div class="example"><a name="ch9-pamwbndxdm"></a><p class="title"><b>Example 7.12. SUSE: PAM <code class="filename">xdm</code> Module Using Winbind</b></p><pre class="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
+</pre></div><div class="example"><a name="ch9-rhsysauth"></a><p class="title"><b>Example 7.13. Red Hat 9: PAM System Authentication File: <code class="filename">/etc/pam.d/system-auth</code> Module Using Winbind</b></p><pre class="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
+</pre></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2564991"></a>Key Points Learned</h3></div></div></div><p>
+ The addition of UNIX/Linux Samba servers and clients is a common requirement. In this chapter, you
+ learned how to integrate such servers so that the UID/GID mappings they use can be consistent
+ across all domain member servers. You also discovered how to implement the ability to use Samba
+ or Windows domain account credentials to log on to a UNIX/Linux client.
+ </p><p>
+ The following are key points made in this chapter:
+ </p><div class="itemizedlist"><ul type="disc"><li><p>
+ Domain controllers are always authoritative for the domain.
+ </p></li><li><p>
+ 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.
+ </p></li><li><p>
+ Resolution of user and group identities on domain member machines may be implemented
+ using direct LDAP services or using winbind.
+ </p></li><li><p>
+ On NSS/PAM enabled UNIX/Linux systems, NSS is responsible for identity management
+ and PAM is responsible for authentication of logon credentials (username and password).
+ </p></li></ul></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2565045"></a>Questions and Answers</h2></div></div></div><p>
+ The following questions were obtained from the mailing list and also from private discussions
+ with Windows network administrators.
+ </p><div class="qandaset"><dl><dt> <a href="unixclients.html#id2565063">
+ We use NIS for all UNIX accounts. Why do we need winbind?
+ </a></dt><dt> <a href="unixclients.html#id2565178">
+ Our IT management people do not like LDAP but are looking at Microsoft Active Directory.
+ Which is better?Active Directory
+ </a></dt><dt> <a href="unixclients.html#id2565262">
+ We want to implement a Samba PDC, four Samba BDCs, and 10 Samba servers. Is it possible
+ to use NIS in place of LDAP?
+ </a></dt><dt> <a href="unixclients.html#id2565373">
+ Are you suggesting that users should not log on to a domain member server? If so, why?
+ </a></dt><dt> <a href="unixclients.html#id2565494">trusted domainsdomaintrustedwinbind trusted domains onlydomain members
+ 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 winbind
+ trusted domains only 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?
+ </a></dt><dt> <a href="unixclients.html#id2565669">
+ What are the benefits of using LDAP for my domain member servers?
+ </a></dt><dt> <a href="unixclients.html#id2565853">
+ Is proper DNS operation necessary for Samba-3 plus LDAP? If so, what must I put into
+ my DNS configuration?
+ </a></dt><dt> <a href="unixclients.html#id2566011">
+ Our Windows 2003 Server Active Directory domain runs with NetBIOS disabled. Can we
+ use Samba-3 with that configuration?
+ </a></dt><dt> <a href="unixclients.html#id2566029">netadsjoinnetrpcjoin
+ When I tried to execute net ads join, I got no output. It did not work, so
+ I think that it failed. I then executed net rpc join and that worked fine.
+ That is okay, isn't it?
+ </a></dt></dl><table border="0" summary="Q and A Set"><col align="left" width="1%"><tbody><tr class="question"><td align="left" valign="top"><a name="id2565063"></a><a name="id2565066"></a><b></b></td><td align="left" valign="top"><p>
+ We use NIS for all UNIX accounts. Why do we need winbind?
+ </p></td></tr><tr class="answer"><td align="left" valign="top"><b></b></td><td align="left" valign="top"><p>
+ <a class="indexterm" name="id2565077"></a>
+ <a class="indexterm" name="id2565084"></a>
+ <a class="indexterm" name="id2565091"></a>
+ <a class="indexterm" name="id2565098"></a>
+ <a class="indexterm" name="id2565104"></a>
+ <a class="indexterm" name="id2565111"></a>
+ 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 <em class="parameter"><code>smbpasswd</code></em> or
+ <em class="parameter"><code>tdbsam</code></em>. Winbind is needed to handle the resolution of
+ SIDs from trusted domains to local UID/GID values.
+ </p><p>
+ <a class="indexterm" name="id2565138"></a>
+ <a class="indexterm" name="id2565146"></a>
+ On a domain member server, you effectively map Windows domain users to local users
+ that are in your NIS database by specifying the <em class="parameter"><code>winbind trusted domains
+ only</code></em>. This causes user and group account lookups to be routed via
+ the <span><strong class="command">getpwnam()</strong></span> family of systems calls. On an NIS-enabled client,
+ this pushes the resolution of users and groups out through NIS.
+ </p><p>
+ As a general rule, it is always a good idea to run winbind on all Samba servers.
+ </p></td></tr><tr class="question"><td align="left" valign="top"><a name="id2565178"></a><a name="id2565180"></a><b></b></td><td align="left" valign="top"><p>
+ Our IT management people do not like LDAP but are looking at Microsoft Active Directory.
+ Which is better?<a class="indexterm" name="id2565187"></a>
+ </p></td></tr><tr class="answer"><td align="left" valign="top"><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2565201"></a><a class="indexterm" name="id2565212"></a><a class="indexterm" name="id2565220"></a>
+ Microsoft Active Directory is an LDAP server that is intricately tied to a Kerberos
+ infrastructure. Most IT managers who object to LDAP do so because
+ an LDAP server is most often supplied as a raw tool that needs to be configured and
+ for which the administrator must create the schema, create the administration tools, and
+ devise the backup and recovery facilities in a site-dependent manner. LDAP servers
+ in general are seen as a high-energy, high-risk facility.
+ </p><p><a class="indexterm" name="id2565240"></a>
+ Microsoft Active Directory by comparison is easy to install and configure and
+ is supplied with all tools necessary to implement and manage the directory. For sites
+ that lack a lot of technical competence, Active Directory is a good choice. For sites
+ that have the technical competence to handle Active Directory well, LDAP is a good
+ alternative. The real issue is, What type of solution does
+ the site want? If management wants a choice to use an alternative, they may want to
+ consider the options. On the other hand, if management just wants a solution that works,
+ Microsoft Active Directory is a good solution.
+ </p></td></tr><tr class="question"><td align="left" valign="top"><a name="id2565262"></a><a name="id2565264"></a><b></b></td><td align="left" valign="top"><p>
+ We want to implement a Samba PDC, four Samba BDCs, and 10 Samba servers. Is it possible
+ to use NIS in place of LDAP?
+ </p></td></tr><tr class="answer"><td align="left" valign="top"><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2565276"></a><a class="indexterm" name="id2565284"></a><a class="indexterm" name="id2565292"></a><a class="indexterm" name="id2565300"></a><a class="indexterm" name="id2565308"></a><a class="indexterm" name="id2565316"></a><a class="indexterm" name="id2565324"></a>
+ 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?
+ </p><p><a class="indexterm" name="id2565341"></a><a class="indexterm" name="id2565349"></a><a class="indexterm" name="id2565357"></a>
+ 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.
+ </p></td></tr><tr class="question"><td align="left" valign="top"><a name="id2565373"></a><a name="id2565375"></a><b></b></td><td align="left" valign="top"><p>
+ Are you suggesting that users should not log on to a domain member server? If so, why?
+ </p></td></tr><tr class="answer"><td align="left" valign="top"><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2565387"></a><a class="indexterm" name="id2565395"></a><a class="indexterm" name="id2565406"></a>
+ Many UNIX administrators mock the model that the personal computer industry has adopted
+ as normative since the early days of Novell NetWare. The old
+ perception of the necessity to keep users off file and print servers was a result of
+ fears concerning the security and integrity of data. It was a simple and generally
+ effective measure to keep users away from servers, except through mapped drives.
+ </p><p><a class="indexterm" name="id2565424"></a><a class="indexterm" name="id2565432"></a><a class="indexterm" name="id2565440"></a><a class="indexterm" name="id2565448"></a><a class="indexterm" name="id2565456"></a>
+ UNIX administrators are fully correct in asserting that UNIX servers and workstations
+ are identical in terms of the software that is installed. They correctly assert that
+ in a well-secured environment it is safe to store files on a system that has hundreds
+ of users. But all network administrators must factor into the decision to allow or
+ reject general user logins to a UNIX system that is principally a file and print
+ server the risk to operations through simple user errors.
+ Only then can one begin to appraise the best strategy and adopt a site-specific
+ policy that best protects the needs of users and of the organization alike.
+ </p><p><a class="indexterm" name="id2565478"></a>
+ 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?
+ </p></td></tr><tr class="question"><td align="left" valign="top"><a name="id2565494"></a><a name="id2565496"></a><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2565500"></a><a class="indexterm" name="id2565508"></a><a class="indexterm" name="id2565519"></a><a class="indexterm" name="id2565527"></a>
+ We want to ensure that only users from our own domain plus from trusted domains can use our
+ Samba servers. In the <code class="filename">smb.conf</code> file on all servers, we have enabled the <em class="parameter"><code>winbind
+ trusted domains only</code></em> 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?
+ </p></td></tr><tr class="answer"><td align="left" valign="top"><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2565560"></a><a class="indexterm" name="id2565568"></a><a class="indexterm" name="id2565575"></a><a class="indexterm" name="id2565583"></a><a class="indexterm" name="id2565591"></a><a class="indexterm" name="id2565599"></a>
+ The manual page for this <em class="parameter"><code>winbind trusted domains only</code></em> parameter says,
+ “<span class="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 <code class="constant">SAMBA\user1</code> would be
+ mapped to the account <code class="constant">user1</code> in <code class="filename">/etc/passwd</code> instead
+ of allocating a new UID for him or her.</span>” This clearly suggests that you are trying
+ to use this parameter inappropriately.
+ </p><p><a class="indexterm" name="id2565641"></a>
+ A far better solution is to use the <em class="parameter"><code>valid users</code></em> by specifying
+ precisely the domain users and groups that should be permitted access to the shares. You could,
+ for example, set the following parameters:
+</p><pre class="screen">
+[demoshare]
+ path = /export/demodata
+ valid users = @"Domain Users", @"OTHERDOMAIN\Domain Users"
+</pre><p>
+ </p></td></tr><tr class="question"><td align="left" valign="top"><a name="id2565669"></a><a name="id2565672"></a><b></b></td><td align="left" valign="top"><p>
+ What are the benefits of using LDAP for my domain member servers?
+ </p></td></tr><tr class="answer"><td align="left" valign="top"><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2565682"></a><a class="indexterm" name="id2565690"></a><a class="indexterm" name="id2565698"></a><a class="indexterm" name="id2565706"></a><a class="indexterm" name="id2565713"></a><a class="indexterm" name="id2565721"></a><a class="indexterm" name="id2565730"></a><a class="indexterm" name="id2565737"></a><a class="indexterm" name="id2565745"></a>
+ 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.
+ </p><p><a class="indexterm" name="id2565761"></a><a class="indexterm" name="id2565769"></a><a class="indexterm" name="id2565777"></a><a class="indexterm" name="id2565785"></a><a class="indexterm" name="id2565793"></a><a class="indexterm" name="id2565801"></a><a class="indexterm" name="id2565812"></a><a class="indexterm" name="id2565820"></a>
+ 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 <em class="parameter"><code>
+ idmap uid/gid</code></em> in the <code class="filename">smb.conf</code> 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.
+ </p></td></tr><tr class="question"><td align="left" valign="top"><a name="id2565853"></a><a name="id2565855"></a><b></b></td><td align="left" valign="top"><p>
+ Is proper DNS operation necessary for Samba-3 plus LDAP? If so, what must I put into
+ my DNS configuration?
+ </p></td></tr><tr class="answer"><td align="left" valign="top"><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2565866"></a><a class="indexterm" name="id2565878"></a><a class="indexterm" name="id2565889"></a><a class="indexterm" name="id2565897"></a><a class="indexterm" name="id2565905"></a><a class="indexterm" name="id2565912"></a><a class="indexterm" name="id2565920"></a>
+ Samba depends on correctly functioning resolution of hostnames to their IP address. Samba
+ makes no direct DNS lookup calls, but rather redirects all name-to-address calls via the
+ <span><strong class="command">getXXXbyXXX()</strong></span> function calls. The configuration of the <code class="constant">hosts</code>
+ entry in the NSS <code class="filename">/etc/nsswitch.conf</code> file determines how the underlying
+ resolution process is implemented. If the <code class="constant">hosts</code> entry in your NSS
+ control file says:
+</p><pre class="screen">
+hosts: files dns wins
+</pre><p>
+ this means that a hostname lookup first tries the <code class="filename">/etc/hosts</code>.
+ If this fails to resolve, it attempts a DNS lookup, and if that fails, it tries a
+ WINS lookup.
+ </p><p><a class="indexterm" name="id2565975"></a><a class="indexterm" name="id2565983"></a><a class="indexterm" name="id2565991"></a>
+ The addition of the WINS-based name lookup makes sense only if NetBIOS over TCP/IP has
+ been enabled on all Windows clients. Where NetBIOS over TCP/IP has been disabled, DNS
+ is the preferred name resolution technology. This usually makes most sense when Samba
+ is a client of an Active Directory domain, where NetBIOS use has been disabled. In this
+ case, the Windows 200x autoregisters all locator records it needs with its own DNS
+ server or servers.
+ </p></td></tr><tr class="question"><td align="left" valign="top"><a name="id2566011"></a><a name="id2566013"></a><b></b></td><td align="left" valign="top"><p>
+ Our Windows 2003 Server Active Directory domain runs with NetBIOS disabled. Can we
+ use Samba-3 with that configuration?
+ </p></td></tr><tr class="answer"><td align="left" valign="top"><b></b></td><td align="left" valign="top"><p>
+ Yes.
+ </p></td></tr><tr class="question"><td align="left" valign="top"><a name="id2566029"></a><a name="id2566031"></a><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2566035"></a><a class="indexterm" name="id2566049"></a>
+ When I tried to execute net ads join, I got no output. It did not work, so
+ I think that it failed. I then executed net rpc join and that worked fine.
+ That is okay, isn't it?
+ </p></td></tr><tr class="answer"><td align="left" valign="top"><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2566073"></a><a class="indexterm" name="id2566081"></a>
+ 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.
+ </p></td></tr></tbody></table></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="DMSMig.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="DMSMig.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="upgrades.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part II. Domain Members, Updating Samba and Migration </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 8. Updating Samba-3</td></tr></table></div></body></html>
projects / samba / blobdiff