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></primary>LDAP</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
 392                 to present itself as a source of system information when
 393                 resolving UNIX usernames and groups. Winbind uses this interface
 394                 and information obtained from a Windows NT server using MSRPC
 395                 calls to provide a new source of account enumeration. Using standard
 396                 UNIX library calls, you can enumerate the users and groups on
 397                 a UNIX machine running Winbind and see all users and groups in
 398                 an NT domain plus any trusted domain as though they were local
 399                 users and groups.</para>
 400
 401                 <para>
 402 <indexterm><primary>NSS</primary></indexterm>
 403 <indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
 404 <indexterm><primary>passwd</primary></indexterm>
 405                 The primary control file for NSS is <filename>/etc/nsswitch.conf</filename>.
 406                 When a UNIX application makes a request to do a lookup,
 407                 the C library looks in <filename>/etc/nsswitch.conf</filename>
 408                 for a line that matches the service type being requested; for
 409                 example, the <quote>passwd</quote> service type is used when user or group names
 410                 are looked up. This config line specifies which implementations
 411                 of that service should be tried and in what order. If the passwd
 412                 config line is:
 413 <screen>
 414 passwd: files example
 415 </screen>
 416 <indexterm><primary>/lib/libnss_files.so</primary></indexterm>
 417 <indexterm><primary>/lib/libnss_example.so</primary></indexterm>
 418 <indexterm><primary>resolver functions</primary></indexterm>
 419                 then the C library will first load a module called
 420                 <filename>/lib/libnss_files.so</filename> followed by
 421                 the module <filename>/lib/libnss_example.so</filename>. The
 422                 C library will dynamically load each of these modules in turn
 423                 and call resolver functions within the modules to try to resolve
 424                 the request. Once the request is resolved, the C library returns the
 425                 result to the application.</para>
 426
 427                 <para>
 428 <indexterm><primary>NSS</primary></indexterm>
 429 <indexterm><primary>libnss_winbind.so</primary></indexterm>
 430 <indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
 431                 This NSS interface provides an easy way for Winbind
 432                 to hook into the operating system. All that needs to be done
 433                 is to put <filename>libnss_winbind.so</filename> in <filename>/lib/</filename>
 434                 then add <quote>winbind</quote> into <filename>/etc/nsswitch.conf</filename> at
 435                 the appropriate place. The C library will then call Winbind to
 436                 resolve user and group names.</para>
 437         </sect2>
 438
 439         <sect2>
 440                 <title>Pluggable Authentication Modules</title>
 441
 442                 <para>
 443 <indexterm><primary>PAM</primary></indexterm>
 444 <indexterm><primary>authentication methods</primary></indexterm>
 445 <indexterm><primary>authorization</primary></indexterm>
 446 <indexterm><primary>NIS database</primary></indexterm>
 447                 PAMs provide a system for abstracting authentication and authorization
 448                 technologies. With a PAM module, it is possible to specify different
 449                 authentication methods for different system applications without
 450                 having to recompile these applications. PAM is also useful
 451                 for implementing a particular policy for authorization. For example,
 452                 a system administrator may only allow console logins from users
 453                 stored in the local password file but only allow users resolved from
 454                 an NIS database to log in over the network.</para>
 455
 456                 <para>
 457 <indexterm><primary>PAM</primary></indexterm>
 458 <indexterm><primary>Winbind</primary></indexterm>
 459 <indexterm><primary>authentication management</primary></indexterm>
 460 <indexterm><primary>password management</primary></indexterm>
 461 <indexterm><primary>PDC</primary></indexterm>
 462                 Winbind uses the authentication management and password
 463                 management PAM interface to integrate Windows NT users into a
 464                 UNIX system. This allows Windows NT users to log in to a UNIX
 465                 machine and be authenticated against a suitable PDC.
 466                 These users can also change their passwords and have
 467                 this change take effect directly on the PDC.
 468                 </para>
 469
 470                 <para>
 471 <indexterm><primary>PAM</primary></indexterm>
 472 <indexterm><primary>/etc/pam.d/</primary></indexterm>
 473 <indexterm><primary>pam_winbind.so</primary></indexterm>
 474 <indexterm><primary>/lib/security/</primary></indexterm>
 475                 PAM is configured by providing control files in the directory
 476                 <filename>/etc/pam.d/</filename> for each of the services that
 477                 require authentication. When an authentication request is made
 478                 by an application, the PAM code in the C library looks up this
 479                 control file to determine what modules to load to do the
 480                 authentication check and in what order. This interface makes adding
 481                 a new authentication service for Winbind very easy: simply copy
 482                 the <filename>pam_winbind.so</filename> module
 483                 to <filename>/lib/security/</filename>, and the PAM
 484                 control files for relevant services are updated to allow
 485                 authentication via Winbind. See the PAM documentation
 486                 in <link linkend="pam">PAM-Based Distributed Authentication</link>, for more information.</para>
 487         </sect2>
 488
 489
 490         <sect2>
 491                 <title>User and Group ID Allocation</title>
 492
 493                 <para>
 494 <indexterm><primary>RID</primary></indexterm>
 495 <indexterm><primary>Winbind</primary></indexterm>
 496 <indexterm><primary>UNIX ID</primary></indexterm>
 497                 When a user or group is created under Windows NT/200x,
 498                 it is allocated a numerical relative identifier (RID). This is
 499                 slightly different from UNIX, which has a range of numbers that are
 500                 used to identify users and the same range used to identify
 501                 groups. It is Winbind's job to convert RIDs to UNIX ID numbers and
 502                 vice versa. When Winbind is configured, it is given part of the UNIX
 503                 user ID space and a part of the UNIX group ID space in which to
 504                 store Windows NT users and groups. If a Windows NT user is
 505                 resolved for the first time, it is allocated the next UNIX ID from
 506                 the range. The same process applies for Windows NT groups. Over
 507                 time, Winbind will have mapped all Windows NT users and groups
 508                 to UNIX user IDs and group IDs.</para>
 509
 510                 <para>
 511 <indexterm><primary>ID mapping database</primary></indexterm>
 512 <indexterm><primary>tdb</primary></indexterm>
 513 <indexterm><primary>UNIX ID</primary></indexterm>
 514 <indexterm><primary>RID</primary></indexterm>
 515                 The results of this mapping are stored persistently in
 516                 an ID mapping database held in a tdb database. This ensures that
 517                 RIDs are mapped to UNIX IDs in a consistent way.</para>
 518         </sect2>
 519
 520
 521         <sect2>
 522                 <title>Result Caching</title>
 523
 524                 <para>
 525 <indexterm><primary>SAM</primary></indexterm>
 526 <indexterm><primary>caching scheme</primary></indexterm>
 527 <indexterm><primary>Winbind</primary></indexterm>
 528 <indexterm><primary>ADS</primary></indexterm>
 529 <indexterm><primary>PDC</primary></indexterm>
 530                         An active directory system can generate a lot of user and group
 531                 name lookups. To reduce the network cost of these lookups, Winbind
 532                 uses a caching scheme based on the SAM sequence number supplied
 533                 by NT domain controllers. User or group information returned
 534                 by a PDC is cached by Winbind along with a sequence number also
 535                 returned by the PDC. This sequence number is incremented by
 536                 Windows NT whenever any user or group information is modified. If
 537                 a cached entry has expired, the sequence number is requested from
 538                 the PDC and compared against the sequence number of the cached entry.
 539                 If the sequence numbers do not match, then the cached information
 540                 is discarded and up-to-date information is requested directly
 541                 from the PDC.</para>
 542         </sect2>
 543 </sect1>
 544
 545
 546 <sect1>
 547         <title>Installation and Configuration</title>
 548
 549 <sect2>
 550 <title>Introduction</title>
 551
 552 <para>
 553 <indexterm><primary>Winbind</primary></indexterm>
 554 <indexterm><primary>PDC</primary></indexterm>
 555 <indexterm><primary>authentication control</primary></indexterm>
 556 This section describes the procedures used to get Winbind up and
 557 running. Winbind is capable of providing access
 558 and authentication control for Windows Domain users through an NT
 559 or Windows 200x PDC for regular services, such as telnet and ftp, as
 560 well for Samba services.
 561 </para>
 562
 563 <itemizedlist>
 564 <listitem>
 565         <para>
 566         <emphasis>Why should I do this?</emphasis>
 567         </para>
 568
 569         <para>
 570 <indexterm><primary>Samba administrator</primary></indexterm>
 571 <indexterm><primary>authentication mechanisms</primary></indexterm>
 572 <indexterm><primary>domain members</primary></indexterm>
 573 <indexterm><primary>accounts</primary></indexterm>
 574         This allows the Samba administrator to rely on the
 575         authentication mechanisms on the Windows NT/200x PDC for the authentication
 576         of domain members. Windows NT/200x users no longer need to have separate
 577         accounts on the Samba server.
 578         </para>
 579 </listitem>
 580
 581 <listitem>
 582         <para>
 583         <emphasis>Who should be reading this document?</emphasis>
 584         </para>
 585
 586         <para>
 587 <indexterm><primary>PDC</primary></indexterm>
 588 <indexterm><primary>Windows NT/200x</primary></indexterm>
 589         This document is designed for system administrators. If you are
 590         implementing Samba on a file server and wish to (fairly easily)
 591         integrate existing Windows NT/200x users from your PDC onto the
 592         Samba server, this document is for you.
 593         </para>
 594 </listitem>
 595 </itemizedlist>
 596 </sect2>
 597
 598
 599 <sect2>
 600 <title>Requirements</title>
 601
 602 <para>
 603 <indexterm><primary>PAM</primary></indexterm>
 604 <indexterm><primary>back up</primary></indexterm>
 605 <indexterm><primary>boot disk`</primary></indexterm>
 606 If you have a Samba configuration file that you are currently using, <emphasis>BACK IT UP!</emphasis>
 607 If your system already uses PAM, <emphasis>back up the <filename>/etc/pam.d</filename> directory
 608 contents!</emphasis> If you haven't already made a boot disk, <emphasis>MAKE ONE NOW!</emphasis>
 609 </para>
 610
 611 <para>
 612 <indexterm><primary>PAM configuration</primary></indexterm>
 613 <indexterm><primary>/etc/pam.d</primary></indexterm>
 614 <indexterm><primary>single-user mode</primary></indexterm>
 615 Messing with the PAM configuration files can make it nearly impossible to log in to your machine. That's
 616 why you want to be able to boot back into your machine in single-user mode and restore your
 617 <filename>/etc/pam.d</filename> to the original state it was in if you get frustrated with the
 618 way things are going.
 619 </para>
 620
 621 <para>
 622 <indexterm><primary>winbindd</primary></indexterm>
 623 <indexterm><primary>daemon</primary></indexterm>
 624 The latest version of Samba-3 includes a functioning winbindd daemon. Please refer to the <ulink
 625 url="http://samba.org/">main Samba Web page</ulink>, or better yet, your closest Samba mirror site for
 626 instructions on downloading the source code.
 627 </para>
 628
 629 <para>
 630 <indexterm><primary>domain users</primary></indexterm>
 631 <indexterm><primary>shares and files</primary></indexterm>
 632 <indexterm><primary>PAM</primary></indexterm>
 633 <indexterm><primary>development libraries</primary></indexterm>
 634 To allow domain users the ability to access Samba shares and files, as well as potentially other services
 635 provided by your Samba machine, PAM must be set up properly on your
 636 machine. In order to compile the Winbind modules, you should have at least the PAM development libraries installed
 637 on your system. Please refer to the PAM Web site <ulink url="http://www.kernel.org/pub/linux/libs/pam/"/>.
 638 </para>
 639 </sect2>
 640
 641 <sect2>
 642 <title>Testing Things Out</title>
 643
 644 <para>
 645 <indexterm><primary>smbd</primary></indexterm>
 646 <indexterm><primary>nmbd</primary></indexterm>
 647 <indexterm><primary>winbindd</primary></indexterm>
 648 <indexterm><primary>/etc/pam.d</primary></indexterm>
 649 <indexterm><primary>PAM</primary></indexterm>
 650 Before starting, it is probably best to kill off all the Samba-related daemons running on your server.
 651 Kill off all &smbd;, &nmbd;, and &winbindd; processes that may be running. To use PAM,
 652 make sure that you have the standard PAM package that supplies the <filename>/etc/pam.d</filename>
 653 directory structure, including the PAM modules that are used by PAM-aware services, several PAM libraries,
 654 and the <filename>/usr/doc</filename> and <filename>/usr/man</filename> entries for PAM. Winbind is built
 655 better in Samba if the pam-devel package is also installed. This package includes the header files
 656 needed to compile PAM-aware applications.
 657 </para>
 658
 659 <sect3>
 660 <title>Configure <filename>nsswitch.conf</filename> and the Winbind Libraries on Linux and Solaris</title>
 661
 662 <para>
 663 <indexterm><primary>PAM</primary></indexterm>
 664 <indexterm><primary>pam-devel</primary></indexterm>
 665 <indexterm><primary>Winbind</primary></indexterm>
 666 <indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
 667 PAM is a standard component of most current generation UNIX/Linux systems. Unfortunately, few systems install
 668 the <filename>pam-devel</filename> libraries that are needed to build PAM-enabled Samba. Additionally, Samba-3
 669 may auto-install the Winbind files into their correct locations on your system, so before you get too far down
 670 the track, be sure to check if the following configuration is really
 671 necessary. You may only need to configure
 672 <filename>/etc/nsswitch.conf</filename>.
 673 </para>
 674
 675 <para>
 676 The libraries needed to run the &winbindd; daemon through nsswitch need to be copied to their proper locations:
 677 </para>
 678
 679 <para>
 680 <indexterm><primary>libnss_winbind.so</primary></indexterm>
 681 <screen>
 682 &rootprompt;<userinput>cp ../samba/source/nsswitch/libnss_winbind.so /lib</userinput>
 683 </screen>
 684 </para>
 685
 686 <para>
 687 I also found it necessary to make the following symbolic link:
 688 </para>
 689
 690 <para>
 691 &rootprompt; <userinput>ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2</userinput>
 692 </para>
 693
 694 <para>And, in the case of Sun Solaris:
 695 <indexterm><primary>nss_winbind.so.1</primary></indexterm>
 696 <screen>
 697 &rootprompt;<userinput>ln -s /usr/lib/libnss_winbind.so /usr/lib/libnss_winbind.so.1</userinput>
 698 &rootprompt;<userinput>ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.1</userinput>
 699 &rootprompt;<userinput>ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.2</userinput>
 700 </screen>
 701 </para>
 702
 703 <para>
 704 <indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
 705 As root, edit <filename>/etc/nsswitch.conf</filename> to
 706 allow user and group entries to be visible from the &winbindd;
 707 daemon. My <filename>/etc/nsswitch.conf</filename> file looked like
 708 this after editing:
 709 <programlisting>
 710 passwd:     files winbind
 711 shadow:     files
 712 group:      files winbind
 713 </programlisting></para>
 714
 715 <para>
 716 <indexterm><primary>winbindd</primary></indexterm>
 717 <indexterm><primary>ldconfig</primary></indexterm>
 718 <indexterm><primary>libnss_winbind</primary></indexterm>
 719 <indexterm><primary>grep</primary></indexterm>
 720 <indexterm><primary>dynamic link loader</primary></indexterm>
 721 The libraries needed by the <command>winbindd</command> daemon will be automatically
 722 entered into the <command>ldconfig</command> cache the next time
 723 your system reboots, but it is faster (and you do not need to reboot) if you do it manually:
 724 <screen>
 725 &rootprompt;<userinput>/sbin/ldconfig -v | grep winbind</userinput>
 726 </screen>
 727 This makes <filename>libnss_winbind</filename> available to winbindd and reports the current
 728 search path that is used by the dynamic link loader. The use of the <command>grep</command>
 729 filters the output of the <command>ldconfig</command> command so that we may see proof that
 730 this library is indeed recognized by the dynamic link loader.
 731 </para>
 732
 733 <para>
 734 <indexterm><primary>dynamic link loader</primary></indexterm>
 735 <indexterm><primary>crle</primary></indexterm>
 736 <indexterm><primary>/usr/local/lib</primary></indexterm>
 737 <indexterm><primary>link loader configuration</primary></indexterm>
 738 <indexterm><primary>object module dependencies</primary></indexterm>
 739 The Sun Solaris dynamic link loader management tool is called <command>crle</command>. The
 740 use of this tool is necessary to instruct the dynamic link loader to search directories that
 741 contain library files that were not supplied as part of the original operating system platform.
 742 The following example shows how to use this tool to add the directory <filename>/usr/local/lib</filename>
 743 to the dynamic link loader's search path:
 744 <screen>
 745 &rootprompt; crle -u -l /usr/lib:/usr/local/lib
 746 </screen>
 747 When executed without arguments, <command>crle</command> reports the current dynamic
 748 link loader configuration. This is demonstrated here:
 749 <screen>
 750 &rootprompt; crle
 751
 752 Configuration file [version 4]: /var/ld/ld.config
 753   Default Library Path (ELF):   /lib:/usr/lib:/usr/local/lib
 754   Trusted Directories (ELF):    /lib/secure:/usr/lib/secure  (system default)
 755
 756 Command line:
 757   crle -c /var/ld/ld.config -l /lib:/usr/lib:/usr/local/lib
 758 </screen>
 759 From this it is apparent that the <filename>/usr/local/lib</filename> directory is included
 760 in the search dynamic link libraries in order to satisfy object module dependencies.
 761 </para>
 762
 763 </sect3>
 764
 765 <sect3>
 766 <title>NSS Winbind on AIX</title>
 767
 768 <para>(This section is only for those running AIX.)</para>
 769
 770 <para>
 771 <indexterm><primary>AIX</primary></indexterm>
 772 <indexterm><primary>Winbind</primary></indexterm>
 773 <indexterm><primary>/usr/lib/security</primary></indexterm>
 774 <indexterm><primary>authentication module API</primary></indexterm>
 775 <indexterm><primary>/usr/lib/security/methods.cfg</primary></indexterm>
 776 <indexterm><primary>PAM module</primary></indexterm>
 777 The Winbind AIX identification module gets built as <filename>libnss_winbind.so</filename> in the
 778 nsswitch directory of the Samba source. This file can be copied to <filename>/usr/lib/security</filename>,
 779 and the AIX naming convention would indicate that it should be named WINBIND. A stanza like the following:
 780 <programlisting>
 781 WINBIND:
 782         program = /usr/lib/security/WINBIND
 783         options = authonly
 784 </programlisting>
 785 can then be added to <filename>/usr/lib/security/methods.cfg</filename>. This module only supports
 786 identification, but there have been reports of success using the standard Winbind PAM module for
 787 authentication. Use caution configuring loadable authentication modules, since misconfiguration can make
 788 it impossible to log on to the system.  Information regarding the AIX authentication module API can
 789 be found in the <quote>Kernel Extensions and Device Support Programming Concepts for AIX</quote> document that
 790 describes the <ulink url="http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixprggd/kernextc/sec_load_mod.htm">
 791 Loadable Authentication Module Programming Interface</ulink> for AIX. Further information on administering the modules
 792 can be found in the <ulink url="http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/baseadmn/iandaadmin.htm">System
 793 Management Guide: Operating System and Devices.</ulink>
 794 </para>
 795 </sect3>
 796
 797 <sect3>
 798 <title>Configure smb.conf</title>
 799
 800 <para>
 801 <indexterm><primary>winbind</primary></indexterm>
 802 <indexterm><primary>man page</primary></indexterm>
 803 <indexterm><primary>winbindd</primary></indexterm>
 804 Several parameters are needed in the &smb.conf; file to control the behavior of &winbindd;. These
 805 are described in more detail in the <citerefentry><refentrytitle>winbindd</refentrytitle>
 806 <manvolnum>8</manvolnum></citerefentry> man page. My &smb.conf; file, as shown in <link
 807 linkend="winbindcfg">the smb.conf for Winbind Setup</link>, was modified to include the necessary entries in the [global] section.
 808 </para>
 809
 810 <example id="winbindcfg">
 811 <title>smb.conf for Winbind Setup</title>
 812 <smbconfblock>
 813 <smbconfsection name="[global]"/>
 814 <smbconfcomment> separate domain and username with '\', like DOMAIN\username</smbconfcomment>
 815 <smbconfoption name="winbind separator">\</smbconfoption>
 816 <smbconfcomment> use uids from 10000 to 20000 for domain users</smbconfcomment>
 817 <smbconfoption name="idmap uid">10000-20000</smbconfoption>
 818 <smbconfcomment> use gids from 10000 to 20000 for domain groups</smbconfcomment>
 819 <smbconfoption name="idmap gid">10000-20000</smbconfoption>
 820 <smbconfcomment> allow enumeration of winbind users and groups</smbconfcomment>
 821 <smbconfoption name="winbind enum users">yes</smbconfoption>
 822 <smbconfoption name="winbind enum groups">yes</smbconfoption>
 823 <smbconfcomment> give winbind users a real shell (only needed if they have telnet access)</smbconfcomment>
 824 <smbconfoption name="template homedir">/home/winnt/%D/%U</smbconfoption>
 825 <smbconfoption name="template shell">/bin/bash</smbconfoption>
 826 </smbconfblock>
 827 </example>
 828
 829 </sect3>
 830
 831
 832 <sect3>
 833 <title>Join the Samba Server to the PDC Domain</title>
 834
 835 <para>
 836 <indexterm><primary>domain security</primary></indexterm>
 837 <indexterm><primary>PDC</primary></indexterm>
 838 <indexterm><primary>BDC</primary></indexterm>
 839 All machines that will participate in domain security should be members of
 840 the domain. This applies also to the PDC and all BDCs.
 841 </para>
 842
 843 <para>
 844 <indexterm><primary>joining domain</primary></indexterm>
 845 <indexterm><primary>domain join</primary></indexterm>
 846 <indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm>
 847 <indexterm><primary>smbd</primary></indexterm>
 848 <indexterm><primary>PDC</primary></indexterm>
 849 <indexterm><primary>domain controller</primary></indexterm>
 850 <indexterm><primary>MS DCE RPC</primary></indexterm>
 851 <indexterm><primary>DCE RPC</primary></indexterm>
 852 <indexterm><primary>RPC</primary></indexterm>
 853 The process of joining a domain requires the use of the <command>net rpc join</command>
 854 command. This process communicates with the domain controller it will register with
 855 (usually the PDC) via MS DCE RPC. This means, of course, that the <command>smbd</command>
 856 process must be running on the target domain controller. It is therefore necessary to temporarily
 857 start Samba on a PDC so that it can join its own domain.
 858 </para>
 859
 860 <para>
 861 <indexterm><primary>PDC</primary></indexterm>
 862 <indexterm><primary>administrative privileges</primary></indexterm>
 863 <indexterm><primary>Administrator</primary></indexterm>
 864 Enter the following command to make the Samba server join the
 865 domain, where <replaceable>PDC</replaceable> is the name of
 866 your PDC and <replaceable>Administrator</replaceable> is
 867 a domain user who has administrative privileges in the domain.
 868 </para>
 869
 870 <note><para>
 871 <indexterm><primary>domain controller</primary></indexterm>
 872 <indexterm><primary>PDC</primary></indexterm>
 873 <indexterm><primary>tcp ports</primary></indexterm>
 874 <indexterm><primary>udp ports</primary></indexterm>
 875 Before attempting to join a machine to the domain, verify that Samba is running
 876 on the target domain controller (usually PDC) and that it is capable of being reached via ports
 877 137/udp, 135/tcp, 139/tcp, and 445/tcp (if Samba or Windows Server 2Kx).
 878 </para></note>
 879
 880 <para>
 881 <indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm>
 882 The use of the <command>net rpc join</command> facility is shown here:
 883 <screen>
 884 &rootprompt;<userinput>/usr/local/samba/bin/net rpc join -S PDC -U Administrator</userinput>
 885 </screen>
 886 The proper response to the command should be <quote>Joined the domain
 887 <replaceable>DOMAIN</replaceable></quote> where <replaceable>DOMAIN</replaceable>
 888 is your domain name.
 889 </para>
 890
 891 </sect3>
 892
 893 <sect3>
 894 <title>Starting and Testing the <command>winbindd</command> Daemon</title>
 895
 896 <para>
 897 <indexterm><primary>startup script</primary></indexterm>
 898 <indexterm><primary>winbindd</primary></indexterm>
 899 <indexterm><primary>Winbind services</primary></indexterm>
 900 Eventually, you will want to modify your Samba startup script to
 901 automatically invoke the winbindd daemon when the other parts of
 902 Samba start, but it is possible to test out just the Winbind
 903 portion first. To start up Winbind services, enter the following
 904 command as root:
 905 <screen>
 906 &rootprompt;<userinput>/usr/local/samba/sbin/winbindd</userinput>
 907 </screen>
 908 Use the appropriate path to the location of the <command>winbindd</command> executable file.
 909 </para>
 910
 911 <note><para>
 912 <indexterm><primary>Winbind</primary></indexterm>
 913 <indexterm><primary>/usr/local/samba</primary></indexterm>
 914 The command to start up Winbind services assumes that Samba has been installed in the <filename>/usr/local/samba</filename>
 915 directory tree. You may need to search for the location of Samba files if this is not the
 916 location of <command>winbindd</command> on your system.
 917 </para></note>
 918
 919 <para>
 920 <indexterm><primary>Winbindd</primary></indexterm>
 921 <indexterm><primary>dual daemon mode</primary></indexterm>
 922 Winbindd can now also run in <quote>dual daemon mode</quote>. This will make it
 923 run as two processes. The first will answer all requests from the cache,
 924 thus making responses to clients faster. The other will
 925 update the cache for the query to which the first has just responded.
 926 The advantage of this is that responses stay accurate and are faster.
 927 You can enable dual daemon mode by adding <option>-B</option> to the command line:
 928 <screen>
 929 &rootprompt;<userinput>/usr/local/samba/sbin/winbindd -B</userinput>
 930 </screen>
 931 </para>
 932
 933 <para>
 934 <indexterm><primary>paranoid</primary></indexterm>
 935 <indexterm><primary>daemon running</primary></indexterm>
 936 I'm always paranoid and like to make sure the daemon is really running.
 937 <screen>
 938 &rootprompt;<userinput>ps -ae | grep winbindd</userinput>
 939 </screen>
 940 </para>
 941
 942 <para>
 943 <indexterm><primary>winbindd</primary></indexterm>
 944 This command should produce output like the following if the daemon is running.
 945 <screen>
 946 3025 ?        00:00:00 winbindd
 947 </screen>
 948 </para>
 949
 950 <para>
 951 <indexterm><primary>PDC</primary></indexterm>
 952 <indexterm><primary>wbinfo</primary></indexterm>
 953 Now, for the real test, try to get some information about the users on your PDC:
 954 <screen>
 955 &rootprompt;<userinput>/usr/local/samba/bin/wbinfo -u</userinput>
 956 </screen>
 957 This should echo back a list of users on your Windows users on
 958 your PDC. For example, I get the following response:
 959 <screen>
 960 CEO\Administrator
 961 CEO\burdell
 962 CEO\Guest
 963 CEO\jt-ad
 964 CEO\krbtgt
 965 CEO\TsInternetUser
 966 </screen>
 967 Obviously, I have named my domain <quote>CEO</quote> and my <smbconfoption name="winbind separator"/> is <quote>\</quote>.
 968 </para>
 969
 970 <para>
 971 <indexterm><primary>wbinfo</primary></indexterm>
 972 <indexterm><primary>PDC</primary></indexterm>
 973 You can do the same sort of thing to get group information from the PDC:
 974 <screen>
 975 &rootprompt;<userinput>/usr/local/samba/bin/wbinfo -g</userinput>
 976 CEO\Domain Admins
 977 CEO\Domain Users
 978 CEO\Domain Guests
 979 CEO\Domain Computers
 980 CEO\Domain Controllers
 981 CEO\Cert Publishers
 982 CEO\Schema Admins
 983 CEO\Enterprise Admins
 984 CEO\Group Policy Creator Owners
 985 </screen></para>
 986
 987 <para>
 988 <indexterm><primary>getent</primary></indexterm>
 989 <indexterm><primary>PDC</primary></indexterm>
 990 <indexterm><primary>/etc/passwd</primary></indexterm>
 991 <indexterm><primary>UID</primary></indexterm>
 992 <indexterm><primary>GID</primary></indexterm>
 993 <indexterm><primary>home directories</primary></indexterm>
 994 <indexterm><primary>default shells</primary></indexterm>
 995 The function <command>getent</command> can now be used to get unified
 996 lists of both local and PDC users and groups. Try the following command:
 997 <screen>
 998 &rootprompt;<userinput>getent passwd</userinput>
 999 </screen>
1000 You should get a list that looks like your <filename>/etc/passwd</filename>
1001 list followed by the domain users with their new UIDs, GIDs, home
1002 directories, and default shells.
1003 </para>
1004
1005 <para>
1006 The same thing can be done for groups with the command:
1007 <screen>
1008 &rootprompt;<userinput>getent group</userinput>
1009 </screen>
1010 </para>
1011
1012 </sect3>
1013
1014
1015 <sect3>
1016 <title>Fix the init.d Startup Scripts</title>
1017
1018 <sect4>
1019 <title>Linux</title>
1020
1021 <para>
1022 <indexterm><primary>winbindd daemon</primary></indexterm>
1023 <indexterm><primary>smbd</primary></indexterm>
1024 <indexterm><primary>nmbd</primary></indexterm>
1025 <indexterm><primary>/etc/init.d/smb</primary></indexterm>
1026 <indexterm><primary>/etc/init.d/samba</primary></indexterm>
1027 <indexterm><primary>/usr/local/samba/bin</primary></indexterm>
1028 <indexterm><primary></primary></indexterm>
1029 <indexterm><primary></primary></indexterm>
1030 <indexterm><primary></primary></indexterm>
1031 The &winbindd; daemon needs to start up after the &smbd; and &nmbd; daemons are running.
1032 To accomplish this task, you need to modify the startup scripts of your system.
1033 They are located at <filename>/etc/init.d/smb</filename> in Red Hat Linux and in
1034 <filename>/etc/init.d/samba</filename> in Debian Linux. Edit your
1035 script to add commands to invoke this daemon in the proper sequence. My
1036 startup script starts up &smbd;, &nmbd;, and &winbindd; from the
1037 <filename>/usr/local/samba/bin</filename> directory directly. The <command>start</command>
1038 function in the script looks like this:
1039 <programlisting>
1040 start() {
1041         KIND="SMB"
1042         echo -n $"Starting $KIND services: "
1043         daemon /usr/local/samba/bin/smbd $SMBDOPTIONS
1044         RETVAL=$?
1045         echo
1046         KIND="NMB"
1047         echo -n $"Starting $KIND services: "
1048         daemon /usr/local/samba/bin/nmbd $NMBDOPTIONS
1049         RETVAL2=$?
1050         echo
1051         KIND="Winbind"
1052         echo -n $"Starting $KIND services: "
1053         daemon /usr/local/samba/sbin/winbindd
1054         RETVAL3=$?
1055         echo
1056         [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 -a $RETVAL3 -eq 0 ] &amp;&amp; \
1057                 touch /var/lock/subsys/smb || RETVAL=1
1058         return $RETVAL
1059 }
1060 </programlisting></para>
1061
1062 <para>If you would like to run winbindd in dual daemon mode, replace
1063 the line:
1064 <programlisting>
1065         daemon /usr/local/samba/sbin/winbindd
1066 </programlisting>
1067
1068 in the example above with:
1069
1070 <programlisting>
1071         daemon /usr/local/samba/sbin/winbindd -B
1072 </programlisting>.
1073 </para>
1074
1075 <para>
1076 The <command>stop</command> function has a corresponding entry to shut down the
1077 services and looks like this:
1078 </para>
1079
1080 <para><programlisting>
1081 stop() {
1082         KIND="SMB"
1083         echo -n $"Shutting down $KIND services: "
1084         killproc smbd
1085         RETVAL=$?
1086         echo
1087         KIND="NMB"
1088         echo -n $"Shutting down $KIND services: "
1089         killproc nmbd
1090         RETVAL2=$?
1091         echo
1092         KIND="Winbind"
1093         echo -n $"Shutting down $KIND services: "
1094         killproc winbindd
1095         RETVAL3=$?
1096         [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 -a $RETVAL3 -eq 0 ] &amp;&amp; \
1097                  rm -f /var/lock/subsys/smb
1098         echo ""
1099         return $RETVAL
1100 }
1101 </programlisting></para>
1102 </sect4>
1103
1104 <sect4>
1105 <title>Solaris</title>
1106
1107 <para>
1108 Winbind does not work on Solaris 9; see <link linkend="winbind-solaris9">Winbind on Solaris 9 section</link>
1109 for details.
1110 </para>
1111
1112 <para>
1113 <indexterm><primary>Solaris 9</primary></indexterm>
1114 <indexterm><primary>/etc/init.d/samba.server</primary></indexterm>
1115 <indexterm><primary>/usr/local/samba/bin</primary></indexterm>
1116 <indexterm><primary>smbd</primary></indexterm>
1117 <indexterm><primary>nmbd</primary></indexterm>
1118 <indexterm><primary>winbindd</primary></indexterm>
1119 On Solaris, you need to modify the <filename>/etc/init.d/samba.server</filename> startup script. It
1120 usually only starts smbd and nmbd but should now start winbindd, too. If you have Samba installed in
1121 <filename>/usr/local/samba/bin</filename>, the file could contains something like this:
1122 </para>
1123
1124 <para>
1125         <programlisting>
1126         ##
1127         ## samba.server
1128         ##
1129
1130         if [ ! -d /usr/bin ]
1131         then                    # /usr not mounted
1132                 exit
1133         fi
1134
1135         killproc() {            # kill the named process(es)
1136                 pid=`/usr/bin/ps -e |
1137                      /usr/bin/grep -w $1 |
1138                      /usr/bin/sed -e 's/^  *//' -e 's/ .*//'`
1139                 [ "$pid" != "" ] &amp;&amp; kill $pid
1140         }
1141
1142         # Start/stop processes required for Samba server
1143
1144         case "$1" in
1145
1146         'start')
1147         #
1148         # Edit these lines to suit your installation (paths, workgroup, host)
1149         #
1150         echo Starting SMBD
1151            /usr/local/samba/bin/smbd -D -s \
1152                 /usr/local/samba/smb.conf
1153
1154         echo Starting NMBD
1155            /usr/local/samba/bin/nmbd -D -l \
1156                 /usr/local/samba/var/log -s /usr/local/samba/smb.conf
1157
1158         echo Starting Winbind Daemon
1159            /usr/local/samba/sbin/winbindd
1160            ;;
1161
1162         'stop')
1163            killproc nmbd
1164            killproc smbd
1165            killproc winbindd
1166            ;;
1167
1168         *)
1169            echo "Usage: /etc/init.d/samba.server { start | stop }"
1170            ;;
1171         esac
1172 </programlisting></para>
1173
1174 <para>
1175 Again, if you would like to run Samba in dual daemon mode, replace:
1176 <programlisting>
1177 /usr/local/samba/sbin/winbindd
1178 </programlisting>
1179 in the script above with:
1180 <programlisting>
1181 /usr/local/samba/sbin/winbindd -B
1182 </programlisting>
1183 </para>
1184
1185 </sect4>
1186
1187 <sect4>
1188 <title>Restarting</title>
1189 <para>
1190 <indexterm><primary>daemons</primary></indexterm>
1191 <indexterm><primary>local user</primary></indexterm>
1192 If you restart the &smbd;, &nmbd;, and &winbindd; daemons at this point, you
1193 should be able to connect to the Samba server as a domain member just as
1194 if you were a local user.
1195 </para>
1196 </sect4>
1197 </sect3>
1198
1199 <sect3>
1200 <title>Configure Winbind and PAM</title>
1201
1202 <para>
1203 <indexterm><primary>winbindd</primary></indexterm>
1204 <indexterm><primary>authentication</primary></indexterm>
1205 <indexterm><primary>PAM</primary></indexterm>
1206 <indexterm><primary>/etc/pam.d</primary></indexterm>
1207 If you have made it this far, you know that <command>winbindd</command> and Samba are working
1208 together. If you want to use Winbind to provide authentication for other
1209 services, keep reading. The PAM configuration files need to be altered in
1210 this step. (Did you remember to make backups of your original
1211 <filename>/etc/pam.d</filename> files? If not, do it now.)
1212 </para>
1213
1214 <para>
1215 <indexterm><primary>NSS</primary></indexterm>
1216 <indexterm><primary>../source/nsswitch</primary></indexterm>
1217 <indexterm><primary>pam_winbind.so</primary></indexterm>
1218 <indexterm><primary>/lib/security</primary></indexterm>
1219 <indexterm><primary>Solaris</primary></indexterm>
1220 <indexterm><primary>/usr/lib/security</primary></indexterm>
1221 You will need a PAM module to use winbindd with these other services. This
1222 module will be compiled in the <filename>../source/nsswitch</filename> directory
1223 by invoking the command:
1224 <screen>
1225 &rootprompt;<userinput>make nsswitch/pam_winbind.so</userinput>
1226 </screen>
1227 from the <filename>../source</filename> directory. The
1228 <filename>pam_winbind.so</filename> file should be copied to the location of
1229 your other PAM security modules. On my Red Hat system, this was the
1230 <filename>/lib/security</filename> directory. On Solaris, the PAM security
1231 modules reside in <filename>/usr/lib/security</filename>.
1232 <screen>
1233 &rootprompt;<userinput>cp ../samba/source/nsswitch/pam_winbind.so /lib/security</userinput>
1234 </screen>
1235 </para>
1236
1237 <sect4>
1238 <title>Linux/FreeBSD-Specific PAM Configuration</title>
1239
1240 <para>
1241 <indexterm><primary>/etc/pam.d/samba</primary></indexterm>
1242 The <filename>/etc/pam.d/samba</filename> file does not need to be changed. I
1243 just left this file as it was:
1244 <programlisting>
1245 auth    required  /lib/security/pam_stack.so service=system-auth
1246 account required  /lib/security/pam_stack.so service=system-auth
1247 </programlisting></para>
1248
1249 <para>
1250 <indexterm><primary>Winbind</primary></indexterm>
1251 <indexterm><primary>authentication service</primary></indexterm>
1252 <indexterm><primary>login</primary></indexterm>
1253 <indexterm><primary>console</primary></indexterm>
1254 <indexterm><primary>telnet logins</primary></indexterm>
1255 <indexterm><primary>ftp service</primary></indexterm>
1256 <indexterm><primary>/etc/xinetd.d</primary></indexterm>
1257 <indexterm><primary>/etc/inetd.conf</primary></indexterm>
1258 <indexterm><primary>/etc/xinetd.d/telnet</primary></indexterm>
1259 The other services that I modified to allow the use of Winbind
1260 as an authentication service were the normal login on the console (or a terminal
1261 session), telnet logins, and ftp service. In order to enable these
1262 services, you may first need to change the entries in
1263 <filename>/etc/xinetd.d</filename> (or <filename>/etc/inetd.conf</filename>).
1264 Red Hat Linux 7.1 and later uses the new xinetd.d structure, in this case you need
1265 to change the lines in <filename>/etc/xinetd.d/telnet</filename>
1266 and <filename>/etc/xinetd.d/wu-ftp</filename> from
1267 <programlisting>
1268         enable = no
1269 </programlisting>
1270 to
1271 <programlisting>
1272         enable = yes
1273 </programlisting></para>
1274
1275 <para>
1276 <indexterm><primary>ftp services</primary></indexterm>
1277 <indexterm><primary>home directory template</primary></indexterm>
1278 <indexterm><primary>domain users</primary></indexterm>
1279 For ftp services to work properly, you will also need to either
1280 have individual directories for the domain users already present on
1281 the server or change the home directory template to a general
1282 directory for all domain users. These can be easily set using
1283 the &smb.conf; global entry
1284 <smbconfoption name="template homedir"/>.
1285 </para>
1286
1287 <note><para>
1288 <indexterm><primary>pam_mkhomedir</primary></indexterm>
1289 The directory in <smbconfoption name="template homedir"/> is not created automatically! Use pam_mkhomedir or
1290 pre-create the directories of users to make sure users can log in on UNIX with their own home directory.
1291 </para></note>
1292
1293 <para>
1294 <indexterm><primary>/etc/pam.d/ftp</primary></indexterm>
1295 <indexterm><primary>Winbind</primary></indexterm>
1296 <indexterm><primary>ftp access</primary></indexterm>
1297 The <filename>/etc/pam.d/ftp</filename> file can be changed
1298 to allow Winbind ftp access in a manner similar to the
1299 samba file. My <filename>/etc/pam.d/ftp</filename> file was
1300 changed to look like this:
1301 <programlisting>
1302 auth       required     /lib/security/pam_listfile.so item=user sense=deny \
1303          file=/etc/ftpusers onerr=succeed
1304 auth       sufficient   /lib/security/pam_winbind.so
1305 auth       required     /lib/security/pam_stack.so service=system-auth
1306 auth       required     /lib/security/pam_shells.so
1307 account    sufficient   /lib/security/pam_winbind.so
1308 account    required     /lib/security/pam_stack.so service=system-auth
1309 session    required     /lib/security/pam_stack.so service=system-auth
1310 </programlisting></para>
1311
1312 <para>
1313 <indexterm><primary>/etc/pam.d/login</primary></indexterm>
1314 The <filename>/etc/pam.d/login</filename> file can be changed in nearly the
1315 same way. It now looks like this:
1316 <programlisting>
1317 auth       required     /lib/security/pam_securetty.so
1318 auth       sufficient   /lib/security/pam_winbind.so
1319 auth       sufficient   /lib/security/pam_unix.so use_first_pass
1320 auth       required     /lib/security/pam_stack.so service=system-auth
1321 auth       required     /lib/security/pam_nologin.so
1322 account    sufficient   /lib/security/pam_winbind.so
1323 account    required     /lib/security/pam_stack.so service=system-auth
1324 password   required     /lib/security/pam_stack.so service=system-auth
1325 session    required     /lib/security/pam_stack.so service=system-auth
1326 session    optional     /lib/security/pam_console.so
1327 </programlisting>
1328 <indexterm><primary>pam_winbind.so</primary></indexterm>
1329 <indexterm><primary>pam_securetty.so</primary></indexterm>
1330 <indexterm><primary>pam_unix.so</primary></indexterm>
1331 In this case, I added the <programlisting>auth sufficient /lib/security/pam_winbind.so</programlisting>
1332 lines as before, but also added the <programlisting>required pam_securetty.so</programlisting>
1333 above it to disallow root logins over the network. I also added a
1334 <programlisting>sufficient /lib/security/pam_unix.so use_first_pass</programlisting>
1335 line after the <command>winbind.so</command> line to get rid of annoying
1336 double prompts for passwords.
1337 </para>
1338
1339 </sect4>
1340
1341 <sect4>
1342 <title>Solaris-Specific Configuration</title>
1343
1344 <para>
1345 <indexterm><primary>/etc/pam.conf</primary></indexterm>
1346 <indexterm><primary></primary></indexterm>
1347 The <filename>/etc/pam.conf</filename> needs to be changed. I changed this file so my Domain
1348 users can log on both locally as well as with telnet. The following are the changes
1349 that I made. You can customize the <filename>pam.conf</filename> file as per your requirements, but
1350 be sure of those changes because in the worst case it will leave your system
1351 nearly impossible to boot.
1352 <programlisting>
1353 #
1354 #ident "@(#)pam.conf 1.14 99/09/16 SMI"
1355 #
1356 # Copyright (c) 1996-1999, Sun Microsystems, Inc.
1357 # All Rights Reserved.
1358 #
1359 # PAM configuration
1360 #
1361 # Authentication management
1362 #
1363 login   auth required   /usr/lib/security/pam_winbind.so
1364 login auth required  /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass
1365 login auth required  /usr/lib/security/$ISA/pam_dial_auth.so.1 try_first_pass
1366 #
1367 rlogin  auth sufficient /usr/lib/security/pam_winbind.so
1368 rlogin  auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1
1369 rlogin auth required  /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass
1370 #
1371 dtlogin auth sufficient /usr/lib/security/pam_winbind.so
1372 dtlogin auth required  /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass
1373 #
1374 rsh auth required /usr/lib/security/$ISA/pam_rhosts_auth.so.1
1375 other   auth sufficient /usr/lib/security/pam_winbind.so
1376 other auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass
1377 #
1378 # Account management
1379 #
1380 login   account sufficient      /usr/lib/security/pam_winbind.so
1381 login account requisite /usr/lib/security/$ISA/pam_roles.so.1
1382 login account required /usr/lib/security/$ISA/pam_unix.so.1
1383 #
1384 dtlogin account sufficient      /usr/lib/security/pam_winbind.so
1385 dtlogin account requisite /usr/lib/security/$ISA/pam_roles.so.1
1386 dtlogin account required /usr/lib/security/$ISA/pam_unix.so.1
1387 #
1388 other   account sufficient      /usr/lib/security/pam_winbind.so
1389 other account requisite /usr/lib/security/$ISA/pam_roles.so.1
1390 other account required /usr/lib/security/$ISA/pam_unix.so.1
1391 #
1392 # Session management
1393 #
1394 other session required /usr/lib/security/$ISA/pam_unix.so.1
1395 #
1396 # Password management
1397 #
1398 #other   password sufficient     /usr/lib/security/pam_winbind.so
1399 other password required /usr/lib/security/$ISA/pam_unix.so.1
1400 dtsession auth required /usr/lib/security/$ISA/pam_unix.so.1
1401 #
1402 # Support for Kerberos V5 authentication (uncomment to use Kerberos)
1403 #
1404 #rlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
1405 #login auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
1406 #dtlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
1407 #other auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
1408 #dtlogin account optional /usr/lib/security/$ISA/pam_krb5.so.1
1409 #other account optional /usr/lib/security/$ISA/pam_krb5.so.1
1410 #other session optional /usr/lib/security/$ISA/pam_krb5.so.1
1411 #other password optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
1412 </programlisting></para>
1413
1414 <para>
1415 <indexterm><primary>winbind.so</primary></indexterm>
1416 I also added a <parameter>try_first_pass</parameter> line after the <filename>winbind.so</filename>
1417 line to get rid of annoying double prompts for passwords.
1418 </para>
1419
1420 <para>
1421 Now restart your Samba and try connecting through your application that you
1422 configured in the pam.conf.
1423 </para>
1424
1425 </sect4>
1426
1427 </sect3>
1428
1429 </sect2>
1430
1431 </sect1>
1432
1433 <sect1>
1434 <title>Conclusion</title>
1435
1436 <para>
1437 <indexterm><primary>Winbind</primary></indexterm>
1438 <indexterm><primary>NSS</primary></indexterm>
1439 <indexterm><primary>PAM</primary></indexterm>
1440 <indexterm><primary>RPC calls</primary></indexterm>
1441 <indexterm><primary>domain users</primary></indexterm>
1442 The Winbind system, through the use of the NSS, PAMs, and appropriate
1443 Microsoft RPC calls, have allowed us to provide seamless
1444 integration of Microsoft Windows NT domain users on a
1445 UNIX system. The result is a great reduction in the administrative
1446 cost of running a mixed UNIX and NT network.</para>
1447
1448 </sect1>
1449
1450 <sect1>
1451 <title>Common Errors</title>
1452
1453         <para>Winbind has a number of limitations in its current
1454         released version that we hope to overcome in future
1455         releases:</para>
1456
1457         <itemizedlist>
1458                 <listitem><para>Winbind is currently only available for
1459                 the Linux, Solaris, AIX, and IRIX operating systems, although ports to other operating
1460                 systems are certainly possible. For such ports to be feasible,
1461                 we require the C library of the target operating system to
1462                 support the NSS and PAM
1463                 systems. This is becoming more common as NSS and
1464                 PAM gain support among UNIX vendors.</para></listitem>
1465
1466                 <listitem><para>The mappings of Windows NT RIDs to UNIX IDs
1467                 is not made algorithmically and depends on the order in which
1468                 unmapped users or groups are seen by Winbind. It may be difficult
1469                 to recover the mappings of RID to UNIX ID if the file
1470                 containing this information is corrupted or destroyed.</para>
1471                 </listitem>
1472
1473                 <listitem><para>Currently the Winbind PAM module does not take
1474                 into account possible workstation and logon time restrictions
1475                 that may be set for Windows NT users; this is
1476                 instead up to the PDC to enforce.</para></listitem>
1477         </itemizedlist>
1478
1479         <sect2>
1480         <title>NSCD Problem Warning</title>
1481
1482         <warning><para>
1483         Do not under any circumstances run <command>nscd</command> on any system
1484         on which <command>winbindd</command> is running.
1485         </para></warning>
1486
1487         <para>
1488         If <command>nscd</command> is running on the UNIX/Linux system, then
1489         even though NSSWITCH is correctly configured, it will not be possible to resolve
1490         domain users and groups for file and directory controls.
1491         </para>
1492
1493         </sect2>
1494
1495         <sect2>
1496         <title>Winbind Is Not Resolving Users and Groups</title>
1497
1498         <para><quote>
1499         My &smb.conf; file is correctly configured. I have specified
1500         <smbconfoption name="idmap uid">12000</smbconfoption>,
1501         and <smbconfoption name="idmap gid">3000-3500</smbconfoption>
1502         and <command>winbind</command> is running. When I do the following, it all works fine.
1503         </quote></para>
1504
1505 <para><screen>
1506 &rootprompt;<userinput>wbinfo -u</userinput>
1507 MIDEARTH\maryo
1508 MIDEARTH\jackb
1509 MIDEARTH\ameds
1510 ...
1511 MIDEARTH\root
1512
1513 &rootprompt;<userinput>wbinfo -g</userinput>
1514 MIDEARTH\Domain Users
1515 MIDEARTH\Domain Admins
1516 MIDEARTH\Domain Guests
1517 ...
1518 MIDEARTH\Accounts
1519
1520 &rootprompt;<userinput>getent passwd</userinput>
1521 root:x:0:0:root:/root:/bin/bash
1522 bin:x:1:1:bin:/bin:/bin/bash
1523 ...
1524 maryo:x:15000:15003:Mary Orville:/home/MIDEARTH/maryo:/bin/false
1525 </screen></para>
1526
1527 <para><quote>
1528 But the following command just fails:
1529 </quote>
1530 <screen>
1531 &rootprompt;<userinput>chown maryo a_file</userinput>
1532 chown: `maryo': invalid user
1533 </screen>
1534 <quote>
1535 This is driving me nuts! What can be wrong?
1536 </quote></para>
1537
1538 <para>
1539 Same problem as the one above.
1540 Your system is likely running <command>nscd</command>, the name service
1541 caching daemon. Shut it down, do not restart it! You will find your problem resolved.
1542 </para>
1543
1544 </sect2>
1545 </sect1>
1546
1547 </chapter>