Docbook XML conversion: projdoc

(This used to be commit f7c9df751459da2d4a996d5f0135334fb3f87f69)

1 files changed, 1169 insertions, 0 deletions

diff --git a/docs/docbook/projdoc/winbind.xml b/docs/docbook/projdoc/winbind.xml
new file mode 100644
index 0000000000..d46c32c2e4
--- /dev/null
+++ b/docs/docbook/projdoc/winbind.xml
@@ -0,0 +1,1169 @@
+<chapter id="winbind">
+
+<chapterinfo>
+	<authorgroup>
+	<author>
+		<firstname>Tim</firstname><surname>Potter</surname>
+		<affiliation>
+			<orgname>Samba Team</orgname>
+			<address><email>tpot@linuxcare.com.au</email></address>
+		</affiliation>
+	</author>
+	&author.tridge;
+	&author.jht;
+	<author>
+		<firstname>Naag</firstname><surname>Mummaneni</surname>
+		<affiliation>
+			<address><email>getnag@rediffmail.com</email></address>
+		</affiliation>
+	</author>
+	&author.jelmer;
+	</authorgroup>
+	<pubdate>27 June 2002</pubdate>
+</chapterinfo>
+
+<title>Unified Logons between Windows NT and UNIX using Winbind</title>
+
+<sect1>
+	<title>Abstract</title>
+
+	<para>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 
+	<emphasis>winbind</emphasis>, 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.</para>
+</sect1>
+
+
+<sect1>
+	<title>Introduction</title>
+	
+	<para>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.</para>
+	
+	<para>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.</para>
+	
+	<para>We divide the unified logon problem for UNIX machines into 
+	three smaller problems:</para>
+	
+	<itemizedlist>
+		<listitem><para>Obtaining Windows NT user and group information
+		</para></listitem>
+		
+		<listitem><para>Authenticating Windows NT users
+		</para></listitem>
+		
+		<listitem><para>Password changing for Windows NT users
+		</para></listitem>
+	</itemizedlist>
+
+
+	<para>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.</para>
+</sect1>
+
+
+<sect1>
+	<title>What Winbind Provides</title>
+
+	<para>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.</para>
+	
+	<para>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.</para>
+	
+	<para>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.</para>
+	
+	<para>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.</para>
+	
+	<para>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).</para>
+	
+	<sect2>
+		<title>Target Uses</title>
+		
+		<para>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.</para>
+		
+		<para>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.</para>
+	</sect2>
+</sect1>
+
+
+
+<sect1>
+	<title>How Winbind Works</title>
+	
+	<para>The winbind system is designed around a client/server 
+	architecture. A long running <command>winbindd</command> 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.</para>
+	
+	<para>The technologies used to implement winbind are described 
+	in detail below.</para>
+	
+	<sect2>
+		<title>Microsoft Remote Procedure Calls</title>
+		
+		<para>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.</para>
+		
+		<para>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.</para>
+	</sect2>
+	
+	<sect2>
+		<title>Microsoft Active Directory Services</title>
+
+		<para>
+                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.  
+                </para>
+	</sect2>
+	
+	<sect2>
+		<title>Name Service Switch</title>
+		
+		<para>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.</para>
+		
+		<para>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.</para>
+		
+		<para>The primary control file for NSS is 
+		<filename>/etc/nsswitch.conf</filename>. 
+		When a UNIX application makes a request to do a lookup 
+		the C library looks in <filename>/etc/nsswitch.conf</filename> 
+		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:</para>
+
+		<para><command>passwd: files example</command></para>
+
+		<para>then the C library will first load a module called 
+		<filename>/lib/libnss_files.so</filename> followed by
+		the module <filename>/lib/libnss_example.so</filename>. 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.</para>
+		
+		<para>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 <filename>libnss_winbind.so</filename> in <filename>/lib/</filename> 
+		then add "winbind" into <filename>/etc/nsswitch.conf</filename> at 
+		the appropriate place. The C library will then call Winbind to 
+		resolve user and group names.</para>
+	</sect2>
+	
+	<sect2>
+		<title>Pluggable Authentication Modules</title>
+		
+		<para>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.</para>
+		
+		<para>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.
+		</para>
+		
+		<para>PAM is configured by providing control files in the directory 
+		<filename>/etc/pam.d/</filename> 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 <filename>pam_winbind.so</filename> module 
+		is copied to <filename>/lib/security/</filename> and the PAM 
+		control files for relevant services are updated to allow 
+		authentication via winbind. See the PAM documentation
+		for more details.</para>
+	</sect2>
+	
+	
+	<sect2>
+		<title>User and Group ID Allocation</title>
+		
+		<para>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.</para>
+
+		<para>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.</para>
+	</sect2>
+	
+	
+	<sect2>
+		<title>Result Caching</title>
+
+		<para>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.</para>
+	</sect2>
+</sect1>
+
+
+<sect1>
+	<title>Installation and Configuration</title>
+	
+<para>
+Many thanks to John Trostel <ulink 
+url="mailto:jtrostel@snapserver.com">jtrostel@snapserver.com</ulink>
+for providing the HOWTO for this section.
+</para>
+
+<para>
+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.
+</para>
+
+<sect2>
+<title>Introduction</title>
+
+<para>
+This HOWTO describes the procedures used to get winbind up and 
+running on my 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.
+</para>
+
+<para>
+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.
+</para>
+
+
+<itemizedlist>
+<listitem>
+	<para>
+	<emphasis>Why should I to this?</emphasis>
+	</para>
+	
+	<para>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.
+	</para>
+</listitem>
+
+<listitem>
+	<para>
+	<emphasis>Who should be reading this document?</emphasis>
+	</para>
+	
+	<para>
+	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.
+	</para>
+</listitem>
+</itemizedlist>
+</sect2>
+
+
+<sect2>
+<title>Requirements</title>
+
+<para>
+If you have a samba configuration file that you are currently 
+using... <emphasis>BACK IT UP!</emphasis>  If your system already uses PAM, 
+<emphasis>back up the <filename>/etc/pam.d</filename> directory 
+contents!</emphasis> If you haven't already made a boot disk, 
+<emphasis>MAKE ONE NOW!</emphasis>
+</para>
+
+<para>
+Messing with the pam configuration files can make it nearly impossible 
+to log in to yourmachine. That's why you want to be able to boot back 
+into your machine in single user mode and restore your 
+<filename>/etc/pam.d</filename> back to the original state they were in if 
+you get frustrated with the way things are going.  ;-)
+</para>
+
+<para>
+The latest version of SAMBA (version 3.0 as of this writing), now 
+includes a functioning winbindd daemon.  Please refer to the 
+<ulink url="http://samba.org/">main SAMBA web page</ulink> or, 
+better yet, your closest SAMBA mirror site for instructions on 
+downloading the source code.
+</para>
+
+<para>
+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 <filename>pam-0.74-22</filename>.  For best results, it is helpful to also
+install the development packages in <filename>pam-devel-0.74-22</filename>.
+</para>
+
+</sect2>
+
+
+<sect2>
+<title>Testing Things Out</title>
+
+<para>
+Before starting, it is probably best to kill off all the SAMBA 
+related daemons running on your server.  Kill off all <command>smbd</command>, 
+<command>nmbd</command>, and <command>winbindd</command> 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 <filename>/etc/pam.d</filename> 
+directory structure, including the pam modules are used by pam-aware 
+services, several pam libraries, and the <filename>/usr/doc</filename> 
+and <filename>/usr/man</filename> 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. For instance, 
+my RedHat system has both <filename>pam-0.74-22</filename> and
+<filename>pam-devel-0.74-22</filename> RPMs installed.
+</para>
+
+<sect3>
+<title>Configure and compile SAMBA</title>
+
+<para>
+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.
+</para>
+
+<para><programlisting>
+<prompt>root#</prompt> <command>autoconf</command>
+<prompt>root#</prompt> <command>make clean</command>
+<prompt>root#</prompt> <command>rm config.cache</command>
+<prompt>root#</prompt> <command>./configure</command>
+<prompt>root#</prompt> <command>make</command>
+<prompt>root#</prompt> <command>make install</command>
+</programlisting></para>
+
+
+<para>
+This will, by default, install SAMBA in <filename>/usr/local/samba</filename>.
+See the main SAMBA documentation if you want to install SAMBA somewhere else.
+It will also build the winbindd executable and libraries. 
+</para>
+
+</sect3>
+
+<sect3>
+<title>Configure <filename>nsswitch.conf</filename> and the 
+winbind libraries on Linux and Solaris</title>
+
+<para>
+The libraries needed to run the <command>winbindd</command> daemon 
+through nsswitch need to be copied to their proper locations, so
+</para>
+
+<para>
+<prompt>root#</prompt> <command>cp ../samba/source/nsswitch/libnss_winbind.so /lib</command>
+</para>
+
+<para>
+I also found it necessary to make the following symbolic link:
+</para>
+
+<para>
+<prompt>root#</prompt> <command>ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2</command>
+</para>
+
+<para>And, in the case of Sun solaris:</para>
+<para>
+<prompt>root#</prompt> <userinput>ln -s /usr/lib/libnss_winbind.so /usr/lib/libnss_winbind.so.1</userinput>
+<prompt>root#</prompt> <userinput>ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.1</userinput>
+<prompt>root#</prompt> <userinput>ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.2</userinput>
+</para>
+
+<para>
+Now, as root you need to edit <filename>/etc/nsswitch.conf</filename> to 
+allow user and group entries to be visible from the <command>winbindd</command> 
+daemon.  My <filename>/etc/nsswitch.conf</filename> file look like 
+this after editing:
+</para>
+
+<para><programlisting>
+	passwd:     files winbind
+	shadow:     files 
+	group:      files winbind
+</programlisting></para>
+
+<para>	
+The libraries needed by the winbind daemon will be automatically 
+entered into the <command>ldconfig</command> cache the next time 
+your system reboots, but it 
+is faster (and you don't need to reboot) if you do it manually:
+</para>
+
+<para>
+<prompt>root#</prompt> <command>/sbin/ldconfig -v | grep winbind</command>
+</para>
+
+<para>
+This makes <filename>libnss_winbind</filename> available to winbindd 
+and echos back a check to you.
+</para>
+
+</sect3>
+
+<sect3>
+<title>NSS Winbind on AIX</title>
+
+<para>(This section is only for those running AIX)</para>
+
+<para>
+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:
+</para>
+
+<para><programlisting>
+WINBIND:
+        program = /usr/lib/security/WINBIND
+        options = authonly
+</programlisting></para>
+
+<para>can then be added to
+<filename>/usr/lib/security/methods.cfg</filename>.  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 &quot;Kernel Extensions and Device Support
+Programming Concepts for AIX&quot;: <link
+url="http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixprggd/kernextc/sec_load_mod.htm">
+Chapter 18. Loadable Authentication Module Programming Interface</link> 
+and more information on administering the  modules at <link
+url="http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/baseadmn/iandaadmin.htm">
+&quot;System Management Guide: Operating System and Devices&quot;</link>.
+</para>
+</sect3>
+
+<sect3>
+<title>Configure smb.conf</title>
+
+<para>
+Several parameters are needed in the smb.conf file to control 
+the behavior of <command>winbindd</command>. Configure 
+<filename>smb.conf</filename> These are described in more detail in 
+the <citerefentry><refentrytitle>winbindd</refentrytitle>
+<manvolnum>8</manvolnum></citerefentry> man page.  My 
+<filename>smb.conf</filename> file was modified to
+include the following entries in the [global] section:
+</para>
+
+<para><programlisting>
+[global]
+     &lt;...&gt;
+     # separate domain and username with '+', like DOMAIN+username
+     <ulink url="winbindd.8.html#WINBINDSEPARATOR">winbind separator</ulink> = +
+     # use uids from 10000 to 20000 for domain users
+     <ulink url="winbindd.8.html#WINBINDUID">winbind uid</ulink> = 10000-20000
+     # use gids from 10000 to 20000 for domain groups
+     <ulink url="winbindd.8.html#WINBINDGID">winbind gid</ulink> = 10000-20000
+     # allow enumeration of winbind users and groups
+     <ulink url="winbindd.8.html#WINBINDENUMUSERS">winbind enum users</ulink> = yes
+     <ulink url="winbindd.8.html#WINBINDENUMGROUP">winbind enum groups</ulink> = yes
+     # give winbind users a real shell (only needed if they have telnet access)
+     <ulink url="winbindd.8.html#TEMPLATEHOMEDIR">template homedir</ulink> = /home/winnt/%D/%U
+     <ulink url="winbindd.8.html#TEMPLATESHELL">template shell</ulink> = /bin/bash
+</programlisting></para>
+
+</sect3>
+
+
+<sect3>
+<title>Join the SAMBA server to the PDC domain</title>
+
+<para>
+Enter the following command to make the SAMBA server join the 
+PDC domain, where <replaceable>DOMAIN</replaceable> is the name of 
+your Windows domain and <replaceable>Administrator</replaceable> is 
+a domain user who has administrative privileges in the domain.
+</para>
+	
+
+<para>
+<prompt>root#</prompt> <command>/usr/local/samba/bin/net join -S PDC -U Administrator</command>
+</para>
+
+
+<para>
+The proper response to the command should be: "Joined the domain 
+<replaceable>DOMAIN</replaceable>" where <replaceable>DOMAIN</replaceable> 
+is your DOMAIN name.
+</para>
+
+</sect3>
+
+
+<sect3>
+<title>Start up the winbindd daemon and test it!</title>
+
+<para>
+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:
+</para>
+	
+<para>
+<prompt>root#</prompt> <command>/usr/local/samba/bin/winbindd</command>
+</para>
+
+<para>
+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 '-B' to the commandline:
+</para>
+
+<para>
+<prompt>root#</prompt> <command>/usr/local/samba/bin/winbindd -B</command>
+</para>
+
+<para>
+I'm always paranoid and like to make sure the daemon 
+is really running...
+</para>
+
+<para>
+<prompt>root#</prompt> <command>ps -ae | grep winbindd</command>
+</para>
+<para>
+This command should produce output like this, if the daemon is running
+</para>
+<para>
+3025 ?        00:00:00 winbindd
+</para>
+
+<para>
+Now... for the real test, try to get some information about the 
+users on your PDC
+</para>
+
+<para>
+<prompt>root#</prompt> <command>/usr/local/samba/bin/wbinfo -u</command>
+</para>
+
+<para>	
+This should echo back a list of users on your Windows users on 
+your PDC.  For example, I get the following response:
+</para>
+
+<para><programlisting>
+	CEO+Administrator
+	CEO+burdell
+	CEO+Guest
+	CEO+jt-ad
+	CEO+krbtgt
+	CEO+TsInternetUser
+</programlisting></para>
+
+<para>
+Obviously, I have named my domain 'CEO' and my <parameter>winbind
+separator</parameter> is '+'.
+</para>
+
+<para>
+You can do the same sort of thing to get group information from 
+the PDC:
+</para>
+
+<para><programlisting>
+<prompt>root#</prompt> <command>/usr/local/samba/bin/wbinfo -g</command>
+	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
+</programlisting></para>
+
+<para>
+The function 'getent' can now be used to get unified 
+lists of both local and PDC users and groups.
+Try the following command:
+</para>
+
+<para>
+<prompt>root#</prompt> <command>getent passwd</command>
+</para>
+	
+<para>
+You should get a list that looks like your <filename>/etc/passwd</filename> 
+list followed by the domain users with their new uids, gids, home 
+directories and default shells.
+</para>
+
+<para>
+The same thing can be done for groups with the command
+</para>
+
+<para>
+<prompt>root#</prompt> <command>getent group</command>
+</para>
+
+</sect3>
+
+
+<sect3>
+<title>Fix the init.d startup scripts</title>
+
+<sect4>
+<title>Linux</title>
+
+<para>
+The <command>winbindd</command> daemon needs to start up after the 
+<command>smbd</command> and <command>nmbd</command> daemons are running.  
+To accomplish this task, you need to modify the startup scripts of your system.
+They are located at <filename>/etc/init.d/smb</filename> in RedHat and 
+<filename>/etc/init.d/samba</filename> in Debian.
+script to add commands to invoke this daemon in the proper sequence.  My 
+startup script starts up <command>smbd</command>, 
+<command>nmbd</command>, and <command>winbindd</command> from the 
+<filename>/usr/local/samba/bin</filename> directory directly.  The 'start' 
+function in the script looks like this:
+</para>
+
+<para><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 ] &amp;&amp; \
+		touch /var/lock/subsys/smb || RETVAL=1
+        return $RETVAL
+}
+</programlisting></para>
+
+<para>If you would like to run winbindd in dual daemon mode, replace 
+the line 
+<programlisting>
+        daemon /usr/local/samba/bin/winbindd
+</programlisting>
+
+in the example above with:
+
+<programlisting>
+        daemon /usr/local/samba/bin/winbindd -B
+</programlisting>.
+</para>
+
+<para>
+The 'stop' function has a corresponding entry to shut down the 
+services and looks like this:
+</para>
+
+<para><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 ] &amp;&amp; \
+		 rm -f /var/lock/subsys/smb
+        echo ""
+        return $RETVAL
+}
+</programlisting></para>
+</sect4>
+
+<sect4>
+<title>Solaris</title>
+
+<para>Winbind doesn't work on solaris 9, see the <link linkend="winbind-solaris9">Portability</link> chapter for details.</para>
+
+<para>On solaris, you need to modify the 
+<filename>/etc/init.d/samba.server</filename> startup script. It usually 
+only starts smbd and nmbd but should now start winbindd too. If you 
+have samba installed in <filename>/usr/local/samba/bin</filename>, 
+the file could contains something like this:
+</para>
+
+<para><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" != "" ] &amp;&amp; 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
+</programlisting></para>
+
+<para>
+Again, if you would like to run samba in dual daemon mode, replace 
+<programlisting>
+	/usr/local/samba/bin/winbindd
+</programlisting>
+
+in the script above with:
+
+<programlisting>
+	/usr/local/samba/bin/winbindd -B
+</programlisting>
+</para>
+
+</sect4>
+
+<sect4>
+<title>Restarting</title>
+<para>
+If you restart the <command>smbd</command>, <command>nmbd</command>, 
+and <command>winbindd</command> 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.
+</para>
+</sect4>
+</sect3>
+
+<sect3>
+<title>Configure Winbind and PAM</title>
+
+<para>
+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 
+<filename>/etc/pam.d</filename> files? If not, do it now.)
+</para>
+
+<para>
+You will need a pam module to use winbindd with these other services.  This 
+module will be compiled in the <filename>../source/nsswitch</filename> directory
+by invoking the command
+</para>
+
+<para>
+<prompt>root#</prompt> <command>make nsswitch/pam_winbind.so</command>
+</para>
+
+<para>
+from the <filename>../source</filename> directory.  The
+<filename>pam_winbind.so</filename> file should be copied to the location of
+your other pam security modules.  On my RedHat system, this was the
+<filename>/lib/security</filename> directory. On Solaris, the pam security 
+modules reside in <filename>/usr/lib/security</filename>.
+</para>
+
+<para>
+<prompt>root#</prompt> <command>cp ../samba/source/nsswitch/pam_winbind.so /lib/security</command>
+</para>
+
+<sect4>
+<title>Linux/FreeBSD-specific PAM configuration</title>
+
+<para>
+The <filename>/etc/pam.d/samba</filename> file does not need to be changed. I 
+just left this fileas it was:
+</para>
+
+
+<para><programlisting>
+	auth    required        /lib/security/pam_stack.so service=system-auth
+	account required        /lib/security/pam_stack.so service=system-auth
+</programlisting></para>
+
+<para>
+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 
+<filename>/etc/xinetd.d</filename> (or <filename>/etc/inetd.conf</filename>).  
+RedHat 7.1 uses the new xinetd.d structure, in this case you need 
+to change the lines in <filename>/etc/xinetd.d/telnet</filename> 
+and <filename>/etc/xinetd.d/wu-ftp</filename> from 
+</para>
+
+<para><programlisting>
+	enable = no
+</programlisting></para>
+
+<para>
+to
+</para>
+
+<para><programlisting>
+	enable = yes
+</programlisting></para>
+
+<para>	
+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 <filename>smb.conf</filename> global entry 
+<command>template homedir</command>.
+</para>
+
+<para>
+The <filename>/etc/pam.d/ftp</filename> file can be changed 
+to allow winbind ftp access in a manner similar to the
+samba file.  My <filename>/etc/pam.d/ftp</filename> file was 
+changed to look like this:
+</para>
+
+<para><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
+</programlisting></para>
+
+<para>
+The <filename>/etc/pam.d/login</filename> file can be changed nearly the 
+same way.  It now looks like this:
+</para>
+
+<para><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
+</programlisting></para>
+
+<para>
+In this case, I added the <command>auth sufficient /lib/security/pam_winbind.so</command> 
+lines as before, but also added the <command>required pam_securetty.so</command> 
+above it, to disallow root logins over the network.  I also added a 
+<command>sufficient /lib/security/pam_unix.so use_first_pass</command>
+line after the <command>winbind.so</command> line to get rid of annoying 
+double prompts for passwords.
+</para>
+
+</sect4>
+
+<sect4>
+<title>Solaris-specific configuration</title>
+
+<para>
+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.
+</para>
+
+<para><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
+</programlisting></para>
+
+<para>
+I also added a try_first_pass line after the winbind.so line to get rid of
+annoying double prompts for passwords.
+</para>
+
+<para>
+Now restart your Samba and try connecting through your application that you
+configured in the pam.conf.
+</para>
+
+</sect4>
+
+</sect3>
+
+</sect2>
+
+</sect1>
+
+<sect1>
+	<title>Limitations</title>
+	
+	<para>Winbind has a number of limitations in its current 
+	released version that we hope to overcome in future 
+	releases:</para>
+
+	<itemizedlist>
+		<listitem><para>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.</para></listitem>
+		
+		<listitem><para>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.</para>
+		</listitem>
+		
+		<listitem><para>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.</para></listitem>
+	</itemizedlist>
+</sect1>
+
+
+<sect1>
+	<title>Conclusion</title>
+
+	<para>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.</para>
+	
+</sect1>
+
+</chapter>