Chapter 14. Identity Mapping (IDMAP)

+ + + + + - + The Microsoft Windows operating system has a number of features that impose specific challenges to interoperability with the operating systems on which Samba is implemented. This chapter deals explicitly with the mechanisms Samba-3 (version 3.0.8 and later) uses to overcome one of the @@ -16,10 +16,10 @@ to UNIX UIDs and GIDs. To ensure sufficient coverage, each possible Samba deployment type is discussed. This is followed by an overview of how the IDMAP facility may be implemented.

- - - - + + + + The IDMAP facility is of concern where more than one Samba server (or Samba network client) is installed in a domain. Where there is a single Samba server, do not be too concerned regarding the IDMAP infrastructure the default behavior of Samba is nearly always sufficient. @@ -27,13 +27,13 @@ Where mulitple Samba servers are used it is often necessary to move data off one another, and that is where the fun begins!

- - - + + + - - - + + + Where user and group account information is stored in an LDAP directory every server can have the same consistent UID and GID for users and groups. This is achieved using NSS and the nss_ldap tool. Samba can be configured to use only local accounts, in which case the scope of the IDMAP problem is somewhat @@ -41,75 +41,75 @@ reduced. This works reasonably well if the servers belong to a single domain, an are not needed. On the other hand, if the Samba servers are NT4 domain members, or ADS domain members, or if there is a need to keep the security name-space separate (i.e., the user DOMINICUS\FJones must not be given access to the account resources of the user -FRANCISCUS\FJones^[4] free from inadvertent cross-over, close attention should be given +FRANCISCUS\FJones^[4] free from inadvertent cross-over, close attention should be given to the way that the IDMAP facility is configured.

- - - - - + + + + + The use of IDMAP is important where the Samba server will be accessed by workstations or servers from more than one domain, in which case it is important to run winbind so it can handle the resolution (ID mapping) of foreign SIDs to local UNIX UIDs and GIDs.

- + The use of the IDMAP facility requires the execution of the winbindd upon Samba startup.

Samba Server Deployment Types and IDMAP

- + There are four basic server deployment types, as documented in the chapter on Server Types and Security Modes. -

Standalone Samba Server

- +

Standalone Samba Server

+ - + A standalone Samba server is an implementation that is not a member of a Windows NT4 domain, a Windows 200X Active Directory domain, or a Samba domain.

- - - + + + By definition, this means that users and groups will be created and controlled locally, and the identity of a network user must match a local UNIX/Linux user login. The IDMAP facility is therefore of little to no interest, winbind will not be necessary, and the IDMAP facility will not be relevant or of interest. -

Domain Member Server or Domain Member Client

- + - + Samba-3 can act as a Windows NT4 PDC or BDC, thereby providing domain control protocols that are compatible with Windows NT4. Samba-3 file and print sharing protocols are compatible with all versions of MS Windows products. Windows NT4, as with MS Active Directory, extensively makes use of Windows SIDs.

- - + + Samba-3 domain member servers and clients must interact correctly with MS Windows SIDs. Incoming Windows SIDs must be translated to local UNIX UIDs and GIDs. Outgoing information from the Samba server must provide to MS Windows clients and servers appropriate SIDs.

- + A Samba member of a Windows networking domain (NT4-style or ADS) can be configured to handle identity mapping in a variety of ways. The mechanism it uses depends on whether or not the winbindd daemon is used and how the winbind functionality is configured. The configuration options are briefly described here:

Winbind is not used; users and groups are local:

- - - - + + + + - - + + - + Where winbindd is not used Samba (smbd) uses the underlying UNIX/Linux mechanisms to resolve the identity of incoming network traffic. This is done using the LoginID (account name) in the @@ -129,21 +129,21 @@ on Server Types and Security Modes. - + - - + + This configuration may be used with standalone Samba servers, domain member servers (NT4 or ADS), and for a PDC that uses either an smbpasswd or a tdbsam-based Samba passdb backend.

Winbind is not used; users and groups resolved via NSS:

- - - + + + - + In this situation user and group accounts are treated as if they are local accounts. The only way in which this differs from having local accounts is that the accounts are stored in a repository that can be shared. In practice @@ -152,18 +152,18 @@ on Server Types and Security Modes. - + - - + + This configuration may be used with standalone Samba servers, domain member servers (NT4 or ADS), and for a PDC that uses either an smbpasswd or a tdbsam-based Samba passdb backend.

Winbind/NSS with the default local IDMAP table:

- + - + There are many sites that require only a simple Samba server or a single Samba server that is a member of a Windows NT4 domain or an ADS domain. A typical example is an appliance like file server on which no local accounts are configured and @@ -171,8 +171,8 @@ on Server Types and Security Modes. domain. The domain control can be provided by Samba-3, MS Windows NT4, or MS Windows Active Directory.

- - + + @@ -182,10 +182,10 @@ on Server Types and Security Modes. which does all the difficult work of mapping incoming SIDs to appropriate UIDs and GIDs. The SIDs are allocated a UID/GID in the order in which winbind receives them.

- + - - + + This configuration is not convenient or practical in sites that have more than one Samba server and that require the same UID or GID for the same user or group across all servers. One of the hazards of this method is that in the event that the winbind @@ -194,10 +194,10 @@ on Server Types and Security Modes. result that MS Windows files that are stored on the Samba server may now not belong to the rightful owners.

Winbind/NSS uses RID based IDMAP:

- - + + - + The IDMAP_RID facility is new to Samba version 3.0.8. It was added to make life easier for a number of sites that are committed to use of MS ADS, that do not apply an ADS schema extension, and that do not have an installed an LDAP directory server just for @@ -205,14 +205,14 @@ on Server Types and Security Modes. domains, and not multiple domain trees) and you want a simple cookie-cutter solution to the IDMAP table problem, then IDMAP_RID is an obvious choice.

