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">
8 <title>Identity Mapping (IDMAP)</title>
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.
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.
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!
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.
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.
78 <indexterm><primary>winbindd</primary></indexterm>
79 The use of the IDMAP facility requires the execution of the <command>winbindd</command> upon Samba startup.
83 <title>Samba Server Deployment Types and IDMAP</title>
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>.
92 <title>Standalone Samba Server</title>
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.
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.
115 <title>Domain Member Server or Domain Member Client</title>
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.
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.
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:
148 <varlistentry><term>Winbind is not used; users and groups are local: </term>
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.
173 <indexterm><primary>SessionSetupAndX</primary></indexterm>
174 <indexterm><primary>/etc/passwd</primary></indexterm>
175 For example, if an incoming SessionSetupAndX request is owned by the user
176 <constant>BERYLIUM\WambatW</constant>, a system call will be made to look up
177 the user <constant>WambatW</constant> in the <filename>/etc/passwd</filename>
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.
197 <varlistentry><term>Winbind is not used; users and groups resolved via NSS: </term>
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.
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.
227 <varlistentry><term>Winbind/NSS with the default local IDMAP table: </term>
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
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.
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
271 <varlistentry><term>Winbind/NSS uses RID based IDMAP: </term>
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.
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>.
307 <varlistentry><term>Winbind with an NSS/LDAP backend-based IDMAP facility: </term>
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.
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.
336 <varlistentry><term>Winbind with NSS to resolve UNIX/Linux user and group IDs: </term>
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.
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.
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
375 <title>Primary Domain Controller</title>
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>.
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 <constant>1000 + (2 x 4321) = 9642</constant>. Thus, if the domain SID is
394 <constant>S-1-5-21-89238497-92787123-12341112</constant>, the resulting SID is
395 <constant>S-1-5-21-89238497-92787123-12341112-9642</constant>.
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.
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.
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.
438 <title>Backup Domain Controller</title>
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.
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
465 <title>Examples of IDMAP Backend Usage</title>
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).
479 <title>Default Winbind TDB</title>
482 Two common configurations are used:
487 Networks that have an NT4 PDC (with or without BDCs) or a Samba PDC (with or without BDCs).
491 Networks that use MS Windows 200x ADS.
496 <title>NT4-Style Domains (Includes Samba Domains)</title>
499 The following is a simple example of an NT4 DMS &smb.conf; file that shows only the global section.
505 idmap uid = 10000-20000
506 idmap gid = 10000-20000
507 template primary group = "Domain Users"
508 template shell = /bin/bash
513 <indexterm><primary>winbind</primary></indexterm>
514 <indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
515 The use of <command>winbind</command> requires configuration of NSS. Edit the <filename>/etc/nsswitch.conf</filename>
516 so it includes the following entries:
519 passwd: files winbind
520 shadow: files winbind
523 hosts: files [dns] wins
526 The use of DNS in the hosts entry should be made only if DNS is used on site.
530 The creation of the DMS requires the following steps:
535 Create or install an &smb.conf; file with the above configuration.
541 &rootprompt; net rpc join -UAdministrator%password
542 Joined domain MEGANET2.
544 <indexterm><primary>join</primary></indexterm>
545 The success of the join can be confirmed with the following command:
547 &rootprompt; net rpc testjoin
548 Join to 'MIDEARTH' is OK
550 A failed join would report an error message like the following:
551 <indexterm><primary>failed join</primary></indexterm>
553 &rootprompt; net rpc testjoin
554 [2004/11/05 16:34:12, 0] utils/net_rpc_join.c:net_rpc_join_ok(66)
555 Join to domain 'MEGANET2' is not valid
560 <indexterm><primary>nmbd</primary></indexterm>
561 <indexterm><primary>winbind</primary></indexterm>
562 <indexterm><primary>smbd</primary></indexterm>
563 Start the <command>nmbd, winbind,</command> and <command>smbd</command> daemons in the order shown.
570 <title>ADS Domains</title>
573 <indexterm><primary>domain join</primary></indexterm>
574 <indexterm><primary>ADS domain</primary></indexterm>
575 The procedure for joining an ADS domain is similar to the NT4 domain join, except the &smb.conf; file
576 will have the following contents:
580 workgroup = BUTTERNET
581 netbios name = GARGOYLE
582 realm = BUTTERNET.BIZ
584 template shell = /bin/bash
585 idmap uid = 500-10000000
586 idmap gid = 500-10000000
587 winbind use default domain = Yes
588 winbind nested groups = Yes
589 printer admin = "BUTTERNET\Domain Admins"
594 <indexterm><primary>KRB</primary></indexterm>
595 <indexterm><primary>kerberos</primary></indexterm>
596 <indexterm><primary>/etc/krb5.conf</primary></indexterm>
597 <indexterm><primary>MIT</primary></indexterm>
598 <indexterm><primary>MIT kerberos</primary></indexterm>
599 <indexterm><primary>Heimdal</primary></indexterm>
600 <indexterm><primary>Heimdal kerberos</primary></indexterm>
601 ADS DMS operation requires use of kerberos (KRB). For this to work, the <filename>krb5.conf</filename>
602 must be configured. The exact requirements depends on which version of MIT or Heimdal Kerberos is being
603 used. It is sound advice to use only the latest version, which at this time are MIT Kerberos version
604 1.3.5 and Heimdal 0.61.
608 The creation of the DMS requires the following steps:
613 Create or install an &smb.conf; file with the above configuration.
617 Edit the <filename>/etc/nsswitch.conf</filename> file as shown above.
622 <indexterm><primary>net</primary><secondary>ads</secondary><tertiary>join</tertiary></indexterm>
624 &rootprompt; net ads join -UAdministrator%password
625 Joined domain BUTTERNET.
627 The success or failure of the join can be confirmed with the following command:
629 &rootprompt; net ads testjoin
630 Using short domain name -- BUTTERNET
631 Joined 'GARGOYLE' to realm 'BUTTERNET.BIZ'
636 An invalid or failed join can be detected by executing:
638 &rootprompt; net ads testjoin
639 GARGOYLE$@'s password:
640 [2004/11/05 16:53:03, 0] utils/net_ads.c:ads_startup(186)
641 ads_connect: No results returned
642 Join to domain is not valid
644 <indexterm><primary>error message</primary></indexterm>
645 <indexterm><primary>failure</primary></indexterm>
646 <indexterm><primary>log level</primary></indexterm>
647 <indexterm><primary>identify</primary></indexterm>
648 The specific error message may differ from the above because it depends on the type of failure that
649 may have occurred. Increase the <parameter>log level</parameter> to 10, repeat the test,
650 and then examine the log files produced to identify the nature of the failure.
654 Start the <command>nmbd</command>, <command>winbind</command>, and <command>smbd</command> daemons in the order shown.
663 <title>IDMAP_RID with Winbind</title>
666 <indexterm><primary>idmap_rid</primary></indexterm>
667 <indexterm><primary>SID</primary></indexterm>
668 <indexterm><primary>RID</primary></indexterm>
669 <indexterm><primary>IDMAP</primary></indexterm>
670 The <command>idmap_rid</command> facility is a new tool that, unlike native winbind, creates a
671 predictable mapping of MS Windows SIDs to UNIX UIDs and GIDs. The key benefit of this method
672 of implementing the Samba IDMAP facility is that it eliminates the need to store the IDMAP data
673 in a central place. The downside is that it can be used only within a single ADS domain and
674 is not compatible with trusted domain implementations.
678 <indexterm><primary>SID</primary></indexterm>
679 <indexterm><primary>allow trusted domains</primary></indexterm>
680 <indexterm><primary>idmap uid</primary></indexterm>
681 <indexterm><primary>idmap gid</primary></indexterm>
682 This alternate method of SID to UID/GID mapping can be achieved using the idmap_rid
683 plug-in. This plug-in uses the RID of the user SID to derive the UID and GID by adding the
684 RID to a base value specified. This utility requires that the parameter
685 <quote>allow trusted domains = No</quote> be specified, as it is not compatible
686 with multiple domain environments. The <parameter>idmap uid</parameter> and
687 <parameter>idmap gid</parameter> ranges must be specified.
691 <indexterm><primary>idmap_rid</primary></indexterm>
692 <indexterm><primary>realm</primary></indexterm>
693 The idmap_rid facility can be used both for NT4/Samba-style domains and Active Directory.
694 To use this with an NT4 domain, do not include the <parameter>realm</parameter> parameter; additionally, the
695 method used to join the domain uses the <constant>net rpc join</constant> process.
699 An example &smb.conf; file for and ADS domain environment is shown here:
704 netbios name = BIGJOE
705 realm = CORP.KPAK.COM
706 server string = Office Server
708 allow trusted domains = No
709 idmap backend = idmap_rid:KPAK=500-100000000
710 idmap uid = 500-100000000
711 idmap gid = 500-100000000
712 template shell = /bin/bash
713 winbind use default domain = Yes
714 winbind enum users = No
715 winbind enum groups = No
716 winbind nested groups = Yes
717 printer admin = "Domain Admins"
722 <indexterm><primary>large domain</primary></indexterm>
723 <indexterm><primary>Active Directory</primary></indexterm>
724 <indexterm><primary>response</primary></indexterm>
725 <indexterm><primary>getent</primary></indexterm>
726 In a large domain with many users it is imperative to disable enumeration of users and groups.
727 For example, at a site that has 22,000 users in Active Directory the winbind-based user and
728 group resolution is unavailable for nearly 12 minutes following first startup of
729 <command>winbind</command>. Disabling enumeration resulted in instantaneous response.
730 The disabling of user and group enumeration means that it will not be possible to list users
731 or groups using the <command>getent passwd</command> and <command>getent group</command>
732 commands. It will be possible to perform the lookup for individual users, as shown in the following procedure.
736 <indexterm><primary>NSS</primary></indexterm>
737 <indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
738 The use of this tool requires configuration of NSS as per the native use of winbind. Edit the
739 <filename>/etc/nsswitch.conf</filename> so it has the following parameters:
742 passwd: files winbind
743 shadow: files winbind
752 The following procedure can be uses the idmap_rid facility:
757 Create or install an &smb.conf; file with the above configuration.
761 Edit the <filename>/etc/nsswitch.conf</filename> file as shown above.
767 &rootprompt; net ads join -UAdministrator%password
768 Using short domain name -- KPAK
769 Joined 'BIGJOE' to realm 'CORP.KPAK.COM'
774 <indexterm><primary>failed join</primary></indexterm>
775 An invalid or failed join can be detected by executing:
777 &rootprompt; net ads testjoin
779 [2004/11/05 16:53:03, 0] utils/net_ads.c:ads_startup(186)
780 ads_connect: No results returned
781 Join to domain is not valid
783 The specific error message may differ from the above because it depends on the type of failure that
784 may have occurred. Increase the <parameter>log level</parameter> to 10, repeat the test,
785 and then examine the log files produced to identify the nature of the failure.
789 Start the <command>nmbd</command>, <command>winbind</command>, and <command>smbd</command> daemons in the order shown.
793 Validate the operation of this configuration by executing:
794 <indexterm><primary></primary></indexterm>
796 &rootprompt; getent passwd administrator
797 administrator:x:1000:1013:Administrator:/home/BE/administrator:/bin/bash
805 <title>IDMAP Storage in LDAP Using Winbind</title>
808 <indexterm><primary>ADAM</primary></indexterm>
809 <indexterm><primary>ADS</primary></indexterm>
810 The storage of IDMAP information in LDAP can be used with both NT4/Samba-3-style domains and
811 ADS domains. OpenLDAP is a commonly used LDAP server for this purpose, although any
812 standards-complying LDAP server can be used. It is therefore possible to deploy this IDMAP
813 configuration using the Sun iPlanet LDAP server, Novell eDirectory, Microsoft ADS plus ADAM,
818 The following example is for an ADS domain:
826 netbios name = GOODELF
828 server string = Samba Server
830 log level = 1 ads:10 auth:10 sam:10 rpc:10
831 ldap admin dn = cn=Manager,dc=SNOWSHOW,dc=COM
832 ldap idmap suffix = ou=Idmap
833 ldap suffix = dc=SNOWSHOW,dc=COM
834 idmap backend = ldap:ldap://ldap.snowshow.com
835 idmap uid = 150000-550000
836 idmap gid = 150000-550000
837 template shell = /bin/bash
838 winbind use default domain = Yes
843 <indexterm><primary>realm</primary></indexterm>
844 In the case of an NT4 or Samba-3-style domain the <parameter>realm</parameter> is not used, and the
845 command used to join the domain is <command>net rpc join</command>. The above example also demonstrates
846 advanced error-reporting techniques that are documented in <link linkend="dbglvl">Reporting Bugs</link>.
850 <indexterm><primary>MIT kerberos</primary></indexterm>
851 <indexterm><primary>Heimdal kerberos</primary></indexterm>
852 <indexterm><primary>/etc/krb5.conf</primary></indexterm>
853 Where MIT kerberos is installed (version 1.3.4 or later), edit the <filename>/etc/krb5.conf</filename>
854 file so it has the following contents:
857 default = FILE:/var/log/krb5libs.log
858 kdc = FILE:/var/log/krb5kdc.log
859 admin_server = FILE:/var/log/kadmind.log
862 default_realm = SNOWSHOW.COM
863 dns_lookup_realm = false
864 dns_lookup_kdc = true
869 ticket_lifetime = 36000
870 renew_lifetime = 36000
878 Where Heimdal kerberos is installed, edit the <filename>/etc/krb5.conf</filename>
879 file so it is either empty (i.e., no contents) or it has the following contents:
882 default_realm = SNOWSHOW.COM
887 kdc = ADSDC.SHOWSHOW.COM
891 .snowshow.com = SNOWSHOW.COM
896 Samba cannot use the Heimdal libraries if there is no <filename>/etc/krb5.conf</filename> file.
897 So long as there is an empty file, the Heimdal kerberos libraries will be usable. There is no
898 need to specify any settings because Samba, using the Heimdal libraries, can figure this out automatically.
902 Edit the NSS control file <filename>/etc/nsswitch.conf</filename> so it has the following entries:
915 <indexterm><primary>PADL</primary></indexterm>
916 <indexterm><primary>/etc/ldap.conf</primary></indexterm>
917 You will need the <ulink url="http://www.padl.com">PADL</ulink> <command>nss_ldap</command>
918 tool set for this solution. Configure the <filename>/etc/ldap.conf</filename> file so it has
919 the information needed. The following is an example of a working file:
922 base dc=snowshow,dc=com
923 binddn cn=Manager,dc=snowshow,dc=com
928 nss_base_passwd ou=People,dc=snowshow,dc=com?one
929 nss_base_shadow ou=People,dc=snowshow,dc=com?one
930 nss_base_group ou=Groups,dc=snowshow,dc=com?one
936 The following procedure may be followed to effect a working configuration:
941 Configure the &smb.conf; file as shown above.
945 Create the <filename>/etc/krb5.conf</filename> file as shown above.
949 Configure the <filename>/etc/nsswitch.conf</filename> file as shown above.
953 Download, build, and install the PADL nss_ldap tool set. Configure the
954 <filename>/etc/ldap.conf</filename> file as shown above.
958 Configure an LDAP server and initialize the directory with the top-level entries needed by IDMAP,
959 shown in the following LDIF file:
961 dn: dc=snowshow,dc=com
962 objectClass: dcObject
963 objectClass: organization
965 o: The Greatest Snow Show in Singapore.
966 description: Posix and Samba LDAP Identity Database
968 dn: cn=Manager,dc=snowshow,dc=com
969 objectClass: organizationalRole
971 description: Directory Manager
973 dn: ou=Idmap,dc=snowshow,dc=com
974 objectClass: organizationalUnit
980 Execute the command to join the Samba DMS to the ADS domain as shown here:
982 &rootprompt; net ads testjoin
983 Using short domain name -- SNOWSHOW
984 Joined 'GOODELF' to realm 'SNOWSHOW.COM'
989 Store the LDAP server access password in the Samba <filename>secrets.tdb</filename> file as follows:
991 &rootprompt; smbpasswd -w not24get
996 Start the <command>nmbd</command>, <command>winbind</command>, and <command>smbd</command> daemons in the order shown.
1001 <indexterm><primary>diagnostic</primary></indexterm>
1002 Follow the diagnositic procedures shown earlier in this chapter to identify success or failure of the join.
1003 In many cases a failure is indicated by a silent return to the command prompt with no indication of the
1010 <title>IDMAP and NSS Using LDAP from ADS with RFC2307bis Schema Extension</title>
1013 <indexterm><primary>rfc2307bis</primary></indexterm>
1014 <indexterm><primary>schema</primary></indexterm>
1015 The use of this method is messy. The information provided in the following is for guidance only
1016 and is very definitely not complete. This method does work; it is used in a number of large sites
1017 and has an acceptable level of performance.
1021 The following is an example &smb.conf; file:
1028 idmap uid = 150000-550000
1029 idmap gid = 150000-550000
1030 template shell = /bin/bash
1031 winbind cache time = 5
1032 winbind use default domain = Yes
1033 winbind trusted domains only = Yes
1034 winbind nested groups = Yes
1039 <indexterm><primary>nss_ldap</primary></indexterm>
1040 The DMS must be joined to the domain using the usual procedure. Additionally, it is necessary
1041 to build and install the PADL nss_ldap tool set. Be sure to build this tool set with the
1044 ./configure --enable-rfc2307bis --enable-schema-mapping
1050 <indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
1051 The following <filename>/etc/nsswitch.conf</filename> file contents are required:
1064 <indexterm><primary>/etc/ldap.conf</primary></indexterm>
1065 <indexterm><primary>nss_ldap</primary></indexterm>
1066 The <filename>/etc/ldap.conf</filename> file must be configured also. Refer to the PADL documentation
1067 and source code for nss_ldap to specific instructions.
1071 The next step involves preparation of the ADS schema. This is briefly discussed in the remaining
1072 part of this chapter.
1076 <title>IDMAP, Active Directory, and MS Services for UNIX 3.5</title>
1079 <indexterm><primary>SFU</primary></indexterm>
1080 The Microsoft Windows Service for UNIX (SFU) version 3.5 is available for free
1081 <ulink url="http://www.microsoft.com/windows/sfu/">download</ulink>
1082 from the Microsoft Web site. You will need to download this tool and install it following
1083 Microsoft instructions.
1089 <title>IDMAP, Active Directory and AD4UNIX</title>
1092 Instructions for obtaining and installing the AD4UNIX tool set can be found from the
1093 <ulink url="http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?LDAP01/An_Alternative_Approach">
1094 Geekcomix</ulink> Web site.