diff options
Diffstat (limited to 'docs/Samba3-HOWTO/TOSHARG-IDMAP.xml')
| -rw-r--r-- | docs/Samba3-HOWTO/TOSHARG-IDMAP.xml | 985 |
1 files changed, 985 insertions, 0 deletions
diff --git a/docs/Samba3-HOWTO/TOSHARG-IDMAP.xml b/docs/Samba3-HOWTO/TOSHARG-IDMAP.xml new file mode 100644 index 0000000000..0ea50280a7 --- /dev/null +++ b/docs/Samba3-HOWTO/TOSHARG-IDMAP.xml @@ -0,0 +1,985 @@ +<?xml version="1.0" encoding="iso-8859-1"?> +<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc"> +<chapter id="idmapper"> +<chapterinfo> + &author.jht; +</chapterinfo> + +<title>Identity Mapping (IDMAP)</title> + +<para> +<indexterm><primary>Windows</primary></indexterm> +<indexterm><primary>interoperability</primary></indexterm> +<indexterm><primary>IDMAP</primary></indexterm> +<indexterm><primary>Windows Security Identifiers</primary><see>SID</see></indexterm> +<indexterm><primary>SID</primary></indexterm> +<indexterm><primary>UID</primary></indexterm> +<indexterm><primary>GID</primary></indexterm> +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. +</para> + +<para> +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. +</para> + +<para> +<indexterm><primary>network client</primary></indexterm> +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. +</para> + +<para> +<indexterm><primary>one domain</primary></indexterm> +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. +</para> + +<para> +<indexterm><primary>winbindd</primary></indexterm> +The use of the IDMAP facility requires that the <command>winbindd</command> be executed on Samba start-up. +</para> + +<sect1> +<title>Samba Server Deployment Types and IDMAP</title> + +<para> +<indexterm><primary>Server Types</primary></indexterm> +There are four (4) basic server deployment types, as documented in <link linkend="ServerType">the chapter +on Server Types and Security Modes</link>. +</para> + + <sect2> + <title>Stand-Alone Samba Server</title> + + <para> + <indexterm><primary>stand-alone server</primary></indexterm> + <indexterm><primary>Active Directory</primary></indexterm> + <indexterm><primary>NT4 Domain</primary></indexterm> + 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. + </para> + + <para> + <indexterm><primary>IDMAP</primary></indexterm> + <indexterm><primary>identity</primary></indexterm> + 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. + </para> + + </sect2> + + <sect2> + <title>Domain Member Server or Domain Member Client</title> + + <para> + <indexterm><primary>PDC</primary></indexterm> + <indexterm><primary>BDC</primary></indexterm> + <indexterm><primary>NT4</primary></indexterm> + <indexterm><primary>SID</primary></indexterm> + <indexterm><primary>Active Directory</primary></indexterm> + 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). + </para> + + <para> + <indexterm><primary>MS Windows SID</primary></indexterm> + <indexterm><primary>UID</primary></indexterm> + <indexterm><primary>GID</primary></indexterm> + 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. + </para> + + <para> + <indexterm><primary>ADS</primary></indexterm> + <indexterm><primary>winbind</primary></indexterm> + 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 <command>winbindd</command> daemon is used, and how the winbind functionality is configured. + The configuration options are briefly described here: + </para> + + <variablelist> + <varlistentry><term>Winbind is not used, users and groups are local: &smbmdash; </term> + <listitem> + <para> + Where <command>winbindd</command> is not used Samba (<command>smbd</command>) + 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 <quote>users and groups are local</quote> + we are implying that they are stored only on the local system, in the + <filename>/etc/passwd</filename> and <filename>/etc/group</filename> respectively. + </para> + + <para> + For example, if an incoming SessionSetupAndX request is owned by the user + <constant>BERYLIUM\WambatW</constant>, a system call will be made to look up + the user <constant>WambatW</constant> in the <filename>/etc/passwd</filename> + file. + </para> + + <para> + 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. + </para> + </listitem> + </varlistentry> + + <varlistentry><term>Winbind is not used, users and groups resolved via NSS: &smbmdash; </term> + <listitem> + <para> + 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. + </para> + + <para> + 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. + </para> + </listitem> + </varlistentry> + + <varlistentry><term>Winbind/NSS with the default local IDMAP table: &smbmdash; </term> + <listitem> + <para> + 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. + </para> + + <para> + 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 &smb.conf; file, the + <filename>/etc/nsswitch.conf</filename> file is configured to use <command>winbind</command> + 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. + </para> + + <para> + 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. + </para> + </listitem> + </varlistentry> + + <varlistentry><term>Winbind/NSS uses RID based IDMAP: &smbmdash; </term> + <listitem> + <para> + <indexterm><primary>RID</primary></indexterm> + <indexterm><primary>idmap_rid</primary></indexterm> + <indexterm><primary>ADS</primary></indexterm> + <indexterm><primary>LDAP</primary></indexterm> + 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. + </para> + + <para> + <indexterm><primary>idmap_rid</primary></indexterm> + <indexterm><primary>idmap uid</primary></indexterm> + <indexterm><primary>idmap gid</primary></indexterm> + <indexterm><primary>RID</primary></indexterm> + <indexterm><primary>SID</primary></indexterm> + <indexterm><primary>UID</primary></indexterm> + <indexterm><primary>idmap backend</primary></indexterm> + This facility requires the allocation of the <parameter>idmap uid</parameter> and the + <parameter>idmap gid</parameter> ranges, and within the <parameter>idmap uid</parameter> + 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 <parameter>idmap uid</parameter> range is <constant>1000-100000000</constant> + and the <parameter>idmap backend = idmap_rid:DOMAIN_NAME=1000-50000000</parameter>, and + a SID is encountered that has the value <constant>S-1-5-21-34567898-12529001-32973135-1234</constant>, + the resulting UID will be <constant>1000 + 1234 = 2234</constant>. + </para> + </listitem> + </varlistentry> + + <varlistentry><term>Winbind with an NSS/LDAP backend based IDMAP facility: &smbmdash; </term> + <listitem> + <para> + <indexterm><primary>Domain Member</primary></indexterm> + In this configuration <command>winbind</command> resolved SIDs to UIDs and GIDs from + the <parameter>idmap uid</parameter> and <parameter>idmap gid</parameter> 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. + </para> + + <para> + <indexterm><primary>idmap backend</primary></indexterm> + It is important that all LDAP IDMAP clients use only the master LDAP server as the + <parameter>idmap backend</parameter> facility in the &smb.conf; file does not correctly + handle LDAP redirects. + </para> + </listitem> + </varlistentry> + + <varlistentry><term>Winbind with NSS to resolve UNIX/Linux user and group IDs: &smbmdash; </term> + <listitem> + <para> + The use of LDAP as the passdb backend is a smart solution for PDC, BDC as well as for + Domain Member servers. It is a neat method for assuring that UIDs, GIDs and the matching + SIDs will be consistent across all servers. + </para> + + <para> + <indexterm><primary>LDAP</primary></indexterm> + <indexterm><primary>PADL</primary></indexterm> + 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. + </para> + + <para> + <indexterm><primary>nss_ldap</primary></indexterm> + <indexterm><primary>AD4UNIX</primary></indexterm> + <indexterm><primary>MMC</primary></indexterm> + 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. + </para> + </listitem> + </varlistentry> + + </variablelist> + + </sect2> + + <sect2> + <title>Primary Domain Controller</title> + + <para> + <indexterm><primary>domain security</primary></indexterm> + <indexterm><primary>SID</primary></indexterm> + <indexterm><primary>RID</primary></indexterm> + <indexterm><primary>algorithmic mapping</primary></indexterm> + 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 &smb.conf; file, plus twice (2X) the UID or GID. This method is called <quote>algorithmic mapping</quote>. + </para> + + <para> + <indexterm><primary>RID base</primary></indexterm> + For example, a user has a UID of 4321, and the algorithmic RID base has a value of 1000, the RID will + be <constant>1000 + (2 x 4321) = 9642</constant>. Thus, if the domain SID is + <constant>S-1-5-21-89238497-92787123-12341112</constant>, the resulting SID is + <constant>S-1-5-21-89238497-92787123-12341112-9642</constant>. + </para> + + <para> + <indexterm><primary>on-the-fly</primary></indexterm> + 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 <parameter>passdb backend = [tdbsam | smbpasswd]</parameter>, or may be stored + as a permanent part of an account in an LDAP based ldapsam. + </para> + + <para> + <indexterm><primary>SFU 3.5</primary></indexterm> + 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. + </para> + + <para> + <indexterm><primary>PDC</primary></indexterm> + 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. + </para> + + </sect2> + + <sect2> + <title>Backup Domain Controller</title> + + <para> + <indexterm><primary>BDC</primary></indexterm> + 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. + </para> + + <para> + 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. + </para> + + </sect2> + +</sect1> + +<sect1> +<title>Examples of IDMAP Backend Usage</title> + +<para> +<indexterm><primary>Domain Member Server</primary><see>DMS</see></indexterm> +<indexterm><primary>Domain Member Client</primary><see>DMC</see></indexterm> +<indexterm><primary>DMS</primary></indexterm> +<indexterm><primary>DMC</primary></indexterm> +Anyone who wishes to use <command>winbind</command> will find the following example configurations helpful. +Remember that in the majority of cases <command>winbind</command> is of primary interest for use with +Domain Member Servers (DMSs) and Domain Member Clients (DMCs). +</para> + + <sect2> + <title>Default Winbind TDB</title> + + <para> + Two common configurations are used: + </para> + + <itemizedlist> + <listitem><para> + Networks that have an NT4 PDC (with or without BDCs) or a Samba PDC (with or without BDCs). + </para></listitem> + + <listitem><para> + Networks that use MS Windows 200X ADS. + </para></listitem> + </itemizedlist> + + <sect3> + <title>NT4 Style Domains (includes Samba Domains)</title> + + <para> + The following is a simple example of an NT4 DMS &smb.conf; file that shows only the global section. +<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 +</screen> + </para> + + <para> + <indexterm><primary>winbind</primary></indexterm> + <indexterm><primary>/etc/nsswitch.conf</primary></indexterm> + The use of <command>winbind</command> requires configuration of NSS. Edit the <filename>/etc/nsswitch.conf</filename> + so it includes the following entries: +<screen> +... +passwd: files winbind +shadow: files winbind +group: files winbind +... +hosts: files wins +... +</screen> + </para> + + <para> + The creation of the DMS requires the following steps: + </para> + + <procedure> + <step><para> + Create or install and &smb.conf; file with the above configuration. + </para></step> + + <step><para> + Execute: +<screen> +&rootprompt; net rpc join -UAdministrator%password +Joined domain MEGANET2. +</screen> + <indexterm><primary>join</primary></indexterm> + The success or failure of the join can be confirmed with the following command: +<screen> +&rootprompt; net rpc testjoin +Join to 'MIDEARTH' is OK +</screen> + A failed join would report an error message like the following: + <indexterm><primary>failed join</primary></indexterm> +<screen> +&rootprompt; 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 +</screen> + </para></step> + + <step><para> + Start the <command>nmbd, winbind,</command> and <command>smbd</command> daemons in the order shown. + </para></step> + </procedure> + + </sect3> + + <sect3> + <title>ADS Domains</title> + + <para> + <indexterm><primary>domain join</primary></indexterm> + The procedure for joining and ADS domain is similar to the NT4 domain join, except the &smb.conf; file + will have the following contents: +<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" +</screen> + </para> + + <para> + <indexterm><primary>KRB</primary></indexterm> + <indexterm><primary>kerberos</primary></indexterm> + <indexterm><primary>/etc/krb5.conf</primary></indexterm> + <indexterm><primary>MIT</primary></indexterm> + <indexterm><primary>MIT kerberos</primary></indexterm> + <indexterm><primary>Heimdal</primary></indexterm> + <indexterm><primary>Heimdal kerberos</primary></indexterm> + ADS DMS operation requires use of kerberos (KRB). For this to work the <filename>krb5.conf</filename> + 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. + </para> + + <para> + The creation of the DMS requires the following steps: + </para> + + <procedure> + <step><para> + Create or install and &smb.conf; file with the above configuration. + </para></step> + + <step><para> + Edit the <filename>/etc/nsswitch.conf</filename> file as shown above. + </para></step> + + <step><para> + Execute: + <indexterm><primary>net ads join</primary></indexterm> +<screen> +&rootprompt; net ads join -UAdministrator%password +Joined domain BUTTERNET. +</screen> + The success or failure of the join can be confirmed with the following command: +<screen> +&rootprompt; net ads testjoin +Using short domain name -- BUTTERNET +Joined 'GARGOYLE' to realm 'BUTTERNET.BIZ' +</screen> + </para> + + <para> + An invalid or failed join can be detected by executing: +<screen> +&rootprompt; 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 +</screen> + <indexterm><primary>error message</primary></indexterm> + The specific error message may differ from the above as it depends on the type of failure that + may have occured. Increase the <parameter>log level</parameter> to 10, repeat the above test + and then examine the log files produced to identify the nature of the failure. + </para></step> + + <step><para> + Start the <command>nmbd, winbind,</command> and <command>smbd</command> daemons in the order shown. + </para></step> + + </procedure> + + </sect3> + </sect2> + + <sect2> + <title>IDMAP_RID with Winbind</title> + + <para> + <indexterm><primary>idmap_rid</primary></indexterm> + <indexterm><primary>SID</primary></indexterm> + <indexterm><primary>RID</primary></indexterm> + <indexterm><primary>IDMAP</primary></indexterm> + The <command>idmap_rid</command> 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. + </para> + + <para> + <indexterm><primary>SID</primary></indexterm> + <indexterm><primary>allow trusted domains</primary></indexterm> + <indexterm><primary>idmap uid</primary></indexterm> + <indexterm><primary>idmap gid</primary></indexterm> + 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 + <quote>allow trusted domains = No</quote> must be specified, as it is not compatible + with multiple domain environments. The <parameter>idmap uid</parameter> and + <parameter>idmap gid</parameter> ranges must be specified. + </para> + + <para> + <indexterm><primary>idmap_rid</primary></indexterm> + <indexterm><primary>realm</primary></indexterm> + 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 <parameter>realm</parameter> is not used, additionally the + method used to join the domain uses the <constant>net rpc join</constant> process. + </para> + + <para> + An example &smb.conf; file for and ADS domain environment is shown here: +<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" +</screen> + </para> + + <para> + <indexterm><primary>large domain</primary></indexterm> + <indexterm><primary>Active Directory</primary></indexterm> + <indexterm><primary>response</primary></indexterm> + <indexterm><primary>getent</primary></indexterm> + 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 + <command>winbind</command>. 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 <command>getent passwd</command> and <command>getent group</command> + commands. It will be possible to perform the lookup for individual users, as shown in the procedure + below. + </para> + + <para> + <indexterm><primary>NSS</primary></indexterm> + <indexterm><primary>/etc/nsswitch.conf</primary></indexterm> + The use of this tool requires configuration of NSS as per the native use of winbind. Edit the + <filename>/etc/nsswitch.conf</filename> so it has the following parameters: +<screen> +... +passwd: files winbind +shadow: files winbind +group: files winbind +... +hosts: files wins +... +</screen> + </para> + + <para> + The following procedure can be used to utilize the idmap_rid facility: + </para> + + <procedure> + <step><para> + Create or install and &smb.conf; file with the above configuration. + </para></step> + + <step><para> + Edit the <filename>/etc/nsswitch.conf</filename> file as shown above. + </para></step> + + <step><para> + Execute: +<screen> +&rootprompt; net ads join -UAdministrator%password +Using short domain name -- KPAK +Joined 'BIGJOE' to realm 'CORP.KPAK.COM' +</screen> + </para> + + <para> + <indexterm><primary>failed join</primary></indexterm> + An invalid or failed join can be detected by executing: +<screen> +&rootprompt; 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 +</screen> + The specific error message may differ from the above as it depends on the type of failure that + may have occured. Increase the <parameter>log level</parameter> to 10, repeat the above test + and then examine the log files produced to identify the nature of the failure. + </para></step> + + <step><para> + Start the <command>nmbd, winbind,</command> and <command>smbd</command> daemons in the order shown. + </para></step> + + <step><para> + Validate the operation of this configuration by executing: + <indexterm><primary></primary></indexterm> +<screen> +&rootprompt; getent passwd administrator +administrator:x:1000:1013:Administrator:/home/BE/administrator:/bin/bash +</screen> + </para></step> + </procedure> + + </sect2> + + <sect2> + <title>IDMAP Storage in LDAP using Winbind</title> + + <para> + <indexterm><primary>ADAM</primary></indexterm> + <indexterm><primary>ADS</primary></indexterm> + 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. + </para> + + <para> + The following example is for an ADS style domain: + </para> + + <para> +<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 +</screen> + </para> + + <para> + <indexterm><primary>realm</primary></indexterm> + In the case of an NT4 or Samba-3 style Domain the <parameter>realm</parameter> is not used and the + command used to join the domain is: <command>net rpc join</command>. The above example also demonstrates + advanced error reporting techniques that are documented in <link linkend="dbglvl">the chapter called + Reporting Bugs</link>. + </para> + + <para> + <indexterm><primary>MIT kerberos</primary></indexterm> + <indexterm><primary>Heimdal kerberos</primary></indexterm> + <indexterm><primary>/etc/krb5.conf</primary></indexterm> + Where MIT kerberos is installed (version 1.3.4 or later) edit the <filename>/etc/krb5.conf</filename> + file so it has the following contents: +<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 + } +</screen> + </para> + + <para> + Where Heimdal kerberos is installed edit the <filename>/etc/krb5.conf</filename> + file so it is either empty (i.e.: no contents) or it has the following contents: +<screen> +[libdefaults] + default_realm = SNOWSHOW.COM + clockskew = 300 + +[realms] + SNOWSHOW.COM = { + kdc = ADSDC.SHOWSHOW.COM + } + +[domain_realm] + .snowshow.com = SNOWSHOW.COM +</screen> + </para> + + <note><para> + Samba can not use the Heimdal libraries if there is no <filename>/etc/krb5.conf</filename> 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. + </para></note> + + <para> + Edit the NSS control file <filename>/etc/nsswitch.conf</filename> so it has the following entries: +<screen> +... +passwd: files ldap +shadow: files ldap +group: files ldap +... +hosts: files wins +... +</screen> + </para> + + <para> + <indexterm><primary>PADL</primary></indexterm> + <indexterm><primary>/etc/ldap.conf</primary></indexterm> + You will need the <ulink url="http://www.padl.com">PADL</ulink> <command>nss_ldap</command> + tool set for this solution. Configure the <filename>/etc/ldap.conf</filename> file so it has + the information needed. The following is an example of a working file: +<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 +</screen> + </para> + + <para> + The following procedure may be followed to affect a working configuration: + </para> + + <procedure> + <step><para> + Configure the &smb.conf; file as shown above. + </para></step> + + <step><para> + Create the <filename>/etc/krb5.conf</filename> file following the indications above. + </para></step> + + <step><para> + Configure the <filename>/etc/nsswitch.conf</filename> file as shown above. + </para></step> + + <step><para> + Download, build and install the PADL nss_ldap tool set. Configure the + <filename>/etc/ldap.conf</filename> file as shown above. + </para></step> + + <step><para> + Configure an LDAP server, initialize the directory with the top level entries needed by IDMAP + as shown in the following LDIF file: +<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 +</screen> + </para></step> + + <step><para> + Execute the command to join the Samba Domain Member Server to the ADS domain as shown here: +<screen> +&rootprompt; net ads testjoin +Using short domain name -- SNOWSHOW +Joined 'GOODELF' to realm 'SNOWSHOW.COM' +</screen> + </para></step> + + <step><para> + Store the LDAP server access password in the Samba <filename>secrets.tdb</filename> file as follows: +<screen> +&rootprompt; smbpasswd -w not24get +</screen> + </para></step> + + <step><para> + Start the <command>nmbd, winbind,</command> and <command>smbd</command> daemons in the order shown. + </para></step> + </procedure> + + <para> + <indexterm><primary>diagnostic</primary></indexterm> + 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. + </para> + + </sect2> + + <sect2> + <title>IDMAP and NSS Using LDAP From ADS with RFC2307bis Schema Extension</title> + + <para> + <indexterm><primary>rfc2307bis</primary></indexterm> + <indexterm><primary>schema</primary></indexterm> + 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. + </para> + + <para> + The following is an example &smb.conf; file: +<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 +</screen> + </para> + + <para> + <indexterm><primary>nss_ldap</primary></indexterm> + 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: +<screen> +./configure --enable-rfc2307bis --enable-schema-mapping +make install +</screen> + </para> + + <para> + <indexterm><primary>/etc/nsswitch.conf</primary></indexterm> + The following <filename>/etc/nsswitch.conf</filename> file contents are required: +<screen> +... +passwd: files ldap +shadow: files ldap +group: files ldap +... +hosts: files wins +... +</screen> + </para> + + <para> + <indexterm><primary>/etc/ldap.conf</primary></indexterm> + <indexterm><primary>nss_ldap</primary></indexterm> + The <filename>/etc/ldap.conf</filename> file must be configured also. Refer to the PADL documentation + and source code for nss_ldap to specific instructions. + </para> + + <para> + The next step involves preparation on the ADS schema. This is briefly discussed in the remaining + part of this chapter. + </para> + + <sect3> + <title>IDMAP, Active Directory and MS Services for UNIX 3.5</title> + + <para> + <indexterm><primary>SFU</primary></indexterm> + The Microsoft Windows Service for UNIX (SFU) version 3.5 is available for free + <ulink url="http://www.microsoft.com/windows/sfu/">download</ulink> + from the Microsoft Web site. You will need to download this tool and install it following + Microsoft instructions. + </para> + + </sect3> + + <sect3> + <title>IDMAP, Active Directory and AD4UNIX</title> + + <para> + Instructions for obtaining and installing the AD4UNIX tool set can be found from the + <ulink url="http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?LDAP01/An_Alternative_Approach"> + Geekcomix</ulink> web site. + </para> + + </sect3> + + </sect2> + +</sect1> + +</chapter> |