--- /dev/null
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 23. Winbind: Use of Domain Accounts</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="The Official Samba-3 HOWTO and Reference Guide"><link rel="up" href="optional.html" title="Part III. Advanced Configuration"><link rel="prev" href="VFS.html" title="Chapter 22. Stackable VFS modules"><link rel="next" href="AdvancedNetworkManagement.html" title="Chapter 24. Advanced Network Management"></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 23. Winbind: Use of Domain Accounts</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="VFS.html">Prev</a> </td><th width="60%" align="center">Part III. Advanced Configuration</th><td width="20%" align="right"> <a accesskey="n" href="AdvancedNetworkManagement.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="winbind"></a>Chapter 23. Winbind: Use of Domain Accounts</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Tim</span> <span class="surname">Potter</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><code class="email"><<a href="mailto:tpot@linuxcare.com.au">tpot@linuxcare.com.au</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Andrew</span> <span class="surname">Tridgell</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><code class="email"><<a href="mailto:tridge@samba.org">tridge@samba.org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Naag</span> <span class="surname">Mummaneni</span></h3><span class="contrib">Notes for Solaris</span><div class="affiliation"><div class="address"><p><code class="email"><<a href="mailto:getnag@rediffmail.com">getnag@rediffmail.com</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="surname">Trostel</span></h3><div class="affiliation"><span class="orgname">SNAP<br></span><div class="address"><p><code class="email"><<a href="mailto:jtrostel@snapserver.com">jtrostel@snapserver.com</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Jelmer</span> <span class="othername">R.</span> <span class="surname">Vernooij</span></h3><div class="affiliation"><span class="orgname">The Samba Team<br></span><div class="address"><p><code class="email"><<a href="mailto:jelmer@samba.org">jelmer@samba.org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="othername">H.</span> <span class="surname">Terpstra</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><code class="email"><<a href="mailto:jht@samba.org">jht@samba.org</a>></code></p></div></div></div></div><div><p class="pubdate">June 15, 2005</p></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="winbind.html#id2620007">Features and Benefits</a></span></dt><dt><span class="sect1"><a href="winbind.html#id2620356">Introduction</a></span></dt><dt><span class="sect1"><a href="winbind.html#id2620445">What Winbind Provides</a></span></dt><dd><dl><dt><span class="sect2"><a href="winbind.html#id2620599">Target Uses</a></span></dt><dt><span class="sect2"><a href="winbind.html#id2620645">Handling of Foreign SIDs</a></span></dt></dl></dd><dt><span class="sect1"><a href="winbind.html#id2620774">How Winbind Works</a></span></dt><dd><dl><dt><span class="sect2"><a href="winbind.html#id2620825">Microsoft Remote Procedure Calls</a></span></dt><dt><span class="sect2"><a href="winbind.html#id2620912">Microsoft Active Directory Services</a></span></dt><dt><span class="sect2"><a href="winbind.html#id2620959">Name Service Switch</a></span></dt><dt><span class="sect2"><a href="winbind.html#id2621192">Pluggable Authentication Modules</a></span></dt><dt><span class="sect2"><a href="winbind.html#id2621348">User and Group ID Allocation</a></span></dt><dt><span class="sect2"><a href="winbind.html#id2621425">Result Caching</a></span></dt></dl></dd><dt><span class="sect1"><a href="winbind.html#id2621482">Installation and Configuration</a></span></dt><dd><dl><dt><span class="sect2"><a href="winbind.html#id2621488">Introduction</a></span></dt><dt><span class="sect2"><a href="winbind.html#id2621603">Requirements</a></span></dt><dt><span class="sect2"><a href="winbind.html#id2621755">Testing Things Out</a></span></dt></dl></dd><dt><span class="sect1"><a href="winbind.html#id2624214">Conclusion</a></span></dt><dt><span class="sect1"><a href="winbind.html#id2624262">Common Errors</a></span></dt><dd><dl><dt><span class="sect2"><a href="winbind.html#id2624305">NSCD Problem Warning</a></span></dt><dt><span class="sect2"><a href="winbind.html#id2624342">Winbind Is Not Resolving Users and Groups</a></span></dt></dl></dd></dl></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2620007"></a>Features and Benefits</h2></div></div></div><p>
+<a class="indexterm" name="id2620015"></a>
+<a class="indexterm" name="id2620022"></a>
+ Integration of UNIX and Microsoft Windows NT through a unified logon has
+ been considered a “<span class="quote">holy grail</span>” in heterogeneous computing environments for
+ a long time.
+ </p><p>
+<a class="indexterm" name="id2620038"></a>
+<a class="indexterm" name="id2620045"></a>
+<a class="indexterm" name="id2620052"></a>
+<a class="indexterm" name="id2620059"></a>
+ There is one other facility without which UNIX and Microsoft Windows network
+ interoperability would suffer greatly. It is imperative that there be a
+ mechanism for sharing files across UNIX systems and to be able to assign
+ domain user and group ownerships with integrity.
+ </p><p>
+<a class="indexterm" name="id2620074"></a>
+<a class="indexterm" name="id2620083"></a>
+<a class="indexterm" name="id2620090"></a>
+<a class="indexterm" name="id2620097"></a>
+ <span class="emphasis"><em>winbind</em></span> is a component of the Samba suite of programs that
+ solves the unified logon problem. Winbind uses a UNIX implementation of Microsoft
+ RPC calls, Pluggable Authentication Modules (PAMs), and the name service switch (NSS) to
+ allow Windows NT domain users to appear and operate as UNIX users on a UNIX
+ machine. This chapter describes the Winbind system, the functionality
+ it provides, how it is configured, and how it works internally.
+ </p><p>
+ Winbind provides three separate functions:
+ </p><div class="itemizedlist"><ul type="disc"><li><p>
+<a class="indexterm" name="id2620125"></a>
+<a class="indexterm" name="id2620131"></a>
+ Authentication of user credentials (via PAM). This makes it possible to
+ log onto a UNIX/Linux system using user and group accounts from a Windows
+ NT4 (including a Samba domain) or an Active Directory domain.
+ </p></li><li><p>
+<a class="indexterm" name="id2620146"></a>
+<a class="indexterm" name="id2620153"></a>
+ Identity resolution (via NSS). This is the default when winbind is not used.
+ </p></li><li><p>
+<a class="indexterm" name="id2620165"></a>
+<a class="indexterm" name="id2620172"></a>
+<a class="indexterm" name="id2620178"></a>
+<a class="indexterm" name="id2620185"></a>
+<a class="indexterm" name="id2620192"></a>
+<a class="indexterm" name="id2620198"></a>
+<a class="indexterm" name="id2620205"></a>
+ Winbind maintains a database called winbind_idmap.tdb in which it stores
+ mappings between UNIX UIDs, GIDs, and NT SIDs. This mapping is used only
+ for users and groups that do not have a local UID/GID. It stores the UID/GID
+ allocated from the idmap uid/gid range that it has mapped to the NT SID.
+ If <em class="parameter"><code>idmap backend</code></em> has been specified as <code class="constant">ldap:ldap://hostname[:389]</code>,
+ then instead of using a local mapping, Winbind will obtain this information
+ from the LDAP database.
+ </p></li></ul></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+ <a class="indexterm" name="id2620240"></a>
+ <a class="indexterm" name="id2620247"></a>
+<a class="indexterm" name="id2620256"></a>
+<a class="indexterm" name="id2620263"></a>
+<a class="indexterm" name="id2620270"></a>
+<a class="indexterm" name="id2620277"></a>
+ If <span><strong class="command">winbindd</strong></span> is not running, smbd (which calls <span><strong class="command">winbindd</strong></span>) will fall back to
+ using purely local information from <code class="filename">/etc/passwd</code> and <code class="filename">/etc/group</code> and no dynamic
+ mapping will be used. On an operating system that has been enabled with the NSS,
+ the resolution of user and group information will be accomplished via NSS.
+ </p></div><div class="figure"><a name="winbind_idmap"></a><p class="title"><b>Figure 23.1. Winbind Idmap</b></p><div class="mediaobject"><img src="images/idmap_winbind_no_loop.png" width="243" alt="Winbind Idmap"></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2620356"></a>Introduction</h2></div></div></div><p>It is well known that UNIX and Microsoft Windows NT have
+ different models for representing user and group information and
+ use different technologies for implementing them. This fact has
+ made it difficult to integrate the two systems in a satisfactory
+ manner.</p><p>
+<a class="indexterm" name="id2620371"></a>
+<a class="indexterm" name="id2620378"></a>
+ One common solution in use today has been to create
+ identically named user accounts on both the UNIX and Windows systems
+ and use the Samba suite of programs to provide file and print services
+ between the two. This solution is far from perfect, however, because
+ adding and deleting users on both sets of machines becomes a chore,
+ and two sets of passwords are required both of which
+ can lead to synchronization problems between the UNIX and Windows
+ systems and confusion for users.</p><p>We divide the unified logon problem for UNIX machines into
+ three smaller problems:</p><div class="itemizedlist"><ul type="disc"><li><p>Obtaining Windows NT user and group information.
+ </p></li><li><p>Authenticating Windows NT users.
+ </p></li><li><p>Password changing for Windows NT users.
+ </p></li></ul></div><p>
+<a class="indexterm" name="id2620422"></a>
+<a class="indexterm" name="id2620429"></a>
+ Ideally, a prospective solution to the unified logon problem
+ would satisfy all the above components without duplication of
+ information on the UNIX machines and without creating additional
+ tasks for the system administrator when maintaining users and
+ groups on either system. The Winbind system provides a simple
+ and elegant solution to all three components of the unified logon
+ problem.</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2620445"></a>What Winbind Provides</h2></div></div></div><p>
+<a class="indexterm" name="id2620453"></a>
+<a class="indexterm" name="id2620460"></a>
+<a class="indexterm" name="id2620467"></a>
+<a class="indexterm" name="id2620474"></a>
+ Winbind unifies UNIX and Windows NT account management by
+ allowing a UNIX box to become a full member of an NT domain. Once
+ this is done, the UNIX box will see NT users and groups as if
+ they were “<span class="quote">native</span>” UNIX users and groups, allowing the NT domain
+ to be used in much the same manner that NIS+ is used within
+ UNIX-only environments.</p><p>
+<a class="indexterm" name="id2620494"></a>
+<a class="indexterm" name="id2620500"></a>
+<a class="indexterm" name="id2620507"></a>
+<a class="indexterm" name="id2620514"></a>
+ The end result is that whenever a
+ program on the UNIX machine asks the operating system to look up
+ a user or group name, the query will be resolved by asking the
+ NT domain controller for the specified domain to do the lookup.
+ Because Winbind hooks into the operating system at a low level
+ (via the NSS name resolution modules in the C library), this
+ redirection to the NT domain controller is completely
+ transparent.</p><p>
+<a class="indexterm" name="id2620531"></a>
+<a class="indexterm" name="id2620538"></a>
+ Users on the UNIX machine can then use NT user and group
+ names as they would “<span class="quote">native</span>” UNIX names. They can chown files
+ so they are owned by NT domain users or even login to the
+ UNIX machine and run a UNIX X-Window session as a domain user.</p><p>
+<a class="indexterm" name="id2620556"></a>
+ The only obvious indication that Winbind is being used is
+ that user and group names take the form <code class="constant">DOMAIN\user</code> and
+ <code class="constant">DOMAIN\group</code>. This is necessary because it allows Winbind to determine
+ that redirection to a domain controller is wanted for a particular
+ lookup and which trusted domain is being referenced.</p><p>
+<a class="indexterm" name="id2620578"></a>
+<a class="indexterm" name="id2620585"></a>
+ Additionally, Winbind provides an authentication service that hooks into the PAM system
+ to provide authentication via an NT domain to any PAM-enabled
+ applications. This capability solves the problem of synchronizing
+ passwords between systems, since all passwords are stored in a single
+ location (on the domain controller).</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2620599"></a>Target Uses</h3></div></div></div><p>
+<a class="indexterm" name="id2620607"></a>
+ Winbind is targeted at organizations that have an
+ existing NT-based domain infrastructure into which they wish
+ to put UNIX workstations or servers. Winbind will allow these
+ organizations to deploy UNIX workstations without having to
+ maintain a separate account infrastructure. This greatly
+ simplifies the administrative overhead of deploying UNIX
+ workstations into an NT-based organization.</p><p>
+<a class="indexterm" name="id2620624"></a>
+<a class="indexterm" name="id2620631"></a>
+ Another interesting way in which we expect Winbind to
+ be used is as a central part of UNIX-based appliances. Appliances
+ that provide file and print services to Microsoft-based networks
+ will be able to use Winbind to provide seamless integration of
+ the appliance into the domain.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2620645"></a>Handling of Foreign SIDs</h3></div></div></div><p>
+<a class="indexterm" name="id2620653"></a>
+ The term <span class="emphasis"><em>foreign SID</em></span> is often met with the reaction that it
+ is not relevant to a particular environment. The following documents an interchange
+ that took place on the Samba mailing list. It is a good example of the confusion
+ often expressed regarding the use of winbind.
+ </p><p>
+<a class="indexterm" name="id2620675"></a>
+ Fact: Winbind is needed to handle users who use workstations that are NOT part
+ of the local domain.
+ </p><p>
+<a class="indexterm" name="id2620687"></a>
+ Response: “<span class="quote">Why? I've used Samba with workstations that are not part of my domains
+ lots of times without using winbind. I thought winbind was for using Samba as a member server
+ in a domain controlled by another Samba/Windows PDC.</span>”
+ </p><p>
+<a class="indexterm" name="id2620704"></a>
+<a class="indexterm" name="id2620711"></a>
+<a class="indexterm" name="id2620717"></a>
+ If the Samba server will be accessed from a domain other than the local Samba domain, or
+ if there will be access from machines that are not local domain members, winbind will
+ permit the allocation of UIDs and GIDs from the assigned pool that will keep the identity
+ of the foreign user separate from users that are members of the Samba domain.
+ </p><p>
+<a class="indexterm" name="id2620733"></a>
+<a class="indexterm" name="id2620740"></a>
+<a class="indexterm" name="id2620747"></a>
+<a class="indexterm" name="id2620754"></a>
+ This means that winbind is eminently useful in cases where a single
+ Samba PDC on a local network is combined with both domain member and domain non-member workstations.
+ If winbind is not used, the user george on a Windows workstation that is not a domain
+ member will be able to access the files of a user called george in the account database
+ of the Samba server that is acting as a PDC. When winbind is used, the default condition
+ is that the local user george will be treated as the account DOMAIN\george and the
+ foreign (non-member of the domain) account will be treated as MACHINE\george because
+ each has a different SID.
+ </p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2620774"></a>How Winbind Works</h2></div></div></div><p>
+<a class="indexterm" name="id2620782"></a>
+<a class="indexterm" name="id2620789"></a>
+<a class="indexterm" name="id2620796"></a>
+<a class="indexterm" name="id2620802"></a>
+ The Winbind system is designed around a client/server
+ architecture. A long-running <span><strong class="command">winbindd</strong></span> daemon
+ listens on a UNIX domain socket waiting for requests
+ to arrive. These requests are generated by the NSS and PAM
+ clients and are processed sequentially.</p><p>The technologies used to implement Winbind are described
+ in detail below.</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2620825"></a>Microsoft Remote Procedure Calls</h3></div></div></div><p>
+<a class="indexterm" name="id2620833"></a>
+<a class="indexterm" name="id2620842"></a>
+<a class="indexterm" name="id2620849"></a>
+<a class="indexterm" name="id2620856"></a>
+<a class="indexterm" name="id2620863"></a>
+ Over the last few years, efforts have been underway by various Samba Team members to implement various aspects of
+ the Microsoft Remote Procedure Call (MSRPC) system. This system is used for most network-related operations
+ between Windows NT machines, including remote management, user authentication, and print spooling. Although
+ initially this work was done to aid the implementation of Primary Domain Controller (PDC) functionality in
+ Samba, it has also yielded a body of code that can be used for other purposes.
+ </p><p>
+<a class="indexterm" name="id2620882"></a>
+<a class="indexterm" name="id2620889"></a>
+<a class="indexterm" name="id2620896"></a>
+ Winbind uses various MSRPC calls to enumerate domain users and groups and to obtain detailed information about
+ individual users or groups. Other MSRPC calls can be used to authenticate NT domain users and to change user
+ passwords. By directly querying a Windows PDC for user and group information, Winbind maps the NT account
+ information onto UNIX user and group names.
+ </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2620912"></a>Microsoft Active Directory Services</h3></div></div></div><p>
+<a class="indexterm" name="id2620920"></a>
+<a class="indexterm" name="id2620926"></a>
+<a class="indexterm" name="id2620933"></a>
+<a class="indexterm" name="id2620940"></a>
+ Since late 2001, Samba has gained the ability to interact with Microsoft Windows 2000 using its “<span class="quote">native
+ mode</span>” protocols rather than the NT4 RPC services. Using LDAP and Kerberos, a domain member running
+ Winbind can enumerate users and groups in exactly the same way as a Windows 200x client would, and in so doing
+ provide a much more efficient and effective Winbind implementation.
+ </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2620959"></a>Name Service Switch</h3></div></div></div><p>
+<a class="indexterm" name="id2620967"></a>
+<a class="indexterm" name="id2620974"></a>
+<a class="indexterm" name="id2620981"></a>
+<a class="indexterm" name="id2620987"></a>
+ The NSS is a feature that is present in many UNIX operating systems. It allows system
+ information such as hostnames, mail aliases, and user information
+ to be resolved from different sources. For example, a standalone
+ UNIX workstation may resolve system information from a series of
+ flat files stored on the local file system. A networked workstation
+ may first attempt to resolve system information from local files,
+ and then consult an NIS database for user information or a DNS server
+ for hostname information.</p><p>
+<a class="indexterm" name="id2621006"></a>
+<a class="indexterm" name="id2621012"></a>
+<a class="indexterm" name="id2621019"></a>
+<a class="indexterm" name="id2621026"></a>
+<a class="indexterm" name="id2621033"></a>
+ The NSS application programming interface allows Winbind
+ to present itself as a source of system information when
+ resolving UNIX usernames and groups. Winbind uses this interface
+ and information obtained from a Windows NT server using MSRPC
+ calls to provide a new source of account enumeration. Using standard
+ UNIX library calls, you can enumerate the users and groups on
+ a UNIX machine running Winbind and see all users and groups in
+ an NT domain plus any trusted domain as though they were local
+ users and groups.</p><p>
+<a class="indexterm" name="id2621052"></a>
+<a class="indexterm" name="id2621059"></a>
+<a class="indexterm" name="id2621066"></a>
+ The primary control file for NSS is <code class="filename">/etc/nsswitch.conf</code>.
+ When a UNIX application makes a request to do a lookup,
+ the C library looks in <code class="filename">/etc/nsswitch.conf</code>
+ for a line that matches the service type being requested; for
+ example, the “<span class="quote">passwd</span>” service type is used when user or group names
+ are looked up. This config line specifies which implementations
+ of that service should be tried and in what order. If the passwd
+ config line is:
+</p><pre class="screen">
+passwd: files example
+</pre><p>
+<a class="indexterm" name="id2621101"></a>
+<a class="indexterm" name="id2621108"></a>
+<a class="indexterm" name="id2621115"></a>
+ then the C library will first load a module called
+ <code class="filename">/lib/libnss_files.so</code> followed by
+ the module <code class="filename">/lib/libnss_example.so</code>. The
+ C library will dynamically load each of these modules in turn
+ and call resolver functions within the modules to try to resolve
+ the request. Once the request is resolved, the C library returns the
+ result to the application.</p><p>
+<a class="indexterm" name="id2621143"></a>
+<a class="indexterm" name="id2621150"></a>
+<a class="indexterm" name="id2621157"></a>
+ This NSS interface provides an easy way for Winbind
+ to hook into the operating system. All that needs to be done
+ is to put <code class="filename">libnss_winbind.so</code> in <code class="filename">/lib/</code>
+ then add “<span class="quote">winbind</span>” into <code class="filename">/etc/nsswitch.conf</code> at
+ the appropriate place. The C library will then call Winbind to
+ resolve user and group names.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2621192"></a>Pluggable Authentication Modules</h3></div></div></div><p>
+<a class="indexterm" name="id2621200"></a>
+<a class="indexterm" name="id2621207"></a>
+<a class="indexterm" name="id2621214"></a>
+<a class="indexterm" name="id2621221"></a>
+ PAMs provide a system for abstracting authentication and authorization
+ technologies. With a PAM module, it is possible to specify different
+ authentication methods for different system applications without
+ having to recompile these applications. PAM is also useful
+ for implementing a particular policy for authorization. For example,
+ a system administrator may only allow console logins from users
+ stored in the local password file but only allow users resolved from
+ an NIS database to log in over the network.</p><p>
+<a class="indexterm" name="id2621240"></a>
+<a class="indexterm" name="id2621246"></a>
+<a class="indexterm" name="id2621253"></a>
+<a class="indexterm" name="id2621260"></a>
+<a class="indexterm" name="id2621267"></a>
+ Winbind uses the authentication management and password
+ management PAM interface to integrate Windows NT users into a
+ UNIX system. This allows Windows NT users to log in to a UNIX
+ machine and be authenticated against a suitable PDC.
+ These users can also change their passwords and have
+ this change take effect directly on the PDC.
+ </p><p>
+<a class="indexterm" name="id2621283"></a>
+<a class="indexterm" name="id2621289"></a>
+<a class="indexterm" name="id2621296"></a>
+<a class="indexterm" name="id2621303"></a>
+ PAM is configured by providing control files in the directory
+ <code class="filename">/etc/pam.d/</code> for each of the services that
+ require authentication. When an authentication request is made
+ by an application, the PAM code in the C library looks up this
+ control file to determine what modules to load to do the
+ authentication check and in what order. This interface makes adding
+ a new authentication service for Winbind very easy: simply copy
+ the <code class="filename">pam_winbind.so</code> module
+ to <code class="filename">/lib/security/</code>, and the PAM
+ control files for relevant services are updated to allow
+ authentication via Winbind. See the PAM documentation
+ in <a href="pam.html" title="Chapter 27. PAM-Based Distributed Authentication">PAM-Based Distributed Authentication</a>, for more information.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2621348"></a>User and Group ID Allocation</h3></div></div></div><p>
+<a class="indexterm" name="id2621356"></a>
+<a class="indexterm" name="id2621363"></a>
+<a class="indexterm" name="id2621369"></a>
+ When a user or group is created under Windows NT/200x,
+ it is allocated a numerical relative identifier (RID). This is
+ slightly different from UNIX, which has a range of numbers that are
+ used to identify users and the same range used to identify
+ groups. It is Winbind's job to convert RIDs to UNIX ID numbers and
+ vice versa. When Winbind is configured, it is given part of the UNIX
+ user ID space and a part of the UNIX group ID space in which to
+ store Windows NT users and groups. If a Windows NT user is
+ resolved for the first time, it is allocated the next UNIX ID from
+ the range. The same process applies for Windows NT groups. Over
+ time, Winbind will have mapped all Windows NT users and groups
+ to UNIX user IDs and group IDs.</p><p>
+<a class="indexterm" name="id2621392"></a>
+<a class="indexterm" name="id2621399"></a>
+<a class="indexterm" name="id2621406"></a>
+<a class="indexterm" name="id2621413"></a>
+ The results of this mapping are stored persistently in
+ an ID mapping database held in a tdb database. This ensures that
+ RIDs are mapped to UNIX IDs in a consistent way.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2621425"></a>Result Caching</h3></div></div></div><p>
+<a class="indexterm" name="id2621432"></a>
+<a class="indexterm" name="id2621439"></a>
+<a class="indexterm" name="id2621446"></a>
+<a class="indexterm" name="id2621453"></a>
+<a class="indexterm" name="id2621459"></a>
+ An active directory system can generate a lot of user and group
+ name lookups. To reduce the network cost of these lookups, Winbind
+ uses a caching scheme based on the SAM sequence number supplied
+ by NT domain controllers. User or group information returned
+ by a PDC is cached by Winbind along with a sequence number also
+ returned by the PDC. This sequence number is incremented by
+ Windows NT whenever any user or group information is modified. If
+ a cached entry has expired, the sequence number is requested from
+ the PDC and compared against the sequence number of the cached entry.
+ If the sequence numbers do not match, then the cached information
+ is discarded and up-to-date information is requested directly
+ from the PDC.</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2621482"></a>Installation and Configuration</h2></div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2621488"></a>Introduction</h3></div></div></div><p>
+<a class="indexterm" name="id2621496"></a>
+<a class="indexterm" name="id2621502"></a>
+<a class="indexterm" name="id2621509"></a>
+This section describes the procedures used to get Winbind up and
+running. Winbind is capable of providing access
+and authentication control for Windows Domain users through an NT
+or Windows 200x PDC for regular services, such as telnet and ftp, as
+well for Samba services.
+</p><div class="itemizedlist"><ul type="disc"><li><p>
+ <span class="emphasis"><em>Why should I do this?</em></span>
+ </p><p>
+<a class="indexterm" name="id2621535"></a>
+<a class="indexterm" name="id2621542"></a>
+<a class="indexterm" name="id2621549"></a>
+<a class="indexterm" name="id2621556"></a>
+ This allows the Samba administrator to rely on the
+ authentication mechanisms on the Windows NT/200x PDC for the authentication
+ of domain members. Windows NT/200x users no longer need to have separate
+ accounts on the Samba server.
+ </p></li><li><p>
+ <span class="emphasis"><em>Who should be reading this document?</em></span>
+ </p><p>
+<a class="indexterm" name="id2621581"></a>
+<a class="indexterm" name="id2621587"></a>
+ This document is designed for system administrators. If you are
+ implementing Samba on a file server and wish to (fairly easily)
+ integrate existing Windows NT/200x users from your PDC onto the
+ Samba server, this document is for you.
+ </p></li></ul></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2621603"></a>Requirements</h3></div></div></div><p>
+<a class="indexterm" name="id2621610"></a>
+<a class="indexterm" name="id2621617"></a>
+<a class="indexterm" name="id2621624"></a>
+If you have a Samba configuration file that you are currently using, <span class="emphasis"><em>BACK IT UP!</em></span>
+If your system already uses PAM, <span class="emphasis"><em>back up the <code class="filename">/etc/pam.d</code> directory
+contents!</em></span> If you haven't already made a boot disk, <span class="emphasis"><em>MAKE ONE NOW!</em></span>
+</p><p>
+<a class="indexterm" name="id2621654"></a>
+<a class="indexterm" name="id2621660"></a>
+<a class="indexterm" name="id2621667"></a>
+Messing with the PAM configuration files can make it nearly impossible to log in to your machine. That's
+why you want to be able to boot back into your machine in single-user mode and restore your
+<code class="filename">/etc/pam.d</code> to the original state it was in if you get frustrated with the
+way things are going.
+</p><p>
+<a class="indexterm" name="id2621688"></a>
+<a class="indexterm" name="id2621695"></a>
+The latest version of Samba-3 includes a functioning winbindd daemon. Please refer to the <a href="http://samba.org/" target="_top">main Samba Web page</a>, or better yet, your closest Samba mirror site for
+instructions on downloading the source code.
+</p><p>
+<a class="indexterm" name="id2621714"></a>
+<a class="indexterm" name="id2621721"></a>
+<a class="indexterm" name="id2621728"></a>
+<a class="indexterm" name="id2621735"></a>
+To allow domain users the ability to access Samba shares and files, as well as potentially other services
+provided by your Samba machine, PAM must be set up properly on your
+machine. In order to compile the Winbind modules, you should have at least the PAM development libraries installed
+on your system. Please refer to the PAM Web site <a href="http://www.kernel.org/pub/linux/libs/pam/" target="_top">http://www.kernel.org/pub/linux/libs/pam/</a>.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2621755"></a>Testing Things Out</h3></div></div></div><p>
+<a class="indexterm" name="id2621762"></a>
+<a class="indexterm" name="id2621769"></a>
+<a class="indexterm" name="id2621776"></a>
+<a class="indexterm" name="id2621783"></a>
+<a class="indexterm" name="id2621790"></a>
+Before starting, it is probably best to kill off all the Samba-related daemons running on your server.
+Kill off all <span class="application">smbd</span>, <span class="application">nmbd</span>, and <span class="application">winbindd</span> processes that may be running. To use PAM,
+make sure that you have the standard PAM package that supplies the <code class="filename">/etc/pam.d</code>
+directory structure, including the PAM modules that are used by PAM-aware services, several PAM libraries,
+and the <code class="filename">/usr/doc</code> and <code class="filename">/usr/man</code> entries for PAM. Winbind is built
+better in Samba if the pam-devel package is also installed. This package includes the header files
+needed to compile PAM-aware applications.
+</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2621842"></a>Configure <code class="filename">nsswitch.conf</code> and the Winbind Libraries on Linux and Solaris</h4></div></div></div><p>
+<a class="indexterm" name="id2621856"></a>
+<a class="indexterm" name="id2621863"></a>
+<a class="indexterm" name="id2621869"></a>
+<a class="indexterm" name="id2621876"></a>
+PAM is a standard component of most current generation UNIX/Linux systems. Unfortunately, few systems install
+the <code class="filename">pam-devel</code> libraries that are needed to build PAM-enabled Samba. Additionally, Samba-3
+may auto-install the Winbind files into their correct locations on your system, so before you get too far down
+the track, be sure to check if the following configuration is really
+necessary. You may only need to configure
+<code class="filename">/etc/nsswitch.conf</code>.
+</p><p>
+The libraries needed to run the <span class="application">winbindd</span> daemon through nsswitch need to be copied to their proper locations:
+</p><p>
+<a class="indexterm" name="id2621916"></a>
+</p><pre class="screen">
+<code class="prompt">root# </code><strong class="userinput"><code>cp ../samba/source/nsswitch/libnss_winbind.so /lib</code></strong>
+</pre><p>
+</p><p>
+I also found it necessary to make the following symbolic link:
+</p><p>
+<code class="prompt">root# </code> <strong class="userinput"><code>ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2</code></strong>
+</p><p>And, in the case of Sun Solaris:
+<a class="indexterm" name="id2621963"></a>
+</p><pre class="screen">
+<code class="prompt">root# </code><strong class="userinput"><code>ln -s /usr/lib/libnss_winbind.so /usr/lib/libnss_winbind.so.1</code></strong>
+<code class="prompt">root# </code><strong class="userinput"><code>ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.1</code></strong>
+<code class="prompt">root# </code><strong class="userinput"><code>ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.2</code></strong>
+</pre><p>
+</p><p>
+<a class="indexterm" name="id2622013"></a>
+As root, edit <code class="filename">/etc/nsswitch.conf</code> to
+allow user and group entries to be visible from the <span class="application">winbindd</span>
+daemon. My <code class="filename">/etc/nsswitch.conf</code> file looked like
+this after editing:
+</p><pre class="programlisting">
+passwd: files winbind
+shadow: files
+group: files winbind
+</pre><p>
+<a class="indexterm" name="id2622049"></a>
+<a class="indexterm" name="id2622056"></a>
+<a class="indexterm" name="id2622062"></a>
+<a class="indexterm" name="id2622069"></a>
+<a class="indexterm" name="id2622076"></a>
+The libraries needed by the <span><strong class="command">winbindd</strong></span> daemon will be automatically
+entered into the <span><strong class="command">ldconfig</strong></span> cache the next time
+your system reboots, but it is faster (and you do not need to reboot) if you do it manually:
+</p><pre class="screen">
+<code class="prompt">root# </code><strong class="userinput"><code>/sbin/ldconfig -v | grep winbind</code></strong>
+</pre><p>
+This makes <code class="filename">libnss_winbind</code> available to winbindd and reports the current
+search path that is used by the dynamic link loader. The use of the <span><strong class="command">grep</strong></span>
+filters the output of the <span><strong class="command">ldconfig</strong></span> command so that we may see proof that
+this library is indeed recognized by the dynamic link loader.
+</p><p>
+<a class="indexterm" name="id2622140"></a>
+<a class="indexterm" name="id2622147"></a>
+<a class="indexterm" name="id2622154"></a>
+<a class="indexterm" name="id2622161"></a>
+<a class="indexterm" name="id2622168"></a>
+The Sun Solaris dynamic link loader management tool is called <span><strong class="command">crle</strong></span>. The
+use of this tool is necessary to instruct the dynamic link loader to search directories that
+contain library files that were not supplied as part of the original operating system platform.
+The following example shows how to use this tool to add the directory <code class="filename">/usr/local/lib</code>
+to the dynamic link loader's search path:
+</p><pre class="screen">
+<code class="prompt">root# </code> crle -u -l /usr/lib:/usr/local/lib
+</pre><p>
+When executed without arguments, <span><strong class="command">crle</strong></span> reports the current dynamic
+link loader configuration. This is demonstrated here:
+</p><pre class="screen">
+<code class="prompt">root# </code> crle
+
+Configuration file [version 4]: /var/ld/ld.config
+ Default Library Path (ELF): /lib:/usr/lib:/usr/local/lib
+ Trusted Directories (ELF): /lib/secure:/usr/lib/secure (system default)
+
+Command line:
+ crle -c /var/ld/ld.config -l /lib:/usr/lib:/usr/local/lib
+</pre><p>
+From this it is apparent that the <code class="filename">/usr/local/lib</code> directory is included
+in the search dynamic link libraries in order to satisfy object module dependencies.
+</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2622240"></a>NSS Winbind on AIX</h4></div></div></div><p>(This section is only for those running AIX.)</p><p>
+<a class="indexterm" name="id2622252"></a>
+<a class="indexterm" name="id2622258"></a>
+<a class="indexterm" name="id2622265"></a>
+<a class="indexterm" name="id2622272"></a>
+<a class="indexterm" name="id2622279"></a>
+<a class="indexterm" name="id2622286"></a>
+The Winbind AIX identification module gets built as <code class="filename">libnss_winbind.so</code> in the
+nsswitch directory of the Samba source. This file can be copied to <code class="filename">/usr/lib/security</code>,
+and the AIX naming convention would indicate that it should be named WINBIND. A stanza like the following:
+</p><pre class="programlisting">
+WINBIND:
+ program = /usr/lib/security/WINBIND
+ options = authonly
+</pre><p>
+can then be added to <code class="filename">/usr/lib/security/methods.cfg</code>. This module only supports
+identification, but there have been reports of success using the standard Winbind PAM module for
+authentication. Use caution configuring loadable authentication modules, since misconfiguration can make
+it impossible to log on to the system. Information regarding the AIX authentication module API can
+be found in the “<span class="quote">Kernel Extensions and Device Support Programming Concepts for AIX</span>” document that
+describes the <a href="http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixprggd/kernextc/sec_load_mod.htm" target="_top">
+Loadable Authentication Module Programming Interface</a> for AIX. Further information on administering the modules
+can be found in the <a href="http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/baseadmn/iandaadmin.htm" target="_top">System
+Management Guide: Operating System and Devices.</a>
+</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2622353"></a>Configure smb.conf</h4></div></div></div><p>
+<a class="indexterm" name="id2622361"></a>
+<a class="indexterm" name="id2622368"></a>
+<a class="indexterm" name="id2622375"></a>
+Several parameters are needed in the <code class="filename">smb.conf</code> file to control the behavior of <span class="application">winbindd</span>. These
+are described in more detail in the <a href="winbindd.8.html"><span class="citerefentry"><span class="refentrytitle">winbindd</span>(8)</span></a> man page. My <code class="filename">smb.conf</code> file, as shown in <a href="winbind.html#winbindcfg" title="Example 23.1. smb.conf for Winbind Setup">the smb.conf for Winbind Setup</a>, was modified to include the necessary entries in the [global] section.
+</p><div class="example"><a name="winbindcfg"></a><p class="title"><b>Example 23.1. smb.conf for Winbind Setup</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><em class="parameter"><code>[global]</code></em></td></tr><tr><td># separate domain and username with '\', like DOMAIN\username</td></tr><tr><td><a class="indexterm" name="id2622448"></a><em class="parameter"><code>winbind separator = \</code></em></td></tr><tr><td># use uids from 10000 to 20000 for domain users</td></tr><tr><td><a class="indexterm" name="id2622465"></a><em class="parameter"><code>idmap uid = 10000-20000</code></em></td></tr><tr><td># use gids from 10000 to 20000 for domain groups</td></tr><tr><td><a class="indexterm" name="id2622482"></a><em class="parameter"><code>idmap gid = 10000-20000</code></em></td></tr><tr><td># allow enumeration of winbind users and groups</td></tr><tr><td><a class="indexterm" name="id2622499"></a><em class="parameter"><code>winbind enum users = yes</code></em></td></tr><tr><td><a class="indexterm" name="id2622512"></a><em class="parameter"><code>winbind enum groups = yes</code></em></td></tr><tr><td># give winbind users a real shell (only needed if they have telnet access)</td></tr><tr><td><a class="indexterm" name="id2622529"></a><em class="parameter"><code>template homedir = /home/winnt/%D/%U</code></em></td></tr><tr><td><a class="indexterm" name="id2622543"></a><em class="parameter"><code>template shell = /bin/bash</code></em></td></tr></table></div></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2622558"></a>Join the Samba Server to the PDC Domain</h4></div></div></div><p>
+<a class="indexterm" name="id2622566"></a>
+<a class="indexterm" name="id2622573"></a>
+<a class="indexterm" name="id2622579"></a>
+All machines that will participate in domain security should be members of
+the domain. This applies also to the PDC and all BDCs.
+</p><p>
+<a class="indexterm" name="id2622591"></a>
+<a class="indexterm" name="id2622598"></a>
+<a class="indexterm" name="id2622605"></a>
+<a class="indexterm" name="id2622616"></a>
+<a class="indexterm" name="id2622623"></a>
+<a class="indexterm" name="id2622630"></a>
+<a class="indexterm" name="id2622636"></a>
+<a class="indexterm" name="id2622643"></a>
+<a class="indexterm" name="id2622650"></a>
+The process of joining a domain requires the use of the <span><strong class="command">net rpc join</strong></span>
+command. This process communicates with the domain controller it will register with
+(usually the PDC) via MS DCE RPC. This means, of course, that the <span><strong class="command">smbd</strong></span>
+process must be running on the target domain controller. It is therefore necessary to temporarily
+start Samba on a PDC so that it can join its own domain.
+</p><p>
+<a class="indexterm" name="id2622678"></a>
+<a class="indexterm" name="id2622684"></a>
+<a class="indexterm" name="id2622692"></a>
+Enter the following command to make the Samba server join the
+domain, where <em class="replaceable"><code>PDC</code></em> is the name of
+your PDC and <em class="replaceable"><code>Administrator</code></em> is
+a domain user who has administrative privileges in the domain.
+</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+<a class="indexterm" name="id2622713"></a>
+<a class="indexterm" name="id2622720"></a>
+<a class="indexterm" name="id2622726"></a>
+<a class="indexterm" name="id2622733"></a>
+Before attempting to join a machine to the domain, verify that Samba is running
+on the target domain controller (usually PDC) and that it is capable of being reached via ports
+137/udp, 135/tcp, 139/tcp, and 445/tcp (if Samba or Windows Server 2Kx).
+</p></div><p>
+<a class="indexterm" name="id2622748"></a>
+The use of the <span><strong class="command">net rpc join</strong></span> facility is shown here:
+</p><pre class="screen">
+<code class="prompt">root# </code><strong class="userinput"><code>/usr/local/samba/bin/net rpc join -S PDC -U Administrator</code></strong>
+</pre><p>
+The proper response to the command should be “<span class="quote">Joined the domain
+<em class="replaceable"><code>DOMAIN</code></em></span>” where <em class="replaceable"><code>DOMAIN</code></em>
+is your domain name.
+</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2622796"></a>Starting and Testing the <span><strong class="command">winbindd</strong></span> Daemon</h4></div></div></div><p>
+<a class="indexterm" name="id2622810"></a>
+<a class="indexterm" name="id2622816"></a>
+<a class="indexterm" name="id2622823"></a>
+Eventually, you will want to modify your Samba startup script to
+automatically invoke the winbindd daemon when the other parts of
+Samba start, but it is possible to test out just the Winbind
+portion first. To start up Winbind services, enter the following
+command as root:
+</p><pre class="screen">
+<code class="prompt">root# </code><strong class="userinput"><code>/usr/local/samba/sbin/winbindd</code></strong>
+</pre><p>
+Use the appropriate path to the location of the <span><strong class="command">winbindd</strong></span> executable file.
+</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+<a class="indexterm" name="id2622863"></a>
+<a class="indexterm" name="id2622870"></a>
+The command to start up Winbind services assumes that Samba has been installed in the <code class="filename">/usr/local/samba</code>
+directory tree. You may need to search for the location of Samba files if this is not the
+location of <span><strong class="command">winbindd</strong></span> on your system.
+</p></div><p>
+<a class="indexterm" name="id2622895"></a>
+<a class="indexterm" name="id2622902"></a>
+Winbindd can now also run in “<span class="quote">dual daemon mode</span>”. This will make it
+run as two processes. The first will answer all requests from the cache,
+thus making responses to clients faster. The other will
+update the cache for the query to which the first has just responded.
+The advantage of this is that responses stay accurate and are faster.
+You can enable dual daemon mode by adding <code class="option">-B</code> to the command line:
+</p><pre class="screen">
+<code class="prompt">root# </code><strong class="userinput"><code>/usr/local/samba/sbin/winbindd -B</code></strong>
+</pre><p>
+</p><p>
+<a class="indexterm" name="id2622942"></a>
+<a class="indexterm" name="id2622949"></a>
+I'm always paranoid and like to make sure the daemon is really running.
+</p><pre class="screen">
+<code class="prompt">root# </code><strong class="userinput"><code>ps -ae | grep winbindd</code></strong>
+</pre><p>
+</p><p>
+<a class="indexterm" name="id2622977"></a>
+This command should produce output like the following if the daemon is running.
+</p><pre class="screen">
+3025 ? 00:00:00 winbindd
+</pre><p>
+</p><p>
+<a class="indexterm" name="id2622994"></a>
+<a class="indexterm" name="id2623001"></a>
+Now, for the real test, try to get some information about the users on your PDC:
+</p><pre class="screen">
+<code class="prompt">root# </code><strong class="userinput"><code>/usr/local/samba/bin/wbinfo -u</code></strong>
+</pre><p>
+This should echo back a list of users on your Windows users on
+your PDC. For example, I get the following response:
+</p><pre class="screen">
+CEO\Administrator
+CEO\burdell
+CEO\Guest
+CEO\jt-ad
+CEO\krbtgt
+CEO\TsInternetUser
+</pre><p>
+Obviously, I have named my domain “<span class="quote">CEO</span>” and my <a class="indexterm" name="id2623039"></a>winbind separator is “<span class="quote">\</span>”.
+</p><p>
+<a class="indexterm" name="id2623053"></a>
+<a class="indexterm" name="id2623060"></a>
+You can do the same sort of thing to get group information from the PDC:
+</p><pre class="screen">
+<code class="prompt">root# </code><strong class="userinput"><code>/usr/local/samba/bin/wbinfo -g</code></strong>
+CEO\Domain Admins
+CEO\Domain Users
+CEO\Domain Guests
+CEO\Domain Computers
+CEO\Domain Controllers
+CEO\Cert Publishers
+CEO\Schema Admins
+CEO\Enterprise Admins
+CEO\Group Policy Creator Owners
+</pre><p>
+<a class="indexterm" name="id2623089"></a>
+<a class="indexterm" name="id2623096"></a>
+<a class="indexterm" name="id2623103"></a>
+<a class="indexterm" name="id2623110"></a>
+<a class="indexterm" name="id2623116"></a>
+<a class="indexterm" name="id2623123"></a>
+<a class="indexterm" name="id2623130"></a>
+The function <span><strong class="command">getent</strong></span> can now be used to get unified
+lists of both local and PDC users and groups. Try the following command:
+</p><pre class="screen">
+<code class="prompt">root# </code><strong class="userinput"><code>getent passwd</code></strong>
+</pre><p>
+You should get a list that looks like your <code class="filename">/etc/passwd</code>
+list followed by the domain users with their new UIDs, GIDs, home
+directories, and default shells.
+</p><p>
+The same thing can be done for groups with the command:
+</p><pre class="screen">
+<code class="prompt">root# </code><strong class="userinput"><code>getent group</code></strong>
+</pre><p>
+</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2623192"></a>Fix the init.d Startup Scripts</h4></div></div></div><div class="sect4" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2623198"></a>Linux</h5></div></div></div><p>
+<a class="indexterm" name="id2623205"></a>
+<a class="indexterm" name="id2623212"></a>
+<a class="indexterm" name="id2623219"></a>
+<a class="indexterm" name="id2623226"></a>
+<a class="indexterm" name="id2623233"></a>
+<a class="indexterm" name="id2623240"></a>
+<a class="indexterm" name="id2623247"></a>
+<a class="indexterm" name="id2623252"></a>
+<a class="indexterm" name="id2623258"></a>
+The <span class="application">winbindd</span> daemon needs to start up after the <span class="application">smbd</span> and <span class="application">nmbd</span> daemons are running.
+To accomplish this task, you need to modify the startup scripts of your system.
+They are located at <code class="filename">/etc/init.d/smb</code> in Red Hat Linux and in
+<code class="filename">/etc/init.d/samba</code> in Debian Linux. Edit your
+script to add commands to invoke this daemon in the proper sequence. My
+startup script starts up <span class="application">smbd</span>, <span class="application">nmbd</span>, and <span class="application">winbindd</span> from the
+<code class="filename">/usr/local/samba/bin</code> directory directly. The <span><strong class="command">start</strong></span>
+function in the script looks like this:
+</p><pre class="programlisting">
+start() {
+ KIND="SMB"
+ echo -n $"Starting $KIND services: "
+ daemon /usr/local/samba/bin/smbd $SMBDOPTIONS
+ RETVAL=$?
+ echo
+ KIND="NMB"
+ echo -n $"Starting $KIND services: "
+ daemon /usr/local/samba/bin/nmbd $NMBDOPTIONS
+ RETVAL2=$?
+ echo
+ KIND="Winbind"
+ echo -n $"Starting $KIND services: "
+ daemon /usr/local/samba/sbin/winbindd
+ RETVAL3=$?
+ echo
+ [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 -a $RETVAL3 -eq 0 ] && \
+ touch /var/lock/subsys/smb || RETVAL=1
+ return $RETVAL
+}
+</pre><p>If you would like to run winbindd in dual daemon mode, replace
+the line:
+</p><pre class="programlisting">
+ daemon /usr/local/samba/sbin/winbindd
+</pre><p>
+
+in the example above with:
+
+</p><pre class="programlisting">
+ daemon /usr/local/samba/sbin/winbindd -B
+</pre><p>.
+</p><p>
+The <span><strong class="command">stop</strong></span> function has a corresponding entry to shut down the
+services and looks like this:
+</p><pre class="programlisting">
+stop() {
+ KIND="SMB"
+ echo -n $"Shutting down $KIND services: "
+ killproc smbd
+ RETVAL=$?
+ echo
+ KIND="NMB"
+ echo -n $"Shutting down $KIND services: "
+ killproc nmbd
+ RETVAL2=$?
+ echo
+ KIND="Winbind"
+ echo -n $"Shutting down $KIND services: "
+ killproc winbindd
+ RETVAL3=$?
+ [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 -a $RETVAL3 -eq 0 ] && \
+ rm -f /var/lock/subsys/smb
+ echo ""
+ return $RETVAL
+}
+</pre></div><div class="sect4" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2623404"></a>Solaris</h5></div></div></div><p>
+Winbind does not work on Solaris 9; see <a href="Portability.html#winbind-solaris9" title="Winbind on Solaris 9">Winbind on Solaris 9 section</a>
+for details.
+</p><p>
+<a class="indexterm" name="id2623425"></a>
+<a class="indexterm" name="id2623432"></a>
+<a class="indexterm" name="id2623439"></a>
+<a class="indexterm" name="id2623446"></a>
+<a class="indexterm" name="id2623452"></a>
+<a class="indexterm" name="id2623459"></a>
+On Solaris, you need to modify the <code class="filename">/etc/init.d/samba.server</code> startup script. It
+usually only starts smbd and nmbd but should now start winbindd, too. If you have Samba installed in
+<code class="filename">/usr/local/samba/bin</code>, the file could contains something like this:
+</p><p>
+ </p><pre class="programlisting">
+ ##
+ ## samba.server
+ ##
+
+ if [ ! -d /usr/bin ]
+ then # /usr not mounted
+ exit
+ fi
+
+ killproc() { # kill the named process(es)
+ pid=`/usr/bin/ps -e |
+ /usr/bin/grep -w $1 |
+ /usr/bin/sed -e 's/^ *//' -e 's/ .*//'`
+ [ "$pid" != "" ] && kill $pid
+ }
+
+ # Start/stop processes required for Samba server
+
+ case "$1" in
+
+ 'start')
+ #
+ # Edit these lines to suit your installation (paths, workgroup, host)
+ #
+ echo Starting SMBD
+ /usr/local/samba/bin/smbd -D -s \
+ /usr/local/samba/smb.conf
+
+ echo Starting NMBD
+ /usr/local/samba/bin/nmbd -D -l \
+ /usr/local/samba/var/log -s /usr/local/samba/smb.conf
+
+ echo Starting Winbind Daemon
+ /usr/local/samba/sbin/winbindd
+ ;;
+
+ 'stop')
+ killproc nmbd
+ killproc smbd
+ killproc winbindd
+ ;;
+
+ *)
+ echo "Usage: /etc/init.d/samba.server { start | stop }"
+ ;;
+ esac
+</pre><p>
+Again, if you would like to run Samba in dual daemon mode, replace:
+</p><pre class="programlisting">
+/usr/local/samba/sbin/winbindd
+</pre><p>
+in the script above with:
+</p><pre class="programlisting">
+/usr/local/samba/sbin/winbindd -B
+</pre><p>
+</p></div><div class="sect4" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2623548"></a>Restarting</h5></div></div></div><p>
+<a class="indexterm" name="id2623555"></a>
+<a class="indexterm" name="id2623562"></a>
+If you restart the <span class="application">smbd</span>, <span class="application">nmbd</span>, and <span class="application">winbindd</span> daemons at this point, you
+should be able to connect to the Samba server as a domain member just as
+if you were a local user.
+</p></div></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2623592"></a>Configure Winbind and PAM</h4></div></div></div><p>
+<a class="indexterm" name="id2623600"></a>
+<a class="indexterm" name="id2623607"></a>
+<a class="indexterm" name="id2623614"></a>
+<a class="indexterm" name="id2623621"></a>
+If you have made it this far, you know that <span><strong class="command">winbindd</strong></span> and Samba are working
+together. If you want to use Winbind to provide authentication for other
+services, keep reading. The PAM configuration files need to be altered in
+this step. (Did you remember to make backups of your original
+<code class="filename">/etc/pam.d</code> files? If not, do it now.)
+</p><p>
+<a class="indexterm" name="id2623648"></a>
+<a class="indexterm" name="id2623654"></a>
+<a class="indexterm" name="id2623661"></a>
+<a class="indexterm" name="id2623668"></a>
+<a class="indexterm" name="id2623675"></a>
+<a class="indexterm" name="id2623682"></a>
+You will need a PAM module to use winbindd with these other services. This
+module will be compiled in the <code class="filename">../source/nsswitch</code> directory
+by invoking the command:
+</p><pre class="screen">
+<code class="prompt">root# </code><strong class="userinput"><code>make nsswitch/pam_winbind.so</code></strong>
+</pre><p>
+from the <code class="filename">../source</code> directory. The
+<code class="filename">pam_winbind.so</code> file should be copied to the location of
+your other PAM security modules. On my Red Hat system, this was the
+<code class="filename">/lib/security</code> directory. On Solaris, the PAM security
+modules reside in <code class="filename">/usr/lib/security</code>.
+</p><pre class="screen">
+<code class="prompt">root# </code><strong class="userinput"><code>cp ../samba/source/nsswitch/pam_winbind.so /lib/security</code></strong>
+</pre><p>
+</p><div class="sect4" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2623759"></a>Linux/FreeBSD-Specific PAM Configuration</h5></div></div></div><p>
+<a class="indexterm" name="id2623767"></a>
+The <code class="filename">/etc/pam.d/samba</code> file does not need to be changed. I
+just left this file as it was:
+</p><pre class="programlisting">
+auth required /lib/security/pam_stack.so service=system-auth
+account required /lib/security/pam_stack.so service=system-auth
+</pre><p>
+<a class="indexterm" name="id2623792"></a>
+<a class="indexterm" name="id2623798"></a>
+<a class="indexterm" name="id2623805"></a>
+<a class="indexterm" name="id2623812"></a>
+<a class="indexterm" name="id2623819"></a>
+<a class="indexterm" name="id2623826"></a>
+<a class="indexterm" name="id2623833"></a>
+<a class="indexterm" name="id2623840"></a>
+<a class="indexterm" name="id2623847"></a>
+The other services that I modified to allow the use of Winbind
+as an authentication service were the normal login on the console (or a terminal
+session), telnet logins, and ftp service. In order to enable these
+services, you may first need to change the entries in
+<code class="filename">/etc/xinetd.d</code> (or <code class="filename">/etc/inetd.conf</code>).
+Red Hat Linux 7.1 and later uses the new xinetd.d structure, in this case you need
+to change the lines in <code class="filename">/etc/xinetd.d/telnet</code>
+and <code class="filename">/etc/xinetd.d/wu-ftp</code> from
+</p><pre class="programlisting">
+ enable = no
+</pre><p>
+to
+</p><pre class="programlisting">
+ enable = yes
+</pre><p>
+<a class="indexterm" name="id2623899"></a>
+<a class="indexterm" name="id2623906"></a>
+<a class="indexterm" name="id2623913"></a>
+For ftp services to work properly, you will also need to either
+have individual directories for the domain users already present on
+the server or change the home directory template to a general
+directory for all domain users. These can be easily set using
+the <code class="filename">smb.conf</code> global entry
+<a class="indexterm" name="id2623931"></a>template homedir.
+</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+<a class="indexterm" name="id2623942"></a>
+The directory in <a class="indexterm" name="id2623950"></a>template homedir is not created automatically! Use pam_mkhomedir or
+pre-create the directories of users to make sure users can log in on UNIX with their own home directory.
+</p></div><p>
+<a class="indexterm" name="id2623963"></a>
+<a class="indexterm" name="id2623970"></a>
+<a class="indexterm" name="id2623977"></a>
+The <code class="filename">/etc/pam.d/ftp</code> file can be changed
+to allow Winbind ftp access in a manner similar to the
+samba file. My <code class="filename">/etc/pam.d/ftp</code> file was
+changed to look like this:
+</p><pre class="programlisting">
+auth required /lib/security/pam_listfile.so item=user sense=deny \
+ file=/etc/ftpusers onerr=succeed
+auth sufficient /lib/security/pam_winbind.so
+auth required /lib/security/pam_stack.so service=system-auth
+auth required /lib/security/pam_shells.so
+account sufficient /lib/security/pam_winbind.so
+account required /lib/security/pam_stack.so service=system-auth
+session required /lib/security/pam_stack.so service=system-auth
+</pre><p>
+<a class="indexterm" name="id2624014"></a>
+The <code class="filename">/etc/pam.d/login</code> file can be changed in nearly the
+same way. It now looks like this:
+</p><pre class="programlisting">
+auth required /lib/security/pam_securetty.so
+auth sufficient /lib/security/pam_winbind.so
+auth sufficient /lib/security/pam_unix.so use_first_pass
+auth required /lib/security/pam_stack.so service=system-auth
+auth required /lib/security/pam_nologin.so
+account sufficient /lib/security/pam_winbind.so
+account required /lib/security/pam_stack.so service=system-auth
+password required /lib/security/pam_stack.so service=system-auth
+session required /lib/security/pam_stack.so service=system-auth
+session optional /lib/security/pam_console.so
+</pre><p>
+<a class="indexterm" name="id2624044"></a>
+<a class="indexterm" name="id2624051"></a>
+<a class="indexterm" name="id2624058"></a>
+In this case, I added the </p><pre class="programlisting">auth sufficient /lib/security/pam_winbind.so</pre><p>
+lines as before, but also added the </p><pre class="programlisting">required pam_securetty.so</pre><p>
+above it to disallow root logins over the network. I also added a
+</p><pre class="programlisting">sufficient /lib/security/pam_unix.so use_first_pass</pre><p>
+line after the <span><strong class="command">winbind.so</strong></span> line to get rid of annoying
+double prompts for passwords.
+</p></div><div class="sect4" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2624096"></a>Solaris-Specific Configuration</h5></div></div></div><p>
+<a class="indexterm" name="id2624105"></a>
+<a class="indexterm" name="id2624112"></a>
+The <code class="filename">/etc/pam.conf</code> needs to be changed. I changed this file so my Domain
+users can log on both locally as well as with telnet. The following are the changes
+that I made. You can customize the <code class="filename">pam.conf</code> file as per your requirements, but
+be sure of those changes because in the worst case it will leave your system
+nearly impossible to boot.
+</p><pre class="programlisting">
+#
+#ident "@(#)pam.conf 1.14 99/09/16 SMI"
+#
+# Copyright (c) 1996-1999, Sun Microsystems, Inc.
+# All Rights Reserved.
+#
+# PAM configuration
+#
+# Authentication management
+#
+login auth required /usr/lib/security/pam_winbind.so
+login auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass
+login auth required /usr/lib/security/$ISA/pam_dial_auth.so.1 try_first_pass
+#
+rlogin auth sufficient /usr/lib/security/pam_winbind.so
+rlogin auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1
+rlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass
+#
+dtlogin auth sufficient /usr/lib/security/pam_winbind.so
+dtlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass
+#
+rsh auth required /usr/lib/security/$ISA/pam_rhosts_auth.so.1
+other auth sufficient /usr/lib/security/pam_winbind.so
+other auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass
+#
+# Account management
+#
+login account sufficient /usr/lib/security/pam_winbind.so
+login account requisite /usr/lib/security/$ISA/pam_roles.so.1
+login account required /usr/lib/security/$ISA/pam_unix.so.1
+#
+dtlogin account sufficient /usr/lib/security/pam_winbind.so
+dtlogin account requisite /usr/lib/security/$ISA/pam_roles.so.1
+dtlogin account required /usr/lib/security/$ISA/pam_unix.so.1
+#
+other account sufficient /usr/lib/security/pam_winbind.so
+other account requisite /usr/lib/security/$ISA/pam_roles.so.1
+other account required /usr/lib/security/$ISA/pam_unix.so.1
+#
+# Session management
+#
+other session required /usr/lib/security/$ISA/pam_unix.so.1
+#
+# Password management
+#
+#other password sufficient /usr/lib/security/pam_winbind.so
+other password required /usr/lib/security/$ISA/pam_unix.so.1
+dtsession auth required /usr/lib/security/$ISA/pam_unix.so.1
+#
+# Support for Kerberos V5 authentication (uncomment to use Kerberos)
+#
+#rlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
+#login auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
+#dtlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
+#other auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
+#dtlogin account optional /usr/lib/security/$ISA/pam_krb5.so.1
+#other account optional /usr/lib/security/$ISA/pam_krb5.so.1
+#other session optional /usr/lib/security/$ISA/pam_krb5.so.1
+#other password optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
+</pre><p>
+<a class="indexterm" name="id2624183"></a>
+I also added a <em class="parameter"><code>try_first_pass</code></em> line after the <code class="filename">winbind.so</code>
+line to get rid of annoying double prompts for passwords.
+</p><p>
+Now restart your Samba and try connecting through your application that you
+configured in the pam.conf.
+</p></div></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2624214"></a>Conclusion</h2></div></div></div><p>
+<a class="indexterm" name="id2624221"></a>
+<a class="indexterm" name="id2624228"></a>
+<a class="indexterm" name="id2624235"></a>
+<a class="indexterm" name="id2624241"></a>
+<a class="indexterm" name="id2624248"></a>
+The Winbind system, through the use of the NSS, PAMs, and appropriate
+Microsoft RPC calls, have allowed us to provide seamless
+integration of Microsoft Windows NT domain users on a
+UNIX system. The result is a great reduction in the administrative
+cost of running a mixed UNIX and NT network.</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2624262"></a>Common Errors</h2></div></div></div><p>Winbind has a number of limitations in its current
+ released version that we hope to overcome in future
+ releases:</p><div class="itemizedlist"><ul type="disc"><li><p>Winbind is currently only available for
+ the Linux, Solaris, AIX, and IRIX operating systems, although ports to other operating
+ systems are certainly possible. For such ports to be feasible,
+ we require the C library of the target operating system to
+ support the NSS and PAM
+ systems. This is becoming more common as NSS and
+ PAM gain support among UNIX vendors.</p></li><li><p>The mappings of Windows NT RIDs to UNIX IDs
+ is not made algorithmically and depends on the order in which
+ unmapped users or groups are seen by Winbind. It may be difficult
+ to recover the mappings of RID to UNIX ID if the file
+ containing this information is corrupted or destroyed.</p></li><li><p>Currently the Winbind PAM module does not take
+ into account possible workstation and logon time restrictions
+ that may be set for Windows NT users; this is
+ instead up to the PDC to enforce.</p></li></ul></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2624305"></a>NSCD Problem Warning</h3></div></div></div><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>
+ Do not under any circumstances run <span><strong class="command">nscd</strong></span> on any system
+ on which <span><strong class="command">winbindd</strong></span> is running.
+ </p></div><p>
+ If <span><strong class="command">nscd</strong></span> is running on the UNIX/Linux system, then
+ even though NSSWITCH is correctly configured, it will not be possible to resolve
+ domain users and groups for file and directory controls.
+ </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2624342"></a>Winbind Is Not Resolving Users and Groups</h3></div></div></div><p>“<span class="quote">
+ My <code class="filename">smb.conf</code> file is correctly configured. I have specified
+ <a class="indexterm" name="id2624358"></a>idmap uid = 12000,
+ and <a class="indexterm" name="id2624366"></a>idmap gid = 3000-3500
+ and <span><strong class="command">winbind</strong></span> is running. When I do the following, it all works fine.
+ </span>”</p><pre class="screen">
+<code class="prompt">root# </code><strong class="userinput"><code>wbinfo -u</code></strong>
+MIDEARTH\maryo
+MIDEARTH\jackb
+MIDEARTH\ameds
+...
+MIDEARTH\root
+
+<code class="prompt">root# </code><strong class="userinput"><code>wbinfo -g</code></strong>
+MIDEARTH\Domain Users
+MIDEARTH\Domain Admins
+MIDEARTH\Domain Guests
+...
+MIDEARTH\Accounts
+
+<code class="prompt">root# </code><strong class="userinput"><code>getent passwd</code></strong>
+root:x:0:0:root:/root:/bin/bash
+bin:x:1:1:bin:/bin:/bin/bash
+...
+maryo:x:15000:15003:Mary Orville:/home/MIDEARTH/maryo:/bin/false
+</pre><p>“<span class="quote">
+But the following command just fails:
+</span>”
+</p><pre class="screen">
+<code class="prompt">root# </code><strong class="userinput"><code>chown maryo a_file</code></strong>
+chown: `maryo': invalid user
+</pre><p>
+“<span class="quote">
+This is driving me nuts! What can be wrong?
+</span>”</p><p>
+Same problem as the one above.
+Your system is likely running <span><strong class="command">nscd</strong></span>, the name service
+caching daemon. Shut it down, do not restart it! You will find your problem resolved.
+</p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="VFS.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="optional.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="AdvancedNetworkManagement.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 22. Stackable VFS modules </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 24. Advanced Network Management</td></tr></table></div></body></html>
projects / samba / blobdiff