- - + + - + - - + + This facility requires the allocation of the idmap uid and the idmap gid ranges, and within the idmap uid it is possible to allocate a subset of this range for automatic mapping of the relative @@ -222,22 +222,22 @@ on Server Types and Security Modes. a SID is encountered that has the value S-1-5-21-34567898-12529001-32973135-1234, the resulting UID will be 1000 + 1234 = 2234.

Winbind with an NSS/LDAP backend-based IDMAP facility:

- - - + + + - + - + In this configuration winbind resolved SIDs to UIDs and GIDs from the idmap uid and idmap gid ranges specified in the smb.conf file, but instead of using a local winbind IDMAP table, it is stored in an LDAP directory so that all domain member machines (clients and servers) can share a common IDMAP table.

- - + + It is important that all LDAP IDMAP clients use only the master LDAP server because the idmap backend facility in the smb.conf file does not correctly @@ -247,17 +247,17 @@ on Server Types and Security Modes. domain member servers. It is a neat method for assuring that UIDs, GIDs, and the matching SIDs are consistent across all servers.

- - + + The use of the LDAP-based passdb backend requires use of the PADL nss_ldap utility or an equivalent. In this situation winbind is used to handle foreign SIDs, that is, SIDs from standalone Windows clients (i.e., not a member of our domain) as well as SIDs from another domain. The foreign UID/GID is mapped from allocated ranges (idmap uid and idmap gid) in precisely the same manner as when using winbind with a local IDMAP table.

- + - + The nss_ldap tool set can be used to access UIDs and GIDs via LDAP as well as via Active Directory. In order to use Active Directory, it is necessary to modify the ADS schema by installing either the AD4UNIX schema extension or using the Microsoft Services for UNIX @@ -266,11 +266,11 @@ on Server Types and Security Modes. installed to permit the UNIX credentials to be set and managed from the ADS User and Computer Management tool. Each account must be separately UNIX-enabled before the UID and GID data can be used by Samba. -

Primary Domain Controller

- - - - +

Primary Domain Controller

+ + + + Microsoft Windows domain security systems generate the user and group SID as part of the process of creation of an account. Windows does not have a concept of the UNIX UID or a GID; rather, it has its own type of security descriptor. When Samba is used as a domain controller, it provides a method @@ -278,7 +278,7 @@ on Server Types and Security Modes. adds an RID that is calculated algorithmically from a base value that can be specified in the smb.conf file, plus twice (2x) the UID or GID. This method is called “algorithmic mapping”.

