docs-xml/Samba3-HOWTO/TOSHARG-IDMAP.xml

   1 <?xml version="1.0" encoding="iso-8859-1"?>
   2 <!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
   3 <chapter id="idmapper">
   4 <chapterinfo>
   5         &author.jht;
   6 </chapterinfo>
   7
   8 <title>Identity Mapping (IDMAP)</title>
   9
  10 <para>
  11 <indexterm><primary>Windows</primary></indexterm>
  12 <indexterm><primary>interoperability</primary></indexterm>
  13 <indexterm><primary>IDMAP</primary></indexterm>
  14 <indexterm><primary>Windows Security Identifiers</primary><see>SID</see></indexterm>
  15 <indexterm><primary>SID</primary></indexterm>
  16 <indexterm><primary>UID</primary></indexterm>
  17 <indexterm><primary>GID</primary></indexterm>
  18 The Microsoft Windows operating system has a number of features that impose specific challenges
  19 to interoperability with the operating systems on which Samba is implemented. This chapter deals
  20 explicitly with the mechanisms Samba-3 (version 3.0.8 and later) uses to overcome one of the
  21 key challenges in the integration of Samba servers into an MS Windows networking environment.
  22 This chapter deals with identity mapping (IDMAP) of Windows security identifiers (SIDs)
  23 to UNIX UIDs and GIDs.
  24 </para>
  25
  26 <para>
  27 To ensure sufficient coverage, each possible Samba deployment type is discussed.
  28 This is followed by an overview of how the IDMAP facility may be implemented.
  29 </para>
  30
  31 <para>
  32 <indexterm><primary>network client</primary></indexterm>
  33 <indexterm><primary>IDMAP</primary></indexterm>
  34 <indexterm><primary>IDMAP infrastructure</primary></indexterm>
  35 <indexterm><primary>default behavior</primary></indexterm>
  36 The IDMAP facility is of concern where more than one Samba server (or Samba network client)
  37 is installed in a domain. Where there is a single Samba server, do not be too concerned regarding
  38 the IDMAP infrastructure &smbmdash; the default behavior of Samba is nearly always sufficient.
  39 Where mulitple Samba servers are used it is often necessary to move data off one server and onto
  40 another, and that is where the fun begins!
  41 </para>
  42
  43 <para>
  44 <indexterm><primary>UID</primary></indexterm>
  45 <indexterm><primary>GID</primary></indexterm>
  46 <indexterm><primary>LDAP</primary></indexterm>
  47 <indexterm><primary>NSS</primary></indexterm>
  48 <indexterm><primary>nss_ldap</primary></indexterm>
  49 <indexterm><primary>NT4 domain members</primary></indexterm>
  50 <indexterm><primary>ADS domain members</primary></indexterm>
  51 <indexterm><primary>security name-space</primary></indexterm>
  52 Where user and group account information is stored in an LDAP directory every server can have the same
  53 consistent UID and GID for users and groups. This is achieved using NSS and the nss_ldap tool. Samba
  54 can be configured to use only local accounts, in which case the scope of the IDMAP problem is somewhat
  55 reduced. This works reasonably well if the servers belong to a single domain, and interdomain trusts
  56 are not needed. On the other hand, if the Samba servers are NT4 domain members, or ADS  domain members,
  57 or if there is a need to keep the security name-space separate (i.e., the user
  58 <literal>DOMINICUS\FJones</literal> must not be given access to the account resources of the user
  59 <literal>FRANCISCUS\FJones</literal><footnote>Samba local account mode results in both
  60 <literal>DOMINICUS\FJones</literal> and <literal>FRANCISCUS\FJones</literal> mapping to the UNIX user
  61 <literal>FJones</literal>.</footnote> free from inadvertent cross-over, close attention should be given
  62 to the way that the IDMAP facility is configured.
  63 </para>
  64
  65 <para>
  66 <indexterm><primary>IDMAP</primary></indexterm>
  67 <indexterm><primary>domain access</primary></indexterm>
  68 <indexterm><primary>SID</primary></indexterm>
  69 <indexterm><primary>UID</primary></indexterm>
  70 <indexterm><primary>GID</primary></indexterm>
  71 <indexterm><primary>one domain</primary></indexterm>
  72 The use of IDMAP is important where the Samba server will be accessed by workstations or servers from
  73 more than one domain, in which case it is important to run winbind so it can handle the resolution (ID mapping)
  74 of foreign SIDs to local UNIX UIDs and GIDs.
  75 </para>
  76
  77 <para>
  78 <indexterm><primary>winbindd</primary></indexterm>
  79 The use of the IDMAP facility requires the execution of the <command>winbindd</command> upon Samba startup.
  80 </para>
  81
  82 <sect1>
  83 <title>Samba Server Deployment Types and IDMAP</title>
  84
  85 <para>
  86 <indexterm><primary>Server Types</primary></indexterm>
  87 There are four basic server deployment types, as documented in <link linkend="ServerType">the chapter
  88 on Server Types and Security Modes</link>.
  89 </para>
  90
  91         <sect2>
  92         <title>Standalone Samba Server</title>
  93
  94         <para>
  95         <indexterm><primary>stand-alone server</primary></indexterm>
  96         <indexterm><primary>Active Directory</primary></indexterm>
  97         <indexterm><primary>NT4 Domain</primary></indexterm>
  98         A standalone Samba server is an implementation that is not a member of a Windows NT4 domain,
  99         a Windows 200X Active Directory domain, or a Samba domain.
 100         </para>
 101
 102         <para>
 103         <indexterm><primary>IDMAP</primary></indexterm>
 104         <indexterm><primary>identity</primary></indexterm>
 105         <indexterm><primary>local user</primary></indexterm>
 106         By definition, this means that users and groups will be created and controlled locally, and
 107         the identity of a network user must match a local UNIX/Linux user login. The IDMAP facility
 108         is therefore of little to no interest, winbind will not be necessary, and the IDMAP facility
 109         will not be relevant or of interest.
 110         </para>
 111
 112         </sect2>
 113
 114         <sect2>
 115         <title>Domain Member Server or Domain Member Client</title>
 116
 117         <para>
 118         <indexterm><primary>PDC</primary></indexterm>
 119         <indexterm><primary>BDC</primary></indexterm>
 120         <indexterm><primary>NT4</primary></indexterm>
 121         <indexterm><primary>SID</primary></indexterm>
 122         <indexterm><primary>Active Directory</primary></indexterm>
 123         Samba-3 can act as a Windows NT4 PDC or BDC, thereby providing domain control protocols that
 124         are compatible with Windows NT4. Samba-3 file and print sharing protocols are compatible with
 125         all versions of MS Windows products. Windows NT4, as with MS Active Directory,
 126         extensively makes use of Windows SIDs.
 127         </para>
 128
 129         <para>
 130         <indexterm><primary>MS Windows SID</primary></indexterm>
 131         <indexterm><primary>UID</primary></indexterm>
 132         <indexterm><primary>GID</primary></indexterm>
 133         Samba-3 domain member servers and clients must interact correctly with MS Windows SIDs. Incoming
 134         Windows SIDs must be translated to local UNIX UIDs and GIDs. Outgoing information from the Samba
 135         server must provide to MS Windows clients and servers appropriate SIDs.
 136         </para>
 137
 138         <para>
 139         <indexterm><primary>ADS</primary></indexterm>
 140         <indexterm><primary>winbind</primary></indexterm>
 141         A Samba member of a Windows networking domain (NT4-style or ADS) can be configured to handle
 142         identity mapping in a variety of ways. The mechanism it uses depends on whether or not
 143         the <command>winbindd</command> daemon is used and how the winbind functionality is configured.
 144         The configuration options are briefly described here:
 145         </para>
 146
 147         <variablelist>
 148                 <varlistentry><term>Winbind is not used; users and groups are local: </term>
 149                         <listitem>
 150                                 <para>
 151                                 <indexterm><primary>winbindd</primary></indexterm>
 152                                 <indexterm><primary>smbd</primary></indexterm>
 153                                 <indexterm><primary>network traffic</primary></indexterm>
 154                                 <indexterm><primary>LoginID</primary></indexterm>
 155                                 <indexterm><primary>account name</primary></indexterm>
 156                                 <indexterm><primary>getpwnam</primary></indexterm>
 157                                 <indexterm><primary>NSS</primary></indexterm>
 158                                 <indexterm><primary>local users</primary></indexterm>
 159                                 <indexterm><primary>local groups</primary></indexterm>
 160                                 <indexterm><primary>/etc/passwd</primary></indexterm>
 161                                 <indexterm><primary>/etc/group</primary></indexterm>
 162                                 Where <command>winbindd</command> is not used Samba (<command>smbd</command>)
 163                                 uses the underlying UNIX/Linux mechanisms to resolve the identity of incoming
 164                                 network traffic. This is done using the LoginID (account name) in the
 165                                 session setup request and passing it to the getpwnam() system function call.
 166                                 This call is implemented using the name service switch (NSS) mechanism on
 167                                 modern UNIX/Linux systems. By saying "users and groups are local,"
 168                                 we are implying that they are stored only on the local system, in the
 169                                 <filename>/etc/passwd</filename> and <filename>/etc/group</filename> respectively.
 170                                 </para>
 171
 172                                 <para>
 173                                 <indexterm><primary>SessionSetupAndX</primary></indexterm>
 174                                 <indexterm><primary>/etc/passwd</primary></indexterm>
 175                                 For example, when the user <literal>BERYLIUM\WambatW</literal> tries to open a
 176                                 connection to a Samba server the incoming SessionSetupAndX request will make a
 177                                 system call to look up the user <literal>WambatW</literal> in the
 178                                 <filename>/etc/passwd</filename> file.
 179                                 </para>
 180
 181                                 <para>
 182                                 <indexterm><primary>standalone</primary></indexterm>
 183                                 <indexterm><primary>domain member server</primary></indexterm>
 184                                 <indexterm><primary>NT4</primary></indexterm>
 185                                 <indexterm><primary>ADS</primary></indexterm>
 186                                 <indexterm><primary>PDC</primary></indexterm>
 187                                 <indexterm><primary>smbpasswd</primary></indexterm>
 188                                 <indexterm><primary>tdbsam</primary></indexterm>
 189                                 <indexterm><primary>passdb backend</primary></indexterm>
 190                                 This configuration may be used with standalone Samba servers, domain member
 191                                 servers (NT4 or ADS), and for a PDC that uses either an smbpasswd
 192                                 or a tdbsam-based Samba passdb backend.
 193                                 </para>
 194                         </listitem>
 195                 </varlistentry>
 196
 197                 <varlistentry><term>Winbind is not used; users and groups resolved via NSS: </term>
 198                         <listitem>
 199                                 <para>
 200                                 <indexterm><primary>user accounts</primary></indexterm>
 201                                 <indexterm><primary>group accounts</primary></indexterm>
 202                                 <indexterm><primary>local accounts</primary></indexterm>
 203                                 <indexterm><primary>repository</primary></indexterm>
 204                                 <indexterm><primary>NIS</primary></indexterm>
 205                                 <indexterm><primary>LDAP</primary></indexterm>
 206                                 In this situation user and group accounts are treated as if they are local
 207                                 accounts. The only way in which this differs from having local accounts is
 208                                 that the accounts are stored in a repository that can be shared. In practice
 209                                 this means that they will reside in either an NIS-type database or else in LDAP.
 210                                 </para>
 211
 212                                 <para>
 213                                 <indexterm><primary>standalone</primary></indexterm>
 214                                 <indexterm><primary>domain member server</primary></indexterm>
 215                                 <indexterm><primary>NT4</primary></indexterm>
 216                                 <indexterm><primary>ADS</primary></indexterm>
 217                                 <indexterm><primary>PDC</primary></indexterm>
 218                                 <indexterm><primary>smbpasswd</primary></indexterm>
 219                                 <indexterm><primary>tdbsam</primary></indexterm>
 220                                 This configuration may be used with standalone Samba servers, domain member
 221                                 servers (NT4 or ADS), and for a PDC that uses either an smbpasswd
 222                                 or a tdbsam-based Samba passdb backend.
 223                                 </para>
 224                         </listitem>
 225                 </varlistentry>
 226
 227                 <varlistentry><term>Winbind/NSS with the default local IDMAP table: </term>
 228                         <listitem>
 229                                 <para>
 230                                 <indexterm><primary>NT4 domain</primary></indexterm>
 231                                 <indexterm><primary>ADS domain</primary></indexterm>
 232                                 <indexterm><primary>winbind</primary></indexterm>
 233                                 <indexterm><primary>domain control</primary></indexterm>
 234                                 There are many sites that require only a simple Samba server or a single Samba
 235                                 server that is a member of a Windows NT4 domain or an ADS domain. A typical example
 236                                 is an appliance like file server on which no local accounts are configured and
 237                                 winbind is used to obtain account credentials from the domain controllers for the
 238                                 domain. The domain control can be provided by Samba-3, MS Windows NT4, or MS Windows
 239                                 Active Directory.
 240                                 </para>
 241
 242                                 <para>
 243                                 <indexterm><primary>UID numbers</primary></indexterm>
 244                                 <indexterm><primary>GID numbers</primary></indexterm>
 245                                 <indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
 246                                 <indexterm><primary>winbind</primary></indexterm>
 247                                 <indexterm><primary>SID</primary></indexterm>
 248                                 Winbind is a great convenience in this situation. All that is needed is a range of
 249                                 UID numbers and GID numbers that can be defined in the &smb.conf; file. The
 250                                 <filename>/etc/nsswitch.conf</filename> file is configured to use <command>winbind</command>,
 251                                 which does all the difficult work of mapping incoming SIDs to appropriate UIDs and GIDs.
 252                                 The SIDs are allocated a UID/GID in the order in which winbind receives them.
 253                                 </para>
 254
 255                                 <para>
 256                                 <indexterm><primary>UID</primary></indexterm>
 257                                 <indexterm><primary>GID</primary></indexterm>
 258                                 <indexterm><primary>IDMAP</primary></indexterm>
 259                                 <indexterm><primary>corrupted file</primary></indexterm>
 260                                 This configuration is not convenient or practical in sites that have more than one
 261                                 Samba server and that require the same UID or GID for the same user or group across
 262                                 all servers. One of the hazards of this method is that in the event that the winbind
 263                                 IDMAP file becomes corrupted or lost, the repaired or rebuilt IDMAP file may allocate
 264                                 UIDs and GIDs to different users and groups from what was there previously with the
 265                                 result that MS Windows files that are stored on the Samba server may now not belong to
 266                                 the rightful owners.
 267                                 </para>
 268                         </listitem>
 269                 </varlistentry>
 270
 271                 <varlistentry><term>Winbind/NSS uses RID based IDMAP: </term>
 272                         <listitem>
 273                                 <para>
 274                                 <indexterm><primary>RID</primary></indexterm>
 275                                 <indexterm><primary>idmap_rid</primary></indexterm>
 276                                 <indexterm><primary>ADS</primary></indexterm>
 277                                 <indexterm><primary>LDAP</primary></indexterm>
 278                                 The IDMAP_RID facility is new to Samba version 3.0.8. It was added to make life easier
 279                                 for a number of sites that are committed to use of MS ADS, that do not apply
 280                                 an ADS schema extension, and that do not have an installed an LDAP directory server just for
 281                                 the purpose of maintaining an IDMAP table. If you have a single ADS domain (not a forest of
 282                                 domains, and not multiple domain trees) and you want a simple cookie-cutter solution to the
 283                                 IDMAP table problem, then IDMAP_RID is an obvious choice.
 284                                 </para>
 285
 286                                 <para>
 287                                 <indexterm><primary>idmap_rid</primary></indexterm>
 288                                 <indexterm><primary>idmap uid</primary></indexterm>
 289                                 <indexterm><primary>idmap gid</primary></indexterm>
 290                                 <indexterm><primary>RID</primary></indexterm>
 291                                 <indexterm><primary>SID</primary></indexterm>
 292                                 <indexterm><primary>UID</primary></indexterm>
 293                                 <indexterm><primary>idmap backend</primary></indexterm>
 294                                 <indexterm><primary>automatic mapping</primary></indexterm>
 295                                 This facility requires the allocation of the <parameter>idmap uid</parameter> and the
 296                                 <parameter>idmap gid</parameter> ranges, and within the <parameter>idmap uid</parameter>
 297                                 it is possible to allocate a subset of this range for automatic mapping of the relative
 298                                 identifier (RID) portion of the SID directly to the base of the UID plus the RID value.
 299                                 For example, if the <parameter>idmap uid</parameter> range is <constant>1000-100000000</constant>
 300                                 and the <parameter>idmap backend = idmap_rid:DOMAIN_NAME=1000-50000000</parameter>, and
 301                                 a SID is encountered that has the value <constant>S-1-5-21-34567898-12529001-32973135-1234</constant>,
 302                                 the resulting UID will be <constant>1000 + 1234 = 2234</constant>.
 303                                 </para>
 304                         </listitem>
 305                 </varlistentry>
 306
 307                 <varlistentry><term>Winbind with an NSS/LDAP backend-based IDMAP facility: </term>
 308                         <listitem>
 309                                 <para>
 310                                 <indexterm><primary>Domain Member</primary></indexterm>
 311                                 <indexterm><primary>winbind</primary></indexterm>
 312                                 <indexterm><primary>SID</primary></indexterm>
 313                                 <indexterm><primary>UID</primary></indexterm>
 314                                 <indexterm><primary>GID</primary></indexterm>
 315                                 <indexterm><primary>idmap gid</primary></indexterm>
 316                                 <indexterm><primary>idmap uid</primary></indexterm>
 317                                 <indexterm><primary>LDAP</primary></indexterm>
 318                                 In this configuration <command>winbind</command> resolved SIDs to UIDs and GIDs from
 319                                 the <parameter>idmap uid</parameter> and <parameter>idmap gid</parameter> ranges specified
 320                                 in the &smb.conf; file, but instead of using a local winbind IDMAP table, it is stored
 321                                 in an LDAP directory so that all domain member machines (clients and servers) can share
 322                                 a common IDMAP table.
 323                                 </para>
 324
 325                                 <para>
 326                                 <indexterm><primary>idmap backend</primary></indexterm>
 327                                 <indexterm><primary>LDAP server</primary></indexterm>
 328                                 <indexterm><primary>LDAP redirects</primary></indexterm>
 329                                 It is important that all LDAP IDMAP clients use only the master LDAP server because the
 330                                 <parameter>idmap backend</parameter> facility in the &smb.conf; file does not correctly
 331                                 handle LDAP redirects.
 332                                 </para>
 333                         </listitem>
 334                 </varlistentry>
 335
 336                 <varlistentry><term>Winbind with NSS to resolve UNIX/Linux user and group IDs: </term>
 337                         <listitem>
 338                                 <para>
 339                                 The use of LDAP as the passdb backend is a smart solution for PDC, BDC, and
 340                                 domain member servers. It is a neat method for assuring that UIDs, GIDs, and the matching
 341                                 SIDs are consistent across all servers.
 342                                 </para>
 343
 344                                 <para>
 345                                 <indexterm><primary>LDAP</primary></indexterm>
 346                                 <indexterm><primary>PADL</primary></indexterm>
 347                                 The use of the LDAP-based passdb backend requires use of the PADL nss_ldap utility or
 348                                 an equivalent. In this situation winbind is used to handle foreign SIDs, that is, SIDs from
 349                                 standalone Windows clients (i.e., not a member of our domain) as well as SIDs from
 350                                 another domain. The foreign UID/GID is mapped from allocated ranges (idmap uid and idmap gid)
 351                                 in precisely the same manner as when using winbind with a local IDMAP table.
 352                                 </para>
 353
 354                                 <para>
 355                                 <indexterm><primary>nss_ldap</primary></indexterm>
 356                                 <indexterm><primary>AD4UNIX</primary></indexterm>
 357                                 <indexterm><primary>MMC</primary></indexterm>
 358                                 The nss_ldap tool set can be used to access UIDs and GIDs via LDAP as well as via Active
 359                                 Directory. In order to use Active Directory, it is necessary to modify the ADS schema by
 360                                 installing either the AD4UNIX schema extension or using the Microsoft Services for UNIX
 361                                 version 3.5 or later to extend the ADS schema so it maintains UNIX account credentials.
 362                                 Where the ADS schema is extended, a Microsoft Management Console (MMC) snap-in is also
 363                                 installed to permit the UNIX credentials to be set and managed from the ADS User and Computer
 364                                 Management tool. Each account must be separately UNIX-enabled before the UID and GID data can
 365                                 be used by Samba.
 366                                 </para>
 367                         </listitem>
 368                 </varlistentry>
 369
 370         </variablelist>
 371
 372         </sect2>
 373
 374         <sect2>
 375         <title>Primary Domain Controller</title>
 376
 377         <para>
 378         <indexterm><primary>domain security</primary></indexterm>
 379         <indexterm><primary>SID</primary></indexterm>
 380         <indexterm><primary>RID</primary></indexterm>
 381         <indexterm><primary>algorithmic mapping</primary></indexterm>
 382         Microsoft Windows domain security systems generate the user and group SID as part
 383         of the process of creation of an account. Windows does not have a concept of the UNIX UID or a GID; rather,
 384         it has its own type of security descriptor. When Samba is used as a domain controller, it provides a method
 385         of producing a unique SID for each user and group. Samba generates a machine and a domain SID to which it
 386         adds an RID that is calculated algorithmically from a base value that can be specified
 387         in the &smb.conf; file, plus twice (2x) the UID or GID. This method is called <quote>algorithmic mapping</quote>.
 388         </para>
 389
 390         <para>
 391         <indexterm><primary>RID base</primary></indexterm>
 392         For example, if a user has a UID of 4321, and the algorithmic RID base has a value of 1000, the RID will
 393         be <literal>1000 + (2 x 4321) = 9642</literal>. Thus, if the domain SID is
 394         <literal>S-1-5-21-89238497-92787123-12341112</literal>, the resulting SID is
 395         <literal>S-1-5-21-89238497-92787123-12341112-9642</literal>.
 396         </para>
 397
 398         <para>
 399         <indexterm><primary>on-the-fly</primary></indexterm>
 400         <indexterm><primary>SID</primary></indexterm>
 401         <indexterm><primary>passdb backend</primary></indexterm>
 402         <indexterm><primary>ldapsam</primary></indexterm>
 403         The foregoing type of SID is produced by Samba as an automatic function and is either produced on the fly
 404         (as is the case when using a <parameter>passdb backend = [tdbsam | smbpasswd]</parameter>), or may be stored
 405         as a permanent part of an account in an LDAP-based ldapsam.
 406         </para>
 407
 408         <para>
 409         <indexterm><primary>SFU 3.5</primary></indexterm>
 410         <indexterm><primary>ADS</primary></indexterm>
 411         <indexterm><primary>directory schema</primary></indexterm>
 412         <indexterm><primary>account attributes</primary></indexterm>
 413         <indexterm><primary>UID</primary></indexterm>
 414         <indexterm><primary>GID</primary></indexterm>
 415         <indexterm><primary>ADS schema</primary></indexterm>
 416         <indexterm><primary>account management</primary></indexterm>
 417         <indexterm><primary>MMC</primary></indexterm>
 418         ADS uses a directory schema that can be extended to accommodate additional
 419         account attributes such as UIDs and GIDs. The installation of Microsoft Service for UNIX 3.5 will expand
 420         the normal ADS schema to include UNIX account attributes. These must of course be managed separately
 421         through a snap-in module to the normal ADS account management MMC interface.
 422         </para>
 423
 424         <para>
 425         <indexterm><primary>PDC</primary></indexterm>
 426         <indexterm><primary>passdb backend</primary></indexterm>
 427         <indexterm><primary>BDC</primary></indexterm>
 428         <indexterm><primary>LDAP backend</primary></indexterm>
 429         Security identifiers used within a domain must be managed to avoid conflict and to preserve itegrity.
 430         In an NT4 domain context, the PDC manages the distribution of all security credentials to the backup
 431         domain controllers (BDCs). At this time the only passdb backend for a Samba domain controller that is suitable
 432         for such information is an LDAP backend.
 433         </para>
 434
 435         </sect2>
 436
 437         <sect2>
 438         <title>Backup Domain Controller</title>
 439
 440         <para>
 441         <indexterm><primary>BDC</primary></indexterm>
 442         <indexterm><primary>read-only access</primary></indexterm>
 443         <indexterm><primary>security credentials</primary></indexterm>
 444         <indexterm><primary>LDAP</primary></indexterm>
 445         <indexterm><primary>group account</primary></indexterm>
 446         <indexterm><primary>write changes</primary></indexterm>
 447         <indexterm><primary>directory</primary></indexterm>
 448         BDCs have read-only access to security credentials that are stored in LDAP.
 449         Changes in user or group account information are passed by the BDC to the PDC. Only the PDC can write
 450         changes to the directory.
 451         </para>
 452
 453         <para>
 454         IDMAP information can be written directly to the LDAP server so long as all domain controllers
 455         have access to the master (writable) LDAP server. Samba-3 at this time does not handle LDAP redirects
 456         in the IDMAP backend. This means that it is is unsafe to use a slave (replicate) LDAP server with
 457         the IDMAP facility.
 458         </para>
 459
 460         </sect2>
 461
 462 </sect1>
 463
 464 <sect1>
 465 <title>Examples of IDMAP Backend Usage</title>
 466
 467 <para>
 468 <indexterm><primary>Domain Member Server</primary><see>DMS</see></indexterm>
 469 <indexterm><primary>Domain Member Client</primary><see>DMC</see></indexterm>
 470 <indexterm><primary>DMS</primary></indexterm>
 471 <indexterm><primary>DMC</primary></indexterm>
 472 <indexterm><primary>winbind</primary></indexterm>
 473 Anyone who wishes to use <command>winbind</command> will find the following example configurations helpful.
 474 Remember that in the majority of cases <command>winbind</command> is of primary interest for use with
 475 domain member servers (DMSs) and domain member clients (DMCs).
 476 </para>
 477
 478         <sect2>
 479         <title>Default Winbind TDB</title>
 480
 481         <para>
 482         Two common configurations are used:
 483         </para>
 484
 485         <itemizedlist>
 486                 <listitem><para>
 487                 Networks that have an NT4 PDC (with or without BDCs) or a Samba PDC (with or without BDCs).
 488                 </para></listitem>
 489
 490                 <listitem><para>
 491                 Networks that use MS Windows 200x ADS.
 492                 </para></listitem>
 493         </itemizedlist>
 494
 495         <sect3>
 496         <title>NT4-Style Domains (Includes Samba Domains)</title>
 497
 498         <para>
 499         <link linkend="idmapnt4dms">NT4 Domain Member Server smb.con</link> is a simple example of an NT4 DMS
 500         &smb.conf; file that shows only the global section.
 501         </para>
 502
 503 <example id="idmapnt4dms">
 504 <title>NT4 Domain Member Server smb.conf</title>
 505 <smbconfblock>
 506 <smbconfcomment>Global parameters</smbconfcomment>
 507 <smbconfsection name="[global]"/>
 508 <smbconfoption name="workgroup">MEGANET2</smbconfoption>
 509 <smbconfoption name="security">DOMAIN</smbconfoption>
 510 <smbconfoption name="idmap uid">10000-20000</smbconfoption>
 511 <smbconfoption name="idmap gid">10000-20000</smbconfoption>
 512 <smbconfoption name="template primary group">"Domain Users"</smbconfoption>
 513 <smbconfoption name="template shell">/bin/bash</smbconfoption>
 514 </smbconfblock>
 515 </example>
 516
 517         <para>
 518         <indexterm><primary>winbind</primary></indexterm>
 519         <indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
 520         The use of <command>winbind</command> requires configuration of NSS. Edit the <filename>/etc/nsswitch.conf</filename>
 521         so it includes the following entries:
 522 <screen>
 523 ...
 524 passwd: files winbind
 525 shadow: files winbind
 526 group:  files winbind
 527 ...
 528 hosts:  files [dns] wins
 529 ...
 530 </screen>
 531         The use of DNS in the hosts entry should be made only if DNS is used on site.
 532         </para>
 533
 534         <para>
 535         The creation of the DMS requires the following steps:
 536         </para>
 537
 538         <procedure>
 539                 <step><para>
 540                 Create or install an &smb.conf; file with the above configuration.
 541                 </para></step>
 542
 543                 <step><para>
 544                 Execute:
 545 <screen>
 546 &rootprompt; net rpc join -UAdministrator%password
 547 Joined domain MEGANET2.
 548 </screen>
 549         <indexterm><primary>join</primary></indexterm>
 550         The success of the join can be confirmed with the following command:
 551 <screen>
 552 &rootprompt; net rpc testjoin
 553 Join to 'MIDEARTH' is OK
 554 </screen>
 555                 A failed join would report an error message like the following:
 556                 <indexterm><primary>failed join</primary></indexterm>
 557 <screen>
 558 &rootprompt; net rpc testjoin
 559 [2004/11/05 16:34:12, 0] utils/net_rpc_join.c:net_rpc_join_ok(66)
 560 Join to domain 'MEGANET2' is not valid
 561 </screen>
 562                 </para></step>
 563
 564                 <step><para>
 565                 <indexterm><primary>nmbd</primary></indexterm>
 566                 <indexterm><primary>winbind</primary></indexterm>
 567                 <indexterm><primary>smbd</primary></indexterm>
 568                 Start the <command>nmbd, winbind,</command> and <command>smbd</command> daemons in the order shown.
 569                 </para></step>
 570         </procedure>
 571
 572         </sect3>
 573
 574         <sect3>
 575         <title>ADS Domains</title>
 576
 577         <para>
 578         <indexterm><primary>domain join</primary></indexterm>
 579         <indexterm><primary>ADS domain</primary></indexterm>
 580         The procedure for joining an ADS domain is similar to the NT4 domain join, except the &smb.conf; file
 581         will have the contents shown in <link linkend="idmapadsdms">ADS Domain Member Server smb.conf</link>
 582         </para>
 583
 584 <example id="idmapadsdms">
 585 <title>ADS Domain Member Server smb.conf</title>
 586 <smbconfblock>
 587 <smbconfcomment>Global parameters</smbconfcomment>
 588 <smbconfsection name="[global]"/>
 589 <smbconfoption name="workgroup">BUTTERNET</smbconfoption>
 590 <smbconfoption name="netbios name">GARGOYLE</smbconfoption>
 591 <smbconfoption name="realm">BUTTERNET.BIZ</smbconfoption>
 592 <smbconfoption name="security">ADS</smbconfoption>
 593 <smbconfoption name="template shell">/bin/bash</smbconfoption>
 594 <smbconfoption name="idmap uid">500-10000000</smbconfoption>
 595 <smbconfoption name="idmap gid">500-10000000</smbconfoption>
 596 <smbconfoption name="winbind use default domain">Yes</smbconfoption>
 597 <smbconfoption name="winbind nested groups">Yes</smbconfoption>
 598 <smbconfoption name="printer admin">"BUTTERNET\Domain Admins"</smbconfoption>
 599 </smbconfblock>
 600 </example>
 601
 602         <para>
 603         <indexterm><primary>KRB</primary></indexterm>
 604         <indexterm><primary>kerberos</primary></indexterm>
 605         <indexterm><primary>/etc/krb5.conf</primary></indexterm>
 606         <indexterm><primary>MIT</primary></indexterm>
 607         <indexterm><primary>MIT kerberos</primary></indexterm>
 608         <indexterm><primary>Heimdal</primary></indexterm>
 609         <indexterm><primary>Heimdal kerberos</primary></indexterm>
 610         ADS DMS operation requires use of kerberos (KRB). For this to work, the <filename>krb5.conf</filename>
 611         must be configured. The exact requirements depends on which version of MIT or Heimdal Kerberos is being
 612         used. It is sound advice to use only the latest version, which at this time are MIT Kerberos version
 613         1.3.5 and Heimdal 0.61.
 614         </para>
 615
 616         <para>
 617         The creation of the DMS requires the following steps:
 618         </para>
 619
 620         <procedure>
 621                 <step><para>
 622                 Create or install an &smb.conf; file with the above configuration.
 623                 </para></step>
 624
 625                 <step><para>
 626                 Edit the <filename>/etc/nsswitch.conf</filename> file as shown above.
 627                 </para></step>
 628
 629                 <step><para>
 630                 Execute:
 631                 <indexterm><primary>net</primary><secondary>ads</secondary><tertiary>join</tertiary></indexterm>
 632 <screen>
 633 &rootprompt; net ads join -UAdministrator%password
 634 Joined domain BUTTERNET.
 635 </screen>
 636         The success or failure of the join can be confirmed with the following command:
 637 <screen>
 638 &rootprompt; net ads testjoin
 639 Using short domain name -- BUTTERNET
 640 Joined 'GARGOYLE' to realm 'BUTTERNET.BIZ'
 641 </screen>
 642         </para>
 643
 644         <para>
 645         An invalid or failed join can be detected by executing:
 646 <screen>
 647 &rootprompt; net ads testjoin
 648 GARGOYLE$@'s password:
 649 [2004/11/05 16:53:03, 0] utils/net_ads.c:ads_startup(186)
 650   ads_connect: No results returned
 651 Join to domain is not valid
 652 </screen>
 653                 <indexterm><primary>error message</primary></indexterm>
 654                 <indexterm><primary>failure</primary></indexterm>
 655                 <indexterm><primary>log level</primary></indexterm>
 656                 <indexterm><primary>identify</primary></indexterm>
 657                 The specific error message may differ from the above because it depends on the type of failure that
 658                 may have occurred. Increase the <parameter>log level</parameter> to 10, repeat the test,
 659                 and then examine the log files produced to identify the nature of the failure.
 660                 </para></step>
 661
 662                 <step><para>
 663                 Start the <command>nmbd</command>, <command>winbind</command>, and <command>smbd</command> daemons in the order shown.
 664                 </para></step>
 665
 666         </procedure>
 667
 668         </sect3>
 669         </sect2>
 670
 671         <sect2>
 672         <title>IDMAP_RID with Winbind</title>
 673
 674         <para>
 675         <indexterm><primary>idmap_rid</primary></indexterm>
 676         <indexterm><primary>SID</primary></indexterm>
 677         <indexterm><primary>RID</primary></indexterm>
 678         <indexterm><primary>IDMAP</primary></indexterm>
 679         The <command>idmap_rid</command> facility is a new tool that, unlike native winbind, creates a
 680         predictable mapping of MS Windows SIDs to UNIX UIDs and GIDs. The key benefit of this method
 681         of implementing the Samba IDMAP facility is that it eliminates the need to store the IDMAP data
 682         in a central place. The downside is that it can be used only within a single ADS domain and
 683         is not compatible with trusted domain implementations.
 684         </para>
 685
 686         <para>
 687         <indexterm><primary>SID</primary></indexterm>
 688         <indexterm><primary>allow trusted domains</primary></indexterm>
 689         <indexterm><primary>idmap uid</primary></indexterm>
 690         <indexterm><primary>idmap gid</primary></indexterm>
 691         This alternate method of SID to UID/GID  mapping can be achieved using the idmap_rid
 692         plug-in. This plug-in uses the RID of the user SID to derive the UID and GID by adding the
 693         RID to a base value specified. This utility requires that the parameter
 694         <quote>allow trusted domains = No</quote> be specified, as it is not compatible
 695         with multiple domain environments. The <parameter>idmap uid</parameter> and
 696         <parameter>idmap gid</parameter> ranges must be specified.
 697         </para>
 698
 699         <para>
 700         <indexterm><primary>idmap_rid</primary></indexterm>
 701         <indexterm><primary>realm</primary></indexterm>
 702         The idmap_rid facility can be used both for NT4/Samba-style domains and Active Directory.
 703         To use this with an NT4 domain, do not include the <parameter>realm</parameter> parameter; additionally, the
 704         method used to join the domain uses the <constant>net rpc join</constant> process.
 705         </para>
 706
 707         <para>
 708         An example &smb.conf; file for and ADS domain environment is shown in <link linkend="idmapadsridDMS">ADS
 709         Domain Member smb.conf using idmap_rid</link>.
 710         </para>
 711
 712 <example id="idmapadsridDMS">
 713 <title>ADS Domain Member smb.conf using idmap_rid</title>
 714 <smbconfblock>
 715 <smbconfcomment>Global parameters</smbconfcomment>
 716 <smbconfsection name="[global]"/>
 717 <smbconfoption name="workgroup">KPAK</smbconfoption>
 718 <smbconfoption name="netbios name">BIGJOE</smbconfoption>
 719 <smbconfoption name="realm">CORP.KPAK.COM</smbconfoption>
 720 <smbconfoption name="server string">Office Server</smbconfoption>
 721 <smbconfoption name="security">ADS</smbconfoption>
 722 <smbconfoption name="allow trusted domains">No</smbconfoption>
 723 <smbconfoption name="idmap backend">idmap_rid:KPAK=500-100000000</smbconfoption>
 724 <smbconfoption name="idmap uid">500-100000000</smbconfoption>
 725 <smbconfoption name="idmap gid">500-100000000</smbconfoption>
 726 <smbconfoption name="template shell">/bin/bash</smbconfoption>
 727 <smbconfoption name="winbind use default domain">Yes</smbconfoption>
 728 <smbconfoption name="winbind enum users">No</smbconfoption>
 729 <smbconfoption name="winbind enum groups">No</smbconfoption>
 730 <smbconfoption name="winbind nested groups">Yes</smbconfoption>
 731 <smbconfoption name="printer admin">"Domain Admins"</smbconfoption>
 732 </smbconfblock>
 733 </example>
 734
 735         <para>
 736         <indexterm><primary>large domain</primary></indexterm>
 737         <indexterm><primary>Active Directory</primary></indexterm>
 738         <indexterm><primary>response</primary></indexterm>
 739         <indexterm><primary>getent</primary></indexterm>
 740         In a large domain with many users it is imperative to disable enumeration of users and groups.
 741         For example, at a site that has 22,000 users in Active Directory the winbind-based user and
 742         group resolution is unavailable for nearly 12 minutes following first startup of
 743         <command>winbind</command>. Disabling enumeration resulted in instantaneous response.
 744         The disabling of user and group enumeration means that it will not be possible to list users
 745         or groups using the <command>getent passwd</command> and <command>getent group</command>
 746         commands. It will be possible to perform the lookup for individual users, as shown in the following procedure.
 747         </para>
 748
 749         <para>
 750         <indexterm><primary>NSS</primary></indexterm>
 751         <indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
 752         The use of this tool requires configuration of NSS as per the native use of winbind. Edit the
 753         <filename>/etc/nsswitch.conf</filename> so it has the following parameters:
 754 <screen>
 755 ...
 756 passwd: files winbind
 757 shadow: files winbind
 758 group:  files winbind
 759 ...
 760 hosts:  files wins
 761 ...
 762 </screen>
 763         </para>
 764
 765         <para>
 766         The following procedure can use the idmap_rid facility:
 767         </para>
 768
 769         <procedure>
 770                 <step><para>
 771                 Create or install an &smb.conf; file with the above configuration.
 772                 </para></step>
 773
 774                 <step><para>
 775                 Edit the <filename>/etc/nsswitch.conf</filename> file as shown above.
 776                 </para></step>
 777
 778                 <step><para>
 779                 Execute:
 780 <screen>
 781 &rootprompt; net ads join -UAdministrator%password
 782 Using short domain name -- KPAK
 783 Joined 'BIGJOE' to realm 'CORP.KPAK.COM'
 784 </screen>
 785                 </para>
 786
 787                 <para>
 788                 <indexterm><primary>failed join</primary></indexterm>
 789                 An invalid or failed join can be detected by executing:
 790 <screen>
 791 &rootprompt; net ads testjoin
 792 BIGJOE$@'s password:
 793 [2004/11/05 16:53:03, 0] utils/net_ads.c:ads_startup(186)
 794   ads_connect: No results returned
 795 Join to domain is not valid
 796 </screen>
 797                 The specific error message may differ from the above because it depends on the type of failure that
 798                 may have occurred. Increase the <parameter>log level</parameter> to 10, repeat the test,
 799                 and then examine the log files produced to identify the nature of the failure.
 800                 </para></step>
 801
 802                 <step><para>
 803                 Start the <command>nmbd</command>, <command>winbind</command>, and <command>smbd</command> daemons in the order shown.
 804                 </para></step>
 805
 806                 <step><para>
 807                 Validate the operation of this configuration by executing:
 808                 <indexterm><primary></primary></indexterm>
 809 <screen>
 810 &rootprompt; getent passwd administrator
 811 administrator:x:1000:1013:Administrator:/home/BE/administrator:/bin/bash
 812 </screen>
 813                 </para></step>
 814         </procedure>
 815
 816         </sect2>
 817
 818         <sect2>
 819         <title>IDMAP Storage in LDAP Using Winbind</title>
 820
 821         <para>
 822         <indexterm><primary>ADAM</primary></indexterm>
 823         <indexterm><primary>ADS</primary></indexterm>
 824         The storage of IDMAP information in LDAP can be used with both NT4/Samba-3-style domains and
 825         ADS domains. OpenLDAP is a commonly used LDAP server for this purpose, although any
 826         standards-complying LDAP server can be used. It is therefore possible to deploy this IDMAP
 827         configuration using the Sun iPlanet LDAP server, Novell eDirectory, Microsoft ADS plus ADAM,
 828         and so on.
 829         </para>
 830
 831         <para>
 832         An example is for an ADS domain is shown in <link linkend="idmapldapDMS">ADS Domain Member Server using
 833         LDAP</link>.
 834         </para>
 835
 836 <example id="idmapldapDMS">
 837 <title>ADS Domain Member Server using LDAP</title>
 838 <smbconfblock>
 839 <smbconfcomment>Global parameters</smbconfcomment>
 840 <smbconfsection name="[global]"/>
 841 <smbconfoption name="workgroup">SNOWSHOW</smbconfoption>
 842 <smbconfoption name="netbios name">GOODELF</smbconfoption>
 843 <smbconfoption name="realm">SNOWSHOW.COM</smbconfoption>
 844 <smbconfoption name="server string">Samba Server</smbconfoption>
 845 <smbconfoption name="security">ADS</smbconfoption>
 846 <smbconfoption name="log level">1 ads:10 auth:10 sam:10 rpc:10</smbconfoption>
 847 <smbconfoption name="ldap admin dn">cn=Manager,dc=SNOWSHOW,dc=COM</smbconfoption>
 848 <smbconfoption name="ldap idmap suffix">ou=Idmap</smbconfoption>
 849 <smbconfoption name="ldap suffix">dc=SNOWSHOW,dc=COM</smbconfoption>
 850 <smbconfoption name="idmap backend">ldap:ldap://ldap.snowshow.com</smbconfoption>
 851 <smbconfoption name="idmap uid">150000-550000</smbconfoption>
 852 <smbconfoption name="idmap gid">150000-550000</smbconfoption>
 853 <smbconfoption name="template shell">/bin/bash</smbconfoption>
 854 <smbconfoption name="winbind use default domain">Yes</smbconfoption>
 855 </smbconfblock>
 856 </example>
 857
 858         <para>
 859         <indexterm><primary>realm</primary></indexterm>
 860         In the case of an NT4 or Samba-3-style domain the <parameter>realm</parameter> is not used, and the
 861         command used to join the domain is <command>net rpc join</command>. The above example also demonstrates
 862         advanced error-reporting techniques that are documented in <link linkend="dbglvl">Reporting Bugs</link>.
 863         </para>
 864
 865         <para>
 866         <indexterm><primary>MIT kerberos</primary></indexterm>
 867         <indexterm><primary>Heimdal kerberos</primary></indexterm>
 868         <indexterm><primary>/etc/krb5.conf</primary></indexterm>
 869         Where MIT kerberos is installed (version 1.3.4 or later), edit the <filename>/etc/krb5.conf</filename>
 870         file so it has the following contents:
 871 <screen>
 872 [logging]
 873  default = FILE:/var/log/krb5libs.log
 874  kdc = FILE:/var/log/krb5kdc.log
 875  admin_server = FILE:/var/log/kadmind.log
 876
 877 [libdefaults]
 878  default_realm = SNOWSHOW.COM
 879  dns_lookup_realm = false
 880  dns_lookup_kdc = true
 881
 882 [appdefaults]
 883  pam = {
 884    debug = false
 885    ticket_lifetime = 36000
 886    renew_lifetime = 36000
 887    forwardable = true
 888    krb4_convert = false
 889  }
 890 </screen>
 891         </para>
 892
 893         <para>
 894         Where Heimdal kerberos is installed, edit the <filename>/etc/krb5.conf</filename>
 895         file so it is either empty (i.e., no contents) or it has the following contents:
 896 <screen>
 897 [libdefaults]
 898         default_realm = SNOWSHOW.COM
 899         clockskew = 300
 900
 901 [realms]
 902         SNOWSHOW.COM = {
 903                 kdc = ADSDC.SHOWSHOW.COM
 904         }
 905
 906 [domain_realm]
 907         .snowshow.com = SNOWSHOW.COM
 908 </screen>
 909         </para>
 910
 911         <note><para>
 912         Samba cannot use the Heimdal libraries if there is no <filename>/etc/krb5.conf</filename> file.
 913         So long as there is an empty file, the Heimdal kerberos libraries will be usable. There is no
 914         need to specify any settings because Samba, using the Heimdal libraries, can figure this out automatically.
 915         </para></note>
 916
 917         <para>
 918         Edit the NSS control file <filename>/etc/nsswitch.conf</filename> so it has the following entries:
 919 <screen>
 920 ...
 921 passwd: files ldap
 922 shadow: files ldap
 923 group:  files ldap
 924 ...
 925 hosts:  files wins
 926 ...
 927 </screen>
 928         </para>
 929
 930         <para>
 931         <indexterm><primary>PADL</primary></indexterm>
 932         <indexterm><primary>/etc/ldap.conf</primary></indexterm>
 933         You will need the <ulink url="http://www.padl.com">PADL</ulink> <command>nss_ldap</command>
 934         tool set for this solution. Configure the <filename>/etc/ldap.conf</filename> file so it has
 935         the information needed. The following is an example of a working file:
 936 <screen>
 937 host    192.168.2.1
 938 base    dc=snowshow,dc=com
 939 binddn  cn=Manager,dc=snowshow,dc=com
 940 bindpw  not24get
 941
 942 pam_password exop
 943
 944 nss_base_passwd ou=People,dc=snowshow,dc=com?one
 945 nss_base_shadow ou=People,dc=snowshow,dc=com?one
 946 nss_base_group  ou=Groups,dc=snowshow,dc=com?one
 947 ssl     no
 948 </screen>
 949         </para>
 950
 951         <para>
 952         The following procedure may be followed to effect a working configuration:
 953         </para>
 954
 955         <procedure>
 956                 <step><para>
 957                 Configure the &smb.conf; file as shown above.
 958                 </para></step>
 959
 960                 <step><para>
 961                 Create the <filename>/etc/krb5.conf</filename> file as shown above.
 962                 </para></step>
 963
 964                 <step><para>
 965                 Configure the <filename>/etc/nsswitch.conf</filename> file as shown above.
 966                 </para></step>
 967
 968                 <step><para>
 969                 Download, build, and install the PADL nss_ldap tool set. Configure the
 970                 <filename>/etc/ldap.conf</filename> file as shown above.
 971                 </para></step>
 972
 973                 <step><para>
 974                 Configure an LDAP server and initialize the directory with the top-level entries needed by IDMAP,
 975                 shown in the following LDIF file:
 976 <screen>
 977 dn: dc=snowshow,dc=com
 978 objectClass: dcObject
 979 objectClass: organization
 980 dc: snowshow
 981 o: The Greatest Snow Show in Singapore.
 982 description: Posix and Samba LDAP Identity Database
 983
 984 dn: cn=Manager,dc=snowshow,dc=com
 985 objectClass: organizationalRole
 986 cn: Manager
 987 description: Directory Manager
 988
 989 dn: ou=Idmap,dc=snowshow,dc=com
 990 objectClass: organizationalUnit
 991 ou: idmap
 992 </screen>
 993                 </para></step>
 994
 995                 <step><para>
 996                 Execute the command to join the Samba DMS to the ADS domain as shown here:
 997 <screen>
 998 &rootprompt; net ads testjoin
 999 Using short domain name -- SNOWSHOW
1000 Joined 'GOODELF' to realm 'SNOWSHOW.COM'
1001 </screen>
1002                 </para></step>
1003
1004                 <step><para>
1005                 Store the LDAP server access password in the Samba <filename>secrets.tdb</filename> file as follows:
1006 <screen>
1007 &rootprompt; smbpasswd -w not24get
1008 </screen>
1009                 </para></step>
1010
1011                 <step><para>
1012                 Start the <command>nmbd</command>, <command>winbind</command>, and <command>smbd</command> daemons in the order shown.
1013                 </para></step>
1014         </procedure>
1015
1016         <para>
1017         <indexterm><primary>diagnostic</primary></indexterm>
1018         Follow the diagnositic procedures shown earlier in this chapter to identify success or failure of the join.
1019         In many cases a failure is indicated by a silent return to the command prompt with no indication of the
1020         reason for failure.
1021         </para>
1022
1023         </sect2>
1024
1025         <sect2>
1026         <title>IDMAP and NSS Using LDAP from ADS with RFC2307bis Schema Extension</title>
1027
1028         <para>
1029         <indexterm><primary>rfc2307bis</primary></indexterm>
1030         <indexterm><primary>schema</primary></indexterm>
1031         The use of this method is messy. The information provided in the following is for guidance only
1032         and is very definitely not complete. This method does work; it is used in a number of large sites
1033         and has an acceptable level of performance.
1034         </para>
1035
1036         <para>
1037         An example &smb.conf; file is shown in <link linkend="idmaprfc2307">ADS Domain Member Server using
1038 RFC2307bis Schema Extension Date via NSS</link>.
1039         </para>
1040
1041 <example id="idmaprfc2307">
1042 <title>ADS Domain Member Server using RFC2307bis Schema Extension Date via NSS</title>
1043 <smbconfblock>
1044 <smbconfcomment>Global parameters</smbconfcomment>
1045 <smbconfsection name="[global]"/>
1046 <smbconfoption name="workgroup">BOBBY</smbconfoption>
1047 <smbconfoption name="realm">BOBBY.COM</smbconfoption>
1048 <smbconfoption name="security">ADS</smbconfoption>
1049 <smbconfoption name="idmap uid">150000-550000</smbconfoption>
1050 <smbconfoption name="idmap gid">150000-550000</smbconfoption>
1051 <smbconfoption name="template shell">/bin/bash</smbconfoption>
1052 <smbconfoption name="winbind cache time">5</smbconfoption>
1053 <smbconfoption name="winbind use default domain">Yes</smbconfoption>
1054 <smbconfoption name="winbind trusted domains only">Yes</smbconfoption>
1055 <smbconfoption name="winbind nested groups">Yes</smbconfoption>
1056 </smbconfblock>
1057 </example>
1058
1059         <para>
1060         <indexterm><primary>nss_ldap</primary></indexterm>
1061         The DMS must be joined to the domain using the usual procedure. Additionally, it is necessary
1062         to build and install the PADL nss_ldap tool set. Be sure to build this tool set with the
1063         following:
1064 <screen>
1065 ./configure --enable-rfc2307bis --enable-schema-mapping
1066 make install
1067 </screen>
1068         </para>
1069
1070         <para>
1071         <indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
1072         The following <filename>/etc/nsswitch.conf</filename> file contents are required:
1073 <screen>
1074 ...
1075 passwd: files ldap
1076 shadow: files ldap
1077 group:  files ldap
1078 ...
1079 hosts:  files wins
1080 ...
1081 </screen>
1082         </para>
1083
1084         <para>
1085         <indexterm><primary>/etc/ldap.conf</primary></indexterm>
1086         <indexterm><primary>nss_ldap</primary></indexterm>
1087         The <filename>/etc/ldap.conf</filename> file must be configured also. Refer to the PADL documentation
1088         and source code for nss_ldap to specific instructions.
1089         </para>
1090
1091         <para>
1092         The next step involves preparation of the ADS schema. This is briefly discussed in the remaining
1093         part of this chapter.
1094         </para>
1095
1096                 <sect3>
1097                 <title>IDMAP, Active Directory, and MS Services for UNIX 3.5</title>
1098
1099                 <para>
1100                 <indexterm><primary>SFU</primary></indexterm>
1101                 The Microsoft Windows Service for UNIX (SFU) version 3.5 is available for free
1102                 <ulink url="http://www.microsoft.com/windows/sfu/">download</ulink>
1103                 from the Microsoft Web site. You will need to download this tool and install it following
1104                 Microsoft instructions.
1105                 </para>
1106
1107                 </sect3>
1108
1109                 <sect3>
1110                 <title>IDMAP, Active Directory and AD4UNIX</title>
1111
1112                 <para>
1113                 Instructions for obtaining and installing the AD4UNIX tool set can be found from the
1114                 <ulink url="http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?LDAP01/An_Alternative_Approach">
1115                 Geekcomix</ulink> Web site.
1116                 </para>
1117
1118                 </sect3>
1119
1120         </sect2>
1121
1122 </sect1>
1123
1124 </chapter>