<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 12. Identity Mapping (IDMAP)</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.64.1"><link rel="home" href="index.html" title="The Official Samba-3 HOWTO and Reference Guide"><link rel="up" href="optional.html" title="Part III. Advanced Configuration"><link rel="previous" href="groupmapping.html" title="Chapter 11. Group Mapping MS Windows and UNIX"><link rel="next" href="AccessControls.html" title="Chapter 13. File, Directory and Share Access Controls"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 12. Identity Mapping (IDMAP)</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="groupmapping.html">Prev</a> </td><th width="60%" align="center">Part III. Advanced Configuration</th><td width="20%" align="right"> <a accesskey="n" href="AccessControls.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="idmapper"></a>Chapter 12. Identity Mapping (IDMAP)</h2></div><div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="othername">H.</span> <span class="surname">Terpstra</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:jht@samba.org">jht@samba.org</a>></tt></p></div></div></div></div></div><div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="idmapper.html#id2538535">Samba Server Deployment Types and IDMAP</a></span></dt><dd><dl><dt><span class="sect2"><a href="idmapper.html#id2538560">Stand-Alone Samba Server</a></span></dt><dt><span class="sect2"><a href="idmapper.html#id2538616">Domain Member Server or Domain Member Client</a></span></dt><dt><span class="sect2"><a href="idmapper.html#id2539200">Primary Domain Controller</a></span></dt><dt><span class="sect2"><a href="idmapper.html#id2539335">Backup Domain Controller</a></span></dt></dl></dd><dt><span class="sect1"><a href="idmapper.html#id2539366">Examples of IDMAP Backend Usage</a></span></dt><dd><dl><dt><span class="sect2"><a href="idmapper.html#id2539422">Default Winbind TDB</a></span></dt><dt><span class="sect2"><a href="idmapper.html#id2539844">IDMAP_RID with Winbind</a></span></dt><dt><span class="sect2"><a href="idmapper.html#id2540230">IDMAP Storage in LDAP using Winbind</a></span></dt><dt><span class="sect2"><a href="idmapper.html#id2540600">IDMAP and NSS Using LDAP From ADS with RFC2307bis Schema Extension</a></span></dt></dl></dd></dl></div><p> <a class="indexterm" name="id2538423"></a> <a class="indexterm" name="id2538430"></a> <a class="indexterm" name="id2538437"></a> <a class="indexterm" name="id2538444"></a> <a class="indexterm" name="id2538453"></a> <a class="indexterm" name="id2538460"></a> <a class="indexterm" name="id2538466"></a> The Microsoft Windows operating system has a number of features that impose specific challenges to interoperability with operating system 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 key challenges in the integration of Samba servers into an MS Windows networking environment. This chapter deals with Identify Mapping (IDMAP) of Windows Security Identifers (SIDs) to UNIX UIDs and GIDs. </p><p> To ensure good sufficient coverage each possible Samba deployment type will be discussed. This is followed by an overview of how the IDMAP facility may be implemented. </p><p> <a class="indexterm" name="id2538490"></a> 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. </p><p> <a class="indexterm" name="id2538505"></a> 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. </p><p> <a class="indexterm" name="id2538520"></a> The use of the IDMAP facility requires that the <span><b class="command">winbindd</b></span> be executed on Samba start-up. </p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2538535"></a>Samba Server Deployment Types and IDMAP</h2></div></div><div></div></div><p> <a class="indexterm" name="id2538543"></a> There are four (4) basic server deployment types, as documented in <a href="ServerType.html" title="Chapter 3. Server Types and Security Modes">the chapter on Server Types and Security Modes</a>. </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2538560"></a>Stand-Alone Samba Server</h3></div></div><div></div></div><p> <a class="indexterm" name="id2538568"></a> <a class="indexterm" name="id2538575"></a> <a class="indexterm" name="id2538582"></a> 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. </p><p> <a class="indexterm" name="id2538595"></a> <a class="indexterm" name="id2538602"></a> 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. </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2538616"></a>Domain Member Server or Domain Member Client</h3></div></div><div></div></div><p> <a class="indexterm" name="id2538624"></a> <a class="indexterm" name="id2538631"></a> <a class="indexterm" name="id2538637"></a> <a class="indexterm" name="id2538644"></a> <a class="indexterm" name="id2538650"></a> 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 version of Microsoft Windows products. Windows NT4, as with Microsoft Active Directory, extensively makes use of Windows security identifiers (SIDs). </p><p> <a class="indexterm" name="id2538666"></a> <a class="indexterm" name="id2538673"></a> <a class="indexterm" name="id2538680"></a> 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. </p><p> <a class="indexterm" name="id2538694"></a> <a class="indexterm" name="id2538701"></a> 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 <span><b class="command">winbindd</b></span> daemon is used, and how the winbind functionality is configured. The configuration options are briefly described here: </p><div class="variablelist"><dl><dt><span class="term">Winbind is not used, users and groups are local: </span></dt><dd><p> Where <span><b class="command">winbindd</b></span> is not used Samba (<span><b class="command">smbd</b></span>) uses the underlying UNIX/Linux mechanisms to resolve the identity of incoming network traffic. This will be done using the LoginID (account name) in the session setup request and passing it to the getpwnam() system function call. This call is implemented using the name service switch (NSS) mechanism on modern UNIX/Linux systems. By saying “<span class="quote"><span class="emphasis"><em>users and groups are local</em></span></span>” we are implying that they are stored only on the local system, in the <tt class="filename">/etc/passwd</tt> and <tt class="filename">/etc/group</tt> respectively. </p><p> For example, if an incoming SessionSetupAndX request is owned by the user <tt class="constant">BERYLIUM\WambatW</tt>, a system call will be made to look up the user <tt class="constant">WambatW</tt> in the <tt class="filename">/etc/passwd</tt> file. </p><p> This configuration may be used with stand-alone Samba servers, Domain Member servers (NT4 or ADS), and may be used for a PDC that uses either an smbpasswd or a tdbsam based Samba passdb backend. </p></dd><dt><span class="term">Winbind is not used, users and groups resolved via NSS: </span></dt><dd><p> 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 this means that they will reside in either a NIS type database or else in LDAP. </p><p> This configuration may be used with stand-alone Samba servers, Domain Member servers (NT4 or ADS), and may be used for a PDC that uses either an smbpasswd or a tdbsam based Samba passdb backend. </p></dd><dt><span class="term">Winbind/NSS with the default local IDMAP table: </span></dt><dd><p> 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 winbind is used to obtain account credentials from the domain controllers for the domain. The domain control can be provided by Samba-3, MS Windows NT4 or MS Windows Active Directory. </p><p> Winbind is a great convenience in this situation. All that is needed is a range of UID numbers and GID numbers that can be defined in the <tt class="filename">smb.conf</tt> file, the <tt class="filename">/etc/nsswitch.conf</tt> file is configured to use <span><b class="command">winbind</b></span> 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. </p><p> 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 IDMAP file may become corrupted or lost, the repaired or rebuilt IDMAP file may allocate UIDs and GIDs to differing users and groups from what was there previously with the result that MS Windows files that are stored on the Samba server may now not belong to to rightful owner. </p></dd><dt><span class="term">Winbind/NSS uses RID based IDMAP: </span></dt><dd><p> <a class="indexterm" name="id2538904"></a> <a class="indexterm" name="id2538911"></a> <a class="indexterm" name="id2538917"></a> <a class="indexterm" name="id2538924"></a> 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, who do not want to apply an ADS schema extension, and who do not wish to install an LDAP directory server just for the purpose of maintaining an IDMAP table. If you have a single ADS domain (not a forest of 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. </p><p> <a class="indexterm" name="id2538943"></a> <a class="indexterm" name="id2538950"></a> <a class="indexterm" name="id2538956"></a> <a class="indexterm" name="id2538963"></a> <a class="indexterm" name="id2538970"></a> <a class="indexterm" name="id2538976"></a> <a class="indexterm" name="id2538983"></a> This facility requires the allocation of the <i class="parameter"><tt>idmap uid</tt></i> and the <i class="parameter"><tt>idmap gid</tt></i> ranges, and within the <i class="parameter"><tt>idmap uid</tt></i> it is possible to allocate a sub-set of this range for automatic mapping of the relative identifier (RID) portion of the SID directly to the base of the UID plus the RID value. For example, if the <i class="parameter"><tt>idmap uid</tt></i> range is <tt class="constant">1000-100000000</tt> and the <i class="parameter"><tt>idmap backend = idmap_rid:DOMAIN_NAME=1000-50000000</tt></i>, and a SID is encountered that has the value <tt class="constant">S-1-5-21-34567898-12529001-32973135-1234</tt>, the resulting UID will be <tt class="constant">1000 + 1234 = 2234</tt>. </p></dd><dt><span class="term">Winbind with an NSS/LDAP backend based IDMAP facility: </span></dt><dd><p> <a class="indexterm" name="id2539054"></a> In this configuration <span><b class="command">winbind</b></span> resolved SIDs to UIDs and GIDs from the <i class="parameter"><tt>idmap uid</tt></i> and <i class="parameter"><tt>idmap gid</tt></i> ranges specified in the <tt class="filename">smb.conf</tt> 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. </p><p> <a class="indexterm" name="id2539092"></a> It is important that all LDAP IDMAP clients use only the master LDAP server as the <i class="parameter"><tt>idmap backend</tt></i> facility in the <tt class="filename">smb.conf</tt> file does not correctly handle LDAP redirects. </p></dd><dt><span class="term">Winbind with NSS to resolve UNIX/Linux user and group IDs: </span></dt><dd><p> When Samba is being used as the PDC and BDC the of an LDAP passdb backend is a smart solution, certainly for the domain controllers, but also for Domain Member servers. It is a neat method for assuring that UIDs, GIDs and the matching SIDs will be consistent across all servers. </p><p> <a class="indexterm" name="id2539139"></a> <a class="indexterm" name="id2539145"></a> 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; ie: SIDs from stand-alone 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. </p><p> <a class="indexterm" name="id2539163"></a> <a class="indexterm" name="id2539170"></a> <a class="indexterm" name="id2539176"></a> 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 else use the Microsoft Services for UNIX version 3.5 of later to extend the ADS schema so it maintains UNIX account credentials. Where the ADS schema is extended a Microsoft Management Console (MMC) snap-in in also 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. </p></dd></dl></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2539200"></a>Primary Domain Controller</h3></div></div><div></div></div><p> <a class="indexterm" name="id2539208"></a> <a class="indexterm" name="id2539215"></a> <a class="indexterm" name="id2539221"></a> <a class="indexterm" name="id2539228"></a> 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 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 of producing a unique SID for each user and group. Samba generates a machine and a domain SID to which it adds a relative identifier (RID) that is calculated algorithmically from a base value that can be specified in the <tt class="filename">smb.conf</tt> file, plus twice (2X) the UID or GID. This method is called “<span class="quote"><span class="emphasis"><em>algorithmic mapping</em></span></span>”. </p><p> <a class="indexterm" name="id2539259"></a> For example, a user has a UID of 4321, and the algorithmic RID base has a value of 1000, the RID will be <tt class="constant">1000 + (2 x 4321) = 9642</tt>. Thus, if the domain SID is <tt class="constant">S-1-5-21-89238497-92787123-12341112</tt>, the resulting SID is <tt class="constant">S-1-5-21-89238497-92787123-12341112-9642</tt>. </p><p> <a class="indexterm" name="id2539284"></a> The foregoing type SID is produced by Samba as an automatic function and is either produced on-the-fly (as in the case when using a <i class="parameter"><tt>passdb backend = [tdbsam | smbpasswd]</tt></i>, or may be stored as a permanent part of an account in an LDAP based ldapsam. </p><p> <a class="indexterm" name="id2539304"></a> MS Active Directory Server (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. </p><p> <a class="indexterm" name="id2539320"></a> Security identifiers used within a domain must be managed to avoid conflict and to preserve itegrity. In an NT4 domain context that PDC manages the distribution of all security credentials to the backup domain controllers. At this time the only passdb backend for a Samba domain controller that is suitable for such information is an LDAP backend. </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2539335"></a>Backup Domain Controller</h3></div></div><div></div></div><p> <a class="indexterm" name="id2539343"></a> Backup Domain Controllers (BDCs) have read-only access to security credentials that are stored in LDAP. Changes in user or group account information are passed by the BDC to the PDC. Only the PDC can write changes to the directory. </p><p> IDMAP information can however be written directly to the LDAP server so long as all domain controllers have access to the master (writable) LDAP server. Samba-3 at this time does not handle LDAP redirects in the IDMAP backend. This means that it is is unsafe to use a slave (replicate) LDAP server with the IDMAP facility. </p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2539366"></a>Examples of IDMAP Backend Usage</h2></div></div><div></div></div><p> <a class="indexterm" name="id2539374"></a> <a class="indexterm" name="id2539383"></a> <a class="indexterm" name="id2539392"></a> <a class="indexterm" name="id2539399"></a> Anyone who wishes to use <span><b class="command">winbind</b></span> will find the following example configurations helpful. Remember that in the majority of cases <span><b class="command">winbind</b></span> is of primary interest for use with Domain Member Servers (DMSs) and Domain Member Clients (DMCs). </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2539422"></a>Default Winbind TDB</h3></div></div><div></div></div><p> Two common configurations are used: </p><div class="itemizedlist"><ul type="disc"><li><p> Networks that have an NT4 PDC (with or without BDCs) or a Samba PDC (with or without BDCs). </p></li><li><p> Networks that use MS Windows 200X ADS. </p></li></ul></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2539446"></a>NT4 Style Domains (includes Samba Domains)</h4></div></div><div></div></div><p> The following is a simple example of an NT4 DMS <tt class="filename">smb.conf</tt> file that shows only the global section. </p><pre class="screen"> #Global parameters [global] workgroup = MEGANET2 security = DOMAIN idmap uid = 10000-20000 idmap gid = 10000-20000 template primary group = "Domain Users" template shell = /bin/bash </pre><p> </p><p> <a class="indexterm" name="id2539475"></a> <a class="indexterm" name="id2539481"></a> The use of <span><b class="command">winbind</b></span> requires configuration of NSS. Edit the <tt class="filename">/etc/nsswitch.conf</tt> so it includes the following entries: </p><pre class="screen"> ... passwd: files winbind shadow: files winbind group: files winbind ... hosts: files wins ... </pre><p> </p><p> The creation of the DMS requires the following steps: </p><div class="procedure"><ol type="1"><li><p> Create or install and <tt class="filename">smb.conf</tt> file with the above configuration. </p></li><li><p> Execute: </p><pre class="screen"> <tt class="prompt">root# </tt> net rpc join -UAdministrator%password Joined domain MEGANET2. </pre><p> <a class="indexterm" name="id2539549"></a> The success or failure of the join can be confirmed with the following command: </p><pre class="screen"> <tt class="prompt">root# </tt> net rpc testjoin Join to 'MIDEARTH' is OK </pre><p> A failed join would report an error message like the following: <a class="indexterm" name="id2539570"></a> </p><pre class="screen"> <tt class="prompt">root# </tt> 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 </pre><p> </p></li><li><p> Start the <span><b class="command">nmbd, winbind,</b></span> and <span><b class="command">smbd</b></span> daemons in the order shown. </p></li></ol></div></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2539613"></a>ADS Domains</h4></div></div><div></div></div><p> <a class="indexterm" name="id2539621"></a> The procedure for joining and ADS domain is similar to the NT4 domain join, except the <tt class="filename">smb.conf</tt> file will have the following contents: </p><pre class="screen"> # 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" </pre><p> </p><p> <a class="indexterm" name="id2539651"></a> <a class="indexterm" name="id2539658"></a> <a class="indexterm" name="id2539665"></a> <a class="indexterm" name="id2539672"></a> <a class="indexterm" name="id2539679"></a> <a class="indexterm" name="id2539686"></a> <a class="indexterm" name="id2539693"></a> ADS DMS operation requires use of kerberos (KRB). For this to work the <tt class="filename">krb5.conf</tt> 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 1.3.5 and Heimdal 0.61. </p><p> The creation of the DMS requires the following steps: </p><div class="procedure"><ol type="1"><li><p> Create or install and <tt class="filename">smb.conf</tt> file with the above configuration. </p></li><li><p> Edit the <tt class="filename">/etc/nsswitch.conf</tt> file as shown above. </p></li><li><p> Execute: <a class="indexterm" name="id2539751"></a> </p><pre class="screen"> <tt class="prompt">root# </tt> net ads join -UAdministrator%password Joined domain BUTTERNET. </pre><p> The success or failure of the join can be confirmed with the following command: </p><pre class="screen"> <tt class="prompt">root# </tt> net ads testjoin Using short domain name -- BUTTERNET Joined 'GARGOYLE' to realm 'BUTTERNET.BIZ' </pre><p> </p><p> An invalid or failed join can be detected by executing: </p><pre class="screen"> <tt class="prompt">root# </tt> net ads testjoin GARGOYLE$@'s password: [2004/11/05 16:53:03, 0] utils/net_ads.c:ads_startup(186) ads_connect: No results returned Join to domain is not valid </pre><p> <a class="indexterm" name="id2539803"></a> The specific error message may differ from the above as it depends on the type of failure that may have occured. Increase the <i class="parameter"><tt>log level</tt></i> to 10, repeat the above test and then examine the log files produced to identify the nature of the failure. </p></li><li><p> Start the <span><b class="command">nmbd, winbind,</b></span> and <span><b class="command">smbd</b></span> daemons in the order shown. </p></li></ol></div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2539844"></a>IDMAP_RID with Winbind</h3></div></div><div></div></div><p> <a class="indexterm" name="id2539852"></a> <a class="indexterm" name="id2539859"></a> <a class="indexterm" name="id2539865"></a> <a class="indexterm" name="id2539872"></a> The <span><b class="command">idmap_rid</b></span> 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 down-side is that it can be used only within a single ADS Domain and is not compatible with trusted domain implementations. </p><p> <a class="indexterm" name="id2539895"></a> <a class="indexterm" name="id2539901"></a> <a class="indexterm" name="id2539908"></a> <a class="indexterm" name="id2539915"></a> This alternate method of SID to UID/GID mapping can be achieved uses the idmap_rid plug-in. This plug-in uses the RID of the user SID to derive the UID and GID by adding the RID to a base value specified. This utility requires that the parameter “<span class="quote"><span class="emphasis"><em>allow trusted domains = No</em></span></span>” must be specified, as it is not compatible with multiple domain environments. The <i class="parameter"><tt>idmap uid</tt></i> and <i class="parameter"><tt>idmap gid</tt></i> ranges must be specified. </p><p> <a class="indexterm" name="id2539949"></a> <a class="indexterm" name="id2539955"></a> The idmap_rid facility can be used both for NT4/Samba style domains as well as with Active Directory. To use this with an NT4 Domain the <i class="parameter"><tt>realm</tt></i> is not used, additionally the method used to join the domain uses the <tt class="constant">net rpc join</tt> process. </p><p> An example <tt class="filename">smb.conf</tt> file for and ADS domain environment is shown here: </p><pre class="screen"> # 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" </pre><p> </p><p> <a class="indexterm" name="id2540004"></a> <a class="indexterm" name="id2540011"></a> <a class="indexterm" name="id2540018"></a> <a class="indexterm" name="id2540025"></a> In a large domain with many users it is imperative to disable enumeration of users and groups. For examplem, at a site that has 22,000 users in Active Directory the winbind based user and group resolution is unavailable for nearly 12 minutes following first start-up of <span><b class="command">winbind</b></span>. Disabling of such enumeration resulted in instantaneous response. The disabling of user and group enumeration means that it will not be possible to list users or groups using the <span><b class="command">getent passwd</b></span> and <span><b class="command">getent group</b></span> commands. It will be possible to perform the lookup for individual users, as shown in the procedure below. </p><p> <a class="indexterm" name="id2540063"></a> <a class="indexterm" name="id2540069"></a> The use of this tool requires configuration of NSS as per the native use of winbind. Edit the <tt class="filename">/etc/nsswitch.conf</tt> so it has the following parameters: </p><pre class="screen"> ... passwd: files winbind shadow: files winbind group: files winbind ... hosts: files wins ... </pre><p> </p><p> The following procedure can be used to utilize the idmap_rid facility: </p><div class="procedure"><ol type="1"><li><p> Create or install and <tt class="filename">smb.conf</tt> file with the above configuration. </p></li><li><p> Edit the <tt class="filename">/etc/nsswitch.conf</tt> file as shown above. </p></li><li><p> Execute: </p><pre class="screen"> <tt class="prompt">root# </tt> net ads join -UAdministrator%password Using short domain name -- KPAK Joined 'BIGJOE' to realm 'CORP.KPAK.COM' </pre><p> </p><p> <a class="indexterm" name="id2540149"></a> An invalid or failed join can be detected by executing: </p><pre class="screen"> <tt class="prompt">root# </tt> net ads testjoin BIGJOE$@'s password: [2004/11/05 16:53:03, 0] utils/net_ads.c:ads_startup(186) ads_connect: No results returned Join to domain is not valid </pre><p> The specific error message may differ from the above as it depends on the type of failure that may have occured. Increase the <i class="parameter"><tt>log level</tt></i> to 10, repeat the above test and then examine the log files produced to identify the nature of the failure. </p></li><li><p> Start the <span><b class="command">nmbd, winbind,</b></span> and <span><b class="command">smbd</b></span> daemons in the order shown. </p></li><li><p> Validate the operation of this configuration by executing: <a class="indexterm" name="id2540208"></a> </p><pre class="screen"> <tt class="prompt">root# </tt> getent passwd administrator administrator:x:1000:1013:Administrator:/home/BE/administrator:/bin/bash </pre><p> </p></li></ol></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2540230"></a>IDMAP Storage in LDAP using Winbind</h3></div></div><div></div></div><p> <a class="indexterm" name="id2540238"></a> <a class="indexterm" name="id2540245"></a> The storage of IDMAP information in LDAP can be used with both NT4/Samba-3 style domains as well as with ADS domains. OpenLDAP is a commonly used LDAP server for this purpose, although any standards complying LDAP server can be used. It is therefore possible to deploy this IDMAP configuration using the Sun iPlanet LDAP server, Novell eDirectory, Microsoft ADS plus ADAM, and so on. </p><p> The following example is for an ADS style domain: </p><p> </p><pre class="screen"> # Global parameters [global] workgroup = SNOWSHOW netbios name = GOODELF realm = SNOWSHOW.COM server string = Samba Server security = ADS log level = 1 ads:10 auth:10 sam:10 rpc:10 ldap admin dn = cn=Manager,dc=SNOWSHOW,dc=COM ldap idmap suffix = ou=Idmap ldap suffix = dc=SNOWSHOW,dc=COM idmap backend = ldap:ldap://ldap.snowshow.com idmap uid = 150000-550000 idmap gid = 150000-550000 template shell = /bin/bash winbind use default domain = Yes </pre><p> </p><p> <a class="indexterm" name="id2540284"></a> In the case of an NT4 or Samba-3 style Domain the <i class="parameter"><tt>realm</tt></i> is not used and the command used to join the domain is: <span><b class="command">net rpc join</b></span>. The above example also demonstrates advanced error reporting techniques that are documented in <a href="bugreport.html#dbglvl" title="Debug Levels">the chapter called Reporting Bugs</a>. </p><p> <a class="indexterm" name="id2540318"></a> <a class="indexterm" name="id2540325"></a> <a class="indexterm" name="id2540332"></a> Where MIT kerberos is installed (version 1.3.4 or later) edit the <tt class="filename">/etc/krb5.conf</tt> file so it has the following contents: </p><pre class="screen"> [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = SNOWSHOW.COM dns_lookup_realm = false dns_lookup_kdc = true [appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false } </pre><p> </p><p> Where Heimdal kerberos is installed edit the <tt class="filename">/etc/krb5.conf</tt> file so it is either empty (i.e.: no contents) or it has the following contents: </p><pre class="screen"> [libdefaults] default_realm = SNOWSHOW.COM clockskew = 300 [realms] SNOWSHOW.COM = { kdc = ADSDC.SHOWSHOW.COM } [domain_realm] .snowshow.com = SNOWSHOW.COM </pre><p> </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> Samba can not use the Heimdal libraries if there is no <tt class="filename">/etc/krb5.conf</tt> file. So long as there is an empty file the Heimdal kerberos libraries will be usable. There is no need to specify any settings as Samba using the Heimdal libraries can figure this out automatically. </p></div><p> Edit the NSS control file <tt class="filename">/etc/nsswitch.conf</tt> so it has the following entries: </p><pre class="screen"> ... passwd: files ldap shadow: files ldap group: files ldap ... hosts: files wins ... </pre><p> </p><p> <a class="indexterm" name="id2540415"></a> <a class="indexterm" name="id2540422"></a> You will need the <a href="http://www.padl.com" target="_top">PADL</a> <span><b class="command">nss_ldap</b></span> tool set for this solution. Configure the <tt class="filename">/etc/ldap.conf</tt> file so it has the information needed. The following is an example of a working file: </p><pre class="screen"> host 192.168.2.1 base dc=snowshow,dc=com binddn cn=Manager,dc=snowshow,dc=com bindpw not24get pam_password exop nss_base_passwd ou=People,dc=snowshow,dc=com?one nss_base_shadow ou=People,dc=snowshow,dc=com?one nss_base_group ou=Groups,dc=snowshow,dc=com?one ssl no </pre><p> </p><p> The following procedure may be followed to affect a working configuration: </p><div class="procedure"><ol type="1"><li><p> Configure the <tt class="filename">smb.conf</tt> file as shown above. </p></li><li><p> Create the <tt class="filename">/etc/krb5.conf</tt> file following the indications above. </p></li><li><p> Configure the <tt class="filename">/etc/nsswitch.conf</tt> file as shown above. </p></li><li><p> Download, build and install the PADL nss_ldap tool set. Configure the <tt class="filename">/etc/ldap.conf</tt> file as shown above. </p></li><li><p> Configure an LDAP server, initialize the directory with the top level entries needed by IDMAP as shown in the following LDIF file: </p><pre class="screen"> dn: dc=snowshow,dc=com objectClass: dcObject objectClass: organization dc: snowshow o: The Greatest Snow Show in Singapore. description: Posix and Samba LDAP Identity Database dn: cn=Manager,dc=snowshow,dc=com objectClass: organizationalRole cn: Manager description: Directory Manager dn: ou=Idmap,dc=snowshow,dc=com objectClass: organizationalUnit ou: idmap </pre><p> </p></li><li><p> Execute the command to join the Samba Domain Member Server to the ADS domain as shown here: </p><pre class="screen"> <tt class="prompt">root# </tt> net ads testjoin Using short domain name -- SNOWSHOW Joined 'GOODELF' to realm 'SNOWSHOW.COM' </pre><p> </p></li><li><p> Start the <span><b class="command">nmbd, winbind,</b></span> and <span><b class="command">smbd</b></span> daemons in the order shown. </p></li></ol></div><p> <a class="indexterm" name="id2540587"></a> 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. </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2540600"></a>IDMAP and NSS Using LDAP From ADS with RFC2307bis Schema Extension</h3></div></div><div></div></div><p> <a class="indexterm" name="id2540608"></a> <a class="indexterm" name="id2540615"></a> The use of this method is messy. The information provided in the following is for guidance only and is very definitely not complete. This method does work; it is used in a number of large sites and has an acceptable level of performance. </p><p> The following is an example <tt class="filename">smb.conf</tt> file: </p><pre class="screen"> # Global parameters [global] workgroup = BOBBY realm = BOBBY.COM security = ADS idmap uid = 150000-550000 idmap gid = 150000-550000 template shell = /bin/bash winbind cache time = 5 winbind use default domain = Yes winbind trusted domains only = Yes winbind nested groups = Yes </pre><p> </p><p> <a class="indexterm" name="id2540651"></a> The DMS must be joined to the domain using the usual procedure. Additionally, it is necessary to build and install the PADL nss_ldap tool set. Be sure to build this tool set with the following: </p><pre class="screen"> ./configure --enable-rfc2307bis --enable-schema-mapping make install </pre><p> </p><p> <a class="indexterm" name="id2540671"></a> The following <tt class="filename">/etc/nsswitch.conf</tt> file contents are required: </p><pre class="screen"> ... passwd: files ldap shadow: files ldap group: files ldap ... hosts: files wins ... </pre><p> </p><p> <a class="indexterm" name="id2540696"></a> <a class="indexterm" name="id2540702"></a> The <tt class="filename">/etc/ldap.conf</tt> file must be configured also. Refer to the PADL documentation and source code for nss_ldap to specific instructions. </p><p> The next step involves preparation on the ADS schema. This is briefly discussed in the remaining part of this chapter. </p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2540724"></a>IDMAP, Active Directory and MS Services for UNIX 3.5</h4></div></div><div></div></div><p> <a class="indexterm" name="id2540732"></a> The Microsoft Windows Service for UNIX (SFU) version 3.5 is available for free <a href="http://www.microsoft.com/windows/sfu/" target="_top">download</a> from the Microsoft Web site. You will need to download this tool and install it following Microsoft instructions. </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2540751"></a>IDMAP, Active Directory and AD4UNIX</h4></div></div><div></div></div><p> Instructions for obtaining and installing the AD4UNIX tool set can be found from the <a href="http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?LDAP01/An_Alternative_Approach" target="_top"> Geekcomix</a> web site. </p></div></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="groupmapping.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="optional.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="AccessControls.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 11. Group Mapping MS Windows and UNIX </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 13. File, Directory and Share Access Controls</td></tr></table></div></body></html>