%global_entities; ]> &author.jht; THIS IS A WORK IN PROGRESS - it is a preparation for the release of Samba-3.0.8. The Microsoft Windows operating system has a number of features that impose specific challenges for interoperability with operating system on which Samba is implemented. This chapter deals explicitly with the mechanisms Samba-3 (version 3.0.8 and later) has to overcome one of the key challenges in the integration of Samba servers into an MS Windows networking environment. This chapter deals with IDentity MAPping (IDMAP) of Windows Security IDentifiers (SIDs) to UNIX UIDs and GIDs. So that this area is covered sufficiently, each possible Samba deployment type will be discussed. This is followed by an overview of how the IDMAP facility may be implemented. The IDMAP facility is usually of concern where more than one Samba server or Samba network client is installed in the one 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. 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 that the winbindd be executed on Samba start-up. There are four (4) basic server deployment types, as documented in the chapter on Server Types and Security Modes. A stand-alone Samba server is an implementation that is not a member of a Windows NT4 Domain, a Windows 200X Active Directory Domain, or of 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. Samba-3 can act as a Windows NT4 PDC or BDC thereby providing domain control protocols that are based on Windows NT4. Thus, where Samba-3 is a Domain Member server or client the matter of SID to UID/GID resolution is equivalent to configuration with a Windows NT4 or earlier domain environment. When Samba-3 is acting as a Domain Member of an Active Directory (ADS) domain it will also be necessary to resolve domain user and group identities (SIDs) to UNIX UIDs and GIDs. 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 is will use 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: &smbmdash Winbind is not used, users and groups resolved via NSS: &smbmdash; Winbind maintains local IDMAP table: &smbmdash; Winbind uses LDAP backend based IDMAP: &smbmdash; Winbind uses NSS to resolve UNIX/Linux user and group IDs: &smbmdash; Winbind uses RID based IDMAP: &smbmdash; Microsoft Windows domain security systems generate the user and group security identifier (SID) as part of the process of creation of an account. Windows does not have a concept of a UID or a GID. MS Active Directory Server (ADS) uses a directory schema that can be extended to accommodate additional account attributes such as UIDs and GIDs.