s3: Fix shadow copy display on Windows 7
[kai/samba-autobuild/.git] / docs-xml / Samba3-HOWTO / TOSHARG-Winbind.xml
1 <?xml version="1.0" encoding="iso-8859-1"?>
2 <!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
3 <chapter id="winbind">
4
5 <chapterinfo>
6         <author>
7                 <firstname>Tim</firstname><surname>Potter</surname>
8                 <affiliation>
9                         <orgname>Samba Team</orgname>
10                         <address><email>tpot@linuxcare.com.au</email></address>
11                 </affiliation>
12         </author>
13         &author.tridge;
14         <author>
15                 <firstname>Naag</firstname><surname>Mummaneni</surname>
16                 <affiliation>
17                         <address><email>getnag@rediffmail.com</email></address>
18                 </affiliation>
19                 <contrib>Notes for Solaris</contrib>
20         </author>
21         <author>
22                 <firstname>John</firstname><surname>Trostel</surname>
23                 <affiliation>
24                         <orgname>SNAP</orgname>
25                         <address><email>jtrostel@snapserver.com</email></address>
26                 </affiliation>
27         </author>
28         &author.jelmer;
29         &author.jht;
30         <pubdate>June 15, 2005</pubdate>
31 </chapterinfo>
32
33 <title>Winbind: Use of Domain Accounts</title>
34
35 <sect1>
36         <title>Features and Benefits</title>
37
38         <para>
39 <indexterm><primary>holy grail</primary></indexterm>
40 <indexterm><primary>heterogeneous computing</primary></indexterm>
41         Integration of UNIX and Microsoft Windows NT through a unified logon has
42         been considered a <quote>holy grail</quote> in heterogeneous computing environments for
43         a long time.
44         </para>
45
46         <para>
47 <indexterm><primary>interoperability</primary></indexterm>
48 <indexterm><primary>domain user</primary></indexterm>
49 <indexterm><primary>domain group</primary></indexterm>
50 <indexterm><primary>group ownership</primary></indexterm>
51         There is one other facility without which UNIX and Microsoft Windows network
52         interoperability would suffer greatly. It is imperative that there be a
53         mechanism for sharing files across UNIX systems and to be able to assign
54         domain user and group ownerships with integrity.
55         </para>
56
57         <para>
58 <indexterm><primary>Pluggable Authentication Modules</primary><see>PAM</see></indexterm>
59 <indexterm><primary>winbind</primary></indexterm>
60 <indexterm><primary>NSS</primary></indexterm>
61 <indexterm><primary>RPC</primary></indexterm>
62         <emphasis>winbind</emphasis> is a component of the Samba suite of programs that
63         solves the unified logon problem. Winbind uses a UNIX implementation of Microsoft
64         RPC calls, Pluggable Authentication Modules (PAMs), and the name service switch (NSS) to
65         allow Windows NT domain users to appear and operate as UNIX users on a UNIX
66         machine. This chapter describes the Winbind system, the functionality
67         it provides, how it is configured, and how it works internally.
68         </para>
69
70         <para>
71         Winbind provides three separate functions:
72         </para>
73
74         <itemizedlist>
75                 <listitem><para>
76 <indexterm><primary>ADS</primary></indexterm>
77 <indexterm><primary>NT4 domain</primary></indexterm>
78                 Authentication of user credentials (via PAM). This makes it possible to
79                 log onto a UNIX/Linux system using user and group accounts from a Windows
80                 NT4 (including a Samba domain) or an Active Directory domain.
81                 </para></listitem>
82
83                 <listitem><para>
84 <indexterm><primary>identity resolution</primary></indexterm>
85 <indexterm><primary>NSS</primary></indexterm>
86                 Identity resolution (via NSS). This is the default when winbind is not used.
87                 </para></listitem>
88
89                 <listitem><para>
90 <indexterm><primary>UID</primary></indexterm>
91 <indexterm><primary>GID</primary></indexterm>
92 <indexterm><primary>SID</primary></indexterm>
93 <indexterm><primary>idmap uid</primary></indexterm>
94 <indexterm><primary>idmap gid</primary></indexterm>
95 <indexterm><primary>idmap backend</primary></indexterm>
96 <indexterm><primary>LDAP</primary></indexterm>
97                 Winbind maintains a database called winbind_idmap.tdb in which it stores
98                 mappings between UNIX UIDs, GIDs, and NT SIDs. This mapping is used only
99                 for users and groups that do not have a local UID/GID. It stores the UID/GID
100                 allocated from the idmap uid/gid range that it has mapped to the NT SID.
101                 If <parameter>idmap backend</parameter> has been specified as <constant>ldap:ldap://hostname[:389]</constant>,
102                 then instead of using a local mapping, Winbind will obtain this information
103                 from the LDAP database.
104                 </para></listitem>
105         </itemizedlist>
106
107         <note><para>
108         <indexterm><primary>winbindd</primary></indexterm>
109         <indexterm><primary>starting samba</primary><secondary>winbindd</secondary></indexterm>
110 <indexterm><primary>/etc/passwd</primary></indexterm>
111 <indexterm><primary>/etc/group</primary></indexterm>
112 <indexterm><primary>smbd</primary></indexterm>
113 <indexterm><primary>NSS</primary></indexterm>
114         If <command>winbindd</command> is not running, smbd (which calls <command>winbindd</command>) will fall back to
115         using purely local information from <filename>/etc/passwd</filename> and <filename>/etc/group</filename> and no dynamic
116         mapping will be used. On an operating system that has been enabled with the NSS,
117         the resolution of user and group information will be accomplished via NSS.
118         </para></note>
119
120
121         <figure id="winbind_idmap">
122         <title>Winbind Idmap</title>
123         <imagefile scale="45">idmap_winbind_no_loop</imagefile>
124         </figure>
125
126 </sect1>
127
128
129 <sect1>
130         <title>Introduction</title>
131
132         <para>It is well known that UNIX and Microsoft Windows NT have
133         different models for representing user and group information and
134         use different technologies for implementing them. This fact has
135         made it difficult to integrate the two systems in a satisfactory
136         manner.</para>
137
138         <para>
139 <indexterm><primary>synchronization problems</primary></indexterm>
140 <indexterm><primary>passwords</primary></indexterm>
141         One common solution in use today has been to create
142         identically named user accounts on both the UNIX and Windows systems
143         and use the Samba suite of programs to provide file and print services
144         between the two. This solution is far from perfect, however, because
145         adding and deleting users on both sets of machines becomes a chore,
146         and two sets of passwords are required &smbmdash; both of which
147         can lead to synchronization problems between the UNIX and Windows
148         systems and confusion for users.</para>
149
150         <para>We divide the unified logon problem for UNIX machines into
151         three smaller problems:</para>
152
153         <itemizedlist>
154                 <listitem><para>Obtaining Windows NT user and group information.
155                 </para></listitem>
156
157                 <listitem><para>Authenticating Windows NT users.
158                 </para></listitem>
159
160                 <listitem><para>Password changing for Windows NT users.
161                 </para></listitem>
162         </itemizedlist>
163
164
165         <para>
166 <indexterm><primary>unified logon</primary></indexterm>
167 <indexterm><primary>duplication of information</primary></indexterm>
168         Ideally, a prospective solution to the unified logon problem
169         would satisfy all the above components without duplication of
170         information on the UNIX machines and without creating additional
171         tasks for the system administrator when maintaining users and
172         groups on either system. The Winbind system provides a simple
173         and elegant solution to all three components of the unified logon
174         problem.</para>
175 </sect1>
176
177
178 <sect1>
179         <title>What Winbind Provides</title>
180
181         <para>
182 <indexterm><primary>Windows account management</primary></indexterm>
183 <indexterm><primary>UNIX users</primary></indexterm>
184 <indexterm><primary>UNIX groups</primary></indexterm>
185 <indexterm><primary>NT domain</primary></indexterm>
186         Winbind unifies UNIX and Windows NT account management by
187         allowing a UNIX box to become a full member of an NT domain. Once
188         this is done, the UNIX box will see NT users and groups as if
189         they were <quote>native</quote> UNIX users and groups, allowing the NT domain
190         to be used in much the same manner that NIS+ is used within
191         UNIX-only environments.</para>
192
193         <para>
194 <indexterm><primary>Winbind hooks</primary></indexterm>
195 <indexterm><primary>domain controller</primary></indexterm>
196 <indexterm><primary>NSS</primary></indexterm>
197 <indexterm><primary>redirection</primary></indexterm>
198         The end result is that whenever a
199         program on the UNIX machine asks the operating system to look up
200         a user or group name, the query will be resolved by asking the
201         NT domain controller for the specified domain to do the lookup.
202         Because Winbind hooks into the operating system at a low level
203         (via the NSS name resolution modules in the C library), this
204         redirection to the NT domain controller is completely
205         transparent.</para>
206
207         <para>
208 <indexterm><primary>user and group</primary></indexterm>
209 <indexterm><primary>domain user</primary></indexterm>
210         Users on the UNIX machine can then use NT user and group
211         names as they would <quote>native</quote> UNIX names. They can chown files
212         so they are owned by NT domain users or even login to the
213         UNIX machine and run a UNIX X-Window session as a domain user.</para>
214
215         <para>
216 <indexterm><primary>domain controller</primary></indexterm>
217         The only obvious indication that Winbind is being used is
218         that user and group names take the form <constant>DOMAIN\user</constant> and
219         <constant>DOMAIN\group</constant>. This is necessary because it allows Winbind to determine
220         that redirection to a domain controller is wanted for a particular
221         lookup and which trusted domain is being referenced.</para>
222
223         <para>
224 <indexterm><primary>PAM-enabled</primary></indexterm>
225 <indexterm><primary>domain controller</primary></indexterm>
226         Additionally, Winbind provides an authentication service that hooks into the PAM system
227         to provide authentication via an NT domain to any PAM-enabled
228         applications. This capability solves the problem of synchronizing
229         passwords between systems, since all passwords are stored in a single
230         location (on the domain controller).</para>
231
232         <sect2>
233                 <title>Target Uses</title>
234
235                 <para>
236 <indexterm><primary>infrastructure</primary></indexterm>
237                 Winbind is targeted at organizations that have an
238                 existing NT-based domain infrastructure into which they wish
239                 to put UNIX workstations or servers. Winbind will allow these
240                 organizations to deploy UNIX workstations without having to
241                 maintain a separate account infrastructure. This greatly
242                 simplifies the administrative overhead of deploying UNIX
243                 workstations into an NT-based organization.</para>
244
245                 <para>
246 <indexterm><primary>Appliances</primary></indexterm>
247 <indexterm><primary>Winbind</primary></indexterm>
248                 Another interesting way in which we expect Winbind to
249                 be used is as a central part of UNIX-based appliances. Appliances
250                 that provide file and print services to Microsoft-based networks
251                 will be able to use Winbind to provide seamless integration of
252                 the appliance into the domain.</para>
253         </sect2>
254
255         <sect2>
256         <title>Handling of Foreign SIDs</title>
257
258         <para>
259 <indexterm><primary>foreign SID</primary></indexterm>
260         The term <emphasis>foreign SID</emphasis> is often met with the reaction that it
261         is not relevant to a particular environment. The following documents an interchange
262         that took place on the Samba mailing list. It is a good example of the confusion
263         often expressed regarding the use of winbind.
264         </para>
265
266         <para>
267 <indexterm><primary>local domain</primary></indexterm>
268         Fact: Winbind is needed to handle users who use workstations that are NOT part
269         of the local domain.
270         </para>
271
272         <para>
273 <indexterm><primary>PDC</primary></indexterm>
274         Response: <quote>Why? I've used Samba with workstations that are not part of my domains
275         lots of times without using winbind. I thought winbind was for using Samba as a member server
276         in a domain controlled by another Samba/Windows PDC.</quote>
277         </para>
278
279         <para>
280 <indexterm><primary>UID</primary></indexterm>
281 <indexterm><primary>GID</primary></indexterm>
282 <indexterm><primary>foreign user</primary></indexterm>
283         If the Samba server will be accessed from a domain other than the local Samba domain, or
284         if there will be access from machines that are not local domain members, winbind will
285         permit the allocation of UIDs and GIDs from the assigned pool that will keep the identity
286         of the foreign user separate from users that are members of the Samba domain.
287         </para>
288
289         <para>
290 <indexterm><primary>PDC</primary></indexterm>
291 <indexterm><primary>domain member</primary></indexterm>
292 <indexterm><primary>domain non-member</primary></indexterm>
293 <indexterm><primary>SID</primary></indexterm>
294         This means that winbind is eminently useful in cases where a single
295         Samba PDC on a local network is combined with both domain member and domain non-member workstations.
296         If winbind is not used, the user george on a Windows workstation that is not a domain
297         member will be able to access the files of a user called george in the account database
298         of the Samba server that is acting as a PDC. When winbind is used, the default condition
299         is that the local user george will be treated as the account DOMAIN\george and the
300         foreign (non-member of the domain) account will be treated as MACHINE\george because
301         each has a different SID.
302         </para>
303
304         </sect2>
305 </sect1>
306
307
308
309 <sect1>
310         <title>How Winbind Works</title>
311
312         <para>
313 <indexterm><primary>winbindd</primary></indexterm>
314 <indexterm><primary>UNIX domain socket</primary></indexterm>
315 <indexterm><primary>NSS</primary></indexterm>
316 <indexterm><primary>PAM</primary></indexterm>
317         The Winbind system is designed around a client/server
318         architecture. A long-running <command>winbindd</command> daemon
319         listens on a UNIX domain socket waiting for requests
320         to arrive. These requests are generated by the NSS and PAM
321         clients and are processed sequentially.</para>
322
323         <para>The technologies used to implement Winbind are described
324         in detail below.</para>
325
326         <sect2>
327                 <title>Microsoft Remote Procedure Calls</title>
328
329                 <para>
330 <indexterm><primary>Microsoft Remote Procedure Call</primary><see>MSRPC</see></indexterm>
331 <indexterm><primary>PDC</primary></indexterm>
332 <indexterm><primary>remote management</primary></indexterm>
333 <indexterm><primary>user authentication</primary></indexterm>
334 <indexterm><primary>print spooling</primary></indexterm>
335                 Over the last few years, efforts have been underway by various Samba Team members to implement various aspects of
336                 the Microsoft Remote Procedure Call (MSRPC) system. This system is used for most network-related operations
337                 between Windows NT machines, including remote management, user authentication, and print spooling. Although
338                 initially this work was done to aid the implementation of Primary Domain Controller (PDC) functionality in
339                 Samba, it has also yielded a body of code that can be used for other purposes.
340                 </para>
341
342                 <para>
343 <indexterm><primary>MSRPC</primary></indexterm>
344 <indexterm><primary>enumerate domain users</primary></indexterm>
345 <indexterm><primary>enumerate domain groups</primary></indexterm>
346                 Winbind uses various MSRPC calls to enumerate domain users and groups and to obtain detailed information about
347                 individual users or groups. Other MSRPC calls can be used to authenticate NT domain users and to change user
348                 passwords. By directly querying a Windows PDC for user and group information, Winbind maps the NT account
349                 information onto UNIX user and group names.
350                 </para>
351         </sect2>
352
353         <sect2>
354                 <title>Microsoft Active Directory Services</title>
355
356                 <para>
357 <indexterm><primary>LDAP</primary></indexterm>
358 <indexterm><primary>Kerberos</primary></indexterm>
359 <indexterm><primary>Winbind</primary></indexterm>
360 <indexterm><primary>native mode</primary></indexterm>
361                 Since late 2001, Samba has gained the ability to interact with Microsoft Windows 2000 using its <quote>native
362                 mode</quote> protocols rather than the NT4 RPC services.  Using LDAP and Kerberos, a domain member running
363                 Winbind can enumerate users and groups in exactly the same way as a Windows 200x client would, and in so doing
364                 provide a much more efficient and effective Winbind implementation.
365                 </para>
366         </sect2>
367
368         <sect2>
369                 <title>Name Service Switch</title>
370
371                 <para>
372 <indexterm><primary>NSS</primary></indexterm>
373 <indexterm><primary>networked workstation</primary></indexterm>
374 <indexterm><primary>NIS</primary></indexterm>
375 <indexterm><primary>DNS</primary></indexterm>
376                 The NSS is a feature that is present in many UNIX operating systems. It allows system
377                 information such as hostnames, mail aliases, and user information
378                 to be resolved from different sources. For example, a standalone
379                 UNIX workstation may resolve system information from a series of
380                 flat files stored on the local file system. A networked workstation
381                 may first attempt to resolve system information from local files,
382                 and then consult an NIS database for user information or a DNS server
383                 for hostname information.</para>
384
385                 <para>
386 <indexterm><primary>NSS</primary></indexterm>
387 <indexterm><primary>MSRPC</primary></indexterm>
388 <indexterm><primary>trusted domain</primary></indexterm>
389 <indexterm><primary>local users</primary></indexterm>
390 <indexterm><primary>local groups</primary></indexterm>
391                 The NSS application programming interface allows Winbind to present itself as a source of system
392                 information when resolving UNIX usernames and groups. Winbind uses this interface and information obtained
393                 from a Windows NT server using MSRPC calls to provide a new source of account enumeration. Using standard UNIX
394                 library calls, you can enumerate the users and groups on a UNIX machine running Winbind and see all users and
395                 groups in an NT domain plus any trusted domain as though they were local users and groups.
396                 </para>
397
398                 <para>
399 <indexterm><primary>NSS</primary></indexterm>
400 <indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
401 <indexterm><primary>passwd</primary></indexterm>
402                 The primary control file for NSS is <filename>/etc/nsswitch.conf</filename>.  When a UNIX application
403                 makes a request to do a lookup, the C library looks in <filename>/etc/nsswitch.conf</filename> for a line that
404                 matches the service type being requested; for example, the <quote>passwd</quote> service type is used when
405                 user or group names are looked up. This config line specifies which implementations of that service should be
406                 tried and in what order. If the passwd config line is:
407 <screen>
408 passwd: files example
409 </screen>
410 <indexterm><primary>/lib/libnss_files.so</primary></indexterm>
411 <indexterm><primary>/lib/libnss_example.so</primary></indexterm>
412 <indexterm><primary>resolver functions</primary></indexterm>
413                 then the C library will first load a module called <filename>/lib/libnss_files.so</filename> followed
414                 by the module <filename>/lib/libnss_example.so</filename>. The C library will dynamically load each of these
415                 modules in turn and call resolver functions within the modules to try to resolve the request. Once the request
416                 is resolved, the C library returns the result to the application.
417                 </para>
418
419                 <para>
420 <indexterm><primary>NSS</primary></indexterm>
421 <indexterm><primary>libnss_winbind.so</primary></indexterm>
422 <indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
423                 This NSS interface provides an easy way for Winbind to hook into the operating system. All that needs
424                 to be done is to put <filename>libnss_winbind.so</filename> in <filename>/lib/</filename> then add
425                 <quote>winbind</quote> into <filename>/etc/nsswitch.conf</filename> at the appropriate place. The C library
426                 will then call Winbind to resolve user and group names.
427                 </para>
428         </sect2>
429
430         <sect2>
431                 <title>Pluggable Authentication Modules</title>
432
433                 <para>
434 <indexterm><primary>PAM</primary></indexterm>
435 <indexterm><primary>authentication methods</primary></indexterm>
436 <indexterm><primary>authorization</primary></indexterm>
437 <indexterm><primary>NIS database</primary></indexterm>
438                 PAMs provide a system for abstracting authentication and authorization technologies. With a PAM
439                 module, it is possible to specify different authentication methods for different system applications without
440                 having to recompile these applications. PAM is also useful for implementing a particular policy for
441                 authorization. For example, a system administrator may only allow console logins from users stored in the
442                 local password file but only allow users resolved from an NIS database to log in over the network.
443                 </para>
444
445                 <para>
446 <indexterm><primary>PAM</primary></indexterm>
447 <indexterm><primary>Winbind</primary></indexterm>
448 <indexterm><primary>authentication management</primary></indexterm>
449 <indexterm><primary>password management</primary></indexterm>
450 <indexterm><primary>PDC</primary></indexterm>
451                 Winbind uses the authentication management and password management PAM interface to integrate Windows
452                 NT users into a UNIX system. This allows Windows NT users to log in to a UNIX machine and be authenticated
453                 against a suitable PDC.  These users can also change their passwords and have this change take effect directly
454                 on the PDC.
455                 </para>
456
457                 <para>
458 <indexterm><primary>PAM</primary></indexterm>
459 <indexterm><primary>/etc/pam.d/</primary></indexterm>
460 <indexterm><primary>pam_winbind.so</primary></indexterm>
461 <indexterm><primary>/lib/security/</primary></indexterm>
462                 PAM is configured by providing control files in the directory <filename>/etc/pam.d/</filename> for
463                 each of the services that require authentication. When an authentication request is made by an application,
464                 the PAM code in the C library looks up this control file to determine what modules to load to do the
465                 authentication check and in what order. This interface makes adding a new authentication service for Winbind
466                 very easy: simply copy the <filename>pam_winbind.so</filename> module to <filename>/lib/security/</filename>,
467                 and the PAM control files for relevant services are updated to allow authentication via Winbind. See the PAM
468                 documentation in <link linkend="pam">PAM-Based Distributed Authentication</link>, for more information.
469                 </para>
470         </sect2>
471
472         <sect2>
473                 <title>User and Group ID Allocation</title>
474
475                 <para>
476 <indexterm><primary>RID</primary></indexterm>
477 <indexterm><primary>Winbind</primary></indexterm>
478 <indexterm><primary>UNIX ID</primary></indexterm>
479                 When a user or group is created under Windows NT/200x, it is allocated a numerical relative identifier
480                 (RID). This is slightly different from UNIX, which has a range of numbers that are used to identify users and
481                 the same range used to identify groups. It is Winbind's job to convert RIDs to UNIX ID numbers and vice versa.
482                 When Winbind is configured, it is given part of the UNIX user ID space and a part of the UNIX group ID space
483                 in which to store Windows NT users and groups. If a Windows NT user is resolved for the first time, it is
484                 allocated the next UNIX ID from the range. The same process applies for Windows NT groups. Over time, Winbind
485                 will have mapped all Windows NT users and groups to UNIX user IDs and group IDs.
486                 </para>
487
488                 <para>
489 <indexterm><primary>ID mapping database</primary></indexterm>
490 <indexterm><primary>tdb</primary></indexterm>
491 <indexterm><primary>UNIX ID</primary></indexterm>
492 <indexterm><primary>RID</primary></indexterm>
493                 The results of this mapping are stored persistently in an ID mapping database held in a tdb database.
494                 This ensures that RIDs are mapped to UNIX IDs in a consistent way.
495                 </para>
496         </sect2>
497
498         <sect2>
499                 <title>Result Caching</title>
500
501                 <para>
502 <indexterm><primary>SAM</primary></indexterm>
503 <indexterm><primary>caching scheme</primary></indexterm>
504 <indexterm><primary>Winbind</primary></indexterm>
505 <indexterm><primary>ADS</primary></indexterm>
506 <indexterm><primary>PDC</primary></indexterm>
507                 An active directory system can generate a lot of user and group name lookups. To reduce the network
508                 cost of these lookups, Winbind uses a caching scheme based on the SAM sequence number supplied by NT domain
509                 controllers. User or group information returned by a PDC is cached by Winbind along with a sequence number
510                 also returned by the PDC. This sequence number is incremented by Windows NT whenever any user or group
511                 information is modified. If a cached entry has expired, the sequence number is requested from the PDC and
512                 compared against the sequence number of the cached entry.  If the sequence numbers do not match, then the
513                 cached information is discarded and up-to-date information is requested directly from the PDC.
514                 </para>
515         </sect2>
516 </sect1>
517
518
519 <sect1>
520         <title>Installation and Configuration</title>
521
522 <sect2>
523 <title>Introduction</title>
524
525 <para>
526 <indexterm><primary>Winbind</primary></indexterm>
527 <indexterm><primary>PDC</primary></indexterm>
528 <indexterm><primary>authentication control</primary></indexterm>
529 This section describes the procedures used to get Winbind up and running. Winbind is capable of providing
530 access and authentication control for Windows Domain users through an NT or Windows 200x PDC for regular
531 services, such as telnet and ftp, as well for Samba services.
532 </para>
533
534 <itemizedlist>
535 <listitem>
536         <para>
537         <emphasis>Why should I do this?</emphasis>
538         </para>
539
540         <para>
541 <indexterm><primary>Samba administrator</primary></indexterm>
542 <indexterm><primary>authentication mechanisms</primary></indexterm>
543 <indexterm><primary>domain members</primary></indexterm>
544 <indexterm><primary>accounts</primary></indexterm>
545 This allows the Samba administrator to rely on the authentication mechanisms on the Windows NT/200x PDC
546 for the authentication of domain members. Windows NT/200x users no longer need to have separate accounts on
547 the Samba server.
548         </para>
549 </listitem>
550
551 <listitem>
552         <para>
553         <emphasis>Who should be reading this document?</emphasis>
554         </para>
555
556         <para>
557 <indexterm><primary>PDC</primary></indexterm>
558 <indexterm><primary>Windows NT/200x</primary></indexterm>
559 This document is designed for system administrators. If you are implementing Samba on a file server and wish
560 to (fairly easily) integrate existing Windows NT/200x users from your PDC onto the Samba server, this document
561 is for you.
562         </para>
563 </listitem>
564 </itemizedlist>
565 </sect2>
566
567
568 <sect2>
569 <title>Requirements</title>
570
571 <para>
572 <indexterm><primary>PAM</primary></indexterm>
573 <indexterm><primary>back up</primary></indexterm>
574 <indexterm><primary>boot disk`</primary></indexterm>
575 If you have a Samba configuration file that you are currently using, <emphasis>BACK IT UP!</emphasis>
576 If your system already uses PAM, <emphasis>back up the <filename>/etc/pam.d</filename> directory
577 contents!</emphasis> If you haven't already made a boot disk, <emphasis>MAKE ONE NOW!</emphasis>
578 </para>
579
580 <para>
581 <indexterm><primary>PAM configuration</primary></indexterm>
582 <indexterm><primary>/etc/pam.d</primary></indexterm>
583 <indexterm><primary>single-user mode</primary></indexterm>
584 Messing with the PAM configuration files can make it nearly impossible to log in to your machine. That's
585 why you want to be able to boot back into your machine in single-user mode and restore your
586 <filename>/etc/pam.d</filename> to the original state it was in if you get frustrated with the
587 way things are going.
588 </para>
589
590 <para>
591 <indexterm><primary>winbindd</primary></indexterm>
592 <indexterm><primary>daemon</primary></indexterm>
593 The latest version of Samba-3 includes a functioning winbindd daemon. Please refer to the <ulink
594 url="http://samba.org/">main Samba Web page</ulink>, or better yet, your closest Samba mirror site for
595 instructions on downloading the source code.
596 </para>
597
598 <para>
599 <indexterm><primary>domain users</primary></indexterm>
600 <indexterm><primary>shares and files</primary></indexterm>
601 <indexterm><primary>PAM</primary></indexterm>
602 <indexterm><primary>development libraries</primary></indexterm>
603 To allow domain users the ability to access Samba shares and files, as well as potentially other services
604 provided by your Samba machine, PAM must be set up properly on your
605 machine. In order to compile the Winbind modules, you should have at least the PAM development libraries installed
606 on your system. Please refer to the PAM Web site <ulink url="http://www.kernel.org/pub/linux/libs/pam/"/>.
607 </para>
608 </sect2>
609
610 <sect2>
611 <title>Testing Things Out</title>
612
613 <para>
614 <indexterm><primary>smbd</primary></indexterm>
615 <indexterm><primary>nmbd</primary></indexterm>
616 <indexterm><primary>winbindd</primary></indexterm>
617 <indexterm><primary>/etc/pam.d</primary></indexterm>
618 <indexterm><primary>PAM</primary></indexterm>
619 Before starting, it is probably best to kill off all the Samba-related daemons running on your server.
620 Kill off all &smbd;, &nmbd;, and &winbindd; processes that may be running. To use PAM,
621 make sure that you have the standard PAM package that supplies the <filename>/etc/pam.d</filename>
622 directory structure, including the PAM modules that are used by PAM-aware services, several PAM libraries,
623 and the <filename>/usr/doc</filename> and <filename>/usr/man</filename> entries for PAM. Winbind is built
624 better in Samba if the pam-devel package is also installed. This package includes the header files
625 needed to compile PAM-aware applications.
626 </para>
627
628 <sect3>
629 <title>Configure <filename>nsswitch.conf</filename> and the Winbind Libraries on Linux and Solaris</title>
630
631 <para>
632 <indexterm><primary>PAM</primary></indexterm>
633 <indexterm><primary>pam-devel</primary></indexterm>
634 <indexterm><primary>Winbind</primary></indexterm>
635 <indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
636 PAM is a standard component of most current generation UNIX/Linux systems. Unfortunately, few systems install
637 the <filename>pam-devel</filename> libraries that are needed to build PAM-enabled Samba. Additionally, Samba-3
638 may auto-install the Winbind files into their correct locations on your system, so before you get too far down
639 the track, be sure to check if the following configuration is really
640 necessary. You may only need to configure
641 <filename>/etc/nsswitch.conf</filename>.
642 </para>
643
644 <para>
645 The libraries needed to run the &winbindd; daemon through nsswitch need to be copied to their proper locations:
646 </para>
647
648 <para>
649 <indexterm><primary>libnss_winbind.so</primary></indexterm>
650 <screen>
651 &rootprompt;<userinput>cp ../samba/source/nsswitch/libnss_winbind.so /lib</userinput>
652 </screen>
653 </para>
654
655 <para>
656 I also found it necessary to make the following symbolic link:
657 </para>
658
659 <para>
660 &rootprompt; <userinput>ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2</userinput>
661 </para>
662
663 <para>And, in the case of Sun Solaris:
664 <indexterm><primary>nss_winbind.so.1</primary></indexterm>
665 <screen>
666 &rootprompt;<userinput>ln -s /usr/lib/libnss_winbind.so /usr/lib/libnss_winbind.so.1</userinput>
667 &rootprompt;<userinput>ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.1</userinput>
668 &rootprompt;<userinput>ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.2</userinput>
669 </screen>
670 </para>
671
672 <para>
673 <indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
674 As root, edit <filename>/etc/nsswitch.conf</filename> to allow user and group entries to be visible from the
675 &winbindd; daemon. My <filename>/etc/nsswitch.conf</filename> file looked like this after editing:
676 <programlisting>
677 passwd:     files winbind
678 shadow:     files
679 group:      files winbind
680 </programlisting></para>
681
682 <para>
683 <indexterm><primary>winbindd</primary></indexterm>
684 <indexterm><primary>ldconfig</primary></indexterm>
685 <indexterm><primary>libnss_winbind</primary></indexterm>
686 <indexterm><primary>grep</primary></indexterm>
687 <indexterm><primary>dynamic link loader</primary></indexterm>
688 The libraries needed by the <command>winbindd</command> daemon will be automatically
689 entered into the <command>ldconfig</command> cache the next time
690 your system reboots, but it is faster (and you do not need to reboot) if you do it manually:
691 <screen>
692 &rootprompt;<userinput>/sbin/ldconfig -v | grep winbind</userinput>
693 </screen>
694 This makes <filename>libnss_winbind</filename> available to winbindd and reports the current
695 search path that is used by the dynamic link loader. The use of the <command>grep</command>
696 filters the output of the <command>ldconfig</command> command so that we may see proof that
697 this library is indeed recognized by the dynamic link loader.
698 </para>
699
700 <para>
701 <indexterm><primary>dynamic link loader</primary></indexterm>
702 <indexterm><primary>crle</primary></indexterm>
703 <indexterm><primary>/usr/local/lib</primary></indexterm>
704 <indexterm><primary>link loader configuration</primary></indexterm>
705 <indexterm><primary>object module dependencies</primary></indexterm>
706 The Sun Solaris dynamic link loader management tool is called <command>crle</command>. The
707 use of this tool is necessary to instruct the dynamic link loader to search directories that
708 contain library files that were not supplied as part of the original operating system platform.
709 The following example shows how to use this tool to add the directory <filename>/usr/local/lib</filename>
710 to the dynamic link loader's search path:
711 <screen>
712 &rootprompt; crle -u -l /usr/lib:/usr/local/lib
713 </screen>
714 When executed without arguments, <command>crle</command> reports the current dynamic
715 link loader configuration. This is demonstrated here:
716 <screen>
717 &rootprompt; crle
718
719 Configuration file [version 4]: /var/ld/ld.config
720   Default Library Path (ELF):   /lib:/usr/lib:/usr/local/lib
721   Trusted Directories (ELF):    /lib/secure:/usr/lib/secure  (system default)
722
723 Command line:
724   crle -c /var/ld/ld.config -l /lib:/usr/lib:/usr/local/lib
725 </screen>
726 From this it is apparent that the <filename>/usr/local/lib</filename> directory is included
727 in the search dynamic link libraries in order to satisfy object module dependencies.
728 </para>
729
730 </sect3>
731
732 <sect3>
733 <title>NSS Winbind on AIX</title>
734
735 <para>(This section is only for those running AIX.)</para>
736
737 <para>
738 <indexterm><primary>AIX</primary></indexterm>
739 <indexterm><primary>Winbind</primary></indexterm>
740 <indexterm><primary>/usr/lib/security</primary></indexterm>
741 <indexterm><primary>authentication module API</primary></indexterm>
742 <indexterm><primary>/usr/lib/security/methods.cfg</primary></indexterm>
743 <indexterm><primary>PAM module</primary></indexterm>
744 The Winbind AIX identification module gets built as <filename>libnss_winbind.so</filename> in the
745 nsswitch directory of the Samba source. This file can be copied to <filename>/usr/lib/security</filename>,
746 and the AIX naming convention would indicate that it should be named WINBIND. A stanza like the following:
747 <programlisting>
748 WINBIND:
749         program = /usr/lib/security/WINBIND
750         options = authonly
751 </programlisting>
752 can then be added to <filename>/usr/lib/security/methods.cfg</filename>. This module only supports
753 identification, but there have been reports of success using the standard Winbind PAM module for
754 authentication. Use caution configuring loadable authentication modules, since misconfiguration can make
755 it impossible to log on to the system.  Information regarding the AIX authentication module API can
756 be found in the <quote>Kernel Extensions and Device Support Programming Concepts for AIX</quote> document that
757 describes the <ulink url="http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixprggd/kernextc/sec_load_mod.htm">
758 Loadable Authentication Module Programming Interface</ulink> for AIX. Further information on administering the modules
759 can be found in the <ulink url="http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/baseadmn/iandaadmin.htm">System
760 Management Guide: Operating System and Devices.</ulink>
761 </para>
762 </sect3>
763
764 <sect3>
765 <title>Configure smb.conf</title>
766
767 <para>
768 <indexterm><primary>winbind</primary></indexterm>
769 <indexterm><primary>man page</primary></indexterm>
770 <indexterm><primary>winbindd</primary></indexterm>
771 Several parameters are needed in the &smb.conf; file to control the behavior of &winbindd;. These
772 are described in more detail in the <citerefentry><refentrytitle>winbindd</refentrytitle>
773 <manvolnum>8</manvolnum></citerefentry> man page. My &smb.conf; file, as shown in <link
774 linkend="winbindcfg">the smb.conf for Winbind Setup</link>, was modified to include the necessary entries in the [global] section.
775 </para>
776
777 <example id="winbindcfg">
778 <title>smb.conf for Winbind Setup</title>
779 <smbconfblock>
780 <smbconfsection name="[global]"/>
781 <smbconfcomment> separate domain and username with '\', like DOMAIN\username</smbconfcomment>
782 <smbconfoption name="winbind separator">\</smbconfoption>
783 <smbconfcomment> use uids from 10000 to 20000 for domain users</smbconfcomment>
784 <smbconfoption name="idmap uid">10000-20000</smbconfoption>
785 <smbconfcomment> use gids from 10000 to 20000 for domain groups</smbconfcomment>
786 <smbconfoption name="idmap gid">10000-20000</smbconfoption>
787 <smbconfcomment> allow enumeration of winbind users and groups</smbconfcomment>
788 <smbconfoption name="winbind enum users">yes</smbconfoption>
789 <smbconfoption name="winbind enum groups">yes</smbconfoption>
790 <smbconfcomment> give winbind users a real shell (only needed if they have telnet access)</smbconfcomment>
791 <smbconfoption name="template homedir">/home/winnt/%D/%U</smbconfoption>
792 <smbconfoption name="template shell">/bin/bash</smbconfoption>
793 </smbconfblock>
794 </example>
795
796 </sect3>
797
798
799 <sect3>
800 <title>Join the Samba Server to the PDC Domain</title>
801
802 <para>
803 <indexterm><primary>domain security</primary></indexterm>
804 <indexterm><primary>PDC</primary></indexterm>
805 <indexterm><primary>BDC</primary></indexterm>
806 All machines that will participate in domain security should be members of
807 the domain. This applies also to the PDC and all BDCs.
808 </para>
809
810 <para>
811 <indexterm><primary>joining domain</primary></indexterm>
812 <indexterm><primary>domain join</primary></indexterm>
813 <indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm>
814 <indexterm><primary>smbd</primary></indexterm>
815 <indexterm><primary>PDC</primary></indexterm>
816 <indexterm><primary>domain controller</primary></indexterm>
817 <indexterm><primary>MS DCE RPC</primary></indexterm>
818 <indexterm><primary>DCE RPC</primary></indexterm>
819 <indexterm><primary>RPC</primary></indexterm>
820 The process of joining a domain requires the use of the <command>net rpc join</command>
821 command. This process communicates with the domain controller it will register with
822 (usually the PDC) via MS DCE RPC. This means, of course, that the <command>smbd</command>
823 process must be running on the target domain controller. It is therefore necessary to temporarily
824 start Samba on a PDC so that it can join its own domain.
825 </para>
826
827 <para>
828 <indexterm><primary>PDC</primary></indexterm>
829 <indexterm><primary>administrative privileges</primary></indexterm>
830 <indexterm><primary>Administrator</primary></indexterm>
831 Enter the following command to make the Samba server join the domain, where <replaceable>PDC</replaceable> is
832 the name of your PDC and <replaceable>Administrator</replaceable> is a domain user who has administrative
833 privileges in the domain.
834 </para>
835
836 <note><para>
837 <indexterm><primary>domain controller</primary></indexterm>
838 <indexterm><primary>PDC</primary></indexterm>
839 <indexterm><primary>tcp ports</primary></indexterm>
840 <indexterm><primary>udp ports</primary></indexterm>
841 Before attempting to join a machine to the domain, verify that Samba is running
842 on the target domain controller (usually PDC) and that it is capable of being reached via ports
843 137/udp, 135/tcp, 139/tcp, and 445/tcp (if Samba or Windows Server 2Kx).
844 </para></note>
845
846 <para>
847 <indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm>
848 The use of the <command>net rpc join</command> facility is shown here:
849 <screen>
850 &rootprompt;<userinput>/usr/local/samba/bin/net rpc join -S PDC -U Administrator</userinput>
851 </screen>
852 The proper response to the command should be <quote>Joined the domain
853 <replaceable>DOMAIN</replaceable></quote> where <replaceable>DOMAIN</replaceable>
854 is your domain name.
855 </para>
856
857 </sect3>
858
859 <sect3>
860 <title>Starting and Testing the <command>winbindd</command> Daemon</title>
861
862 <para>
863 <indexterm><primary>startup script</primary></indexterm>
864 <indexterm><primary>winbindd</primary></indexterm>
865 <indexterm><primary>Winbind services</primary></indexterm>
866 Eventually, you will want to modify your Samba startup script to automatically invoke the winbindd daemon when
867 the other parts of Samba start, but it is possible to test out just the Winbind portion first. To start up
868 Winbind services, enter the following command as root:
869 <screen>
870 &rootprompt;<userinput>/usr/local/samba/sbin/winbindd</userinput>
871 </screen>
872 Use the appropriate path to the location of the <command>winbindd</command> executable file.
873 </para>
874
875 <note><para>
876 <indexterm><primary>Winbind</primary></indexterm>
877 <indexterm><primary>/usr/local/samba</primary></indexterm>
878 The command to start up Winbind services assumes that Samba has been installed in the
879 <filename>/usr/local/samba</filename> directory tree. You may need to search for the location of Samba files
880 if this is not the location of <command>winbindd</command> on your system.
881 </para></note>
882
883 <para>
884 <indexterm><primary>paranoid</primary></indexterm>
885 <indexterm><primary>daemon running</primary></indexterm>
886 I'm always paranoid and like to make sure the daemon is really running.
887 <screen>
888 &rootprompt;<userinput>ps -ae | grep winbindd</userinput>
889 </screen>
890 </para>
891
892 <para>
893 <indexterm><primary>winbindd</primary></indexterm>
894 This command should produce output like the following if the daemon is running.
895 <screen>
896 3025 ?        00:00:00 winbindd
897 </screen>
898 </para>
899
900 <para>
901 <indexterm><primary>PDC</primary></indexterm>
902 <indexterm><primary>wbinfo</primary></indexterm>
903 Now, for the real test, try to get some information about the users on your PDC:
904 <screen>
905 &rootprompt;<userinput>/usr/local/samba/bin/wbinfo -u</userinput>
906 </screen>
907 This should echo back a list of users on your Windows users on your PDC. For example, I get the following
908 response:
909 <screen>
910 CEO\Administrator
911 CEO\burdell
912 CEO\Guest
913 CEO\jt-ad
914 CEO\krbtgt
915 CEO\TsInternetUser
916 </screen>
917 Obviously, I have named my domain <quote>CEO</quote> and my <smbconfoption name="winbind separator"/> is
918 <quote>\</quote>.
919 </para>
920
921 <para>
922 <indexterm><primary>wbinfo</primary></indexterm>
923 <indexterm><primary>PDC</primary></indexterm>
924 You can do the same sort of thing to get group information from the PDC:
925 <screen>
926 &rootprompt;<userinput>/usr/local/samba/bin/wbinfo -g</userinput>
927 CEO\Domain Admins
928 CEO\Domain Users
929 CEO\Domain Guests
930 CEO\Domain Computers
931 CEO\Domain Controllers
932 CEO\Cert Publishers
933 CEO\Schema Admins
934 CEO\Enterprise Admins
935 CEO\Group Policy Creator Owners
936 </screen></para>
937
938 <para>
939 <indexterm><primary>getent</primary></indexterm>
940 <indexterm><primary>PDC</primary></indexterm>
941 <indexterm><primary>/etc/passwd</primary></indexterm>
942 <indexterm><primary>UID</primary></indexterm>
943 <indexterm><primary>GID</primary></indexterm>
944 <indexterm><primary>home directories</primary></indexterm>
945 <indexterm><primary>default shells</primary></indexterm>
946 The function <command>getent</command> can now be used to get unified lists of both local and PDC users and
947 groups. Try the following command:
948 <screen>
949 &rootprompt;<userinput>getent passwd</userinput>
950 </screen>
951 You should get a list that looks like your <filename>/etc/passwd</filename>
952 list followed by the domain users with their new UIDs, GIDs, home
953 directories, and default shells.
954 </para>
955
956 <para>
957 The same thing can be done for groups with the command:
958 <screen>
959 &rootprompt;<userinput>getent group</userinput>
960 </screen>
961 </para>
962
963 </sect3>
964
965
966 <sect3>
967 <title>Fix the init.d Startup Scripts</title>
968
969 <sect4>
970 <title>Linux</title>
971
972 <para>
973 <indexterm><primary>winbindd daemon</primary></indexterm>
974 <indexterm><primary>smbd</primary></indexterm>
975 <indexterm><primary>nmbd</primary></indexterm>
976 <indexterm><primary>/etc/init.d/smb</primary></indexterm>
977 <indexterm><primary>/etc/init.d/samba</primary></indexterm>
978 <indexterm><primary>/usr/local/samba/bin</primary></indexterm>
979 <indexterm><primary></primary></indexterm>
980 <indexterm><primary></primary></indexterm>
981 <indexterm><primary></primary></indexterm>
982 The &winbindd; daemon needs to start up after the &smbd; and &nmbd; daemons are running.  To accomplish this
983 task, you need to modify the startup scripts of your system.  They are located at
984 <filename>/etc/init.d/smb</filename> in Red Hat Linux and in <filename>/etc/init.d/samba</filename> in Debian
985 Linux. Edit your script to add commands to invoke this daemon in the proper sequence. My startup script starts
986 up &smbd;, &nmbd;, and &winbindd; from the <filename>/usr/local/samba/bin</filename> directory directly. The
987 <command>start</command> function in the script looks like this:
988 <programlisting>
989 start() {
990         KIND="SMB"
991         echo -n $"Starting $KIND services: "
992         daemon /usr/local/samba/bin/smbd $SMBDOPTIONS
993         RETVAL=$?
994         echo
995         KIND="NMB"
996         echo -n $"Starting $KIND services: "
997         daemon /usr/local/samba/bin/nmbd $NMBDOPTIONS
998         RETVAL2=$?
999         echo
1000         KIND="Winbind"
1001         echo -n $"Starting $KIND services: "
1002         daemon /usr/local/samba/sbin/winbindd
1003         RETVAL3=$?
1004         echo
1005         [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 -a $RETVAL3 -eq 0 ] &amp;&amp; \
1006                 touch /var/lock/subsys/smb || RETVAL=1
1007         return $RETVAL
1008 }
1009 </programlisting></para>
1010
1011 <para>If you would like to run winbindd in dual daemon mode, replace the line:
1012 <programlisting>
1013         daemon /usr/local/samba/sbin/winbindd
1014 </programlisting>
1015
1016 in the example above with:
1017
1018 <programlisting>
1019         daemon /usr/local/samba/sbin/winbindd -D
1020 </programlisting>.
1021 </para>
1022
1023 <para>
1024 The <command>stop</command> function has a corresponding entry to shut down the services and looks like this:
1025 </para>
1026
1027 <para><programlisting>
1028 stop() {
1029         KIND="SMB"
1030         echo -n $"Shutting down $KIND services: "
1031         killproc smbd
1032         RETVAL=$?
1033         echo
1034         KIND="NMB"
1035         echo -n $"Shutting down $KIND services: "
1036         killproc nmbd
1037         RETVAL2=$?
1038         echo
1039         KIND="Winbind"
1040         echo -n $"Shutting down $KIND services: "
1041         killproc winbindd
1042         RETVAL3=$?
1043         [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 -a $RETVAL3 -eq 0 ] &amp;&amp; \
1044                  rm -f /var/lock/subsys/smb
1045         echo ""
1046         return $RETVAL
1047 }
1048 </programlisting></para>
1049 </sect4>
1050
1051 <sect4>
1052 <title>Solaris</title>
1053
1054 <para>
1055 Winbind does not work on Solaris 9; see <link linkend="winbind-solaris9">Winbind on Solaris 9 section</link>
1056 for details.
1057 </para>
1058
1059 <para>
1060 <indexterm><primary>Solaris 9</primary></indexterm>
1061 <indexterm><primary>/etc/init.d/samba.server</primary></indexterm>
1062 <indexterm><primary>/usr/local/samba/bin</primary></indexterm>
1063 <indexterm><primary>smbd</primary></indexterm>
1064 <indexterm><primary>nmbd</primary></indexterm>
1065 <indexterm><primary>winbindd</primary></indexterm>
1066 On Solaris, you need to modify the <filename>/etc/init.d/samba.server</filename> startup script. It
1067 usually only starts smbd and nmbd but should now start winbindd, too. If you have Samba installed in
1068 <filename>/usr/local/samba/bin</filename>, the file could contains something like this:
1069 </para>
1070
1071 <para>
1072         <programlisting>
1073         ##
1074         ## samba.server
1075         ##
1076
1077         if [ ! -d /usr/bin ]
1078         then                    # /usr not mounted
1079                 exit
1080         fi
1081
1082         killproc() {            # kill the named process(es)
1083                 pid=`/usr/bin/ps -e |
1084                      /usr/bin/grep -w $1 |
1085                      /usr/bin/sed -e 's/^  *//' -e 's/ .*//'`
1086                 [ "$pid" != "" ] &amp;&amp; kill $pid
1087         }
1088
1089         # Start/stop processes required for Samba server
1090
1091         case "$1" in
1092
1093         'start')
1094         #
1095         # Edit these lines to suit your installation (paths, workgroup, host)
1096         #
1097         echo Starting SMBD
1098            /usr/local/samba/bin/smbd -D -s \
1099                 /usr/local/samba/smb.conf
1100
1101         echo Starting NMBD
1102            /usr/local/samba/bin/nmbd -D -l \
1103                 /usr/local/samba/var/log -s /usr/local/samba/smb.conf
1104
1105         echo Starting Winbind Daemon
1106            /usr/local/samba/sbin/winbindd
1107            ;;
1108
1109         'stop')
1110            killproc nmbd
1111            killproc smbd
1112            killproc winbindd
1113            ;;
1114
1115         *)
1116            echo "Usage: /etc/init.d/samba.server { start | stop }"
1117            ;;
1118         esac
1119 </programlisting></para>
1120
1121 <para>
1122 Again, if you would like to run Samba in dual daemon mode, replace:
1123 <programlisting>
1124 /usr/local/samba/sbin/winbindd
1125 </programlisting>
1126 in the script above with:
1127 <programlisting>
1128 /usr/local/samba/sbin/winbindd -D
1129 </programlisting>
1130 </para>
1131
1132 </sect4>
1133
1134 <sect4>
1135 <title>Restarting</title>
1136 <para>
1137 <indexterm><primary>daemons</primary></indexterm>
1138 <indexterm><primary>local user</primary></indexterm>
1139 If you restart the &smbd;, &nmbd;, and &winbindd; daemons at this point, you
1140 should be able to connect to the Samba server as a domain member just as
1141 if you were a local user.
1142 </para>
1143 </sect4>
1144 </sect3>
1145
1146 <sect3>
1147 <title>Configure Winbind and PAM</title>
1148
1149 <para>
1150 <indexterm><primary>winbindd</primary></indexterm>
1151 <indexterm><primary>authentication</primary></indexterm>
1152 <indexterm><primary>PAM</primary></indexterm>
1153 <indexterm><primary>/etc/pam.d</primary></indexterm>
1154 If you have made it this far, you know that <command>winbindd</command> and Samba are working together. If you
1155 want to use Winbind to provide authentication for other services, keep reading. The PAM configuration files
1156 need to be altered in this step. (Did you remember to make backups of your original
1157 <filename>/etc/pam.d</filename> files? If not, do it now.)
1158 </para>
1159
1160 <para>
1161 <indexterm><primary>NSS</primary></indexterm>
1162 <indexterm><primary>../source/nsswitch</primary></indexterm>
1163 <indexterm><primary>pam_winbind.so</primary></indexterm>
1164 <indexterm><primary>/lib/security</primary></indexterm>
1165 <indexterm><primary>Solaris</primary></indexterm>
1166 <indexterm><primary>/usr/lib/security</primary></indexterm>
1167 You will need a PAM module to use winbindd with these other services. This module will be compiled in the
1168 <filename>../source/nsswitch</filename> directory by invoking the command:
1169 <screen>
1170 &rootprompt;<userinput>make nsswitch/pam_winbind.so</userinput>
1171 </screen>
1172 from the <filename>../source</filename> directory. The <filename>pam_winbind.so</filename> file should be
1173 copied to the location of your other PAM security modules. On my Red Hat system, this was the
1174 <filename>/lib/security</filename> directory. On Solaris, the PAM security modules reside in
1175 <filename>/usr/lib/security</filename>.
1176 <screen>
1177 &rootprompt;<userinput>cp ../samba/source/nsswitch/pam_winbind.so /lib/security</userinput>
1178 </screen>
1179 </para>
1180
1181 <sect4>
1182 <title>Linux/FreeBSD-Specific PAM Configuration</title>
1183
1184 <para>
1185 <indexterm><primary>/etc/pam.d/samba</primary></indexterm>
1186 The <filename>/etc/pam.d/samba</filename> file does not need to be changed. I just left this file as it was:
1187 <programlisting>
1188 auth    required  /lib/security/pam_stack.so service=system-auth
1189 account required  /lib/security/pam_stack.so service=system-auth
1190 </programlisting></para>
1191
1192 <para>
1193 <indexterm><primary>Winbind</primary></indexterm>
1194 <indexterm><primary>authentication service</primary></indexterm>
1195 <indexterm><primary>login</primary></indexterm>
1196 <indexterm><primary>console</primary></indexterm>
1197 <indexterm><primary>telnet logins</primary></indexterm>
1198 <indexterm><primary>ftp service</primary></indexterm>
1199 <indexterm><primary>/etc/xinetd.d</primary></indexterm>
1200 <indexterm><primary>/etc/inetd.conf</primary></indexterm>
1201 <indexterm><primary>/etc/xinetd.d/telnet</primary></indexterm>
1202 The other services that I modified to allow the use of Winbind as an authentication service were the normal
1203 login on the console (or a terminal session), telnet logins, and ftp service. In order to enable these
1204 services, you may first need to change the entries in <filename>/etc/xinetd.d</filename> (or
1205 <filename>/etc/inetd.conf</filename>).  Red Hat Linux 7.1 and later uses the new xinetd.d structure, in this
1206 case you need to change the lines in <filename>/etc/xinetd.d/telnet</filename> and
1207 <filename>/etc/xinetd.d/wu-ftp</filename> from:
1208 <programlisting>
1209         enable = no
1210 </programlisting>
1211 to
1212 <programlisting>
1213         enable = yes
1214 </programlisting></para>
1215
1216 <para>
1217 <indexterm><primary>ftp services</primary></indexterm>
1218 <indexterm><primary>home directory template</primary></indexterm>
1219 <indexterm><primary>domain users</primary></indexterm>
1220 For ftp services to work properly, you will also need to either have individual directories for the domain
1221 users already present on the server or change the home directory template to a general directory for all
1222 domain users. These can be easily set using the &smb.conf; global entry <smbconfoption name="template
1223 homedir"/>.
1224 </para>
1225
1226 <note><para>
1227 <indexterm><primary>pam_mkhomedir</primary></indexterm>
1228 The directory in <smbconfoption name="template homedir"/> is not created automatically! Use pam_mkhomedir or
1229 pre-create the directories of users to make sure users can log in on UNIX with their own home directory.
1230 </para></note>
1231
1232 <para>
1233 <indexterm><primary>/etc/pam.d/ftp</primary></indexterm>
1234 <indexterm><primary>Winbind</primary></indexterm>
1235 <indexterm><primary>ftp access</primary></indexterm>
1236 The <filename>/etc/pam.d/ftp</filename> file can be changed to allow Winbind ftp access in a manner similar to
1237 the samba file. My <filename>/etc/pam.d/ftp</filename> file was changed to look like this:
1238 <programlisting>
1239 auth       required     /lib/security/pam_listfile.so item=user sense=deny \
1240          file=/etc/ftpusers onerr=succeed
1241 auth       sufficient   /lib/security/pam_winbind.so
1242 auth       required     /lib/security/pam_stack.so service=system-auth
1243 auth       required     /lib/security/pam_shells.so
1244 account    sufficient   /lib/security/pam_winbind.so
1245 account    required     /lib/security/pam_stack.so service=system-auth
1246 session    required     /lib/security/pam_stack.so service=system-auth
1247 </programlisting></para>
1248
1249 <para>
1250 <indexterm><primary>/etc/pam.d/login</primary></indexterm>
1251 The <filename>/etc/pam.d/login</filename> file can be changed in nearly the same way. It now looks like this:
1252 <programlisting>
1253 auth       required     /lib/security/pam_securetty.so
1254 auth       sufficient   /lib/security/pam_winbind.so
1255 auth       sufficient   /lib/security/pam_unix.so use_first_pass
1256 auth       required     /lib/security/pam_stack.so service=system-auth
1257 auth       required     /lib/security/pam_nologin.so
1258 account    sufficient   /lib/security/pam_winbind.so
1259 account    required     /lib/security/pam_stack.so service=system-auth
1260 password   required     /lib/security/pam_stack.so service=system-auth
1261 session    required     /lib/security/pam_stack.so service=system-auth
1262 session    optional     /lib/security/pam_console.so
1263 </programlisting>
1264 <indexterm><primary>pam_winbind.so</primary></indexterm>
1265 <indexterm><primary>pam_securetty.so</primary></indexterm>
1266 <indexterm><primary>pam_unix.so</primary></indexterm>
1267 In this case, I added the <programlisting>auth sufficient /lib/security/pam_winbind.so</programlisting> lines
1268 as before, but also added the <programlisting>required pam_securetty.so</programlisting> above it to disallow
1269 root logins over the network. I also added a <programlisting>sufficient /lib/security/pam_unix.so
1270 use_first_pass</programlisting> line after the <command>winbind.so</command> line to get rid of annoying
1271 double prompts for passwords.
1272 </para>
1273
1274 </sect4>
1275
1276 <sect4>
1277 <title>Solaris-Specific Configuration</title>
1278
1279 <para>
1280 <indexterm><primary>/etc/pam.conf</primary></indexterm>
1281 <indexterm><primary></primary></indexterm>
1282 The <filename>/etc/pam.conf</filename> needs to be changed. I changed this file so my Domain
1283 users can log on both locally as well as with telnet. The following are the changes
1284 that I made. You can customize the <filename>pam.conf</filename> file as per your requirements, but
1285 be sure of those changes because in the worst case it will leave your system
1286 nearly impossible to boot.
1287 <programlisting>
1288 #
1289 #ident "@(#)pam.conf 1.14 99/09/16 SMI"
1290 #
1291 # Copyright (c) 1996-1999, Sun Microsystems, Inc.
1292 # All Rights Reserved.
1293 #
1294 # PAM configuration
1295 #
1296 # Authentication management
1297 #
1298 login   auth required   /usr/lib/security/pam_winbind.so
1299 login auth required  /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass
1300 login auth required  /usr/lib/security/$ISA/pam_dial_auth.so.1 try_first_pass
1301 #
1302 rlogin  auth sufficient /usr/lib/security/pam_winbind.so
1303 rlogin  auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1
1304 rlogin auth required  /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass
1305 #
1306 dtlogin auth sufficient /usr/lib/security/pam_winbind.so
1307 dtlogin auth required  /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass
1308 #
1309 rsh auth required /usr/lib/security/$ISA/pam_rhosts_auth.so.1
1310 other   auth sufficient /usr/lib/security/pam_winbind.so
1311 other auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass
1312 #
1313 # Account management
1314 #
1315 login   account sufficient      /usr/lib/security/pam_winbind.so
1316 login account requisite /usr/lib/security/$ISA/pam_roles.so.1
1317 login account required /usr/lib/security/$ISA/pam_unix.so.1
1318 #
1319 dtlogin account sufficient      /usr/lib/security/pam_winbind.so
1320 dtlogin account requisite /usr/lib/security/$ISA/pam_roles.so.1
1321 dtlogin account required /usr/lib/security/$ISA/pam_unix.so.1
1322 #
1323 other   account sufficient      /usr/lib/security/pam_winbind.so
1324 other account requisite /usr/lib/security/$ISA/pam_roles.so.1
1325 other account required /usr/lib/security/$ISA/pam_unix.so.1
1326 #
1327 # Session management
1328 #
1329 other session required /usr/lib/security/$ISA/pam_unix.so.1
1330 #
1331 # Password management
1332 #
1333 #other   password sufficient     /usr/lib/security/pam_winbind.so
1334 other password required /usr/lib/security/$ISA/pam_unix.so.1
1335 dtsession auth required /usr/lib/security/$ISA/pam_unix.so.1
1336 #
1337 # Support for Kerberos V5 authentication (uncomment to use Kerberos)
1338 #
1339 #rlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
1340 #login auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
1341 #dtlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
1342 #other auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
1343 #dtlogin account optional /usr/lib/security/$ISA/pam_krb5.so.1
1344 #other account optional /usr/lib/security/$ISA/pam_krb5.so.1
1345 #other session optional /usr/lib/security/$ISA/pam_krb5.so.1
1346 #other password optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
1347 </programlisting></para>
1348
1349 <para>
1350 <indexterm><primary>winbind.so</primary></indexterm>
1351 I also added a <parameter>try_first_pass</parameter> line after the <filename>winbind.so</filename>
1352 line to get rid of annoying double prompts for passwords.
1353 </para>
1354
1355 <para>
1356 Now restart your Samba and try connecting through your application that you
1357 configured in the pam.conf.
1358 </para>
1359
1360 </sect4>
1361
1362 </sect3>
1363
1364 </sect2>
1365
1366 </sect1>
1367
1368 <sect1>
1369 <title>Conclusion</title>
1370
1371 <para>
1372 <indexterm><primary>Winbind</primary></indexterm>
1373 <indexterm><primary>NSS</primary></indexterm>
1374 <indexterm><primary>PAM</primary></indexterm>
1375 <indexterm><primary>RPC calls</primary></indexterm>
1376 <indexterm><primary>domain users</primary></indexterm>
1377 The Winbind system, through the use of the NSS, PAMs, and appropriate Microsoft RPC calls, have allowed us to
1378 provide seamless integration of Microsoft Windows NT domain users on a UNIX system. The result is a great
1379 reduction in the administrative cost of running a mixed UNIX and NT network.
1380 </para>
1381
1382 </sect1>
1383
1384 <sect1>
1385 <title>Common Errors</title>
1386
1387         <para>
1388         Winbind has a number of limitations in its current released version that we hope to overcome in future releases:
1389         </para>
1390
1391         <itemizedlist>
1392                 <listitem><para>
1393                 Winbind is currently only available for the Linux, Solaris, AIX, and IRIX operating systems, although
1394                 ports to other operating systems are certainly possible. For such ports to be feasible, we require the C
1395                 library of the target operating system to support the NSS and PAM systems. This is becoming more common as NSS
1396                 and PAM gain support among UNIX vendors.
1397                 </para></listitem>
1398
1399                 <listitem><para>
1400                 The mappings of Windows NT RIDs to UNIX IDs is not made algorithmically and depends on the order in
1401                 which unmapped users or groups are seen by Winbind. It may be difficult to recover the mappings of RID to UNIX
1402                 ID if the file containing this information is corrupted or destroyed.
1403                 </para></listitem>
1404
1405                 <listitem><para>
1406                 Currently the Winbind PAM module does not take into account possible workstation and logon time
1407                 restrictions that may be set for Windows NT users; this is instead up to the PDC to enforce.
1408                 </para></listitem>
1409         </itemizedlist>
1410
1411         <sect2>
1412         <title>NSCD Problem Warning</title>
1413
1414         <warning><para>
1415         Do not under any circumstances run <command>nscd</command> on any system
1416         on which <command>winbindd</command> is running.
1417         </para></warning>
1418
1419         <para>
1420         If <command>nscd</command> is running on the UNIX/Linux system, then
1421         even though NSSWITCH is correctly configured, it will not be possible to resolve
1422         domain users and groups for file and directory controls.
1423         </para>
1424
1425         </sect2>
1426
1427         <sect2>
1428         <title>Winbind Is Not Resolving Users and Groups</title>
1429
1430         <para><quote>
1431         My &smb.conf; file is correctly configured. I have specified <smbconfoption name="idmap uid">12000</smbconfoption>,
1432         and <smbconfoption name="idmap gid">3000-3500</smbconfoption> and <command>winbind</command> is running.
1433         When I do the following, it all works fine.
1434         </quote></para>
1435
1436 <para><screen>
1437 &rootprompt;<userinput>wbinfo -u</userinput>
1438 MIDEARTH\maryo
1439 MIDEARTH\jackb
1440 MIDEARTH\ameds
1441 ...
1442 MIDEARTH\root
1443
1444 &rootprompt;<userinput>wbinfo -g</userinput>
1445 MIDEARTH\Domain Users
1446 MIDEARTH\Domain Admins
1447 MIDEARTH\Domain Guests
1448 ...
1449 MIDEARTH\Accounts
1450
1451 &rootprompt;<userinput>getent passwd</userinput>
1452 root:x:0:0:root:/root:/bin/bash
1453 bin:x:1:1:bin:/bin:/bin/bash
1454 ...
1455 maryo:x:15000:15003:Mary Orville:/home/MIDEARTH/maryo:/bin/false
1456 </screen></para>
1457
1458 <para><quote>
1459 But the following command just fails:
1460 </quote>
1461 <screen>
1462 &rootprompt;<userinput>chown maryo a_file</userinput>
1463 chown: `maryo': invalid user
1464 </screen>
1465 <quote>
1466 This is driving me nuts! What can be wrong?
1467 </quote></para>
1468
1469 <para>
1470 Same problem as the one above.
1471 Your system is likely running <command>nscd</command>, the name service
1472 caching daemon. Shut it down, do not restart it! You will find your problem resolved.
1473 Alternately, fix the operation of nscd to resolve the problem.
1474 </para>
1475
1476 </sect2>
1477 </sect1>
1478
1479 </chapter>