diff options
Diffstat (limited to 'docs/htmldocs/Samba3-HOWTO/winbind.html')
| -rw-r--r-- | docs/htmldocs/Samba3-HOWTO/winbind.html | 1101 |
1 files changed, 1101 insertions, 0 deletions
diff --git a/docs/htmldocs/Samba3-HOWTO/winbind.html b/docs/htmldocs/Samba3-HOWTO/winbind.html new file mode 100644 index 0000000000..dbda513cee --- /dev/null +++ b/docs/htmldocs/Samba3-HOWTO/winbind.html @@ -0,0 +1,1101 @@ +<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 24. Winbind: Use of Domain Accounts</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.71.0"><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 23. Stackable VFS modules"><link rel="next" href="AdvancedNetworkManagement.html" title="Chapter 25. 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 24. 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 24. 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#id411256">Features and Benefits</a></span></dt><dt><span class="sect1"><a href="winbind.html#id411579">Introduction</a></span></dt><dt><span class="sect1"><a href="winbind.html#id411657">What Winbind Provides</a></span></dt><dd><dl><dt><span class="sect2"><a href="winbind.html#id411796">Target Uses</a></span></dt><dt><span class="sect2"><a href="winbind.html#id411839">Handling of Foreign SIDs</a></span></dt></dl></dd><dt><span class="sect1"><a href="winbind.html#id411950">How Winbind Works</a></span></dt><dd><dl><dt><span class="sect2"><a href="winbind.html#id411998">Microsoft Remote Procedure Calls</a></span></dt><dt><span class="sect2"><a href="winbind.html#id412076">Microsoft Active Directory Services</a></span></dt><dt><span class="sect2"><a href="winbind.html#id412120">Name Service Switch</a></span></dt><dt><span class="sect2"><a href="winbind.html#id412336">Pluggable Authentication Modules</a></span></dt><dt><span class="sect2"><a href="winbind.html#id412481">User and Group ID Allocation</a></span></dt><dt><span class="sect2"><a href="winbind.html#id412549">Result Caching</a></span></dt></dl></dd><dt><span class="sect1"><a href="winbind.html#id412600">Installation and Configuration</a></span></dt><dd><dl><dt><span class="sect2"><a href="winbind.html#id412605">Introduction</a></span></dt><dt><span class="sect2"><a href="winbind.html#id412712">Requirements</a></span></dt><dt><span class="sect2"><a href="winbind.html#id412857">Testing Things Out</a></span></dt></dl></dd><dt><span class="sect1"><a href="winbind.html#id415146">Conclusion</a></span></dt><dt><span class="sect1"><a href="winbind.html#id415192">Common Errors</a></span></dt><dd><dl><dt><span class="sect2"><a href="winbind.html#id415226">NSCD Problem Warning</a></span></dt><dt><span class="sect2"><a href="winbind.html#id415261">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="id411256"></a>Features and Benefits</h2></div></div></div><p> +<a class="indexterm" name="id411264"></a> +<a class="indexterm" name="id411270"></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="id411285"></a> +<a class="indexterm" name="id411292"></a> +<a class="indexterm" name="id411299"></a> +<a class="indexterm" name="id411306"></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="id411318"></a> +<a class="indexterm" name="id411327"></a> +<a class="indexterm" name="id411334"></a> +<a class="indexterm" name="id411341"></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="id411364"></a> +<a class="indexterm" name="id411371"></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="id411384"></a> +<a class="indexterm" name="id411391"></a> + Identity resolution (via NSS). This is the default when winbind is not used. + </p></li><li><p> +<a class="indexterm" name="id411402"></a> +<a class="indexterm" name="id411409"></a> +<a class="indexterm" name="id411416"></a> +<a class="indexterm" name="id411422"></a> +<a class="indexterm" name="id411429"></a> +<a class="indexterm" name="id411436"></a> +<a class="indexterm" name="id411442"></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="id411468"></a> + <a class="indexterm" name="id411475"></a> +<a class="indexterm" name="id411484"></a> +<a class="indexterm" name="id411491"></a> +<a class="indexterm" name="id411498"></a> +<a class="indexterm" name="id411504"></a> + If <code class="literal">winbindd</code> is not running, smbd (which calls <code class="literal">winbindd</code>) 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 24.1. Winbind Idmap</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/idmap_winbind_no_loop.png" width="243" alt="Winbind Idmap"></div></div></div><br class="figure-break"></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id411579"></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="id411593"></a> +<a class="indexterm" name="id411600"></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="id411638"></a> +<a class="indexterm" name="id411645"></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="id411657"></a>What Winbind Provides</h2></div></div></div><p> +<a class="indexterm" name="id411665"></a> +<a class="indexterm" name="id411672"></a> +<a class="indexterm" name="id411679"></a> +<a class="indexterm" name="id411686"></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="id411702"></a> +<a class="indexterm" name="id411709"></a> +<a class="indexterm" name="id411716"></a> +<a class="indexterm" name="id411722"></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="id411736"></a> +<a class="indexterm" name="id411743"></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="id411758"></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="id411778"></a> +<a class="indexterm" name="id411785"></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="id411796"></a>Target Uses</h3></div></div></div><p> +<a class="indexterm" name="id411804"></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="id411820"></a> +<a class="indexterm" name="id411827"></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="id411839"></a>Handling of Foreign SIDs</h3></div></div></div><p> +<a class="indexterm" name="id411847"></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="id411863"></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="id411874"></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="id411889"></a> +<a class="indexterm" name="id411895"></a> +<a class="indexterm" name="id411902"></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="id411915"></a> +<a class="indexterm" name="id411922"></a> +<a class="indexterm" name="id411928"></a> +<a class="indexterm" name="id411935"></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="id411950"></a>How Winbind Works</h2></div></div></div><p> +<a class="indexterm" name="id411958"></a> +<a class="indexterm" name="id411965"></a> +<a class="indexterm" name="id411972"></a> +<a class="indexterm" name="id411978"></a> + The Winbind system is designed around a client/server + architecture. A long-running <code class="literal">winbindd</code> 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="id411998"></a>Microsoft Remote Procedure Calls</h3></div></div></div><p> +<a class="indexterm" name="id412006"></a> +<a class="indexterm" name="id412015"></a> +<a class="indexterm" name="id412022"></a> +<a class="indexterm" name="id412028"></a> +<a class="indexterm" name="id412035"></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="id412050"></a> +<a class="indexterm" name="id412056"></a> +<a class="indexterm" name="id412063"></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="id412076"></a>Microsoft Active Directory Services</h3></div></div></div><p> +<a class="indexterm" name="id412083"></a> +<a class="indexterm" name="id412090"></a> +<a class="indexterm" name="id412097"></a> +<a class="indexterm" name="id412104"></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="id412120"></a>Name Service Switch</h3></div></div></div><p> +<a class="indexterm" name="id412127"></a> +<a class="indexterm" name="id412134"></a> +<a class="indexterm" name="id412141"></a> +<a class="indexterm" name="id412147"></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="id412162"></a> +<a class="indexterm" name="id412168"></a> +<a class="indexterm" name="id412175"></a> +<a class="indexterm" name="id412182"></a> +<a class="indexterm" name="id412188"></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="id412208"></a> +<a class="indexterm" name="id412214"></a> +<a class="indexterm" name="id412221"></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="id412252"></a> +<a class="indexterm" name="id412259"></a> +<a class="indexterm" name="id412266"></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="id412291"></a> +<a class="indexterm" name="id412297"></a> +<a class="indexterm" name="id412304"></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="id412336"></a>Pluggable Authentication Modules</h3></div></div></div><p> +<a class="indexterm" name="id412344"></a> +<a class="indexterm" name="id412351"></a> +<a class="indexterm" name="id412358"></a> +<a class="indexterm" name="id412364"></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="id412379"></a> +<a class="indexterm" name="id412386"></a> +<a class="indexterm" name="id412392"></a> +<a class="indexterm" name="id412399"></a> +<a class="indexterm" name="id412406"></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="id412422"></a> +<a class="indexterm" name="id412428"></a> +<a class="indexterm" name="id412435"></a> +<a class="indexterm" name="id412442"></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 28. 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="id412481"></a>User and Group ID Allocation</h3></div></div></div><p> +<a class="indexterm" name="id412488"></a> +<a class="indexterm" name="id412495"></a> +<a class="indexterm" name="id412502"></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="id412518"></a> +<a class="indexterm" name="id412525"></a> +<a class="indexterm" name="id412532"></a> +<a class="indexterm" name="id412539"></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="id412549"></a>Result Caching</h3></div></div></div><p> +<a class="indexterm" name="id412557"></a> +<a class="indexterm" name="id412563"></a> +<a class="indexterm" name="id412570"></a> +<a class="indexterm" name="id412577"></a> +<a class="indexterm" name="id412583"></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="id412600"></a>Installation and Configuration</h2></div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id412605"></a>Introduction</h3></div></div></div><p> +<a class="indexterm" name="id412613"></a> +<a class="indexterm" name="id412620"></a> +<a class="indexterm" name="id412626"></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="id412650"></a> +<a class="indexterm" name="id412657"></a> +<a class="indexterm" name="id412664"></a> +<a class="indexterm" name="id412670"></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="id412692"></a> +<a class="indexterm" name="id412699"></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="id412712"></a>Requirements</h3></div></div></div><p> +<a class="indexterm" name="id412720"></a> +<a class="indexterm" name="id412726"></a> +<a class="indexterm" name="id412733"></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="id412761"></a> +<a class="indexterm" name="id412768"></a> +<a class="indexterm" name="id412775"></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="id412793"></a> +<a class="indexterm" name="id412800"></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="id412818"></a> +<a class="indexterm" name="id412824"></a> +<a class="indexterm" name="id412831"></a> +<a class="indexterm" name="id412838"></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="id412857"></a>Testing Things Out</h3></div></div></div><p> +<a class="indexterm" name="id412865"></a> +<a class="indexterm" name="id412872"></a> +<a class="indexterm" name="id412878"></a> +<a class="indexterm" name="id412885"></a> +<a class="indexterm" name="id412892"></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="id412939"></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="id412953"></a> +<a class="indexterm" name="id412960"></a> +<a class="indexterm" name="id412967"></a> +<a class="indexterm" name="id412973"></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="id413009"></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="id413054"></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="id413102"></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="id413136"></a> +<a class="indexterm" name="id413143"></a> +<a class="indexterm" name="id413149"></a> +<a class="indexterm" name="id413156"></a> +<a class="indexterm" name="id413163"></a> +The libraries needed by the <code class="literal">winbindd</code> daemon will be automatically +entered into the <code class="literal">ldconfig</code> 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 <code class="literal">grep</code> +filters the output of the <code class="literal">ldconfig</code> command so that we may see proof that +this library is indeed recognized by the dynamic link loader. +</p><p> +<a class="indexterm" name="id413222"></a> +<a class="indexterm" name="id413229"></a> +<a class="indexterm" name="id413236"></a> +<a class="indexterm" name="id413243"></a> +<a class="indexterm" name="id413250"></a> +The Sun Solaris dynamic link loader management tool is called <code class="literal">crle</code>. 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, <code class="literal">crle</code> 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="id413313"></a>NSS Winbind on AIX</h4></div></div></div><p>(This section is only for those running AIX.)</p><p> +<a class="indexterm" name="id413325"></a> +<a class="indexterm" name="id413331"></a> +<a class="indexterm" name="id413338"></a> +<a class="indexterm" name="id413345"></a> +<a class="indexterm" name="id413352"></a> +<a class="indexterm" name="id413359"></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="id413415"></a>Configure smb.conf</h4></div></div></div><p> +<a class="indexterm" name="id413423"></a> +<a class="indexterm" name="id413430"></a> +<a class="indexterm" name="id413436"></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 24.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 24.1. smb.conf for Winbind Setup</b></p><div class="example-contents"><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="id413507"></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="id413523"></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="id413539"></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="id413556"></a><em class="parameter"><code>winbind enum users = yes</code></em></td></tr><tr><td><a class="indexterm" name="id413568"></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="id413585"></a><em class="parameter"><code>template homedir = /home/winnt/%D/%U</code></em></td></tr><tr><td><a class="indexterm" name="id413598"></a><em class="parameter"><code>template shell = /bin/bash</code></em></td></tr></table></div></div><br class="example-break"></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id413612"></a>Join the Samba Server to the PDC Domain</h4></div></div></div><p> +<a class="indexterm" name="id413620"></a> +<a class="indexterm" name="id413627"></a> +<a class="indexterm" name="id413634"></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="id413645"></a> +<a class="indexterm" name="id413651"></a> +<a class="indexterm" name="id413658"></a> +<a class="indexterm" name="id413669"></a> +<a class="indexterm" name="id413676"></a> +<a class="indexterm" name="id413683"></a> +<a class="indexterm" name="id413689"></a> +<a class="indexterm" name="id413696"></a> +<a class="indexterm" name="id413703"></a> +The process of joining a domain requires the use of the <code class="literal">net rpc join</code> +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 <code class="literal">smbd</code> +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="id413728"></a> +<a class="indexterm" name="id413734"></a> +<a class="indexterm" name="id413741"></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="id413761"></a> +<a class="indexterm" name="id413768"></a> +<a class="indexterm" name="id413774"></a> +<a class="indexterm" name="id413781"></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="id413793"></a> +The use of the <code class="literal">net rpc join</code> 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="id413839"></a>Starting and Testing the <code class="literal">winbindd</code> Daemon</h4></div></div></div><p> +<a class="indexterm" name="id413853"></a> +<a class="indexterm" name="id413860"></a> +<a class="indexterm" name="id413867"></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 <code class="literal">winbindd</code> 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="id413903"></a> +<a class="indexterm" name="id413910"></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 <code class="literal">winbindd</code> on your system. +</p></div><p> +<a class="indexterm" name="id413933"></a> +<a class="indexterm" name="id413940"></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="id413976"></a> +<a class="indexterm" name="id413983"></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="id414010"></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="id414026"></a> +<a class="indexterm" name="id414033"></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="id414068"></a>winbind separator is “<span class="quote">\</span>”. +</p><p> +<a class="indexterm" name="id414081"></a> +<a class="indexterm" name="id414088"></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="id414115"></a> +<a class="indexterm" name="id414122"></a> +<a class="indexterm" name="id414128"></a> +<a class="indexterm" name="id414135"></a> +<a class="indexterm" name="id414142"></a> +<a class="indexterm" name="id414148"></a> +<a class="indexterm" name="id414155"></a> +The function <code class="literal">getent</code> 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="id414214"></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="id414220"></a>Linux</h5></div></div></div><p> +<a class="indexterm" name="id414227"></a> +<a class="indexterm" name="id414234"></a> +<a class="indexterm" name="id414241"></a> +<a class="indexterm" name="id414248"></a> +<a class="indexterm" name="id414255"></a> +<a class="indexterm" name="id414261"></a> +<a class="indexterm" name="id414268"></a> +<a class="indexterm" name="id414274"></a> +<a class="indexterm" name="id414279"></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 <code class="literal">start</code> +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 <code class="literal">stop</code> 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="id414403"></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="id414422"></a> +<a class="indexterm" name="id414429"></a> +<a class="indexterm" name="id414436"></a> +<a class="indexterm" name="id414443"></a> +<a class="indexterm" name="id414450"></a> +<a class="indexterm" name="id414456"></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="id414522"></a>Restarting</h5></div></div></div><p> +<a class="indexterm" name="id414530"></a> +<a class="indexterm" name="id414537"></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="id414566"></a>Configure Winbind and PAM</h4></div></div></div><p> +<a class="indexterm" name="id414573"></a> +<a class="indexterm" name="id414580"></a> +<a class="indexterm" name="id414587"></a> +<a class="indexterm" name="id414594"></a> +If you have made it this far, you know that <code class="literal">winbindd</code> 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="id414618"></a> +<a class="indexterm" name="id414625"></a> +<a class="indexterm" name="id414631"></a> +<a class="indexterm" name="id414638"></a> +<a class="indexterm" name="id414645"></a> +<a class="indexterm" name="id414652"></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="id414724"></a>Linux/FreeBSD-Specific PAM Configuration</h5></div></div></div><p> +<a class="indexterm" name="id414732"></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="id414755"></a> +<a class="indexterm" name="id414761"></a> +<a class="indexterm" name="id414768"></a> +<a class="indexterm" name="id414775"></a> +<a class="indexterm" name="id414782"></a> +<a class="indexterm" name="id414789"></a> +<a class="indexterm" name="id414795"></a> +<a class="indexterm" name="id414802"></a> +<a class="indexterm" name="id414809"></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="id414857"></a> +<a class="indexterm" name="id414864"></a> +<a class="indexterm" name="id414870"></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="id414886"></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="id414897"></a> +The directory in <a class="indexterm" name="id414904"></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="id414916"></a> +<a class="indexterm" name="id414922"></a> +<a class="indexterm" name="id414929"></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="id414961"></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="id414985"></a> +<a class="indexterm" name="id414992"></a> +<a class="indexterm" name="id414999"></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 <code class="literal">winbind.so</code> 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="id415034"></a>Solaris-Specific Configuration</h5></div></div></div><p> +<a class="indexterm" name="id415042"></a> +<a class="indexterm" name="id415048"></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="id415117"></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="id415146"></a>Conclusion</h2></div></div></div><p> +<a class="indexterm" name="id415154"></a> +<a class="indexterm" name="id415160"></a> +<a class="indexterm" name="id415167"></a> +<a class="indexterm" name="id415174"></a> +<a class="indexterm" name="id415180"></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="id415192"></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="id415226"></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 <code class="literal">nscd</code> on any system + on which <code class="literal">winbindd</code> is running. + </p></div><p> + If <code class="literal">nscd</code> 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="id415261"></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="id415276"></a>idmap uid = 12000, + and <a class="indexterm" name="id415284"></a>idmap gid = 3000-3500 + and <code class="literal">winbind</code> 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 <code class="literal">nscd</code>, 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 23. 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 25. Advanced Network Management</td></tr></table></div></body></html> |