docs/Samba-Guide/Chap09-AddingUNIXClients.xml

   1 <?xml version="1.0" encoding="iso-8859-1"?>
   2 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
   3                 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
   4
   5   <!-- Stuff for xincludes -->
   6   <!ENTITY % xinclude SYSTEM "../entities/xinclude.dtd">
   7   %xinclude;
   8
   9   <!-- entities files to use -->
  10   <!ENTITY % global_entities SYSTEM '../entities/global.entities'>
  11   %global_entities;
  12
  13 ]>
  14
  15 <chapter id="unixclients">
  16   <title>Adding UNIX/LINUX Servers and Clients</title>
  17
  18     <para><indexterm>
  19         <primary>Open Magazine</primary>
  20       </indexterm><indexterm>
  21         <primary>survey</primary>
  22       </indexterm>
  23         The most frequently discussed Samba subjects over the past two years have focused around Domain Control and printing.
  24         It is well known that Samba is a file and print server. A recent survey conducted by Open Magazine found
  25         that of all respondents: 97% use Samba for file and print services, and 68% use Samba for Domain Control. See the
  26         <ulink url="http://www.open-mag.com/cgi-bin/opencgi/surveys/survey.cgi?survey_name=samba">Open-Mag</ulink>
  27         Web site for current information. The survey results as found on January 14, 2004, as shown in
  28         <link linkend="ch09openmag"/>.
  29         </para>
  30
  31         <image id="ch09openmag">
  32                 <imagedescription>Open Magazine Samba Survey</imagedescription>
  33                 <imagefile scale="60">openmag</imagefile>
  34         </image>
  35
  36         <para>
  37         While Domain Control is an exciting subject, basic file and print sharing remains the staple bread-and-butter
  38         function that Samba provides. Yet this book may give the appearance of having focused too much on more
  39         exciting aspects of Samba deployment. This chapter directs your attention to provide important information on
  40         the addition of Samba servers into your present Windows network &smbmdash; whatever the controlling technology
  41         may be. So let's get back to Abmas and our good friends Bob Jordan and company.
  42         </para>
  43
  44 <sect1>
  45         <title>Introduction</title>
  46
  47       <para><indexterm>
  48           <primary>Linux desktop</primary>
  49         </indexterm><indexterm>
  50           <primary>Domain Member</primary>
  51           <secondary>server</secondary>
  52         </indexterm>
  53         Bob Jordan looks back over the achievements of the past year or two. Daily events are rather straightforward
  54         with not too many distractions or problems. Bob, your team is doing well, but a number of employees
  55         are asking for Linux desktop systems. Your network has grown and demands additional Domain Member servers. Let's
  56         get on with this; Christine and Stan are ready to go.
  57         </para>
  58
  59       <para><indexterm>
  60           <primary>Domain Member</primary>
  61           <secondary>desktop</secondary>
  62         </indexterm>
  63         Stan Soroka is firmly in control of the Department of the Future, while Christine is enjoying a stable and
  64         predictable network environment. It is time to add more servers and to add Linux desktops. It is
  65         time to meet the demands of future growth and endure trial by fire. Go on, walk the steps
  66         with Stan and Company.
  67         </para>
  68
  69         <sect2>
  70         <title>Assignment Tasks</title>
  71
  72         <para><indexterm>
  73             <primary>Active Directory</primary>
  74           </indexterm>
  75         You must now add UNIX/Linux Domain Member servers to your network. You have a friend who has a Windows 2003
  76         Active Directory Domain network who wants to add a Samba/Linux server and has asked Christine to help him
  77         out. Your real objective is to help Christine to see more of the way the Microsoft world lives and use
  78         her help to get validation that Samba really does live up to expectations.
  79         </para>
  80
  81         <para>
  82         Over the past six months, you have hired several new staff who want Linux on their desktops. You must integrate
  83         these systems to make sure that Abmas is not building islands of technology. You ask Christine to
  84         do likewise at Swodniw Biz NL (your friend's company) to help them to evaluate a Linux desktop. You want to make
  85         the right decision, don't you?
  86         </para>
  87
  88         </sect2>
  89 </sect1>
  90
  91 <sect1>
  92         <title>Dissection and Discussion</title>
  93
  94       <para><indexterm>
  95           <primary>winbind</primary>
  96         </indexterm>
  97         Recent Samba mailing list activity is witness to how many sites are using winbind. Some have no trouble
  98         at all with it, yet to others the problems seem insurmountable. Periodically there are complaints concerning
  99         an inability to achieve identical user and group IDs between Windows and UNIX environments.
 100         </para>
 101
 102         <para>
 103         You provide step-by-step implementations of the various tools that can be used for identity
 104         resolution. You also provide working examples of solutions for integrated authentication for
 105         both UNIX/Linux and Windows environments.
 106         </para>
 107
 108         <sect2>
 109                 <title>Technical Issues</title>
 110
 111                 <para>
 112                 One of the great challenges we face when people ask us, <quote>What is the best way to solve
 113                 this problem?</quote> is to get beyond the facts so we can not only clearly comprehend
 114                 the immediate technical problem, but also understand how needs may change.
 115                 </para>
 116
 117         <para><indexterm>
 118             <primary>integrate</primary>
 119           </indexterm>
 120                 There are a few facts we should note when dealing with the question of how best to
 121                 integrate UNIX/Linux clients and servers into a Windows networking environment:
 122                 </para>
 123
 124                 <itemizedlist>
 125           <listitem><para><indexterm>
 126                 <primary>Domain Controller</primary>
 127               </indexterm><indexterm>
 128                 <primary>authoritative</primary>
 129               </indexterm><indexterm>
 130                 <primary>accounts</primary>
 131                 <secondary>authoritative</secondary>
 132               </indexterm><indexterm>
 133                 <primary>PDC</primary>
 134               </indexterm><indexterm>
 135                 <primary>BDC</primary>
 136               </indexterm>
 137                         A Domain Controller (PDC or BDC) is always authoritative for all accounts in its Domain.
 138                         This means that a BDC must (of necessity) be able to resolve all account UIDs and GIDs
 139                         to the same values that the PDC resolved them to.
 140                         </para></listitem>
 141
 142           <listitem><para><indexterm>
 143                 <primary>local accounts</primary>
 144               </indexterm><indexterm>
 145                 <primary>Domain Member</primary>
 146                 <secondary>authoritative</secondary>
 147                 <tertiary>local accounts</tertiary>
 148               </indexterm><indexterm>
 149                 <primary>Domain accounts</primary>
 150               </indexterm><indexterm>
 151                 <primary>winbindd</primary>
 152               </indexterm>
 153                         A Domain Member can be authoritative for local accounts, but is never authoritative for
 154                         Domain accounts. If a user is accessing a Domain Member server and that user's account
 155                         is not known locally, the Domain Member server must resolve the identity of that user
 156                         from the Domain in which that user's account resides. It must then map that ID to a
 157                         UID/GID pair that it can use locally. This is handled by <command>winbindd</command>.
 158                         </para></listitem>
 159
 160                         <listitem><para>
 161                         Samba, when running on a Domain Member server, can resolve user identities from a
 162                         number of sources:
 163
 164                         <itemizedlist>
 165                 <listitem><para><indexterm>
 166                       <primary>getpwnam</primary>
 167                     </indexterm><indexterm>
 168                       <primary>getgrnam</primary>
 169                     </indexterm><indexterm>
 170                       <primary>NSS</primary>
 171                     </indexterm><indexterm>
 172                       <primary>LDAP</primary>
 173                     </indexterm><indexterm>
 174                       <primary>NIS</primary>
 175                     </indexterm>
 176                                 By executing a system <command>getpwnam()</command> or <command>getgrnam()</command> call.
 177                                 On systems that support it, this utilizes the name service switch (NSS) facility to
 178                                 resolve names according to the configuration of the <filename>/etc/nsswitch.conf</filename>
 179                                 file. NSS can be configured to use LDAP, winbind, NIS, or local files.
 180                                 </para></listitem>
 181
 182                 <listitem><para><indexterm>
 183                       <primary>passdb backend</primary>
 184                     </indexterm><indexterm>
 185                       <primary>PADL</primary>
 186                     </indexterm><indexterm>
 187                       <primary>nss_ldap</primary>
 188                     </indexterm>
 189                                 Performing, via NSS, a direct LDAP search (where an LDAP passdb backend has been configured).
 190                                 This requires the use of the PADL nss_ldap tool (or equivalent).
 191                                 </para></listitem>
 192
 193                 <listitem><para><indexterm>
 194                       <primary>winbindd</primary>
 195                     </indexterm><indexterm>
 196                       <primary>SID</primary>
 197                     </indexterm><indexterm>
 198                       <primary>winbindd_idmap.tdb</primary>
 199                     </indexterm><indexterm>
 200                       <primary>winbindd_cache.tdb</primary>
 201                     </indexterm>
 202                                 Directly by querying <command>winbindd</command>. The <command>winbindd</command>
 203                                 contact a Domain Controller to attempt to resolve the identity of the user or group. It
 204                                 receives the Windows networking security identifier (SID) for that appropriate
 205                                 account and then allocates a local UID or GID from the range of available IDs and
 206                                 creates an entry in its <filename>winbindd_idmap.tdb</filename> and
 207                                 <filename>winbindd_cache.tdb</filename> files.
 208                                 </para>
 209
 210                   <para><indexterm>
 211                       <primary>idmap backend</primary>
 212                     </indexterm><indexterm>
 213                       <primary>mapping</primary>
 214                     </indexterm>
 215                                 If the parameter
 216                         <smbconfoption><name>idmap backend</name><value>ldap:ldap://myserver.domain</value></smbconfoption>
 217                                 was specified and the LDAP server has been configured with a container in which it may
 218                                 store the IDMAP entries, all Domain Members may share a common mapping.
 219                                 </para></listitem>
 220                         </itemizedlist>
 221                         </para>
 222
 223                         <para>
 224                         Irrespective of how &smb.conf; is configured, winbind creates and caches a local copy of
 225                         the ID mapping database. It uses the <filename>winbindd_idmap.tdb</filename>, and
 226                                 <filename>winbindd_cache.tdb</filename> files to do this.
 227                         </para>
 228
 229                         <para>
 230                         Which of the above resolver methods is chosen is determined by the way that Samba is configured
 231                         in the &smb.conf; file. Some of the configuration options are rather less than obvious to the
 232                         casual user.
 233                         </para></listitem>
 234
 235           <listitem><para><indexterm>
 236                 <primary>winbind enable local accounts</primary>
 237               </indexterm><indexterm>
 238                 <primary>Domain Member</primary>
 239                 <secondary>servers</secondary>
 240               </indexterm><indexterm>
 241                 <primary>Domain Controllers</primary>
 242               </indexterm>
 243                         If you wish to make use of accounts (users and/or groups) that are local to (i.e., capable
 244                         of being resolved using) the name service switch (NSS) facility, it is imperative to use the
 245                         <smbconfoption><name>winbind enable local accounts</name><value>Yes</value></smbconfoption>
 246                         in the &smb.conf; file. This parameter specifically applies only to Domain Controllers,
 247                         not to Domain Member servers.
 248                         </para></listitem>
 249                 </itemizedlist>
 250
 251         <para><indexterm>
 252             <primary>Posix accounts</primary>
 253           </indexterm><indexterm>
 254             <primary>Samba accounts</primary>
 255           </indexterm><indexterm>
 256             <primary>LDAP</primary>
 257           </indexterm>
 258                 For many administrators, it should be plain that the use of an LDAP-based repository for all network
 259                 accounts (both for Posix accounts as well as for Samba accounts) provides the most elegant and
 260                 controllable facility. You eventually appreciate the decision to use LDAP.
 261                 </para>
 262
 263         <para><indexterm>
 264             <primary>nss_ldap</primary>
 265           </indexterm><indexterm>
 266             <primary>identifiers</primary>
 267           </indexterm><indexterm>
 268             <primary>resolve</primary>
 269           </indexterm>
 270                 If your network account information resides in an LDAP repository, you should use it ahead of any
 271                 alternative method. This means that if it is humanly possible to use the <command>nss_ldap</command>
 272                 tools to resolve UNIX account UIDs/GIDs via LDAP, this is the preferred solution, as it provides
 273                 a more readily controllable method for asserting the exact same user and group identifiers
 274                 throughout the network.
 275                 </para>
 276
 277                 <para><indexterm>
 278             <primary>Domain Member</primary>
 279             <secondary>server</secondary>
 280           </indexterm><indexterm>
 281             <primary>winbind trusted domains only</primary>
 282           </indexterm><indexterm>
 283             <primary>getpwnam</primary>
 284           </indexterm><indexterm>
 285             <primary>smbd</primary>
 286           </indexterm><indexterm>
 287             <primary>Trusted Domains</primary>
 288           </indexterm><indexterm>
 289             <primary>External Domains</primary>
 290           </indexterm>
 291                 In the situation where UNIX accounts are held on the Domain Member server itself, the only effective
 292                 way to use them involves the &smb.conf; entry
 293                 <smbconfoption><name>winbind trusted domains only</name><value>Yes</value></smbconfoption>. This forces
 294                 Samba (<command>smbd</command>) to perform a <command>getpwnam()</command> system call that can
 295                 then be controlled via <filename>/etc/nsswitch.conf</filename> file settings. The use of this parameter
 296                 disables the use of Samba with Trusted Domains (i.e., External Domains).
 297                 </para>
 298
 299         <para><indexterm>
 300             <primary>appliance mode</primary>
 301           </indexterm><indexterm>
 302             <primary>Domain Member</primary>
 303             <secondary>server</secondary>
 304           </indexterm><indexterm>
 305             <primary>winbindd</primary>
 306           </indexterm><indexterm>
 307             <primary>automatically allocate</primary>
 308           </indexterm>
 309                 Winbind can be used to create an appliance mode Domain Member server. In this capacity, <command>winbindd</command>
 310                 is configured to automatically allocate UIDs/GIDs from numeric ranges set in the &smb.conf; file. The allocation
 311                 is made for all accounts that connect to that Domain Member server, whether within its own Domain or from
 312                 Trusted Domains. If not stored in an LDAP backend, each Domain Member maintains its own unique mapping database.
 313                 This means that it is almost certain that a given user who accesses two Domain Member servers does not have the
 314                 same UID/GID on both servers &smbmdash; however, this is transparent to the Windows network user. This data
 315                 is stored in the <filename>winbindd_idmap.tdb</filename> and <filename>winbindd_cache.tdb</filename> files.
 316                 </para>
 317
 318         <para><indexterm>
 319             <primary>mapping</primary>
 320           </indexterm>
 321                 The use of an LDAP backend for the Winbind IDMAP facility permits Windows Domain security identifiers (SIDs)
 322                 mappings to UIDs/GIDs to be stored centrally. The result is a consistent mapping across all Domain Member
 323                 servers so configured. This solves one of the major headaches for network administrators who need to copy
 324                 files between/across network file servers.
 325                 </para>
 326
 327         </sect2>
 328
 329         <sect2>
 330                 <title>Political Issues</title>
 331
 332         <para><indexterm>
 333             <primary>OpenLDAP</primary>
 334           </indexterm><indexterm>
 335             <primary>NIS</primary>
 336           </indexterm><indexterm>
 337             <primary>yellow pages</primary>
 338             <see>NIS</see>
 339           </indexterm><indexterm>
 340             <primary>identity management</primary>
 341           </indexterm>
 342                 One of the most fierce conflicts recently being waged is one of resistance to the adoption of LDAP, in
 343                 particular OpenLDAP, as a replacement for UNIX NIS (previously called Yellow Pages). Let's face it, LDAP
 344                 is different and requires a new approach to the need for a better identity management solution. The more
 345                 you work with LDAP, the more its power and flexibility emerges from its dark, cavernous chasm.
 346                 </para>
 347
 348                 <para>
 349                 LDAP is a most suitable solution for heterogenous environments. If you need crypto, add Kerberos.
 350                 The reason these are preferable is because they are heterogenous. Windows solutions of this sort are NOT
 351                 heterogenous by design. This is fundamental &smbmdash; it isn't religious or political. This also doesn't say that
 352                 you can't use Windows Active Directory in a heterogenous environment &smbmdash; it can be done, it just requires
 353                 commercial integration products &smbmdash; it's just not what Active Directory was designed for.
 354                 </para>
 355
 356         <para><indexterm>
 357             <primary>directory</primary>
 358           </indexterm><indexterm>
 359             <primary>management</primary>
 360           </indexterm>
 361                 A number of long-term UNIX devotees have recently commented in various communications that the Samba Team
 362                 is the first application group to almost force network administrators to use LDAP. It should be pointed
 363                 out that we resisted this as long as we could. It is not out of laziness or out of malice that LDAP has
 364                 finally emerged as the preferred identity management backend for Samba. We recommend LDAP for your total
 365                 organizational directory needs.
 366                 </para>
 367
 368         </sect2>
 369
 370 </sect1>
 371
 372 <sect1>
 373         <title>Implementation</title>
 374
 375       <para><indexterm>
 376           <primary>Domain Member</primary>
 377           <secondary>server</secondary>
 378         </indexterm><indexterm>
 379           <primary>Domain Member</primary>
 380           <secondary>client</secondary>
 381         </indexterm><indexterm>
 382           <primary>Domain Controller</primary>
 383         </indexterm>
 384         The Domain Member server and the Domain Member client are at the center of focus in this chapter.
 385         Configuration of Samba-3 Domain Controller has been covered in earlier chapters, so if your
 386         interest is in Domain Controller configuration, you will not find that here. You will find good
 387         oil that helps you to add Domain Member servers and clients.
 388         </para>
 389
 390       <para><indexterm>
 391           <primary>Domain Member</primary>
 392           <secondary>workstations</secondary>
 393         </indexterm>
 394         In practice, Domain Member servers and Domain Member workstations are very different entities, but in
 395         terms of technology they share similar core infrastructure. A technologist would argue that servers
 396         and workstations are identical. Many users would argue otherwise, given that in a well-disciplined
 397         environment a workstation (client) is a device from which a user creates documents and files that
 398         are located on servers. A workstation is frequently viewed as a disposable (easy to replace) item,
 399         but a server is viewed as a core component of the business.
 400         </para>
 401
 402       <para><indexterm>
 403           <primary>workstation</primary>
 404         </indexterm>
 405         One can look at this another way. If a workstation breaks down, one user is affected, but if a
 406         server breaks down, hundreds of users may not be able to work. The services that a workstation
 407         must provide are document and file production oriented; a server provides information storage
 408         and is distribution oriented.
 409         </para>
 410
 411       <para><indexterm>
 412           <primary>authentication process</primary>
 413         </indexterm><indexterm>
 414           <primary>logon process</primary>
 415         </indexterm><indexterm>
 416           <primary>user identities</primary>
 417         </indexterm>
 418         <emphasis>Why is this important?</emphasis> &smbmdash; For starters, we must identify what
 419         components of the operating system and its environment must be configured. Also, it is necessary
 420         to recognize where the interdependencies between the various services to be used are.
 421         In particular, it is important to understand the operation of each critical part of the
 422         authentication process, the logon process, and how user identities get resolved and applied
 423         within the operating system and applications (like Samba) that depend on this and may
 424         actually contribute to it.
 425         </para>
 426
 427         <para>
 428         So, while here we demonstrate how to implement the technology. It is done within a context of
 429         what type of service need must be fulfilled.
 430         </para>
 431
 432         <sect2 id="sdcsdmldap">
 433                 <title>Samba Domain with Samba Domain Member Server &smbmdash; Using LDAP</title>
 434
 435         <para><indexterm>
 436             <primary>ldapsam</primary>
 437           </indexterm><indexterm>
 438             <primary>ldapsam backend</primary>
 439           </indexterm><indexterm>
 440             <primary>IDMAP</primary>
 441           </indexterm><indexterm>
 442             <primary>mapping</primary>
 443             <secondary>consistent</secondary>
 444           </indexterm><indexterm>
 445             <primary>winbindd</primary>
 446           </indexterm><indexterm>
 447             <primary>foreign SID</primary>
 448           </indexterm>
 449         In this example, it is assumed that you have Samba PDC/BDC servers. This means you are using
 450         an LDAP ldapsam backend. In this example, we are adding to the LDAP backend database (directory)
 451         containers for use by the IDMAP facility. This makes it possible to have globally consistent
 452         mapping of SIDs to/from UIDs/GIDs. This means that you are running <command>winbindd</command>
 453         as part of your configuration. The primary purpose of running <command>winbindd</command> (within
 454         this operational context) is to permit mapping of foreign SIDs (those not originating from our
 455         own Domain). Foreign SIDs can come from any external Domain or from Windows clients that do not
 456         belong to a Domain.
 457         </para>
 458
 459         <para><indexterm>
 460             <primary>winbindd</primary>
 461           </indexterm><indexterm>
 462             <primary>getpwnam</primary>
 463           </indexterm><indexterm>
 464             <primary>NSS</primary>
 465           </indexterm>
 466         If your installation is accessed only from clients that are members of your own domain, then
 467         it is not necessary to run <command>winbindd</command> as long as all users can be resolved
 468         locally via the <command>getpwnam()</command> system call. On NSS-enabled systems, this condition
 469         is met by having:
 470         </para>
 471
 472         <itemizedlist>
 473           <listitem><para><indexterm>
 474                 <primary>/etc/passwd</primary>
 475               </indexterm><indexterm>
 476                 <primary>/etc/group</primary>
 477               </indexterm>
 478                 All accounts in <filename>/etc/passwd</filename> or in <filename>/etc/group</filename>.
 479                 </para></listitem>
 480
 481           <listitem><para><indexterm>
 482                 <primary>NSS</primary>
 483               </indexterm><indexterm>
 484                 <primary>compat</primary>
 485               </indexterm><indexterm>
 486                 <primary>compat</primary>
 487               </indexterm><indexterm>
 488                 <primary>ldap</primary>
 489               </indexterm><indexterm>
 490                 <primary>nis</primary>
 491               </indexterm><indexterm>
 492                 <primary>nisplus</primary>
 493               </indexterm><indexterm>
 494                 <primary>hesoid</primary>
 495               </indexterm><indexterm>
 496                 <primary>ldap</primary>
 497               </indexterm><indexterm>
 498                 <primary>nss_ldap</primary>
 499               </indexterm><indexterm>
 500                 <primary>PADL Software</primary>
 501               </indexterm>
 502                 Resolution via NSS. On NSS-enabled systems, there is usually a facility to resolve IDs
 503                 via multiple methods. The methods typically include: <command>files, compat, db, ldap,
 504                 nis, nisplus, hesoid.</command>  When correctly installed, Samba adds to this list
 505                 the <command>winbindd</command> facility. The ldap facility is frequently the nss_ldap
 506                 tool provided by PADL Software.
 507                 </para></listitem>
 508         </itemizedlist>
 509
 510         <para><indexterm>
 511             <primary>Identity resolution</primary>
 512           </indexterm>
 513         The diagram in <link linkend="ch9-sambadc"/> demonstrates the relationship of samba and system
 514         components that are involved in the Identity resolution process where Samba is used as a Domain
 515         Member server within a Samba Domain Control network.
 516         </para>
 517
 518 <image id="ch9-sambadc">
 519         <imagedescription>Samba Domain: Samba Member Server</imagedescription>
 520         <imagefile scale="75">chap9-SambaDC</imagefile>
 521 </image>
 522
 523         <para><indexterm>
 524             <primary>IDMAP</primary>
 525           </indexterm><indexterm>
 526             <primary>foreign</primary>
 527           </indexterm>
 528         In this example configuration, Samba will directly search the LDAP-based passwd backend ldapsam
 529         to obtain authentication and user identity information. The IDMAP information is stored in the LDAP
 530         backend so that it can be shared by all Domain Member servers so that every user will have a
 531         consistent UID and GID across all of them. The IDMAP facility will be used for all foreign
 532         (i.e., not having the same SID as the Domain it is a member of) Domains. The configuration of
 533         NSS will ensure that all unix processes will obtain a consistent UID/GID.
 534         </para>
 535
 536         <para>
 537         The instructions given here apply to the Samba environment as shown in Chapters 6 and 7.
 538         If your network does not have an LDAP slave server (i.e., Chapter 6 configuration), you
 539         must change the target LDAP server from <constant>lapdc</constant> to <constant>massive.</constant>
 540         </para>
 541
 542         <procedure>
 543         <title>Configuration of LDAP-Based Identity Resolution</title>
 544
 545                 <step><para>
 546                 Create the &smb.conf; file as shown in <link linkend="ch9-sdmsdc"/>. Locate
 547                 this file in the directory <filename>/etc/samba</filename>.
 548                 </para></step>
 549
 550           <step><para><indexterm>
 551                 <primary>ldap.conf</primary>
 552               </indexterm>
 553                 Configure the file that will be used by <constant>nss_ldap</constant> to
 554                 locate and communicate with the LDAP server. This file is called <filename>ldap.conf</filename>.
 555                 If your implementation of <constant>nss_ldap</constant> is consistent with
 556                 the defaults suggested by PADL (the authors), it will be located in the
 557                 <filename>/etc</filename> directory. On some systems, the default location is
 558                 the <filename>/etc/openldap</filename> directory. Change the parameters inside
 559                 the file that is located on your OS so it matches <link linkend="ch9-sdmlcnf"/>.
 560                 To find the correct location of this file, you can obtain this from the
 561                 library that will be used by executing the following:
 562 <screen>
 563 &rootprompt; strings /lib/libnss_ldap* | grep ldap.conf
 564 /etc/ldap.conf
 565 </screen>
 566                 </para></step>
 567
 568                 <step><para>
 569                 Configure the name service switch (NSS) control file so it matches the one shown
 570                 in <link linkend="ch9-sdmnss"/>.
 571                 </para></step>
 572
 573           <step><para><indexterm>
 574                 <primary>Identity resolution</primary>
 575               </indexterm><indexterm>
 576                 <primary>getent</primary>
 577               </indexterm>
 578                 Before proceeding to configure Samba, validate the operation of the NSS Identity
 579                 resolution via LDAP by executing:
 580 <screen>
 581 &rootprompt; getent passwd
 582 ...
 583 root:x:0:512:Netbios Domain Administrator:/root:/bin/false
 584 nobody:x:999:514:nobody:/dev/null:/bin/false
 585 bobj:x:1000:513:Robert Jordan:/home/bobj:/bin/bash
 586 stans:x:1001:513:Stanley Soroka:/home/stans:/bin/bash
 587 chrisr:x:1002:513:Christine Roberson:/home/chrisr:/bin/bash
 588 maryv:x:1003:513:Mary Vortexis:/home/maryv:/bin/bash
 589 jht:x:1004:513:John H Terpstra:/home/jht:/bin/bash
 590 bldg1$:x:1006:553:bldg1$:/dev/null:/bin/false
 591 temptation$:x:1009:553:temptation$:/dev/null:/bin/false
 592 vaioboss$:x:1005:553:vaioboss$:/dev/null:/bin/false
 593 fran$:x:1008:553:fran$:/dev/null:/bin/false
 594 josephj:x:1007:513:Joseph James:/home/josephj:/bin/bash
 595 </screen>
 596                 You should notice the location of the users' home directories. First, make certain that
 597                 the home directories exist on the Domain Member server; otherwise, the home directory
 598                 share is not available. The home directories could be mounted off a domain controller
 599                 using NFS, or by any other suitable means. Second, the absence of the Domain name in the
 600                 home directory path is indicative that Identity resolution is not being done via Winbind.
 601 <screen>
 602 &rootprompt; getent group
 603 ...
 604 Domain Admins:x:512:root,jht
 605 Domain Users:x:513:bobj,stans,chrisr,maryv,jht,josephj
 606 Domain Guests:x:514:
 607 Accounts:x:1000:
 608 Finances:x:1001:
 609 PIOps:x:1002:
 610 sammy:x:4321:
 611 </screen>
 612               <indexterm>
 613                 <primary>secondary group</primary>
 614               </indexterm><indexterm>
 615                 <primary>primary group</primary>
 616               </indexterm><indexterm>
 617                 <primary>group membership</primary>
 618               </indexterm>
 619                 This shows that all is working as it should. Notice that in the LDAP database
 620                 the users primary and secondary group memberships are identical. It is not
 621                 necessary to add secondary group memberships (in the group database) if the
 622                 user is already a member via primary group membership in the password database.
 623                 When using winbind, it is in fact undesirable to do this as it results in
 624                 doubling up of group memberships and may break winbind under certain conditions.
 625                 </para></step>
 626
 627           <step><para><indexterm>
 628                 <primary>slapcat</primary>
 629               </indexterm>
 630                 The LDAP directory must have a container object for IDMAP data. There are several ways you can
 631                 check that your LDAP database is able to receive IDMAP information. One of the simplest is to
 632                 execute:
 633 <screen>
 634 &rootprompt; slapcat | grep -i idmap
 635 dn: ou=Idmap,dc=abmas,dc=biz
 636 ou: idmap
 637 </screen>
 638               <indexterm>
 639                 <primary>ldapadd</primary>
 640               </indexterm>
 641                 If the execution of this command does not return IDMAP entries, you need to create an LDIF
 642                 template file (see <link linkend="ch9-ldifadd"/>). You can add the required entries using the following command:
 643 <screen>
 644 &rootprompt; ldapadd -x -D "cn=Manager,dc=abmas,dc=biz" \
 645                 -w not24get &lt; /etc/openldap/idmap.LDIF
 646 </screen>
 647                 Samba automatically populates this LDAP directory container when it needs to.
 648                 </para></step>
 649
 650           <step><para><indexterm>
 651                 <primary>net</primary>
 652                 <secondary>rpc</secondary>
 653                 <tertiary>join</tertiary>
 654               </indexterm><indexterm>
 655                 <primary>Domain join</primary>
 656               </indexterm>
 657                 The system is ready to join the Domain. Execute the following:
 658 <screen>
 659 net rpc join -U root%not24et
 660 Joined domain MEGANET2.
 661 </screen>
 662                 This indicates that the Domain join succeeded.
 663                 </para></step>
 664
 665                 <step><para>
 666                 You may now start Samba in the usual manner and your Samba Domain Member server
 667                 is ready for use. Just add shares as required.
 668                 </para></step>
 669
 670         </procedure>
 671
 672 <smbconfexample id="ch9-sdmsdc">
 673 <title>Samba Domain Member in Samba Domain Control Context &smbmdash; &smb.conf; File</title>
 674 <smbconfcomment>Global parameters</smbconfcomment>
 675 <smbconfsection>[global]</smbconfsection>
 676 <smbconfoption><name>unix charset</name><value>LOCALE</value></smbconfoption>
 677 <smbconfoption><name>workgroup</name><value>MEGANET2</value></smbconfoption>
 678 <smbconfoption><name>security</name><value>DOMAIN</value></smbconfoption>
 679 <smbconfoption><name>username map</name><value>/etc/samba/smbusers</value></smbconfoption>
 680 <smbconfoption><name>log level</name><value>10</value></smbconfoption>
 681 <smbconfoption><name>syslog</name><value>0</value></smbconfoption>
 682 <smbconfoption><name>log file</name><value>/var/log/samba/%m</value></smbconfoption>
 683 <smbconfoption><name>max log size</name><value>50</value></smbconfoption>
 684 <smbconfoption><name>smb ports</name><value>139 445</value></smbconfoption>
 685 <smbconfoption><name>name resolve order</name><value>wins bcast hosts</value></smbconfoption>
 686 <smbconfoption><name>printcap name</name><value>CUPS</value></smbconfoption>
 687 <smbconfoption><name>wins server</name><value>192.168.2.1</value></smbconfoption>
 688 <smbconfoption><name>ldap suffix</name><value>dc=abmas,dc=biz</value></smbconfoption>
 689 <smbconfoption><name>ldap machine suffix</name><value>ou=People</value></smbconfoption>
 690 <smbconfoption><name>ldap user suffix</name><value>ou=People</value></smbconfoption>
 691 <smbconfoption><name>ldap group suffix</name><value>ou=Groups</value></smbconfoption>
 692 <smbconfoption><name>ldap idmap suffix</name><value>ou=Idmap</value></smbconfoption>
 693 <smbconfoption><name>ldap admin dn</name><value>cn=Manager,dc=abmas,dc=biz</value></smbconfoption>
 694 <smbconfoption><name>idmap backend</name><value>ldap:ldap://lapdc.abmas.biz</value></smbconfoption>
 695 <smbconfoption><name>idmap uid</name><value>10000-20000</value></smbconfoption>
 696 <smbconfoption><name>idmap gid</name><value>10000-20000</value></smbconfoption>
 697 <smbconfoption><name>winbind trusted domains only</name><value>Yes</value></smbconfoption>
 698 <smbconfoption><name>printer admin</name><value>root</value></smbconfoption>
 699 <smbconfoption><name>printing</name><value>cups</value></smbconfoption>
 700
 701 <smbconfsection>[homes]</smbconfsection>
 702 <smbconfoption><name>comment</name><value>Home Directories</value></smbconfoption>
 703 <smbconfoption><name>valid users</name><value>%S</value></smbconfoption>
 704 <smbconfoption><name>read only</name><value>No</value></smbconfoption>
 705 <smbconfoption><name>browseable</name><value>No</value></smbconfoption>
 706
 707 <smbconfsection>[printers]</smbconfsection>
 708 <smbconfoption><name>comment</name><value>SMB Print Spool</value></smbconfoption>
 709 <smbconfoption><name>path</name><value>/var/spool/samba</value></smbconfoption>
 710 <smbconfoption><name>guest ok</name><value>Yes</value></smbconfoption>
 711 <smbconfoption><name>printable</name><value>Yes</value></smbconfoption>
 712 <smbconfoption><name>browseable</name><value>No</value></smbconfoption>
 713
 714 <smbconfsection>[print$]</smbconfsection>
 715 <smbconfoption><name>comment</name><value>Printer Drivers</value></smbconfoption>
 716 <smbconfoption><name>path</name><value>/var/lib/samba/drivers</value></smbconfoption>
 717 <smbconfoption><name>admin users</name><value>root, Administrator</value></smbconfoption>
 718 <smbconfoption><name>write list</name><value>root</value></smbconfoption>
 719 </smbconfexample>
 720
 721 <example id="ch9-ldifadd">
 722 <title>LDIF IDMAP Add-On Load File &smbmdash; File: /etc/openldap/idmap.LDIF</title>
 723 <screen>
 724 dn: ou=Idmap,dc=abmas,dc=biz
 725 objectClass: organizationalUnit
 726 ou: idmap
 727 structuralObjectClass: organizationalUnit
 728 </screen>
 729 </example>
 730
 731 <example id="ch9-sdmlcnf">
 732 <title>Configuration File for NSS LDAP Support &smbmdash; <filename>/etc/ldap.conf</filename></title>
 733 <screen>
 734 URI     ldap://massive.abmas.biz ldap://massive.abmas.biz:636
 735 host    192.168.2.1
 736 base    dc=abmas,dc=biz
 737 binddn  cn=Manager,dc=abmas,dc=biz
 738 bindpw  not24get
 739
 740 pam_password exop
 741
 742 nss_base_passwd ou=People,dc=abmas,dc=biz?one
 743 nss_base_shadow ou=People,dc=abmas,dc=biz?one
 744 nss_base_group  ou=Groups,dc=abmas,dc=biz?one
 745 ssl     no
 746 </screen>
 747 </example>
 748
 749 <example id="ch9-sdmnss">
 750 <title>NSS using LDAP for Identity Resolution &smbmdash; File: <filename>/etc/nsswitch.conf</filename></title>
 751 <screen>
 752 passwd:         compat ldap
 753 group:          compat ldap
 754
 755 hosts:          files dns wins
 756 networks:       files dns
 757
 758 services:       files
 759 protocols:      files
 760 rpc:            files
 761 ethers:         files
 762 netmasks:       files
 763 netgroup:       files
 764 publickey:      files
 765
 766 bootparams:     files
 767 automount:      files
 768 aliases:        files
 769 </screen>
 770 </example>
 771
 772         </sect2>
 773
 774         <sect2 id="wdcsdm">
 775                 <title>NT4/Samba Domain with Samba Domain Member Server &smbmdash; Using Winbind</title>
 776
 777         <para>
 778         You need to use this method for creating a Samba Domain Member server if any of the following conditions
 779         prevail:
 780         </para>
 781
 782         <itemizedlist>
 783                 <listitem><para>
 784                 LDAP support (client) is not installed on the system.
 785                 </para></listitem>
 786
 787                 <listitem><para>
 788                 There are mitigating circumstances forcing a decision not to use LDAP.
 789                 </para></listitem>
 790
 791                 <listitem><para>
 792                 The Samba Domain Member server must be part of a Windows NT4 Domain.
 793                 </para></listitem>
 794         </itemizedlist>
 795
 796         <para><indexterm>
 797             <primary>Windows ADS Domain</primary>
 798           </indexterm><indexterm>
 799             <primary>Samba Domain</primary>
 800           </indexterm><indexterm>
 801             <primary>LDAP</primary>
 802           </indexterm>
 803         Later in the chapter, you can see how to configure a Samba Domain Member server for a Windows ADS Domain.
 804         Right now your objective is to configure a Samba server that can be a member of a Windows NT4 style
 805         Domain and/or does not use LDAP.
 806         </para>
 807
 808         <note><para><indexterm>
 809               <primary>duplicate accounts</primary>
 810             </indexterm>
 811         If you use <command>winbind</command> for Identity resolution, do make sure that there are no
 812         duplicate accounts.
 813         </para>
 814
 815           <para><indexterm>
 816               <primary>/etc/passwd</primary>
 817             </indexterm>
 818         For example, do not have more than one account that has UID=0 in the password database. If there
 819         is an account called <constant>root</constant> in the <filename>/etc/passwd</filename> database,
 820         it is okay to have an account called <constant>root</constant> in the LDAP ldapsam or in the
 821         tdbsam. But if there are two accounts in the passdb backend that have the same UID, winbind will
 822         break. This means that the <constant>Administrator</constant> account must be called
 823         <constant>root</constant>.
 824         </para>
 825
 826           <para><indexterm>
 827               <primary>/etc/passwd</primary>
 828             </indexterm><indexterm>
 829               <primary>ldapsam</primary>
 830             </indexterm><indexterm>
 831               <primary>tdbsam</primary>
 832             </indexterm>
 833         Winbind will break if there is an account in <filename>/etc/passwd</filename> that has
 834         the same UID as an account that is in LDAP ldapsam (or in tdbsam) but that differs in name only.
 835         </para></note>
 836
 837         <para><indexterm>
 838             <primary>credentials</primary>
 839           </indexterm><indexterm>
 840             <primary>traverse</primary>
 841           </indexterm><indexterm>
 842             <primary>wide-area</primary>
 843           </indexterm><indexterm>
 844             <primary>network</primary>
 845             <secondary>wide-area</secondary>
 846           </indexterm><indexterm>
 847             <primary>tdbdump</primary>
 848           </indexterm>
 849         The following configuration uses CIFS/SMB protocols alone to obtain user and group credentials.
 850         The winbind information is locally cached in the <filename>winbindd_cache.tdb winbindd_idmap.tdb</filename>
 851         files. This provides considerable performance benefits compared with the LDAP solution, particularly
 852         where the LDAP lookups must traverse wide-area network links. You may examine the contents of these
 853         files using the tool <command>tdbdump</command>, though you may have to build this from the Samba
 854         source code if it has not been supplied as part of a binary package distribution that you may be using.
 855         </para>
 856
 857         <procedure>
 858         <title>Configuration of Winbind-Based Identity Resolution</title>
 859
 860                 <step><para>
 861                 Using your favorite text editor, create the &smb.conf; file so it has the contents
 862                 shown in <link linkend="ch0-NT4DSDM"/>.
 863                 </para></step>
 864
 865           <step><para><indexterm>
 866                 <primary>/etc/nsswitch.conf</primary>
 867               </indexterm>
 868                 Edit the <filename>/etc/nsswitch.conf</filename> so it has the entries shown in
 869                 <link linkend="ch9-nsswbnd"/>.
 870                 </para></step>
 871
 872           <step><para><indexterm>
 873                 <primary>net</primary>
 874                 <secondary>rpc</secondary>
 875                 <tertiary>join</tertiary>
 876               </indexterm>
 877                 The system is ready to join the Domain. Execute the following:
 878 <screen>
 879 net rpc join -U root%not24et
 880 Joined domain MEGANET2.
 881 </screen>
 882                 This indicates that the Domain join succeed.
 883
 884                 </para></step>
 885
 886           <step><para><indexterm>
 887                 <primary>winbind</primary>
 888               </indexterm><indexterm>
 889                 <primary>wbinfo</primary>
 890               </indexterm>
 891                 Validate operation of <command>winbind</command> using the <command>wbinfo</command>
 892                 tool as follows:
 893 <screen>
 894 &rootprompt; wbinfo -u
 895 MEGANET2+root
 896 MEGANET2+nobody
 897 MEGANET2+jht
 898 MEGANET2+maryv
 899 MEGANET2+billr
 900 MEGANET2+jelliott
 901 MEGANET2+dbrady
 902 MEGANET2+joeg
 903 MEGANET2+balap
 904 </screen>
 905                 This shows that Domain users have been listed correctly.
 906 <screen>
 907 &rootprompt; wbinfo -g
 908 MEGANET2+Domain Admins
 909 MEGANET2+Domain Users
 910 MEGANET2+Domain Guests
 911 MEGANET2+Accounts
 912 MEGANET2+Finances
 913 MEGANET2+PIOps
 914 </screen>
 915                 This shows that Domain groups have been correctly obtained also.
 916                 </para></step>
 917
 918           <step><para><indexterm>
 919                 <primary>NSS</primary>
 920               </indexterm><indexterm>
 921                 <primary>getent</primary>
 922               </indexterm><indexterm>
 923                 <primary>winbind</primary>
 924               </indexterm>
 925                 The next step verifies that NSS is able to obtain this information
 926                 correctly from <command>winbind</command> also.
 927 <screen>
 928 &rootprompt; getent passwd
 929 ...
 930 MEGANET2+root:x:10000:10001:NetBIOS Domain Admin:
 931                       /home/MEGANET2/root:/bin/bash
 932 MEGANET2+nobody:x:10001:10001:nobody:
 933                       /home/MEGANET2/nobody:/bin/bash
 934 MEGANET2+jht:x:10002:10001:John H Terpstra:
 935                       /home/MEGANET2/jht:/bin/bash
 936 MEGANET2+maryv:x:10003:10001:Mary Vortexis:
 937                       /home/MEGANET2/maryv:/bin/bash
 938 MEGANET2+billr:x:10004:10001:William Randalph:
 939                       /home/MEGANET2/billr:/bin/bash
 940 MEGANET2+jelliott:x:10005:10001:John G Elliott:
 941                       /home/MEGANET2/jelliott:/bin/bash
 942 MEGANET2+dbrady:x:10006:10001:Darren Brady:
 943                       /home/MEGANET2/dbrady:/bin/bash
 944 MEGANET2+joeg:x:10007:10001:Joe Green:
 945                       /home/MEGANET2/joeg:/bin/bash
 946 MEGANET2+balap:x:10008:10001:Bala Pillay:
 947                       /home/MEGANET2/balap:/bin/bash
 948 </screen>
 949                 The user account information has been correctly obtained. This information has
 950                 been merged with the winbind template information configured in the &smb.conf; file.
 951 <screen>
 952 &rootprompt;# getent group
 953 ...
 954 MEGANET2+Domain Admins:x:10000:MEGANET2+root,MEGANET2+jht
 955 MEGANET2+Domain Users:x:10001:MEGANET2+jht,MEGANET2+maryv,\
 956         MEGANET2+billr,MEGANET2+jelliott,MEGANET2+dbrady,\
 957         MEGANET2+joeg,MEGANET2+balap
 958 MEGANET2+Domain Guests:x:10002:MEGANET2+nobody
 959 MEGANET2+Accounts:x:10003:
 960 MEGANET2+Finances:x:10004:
 961 MEGANET2+PIOps:x:10005:
 962 </screen>
 963                 </para></step>
 964
 965                 <step><para>
 966                 The Samba member server of a Windows NT4 Domain is ready for use.
 967                 </para></step>
 968         </procedure>
 969
 970 <smbconfexample id="ch0-NT4DSDM">
 971 <title>Samba Domain Member Server &smb.conf; File for NT4 Domain</title>
 972 <smbconfcomment>Global parameters</smbconfcomment>
 973 <smbconfsection>[global]</smbconfsection>
 974 <smbconfoption><name>unix charset</name><value>LOCALE</value></smbconfoption>
 975 <smbconfoption><name>workgroup</name><value>MEGANET2</value></smbconfoption>
 976 <smbconfoption><name>security</name><value>DOMAIN</value></smbconfoption>
 977 <smbconfoption><name>username map</name><value>/etc/samba/smbusers</value></smbconfoption>
 978 <smbconfoption><name>log level</name><value>1</value></smbconfoption>
 979 <smbconfoption><name>syslog</name><value>0</value></smbconfoption>
 980 <smbconfoption><name>log file</name><value>/var/log/samba/%m</value></smbconfoption>
 981 <smbconfoption><name>max log size</name><value>0</value></smbconfoption>
 982 <smbconfoption><name>smb ports</name><value>139 445</value></smbconfoption>
 983 <smbconfoption><name>name resolve order</name><value>wins bcast hosts</value></smbconfoption>
 984 <smbconfoption><name>printcap name</name><value>CUPS</value></smbconfoption>
 985 <smbconfoption><name>wins server</name><value>192.168.2.1</value></smbconfoption>
 986 <smbconfoption><name>idmap uid</name><value>10000-20000</value></smbconfoption>
 987 <smbconfoption><name>idmap gid</name><value>10000-20000</value></smbconfoption>
 988 <smbconfoption><name>template primary group</name><value>"Domain Users"</value></smbconfoption>
 989 <smbconfoption><name>template shell</name><value>/bin/bash</value></smbconfoption>
 990 <smbconfoption><name>winbind separator</name><value>+</value></smbconfoption>
 991 <smbconfoption><name>printer admin</name><value>root</value></smbconfoption>
 992 <smbconfoption><name>hosts allow</name><value>192.168.2., 192.168.3., 127.</value></smbconfoption>
 993 <smbconfoption><name>printing</name><value>cups</value></smbconfoption>
 994
 995 <smbconfsection>[homes]</smbconfsection>
 996 <smbconfoption><name>comment</name><value>Home Directories</value></smbconfoption>
 997 <smbconfoption><name>valid users</name><value>%S</value></smbconfoption>
 998 <smbconfoption><name>read only</name><value>No</value></smbconfoption>
 999 <smbconfoption><name>browseable</name><value>No</value></smbconfoption>
1000
1001 <smbconfsection>[printers]</smbconfsection>
1002 <smbconfoption><name>comment</name><value>SMB Print Spool</value></smbconfoption>
1003 <smbconfoption><name>path</name><value>/var/spool/samba</value></smbconfoption>
1004 <smbconfoption><name>guest ok</name><value>Yes</value></smbconfoption>
1005 <smbconfoption><name>printable</name><value>Yes</value></smbconfoption>
1006 <smbconfoption><name>browseable</name><value>No</value></smbconfoption>
1007
1008 <smbconfsection>[print$]</smbconfsection>
1009 <smbconfoption><name>comment</name><value>Printer Drivers</value></smbconfoption>
1010 <smbconfoption><name>path</name><value>/var/lib/samba/drivers</value></smbconfoption>
1011 <smbconfoption><name>admin users</name><value>root, Administrator</value></smbconfoption>
1012 <smbconfoption><name>write list</name><value>root</value></smbconfoption>
1013 </smbconfexample>
1014
1015 <example id="ch9-nsswbnd">
1016 <title>Name Service Switch Control File: <filename>/etc/nsswitch.conf</filename></title>
1017 <screen>
1018 # /etc/nsswitch.conf
1019
1020 passwd:         compat winbind
1021 group:          compat winbind
1022
1023 hosts:          files dns wins
1024 networks:       files dns
1025
1026 services:       files
1027 protocols:      files
1028 rpc:            files
1029 ethers:         files
1030 netmasks:       files
1031 netgroup:       files
1032 publickey:      files
1033
1034 bootparams:     files
1035 automount:      files
1036 aliases:        files
1037 </screen>
1038 </example>
1039
1040         </sect2>
1041
1042         <sect2 id="adssdm">
1043         <title>Active Directory Domain with Samba Domain Member Server</title>
1044
1045         <para><indexterm>
1046             <primary>Active Directory</primary>
1047             <secondary>join</secondary>
1048           </indexterm><indexterm>
1049             <primary>Kerberos</primary>
1050           </indexterm><indexterm>
1051             <primary>Domain Member</primary>
1052             <secondary>server</secondary>
1053           </indexterm>
1054         One of the much-sought-after features new to Samba-3 is the ability to join an Active Directory
1055         Domain using Kerberos protocols. This makes it possible to operate an entire Windows network
1056         without the need to run NetBIOS over TCP/IP and permits more secure networking in general. An
1057         exhaustively complete discussion of the protocols is not possible in this book; perhaps a
1058         later book may explore the intricacies of the NetBIOS-less operation that Samba-3 can participate
1059         in. For now, we simply focus on how a Samba-3 server can be made a Domain Member server.
1060         </para>
1061
1062         <para><indexterm>
1063             <primary>Active Directory</primary>
1064           </indexterm><indexterm>
1065             <primary>LDAP</primary>
1066           </indexterm><indexterm>
1067             <primary>Identity resolution</primary>
1068           </indexterm><indexterm>
1069             <primary>Kerberos</primary>
1070           </indexterm>
1071         The diagram in <link linkend="ch9-adsdc"/> demonstrates how Samba-3 interfaces with
1072         Microsoft Active Directory components. It should be noted that if Microsoft Windows Services
1073         for UNIX has been installed and correctly configured, it is possible to use client LDAP
1074         for Identity resolution just as can be done with Samba-3 when using an LDAP passdb backend.
1075         The UNIX tool that you need for this, as in the case of LDAP on UNIX/Linux, is the PADL
1076         Software nss_ldap tool-set. Compared with use of winbind and Kerberos, the use of
1077         LDAP-based Identity resolution is a little less secure. In view of the fact that this solution
1078         requires additional software to be installed on the Windows 200x ADS Domain Controllers,
1079         and that means more management overhead, it is likely that most Samba-3 ADS client sites
1080         may elect to use winbind.
1081         </para>
1082
1083         <para>
1084         Do not attempt to use this procedure if you are not 100 percent certain that the build of Samba-3
1085         you are using has been compiled and linked with all the tools necessary for this to work.
1086         Given the importance of this step, you must first validate that the Samba-3 message block
1087         daemon (<command>smbd</command>) has the necessary features.
1088         </para>
1089
1090         <para>
1091         The hypothetical domain you are using in this example assumes that the Abmas London office
1092         decided to take their own lead (some would say this is a typical behavior in a global
1093         corporate world; besides, a little divergence and conflict makes for an interesting life).
1094         The Windows Server 2003 ADS Domain is called <constant>london.abmas.biz</constant> and the
1095         name of the server is <constant>W2K3S</constant>. In ADS realm terms, the Domain Controller
1096         is known as <constant>w2k3s.london.abmas.biz</constant>. In NetBIOS nomenclature, the
1097         Domain Name is <constant>LONDON</constant> and the server name is <constant>W2K3S</constant>.
1098         </para>
1099
1100         <image id="ch9-adsdc">
1101                 <imagedescription>Active Directory Domain: Samba Member Server</imagedescription>
1102                 <imagefile scale="75">chap9-ADSDC</imagefile>
1103         </image>
1104
1105         <procedure>
1106           <step><para><indexterm>
1107                 <primary>smbd</primary>
1108               </indexterm>
1109                 Before you try to use Samba-3, you want to know for certain that your executables have
1110                 support for Kerberos and for LDAP. Execute the following to identify whether or
1111                 not this build is perhaps suitable for use:
1112 <screen>
1113 &rootprompt; cd /usr/sbin
1114 &rootprompt; smbd -b | grep KRB
1115    HAVE_KRB5_H
1116    HAVE_ADDR_TYPE_IN_KRB5_ADDRESS
1117    HAVE_KRB5
1118    HAVE_KRB5_AUTH_CON_SETKEY
1119    HAVE_KRB5_GET_DEFAULT_IN_TKT_ETYPES
1120    HAVE_KRB5_GET_PW_SALT
1121    HAVE_KRB5_KEYBLOCK_KEYVALUE
1122    HAVE_KRB5_KEYTAB_ENTRY_KEYBLOCK
1123    HAVE_KRB5_MK_REQ_EXTENDED
1124    HAVE_KRB5_PRINCIPAL_GET_COMP_STRING
1125    HAVE_KRB5_SET_DEFAULT_IN_TKT_ETYPES
1126    HAVE_KRB5_STRING_TO_KEY
1127    HAVE_KRB5_STRING_TO_KEY_SALT
1128    HAVE_LIBKRB5
1129 </screen>
1130                 The above output was obtained on a SuSE Linux system and shows the output for
1131                 Samba that has been compiled and linked with the Heimdal Kerberos libraries.
1132                 The following is a typical output that will be found on a Red Hat Linux system that
1133                 has been linked with the MIT Kerberos libraries:
1134 <screen>
1135 &rootprompt; cd /usr/sbin
1136 &rootprompt; smbd -b | grep KRB
1137    HAVE_KRB5_H
1138    HAVE_ADDRTYPE_IN_KRB5_ADDRESS
1139    HAVE_KRB5
1140    HAVE_KRB5_AUTH_CON_SETUSERUSERKEY
1141    HAVE_KRB5_ENCRYPT_DATA
1142    HAVE_KRB5_FREE_DATA_CONTENTS
1143    HAVE_KRB5_FREE_KTYPES
1144    HAVE_KRB5_GET_PERMITTED_ENCTYPES
1145    HAVE_KRB5_KEYTAB_ENTRY_KEY
1146    HAVE_KRB5_LOCATE_KDC
1147    HAVE_KRB5_MK_REQ_EXTENDED
1148    HAVE_KRB5_PRINCIPAL2SALT
1149    HAVE_KRB5_PRINC_COMPONENT
1150    HAVE_KRB5_SET_DEFAULT_TGS_KTYPES
1151    HAVE_KRB5_SET_REAL_TIME
1152    HAVE_KRB5_STRING_TO_KEY
1153    HAVE_KRB5_TKT_ENC_PART2
1154    HAVE_KRB5_USE_ENCTYPE
1155    HAVE_LIBGSSAPI_KRB5
1156    HAVE_LIBKRB5
1157 </screen>
1158                 You can validate that Samba has been compiled and linked with LDAP support
1159                 by executing:
1160 <screen>
1161 &rootprompt; smbd -b | grep LDAP
1162 massive:/usr/sbin # smbd -b | grep LDAP
1163    HAVE_LDAP_H
1164    HAVE_LDAP
1165    HAVE_LDAP_DOMAIN2HOSTLIST
1166    HAVE_LDAP_INIT
1167    HAVE_LDAP_INITIALIZE
1168    HAVE_LDAP_SET_REBIND_PROC
1169    HAVE_LIBLDAP
1170    LDAP_SET_REBIND_PROC_ARGS
1171 </screen>
1172                 This does look promising; <command>smbd</command> has been built with Kerberos and LDAP
1173                 support. You are relieved to know that it is safe to progress.
1174                 </para></step>
1175
1176           <step><para><indexterm>
1177                 <primary>Kerberos</primary>
1178                 <secondary>libraries</secondary>
1179               </indexterm><indexterm>
1180                 <primary>MIT Kerberos</primary>
1181               </indexterm><indexterm>
1182                 <primary>Heimdal Kerberos</primary>
1183               </indexterm><indexterm>
1184                 <primary>Kerberos</primary>
1185                 <secondary>MIT</secondary>
1186               </indexterm><indexterm>
1187                 <primary>Kerberos</primary>
1188                 <secondary>Heimdal</secondary>
1189               </indexterm><indexterm>
1190                 <primary>Red Hat Linux</primary>
1191               </indexterm><indexterm>
1192                 <primary>SUSE Linux</primary>
1193               </indexterm><indexterm>
1194                 <primary>SerNet</primary>
1195               </indexterm><indexterm>
1196                 <primary>validated</primary>
1197               </indexterm>
1198                 The next step is to identify which version of the Kerberos libraries have been used.
1199                 In order to permit Samba-3 to interoperate with Windows 2003 Active Directory, it is
1200                 essential that it has been linked with either MIT Kerberos version 1.3.1 or later,
1201                 or that it has been linked with Heimdal Kerberos 0.6 plus specific patches. You may
1202                 identify what version of the MIT Kerberos libraries are installed on your system by
1203                 executing (on Red Hat Linux):
1204 <screen>
1205 &rootprompt; rpm -q krb5
1206 </screen>
1207                 Or on SUSE Linux, execute:
1208 <screen>
1209 &rootprompt; rpm -q heimdal
1210 </screen>
1211                 Please note that the RPMs provided by the Samba-Team are known to be working and have
1212                 been validated. Red Hat Linux RPMs may be obtained from the Samba FTP sites. SUSE
1213                 Linux RPMs may be obtained from <ulink url="ftp://ftp.sernet.de">Sernet</ulink> in
1214                 Germany.
1215                 </para>
1216
1217                 <para>
1218                 From this point on, you are certain that the Samba-3 build you are using has the
1219                 necessary capabilities. You can now configure Samba-3 and the name service
1220                 switcher (NSS).
1221                 </para></step>
1222
1223                 <step><para>
1224                 Using you favorite editor, configure the &smb.conf; file that is located in the
1225                 <filename>/etc/samba</filename> directory so that it has the contents shown
1226                 in <link linkend="ch9-adssdm"/>.
1227                 </para></step>
1228
1229                 <step><para>
1230                 Edit or create the NSS control file so it has the contents shown in <link linkend="ch9-nsswbnd"/>.
1231                 </para></step>
1232
1233           <step><para><indexterm>
1234                 <primary>/etc/samba/secrets.tdb</primary>
1235               </indexterm>
1236                 Delete the file <filename>/etc/samba/secrets.tdb</filename>, if it exists. Of course, you
1237                 do keep a backup, don't you?
1238                 </para></step>
1239
1240                 <step><para>
1241                 Delete the tdb files that cache Samba information. You keep a backup of the old
1242                 files, of course. You also remove all files to ensure that nothing can pollute your
1243                 nice, new configuration. Execute the following (example is for SUSE Linux):
1244 <screen>
1245 &rootprompt; rm /var/lib/samba/*tdb
1246 </screen>
1247                 </para></step>
1248
1249           <step><para><indexterm>
1250                 <primary>testparm</primary>
1251               </indexterm>
1252                 Validate your &smb.conf; file using <command>testparm</command> (as you have
1253                 done previously). Correct all errors reported before proceeding. The command you
1254                 execute is:
1255 <screen>
1256 &rootprompt; testparm -s | less
1257 </screen>
1258                 Now that you are satisfied that your Samba server is ready to join the Windows
1259                 ADS Domain, let's move on.
1260                 </para></step>
1261
1262           <step><para><indexterm>
1263                 <primary>net</primary>
1264                 <secondary>ads</secondary>
1265                 <tertiary>join</tertiary>
1266               </indexterm><indexterm>
1267                 <primary>Kerberos</primary>
1268               </indexterm>
1269                 This is a good time to double-check everything and then execute the following
1270                 command when everything you have done has checked out okay:
1271 <screen>
1272 &rootprompt; net ads join -UAdministrator%not24get
1273 Using short domain name -- LONDON
1274 Joined 'FRAN' to realm 'LONDON.ABMAS.BIZ'
1275 </screen>
1276                 You have successfully made your Samba-3 server a member of the ADS Domain
1277                 using Kerberos protocols.
1278                 </para>
1279
1280             <para><indexterm>
1281                 <primary>silent return</primary>
1282               </indexterm><indexterm>
1283                 <primary>failed join</primary>
1284               </indexterm>
1285                 In the event that you receive no output messages, a silent return means that the
1286                 Domain join failed. You should use <command>ethereal</command> to identify what
1287                 may be failing. Common causes of a failed join include:
1288
1289                 <itemizedlist>
1290                 <listitem><para><indexterm>
1291                       <primary>name resolution</primary>
1292                       <secondary>Defective</secondary>
1293                     </indexterm>
1294                         Defective or misconfigured DNS name resolution.
1295                         </para></listitem>
1296
1297                 <listitem><para><indexterm>
1298                       <primary>Restrictive security</primary>
1299                     </indexterm>
1300                         Restrictive security settings on the Windows 200x ADS Domain controller
1301                         preventing needed communications protocols. You can check this by searching
1302                         the Windows Server 200x Event Viewer.
1303                         </para></listitem>
1304
1305                         <listitem><para>
1306                         Incorrectly configured &smb.conf; file settings.
1307                         </para></listitem>
1308
1309                         <listitem><para>
1310                         Lack of support of necessary Kerberos protocols because the version of MIT
1311                         Kerberos (or Heimdal) in use is not up to date enough to support the necessary
1312                         functionality.
1313                         </para></listitem>
1314                 </itemizedlist>
1315               <indexterm>
1316                 <primary>net</primary>
1317                 <secondary>rpc</secondary>
1318                 <tertiary>join</tertiary>
1319               </indexterm><indexterm>
1320                 <primary>RPC</primary>
1321               </indexterm><indexterm>
1322                 <primary>mixed mode</primary>
1323               </indexterm>
1324                 In any case, never execute the <command>net rpc join</command> command in an attempt
1325                 to join the Samba server to the Domain, unless you wish not to use the Kerberos
1326                 security protocols. Use of the older RPC-based Domain join facility requires that
1327                 Windows Server 200x ADS has been configured appropriately for mixed mode operation.
1328                 </para></step>
1329
1330           <step><para><indexterm>
1331                 <primary>tdbdump</primary>
1332               </indexterm><indexterm>
1333                 <primary>/etc/samba/secrets.tdb</primary>
1334               </indexterm>
1335                 If the <command>tdbdump</command> is installed on your system (not essential),
1336                 you can look inside the <filename>/etc/samba/secrets.tdb</filename> file. If
1337                 you wish to do this, execute:
1338 <screen>
1339 &rootprompt; tdbdump secrets.tdb
1340 {
1341 key = "SECRETS/SID/LONDON"
1342 data = "\01\04\00\00\00\00\00\05\15\00\00\00\EBw\86\F1\ED\BD\
1343    F6{\5C6\E5W\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\
1344    00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\
1345    00\00\00\00\00\00\00\00"
1346 }
1347 {
1348 key = "SECRETS/MACHINE_PASSWORD/LONDON"
1349 data = "le3Q5FPnN5.ueC\00"
1350 }
1351 {
1352 key = "SECRETS/MACHINE_SEC_CHANNEL_TYPE/LONDON"
1353 data = "\02\00\00\00"
1354 }
1355 {
1356 key = "SECRETS/MACHINE_LAST_CHANGE_TIME/LONDON"
1357 data = "E\89\F6?"
1358 }
1359 </screen>
1360                 This is given to demonstrate to the skeptics that this process truly does work.
1361                 </para></step>
1362
1363                 <step><para>
1364                 It is now time to start Samba in the usual way (as has been done many time before
1365                 in this book).
1366                 </para></step>
1367
1368           <step><para><indexterm>
1369                 <primary>wbinfo</primary>
1370               </indexterm>
1371                 This is a good time to verify that everything is working. First, check that
1372                 winbind is able to obtain the list of users and groups from the ADS Domain Controller.
1373                 Execute the following:
1374 <screen>
1375 &rootprompt; wbinfo -u
1376 LONDON+Administrator
1377 LONDON+Guest
1378 LONDON+SUPPORT_388945a0
1379 LONDON+krbtgt
1380 LONDON+jht
1381 </screen>
1382                 Good, the list of users was obtained. Now do likewise for group accounts:
1383 <screen>
1384 &rootprompt; wbinfo -g
1385 LONDON+Domain Computers
1386 LONDON+Domain Controllers
1387 LONDON+Schema Admins
1388 LONDON+Enterprise Admins
1389 LONDON+Domain Admins
1390 LONDON+Domain Users
1391 LONDON+Domain Guests
1392 LONDON+Group Policy Creator Owners
1393 LONDON+DnsUpdateProxy
1394 </screen>
1395                 Excellent. That worked also, as expected.
1396                 </para></step>
1397
1398           <step><para><indexterm>
1399                 <primary>getent</primary>
1400               </indexterm>
1401                 Now repeat this via NSS to validate that full Identity resolution is
1402                 functional as required. Execute:
1403 <screen>
1404 &rootprompt; getent passwd
1405 ...
1406 LONDON+Administrator:x:10000:10000:Administrator:
1407              /home/LONDON/administrator:/bin/bash
1408 LONDON+Guest:x:10001:10001:Guest:
1409              /home/LONDON/guest:/bin/bash
1410 LONDON+SUPPORT_388945a0:x:10002:10000:SUPPORT_388945a0:
1411              /home/LONDON/support_388945a0:/bin/bash
1412 LONDON+krbtgt:x:10003:10000:krbtgt:
1413              /home/LONDON/krbtgt:/bin/bash
1414 LONDON+jht:x:10004:10000:John H. Terpstra:
1415              /home/LONDON/jht:/bin/bash
1416 </screen>
1417                 Okay, ADS user accounts are being resolved. Now you try group resolution as follows:
1418 <screen>
1419 &rootprompt; getent group
1420 ...
1421 LONDON+Domain Computers:x:10002:
1422 LONDON+Domain Controllers:x:10003:
1423 LONDON+Schema Admins:x:10004:LONDON+Administrator
1424 LONDON+Enterprise Admins:x:10005:LONDON+Administrator
1425 LONDON+Domain Admins:x:10006:LONDON+jht,LONDON+Administrator
1426 LONDON+Domain Users:x:10000:
1427 LONDON+Domain Guests:x:10001:
1428 LONDON+Group Policy Creator Owners:x:10007:LONDON+Administrator
1429 LONDON+DnsUpdateProxy:x:10008:
1430 </screen>
1431                 This is very pleasing. Everything works as expected.
1432                 </para></step>
1433
1434           <step><para><indexterm>
1435                 <primary>net</primary>
1436                 <secondary>ads</secondary>
1437                 <tertiary>info</tertiary>
1438               </indexterm><indexterm>
1439                 <primary>Active Directory</primary>
1440                 <secondary>server</secondary>
1441               </indexterm><indexterm>
1442                 <primary>Kerberos</primary>
1443               </indexterm>
1444                 You may now perform final verification that communications between Samba-3 winbind and
1445                 the Active Directory server is using Kerberos protocols. Execute the following:
1446 <screen>
1447 &rootprompt; net ads info
1448 LDAP server: 192.168.2.123
1449 LDAP server name: w2k3s
1450 Realm: LONDON.ABMAS.BIZ
1451 Bind Path: dc=LONDON,dc=ABMAS,dc=BIZ
1452 LDAP port: 389
1453 Server time: Sat, 03 Jan 2004 02:44:44 GMT
1454 KDC server: 192.168.2.123
1455 Server time offset: 2
1456 </screen>
1457                 It should be noted that Kerberos protocols are time-clock critical. You should
1458                 keep all server time clocks synchronized using the network time protocol (NTP).
1459                 In any case, the output we obtained confirms that all systems are operational.
1460                 </para></step>
1461
1462           <step><para><indexterm>
1463                 <primary>net</primary>
1464                 <secondary>ads</secondary>
1465                 <tertiary>status</tertiary>
1466               </indexterm>
1467                 There is one more action you elect to take, just because you are paranoid and disbelieving,
1468                 so you execute the following command:
1469 <programlisting>
1470 &rootprompt; net ads status -UAdministrator%not24get
1471 objectClass: top
1472 objectClass: person
1473 objectClass: organizationalPerson
1474 objectClass: user
1475 objectClass: computer
1476 cn: fran
1477 distinguishedName: CN=fran,CN=Computers,DC=london,DC=abmas,DC=biz
1478 instanceType: 4
1479 whenCreated: 20040103092006.0Z
1480 whenChanged: 20040103092006.0Z
1481 uSNCreated: 28713
1482 uSNChanged: 28717
1483 name: fran
1484 objectGUID: 58f89519-c467-49b9-acb0-f099d73696e
1485 userAccountControl: 69632
1486 badPwdCount: 0
1487 codePage: 0
1488 countryCode: 0
1489 badPasswordTime: 0
1490 lastLogoff: 0
1491 lastLogon: 127175965783327936
1492 localPolicyFlags: 0
1493 pwdLastSet: 127175952062598496
1494 primaryGroupID: 515
1495 objectSid: S-1-5-21-4052121579-2079768045-1474639452-1109
1496 accountExpires: 9223372036854775807
1497 logonCount: 13
1498 sAMAccountName: fran$
1499 sAMAccountType: 805306369
1500 operatingSystem: Samba
1501 operatingSystemVersion: 3.0.2-SUSE
1502 dNSHostName: fran
1503 userPrincipalName: HOST/fran@LONDON.ABMAS.BIZ
1504 servicePrincipalName: CIFS/fran.london.abmas.biz
1505 servicePrincipalName: CIFS/fran
1506 servicePrincipalName: HOST/fran.london.abmas.biz
1507 servicePrincipalName: HOST/fran
1508 objectCategory: CN=Computer,CN=Schema,CN=Configuration,
1509                               DC=london,DC=abmas,DC=biz
1510 isCriticalSystemObject: FALSE
1511 -------------- Security Descriptor (revision: 1, type: 0x8c14)
1512 owner SID: S-1-5-21-4052121579-2079768045-1474639452-512
1513 group SID: S-1-5-21-4052121579-2079768045-1474639452-513
1514 ------- (system) ACL (revision: 4, size: 120, number of ACEs: 2)
1515 ------- ACE (type: 0x07, flags: 0x5a, size: 0x38,
1516                mask: 0x20, object flags: 0x3)
1517 access SID:  S-1-1-0
1518 access type: AUDIT OBJECT
1519 Permissions:
1520         [Write All Properties]
1521 ------- ACE (type: 0x07, flags: 0x5a, size: 0x38,
1522                mask: 0x20, object flags: 0x3)
1523 access SID:  S-1-1-0
1524 access type: AUDIT OBJECT
1525 Permissions:
1526         [Write All Properties]
1527 ------- (user) ACL (revision: 4, size: 1944, number of ACEs: 40)
1528 ------- ACE (type: 0x00, flags: 0x00, size: 0x24, mask: 0xf01ff)
1529 access SID:  S-1-5-21-4052121579-2079768045-1474639452-512
1530 access type: ALLOWED
1531 Permissions: [Full Control]
1532 ------- ACE (type: 0x00, flags: 0x00, size: 0x18, mask: 0xf01ff)
1533 access SID:  S-1-5-32-548
1534 ...
1535 ------- ACE (type: 0x05, flags: 0x12, size: 0x38,
1536                 mask: 0x10, object flags: 0x3)
1537 access SID:  S-1-5-9
1538 access type: ALLOWED OBJECT
1539 Permissions:
1540         [Read All Properties]
1541 -------------- End Of Security Descriptor
1542 </programlisting>
1543                 And now you have conclusive proof that your Samba-3 ADS Domain Member Server
1544                 called <constant>FRAN</constant>, is able to communicate fully with the ADS
1545                 Domain Controllers.
1546                 </para></step>
1547         </procedure>
1548
1549
1550         <para>
1551         Your Samba-3 ADS Domain Member server is ready for use. During training sessions,
1552         you may be asked what is inside the <filename>winbindd_cache.tdb and winbindd_idmap.tdb</filename>
1553         files. Since curiosity just took hold of you, execute the following:
1554 <programlisting>
1555 &rootprompt; tdbdump /var/lib/samba/winbindd_idmap.tdb
1556 {
1557 key = "S-1-5-21-4052121579-2079768045-1474639452-501\00"
1558 data = "UID 10001\00"
1559 }
1560 {
1561 key = "UID 10005\00"
1562 data = "S-1-5-21-4052121579-2079768045-1474639452-1111\00"
1563 }
1564 {
1565 key = "GID 10004\00"
1566 data = "S-1-5-21-4052121579-2079768045-1474639452-518\00"
1567 }
1568 {
1569 key = "S-1-5-21-4052121579-2079768045-1474639452-502\00"
1570 data = "UID 10003\00"
1571 }
1572 ...
1573
1574 &rootprompt; tdbdump /var/lib/samba/winbindd_cache.tdb
1575 {
1576 key = "UL/LONDON"
1577 data = "\00\00\00\00bp\00\00\06\00\00\00\0DAdministrator\0D
1578    Administrator-S-1-5-21-4052121579-2079768045-1474639452-500-
1579    S-1-5-21-4052121579-2079768045-1474639452-513\05Guest\05
1580    Guest-S-1-5-21-4052121579-2079768045-1474639452-501-
1581    S-1-5-21-4052121579-2079768045-1474639452-514\10
1582    SUPPORT_388945a0\10SUPPORT_388945a0.
1583    S-1-5-21-4052121579-2079768045-1474639452-1001-
1584    S-1-5-21-4052121579-2079768045-1474639452-513\06krbtgt\06
1585    krbtgt-S-1-5-21-4052121579-2079768045-1474639452-502-
1586    S-1-5-21-4052121579-2079768045-1474639452-513\03jht\10
1587    John H. Terpstra.S-1-5-21-4052121579-2079768045-1474639452-1110-
1588    S-1-5-21-4052121579-2079768045-1474639452-513"
1589 }
1590 {
1591 key = "GM/S-1-5-21-4052121579-2079768045-1474639452-512"
1592 data = "\00\00\00\00bp\00\00\02\00\00\00.
1593    S-1-5-21-4052121579-2079768045-1474639452-1110\03
1594    jht\01\00\00\00-S-1-5-21-4052121579-2079768045-1474639452-500\0D
1595    Administrator\01\00\00\00"
1596 }
1597 {
1598 key = "SN/S-1-5-21-4052121579-2079768045-1474639452-513"
1599 data = "\00\00\00\00xp\00\00\02\00\00\00\0CDomain Users"
1600 }
1601 {
1602 key = "GM/S-1-5-21-4052121579-2079768045-1474639452-518"
1603 data = "\00\00\00\00bp\00\00\01\00\00\00-
1604    S-1-5-21-4052121579-2079768045-1474639452-500\0D
1605    Administrator\01\00\00\00"
1606 }
1607 {
1608 key = "SEQNUM/LONDON\00"
1609 data = "xp\00\00C\92\F6?"
1610 }
1611 {
1612 key = "U/S-1-5-21-4052121579-2079768045-1474639452-1110"
1613 data = "\00\00\00\00xp\00\00\03jht\10John H. Terpstra.
1614    S-1-5-21-4052121579-2079768045-1474639452-1110-
1615    S-1-5-21-4052121579-2079768045-1474639452-513"
1616 }
1617 {
1618 key = "NS/S-1-5-21-4052121579-2079768045-1474639452-502"
1619 data = "\00\00\00\00bp\00\00-
1620    S-1-5-21-4052121579-2079768045-1474639452-502"
1621 }
1622 {
1623 key = "SN/S-1-5-21-4052121579-2079768045-1474639452-1001"
1624 data = "\00\00\00\00bp\00\00\01\00\00\00\10SUPPORT_388945a0"
1625 }
1626 {
1627 key = "SN/S-1-5-21-4052121579-2079768045-1474639452-500"
1628 data = "\00\00\00\00bp\00\00\01\00\00\00\0DAdministrator"
1629 }
1630 {
1631 key = "U/S-1-5-21-4052121579-2079768045-1474639452-502"
1632 data = "\00\00\00\00bp\00\00\06krbtgt\06krbtgt-
1633    S-1-5-21-4052121579-2079768045-1474639452-502-
1634    S-1-5-21-4052121579-2079768045-1474639452-513"
1635 }
1636 ....
1637 </programlisting>
1638         Now all is revealed. Your curiosity, as well as that of those with you, has been put at ease.
1639         May this server serve well all who happen upon it.
1640         </para>
1641
1642 <smbconfexample id="ch9-adssdm">
1643 <title>Samba Domain Member &smb.conf; File for Active Directory Membership</title>
1644 <smbconfcomment>Global parameters</smbconfcomment>
1645 <smbconfsection>[global]</smbconfsection>
1646 <smbconfoption><name>unix charset</name><value>LOCALE</value></smbconfoption>
1647 <smbconfoption><name>workgroup</name><value>LONDON</value></smbconfoption>
1648 <smbconfoption><name>realm</name><value>LONDON.ABMAS.BIZ</value></smbconfoption>
1649 <smbconfoption><name>server string</name><value>Samba 3.0.2</value></smbconfoption>
1650 <smbconfoption><name>security</name><value>ADS</value></smbconfoption>
1651 <smbconfoption><name>username map</name><value>/etc/samba/smbusers</value></smbconfoption>
1652 <smbconfoption><name>log level</name><value>1</value></smbconfoption>
1653 <smbconfoption><name>syslog</name><value>0</value></smbconfoption>
1654 <smbconfoption><name>log file</name><value>/var/log/samba/%m</value></smbconfoption>
1655 <smbconfoption><name>max log size</name><value>50</value></smbconfoption>
1656 <smbconfoption><name>printcap name</name><value>CUPS</value></smbconfoption>
1657 <smbconfoption><name>ldap ssl</name><value>no</value></smbconfoption>
1658 <smbconfoption><name>idmap uid</name><value>10000-20000</value></smbconfoption>
1659 <smbconfoption><name>idmap gid</name><value>10000-20000</value></smbconfoption>
1660 <smbconfoption><name>template primary group</name><value>"Domain Users"</value></smbconfoption>
1661 <smbconfoption><name>template shell</name><value>/bin/bash</value></smbconfoption>
1662 <smbconfoption><name>winbind separator</name><value>+</value></smbconfoption>
1663 <smbconfoption><name>printing</name><value>cups</value></smbconfoption>
1664
1665 <smbconfsection>[homes]</smbconfsection>
1666 <smbconfoption><name>comment</name><value>Home Directories</value></smbconfoption>
1667 <smbconfoption><name>valid users</name><value>%S</value></smbconfoption>
1668 <smbconfoption><name>read only</name><value>No</value></smbconfoption>
1669 <smbconfoption><name>browseable</name><value>No</value></smbconfoption>
1670
1671 <smbconfsection>[printers]</smbconfsection>
1672 <smbconfoption><name>comment</name><value>SMB Print Spool</value></smbconfoption>
1673 <smbconfoption><name>path</name><value>/var/spool/samba</value></smbconfoption>
1674 <smbconfoption><name>guest ok</name><value>Yes</value></smbconfoption>
1675 <smbconfoption><name>printable</name><value>Yes</value></smbconfoption>
1676 <smbconfoption><name>browseable</name><value>No</value></smbconfoption>
1677
1678 <smbconfsection>[print$]</smbconfsection>
1679 <smbconfoption><name>comment</name><value>Printer Drivers</value></smbconfoption>
1680 <smbconfoption><name>path</name><value>/var/lib/samba/drivers</value></smbconfoption>
1681 <smbconfoption><name>admin users</name><value>root, Administrator</value></smbconfoption>
1682 <smbconfoption><name>write list</name><value>root</value></smbconfoption>
1683 </smbconfexample>
1684
1685         </sect2>
1686
1687         <sect2>
1688         <title>UNIX/Linux Client Domain Member</title>
1689
1690         <para><indexterm>
1691             <primary>user credentials</primary>
1692           </indexterm>
1693         So far this chapter has been mainly concerned with the provision of file and print
1694         services for Domain Member servers. However, an increasing number of UNIX/Linux
1695         workstations are being installed that do not act as file or print servers to anyone
1696         other than a single desktop user. The key demand for desktop systems is to be able
1697         to log onto any UNIX/Linux or Windows desktop using the same network user credentials.
1698         </para>
1699
1700         <para><indexterm>
1701             <primary>Single Sign-On</primary>
1702             <see>SOS</see>
1703           </indexterm>
1704         The ability to use a common set of user credential across a variety of network systems
1705         is generally regarded as a Single Sign-On (SOS) solution. SOS systems are sold by a
1706         large number of vendors and include a range of technologies such as:
1707         </para>
1708
1709         <itemizedlist>
1710                 <listitem><para>
1711                 Proxy sign-on
1712                 </para></listitem>
1713
1714                 <listitem><para>
1715                 Federated directory provisioning
1716                 </para></listitem>
1717
1718                 <listitem><para>
1719                 Meta-directory server solutions
1720                 </para></listitem>
1721
1722                 <listitem><para>
1723                 Replacement authentication systems
1724                 </para></listitem>
1725         </itemizedlist>
1726
1727         <para><indexterm>
1728             <primary>Identity management</primary>
1729           </indexterm>
1730         There are really only three solutions that provide integrated authentication and
1731         user Identity management facilities:
1732         </para>
1733
1734         <itemizedlist>
1735                 <listitem><para>
1736                 Samba Winbind (free)
1737                 </para></listitem>
1738
1739                 <listitem><para>
1740                 <ulink url="http://www.padl.com">PADL</ulink> PAM and LDAP Tools (free)
1741                 </para></listitem>
1742
1743                 <listitem><para>
1744                 <ulink url="http://www.vintela.com">Vintela</ulink> Authentication Services (Commercial)
1745                 </para></listitem>
1746         </itemizedlist>
1747
1748         <para>
1749         The following guidelines are pertinent in respect of the deployment of winbind-based authentication
1750         and Identity resolution with the express purpose of allowing users to log onto UNIX/Linux desktops
1751         using Windows network Domain user credentials (username and password).
1752         </para>
1753
1754         <para>
1755         You should note that it is possible to use LDAP-based PAM and NSS tools to permit distributed
1756         systems logons (SSO) providing user and group accounts are stored in an LDAP directory. This
1757         provides logon services for UNIX/Linux users, while Windows users obtain their sign-on
1758         support via Samba-3.
1759         </para>
1760
1761         <para><indexterm>
1762             <primary>Windows Services for UNIX</primary>
1763             <see>SUS</see>
1764           </indexterm>
1765         On the other hand, if the authentication and Identity resolution backend must be provided by
1766         a Windows NT4 style Domain or from an Active Directory Domain that does not have the Microsoft
1767         Windows Services for UNIX (SUS) installed, winbind is your best friend. Specific guidance for these
1768         situations now follows.
1769         </para>
1770
1771         <para><indexterm>
1772             <primary>PAM</primary>
1773           </indexterm><indexterm>
1774             <primary>Identity resolution</primary>
1775           </indexterm><indexterm>
1776             <primary>NSS</primary>
1777           </indexterm>
1778         To permit users to log onto a Linux system using Windows network credentials, you need to
1779         configure Identity resolution (NSS) and PAM. This means that the basic steps include those
1780         outlined above with the addition of PAM configuration. Given that most workstations (desktop/client)
1781         usually do not need to provide file and print services to a group of users, the configuration
1782         of shares and printers is generally less important. Often this allows the share specifications
1783         to be entirely removed from the &smb.conf; file. That is obviously an administrator decision.
1784         </para>
1785
1786                 <sect3>
1787                 <title>NT4 Domain Member</title>
1788
1789                 <para>
1790                 The following steps provide a Linux system that users can log onto using
1791                 Windows NT4 Domain (or Samba-3) Domain network credentials:
1792                 </para>
1793
1794                 <procedure>
1795                         <step><para>
1796                         Follow the steps outlined in <link linkend="wdcsdm"/> and ensure that
1797                         all validation tests function as shown.
1798                         </para></step>
1799
1800                         <step><para>
1801                         Identify what services users must log onto. On Red Hat Linux, if it is
1802                         intended that the user shall be given access to all services, it may be
1803                         most expeditious to simply configure the file
1804                         <filename>/etc/pam.d/system-auth</filename>.
1805                         </para></step>
1806
1807                         <step><para>
1808                         Carefully make a backup copy of all PAM configuration files before you
1809                         begin making changes. If you break the PAM configuration, please note
1810                         that you may need to use an emergency boot process to recover your Linux
1811                         system. It is possible to break the ability to log into the system if
1812                         PAM files are incorrectly configured. The entire directory
1813                         <filename>/etc/pam.d</filename> should be backed up to a safe location.
1814                         </para></step>
1815
1816                         <step><para>
1817                         If you require only console login support, edit the <filename>/etc/pam.d/login</filename>
1818                         so it matches <link linkend="ch9-pamwnbdlogin"/>.
1819                         </para></step>
1820
1821                         <step><para>
1822                         To provide the ability to log onto the graphical desktop interface, you must edit
1823                         the files <filename>gdm</filename> and <filename>xdm</filename> in the
1824                         <filename>/etc/pam.d</filename> directory.
1825                         </para></step>
1826
1827                         <step><para>
1828                         Edit only one file at a time. Carefully validate its operation before attempting
1829                         to reboot the machine.
1830                         </para></step>
1831                 </procedure>
1832
1833                 </sect3>
1834
1835                 <sect3>
1836                 <title>ADS Domain Member</title>
1837
1838                 <para>
1839                 This procedure should be followed to permit a Linux network client (workstation/desktop)
1840                 to permit users to log on using Microsoft Active Directory based user credentials.
1841                 </para>
1842
1843                 <procedure>
1844                         <step><para>
1845                         Follow the steps outlined in <link linkend="adssdm"/> and ensure that
1846                         all validation tests function as shown.
1847                         </para></step>
1848
1849                         <step><para>
1850                         Identify what services users must log onto. On Red Hat Linux, if it is
1851                         intended that the user shall be given access to all services, it may be
1852                         most expeditious to simply configure the file
1853                         <filename>/etc/pam.d/system-auth</filename> as shown in <link linkend="ch9-rhsysauth"/>.
1854                         </para></step>
1855
1856                         <step><para>
1857                         Carefully make a backup copy of all PAM configuration files before you
1858                         begin making changes. If you break the PAM configuration, please note
1859                         that you may need to use an emergency boot process to recover your Linux
1860                         system. It is possible to break the ability to log into the system if
1861                         PAM files are incorrectly configured. The entire directory
1862                         <filename>/etc/pam.d</filename> should be backed up to a safe location.
1863                         </para></step>
1864
1865                         <step><para>
1866                         If you require only console login support, edit the <filename>/etc/pam.d/login</filename>
1867                         so it matches <link linkend="ch9-pamwnbdlogin"/>.
1868                         </para></step>
1869
1870                         <step><para>
1871                         To provide the ability to log onto the graphical desktop interface, you must edit
1872                         the files <filename>gdm</filename> and <filename>xdm</filename> in the
1873                         <filename>/etc/pam.d</filename> directory.
1874                         </para></step>
1875
1876                         <step><para>
1877                         Edit only one file at a time. Carefully validate its operation before attempting
1878                         to reboot the machine.
1879                         </para></step>
1880                 </procedure>
1881
1882                 </sect3>
1883
1884 <example id="ch9-pamwnbdlogin">
1885 <title>SUSE: PAM <filename>login</filename> Module Using Winbind</title>
1886 <screen>
1887 # /etc/pam.d/login
1888
1889 #%PAM-1.0
1890 auth sufficient pam_unix2.so    nullok
1891 auth sufficient pam_winbind.so use_first_pass use_authtok
1892 auth required   pam_securetty.so
1893 auth required   pam_nologin.so
1894 auth required   pam_env.so
1895 auth required   pam_mail.so
1896 account sufficient      pam_unix2.so
1897 account sufficient      pam_winbind.so user_first_pass use_authtok
1898 password required       pam_pwcheck.so  nullok
1899 password sufficient     pam_unix2.so    nullok use_first_pass use_authtok
1900 password sufficient     pam_winbind.so  use_first_pass use_authtok
1901 session sufficient      pam_unix2.so    none
1902 session sufficient      pam_winbind.so  use_first_pass use_authtok
1903 session required        pam_limits.so
1904 </screen>
1905 </example>
1906
1907 <example id="ch9-pamwbndxdm">
1908 <title>SUSE: PAM <filename>xdm</filename> Module Using Winbind</title>
1909 <screen>
1910 # /etc/pam.d/gdm (/etc/pam.d/xdm)
1911
1912 #%PAM-1.0
1913 auth     sufficient     pam_unix2.so     nullok
1914 auth     sufficient     pam_winbind.so   use_first_pass use_authtok
1915 account  sufficient     pam_unix2.so
1916 account  sufficient     pam_winbind.so   use_first_pass use_authtok
1917 password sufficient     pam_unix2.so
1918 password sufficient     pam_winbind.so   use_first_pass use_authtok
1919 session  sufficient     pam_unix2.so
1920 session  sufficient     pam_winbind.so   use_first_pass use_authtok
1921 session  required       pam_dev perm.so
1922 session  required       pam_resmgr.so
1923 </screen>
1924 </example>
1925
1926 <example id="ch9-rhsysauth">
1927 <title>Red Hat 9: PAM System Authentication File: <filename>/etc/pam.d/system-auth</filename> Module Using Winbind</title>
1928 <screen>
1929 #%PAM-1.0
1930 auth        required      /lib/security/$ISA/pam_env.so
1931 auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
1932 auth        sufficient    /lib/security/$ISA/pam_winbind.so use_first_pass
1933 auth        required      /lib/security/$ISA/pam_deny.so
1934
1935 account     required      /lib/security/$ISA/pam_unix.so
1936 account     sufficient    /lib/security/$ISA/pam_winbind.so use_first_pass
1937
1938 password    required      /lib/security/$ISA/pam_cracklib.so retry=3 type=
1939 # Note: The above line is complete. There is nothing following the '='
1940 password    sufficient    /lib/security/$ISA/pam_unix.so \
1941                                              nullok use_authtok md5 shadow
1942 password    sufficient    /lib/security/$ISA/pam_winbind.so use_first_pass
1943 password    required      /lib/security/$ISA/pam_deny.so
1944
1945 session     required      /lib/security/$ISA/pam_limits.so
1946 session     sufficient    /lib/security/$ISA/pam_unix.so
1947 session     sufficient    /lib/security/$ISA/pam_winbind.so use_first_pass
1948 </screen>
1949 </example>
1950
1951         </sect2>
1952
1953         <sect2>
1954                 <title>Key Points Learned</title>
1955
1956                 <para>
1957                 The addition of UNIX/Linux Samba servers and clients is a common requirement. In this chapter, you
1958                 learned how to integrate such servers so that the UID/GID mappings they use can be consistent
1959                 across all Domain Member servers. You also discovered how to implement the ability to use Samba
1960                 or Windows Domain account credentials to log onto a UNIX/Linux client.
1961                 </para>
1962
1963                 <para>
1964                 The following are key points noted:
1965                 </para>
1966
1967                 <itemizedlist>
1968                         <listitem><para>
1969                         Domain Controllers are always authoritative for the Domain.
1970                         </para></listitem>
1971
1972                         <listitem><para>
1973                         Domain Members may have local accounts and must be able to resolve the identity of
1974                         Domain user accounts. Domain user account identity must map to a local UID/GID. That
1975                         local UID/GID can be stored in LDAP. This way, it is possible to share the IDMAP data
1976                         across all Domain Member machines.
1977                         </para></listitem>
1978
1979                         <listitem><para>
1980                         Resolution of user and group identities on Domain Member machines may be implemented
1981                         using direct LDAP services or using winbind.
1982                         </para></listitem>
1983
1984                         <listitem><para>
1985                         On NSS/PAM enabled UNIX/Linux systems, NSS is responsible for Identity management
1986                         and PAM is responsible for authentication of logon credentials (user name and password).
1987                         </para></listitem>
1988                 </itemizedlist>
1989
1990         </sect2>
1991
1992 </sect1>
1993
1994 <sect1>
1995         <title>Questions and Answers</title>
1996
1997         <para>
1998         The following questions were obtained from the mailing list and also from private discussions
1999         with Windows network administrators.
2000         </para>
2001
2002         <qandaset defaultlabel="chap09qa" type="number">
2003         <qandaentry>
2004         <question>
2005
2006                 <para>
2007                 We use NIS for all UNIX accounts. Why do we need winbind?
2008                 </para>
2009
2010         </question>
2011         <answer>
2012
2013             <para><indexterm>
2014                 <primary>NIS</primary>
2015               </indexterm><indexterm>
2016                 <primary>encrypted passwords</primary>
2017               </indexterm><indexterm>
2018                 <primary>smbpasswd</primary>
2019               </indexterm><indexterm>
2020                 <primary>tdbsam</primary>
2021               </indexterm><indexterm>
2022                 <primary>passdb backend</primary>
2023               </indexterm><indexterm>
2024                 <primary>Winbind</primary>
2025               </indexterm>
2026                 You can use NIS for your UNIX accounts. NIS does not store the Windows encrypted
2027                 passwords that need to be stored in one of the acceptable passdb backends.
2028                 Your choice of backend is limited to <parameter>smbpasswd</parameter> or
2029                 <parameter>tdbsam</parameter>. Winbind is needed to handle the resolution of
2030                 SIDs from trusted domains to local UID/GID values.
2031                 </para>
2032
2033             <para><indexterm>
2034                 <primary>winbind trusted domains only</primary>
2035               </indexterm><indexterm>
2036                 <primary>getpwnam()</primary>
2037               </indexterm>
2038                 On a Domain Member server, you effectively map Windows Domain users to local users
2039                 that are in your NIS database by specifying the <parameter>winbind trusted domains
2040                 only</parameter>. This causes user and group account lookups to be routed via
2041                 the <command>getpwnam()</command> family of systems calls. On an NIS-enabled client,
2042                 this pushes the resolution of users and groups out through NIS.
2043                 </para>
2044
2045                 <para>
2046                 As a general rule, it is always a good idea to run winbind on all Samba servers.
2047                 </para>
2048
2049         </answer>
2050         </qandaentry>
2051
2052         <qandaentry>
2053         <question>
2054
2055                 <para>
2056                 Our IT management people do not like LDAP, but are looking at Microsoft Active Directory.
2057               Which is better?<indexterm>
2058                 <primary>Active Directory</primary>
2059               </indexterm>
2060                 </para>
2061
2062         </question>
2063         <answer>
2064
2065             <para><indexterm>
2066                 <primary>LDAP</primary>
2067                 <secondary>server</secondary>
2068               </indexterm><indexterm>
2069                 <primary>Kerberos</primary>
2070               </indexterm><indexterm>
2071                 <primary>schema</primary>
2072               </indexterm>
2073                 Microsoft Active Directory is an LDAP server that is intricately tied to a Kerberos
2074                 infrastructure. Most IT managers who object to LDAP do so because of the fact that
2075                 an LDAP server is most often supplied as a raw tool that needs to be configured, and
2076                 for which the administrator must create the schema, create the administration tools and
2077                 devise the backup and recovery facilities in a site dependent manner. LDAP servers
2078                 in general are seen as a high-energy, high-risk facility.
2079                 </para>
2080
2081             <para><indexterm>
2082                 <primary>management</primary>
2083               </indexterm>
2084                 Microsoft Active Directory by comparison is easy to install, configure, and
2085                 is supplied with all tools necessary to implement and manage the directory. For sites
2086                 that lack a lot of technical competence, Active Directory is a good choice. For sites
2087                 that have the technical competence to handle Active Directory well, LDAP is a good
2088                 alternative. The real issue that needs to be addressed is what type of solution does
2089                 the site want? If management wants a choice to use an alternative, they may want to
2090                 consider the options. On the other hand, if management just wants a solution that works,
2091                 Microsoft Active Directory is a good solution.
2092                 </para>
2093
2094         </answer>
2095         </qandaentry>
2096
2097         <qandaentry>
2098         <question>
2099
2100                 <para>
2101                 We want to implement a Samba PDC, four Samba BDCs, and 10 Samba servers. Is it possible
2102                 to use NIS in place of LDAP?
2103                 </para>
2104
2105         </question>
2106         <answer>
2107
2108             <para><indexterm>
2109                 <primary>NIS</primary>
2110               </indexterm><indexterm>
2111                 <primary>LDAP</primary>
2112               </indexterm><indexterm>
2113                 <primary>encrypted passwords</primary>
2114               </indexterm><indexterm>
2115                 <primary>synchronized</primary>
2116               </indexterm><indexterm>
2117                 <primary>secure account password</primary>
2118               </indexterm><indexterm>
2119                 <primary>PDC</primary>
2120               </indexterm><indexterm>
2121                 <primary>BDC</primary>
2122               </indexterm>
2123                 Yes, it is possible to use NIS in place of LDAP, but there may be problems with keeping
2124                 the Windows (SMB) encrypted passwords database correctly synchronized across the entire
2125                 network. Workstations (Windows client machines) periodically change their Domain
2126                 Membership secure account password. How can you keep changes that are on remote BDCs
2127                 synchronized on the PDC?
2128                 </para>
2129
2130             <para><indexterm>
2131                 <primary>centralized storage</primary>
2132               </indexterm><indexterm>
2133                 <primary>management</primary>
2134               </indexterm><indexterm>
2135                 <primary>network Identities</primary>
2136               </indexterm>
2137                 LDAP is a more elegant solution because it permits centralized storage and management
2138                 of all network Identities (user, group and machine accounts) together with all information
2139                 Samba needs to provide to network clients and their users.
2140                 </para>
2141
2142         </answer>
2143         </qandaentry>
2144
2145         <qandaentry>
2146         <question>
2147
2148                 <para>
2149                 Are you suggesting that users should not log onto a Domain Member server? If so, why?
2150                 </para>
2151
2152         </question>
2153         <answer>
2154
2155             <para><indexterm>
2156                 <primary>security</primary>
2157               </indexterm><indexterm>
2158                 <primary>data</primary>
2159                 <secondary>integrity</secondary>
2160               </indexterm><indexterm>
2161                 <primary>mapped drives</primary>
2162               </indexterm>
2163                 Many UNIX administrators mock the model that the Personal Computer industry has adopted
2164                 as normative since the early days of Novell Netware. One may well argue that the old
2165                 perception of the necessity to keep users off file and print servers was a result of
2166                 fears concerning the security and integrity of data. It was a simple and generally
2167                 effective measure to keep users away from servers, except through mapped drives.
2168                 </para>
2169
2170             <para><indexterm>
2171                 <primary>user logins</primary>
2172               </indexterm><indexterm>
2173                 <primary>risk</primary>
2174               </indexterm><indexterm>
2175                 <primary>user errors</primary>
2176               </indexterm><indexterm>
2177                 <primary>strategy</primary>
2178               </indexterm><indexterm>
2179                 <primary>policy</primary>
2180               </indexterm>
2181                 UNIX administrators are fully correct in asserting that UNIX servers and workstations
2182                 are identical in terms of the software that is installed. They correctly assert that
2183                 in a well secured environment it is safe to store files on a system that has hundreds
2184                 of users. But all network administrators must factor into the decision to allow or
2185                 reject general user logins to a UNIX system that is principally a file and print
2186                 server. One must take account of the risk to operations through simple user errors.
2187                 Only then can one begin to appraise the best strategy and adopt a site-specific
2188                 policy that best protects the needs of users and of the organization alike.
2189                 </para>
2190
2191             <para><indexterm>
2192                 <primary>system level logins</primary>
2193               </indexterm>
2194                 From experience, it is my recommendation to keep general system level logins to a
2195                 practical minimum and to eliminate them if possible. This should not be taken as a
2196                 hard rule, though. The better question is, what works best for the site?
2197                 </para>
2198
2199         </answer>
2200         </qandaentry>
2201
2202         <qandaentry>
2203         <question>
2204
2205             <para><indexterm>
2206                 <primary>winbind enable local accounts</primary>
2207               </indexterm><indexterm>
2208                 <primary>/etc/passwd</primary>
2209               </indexterm><indexterm>
2210                 <primary>options list</primary>
2211               </indexterm><indexterm>
2212                 <primary>ACL</primary>
2213               </indexterm><indexterm>
2214                 <primary>share</primary>
2215               </indexterm>
2216                 In my &smb.conf; file, I enabled the parameter <parameter>winbind enable local accounts
2217                 </parameter> on all Domain Member servers, but it does not work. The accounts I put in
2218                 <filename>/etc/passwd</filename> do not show up in the options list when I try to set an
2219                 ACL on a share. What have I done wrong?
2220                 </para>
2221
2222         </question>
2223         <answer>
2224
2225             <para><indexterm>
2226                 <primary>local users</primary>
2227               </indexterm><indexterm>
2228                 <primary>local groups</primary>
2229               </indexterm><indexterm>
2230                 <primary>UNIX account</primary>
2231               </indexterm><indexterm>
2232                 <primary>getpwnam()</primary>
2233               </indexterm><indexterm>
2234                 <primary>getgrgid()</primary>
2235               </indexterm><indexterm>
2236                 <primary>Identity resolution</primary>
2237               </indexterm><indexterm>
2238                 <primary>failure</primary>
2239               </indexterm><indexterm>
2240                 <primary>Domain</primary>
2241               </indexterm>
2242                 The manual page for this &smb.conf; file parameter clearly says, <quote>This parameter
2243                 controls whether or not winbindd will act as a stand in replacement for the various
2244                 account management hooks in smb.conf (for example, add user script). If enabled, winbindd
2245                 will support the creation of local users and groups as another source of UNIX account
2246                 information available via getpwnam() or getgrgid(), etc...</quote> By default this
2247                 parameter is already enabled; therefore, the action you are seeing is a result of a failure
2248                 of Identity resolution in the Domain.
2249                 </para>
2250
2251             <para><indexterm>
2252                 <primary>Domain logons</primary>
2253               </indexterm><indexterm>
2254                 <primary>Identity resolution</primary>
2255               </indexterm><indexterm>
2256                 <primary>Domain</primary>
2257                 <secondary>user</secondary>
2258               </indexterm><indexterm>
2259                 <primary>Domain</primary>
2260                 <secondary>group</secondary>
2261               </indexterm><indexterm>
2262                 <primary>UID</primary>
2263               </indexterm><indexterm>
2264                 <primary>GID</primary>
2265               </indexterm>
2266                 These are the accounts that are available for Windows network Domain logons. Providing
2267                 Identity resolution has been correctly configured on the Domain Controllers, as well as
2268                 on Domain Member servers. The Domain user and group identities automatically map
2269                 to a valid local UID and GID pair.
2270                 </para>
2271
2272         </answer>
2273         </qandaentry>
2274
2275         <qandaentry>
2276         <question>
2277
2278             <para><indexterm>
2279                 <primary>trusted domains</primary>
2280               </indexterm><indexterm>
2281                 <primary>domain</primary>
2282                 <secondary>trusted</secondary>
2283               </indexterm><indexterm>
2284                 <primary>winbind trusted domains only</primary>
2285               </indexterm><indexterm>
2286                 <primary>domain members</primary>
2287               </indexterm>
2288                 We want to ensure that only users from our own domain plus from trusted domains can use our
2289                 Samba servers. In the &smb.conf; file on all servers, we have enabled the <parameter>winbind
2290                 trusted domains only</parameter> parameter. We now find that users from trusted domains
2291                 cannot access our servers, and users from Windows clients that are not domain members
2292                 can also access our servers. Is this a Samba bug?
2293                 </para>
2294
2295         </question>
2296         <answer>
2297
2298             <para><indexterm>
2299                 <primary>distributed</primary>
2300               </indexterm><indexterm>
2301                 <primary>NIS</primary>
2302               </indexterm><indexterm>
2303                 <primary>rsync</primary>
2304               </indexterm><indexterm>
2305                 <primary>LDAP</primary>
2306               </indexterm><indexterm>
2307                 <primary>winbindd</primary>
2308               </indexterm><indexterm>
2309                 <primary>/etc/passwd</primary>
2310               </indexterm>
2311                 The manual page for this <parameter>winbind trusted domains only</parameter> parameter says,
2312                 <quote>This parameter is designed to allow Samba servers that are members of a Samba controlled
2313                 domain to use UNIX accounts distributed vi NIS, rsync, or LDAP as the UIDs for winbindd users
2314                 in the hosts primary domain. Therefore,  the user <constant>SAMBA\user1</constant> would be
2315                 mapped to the account <constant>user1</constant> in <filename>/etc/passwd</filename> instead
2316                 of allocating a new UID for him or her.</quote> This would clearly suggest that you are trying
2317                 to use this parameter inappropriately.
2318                 </para>
2319
2320             <para><indexterm>
2321                 <primary>valid users</primary>
2322               </indexterm>
2323                 A far better solution would be to use the <parameter>valid users</parameter> by specifying
2324                 precisely the Domain users and groups that should be permitted access to the shares. You could,
2325                 for example, set the following parameters:
2326 <screen>
2327 [demoshare]
2328         path = /export/demodata
2329         valid users = @"Domain Users", @"OTHERDOMAIN\Domain Users"
2330 </screen>
2331                 </para>
2332
2333
2334         </answer>
2335         </qandaentry>
2336
2337         <qandaentry>
2338         <question>
2339
2340                 <para>
2341                 What are the benefits of using LDAP for my Domain Member servers?
2342                 </para>
2343
2344         </question>
2345         <answer>
2346
2347             <para><indexterm>
2348                 <primary>LDAP</primary>
2349               </indexterm><indexterm>
2350                 <primary>benefit</primary>
2351               </indexterm><indexterm>
2352                 <primary>UID</primary>
2353               </indexterm><indexterm>
2354                 <primary>GID</primary>
2355               </indexterm><indexterm>
2356                 <primary>Domain Controllers</primary>
2357               </indexterm><indexterm>
2358                 <primary>Domain Member servers</primary>
2359               </indexterm><indexterm>
2360                 <primary>copy</primary>
2361               </indexterm><indexterm>
2362                 <primary>replicate</primary>
2363               </indexterm><indexterm>
2364                 <primary>identity</primary>
2365               </indexterm>
2366                 The key benefit of using LDAP is that the UID of all users and the GID of all groups
2367                 are globally consistent on Domain Controllers as well as on Domain Member servers.
2368                 This means that it is possible to copy/replicate files across servers without
2369                 loss of identity.
2370                 </para>
2371
2372             <para><indexterm>
2373                 <primary>Identity resolution</primary>
2374               </indexterm><indexterm>
2375                 <primary>winbind</primary>
2376               </indexterm><indexterm>
2377                 <primary>IDMAP backend</primary>
2378               </indexterm><indexterm>
2379                 <primary>LDAP</primary>
2380               </indexterm><indexterm>
2381                 <primary>Domain Controllers</primary>
2382               </indexterm><indexterm>
2383                 <primary>Domain Member</primary>
2384                 <secondary>servers</secondary>
2385               </indexterm><indexterm>
2386                 <primary>Posix</primary>
2387               </indexterm><indexterm>
2388                 <primary>account information</primary>
2389               </indexterm>
2390                 When use is made of account Identity resolution via winbind, even when an IDMAP backend
2391                 is stored in LDAP, the UID/GID on Domain Member servers is consistent, but differs
2392                 from the ID that the user/group has on Domain Controllers. The winbind allocated UID/GID
2393                 that is stored in LDAP (or locally) will be in the numeric range specified in the <parameter>
2394                 idmap uid/gid</parameter> in the &smb.conf; file. On Domain Controllers, the UID/GID is
2395                 that of the Posix value assigned in the LDAP directory as part of the Posix account information.
2396                 </para>
2397
2398         </answer>
2399         </qandaentry>
2400
2401         <qandaentry>
2402         <question>
2403
2404                 <para>
2405                 Is proper DNS operation necessary for Samba-3 plus LDAP? If so, what must I put into
2406                 my DNS configuration?
2407                 </para>
2408
2409         </question>
2410         <answer>
2411
2412             <para><indexterm>
2413                 <primary>DNS</primary>
2414                 <secondary>configuration</secondary>
2415               </indexterm><indexterm>
2416                 <primary>DNS</primary>
2417                 <secondary>lookup</secondary>
2418               </indexterm><indexterm>
2419                 <primary>hosts</primary>
2420               </indexterm><indexterm>
2421                 <primary>/etc/nsswitch.conf</primary>
2422               </indexterm><indexterm>
2423                 <primary>NSS</primary>
2424               </indexterm><indexterm>
2425                 <primary>/etc/hosts</primary>
2426               </indexterm><indexterm>
2427                 <primary>WINS</primary>
2428                 <secondary>lookup</secondary>
2429               </indexterm>
2430                 Samba depends on correctly functioning resolution of host names to their IP address. Samba
2431                 makes no direct DNS lookup calls, but rather redirects all name to address calls via the
2432                 <command>getXXXbyXXX()</command> function calls. The configuration of the <constant>hosts</constant>
2433                 entry in the NSS <filename>/etc/nsswitch.conf</filename> file determines how the underlying
2434                 resolution process is implemented. If the <constant>hosts</constant> entry in your NSS
2435                 control file says:
2436 <screen>
2437 hosts: files dns wins
2438 </screen>
2439                 This means that a host name lookup first tries the <filename>/etc/hosts</filename>.
2440                 If this fails to resolve, it attempts a DNS lookup and if that fails, it tries a
2441                 WINS lookup.
2442                 </para>
2443
2444             <para><indexterm>
2445                 <primary>NetBIOS</primary>
2446               </indexterm><indexterm>
2447                 <primary>TCP/IP</primary>
2448               </indexterm><indexterm>
2449                 <primary>name resolution</primary>
2450               </indexterm>
2451                 The addition of the WINS-based name lookup makes sense only if NetBIOS over TCP/IP has
2452                 been enabled on all Windows clients. Where NetBIOS over TCP/IP has been disabled, DNS
2453                 is the preferred name resolution technology. This usually makes most sense when Samba
2454                 is a client of an Active Directory Domain, where NetBIOS use has been disabled. In this
2455                 case, the Windows 200x auto-registers all locator records it needs with its own DNS
2456                 server/s.
2457                 </para>
2458
2459         </answer>
2460         </qandaentry>
2461
2462         <qandaentry>
2463         <question>
2464
2465                 <para>
2466                 Our Windows 2003 Server Active Directory Domain runs with NetBIOS disabled. Can we
2467                 use Samba-3 with that configuration?
2468                 </para>
2469
2470         </question>
2471         <answer>
2472
2473                 <para>
2474                 Yes.
2475                 </para>
2476
2477         </answer>
2478         </qandaentry>
2479
2480         <qandaentry>
2481         <question>
2482
2483             <para><indexterm>
2484                 <primary>net</primary>
2485                 <secondary>ads</secondary>
2486                 <tertiary>join</tertiary>
2487               </indexterm><indexterm>
2488                 <primary>net</primary>
2489                 <secondary>rpc</secondary>
2490                 <tertiary>join</tertiary>
2491               </indexterm>
2492                 When I tried to execute <quote>net ads join</quote>, I got no output. It did not work, so
2493                 I think that it failed. I then executed <quote>net rpc join</quote> and that worked fine.
2494                 That is okay, isn't it?
2495                 </para>
2496
2497         </question>
2498         <answer>
2499
2500             <para><indexterm>
2501                 <primary>Kerberos</primary>
2502               </indexterm><indexterm>
2503                 <primary>authentication</primary>
2504               </indexterm>
2505                 No. This is not okay. It means that your Samba-3 client has joined the ADS Domain as
2506                 a Windows NT4 client, and Samba-3 will not be using Kerberos-based authentication.
2507                 </para>
2508
2509         </answer>
2510         </qandaentry>
2511
2512         </qandaset>
2513
2514 </sect1>
2515
2516 </chapter>