diff options
Diffstat (limited to 'docs/htmldocs/winbind.html')
| -rw-r--r-- | docs/htmldocs/winbind.html | 733 |
1 files changed, 0 insertions, 733 deletions
diff --git a/docs/htmldocs/winbind.html b/docs/htmldocs/winbind.html deleted file mode 100644 index b289f5141e..0000000000 --- a/docs/htmldocs/winbind.html +++ /dev/null @@ -1,733 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> -<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 21. Integrated Logon Support using Winbind</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.60.1"><link rel="home" href="index.html" title="SAMBA Project Documentation"><link rel="up" href="optional.html" title="Part III. Advanced Configuration"><link rel="previous" href="VFS.html" title="Chapter 20. Stackable VFS modules"><link rel="next" href="AdvancedNetworkManagement.html" title="Chapter 22. 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 21. Integrated Logon Support using Winbind</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 21. Integrated Logon Support using Winbind</h2></div><div><div class="authorgroup"><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><tt class="email"><<a href="mailto:tpot@samba.org">tpot@samba.org</a>></tt></p></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><tt class="email"><<a href="mailto:tridge@samba.org">tridge@samba.org</a>></tt></p></div></div></div><div class="author"><h3 class="author"><span class="firstname">Naag</span> <span class="surname">Mummaneni</span></h3><div class="affiliation"><div class="address"><p><tt class="email"><<a href="mailto:getnag@rediffmail.com">getnag@rediffmail.com</a>></tt></p></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><tt class="email"><<a href="mailto:jelmer@samba.org">jelmer@samba.org</a>></tt></p></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><tt class="email"><<a href="mailto:jht@samba.org">jht@samba.org</a>></tt></p></div></div></div></div></div><div><p class="pubdate">27 June 2002</p></div></div><div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><a href="winbind.html#id2975777">Features and Benefits</a></dt><dt><a href="winbind.html#id2975805">Introduction</a></dt><dt><a href="winbind.html#id2977838">What Winbind Provides</a></dt><dd><dl><dt><a href="winbind.html#id2977898">Target Uses</a></dt></dl></dd><dt><a href="winbind.html#id2977929">How Winbind Works</a></dt><dd><dl><dt><a href="winbind.html#id2977957">Microsoft Remote Procedure Calls</a></dt><dt><a href="winbind.html#id2977989">Microsoft Active Directory Services</a></dt><dt><a href="winbind.html#id2978012">Name Service Switch</a></dt><dt><a href="winbind.html#id2975323">Pluggable Authentication Modules</a></dt><dt><a href="winbind.html#id2975394">User and Group ID Allocation</a></dt><dt><a href="winbind.html#id2975429">Result Caching</a></dt></dl></dd><dt><a href="winbind.html#id2975457">Installation and Configuration</a></dt><dd><dl><dt><a href="winbind.html#id2975485">Introduction</a></dt><dt><a href="winbind.html#id2975560">Requirements</a></dt><dt><a href="winbind.html#id2976836">Testing Things Out</a></dt></dl></dd><dt><a href="winbind.html#id2981237">Conclusion</a></dt><dt><a href="winbind.html#id2981256">Common Errors</a></dt></dl></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2975777"></a>Features and Benefits</h2></div></div><div></div></div><p>Integration of UNIX and Microsoft Windows NT through - a unified logon has been considered a "holy grail" in heterogeneous - computing environments for a long time. We present - <span class="emphasis"><em>winbind</em></span>, a component of the Samba suite - of programs as a solution to the unified logon problem. Winbind - uses a UNIX implementation - of Microsoft RPC calls, Pluggable Authentication Modules, and the Name - Service Switch to allow Windows NT domain users to appear and operate - as UNIX users on a UNIX machine. This paper describes the winbind - system, explaining the functionality it provides, how it is configured, - and how it works internally.</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2975805"></a>Introduction</h2></div></div><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>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, as - 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>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="id2977838"></a>What Winbind Provides</h2></div></div><div></div></div><p>Winbind unifies UNIX and Windows NT account management by - allowing a UNIX box to become a full member of a NT domain. Once - this is done the UNIX box will see NT users and groups as if - they were native 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>The end result is that whenever any - program on the UNIX machine asks the operating system to lookup - 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>Users on the UNIX machine can then use NT user and group - names as they would use "native" UNIX names. They can chown files - so that 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>The only obvious indication that Winbind is being used is - that user and group names take the form DOMAIN\user and - DOMAIN\group. This is necessary as 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>Additionally, Winbind provides an authentication service - that hooks into the Pluggable Authentication Modules (PAM) system - to provide authentication via a 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="id2977898"></a>Target Uses</h3></div></div><div></div></div><p>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 a NT based organization.</p><p>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><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2977929"></a>How Winbind Works</h2></div></div><div></div></div><p>The winbind system is designed around a client/server - architecture. A long running <b class="command">winbindd</b> daemon - listens on a UNIX domain socket waiting for requests - to arrive. These requests are generated by the NSS and PAM - clients and 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="id2977957"></a>Microsoft Remote Procedure Calls</h3></div></div><div></div></div><p>Over the last few years, efforts have been underway - by various Samba Team members to decode 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 which - can be used for other purposes.</p><p>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="id2977989"></a>Microsoft Active Directory Services</h3></div></div><div></div></div><p> - Since late 2001, Samba has gained the ability to - interact with Microsoft Windows 2000 using its 'Native - Mode' 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 Win2k 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="id2978012"></a>Name Service Switch</h3></div></div><div></div></div><p>The Name Service Switch, or 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 filesystem. A networked workstation - may first attempt to resolve system information from local files, - and then consult a NIS database for user information or a DNS server - for hostname information.</p><p>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, one can enumerate the users and groups on - a UNIX machine running winbind and see all users and groups in - a NT domain plus any trusted domain as though they were local - users and groups.</p><p>The primary control file for NSS is - <tt class="filename">/etc/nsswitch.conf</tt>. - When a UNIX application makes a request to do a lookup - the C library looks in <tt class="filename">/etc/nsswitch.conf</tt> - for a line which matches the service type being requested, for - example the "passwd" service type is used when user or group names - are looked up. This config line species which implementations - of that service should be tried and in what order. If the passwd - config line is:</p><pre class="programlisting"> -passwd: files example - </pre><p>then the C library will first load a module called - <tt class="filename">/lib/libnss_files.so</tt> followed by - the module <tt class="filename">/lib/libnss_example.so</tt>. 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>This NSS interface provides a very easy way for Winbind - to hook into the operating system. All that needs to be done - is to put <tt class="filename">libnss_winbind.so</tt> in <tt class="filename">/lib/</tt> - then add "winbind" into <tt class="filename">/etc/nsswitch.conf</tt> 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="id2975323"></a>Pluggable Authentication Modules</h3></div></div><div></div></div><p>Pluggable Authentication Modules, also known as PAM, - is 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 - a NIS database to log in over the network.</p><p>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 Primary Domain - Controller. These users can also change their passwords and have - this change take effect directly on the Primary Domain Controller. - </p><p>PAM is configured by providing control files in the directory - <tt class="filename">/etc/pam.d/</tt> 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, all that needs - to be done is that the <tt class="filename">pam_winbind.so</tt> module - is copied to <tt class="filename">/lib/security/</tt> and the PAM - control files for relevant services are updated to allow - authentication via winbind. See the PAM documentation - for more details.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2975394"></a>User and Group ID Allocation</h3></div></div><div></div></div><p>When a user or group is created under Windows NT - is it allocated a numerical relative identifier (RID). This is - slightly different to UNIX which has a range of numbers that are - used to identify users, and the same range in which 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>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="id2975429"></a>Result Caching</h3></div></div><div></div></div><p>An active 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="id2975457"></a>Installation and Configuration</h2></div></div><div></div></div><p> -Many thanks to John Trostel <a href="mailto:jtrostel@snapserver.com" target="_top">jtrostel@snapserver.com</a> -for providing the HOWTO for this section. -</p><p> -This HOWTO describes how to get winbind services up and running -to control access and authenticate users on your Linux box using -the winbind services which come with SAMBA 3.0. -</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2975485"></a>Introduction</h3></div></div><div></div></div><p> -This section describes the procedures used to get winbind up and -running on a RedHat 7.1 system. Winbind is capable of providing access -and authentication control for Windows Domain users through an NT -or Win2K PDC for 'regular' services, such as telnet a nd ftp, as -well for SAMBA services. -</p><p> -This HOWTO has been written from a 'RedHat-centric' perspective, so if -you are using another distribution, you may have to modify the instructions -somewhat to fit the way your distribution works. -</p><div class="itemizedlist"><ul type="disc"><li><p> - <span class="emphasis"><em>Why should I to this?</em></span> - </p><p>This allows the SAMBA administrator to rely on the - authentication mechanisms on the NT/Win2K PDC for the authentication - of domain members. NT/Win2K 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> - This HOWTO is designed for system administrators. If you are - implementing SAMBA on a file server and wish to (fairly easily) - integrate existing NT/Win2K users from your PDC onto the - SAMBA server, this HOWTO is for you. That said, I am no NT or PAM - expert, so you may find a better or easier way to accomplish - these tasks. - </p></li></ul></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2975560"></a>Requirements</h3></div></div><div></div></div><p> -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 <tt class="filename">/etc/pam.d</tt> directory -contents!</em></span> If you haven't already made a boot disk, -<span class="emphasis"><em>MAKE ONE NOW!</em></span> -</p><p> -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 -<tt class="filename">/etc/pam.d</tt> back to the original state they were in if -you get frustrated with the way things are going. ;-) -</p><p> -The latest version of SAMBA (version 3.0 as of this writing), now -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> -To allow Domain users the ability to access SAMBA shares and -files, as well as potentially other services provided by your -SAMBA machine, PAM (pluggable authentication modules) must -be setup properly on your machine. In order to compile the -winbind modules, you should have at least the pam libraries resident -on your system. For recent RedHat systems (7.1, for instance), that -means <tt class="filename">pam-0.74-22</tt>. For best results, it is helpful to also -install the development packages in <tt class="filename">pam-devel-0.74-22</tt>. -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2976836"></a>Testing Things Out</h3></div></div><div></div></div><p> -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, you will want to make sure that you have the -standard PAM package (for RedHat) which supplies the <tt class="filename">/etc/pam.d</tt> -directory structure, including the pam modules are used by pam-aware -services, several pam libraries, and the <tt class="filename">/usr/doc</tt> -and <tt class="filename">/usr/man</tt> entries for pam. Winbind built better -in SAMBA if the pam-devel package was 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="id2976898"></a>Configure and compile SAMBA</h4></div></div><div></div></div><p> -The configuration and compilation of SAMBA is pretty straightforward. -The first three steps may not be necessary depending upon -whether or not you have previously built the Samba binaries. -</p><pre class="screen"> -<tt class="prompt">root# </tt><b class="command">autoconf</b> -<tt class="prompt">root# </tt><b class="command">make clean</b> -<tt class="prompt">root# </tt><b class="command">rm config.cache</b> -<tt class="prompt">root# </tt><b class="command">./configure</b> -<tt class="prompt">root# </tt><b class="command">make</b> -<tt class="prompt">root# </tt><b class="command">make install</b> -</pre><p> -This will, by default, install SAMBA in <tt class="filename">/usr/local/samba</tt>. -See the main SAMBA documentation if you want to install SAMBA somewhere else. -It will also build the winbindd executable and libraries. -</p></div><div xmlns:ns74="" class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2977010"></a>Configure <tt class="filename">nsswitch.conf</tt> and the -winbind libraries on Linux and Solaris</h4></div></div><div></div></div><p> -The libraries needed to run the <span class="application">winbindd</span> daemon -through nsswitch need to be copied to their proper locations, so -</p><ns74:p> -</ns74:p><pre class="screen"> -<tt class="prompt">root# </tt><b class="userinput"><tt>cp ../samba/source/nsswitch/libnss_winbind.so /lib</tt></b> -</pre><ns74:p> -</ns74:p><p> -I also found it necessary to make the following symbolic link: -</p><p> -<tt class="prompt">root# </tt> <b class="userinput"><tt>ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2</tt></b> -</p><p>And, in the case of Sun Solaris:</p><pre class="screen"> -<tt class="prompt">root# </tt><b class="userinput"><tt>ln -s /usr/lib/libnss_winbind.so /usr/lib/libnss_winbind.so.1</tt></b> -<tt class="prompt">root# </tt><b class="userinput"><tt>ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.1</tt></b> -<tt class="prompt">root# </tt><b class="userinput"><tt>ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.2</tt></b> -</pre><p> -Now, as root you need to edit <tt class="filename">/etc/nsswitch.conf</tt> to -allow user and group entries to be visible from the <span class="application">winbindd</span> -daemon. My <tt class="filename">/etc/nsswitch.conf</tt> file look like -this after editing: -</p><pre class="programlisting"> - passwd: files winbind - shadow: files - group: files winbind -</pre><p> -The libraries needed by the winbind daemon will be automatically -entered into the <b class="command">ldconfig</b> cache the next time -your system reboots, but it -is faster (and you don't need to reboot) if you do it manually: -</p><p> -<tt class="prompt">root# </tt><b class="userinput"><tt>/sbin/ldconfig -v | grep winbind</tt></b> -</p><p> -This makes <tt class="filename">libnss_winbind</tt> available to winbindd -and echos back a check to you. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2977217"></a>NSS Winbind on AIX</h4></div></div><div></div></div><p>(This section is only for those running AIX)</p><p> -The winbind AIX identification module gets built as libnss_winbind.so in the -nsswitch directory of the samba source. This file can be copied to -/usr/lib/security, 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 -<tt class="filename">/usr/lib/security/methods.cfg</tt>. This module only -supports identification, but there have been success reports using the -standard winbind pam module for authentication. Use caution configuring -loadable authentication modules as it is possible to make it impossible -to logon to the system. More information about the AIX authentication -module API can be found at "Kernel Extensions and Device Support -Programming Concepts for AIX": <a href="http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixprggd/kernextc/sec_load_mod.htm" target="_top"> -Chapter 18. Loadable Authentication Module Programming Interface</a> -and more information on administering the modules at <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="id2977288"></a>Configure smb.conf</h4></div></div><div></div></div><p> -Several parameters are needed in the smb.conf file to control -the behavior of <span class="application">winbindd</span>. Configure -<tt class="filename">smb.conf</tt> 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 -<tt class="filename">smb.conf</tt> file was modified to -include the following entries in the [global] section: -</p><pre class="programlisting"> -[global] - <...> - # separate domain and username with '+', like DOMAIN+username - <a href="winbindd.8.html#WINBINDSEPARATOR" target="_top">winbind separator</a> = + - # use uids from 10000 to 20000 for domain users - <a href="winbindd.8.html#WINBINDUID" target="_top">idmap uid</a> = 10000-20000 - # use gids from 10000 to 20000 for domain groups - <a href="winbindd.8.html#WINBINDGID" target="_top">idmap gid</a> = 10000-20000 - # allow enumeration of winbind users and groups - <a href="winbindd.8.html#WINBINDENUMUSERS" target="_top">winbind enum users</a> = yes - <a href="winbindd.8.html#WINBINDENUMGROUP" target="_top">winbind enum groups</a> = yes - # give winbind users a real shell (only needed if they have telnet access) - <a href="winbindd.8.html#TEMPLATEHOMEDIR" target="_top">template homedir</a> = /home/winnt/%D/%U - <a href="winbindd.8.html#TEMPLATESHELL" target="_top">template shell</a> = /bin/bash -</pre></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2977402"></a>Join the SAMBA server to the PDC domain</h4></div></div><div></div></div><p> -Enter the following command to make the SAMBA server join the -PDC domain, where <i class="replaceable"><tt>DOMAIN</tt></i> is the name of -your Windows domain and <i class="replaceable"><tt>Administrator</tt></i> is -a domain user who has administrative privileges in the domain. -</p><p> -<tt class="prompt">root# </tt><b class="userinput"><tt>/usr/local/samba/bin/net join -S PDC -U Administrator</tt></b> -</p><p> -The proper response to the command should be: "Joined the domain -<i class="replaceable"><tt>DOMAIN</tt></i>" where <i class="replaceable"><tt>DOMAIN</tt></i> -is your DOMAIN name. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2980297"></a>Start up the winbindd daemon and test it!</h4></div></div><div></div></div><p> -Eventually, you will want to modify your smb 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><p> -<tt class="prompt">root# </tt><b class="userinput"><tt>/usr/local/samba/bin/winbindd</tt></b> -</p><p> -Winbindd can now also run in 'dual daemon mode'. This will make it -run as 2 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 that the first has just responded. -Advantage of this is that responses stay accurate and are faster. -You can enable dual daemon mode by adding <tt class="option">-B</tt> to the commandline: -</p><p> -<tt class="prompt">root# </tt><b class="userinput"><tt>/usr/local/samba/bin/winbindd -B</tt></b> -</p><p> -I'm always paranoid and like to make sure the daemon -is really running... -</p><p> -<tt class="prompt">root# </tt><b class="userinput"><tt>ps -ae | grep winbindd</tt></b> -</p><p> -This command should produce output like this, if the daemon is running -</p><pre class="screen"> -3025 ? 00:00:00 winbindd -</pre><p> -Now... for the real test, try to get some information about the -users on your PDC -</p><p> -<tt class="prompt">root# </tt><b class="userinput"><tt>/usr/local/samba/bin/wbinfo -u</tt></b> -</p><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 'CEO' and my <i class="parameter"><tt>winbind -separator</tt></i> is '+'. -</p><p> -You can do the same sort of thing to get group information from -the PDC: -</p><pre class="screen"> -<tt class="prompt">root# </tt><b class="userinput"><tt>/usr/local/samba/bin/wbinfo -g</tt></b> - 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> -The function 'getent' can now be used to get unified -lists of both local and PDC users and groups. -Try the following command: -</p><p> -<tt class="prompt">root# </tt><b class="userinput"><tt>getent passwd</tt></b> -</p><p> -You should get a list that looks like your <tt class="filename">/etc/passwd</tt> -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><p> -<tt class="prompt">root# </tt><b class="userinput"><tt>getent group</tt></b> -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2980538"></a>Fix the init.d startup scripts</h4></div></div><div></div></div><div xmlns:ns75="" class="sect4" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2980545"></a>Linux</h5></div></div><div></div></div><p> -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 <tt class="filename">/etc/init.d/smb</tt> in RedHat and -<tt class="filename">/etc/init.d/samba</tt> in Debian. -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 -<tt class="filename">/usr/local/samba/bin</tt> directory directly. The 'start' -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/bin/winbindd - RETVAL3=$? - echo - [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 -a $RETVAL3 -eq 0 ] && \ - touch /var/lock/subsys/smb || RETVAL=1 - return $RETVAL -} -</pre><ns75:p>If you would like to run winbindd in dual daemon mode, replace -the line -</ns75:p><pre class="programlisting"> - daemon /usr/local/samba/bin/winbindd -</pre><ns75:p> - -in the example above with: - -</ns75:p><pre class="programlisting"> - daemon /usr/local/samba/bin/winbindd -B -</pre><ns75:p>. -</ns75:p><p> -The 'stop' 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 xmlns:ns76="" class="sect4" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2980690"></a>Solaris</h5></div></div><div></div></div><p>Winbind doesn't work on Solaris 9, see the <a href="Portability.html#winbind-solaris9" title="Winbind on Solaris 9">Portability</a> chapter for details.</p><p>On Solaris, you need to modify the -<tt class="filename">/etc/init.d/samba.server</tt> startup script. It usually -only starts smbd and nmbd but should now start winbindd too. If you -have samba installed in <tt class="filename">/usr/local/samba/bin</tt>, -the file could contains something like this: -</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/bin/winbindd - ;; - - 'stop') - killproc nmbd - killproc smbd - killproc winbindd - ;; - - *) - echo "Usage: /etc/init.d/samba.server { start | stop }" - ;; - esac -</pre><ns76:p> -Again, if you would like to run samba in dual daemon mode, replace -</ns76:p><pre class="programlisting"> - /usr/local/samba/bin/winbindd -</pre><ns76:p> - -in the script above with: - -</ns76:p><pre class="programlisting"> - /usr/local/samba/bin/winbindd -B -</pre><ns76:p> -</ns76:p></div><div class="sect4" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2980779"></a>Restarting</h5></div></div><div></div></div><p> -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="id2980816"></a>Configure Winbind and PAM</h4></div></div><div></div></div><p> -If you have made it this far, you know that winbindd 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 -<tt class="filename">/etc/pam.d</tt> files? If not, do it now.) -</p><p> -You will need a pam module to use winbindd with these other services. This -module will be compiled in the <tt class="filename">../source/nsswitch</tt> directory -by invoking the command -</p><p> -<tt class="prompt">root# </tt><b class="userinput"><tt>make nsswitch/pam_winbind.so</tt></b> -</p><p> -from the <tt class="filename">../source</tt> directory. The -<tt class="filename">pam_winbind.so</tt> file should be copied to the location of -your other pam security modules. On my RedHat system, this was the -<tt class="filename">/lib/security</tt> directory. On Solaris, the pam security -modules reside in <tt class="filename">/usr/lib/security</tt>. -</p><p> -<tt class="prompt">root# </tt><b class="userinput"><tt>cp ../samba/source/nsswitch/pam_winbind.so /lib/security</tt></b> -</p><div xmlns:ns77="" class="sect4" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2980922"></a>Linux/FreeBSD-specific PAM configuration</h5></div></div><div></div></div><p> -The <tt class="filename">/etc/pam.d/samba</tt> 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> -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 -<tt class="filename">/etc/xinetd.d</tt> (or <tt class="filename">/etc/inetd.conf</tt>). -RedHat 7.1 uses the new xinetd.d structure, in this case you need -to change the lines in <tt class="filename">/etc/xinetd.d/telnet</tt> -and <tt class="filename">/etc/xinetd.d/wu-ftp</tt> from -</p><pre class="programlisting"> - enable = no -</pre><p> -to -</p><pre class="programlisting"> - enable = yes -</pre><p> -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 <tt class="filename">smb.conf</tt> global entry -<i class="parameter"><tt>template homedir</tt></i>. -</p><p> -The <tt class="filename">/etc/pam.d/ftp</tt> file can be changed -to allow winbind ftp access in a manner similar to the -samba file. My <tt class="filename">/etc/pam.d/ftp</tt> 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> -The <tt class="filename">/etc/pam.d/login</tt> file can be changed 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><ns77:p> -In this case, I added the </ns77:p><pre class="programlisting">auth sufficient /lib/security/pam_winbind.so</pre><ns77:p> -lines as before, but also added the </ns77:p><pre class="programlisting">required pam_securetty.so</pre><ns77:p> -above it, to disallow root logins over the network. I also added a -<b class="command">sufficient /lib/security/pam_unix.so use_first_pass</b> -line after the <b class="command">winbind.so</b> line to get rid of annoying -double prompts for passwords. -</ns77:p></div><div class="sect4" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2981145"></a>Solaris-specific configuration</h5></div></div><div></div></div><p> -The /etc/pam.conf needs to be changed. I changed this file so that my Domain -users can logon both locally as well as telnet.The following are the changes -that I made.You can customize the pam.conf 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> -I also added a try_first_pass line after the winbind.so 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="id2981237"></a>Conclusion</h2></div></div><div></div></div><p>The winbind system, through the use of the Name Service - Switch, Pluggable Authentication Modules, 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="id2981256"></a>Common Errors</h2></div></div><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 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 Name Service Switch and Pluggable Authentication - Modules 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 mapping 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 been set for Windows NT users, this is - instead up to the PDC to enforce.</p></li></ul></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 20. 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 22. Advanced Network Management</td></tr></table></div></body></html> |