- + For example, if a user has a UID of 4321, and the algorithmic RID base has a value of 1000, the RID will be 1000 + (2 x 4321) = 9642. Thus, if the domain SID is S-1-5-21-89238497-92787123-12341112, the resulting SID is @@ -286,39 +286,39 @@ on Server Types and Security Modes.

- - + + The foregoing type of SID is produced by Samba as an automatic function and is either produced on the fly (as is the case when using a passdb backend = [tdbsam | smbpasswd]), or may be stored as a permanent part of an account in an LDAP-based ldapsam.

- - - - - - - - - + + + + + + + + + ADS uses a directory schema that can be extended to accommodate additional account attributes such as UIDs and GIDs. The installation of Microsoft Service for UNIX 3.5 will expand the normal ADS schema to include UNIX account attributes. These must of course be managed separately through a snap-in module to the normal ADS account management MMC interface.

- + - + Security identifiers used within a domain must be managed to avoid conflict and to preserve itegrity. In an NT4 domain context, the PDC manages the distribution of all security credentials to the backup domain controllers (BDCs). At this time the only passdb backend for a Samba domain controller that is suitable for such information is an LDAP backend. -

Backup Domain Controller

- - +

Backup Domain Controller

+ + - + @@ -331,25 +331,25 @@ on Server Types and Security Modes. in the IDMAP backend. This means that it is is unsafe to use a slave (replicate) LDAP server with the IDMAP facility.

Examples of IDMAP Backend Usage

- - - - - + + + + + Anyone who wishes to use winbind will find the following example configurations helpful. Remember that in the majority of cases winbind is of primary interest for use with domain member servers (DMSs) and domain member clients (DMCs). -

Default Winbind TDB

Two common configurations are used:

Networks that have an NT4 PDC (with or without BDCs) or a Samba PDC (with or without BDCs).
Networks that use MS Windows 200x ADS. -

NT4-Style Domains (Includes Samba Domains)

NT4 Domain Member Server smb.con is a simple example of an NT4 DMS smb.conf file that shows only the global section. -

Example 14.1. NT4 Domain Member Server smb.conf

# Global parameters

[global]

workgroup = MEGANET2

security = DOMAIN

idmap uid = 10000-20000

idmap gid = 10000-20000

template primary group = "Domain Users"

template shell = /bin/bash

- +

Example 14.1. NT4 Domain Member Server smb.conf

# Global parameters

[global]

workgroup = MEGANET2

security = DOMAIN

idmap uid = 10000-20000

idmap gid = 10000-20000

template primary group = "Domain Users"

template shell = /bin/bash

+ The use of winbind requires configuration of NSS. Edit the /etc/nsswitch.conf so it includes the following entries: @@ -380,30 +380,30 @@ Joined domain MEGANET2. Join to 'MIDEARTH' is OK

A failed join would report an error message like the following: - +

 root#  net rpc testjoin
 [2004/11/05 16:34:12, 0] utils/net_rpc_join.c:net_rpc_join_ok(66)
 Join to domain 'MEGANET2' is not valid

- - + + Start the nmbd, winbind, and smbd daemons in the order shown.

ADS Domains

- - + + The procedure for joining an ADS domain is similar to the NT4 domain join, except the smb.conf file will have the contents shown in ADS Domain Member Server smb.conf -

Example 14.2. ADS Domain Member Server smb.conf

# Global parameters

[global]

workgroup = BUTTERNET

netbios name = GARGOYLE

realm = BUTTERNET.BIZ

security = ADS

template shell = /bin/bash

idmap uid = 500-10000000

idmap gid = 500-10000000

winbind use default domain = Yes

winbind nested groups = Yes

printer admin = "BUTTERNET\Domain Admins"

- - +

Example 14.2. ADS Domain Member Server smb.conf

# Global parameters

[global]

workgroup = BUTTERNET

netbios name = GARGOYLE

realm = BUTTERNET.BIZ

security = ADS

template shell = /bin/bash

idmap uid = 500-10000000

idmap gid = 500-10000000

winbind use default domain = Yes

winbind nested groups = Yes

printer admin = "BUTTERNET\Domain Admins"

+ + - - - + + + ADS DMS operation requires use of kerberos (KRB). For this to work, the krb5.conf must be configured. The exact requirements depends on which version of MIT or Heimdal Kerberos is being used. It is sound advice to use only the latest version, which at this time are MIT Kerberos version @@ -416,7 +416,7 @@ Join to domain 'MEGANET2' is not valid Edit the /etc/nsswitch.conf file as shown above.

