1 <?xml version="1.0" encoding="iso-8859-1"?>
2 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
3 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
5 <!-- entities files to use -->
6 <!ENTITY % global_entities SYSTEM '../entities/global.entities'>
11 <chapter id="idmapper">
16 <title>Identity Mapping (IDMAP)</title>
19 THIS IS A WORK IN PROGRESS - it is a preparation for the release of Samba-3.0.8.
23 The Microsoft Windows operating system has a number of features that impose specific challenges
24 to interoperability with operating system on which Samba is implemented. This chapter deals
25 explicitly with the mechanisms Samba-3 (version 3.0.8 and later) uses to overcome one of the
26 key challenges in the integration of Samba servers into an MS Windows networking environment.
27 This chapter deals with Identify Mapping (IDMAP) of Windows Security Identifers (SIDs)
28 to UNIX UIDs and GIDs.
32 To ensure good sufficient coverage each possible Samba deployment type will be discussed.
33 This is followed by an overview of how the IDMAP facility may be implemented.
37 The IDMAP facility is usually of concern where more than one Samba server (or Samba network client)
38 is installed in the one Domain. Where there is a single Samba server do not be too concerned regarding
39 the IDMAP infrastructure - the default behavior of Samba is nearly always sufficient.
43 The use of IDMAP is important where the Samba server will be accessed by workstations or servers from
44 more than one domain, in which case it is important to run winbind so it can handle the resolution (ID mapping)
45 of foreign SIDs to local UNIX UIDs and GIDs.
49 The use of the IDMAP facility requires that the <command>winbindd</command> be executed on Samba start-up.
53 <title>Samba Server Deployment Types</title>
56 There are four (4) basic server deployment types, as documented in <link linkend="ServerType">the chapter
57 on Server Types and Security Modes</link>.
61 <title>Stand-Alone Samba Server</title>
64 A stand-alone Samba server is an implementation that is not a member of a Windows NT4 Domain,
65 a Windows 200X Active Directory Domain, or of a Samba Domain.
69 By definition, this means that users and groups will be created and controlled locally and
70 the identity of a network user must match a local UNIX/Linux user login. The IDMAP facility
71 is therefore of little to no interest, winbind will not be necessary, and the IDMAP facility
72 will not be relevant or of interest.
78 <title>Domain Member Server or Domain Member Client</title>
81 Samba-3 can act as a Windows NT4 PDC or BDC thereby providing domain control protocols that
82 are compatible with Windows NT4. Samba-3 file and print sharing protocols are compatible with
83 all version of Microsoft Windows products. Windows NT4, as with Microsoft Active Directory, i
84 extensively makes use of Windows security identifiers (SIDs).
88 Samba-3 Domain Member servers and clients must interact correctly with MS Windows SIDs. Incoming
89 Windows SIDs must be translated to local UNIX UIDs and GIDs. Outgoing information from the Samba
90 server must provide to MS Windows clients and servers appropriate SIDs.
94 A Samba member of a Windows networking domain (NT4-style or ADS) can be configured to handle
95 identity mapping in a variety of ways. The mechanism is will use depends on whether or not
96 the <command>winbindd</command> daemon is used, and how the winbind functionality is configured.
97 The configuration options are briefly described here:
101 <varlistentry><term>Winbind is not used, users and groups are local: &smbmdash; </term>
104 Where <command>winbindd</command> is not used Samba (<command>smbd</command>)
105 uses the underlying UNIX/Linux mechanisms to resolve the identity of incoming
106 network traffic. This will be done using the LoginID (account name) in the
107 session setup request and passing it to the getpwnam() system function call.
108 This call is implemented using the name service switch (NSS) mechanism on
109 modern UNIX/Linux systems. By saying <quote>users and groups are local</quote>
110 we are implying that they are stored only on the local system, in the
111 <filename>/etc/passwd</filename> and <filename>/etc/group</filename> respectively.
115 For example, if an incoming SessionSetupAndX request is owned by the user
116 <constant>BERYLIUM\WambatW</constant>, a system call will be made to look up
117 the user <constant>WambatW</constant> in the <filename>/etc/passwd</filename>
122 This configuration may be used with stand-alone Samba servers, Domain Member
123 servers (NT4 or ADS), and may be used for a PDC that uses either an smbpasswd
124 or a tdbsam based Samba passdb backend.
129 <varlistentry><term>Winbind is not used, users and groups resolved via NSS: &smbmdash; </term>
132 In this situation user and group accounts are treated as if they are local
133 accounts, the only way in which this differs from having local accounts is
134 that the accounts are stored in a repository that can be shared. In practice
135 this means that they will reside in either a NIS type database or else in LDAP.
139 This configuration may be used with stand-alone Samba servers, Domain Member
140 servers (NT4 or ADS), and may be used for a PDC that uses either an smbpasswd
141 or a tdbsam based Samba passdb backend.
146 <varlistentry><term>Winbind/NSS with the default local IDMAP table: &smbmdash; </term>
149 There are many sites that require only a simple Samba server, or a single Samba
150 server that is a member of a Windows NT4 Domain or an ADS Domain. A typical example
151 is an appliance like file server on which no local accounts are configured and
152 winbind is used to obtain account credentials from the domain controllers for the
153 domain. The domain control can be provided by Samba-3, MS Windows NT4 or MS Windows
158 Winbind is a great convenience in this situation. All that is needed is a range of
159 UID numbers and GID numbers that can be defined in the &smb.conf; file, the
160 <filename>/etc/nsswitch.conf</filename> file is configured to use <command>winbind</command>
161 which does all the difficult work of mapping incoming SIDs to appropriate UIDs and GIDs.
162 The SIDs are allocated a UID/GID in the order in which winbind receives them.
166 This configuration is not convenient or practical in sites that have more than one
167 Samba server and that require the same UID or GID for the same user or group across
168 all servers. One of the hazards of this method is that in the event that the winbind
169 IDMAP file may become corrupted or lost, the repaired or rebuilt IDMAP file may allocate
170 UIDs and GIDs to differing users and groups from what was there previously with the
171 result that MS Windows files that are stored on the Samba server may now not belong to
177 <varlistentry><term>Winbind with an NSS/LDAP backend based IDMAP facility: &smbmdash; </term>
180 In this configuration <command>winbind</command> resolved SIDs to UIDs and GIDs from
181 the <parameter>idmap uid</parameter> and <parameter>idmap gid</parameter> ranges specified
182 in the &smb.conf; file, but instead of using a local winbind IDMAP table it is stored
183 in an LDAP directory so that all Domain Member machines (clients and servers) can share
184 a common IDMAP table.
188 It is important that all LDAP IDMAP clients use only the master LDAP server as the
189 <parameter>idmap backend</parameter> facility in the &smb.conf; file does not correctly
190 handle LDAP redirects.
195 <varlistentry><term>Winbind with NSS to resolve UNIX/Linux user and group IDs: &smbmdash; </term>
198 When Samba is being used as the PDC and BDC the of an LDAP passdb backend is a smart
199 solution, certainly for the domain controllers, but also for Domain Member servers.
200 It is a neat method for assuring that UIDs, GIDs and the matching SIDs will be consistent
205 The use of the LDAP based passdb backend requires use of the PADL nss_ldap utility, or
206 an equivalent. In this situation winbind is used to handle foreign SIDs; ie: SIDs from
207 stand-alone Windows clients (i.e.: not a member of our domain) as well as SIDs from
208 another domain. The foreign UID/GID is mapped from allocated ranges (idmap uid and idmap gid)
209 in precisely the same manner as when using winbind with a local IDMAP table.
213 The nss_ldap tool set can be used to access UIDs and GIDs via LDAP as well as via Active
214 Directory. In order to use Active Directory it is necessary to modify the ADS schema by
215 installing either the AD4UNIX schema extension or else use the Microsoft Services for UNIX
216 version 3.5 of later to extend the ADS schema so it maintains UNIX account credentials.
217 Where the ADS schema is extended a Microsoft Management Console (MMC) snap-in in also
218 installed to permit the UNIX credentials to be set and managed from the ADS User and Computer
219 management tool. Each account must be separately UNIX enabled before the UID and GID data can
225 <varlistentry><term>Winbind/NSS uses RID based IDMAP: &smbmdash; </term>
228 The IDMAP_RID facility is new to Samba version 3.0.8. It was added to make life easier
229 for a number of sites that are committed to use of MS ADS, who do not want to apply
230 an ADS schema extension, and who do not wish to install an LDAP directory server just for
231 the purpose of maintaining an IDMAP table. If you have a single ADS domain (not a forest of
232 domains, and not multiple domain trees) and you want a simple cookie-cutter solution to the
233 IDMAP table problem, then IDMAP_RID is an obvious choice.
237 This facility requires the allocation of the <parameter>idmap uid</parameter> and the
238 <parameter>idmap gid</parameter> ranges, and within the <parameter>idmap uid</parameter>
239 it is possible to allocate a sub-set of this range for automatic mapping of the relative
240 identifier (RID) portion of the SID directly to the base of the UID plus the RID value.
241 For example, if the <parameter>idmap uid</parameter> range is <constant>1000-100000000</constant>
242 and the <parameter>idmap backend = idmap_rid:DOMAIN_NAME=1000-50000000</parameter>, and
243 a SID is encountered that has the value <constant>S-1-5-21-34567898-12529001-32973135-1234</constant>,
244 the resulting UID will be <constant>1000 + 1234 = 2234</constant>.
254 <title>Primary Domain Controller</title>
257 Microsoft Windows domain security systems generate the user and group security identifier (SID) as part
258 of the process of creation of an account. Windows does not have a concept of the UNIX UID or a GID, rather
259 it has its own type of security descriptor. When Samba is used as a Domain Controller, it provides a method
260 of producing a unique SID for each user and group. Samba generates a machine and a domain SID to which it
261 adds a relative identifier (RID) that is calculated algorithmically from a base value that can be specified
262 in the &smb.conf; file, plus twice (2X) the UID or GID.
266 For example, a user has a UID of 4321, and the algorithmic RID base has a value of 1000, the RID will
267 be <constant>1000 + (2 x 4321) = 9642</constant>. Thus, if the domain SID is
268 <constant>S-1-5-21-89238497-92787123-12341112</constant>, the resulting SID is
269 <constant>S-1-5-21-89238497-92787123-12341112-9642</constant>.
273 The foregoing type SID is produced by Samba as an automatic function and is either produced on-the-fly
274 (as in the case when using a <parameter>passdb backend = [tdbsam | smbpasswd]</parameter>, or may be stored
275 as a permanent part of an account in an LDAP based ldapsam.
279 MS Active Directory Server (ADS) uses a directory schema that can be extended to accommodate additional
280 account attributes such as UIDs and GIDs. The installation of Microsoft Service for UNIX 3.5 will expand
281 the normal ADS schema to include UNIX account attributes. These must of course be managed separately
282 through a snap-in module to the normal ADS account management MMC interface.
286 Security identifiers used within a domain must be managed to avoid conflict and to preserve itegrity.
287 In an NT4 domain context that PDC manages the distribution of all security credentials to the backup
288 domain controllers. At this time the only passdb backend for a Samba domain controller that is suitable
289 for such information is an LDAP backend.
295 <title>Backup Domain Controller</title>
298 Backup Domain Controllers (BDCs) have read-only access to security credentials that are stored in LDAP.
299 Changes in user or group account information are passed by the BDC to the PDC. Only the PDC can write
300 changes to the directory.
304 IDMAP information can however be written directly to the LDAP server so long as all domain controllers
305 have access to the master (writable) LDAP server. Samba-3 at this time does not handle LDAP redirects
306 in the IDMAP backend. This means that it is is unsafe to use a slave (replicate) LDAP server with
315 <title>IDMAP Backend Usage</title>
318 Anyone who wishes to use <command>winbind</command> will find the following example configurations helpful.
319 Remember that in the majority of cases <command>winbind</command> is of primary interest for use with
320 Domain Member Servers (DMSs) and Domain Member Clients (DMCs).
324 <title>Default Winbind TDB</title>
327 The following is a simple example of an NT4 DMS &smb.conf; file that shows only the global section.
333 idmap uid = 10000-20000
334 idmap gid = 10000-20000
335 template primary group = "Domain Users"
336 template shell = /bin/bash
337 winbind separator = +
342 The creation of the DMS requires the following steps:
347 Create or install and &smb.conf; file with the above configuration.
353 &rootprompt; net rpc join -UAdministrator%password
354 Joined domain MEGANET2.
356 The success or failure of the join can be confirmed with the following command:
358 &rootprompt; net rpc testjoin
359 Join to 'MIDEARTH' is OK
361 A failed join would report the following:
363 &rootprompt; net rpc testjoin
364 [2004/11/05 16:34:12, 0] utils/net_rpc_join.c:net_rpc_join_ok(66)
365 Join to domain 'MEGANET2' is not valid
370 Start the <command>nmbd, winbind,</command> and <command>smbd</command> daemons in the order shown.
375 The procedure for joining and ADS domain is similar to the NT4 domain join, except the &smb.conf; file
376 will have the following contents:
380 workgroup = BUTTERNET
381 netbios name = GARGOYLE
382 realm = BUTTERNET.BIZ
384 template shell = /bin/bash
385 idmap uid = 500-10000000
386 idmap gid = 500-10000000
387 winbind use default domain = Yes
388 winbind nested groups = Yes
389 printer admin = "BUTTERNET\Domain Admins"
394 ADS DMS operation requires use of kerberos (KRB). For this to work the <filename>krb5.conf</filename>
395 must be configured. The exact requirements depends on which version of MIT or Heimdal kerberos is being
396 used. It is sound advice to use only the latest version, which at this time are MIT kerberos version
397 1.3.5 and Heimdal 0.61.
401 The creation of the DMS requires the following steps:
406 Create or install and &smb.conf; file with the above configuration.
412 &rootprompt; net ads join -UAdministrator%password
413 Joined domain BUTTERNET.
415 The success or failure of the join can be confirmed with the following command:
417 &rootprompt; net ads testjoin
418 Join to 'BUTTERNET' is OK
423 An invalid or failed join can be detected by executing:
425 &rootprompt; net ads testjoin
426 GARGOYLE$@'s password:
427 [2004/11/05 16:53:03, 0] utils/net_ads.c:ads_startup(186)
428 ads_connect: No results returned
429 Join to domain is not valid
434 Start the <command>nmbd, winbind,</command> and <command>smbd</command> daemons in the order shown.
442 <title>IDMAP Storage in LDAP using Winbind</title>
450 server string = Samba Server
452 log level = 1 ads:10 auth:10 sam:10 rpc:10
453 ldap admin dn = cn=Manager,dc=SNOWSHOW,dc=COM
454 ldap idmap suffix = ou=Idmap
455 ldap suffix = dc=SNOWSHOW,dc=COM
456 idmap backend = ldap:ldap://ldap.snowshow.com
457 idmap uid = 150000-550000
458 idmap gid = 150000-550000
459 template shell = /bin/bash
460 winbind use default domain = Yes
467 <title>IDMAP and NSS IDMAP Resolution</title>
476 idmap uid = 150000-550000
477 idmap gid = 150000-550000
478 template shell = /bin/bash
479 winbind cache time = 5
480 winbind use default domain = Yes
481 winbind trusted domains only = Yes
482 winbind nested groups = Yes
487 <title>IDMAP, Active Directory and MS Services for UNIX 3.5</title>
495 <title>IDMAP, Active Directory and AD4UNIX</title>
505 <title>IDMAP_RID with Winbind</title>
512 realm = corp.kpak.com
513 server string = Office Server
515 allow trusted domains = No
516 idmap backend = idmap_rid:KPAK=500-100000000
517 idmap uid = 500-100000000
518 idmap gid = 500-100000000
519 template shell = /bin/bash
520 winbind use default domain = Yes
521 winbind enum users = No
522 winbind enum groups = No
523 winbind nested groups = Yes
524 printer admin = "Domain Admins"