Execute: - +

 root#  net ads join -UAdministrator%password
 Joined domain BUTTERNET.
@@ -439,7 +439,7 @@ Join to domain is not valid
 		
 		
 		
-		
+		
 		The specific error message may differ from the above because it depends on the type of failure that
 		may have occurred. Increase the log level to 10, repeat the test,
 		and then examine the log files produced to identify the nature of the failure.
@@ -447,18 +447,18 @@ Join to domain is not valid
 		Start the nmbd, winbind, and smbd daemons in the order shown.

IDMAP_RID with Winbind

- - - + + + The idmap_rid facility is a new tool that, unlike native winbind, creates a predictable mapping of MS Windows SIDs to UNIX UIDs and GIDs. The key benefit of this method of implementing the Samba IDMAP facility is that it eliminates the need to store the IDMAP data in a central place. The downside is that it can be used only within a single ADS domain and is not compatible with trusted domain implementations.

- - - + + + This alternate method of SID to UID/GID mapping can be achieved using the idmap_rid plug-in. This plug-in uses the RID of the user SID to derive the UID and GID by adding the @@ -467,17 +467,17 @@ Join to domain is not valid with multiple domain environments. The idmap uid and idmap gid ranges must be specified.

- - + + The idmap_rid facility can be used both for NT4/Samba-style domains and Active Directory. To use this with an NT4 domain, do not include the realm parameter; additionally, the method used to join the domain uses the net rpc join process.

An example smb.conf file for and ADS domain environment is shown in ADS Domain Member smb.conf using idmap_rid. -

Example 14.3. ADS Domain Member smb.conf using idmap_rid

# Global parameters

[global]

workgroup = KPAK

netbios name = BIGJOE

realm = CORP.KPAK.COM

server string = Office Server

security = ADS

allow trusted domains = No

idmap backend = idmap_rid:KPAK=500-100000000

idmap uid = 500-100000000

idmap gid = 500-100000000

template shell = /bin/bash

winbind use default domain = Yes

winbind enum users = No

winbind enum groups = No

winbind nested groups = Yes

printer admin = "Domain Admins"

- - +

Example 14.3. ADS Domain Member smb.conf using idmap_rid

# Global parameters

[global]

workgroup = KPAK

netbios name = BIGJOE

realm = CORP.KPAK.COM

server string = Office Server

security = ADS

allow trusted domains = No

idmap backend = idmap_rid:KPAK=500-100000000

idmap uid = 500-100000000

idmap gid = 500-100000000

template shell = /bin/bash

winbind use default domain = Yes

winbind enum users = No

winbind enum groups = No

winbind nested groups = Yes

printer admin = "Domain Admins"

+ + In a large domain with many users it is imperative to disable enumeration of users and groups. @@ -488,7 +488,7 @@ Join to domain is not valid or groups using the getent passwd and getent group commands. It will be possible to perform the lookup for individual users, as shown in the following procedure.

- + The use of this tool requires configuration of NSS as per the native use of winbind. Edit the /etc/nsswitch.conf so it has the following parameters: @@ -515,7 +515,7 @@ Using short domain name -- KPAK Joined 'BIGJOE' to realm 'CORP.KPAK.COM'

- + An invalid or failed join can be detected by executing:

 root#  net ads testjoin
@@ -531,13 +531,13 @@ Join to domain is not valid
 		Start the nmbd, winbind, and smbd daemons in the order shown.
 		

 		Validate the operation of this configuration by executing:
-		
+		
 
 root#  getent passwd administrator
 administrator:x:1000:1013:Administrator:/home/BE/administrator:/bin/bash
 

-

IDMAP Storage in LDAP Using Winbind

- +

- + Follow the diagnositic procedures shown earlier in this chapter to identify success or failure of the join. In many cases a failure is indicated by a silent return to the command prompt with no indication of the reason for failure. -

Prev	Up	Next
Chapter 13. Remote and Local Management: The Net Command	Home	Chapter 15. User Rights and Privileges

Prev	Up	Next
Chapter 13. Remote and Local Management: The Net Command	Home	Chapter 15. User Rights and Privileges