source: vendor/3.6.23/docs-xml/Samba3-ByExample/SBE-AddingUNIXClients.xml

<?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="unixclients">
  <title>Adding Domain Member Servers and Clients</title>

    <para><indexterm>
        <primary>Open Magazine</primary>
      </indexterm><indexterm>
        <primary>survey</primary>
      </indexterm>
        The most frequently discussed Samba subjects over the past 2 years have focused around domain control and printing. 
        It is well known that Samba is a file and print server. A recent survey conducted by <emphasis>Open Magazine</emphasis> found 
        that of all respondents, 97 percent use Samba for file and print services, and 68 percent use Samba for Domain Control. See the 
        <ulink url="http://www.open-mag.com/cgi-bin/opencgi/surveys/survey.cgi?survey_name=samba">Open-Mag</ulink>
        Web site for current information. The survey results as found on January 14, 2004, are shown in
        <link linkend="ch09openmag"/>.
        </para>

        <figure id="ch09openmag">
                <title>Open Magazine Samba Survey</title>
                <imagefile scale="60">openmag</imagefile>
        </figure>

        <para>
        While domain control is an exciting subject, basic file and print sharing remains the staple bread-and-butter
        function that Samba provides. Yet this book may give the appearance of having focused too much on more
        exciting aspects of Samba deployment. This chapter directs your attention to provide important information on
        the addition of Samba servers into your present Windows network &smbmdash; whatever the controlling technology
        may be. So let's get back to our good friends at Abmas.
        </para>

<sect1>
        <title>Introduction</title>

      <para><indexterm>
          <primary>Linux desktop</primary>
        </indexterm><indexterm>
          <primary>Domain Member</primary>
          <secondary>server</secondary>
        </indexterm>
        Looking back over the achievements of the past year or two, daily events at Abmas are rather straightforward
        with not too many distractions or problems. Your team is doing well, but a number of employees
        are asking for Linux desktop systems. Your network has grown and demands additional domain member servers. Let's
        get on with this; Christine and Stan are ready to go.
        </para>

      <para><indexterm>
          <primary>Domain Member</primary>
          <secondary>desktop</secondary>
        </indexterm>
        Stan is firmly in control of the department of the future, while Christine is enjoying a stable and
        predictable network environment. It is time to add more servers and to add Linux desktops. It is
        time to meet the demands of future growth and endure trial by fire.
        </para>

        <sect2>
        <title>Assignment Tasks</title>

        <para><indexterm>
            <primary>Active Directory</primary>
          </indexterm>
        You must now add UNIX/Linux domain member servers to your network. You have a friend who has a Windows 2003
        Active Directory domain network who wants to add a Samba/Linux server and has asked Christine to help him
        out. Your real objective is to help Christine to see more of the way the Microsoft world lives and use
        her help to get validation that Samba really does live up to expectations.
        </para>

        <para>
        Over the past 6 months, you have hired several new staff who want Linux on their desktops. You must integrate
        these systems to make sure that Abmas is not building islands of technology. You ask Christine to
        do likewise at Swodniw Biz NL (your friend's company) to help them to evaluate a Linux desktop. You want to make
        the right decision, don't you?
        </para>

        </sect2>
</sect1>

<sect1>
        <title>Dissection and Discussion</title>

        <para>
        <indexterm><primary>winbind</primary></indexterm>
        Recent Samba mailing-list activity is witness to how many sites are using winbind. Some have no trouble
        at all with it, yet to others the problems seem insurmountable. Periodically there are complaints concerning
        an inability to achieve identical user and group IDs between Windows and UNIX environments.
        </para>

        <para>
        You provide step-by-step implementations of the various tools that can be used for identity
        resolution. You also provide working examples of solutions for integrated authentication for
        both UNIX/Linux and Windows environments.
        </para>

        <sect2>
                <title>Technical Issues</title>

                <para>
                One of the great challenges we face when people ask us, <quote>What is the best way to solve
                this problem?</quote> is to get beyond the facts so we not only can clearly comprehend
                the immediate technical problem, but also can understand how needs may change.
                </para>

                <para>
                <indexterm><primary>integrate</primary></indexterm>
                There are a few facts we should note when dealing with the question of how best to
                integrate UNIX/Linux clients and servers into a Windows networking environment:
                </para>

                <itemizedlist>
                        <listitem><para>
                        <indexterm><primary>Domain Controller</primary></indexterm>
                        <indexterm><primary>authoritative</primary></indexterm>
                        <indexterm><primary>accounts</primary><secondary>authoritative</secondary></indexterm>
                        <indexterm><primary>PDC</primary></indexterm>
                        <indexterm><primary>BDC</primary></indexterm>
                        A domain controller (PDC or BDC) is always authoritative for all accounts in its domain.
                        This means that a BDC must (of necessity) be able to resolve all account UIDs and GIDs
                        to the same values that the PDC resolved them to.
                        </para></listitem>

                        <listitem><para>
                        <indexterm><primary>local accounts</primary></indexterm>
                        <indexterm><primary>Domain Member</primary><secondary>authoritative</secondary><tertiary>local accounts</tertiary></indexterm>
                        <indexterm><primary>Domain accounts</primary></indexterm>
                        <indexterm><primary>winbindd</primary></indexterm>
                        A domain member can be authoritative for local accounts, but is never authoritative for
                        domain accounts. If a user is accessing a domain member server and that user's account
                        is not known locally, the domain member server must resolve the identity of that user
                        from the domain in which that user's account resides. It must then map that ID to a
                        UID/GID pair that it can use locally. This is handled by <command>winbindd</command>.
                        </para></listitem>

                        <listitem><para>
                        Samba, when running on a domain member server, can resolve user identities from a
                        number of sources:
                        </para>

                        <itemizedlist>
                                <listitem><para>
                                <indexterm><primary>getpwnam</primary></indexterm>
                                <indexterm><primary>getgrnam</primary></indexterm>
                                <indexterm><primary>NSS</primary></indexterm>
                                <indexterm><primary>LDAP</primary></indexterm>
                                <indexterm><primary>NIS</primary></indexterm>
                                By executing a system <command>getpwnam()</command> or <command>getgrnam()</command> call. 
                                On systems that support it, this utilizes the name service switch (NSS) facility to 
                                resolve names according to the configuration of the <filename>/etc/nsswitch.conf</filename> 
                                file. NSS can be configured to use LDAP, winbind, NIS, or local files.
                                </para></listitem>

                                <listitem><para>
                                <indexterm><primary>passdb backend</primary></indexterm>
                                <indexterm><primary>PADL</primary></indexterm>
                                <indexterm><primary>nss_ldap</primary></indexterm>
                                Performing, via NSS, a direct LDAP search (where an LDAP passdb backend has been configured).
                                This requires the use of the PADL nss_ldap tool (or equivalent).
                                </para></listitem>

                                <listitem><para>
                                <indexterm><primary>winbindd</primary></indexterm>
                                <indexterm><primary>SID</primary></indexterm>
                                <indexterm><primary>winbindd_idmap.tdb</primary></indexterm>
                                <indexterm><primary>winbindd_cache.tdb</primary></indexterm>
                                Directly by querying <command>winbindd</command>. The <command>winbindd</command>
                                contacts a domain controller to attempt to resolve the identity of the user or group. It
                                receives the Windows networking security identifier (SID) for that appropriate
                                account and then allocates a local UID or GID from the range of available IDs and
                                creates an entry in its <filename>winbindd_idmap.tdb</filename> and 
                                <filename>winbindd_cache.tdb</filename> files.
                                </para>

                                <para>
                                <indexterm><primary>idmap backend</primary></indexterm>
                                <indexterm><primary>mapping</primary></indexterm>
                                If the parameter <smbconfoption name="idmap backend">ldap:ldap://myserver.domain</smbconfoption>
                                was specified and the LDAP server has been configured with a container in which it may
                                store the IDMAP entries, all domain members may share a common mapping.
                                </para></listitem>
                        </itemizedlist>

                        <para>
                        Irrespective of how &smb.conf; is configured, winbind creates and caches a local copy of
                        the ID mapping database. It uses the <filename>winbindd_idmap.tdb</filename> and
                                <filename>winbindd_cache.tdb</filename> files to do this.
                        </para>

                        <para>
                        Which of the resolver methods is chosen is determined by the way that Samba is configured 
                        in the &smb.conf; file. Some of the configuration options are rather less than obvious to the 
                        casual user.
                        </para></listitem>

                        <listitem><para>
                        <indexterm><primary>winbind trusted domains only</primary></indexterm>
                        <indexterm><primary>domain member</primary><secondary>servers</secondary></indexterm>
                        <indexterm><primary>domain controllers</primary></indexterm>
                        If you wish to make use of accounts (users and/or groups) that are local to (i.e., capable
                        of being resolved using) the NSS facility, it is possible to use the 
                        <smbconfoption name="winbind trusted domains only">Yes</smbconfoption>
                        in the &smb.conf; file. This parameter specifically applies to domain controllers, 
                        and to domain member servers.
                        </para></listitem>

                </itemizedlist>

                <para>
                <indexterm><primary>Posix accounts</primary></indexterm>
                <indexterm><primary>Samba accounts</primary></indexterm>
                <indexterm><primary>LDAP</primary></indexterm>
                For many administrators, it should be plain that the use of an LDAP-based repository for all network
                accounts (both for POSIX accounts and for Samba accounts) provides the most elegant and
                controllable facility. You eventually appreciate the decision to use LDAP.
                </para>

                <para>
                <indexterm><primary>nss_ldap</primary></indexterm>
                <indexterm><primary>identifiers</primary></indexterm>
                <indexterm><primary>resolve</primary></indexterm>
                If your network account information resides in an LDAP repository, you should use it ahead of any
                alternative method. This means that if it is humanly possible to use the <command>nss_ldap</command>
                tools to resolve UNIX account UIDs/GIDs via LDAP, this is the preferred solution, because it provides
                a more readily controllable method for asserting the exact same user and group identifiers 
                throughout the network.
                </para>

                <para>
                <indexterm><primary>Domain Member</primary><secondary>server</secondary></indexterm>
                <indexterm><primary>winbind trusted domains only</primary></indexterm>
                <indexterm><primary>getpwnam</primary></indexterm>
                <indexterm><primary>smbd</primary></indexterm>
                <indexterm><primary>Trusted Domains</primary></indexterm>
                <indexterm><primary>External Domains</primary></indexterm>
                In the situation where UNIX accounts are held on the domain member server itself, the only effective
                way to use them involves the &smb.conf; entry 
                <smbconfoption name="winbind trusted domains only">Yes</smbconfoption>. This forces 
                Samba (<command>smbd</command>) to perform a <command>getpwnam()</command> system call that can
                then be controlled via <filename>/etc/nsswitch.conf</filename> file settings. The use of this parameter
                disables the use of Samba with trusted domains (i.e., external domains).
                </para>

                <para>
                <indexterm><primary>appliance mode</primary></indexterm>
                <indexterm><primary>Domain Member</primary><secondary>server</secondary></indexterm>
                <indexterm><primary>winbindd</primary></indexterm>
                <indexterm><primary>automatically allocate</primary></indexterm>
                Winbind can be used to create an appliance mode domain member server. In this capacity, <command>winbindd</command>
                is configured to automatically allocate UIDs/GIDs from numeric ranges set in the &smb.conf; file. The allocation
                is made for all accounts that connect to that domain member server, whether within its own domain or from
                trusted domains. If not stored in an LDAP backend, each domain member maintains its own unique mapping database.
                This means that it is almost certain that a given user who accesses two domain member servers does not have the
                same UID/GID on both servers &smbmdash; however, this is transparent to the Windows network user. This data
                is stored in the <filename>winbindd_idmap.tdb</filename> and <filename>winbindd_cache.tdb</filename> files.
                </para>
        
                <para>
                <indexterm><primary>mapping</primary></indexterm>
                The use of an LDAP backend for the Winbind IDMAP facility permits Windows domain SIDs
                mappings to UIDs/GIDs to be stored centrally. The result is a consistent mapping across all domain member
                servers so configured. This solves one of the major headaches for network administrators who need to copy
                files between or across network file servers.
                </para>

        </sect2>

        <sect2>
                <title>Political Issues</title>

                <para>
                <indexterm><primary>OpenLDAP</primary></indexterm>
                <indexterm><primary>NIS</primary></indexterm>
                <indexterm><primary>yellow pages</primary><see>NIS</see></indexterm>
                <indexterm><primary>identity management</primary></indexterm>
                One of the most fierce conflicts recently being waged is resistance to the adoption of LDAP, in
                particular OpenLDAP, as a replacement for UNIX NIS (previously called Yellow Pages). Let's face it, LDAP
                is different and requires a new approach to the need for a better identity management solution. The more
                you work with LDAP, the more its power and flexibility emerges from its dark, cavernous chasm.
                </para>

                <para>
                LDAP is a most suitable solution for heterogenous environments. If you need crypto, add Kerberos. 
                The reason these are preferable is because they are heterogenous. Windows solutions of this sort are <emphasis>not</emphasis> 
                heterogenous by design. This is fundamental &smbmdash; it isn't religious or political. This also doesn't say that 
                you can't use Windows Active Directory in a heterogenous environment &smbmdash; it can be done, it just requires 
                commercial integration products. But it's not what Active Directory was designed for.
                </para>

                <para>
                <indexterm><primary>directory</primary></indexterm>
                <indexterm><primary>management</primary></indexterm>
                A number of long-term UNIX devotees have recently commented in various communications that the Samba Team
                is the first application group to almost force network administrators to use LDAP. It should be pointed
                out that we resisted this for as long as we could. It is not out of laziness or malice that LDAP has
                finally emerged as the preferred identity management backend for Samba. We recommend LDAP for your total
                organizational directory needs.
                </para>

        </sect2>

</sect1>

<sect1>
        <title>Implementation</title>

        <para>
        <indexterm><primary>Domain Member</primary><secondary>server</secondary></indexterm>
        <indexterm><primary>Domain Member</primary><secondary>client</secondary></indexterm>
        <indexterm><primary>Domain Controller</primary></indexterm>
        The domain member server and the domain member client are at the center of focus in this chapter.
        Configuration of Samba-3 domain controller is covered in earlier chapters, so if your 
        interest is in domain controller configuration, you will not find that here. You will find good
        oil that helps you to add domain member servers and clients.
        </para>

        <para>
        <indexterm><primary>Domain Member</primary><secondary>workstations</secondary></indexterm>
        In practice, domain member servers and domain member workstations are very different entities, but in
        terms of technology they share similar core infrastructure. A technologist would argue that servers
        and workstations are identical. Many users would argue otherwise, given that in a well-disciplined
        environment a workstation (client) is a device from which a user creates documents and files that
        are located on servers. A workstation is frequently viewed as a disposable (easy to replace) item,
        but a server is viewed as a core component of the business.
        </para>

        <para>
        <indexterm><primary>workstation</primary></indexterm>
        We can look at this another way. If a workstation breaks down, one user is affected, but if a
        server breaks down, hundreds of users may not be able to work. The services that a workstation
        must provide are document- and file-production oriented; a server provides information storage
        and is distribution oriented.
        </para>

        <para>
        <indexterm><primary>authentication process</primary></indexterm>
        <indexterm><primary>logon process</primary></indexterm>
        <indexterm><primary>user identities</primary></indexterm>
        <emphasis>Why is this important?</emphasis> For starters, we must identify what
        components of the operating system and its environment must be configured. Also, it is necessary
        to recognize where the interdependencies between the various services to be used are.
        In particular, it is important to understand the operation of each critical part of the
        authentication process, the logon process, and how user identities get resolved and applied
        within the operating system and applications (like Samba) that depend on this and may
        actually contribute to it.
        </para>

        <para>
        So, in this chapter we demonstrate how to implement the technology. It is done within a context of
        what type of service need must be fulfilled.
        </para>

        <sect2 id="sdcsdmldap">
        <title>Samba Domain with Samba Domain Member Server &smbmdash; Using NSS LDAP</title>

        <para>
        <indexterm><primary>ldapsam</primary></indexterm>
        <indexterm><primary>ldapsam backend</primary></indexterm>
        <indexterm><primary>IDMAP</primary></indexterm>
        <indexterm><primary>mapping</primary><secondary>consistent</secondary></indexterm>
        <indexterm><primary>winbindd</primary></indexterm>
        <indexterm><primary>foreign SID</primary></indexterm>
        In this example, it is assumed that you have Samba PDC/BDC servers. This means you are using
        an LDAP ldapsam backend. We are adding to the LDAP backend database (directory)
        containers for use by the IDMAP facility. This makes it possible to have globally consistent
        mapping of SIDs to and from UIDs and GIDs. This means that it is necessary to run 
        <command>winbindd</command> as part of your configuration. The primary purpose of running
        <command>winbindd</command> (within this operational context) is to permit mapping of foreign
        SIDs (those not originating from the the local Samba server). Foreign SIDs can come from any
        domain member client or server, or from Windows clients that do not belong to a domain. Another
        way to explain the necessity to run <command>winbindd</command> is that Samba can locally
        resolve only accounts that belong to the security context of its own machine SID. Winbind
        handles all non-local SIDs and maps them to a local UID/GID value. The UID and GID are allocated
        from the parameter values set in the &smb.conf; file for the <parameter>idmap uid</parameter> and
        <parameter>idmap gid</parameter> ranges. Where LDAP is used, the mappings can be stored in LDAP
        so that all domain member servers can use a consistent mapping.
        </para>

        <para>
        <indexterm><primary>winbindd</primary></indexterm>
        <indexterm><primary>getpwnam</primary></indexterm>
        <indexterm><primary>NSS</primary></indexterm>
        If your installation is accessed only from clients that are members of your own domain, and all 
        user accounts are present in a local passdb backend then it is not necessary to run
        <command>winbindd</command>. The local passdb backend can be in smbpasswd, tdbsam, or in ldapsam.
        </para>

        <para>
        It is possible to use a local passdb backend with any convenient means of resolving the POSIX
        user and group account information. The POSIX information is usually obtained using the
        <command>getpwnam()</command> system call. On NSS-enabled systems, the actual POSIX account
        source can be provided from
        </para>

        <itemizedlist>
                <listitem><para>
                <indexterm><primary>/etc/passwd</primary></indexterm>
                <indexterm><primary>/etc/group</primary></indexterm>
                Accounts in <filename>/etc/passwd</filename> or in <filename>/etc/group</filename>.
                </para></listitem>

                <listitem><para>
                <indexterm><primary>NSS</primary></indexterm>
                <indexterm><primary>compat</primary></indexterm>
                <indexterm><primary>ldap</primary></indexterm>
                <indexterm><primary>nis</primary></indexterm>
                <indexterm><primary>nisplus</primary></indexterm>
                <indexterm><primary>hesiod</primary></indexterm>
                <indexterm><primary>ldap</primary></indexterm>
                <indexterm><primary>nss_ldap</primary></indexterm>
                <indexterm><primary>PADL Software</primary></indexterm>
                Resolution via NSS. On NSS-enabled systems, there is usually a facility to resolve IDs
                via multiple methods. The methods typically include <command>files</command>,
                <command>compat</command>, <command>db</command>, <command>ldap</command>, 
                <command>nis</command>, <command>nisplus</command>, <command>hesiod.</command>  When
                correctly installed, Samba adds to this list the <command>winbindd</command> facility.
                The ldap facility is frequently the nss_ldap tool provided by PADL Software.
                </para></listitem>
        </itemizedlist>

        <note><para>
        To advoid confusion the use of the term <literal>local passdb backend</literal> means that
        the user account backend is not shared by any other Samba server &smbmdash; instead, it is
        used only locally on the Samba domain member server under discussion.
        </para></note>

        <para>
        <indexterm><primary>Identity resolution</primary></indexterm>
        The diagram in <link linkend="ch9-sambadc"/> demonstrates the relationship of Samba and system 
        components that are involved in the identity resolution process where Samba is used as a domain
        member server within a Samba domain control network.
        </para>

<figure id="ch9-sambadc">
        <title>Samba Domain: Samba Member Server</title>
        <imagefile scale="60">chap9-SambaDC</imagefile>
</figure>

        <para>
        <indexterm><primary>IDMAP</primary></indexterm>
        <indexterm><primary>foreign</primary></indexterm>
        In this example configuration, Samba will directly search the LDAP-based passwd backend ldapsam
        to obtain authentication and user identity information. The IDMAP information is stored in the LDAP
        backend so that it can be shared by all domain member servers so that every user will have a
        consistent UID and GID across all of them. The IDMAP facility will be used for all foreign
        (i.e., not having the same SID as the domain it is a member of) domains. The configuration of 
        NSS will ensure that all UNIX processes will obtain a consistent UID/GID.
        </para>

        <para>
        The instructions given here apply to the Samba environment shown in <link linkend="happy"/> and <link linkend="net2000users"/>.
        If the network does not have an LDAP slave server (i.e., <link linkend="happy"/> configuration), 
        change the target LDAP server from <constant>lapdc</constant> to <constant>massive.</constant>
        </para>

        <procedure>
        <title>Configuration of NSS_LDAP-Based Identity Resolution</title>

                <step><para>
                Create the &smb.conf; file as shown in <link linkend="ch9-sdmsdc"/>. Locate
                this file in the directory <filename>/etc/samba</filename>.
                </para></step>

                <step><para>
                <indexterm><primary>ldap.conf</primary></indexterm>
                Configure the file that will be used by <constant>nss_ldap</constant> to
                locate and communicate with the LDAP server. This file is called <filename>ldap.conf</filename>.
                If your implementation of <constant>nss_ldap</constant> is consistent with
                the defaults suggested by PADL (the authors), it will be located in the
                <filename>/etc</filename> directory. On some systems, the default location is
                the <filename>/etc/openldap</filename> directory, however this file is intended
                for use by the OpenLDAP utilities and should not really be used by the nss_ldap
                utility since its content and structure serves the specific purpose of enabling
                the resolution of user and group IDs via NSS.
                </para>

                <para>
                Change the parameters inside the file that is located on your OS so it matches
                <link linkend="ch9-sdmlcnf"/>.  To find the correct location of this file, you
                can obtain this from the library that will be used by executing the following:
<screen>
&rootprompt; strings /lib/libnss_ldap* | grep ldap.conf
/etc/ldap.conf
</screen>
                </para></step>

                <step><para>
                Configure the NSS control file so it matches the one shown in
                <link linkend="ch9-sdmnss"/>.
                </para></step>

                <step><para>
                <indexterm><primary>Identity resolution</primary></indexterm>
                <indexterm><primary>getent</primary></indexterm>
                Before proceeding to configure Samba, validate the operation of the NSS identity 
                resolution via LDAP by executing:
<screen>
&rootprompt; getent passwd
...
root:x:0:512:Netbios Domain Administrator:/root:/bin/false
nobody:x:999:514:nobody:/dev/null:/bin/false
bobj:x:1000:513:Robert Jordan:/home/bobj:/bin/bash
stans:x:1001:513:Stanley Soroka:/home/stans:/bin/bash
chrisr:x:1002:513:Christine Roberson:/home/chrisr:/bin/bash
maryv:x:1003:513:Mary Vortexis:/home/maryv:/bin/bash
jht:x:1004:513:John H Terpstra:/home/jht:/bin/bash
bldg1$:x:1006:553:bldg1$:/dev/null:/bin/false
temptation$:x:1009:553:temptation$:/dev/null:/bin/false
vaioboss$:x:1005:553:vaioboss$:/dev/null:/bin/false
fran$:x:1008:553:fran$:/dev/null:/bin/false
josephj:x:1007:513:Joseph James:/home/josephj:/bin/bash
</screen>
                You should notice the location of the users' home directories. First, make certain that
                the home directories exist on the domain member server; otherwise, the home directory
                share is not available. The home directories could be mounted off a domain controller
                using NFS or by any other suitable means. Second, the absence of the domain name in the
                home directory path is indicative that identity resolution is not being done via winbind.
<screen>
&rootprompt; getent group
...
Domain Admins:x:512:root,jht
Domain Users:x:513:bobj,stans,chrisr,maryv,jht,josephj
Domain Guests:x:514:
Accounts:x:1000:
Finances:x:1001:
PIOps:x:1002:
sammy:x:4321:
</screen>
                <indexterm><primary>secondary group</primary></indexterm>
                <indexterm><primary>primary group</primary></indexterm>
                <indexterm><primary>group membership</primary></indexterm>
                This shows that all is working as it should be. Notice that in the LDAP database
                the users' primary and secondary group memberships are identical. It is not
                necessary to add secondary group memberships (in the group database) if the
                user is already a member via primary group membership in the password database.
                When using winbind, it is in fact undesirable to do this because it results in
                doubling up of group memberships and may cause problems with winbind under certain 
                conditions. It is intended that these limitations with winbind will be resolved soon
                after Samba-3.0.20 has been released.
                </para></step>

                <step><para>
                <indexterm><primary>slapcat</primary></indexterm>
                The LDAP directory must have a container object for IDMAP data. There are several ways you can
                check that your LDAP database is able to receive IDMAP information. One of the simplest is to
                execute:
<screen>
&rootprompt; slapcat | grep -i idmap
dn: ou=Idmap,dc=abmas,dc=biz
ou: idmap
</screen>
                <indexterm><primary>ldapadd</primary></indexterm>
                If the execution of this command does not return IDMAP entries, you need to create an LDIF
                template file (see <link linkend="ch9-ldifadd"/>). You can add the required entries using
                the following command:
<screen>
&rootprompt; ldapadd -x -D "cn=Manager,dc=abmas,dc=biz" \
                -w not24get &lt; /etc/openldap/idmap.LDIF
</screen>
                </para></step>

                <step><para>
                Samba automatically populates the LDAP directory container when it needs to. To permit Samba
                write access to the LDAP directory it is necessary to set the LDAP administrative password
                in the <filename>secrets.tdb</filename> file as shown here:
<screen>
&rootprompt; smbpasswd -w not24get
</screen>
                </para></step>

                <step><para>
                <indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm>
                <indexterm><primary>Domain join</primary></indexterm>
                The system is ready to join the domain. Execute the following:
<screen>
&rootprompt; net rpc join -U root%not24get
Joined domain MEGANET2.
</screen>
                This indicates that the domain join succeeded.
                </para>

                <para>
                Failure to join the domain could be caused by any number of variables. The most common
                causes of failure to join are:
                </para>

                <para>
                <itemizedlist>
                        <listitem><para>Broken resolution of NetBIOS names to the respective IP address.</para></listitem>
                        <listitem><para>Incorrect username and password credentials.</para></listitem>
                        <listitem><para>The NT4 <parameter>restrict anonymous</parameter> is set to exclude anonymous
                                connections.</para></listitem>
                </itemizedlist> 
                </para>

                <para>
                The connection setup can be diagnosed by executing:
<screen>
&rootprompt; net rpc join -S 'pdc-name' -U administrator%password -d 5
</screen>
                <indexterm><primary>failed</primary></indexterm>
                <indexterm><primary>failed join</primary></indexterm>
                <indexterm><primary>rejected</primary></indexterm>
                <indexterm><primary>restrict anonymous</primary></indexterm>
                Note: Use "root" for UNIX/Linux and Samba, use "Administrator" for Windows NT4/200X. If the cause of
                the failure appears to be related to a rejected or failed NT_SESSION_SETUP*  or an error message that
                says NT_STATUS_ACCESS_DENIED immediately check the Windows registry setting that controls the
                <constant>restrict anonymous</constant> setting. Set this to the value 0 so that an anonymous connection
                can be sustained, then try again.
                </para>

                <para>
                It is possible (perhaps even recommended) to use the following to validate the ability to connect
                to an NT4 PDC/BDC:
<screen>
&rootprompt; net rpc info -S 'pdc-name' -U Administrator%not24get
Domain Name: MEGANET2
Domain SID: S-1-5-21-422319763-4138913805-7168186429
Sequence number: 1519909596
Num users: 7003
Num domain groups: 821
Num local groups: 8

&rootprompt; net rpc testjoin -S 'pdc-name' -U Administrator%not24get
Join to 'MEGANET2' is OK
</screen>
                If for any reason the following response is obtained to the last command above,it is time to
                call in the Networking Super-Snooper task force (i.e., start debugging):
<screen>
NT_STATUS_ACCESS_DENIED
Join to 'MEGANET2' failed.
</screen>
                </para></step>

                <step><para>
                <indexterm><primary>wbinfo</primary></indexterm>
                Just joining the domain is not quite enough; you must now provide a privileged set
                of credentials through which <command>winbindd</command> can interact with the 
                domain servers. Execute the following to implant the necessary credentials:
<screen>
&rootprompt; wbinfo --set-auth-user=Administrator%not24get
</screen>
                The configuration is now ready to obtain the Samba domain user and group information.
                </para></step>

                <step><para>
                You may now start Samba in the usual manner, and your Samba domain member server
                is ready for use. Just add shares as required.
                </para></step>

        </procedure>

<example id="ch9-sdmsdc">
<title>Samba Domain Member in Samba Domain Using LDAP &smbmdash; &smb.conf; File</title>
<smbconfblock>
<smbconfcomment>Global parameters</smbconfcomment>
<smbconfsection name="[global]"/>
<smbconfoption name="unix charset">LOCALE</smbconfoption>
<smbconfoption name="workgroup">MEGANET2</smbconfoption>
<smbconfoption name="security">DOMAIN</smbconfoption>
<smbconfoption name="username map">/etc/samba/smbusers</smbconfoption>
<smbconfoption name="log level">10</smbconfoption>
<smbconfoption name="syslog">0</smbconfoption>
<smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
<smbconfoption name="max log size">50</smbconfoption>
<smbconfoption name="smb ports">139</smbconfoption>
<smbconfoption name="name resolve order">wins bcast hosts</smbconfoption>
<smbconfoption name="printcap name">CUPS</smbconfoption>
<smbconfoption name="wins server">192.168.2.1</smbconfoption>
<smbconfoption name="ldap suffix">dc=abmas,dc=biz</smbconfoption>
<smbconfoption name="ldap machine suffix">ou=People</smbconfoption>
<smbconfoption name="ldap user suffix">ou=People</smbconfoption>
<smbconfoption name="ldap group suffix">ou=Groups</smbconfoption>
<smbconfoption name="ldap idmap suffix">ou=Idmap</smbconfoption>
<smbconfoption name="ldap admin dn">cn=Manager,dc=abmas,dc=biz</smbconfoption>
<smbconfoption name="idmap backend">ldap:ldap://lapdc.abmas.biz</smbconfoption>
<smbconfoption name="idmap uid">10000-20000</smbconfoption>
<smbconfoption name="idmap gid">10000-20000</smbconfoption>
<smbconfoption name="winbind trusted domains only">Yes</smbconfoption>
<smbconfoption name="printer admin">root</smbconfoption>
<smbconfoption name="printing">cups</smbconfoption>

<smbconfsection name="[homes]"/>
<smbconfoption name="comment">Home Directories</smbconfoption>
<smbconfoption name="valid users">%S</smbconfoption>
<smbconfoption name="read only">No</smbconfoption>
<smbconfoption name="browseable">No</smbconfoption>

<smbconfsection name="[printers]"/>
<smbconfoption name="comment">SMB Print Spool</smbconfoption>
<smbconfoption name="path">/var/spool/samba</smbconfoption>
<smbconfoption name="guest ok">Yes</smbconfoption>
<smbconfoption name="printable">Yes</smbconfoption>
<smbconfoption name="browseable">No</smbconfoption>

<smbconfsection name="[print$]"/>
<smbconfoption name="comment">Printer Drivers</smbconfoption>
<smbconfoption name="path">/var/lib/samba/drivers</smbconfoption>
<smbconfoption name="admin users">root, Administrator</smbconfoption>
<smbconfoption name="write list">root</smbconfoption>
</smbconfblock>
</example>

<example id="ch9-ldifadd">
<title>LDIF IDMAP Add-On Load File &smbmdash; File: /etc/openldap/idmap.LDIF</title>
<screen>
dn: ou=Idmap,dc=abmas,dc=biz
objectClass: organizationalUnit
ou: idmap
structuralObjectClass: organizationalUnit
</screen>
</example>

<example id="ch9-sdmlcnf">
<title>Configuration File for NSS LDAP Support &smbmdash; <filename>/etc/ldap.conf</filename></title>
<screen>
URI     ldap://massive.abmas.biz ldap://massive.abmas.biz:636
host    192.168.2.1
base    dc=abmas,dc=biz
binddn  cn=Manager,dc=abmas,dc=biz
bindpw  not24get

pam_password exop

nss_base_passwd ou=People,dc=abmas,dc=biz?one
nss_base_shadow ou=People,dc=abmas,dc=biz?one
nss_base_group  ou=Groups,dc=abmas,dc=biz?one
ssl     no
</screen>
</example>

<example id="ch9-sdmnss">
<title>NSS using LDAP for Identity Resolution &smbmdash; File: <filename>/etc/nsswitch.conf</filename></title>
<screen>
passwd:         files ldap
shadow:         files ldap
group:          files ldap

hosts:          files dns wins
networks:       files dns

services:       files
protocols:      files
rpc:            files
ethers:         files
netmasks:       files
netgroup:       files
publickey:      files

bootparams:     files
automount:      files
aliases:        files
</screen>
</example>

        </sect2>

        <sect2 id="wdcsdm">
                <title>NT4/Samba Domain with Samba Domain Member Server: Using NSS and Winbind</title>

        <para>
        You need to use this method for creating a Samba domain member server if any of the following conditions
        prevail:
        </para>

        <itemizedlist>
                <listitem><para>
                LDAP support (client) is not installed on the system.
                </para></listitem>

                <listitem><para>
                There are mitigating circumstances forcing a decision not to use LDAP.
                </para></listitem>

                <listitem><para>
                The Samba domain member server must be part of a Windows NT4 Domain, or a Samba Domain.
                </para></listitem>
        </itemizedlist>

        <para>
        <indexterm><primary>Windows ADS Domain</primary></indexterm>
        <indexterm><primary>Samba Domain</primary></indexterm>
        <indexterm><primary>LDAP</primary></indexterm>
        Later in the chapter, you can see how to configure a Samba domain member server for a Windows ADS domain.
        Right now your objective is to configure a Samba server that can be a member of a Windows NT4-style
        domain and/or does not use LDAP.
        </para>

        <note><para>
        <indexterm><primary>duplicate accounts</primary></indexterm>
        If you use <command>winbind</command> for identity resolution, make sure that there are no
        duplicate accounts.
        </para>

        <para>
        <indexterm><primary>/etc/passwd</primary></indexterm>
        For example, do not have more than one account that has UID=0 in the password database. If there 
        is an account called <constant>root</constant> in the <filename>/etc/passwd</filename> database, 
        it is okay to have an account called <constant>root</constant> in the LDAP ldapsam or in the 
        tdbsam. But if there are two accounts in the passdb backend that have the same UID, winbind will 
        break. This means that the <constant>Administrator</constant> account must be called 
        <constant>root</constant>.
        </para>

        <para>
        <indexterm><primary>/etc/passwd</primary></indexterm>
        <indexterm><primary>ldapsam</primary></indexterm>
        <indexterm><primary>tdbsam</primary></indexterm>
        Winbind will break if there is an account in <filename>/etc/passwd</filename> that has 
        the same UID as an account that is in LDAP ldapsam (or in tdbsam) but that differs in name only.
        </para></note>

        <para>
        <indexterm><primary>credentials</primary></indexterm>
        <indexterm><primary>traverse</primary></indexterm>
        <indexterm><primary>wide-area</primary></indexterm>
        <indexterm><primary>network</primary><secondary>wide-area</secondary></indexterm>
        <indexterm><primary>tdbdump</primary></indexterm>
        The following configuration uses CIFS/SMB protocols alone to obtain user and group credentials.
        The winbind information is locally cached in the <filename>winbindd_cache.tdb winbindd_idmap.tdb</filename>
        files. This provides considerable performance benefits compared with the LDAP solution, particularly
        where the LDAP lookups must traverse WAN links. You may examine the contents of these
        files using the tool <command>tdbdump</command>, though you may have to build this from the Samba
        source code if it has not been supplied as part of a binary package distribution that you may be using.
        </para>

        <procedure>
        <title>Configuration of Winbind-Based Identity Resolution</title>

                <step><para>
                Using your favorite text editor, create the &smb.conf; file so it has the contents
                shown in <link linkend="ch0-NT4DSDM"/>.
                </para></step>

                <step><para>
                <indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
                Edit the <filename>/etc/nsswitch.conf</filename> so it has the entries shown in
                <link linkend="ch9-sdmnss"/>.
                </para></step>

                <step><para>
                <indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm>
                The system is ready to join the domain. Execute the following:
<screen>
net rpc join -U root%not2g4et
Joined domain MEGANET2.
</screen>
                This indicates that the domain join succeed.

                </para></step>

                <step><para>
                <indexterm><primary>winbind</primary></indexterm>
                <indexterm><primary>wbinfo</primary></indexterm>
                Validate operation of <command>winbind</command> using the <command>wbinfo</command>
                tool as follows:
<screen>
&rootprompt; wbinfo -u
MEGANET2+root
MEGANET2+nobody
MEGANET2+jht
MEGANET2+maryv
MEGANET2+billr
MEGANET2+jelliott
MEGANET2+dbrady
MEGANET2+joeg
MEGANET2+balap
</screen>
                This shows that domain users have been listed correctly.
<screen>
&rootprompt; wbinfo -g
MEGANET2+Domain Admins
MEGANET2+Domain Users
MEGANET2+Domain Guests
MEGANET2+Accounts
MEGANET2+Finances
MEGANET2+PIOps
</screen>
                This shows that domain groups have been correctly obtained also.
                </para></step>

                <step><para>
                <indexterm><primary>NSS</primary></indexterm>
                <indexterm><primary>getent</primary></indexterm>
                <indexterm><primary>winbind</primary></indexterm>
                The next step verifies that NSS is able to obtain this information
                correctly from <command>winbind</command> also.
<screen>
&rootprompt; getent passwd
...
MEGANET2+root:x:10000:10001:NetBIOS Domain Admin:
                      /home/MEGANET2/root:/bin/bash
MEGANET2+nobody:x:10001:10001:nobody:
                      /home/MEGANET2/nobody:/bin/bash
MEGANET2+jht:x:10002:10001:John H Terpstra:
                      /home/MEGANET2/jht:/bin/bash
MEGANET2+maryv:x:10003:10001:Mary Vortexis:
                      /home/MEGANET2/maryv:/bin/bash
MEGANET2+billr:x:10004:10001:William Randalph:
                      /home/MEGANET2/billr:/bin/bash
MEGANET2+jelliott:x:10005:10001:John G Elliott:
                      /home/MEGANET2/jelliott:/bin/bash
MEGANET2+dbrady:x:10006:10001:Darren Brady:
                      /home/MEGANET2/dbrady:/bin/bash
MEGANET2+joeg:x:10007:10001:Joe Green:
                      /home/MEGANET2/joeg:/bin/bash
MEGANET2+balap:x:10008:10001:Bala Pillay:
                      /home/MEGANET2/balap:/bin/bash
</screen>
                The user account information has been correctly obtained. This information has
                been merged with the winbind template information configured in the &smb.conf; file.
<screen>
&rootprompt;# getent group
...
MEGANET2+Domain Admins:x:10000:MEGANET2+root,MEGANET2+jht
MEGANET2+Domain Users:x:10001:MEGANET2+jht,MEGANET2+maryv,\
        MEGANET2+billr,MEGANET2+jelliott,MEGANET2+dbrady,\
        MEGANET2+joeg,MEGANET2+balap
MEGANET2+Domain Guests:x:10002:MEGANET2+nobody
MEGANET2+Accounts:x:10003:
MEGANET2+Finances:x:10004:
MEGANET2+PIOps:x:10005:
</screen>
                </para></step>

                <step><para>
                The Samba member server of a Windows NT4 domain is ready for use.
                </para></step>

        </procedure>

<example id="ch0-NT4DSDM">
<title>Samba Domain Member Server Using Winbind &smb.conf; File for NT4 Domain</title>
<smbconfblock>
<smbconfcomment>Global parameters</smbconfcomment>
<smbconfsection name="[global]"/>
<smbconfoption name="unix charset">LOCALE</smbconfoption>
<smbconfoption name="workgroup">MEGANET2</smbconfoption>
<smbconfoption name="security">DOMAIN</smbconfoption>
<smbconfoption name="username map">/etc/samba/smbusers</smbconfoption>
<smbconfoption name="log level">1</smbconfoption>
<smbconfoption name="syslog">0</smbconfoption>
<smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
<smbconfoption name="max log size">0</smbconfoption>
<smbconfoption name="smb ports">139</smbconfoption>
<smbconfoption name="name resolve order">wins bcast hosts</smbconfoption>
<smbconfoption name="printcap name">CUPS</smbconfoption>
<smbconfoption name="wins server">192.168.2.1</smbconfoption>
<smbconfoption name="idmap uid">10000-20000</smbconfoption>
<smbconfoption name="idmap gid">10000-20000</smbconfoption>
<smbconfoption name="template primary group">"Domain Users"</smbconfoption>
<smbconfoption name="template shell">/bin/bash</smbconfoption>
<smbconfoption name="winbind separator">+</smbconfoption>
<smbconfoption name="printer admin">root</smbconfoption>
<smbconfoption name="hosts allow">192.168.2., 192.168.3., 127.</smbconfoption>
<smbconfoption name="printing">cups</smbconfoption>

<smbconfsection name="[homes]"/>
<smbconfoption name="comment">Home Directories</smbconfoption>
<smbconfoption name="valid users">%S</smbconfoption>
<smbconfoption name="read only">No</smbconfoption>
<smbconfoption name="browseable">No</smbconfoption>

<smbconfsection name="[printers]"/>
<smbconfoption name="comment">SMB Print Spool</smbconfoption>
<smbconfoption name="path">/var/spool/samba</smbconfoption>
<smbconfoption name="guest ok">Yes</smbconfoption>
<smbconfoption name="printable">Yes</smbconfoption>
<smbconfoption name="browseable">No</smbconfoption>

<smbconfsection name="[print$]"/>
<smbconfoption name="comment">Printer Drivers</smbconfoption>
<smbconfoption name="path">/var/lib/samba/drivers</smbconfoption>
<smbconfoption name="admin users">root, Administrator</smbconfoption>
<smbconfoption name="write list">root</smbconfoption>
</smbconfblock>
</example>

        </sect2>

        <sect2 id="dcwonss">
        <title>NT4/Samba Domain with Samba Domain Member Server without NSS Support</title>

        <para>
        No matter how many UNIX/Linux administrators there may be who believe that a UNIX operating
        system that does not have NSS and PAM support to be outdated, the fact is there
        are still many such systems in use today. Samba can be used without NSS support, but this
        does limit it to the use of local user and group accounts only.
        </para>

        <para>
        The following steps may be followed to implement Samba with support for local accounts.
        In this configuration Samba is made a domain member server. All incoming connections
        to the Samba server will cause the look-up of the incoming username. If the account
        is found, it is used. If the account is not found, one will be automatically created
        on the local machine so that it can then be used for all access controls.
        </para>

        <procedure>
        <title>Configuration Using Local Accounts Only</title>

                <step><para>
                Using your favorite text editor, create the &smb.conf; file so it has the contents
                shown in <link linkend="ch0-NT4DSCM"/>.
                </para></step>

                <step>
                <para><indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm>
                The system is ready to join the domain. Execute the following:
<screen>
net rpc join -U root%not24get
Joined domain MEGANET2.
</screen>
                This indicates that the domain join succeed.
                </para></step>

                <step><para>
                Be sure to run all three Samba daemons: <command>smbd</command>, <command>nmbd</command>, <command>winbindd</command>.
                </para></step>

                <step><para>
                The Samba member server of a Windows NT4 domain is ready for use.
                </para></step>
        </procedure>

<example id="ch0-NT4DSCM">
<title>Samba Domain Member Server Using Local Accounts &smb.conf; File for NT4 Domain</title>
<smbconfblock>
<smbconfcomment>Global parameters</smbconfcomment>
<smbconfsection name="[global]"/>
<smbconfoption name="unix charset">LOCALE</smbconfoption>
<smbconfoption name="workgroup">MEGANET3</smbconfoption>
<smbconfoption name="netbios name">BSDBOX</smbconfoption>
<smbconfoption name="security">DOMAIN</smbconfoption>
<smbconfoption name="username map">/etc/samba/smbusers</smbconfoption>
<smbconfoption name="log level">1</smbconfoption>
<smbconfoption name="syslog">0</smbconfoption>
<smbconfoption name="add user script">/usr/sbin/useradd -m '%u'</smbconfoption>
<smbconfoption name="add machine script">/usr/sbin/useradd -M '%u'</smbconfoption>
<smbconfoption name="add group script">/usr/sbin/groupadd '%g'</smbconfoption>
<smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
<smbconfoption name="max log size">0</smbconfoption>
<smbconfoption name="smb ports">139</smbconfoption>
<smbconfoption name="name resolve order">wins bcast hosts</smbconfoption>
<smbconfoption name="printcap name">CUPS</smbconfoption>
<smbconfoption name="wins server">192.168.2.1</smbconfoption>
<smbconfoption name="printer admin">root</smbconfoption>
<smbconfoption name="hosts allow">192.168.2., 192.168.3., 127.</smbconfoption>
<smbconfoption name="printing">cups</smbconfoption>

<smbconfsection name="[homes]"/>
<smbconfoption name="comment">Home Directories</smbconfoption>
<smbconfoption name="valid users">%S</smbconfoption>
<smbconfoption name="read only">No</smbconfoption>
<smbconfoption name="browseable">No</smbconfoption>

<smbconfsection name="[printers]"/>
<smbconfoption name="comment">SMB Print Spool</smbconfoption>
<smbconfoption name="path">/var/spool/samba</smbconfoption>
<smbconfoption name="guest ok">Yes</smbconfoption>
<smbconfoption name="printable">Yes</smbconfoption>
<smbconfoption name="browseable">No</smbconfoption>

<smbconfsection name="[print$]"/>
<smbconfoption name="comment">Printer Drivers</smbconfoption>
<smbconfoption name="path">/var/lib/samba/drivers</smbconfoption>
<smbconfoption name="admin users">root, Administrator</smbconfoption>
<smbconfoption name="write list">root</smbconfoption>
</smbconfblock>
</example>
        </sect2>

        <sect2 id="adssdm">
        <title>Active Directory Domain with Samba Domain Member Server</title>

        <para>
        <indexterm><primary>Active Directory</primary><secondary>join</secondary></indexterm>
        <indexterm><primary>Kerberos</primary></indexterm>
        <indexterm><primary>Domain Member</primary><secondary>server</secondary></indexterm>
        One of the much-sought-after features new to Samba-3 is the ability to join an Active Directory
        domain using Kerberos protocols. This makes it possible to operate an entire Windows network
        without the need to run NetBIOS over TCP/IP and permits more secure networking in general. An
        exhaustively complete discussion of the protocols is not possible in this book; perhaps a
        later book may explore the intricacies of the NetBIOS-less operation that Samba-3 can participate
        in. For now, we simply focus on how a Samba-3 server can be made a domain member server.
        </para>

        <para>
        <indexterm><primary>Active Directory</primary></indexterm>
        <indexterm><primary>LDAP</primary></indexterm>
        <indexterm><primary>Identity resolution</primary></indexterm>
        <indexterm><primary>Kerberos</primary></indexterm>
        The diagram in <link linkend="ch9-adsdc"/> demonstrates how Samba-3 interfaces with
        Microsoft Active Directory components. It should be noted that if Microsoft Windows Services
        for UNIX (SFU) has been installed and correctly configured, it is possible to use client LDAP
        for identity resolution just as can be done with Samba-3 when using an LDAP passdb backend.
        The UNIX tool that you need for this, as in the case of LDAP on UNIX/Linux, is the PADL
        Software nss_ldap tool-set. Compared with use of winbind and Kerberos, the use of 
        LDAP-based identity resolution is a little less secure. In view of the fact that this solution
        requires additional software to be installed on the Windows 200x ADS domain controllers,
        and that means more management overhead, it is likely that most Samba-3 ADS client sites
        may elect to use winbind.
        </para>

        <para>
        Do not attempt to use this procedure if you are not 100 percent certain that the build of Samba-3
        you are using has been compiled and linked with all the tools necessary for this to work.
        Given the importance of this step, you must first validate that the Samba-3 message block
        daemon (<command>smbd</command>) has the necessary features.
        </para>

        <para>
        The hypothetical domain you are using in this example assumes that the Abmas London office
        decided to take its own lead (some would say this is a typical behavior in a global
        corporate world; besides, a little divergence and conflict makes for an interesting life).
        The Windows Server 2003 ADS domain is called <constant>london.abmas.biz</constant> and the
        name of the server is <constant>W2K3S</constant>. In ADS realm terms, the domain controller
        is known as <constant>w2k3s.london.abmas.biz</constant>. In NetBIOS nomenclature, the
        domain name is <constant>LONDON</constant> and the server name is <constant>W2K3S</constant>.
        </para>

        <figure id="ch9-adsdc">
                <title>Active Directory Domain: Samba Member Server</title>
                <imagefile scale="60">chap9-ADSDC</imagefile>
        </figure>

        <procedure>
        <title>Joining a Samba Server as an ADS Domain Member</title>

                <step><para>
                <indexterm><primary>smbd</primary></indexterm>
                Before you try to use Samba-3, you want to know for certain that your executables have
                support for Kerberos and for LDAP. Execute the following to identify whether or
                not this build is perhaps suitable for use:
<screen>
&rootprompt; cd /usr/sbin
&rootprompt; smbd -b | grep KRB
   HAVE_KRB5_H
   HAVE_ADDR_TYPE_IN_KRB5_ADDRESS
   HAVE_KRB5
   HAVE_KRB5_AUTH_CON_SETKEY
   HAVE_KRB5_GET_DEFAULT_IN_TKT_ETYPES
   HAVE_KRB5_GET_PW_SALT
   HAVE_KRB5_KEYBLOCK_KEYVALUE
   HAVE_KRB5_KEYTAB_ENTRY_KEYBLOCK
   HAVE_KRB5_MK_REQ_EXTENDED
   HAVE_KRB5_PRINCIPAL_GET_COMP_STRING
   HAVE_KRB5_SET_DEFAULT_IN_TKT_ETYPES
   HAVE_KRB5_STRING_TO_KEY
   HAVE_KRB5_STRING_TO_KEY_SALT
   HAVE_LIBKRB5
</screen>
                This output was obtained on a SUSE Linux system and shows the output for
                Samba that has been compiled and linked with the Heimdal Kerberos libraries.
                The following is a typical output that will be found on a Red Hat Linux system that
                has been linked with the MIT Kerberos libraries:
<screen>
&rootprompt; cd /usr/sbin
&rootprompt; smbd -b | grep KRB
   HAVE_KRB5_H
   HAVE_ADDRTYPE_IN_KRB5_ADDRESS
   HAVE_KRB5
   HAVE_KRB5_AUTH_CON_SETUSERUSERKEY
   HAVE_KRB5_ENCRYPT_DATA
   HAVE_KRB5_FREE_DATA_CONTENTS
   HAVE_KRB5_FREE_KTYPES
   HAVE_KRB5_GET_PERMITTED_ENCTYPES
   HAVE_KRB5_KEYTAB_ENTRY_KEY
   HAVE_KRB5_LOCATE_KDC
   HAVE_KRB5_MK_REQ_EXTENDED
   HAVE_KRB5_PRINCIPAL2SALT
   HAVE_KRB5_PRINC_COMPONENT
   HAVE_KRB5_SET_DEFAULT_TGS_KTYPES
   HAVE_KRB5_SET_REAL_TIME
   HAVE_KRB5_STRING_TO_KEY
   HAVE_KRB5_TKT_ENC_PART2
   HAVE_KRB5_USE_ENCTYPE
   HAVE_LIBGSSAPI_KRB5
   HAVE_LIBKRB5
</screen>
                You can validate that Samba has been compiled and linked with LDAP support
                by executing:
<screen>
&rootprompt; smbd -b | grep LDAP
massive:/usr/sbin # smbd -b | grep LDAP
   HAVE_LDAP_H
   HAVE_LDAP
   HAVE_LDAP_DOMAIN2HOSTLIST
   HAVE_LDAP_INIT
   HAVE_LDAP_INITIALIZE
   HAVE_LDAP_SET_REBIND_PROC
   HAVE_LIBLDAP
   LDAP_SET_REBIND_PROC_ARGS
</screen>
                This does look promising; <command>smbd</command> has been built with Kerberos and LDAP
                support. You are relieved to know that it is safe to progress.
                </para></step>

                <step><para>
                <indexterm><primary>Kerberos</primary><secondary>libraries</secondary></indexterm>
                <indexterm><primary>MIT Kerberos</primary></indexterm>
                <indexterm><primary>Heimdal Kerberos</primary></indexterm>
                <indexterm><primary>Kerberos</primary><secondary>MIT</secondary></indexterm>
                <indexterm><primary>Kerberos</primary><secondary>Heimdal</secondary></indexterm>
                <indexterm><primary>Red Hat Linux</primary></indexterm>
                <indexterm><primary>SUSE Linux</primary></indexterm>
                <indexterm><primary>SerNet</primary></indexterm>
                <indexterm><primary>validated</primary></indexterm>
                The next step is to identify which version of the Kerberos libraries have been used.
                In order to permit Samba-3 to interoperate with Windows 2003 Active Directory, it is
                essential that it has been linked with either MIT Kerberos version 1.3.1 or later,
                or that it has been linked with Heimdal Kerberos 0.6 plus specific patches. You may
                identify what version of the MIT Kerberos libraries are installed on your system by
                executing (on Red Hat Linux):
<screen>
&rootprompt; rpm -q krb5
</screen>
                Or on SUSE Linux, execute:
<screen>
&rootprompt; rpm -q heimdal
</screen>
                Please note that the RPMs provided by the Samba-Team are known to be working and have
                been validated. Red Hat Linux RPMs may be obtained from the Samba FTP sites. SUSE
                Linux RPMs may be obtained from <ulink url="ftp://ftp.sernet.de">Sernet</ulink> in
                Germany.
                </para>

                <para>
                From this point on, you are certain that the Samba-3 build you are using has the
                necessary capabilities. You can now configure Samba-3 and the NSS. 
                </para></step>

                <step><para>
                Using you favorite editor, configure the &smb.conf; file that is located in the 
                <filename>/etc/samba</filename> directory so that it has the contents shown 
                in <link linkend="ch9-adssdm"/>.
                </para></step>

                <step><para>
                Edit or create the NSS control file so it has the contents shown in <link linkend="ch9-sdmnss"/>.
                </para></step>

                <step><para>
                <indexterm><primary>/etc/samba/secrets.tdb</primary></indexterm>
                Delete the file <filename>/etc/samba/secrets.tdb</filename> if it exists. Of course, you
                do keep a backup, don't you?
                </para></step>

                <step><para>
                Delete the tdb files that cache Samba information. You keep a backup of the old
                files, of course. You also remove all files to ensure that nothing can pollute your
                nice, new configuration. Execute the following (example is for SUSE Linux):
<screen>
&rootprompt; rm /var/lib/samba/*tdb
</screen>
                </para></step>

                <step><para>
                <indexterm><primary>testparm</primary></indexterm>
                Validate your &smb.conf; file using <command>testparm</command> (as you have
                done previously). Correct all errors reported before proceeding. The command you
                execute is:
<screen>
&rootprompt; testparm -s | less
</screen>
                Now that you are satisfied that your Samba server is ready to join the Windows
                ADS domain, let's move on.
                </para></step>

                <step><para>
                <indexterm><primary>net</primary><secondary>ads</secondary><tertiary>join</tertiary></indexterm>
                <indexterm><primary>Kerberos</primary></indexterm>
                This is a good time to double-check everything and then execute the following
                command when everything you have done has checked out okay:
<screen>
&rootprompt; net ads join -UAdministrator%not24get
Using short domain name -- LONDON
Joined 'FRAN' to realm 'LONDON.ABMAS.BIZ'
</screen>
                You have successfully made your Samba-3 server a member of the ADS domain
                using Kerberos protocols.
                </para>

            <para>
                <indexterm><primary>silent return</primary></indexterm>
                <indexterm><primary>failed join</primary></indexterm>
                In the event that you receive no output messages, a silent return means that the
                domain join failed. You should use <command>ethereal</command> to identify what
                may be failing. Common causes of a failed join include:

                <itemizedlist>
                        <listitem><para>
                        <indexterm><primary>name resolution</primary><secondary>Defective</secondary></indexterm>
                        Defective or misconfigured DNS name resolution.
                        </para></listitem>

                        <listitem><para>
                        <indexterm><primary>Restrictive security</primary></indexterm>
                        Restrictive security settings on the Windows 200x ADS domain controller
                        preventing needed communications protocols. You can check this by searching
                        the Windows Server 200x Event Viewer.
                        </para></listitem>

                        <listitem><para>
                        Incorrectly configured &smb.conf; file settings.
                        </para></listitem>

                        <listitem><para>
                        Lack of support of necessary Kerberos protocols because the version of MIT
                        Kerberos (or Heimdal) in use is not up to date enough to support the necessary
                        functionality.
                        </para></listitem>
                </itemizedlist>

                <indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm>
                <indexterm><primary>RPC</primary></indexterm>
                <indexterm><primary>mixed mode</primary></indexterm>
                In any case, never execute the <command>net rpc join</command> command in an attempt
                to join the Samba server to the domain, unless you wish not to use the Kerberos
                security protocols. Use of the older RPC-based domain join facility requires that
                Windows Server 200x ADS has been configured appropriately for mixed mode operation.
                </para></step>

                <step><para>
                <indexterm><primary>tdbdump</primary></indexterm>
                <indexterm><primary>/etc/samba/secrets.tdb</primary></indexterm>
                If the <command>tdbdump</command> is installed on your system (not essential),
                you can look inside the <filename>/etc/samba/secrets.tdb</filename> file. If
                you wish to do this, execute:
<screen>
&rootprompt; tdbdump secrets.tdb
{
key = "SECRETS/SID/LONDON"
data = "\01\04\00\00\00\00\00\05\15\00\00\00\EBw\86\F1\ED\BD\
   F6{\5C6\E5W\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\
   00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\
   00\00\00\00\00\00\00\00"
}
{
key = "SECRETS/MACHINE_PASSWORD/LONDON"
data = "le3Q5FPnN5.ueC\00"
}
{
key = "SECRETS/MACHINE_SEC_CHANNEL_TYPE/LONDON"
data = "\02\00\00\00"
}
{
key = "SECRETS/MACHINE_LAST_CHANGE_TIME/LONDON"
data = "E\89\F6?"
}
</screen>
                This is given to demonstrate to the skeptics that this process truly does work.
                </para></step>

                <step><para>
                It is now time to start Samba in the usual way (as has been done many time before
                in this book).  
                </para></step>

                <step><para>
                <indexterm><primary>wbinfo</primary></indexterm>
                This is a good time to verify that everything is working. First, check that
                winbind is able to obtain the list of users and groups from the ADS domain controller.
                Execute the following:
<screen>
&rootprompt; wbinfo -u
LONDON+Administrator
LONDON+Guest
LONDON+SUPPORT_388945a0
LONDON+krbtgt
LONDON+jht
</screen>
                Good, the list of users was obtained. Now do likewise for group accounts:
<screen>
&rootprompt; wbinfo -g
LONDON+Domain Computers
LONDON+Domain Controllers
LONDON+Schema Admins
LONDON+Enterprise Admins
LONDON+Domain Admins
LONDON+Domain Users
LONDON+Domain Guests
LONDON+Group Policy Creator Owners
LONDON+DnsUpdateProxy
</screen>
                Excellent. That worked also, as expected.
                </para></step>

          <step><para><indexterm>
                <primary>getent</primary>
              </indexterm>
                Now repeat this via NSS to validate that full identity resolution is
                functional as required. Execute:
<screen>
&rootprompt; getent passwd
...
LONDON+Administrator:x:10000:10000:Administrator:
             /home/LONDON/administrator:/bin/bash
LONDON+Guest:x:10001:10001:Guest:
             /home/LONDON/guest:/bin/bash
LONDON+SUPPORT_388945a0:x:10002:10000:SUPPORT_388945a0:
             /home/LONDON/support_388945a0:/bin/bash
LONDON+krbtgt:x:10003:10000:krbtgt:
             /home/LONDON/krbtgt:/bin/bash
LONDON+jht:x:10004:10000:John H. Terpstra:
             /home/LONDON/jht:/bin/bash
</screen>
                Okay, ADS user accounts are being resolved. Now you try group resolution:
<screen>
&rootprompt; getent group
...
LONDON+Domain Computers:x:10002:
LONDON+Domain Controllers:x:10003:
LONDON+Schema Admins:x:10004:LONDON+Administrator
LONDON+Enterprise Admins:x:10005:LONDON+Administrator
LONDON+Domain Admins:x:10006:LONDON+jht,LONDON+Administrator
LONDON+Domain Users:x:10000:
LONDON+Domain Guests:x:10001:
LONDON+Group Policy Creator Owners:x:10007:LONDON+Administrator
LONDON+DnsUpdateProxy:x:10008:
</screen>
                This is very pleasing. Everything works as expected.
                </para></step>

                <step><para>
                <indexterm><primary>net</primary><secondary>ads</secondary><tertiary>info</tertiary></indexterm>
                <indexterm><primary>Active Directory</primary><secondary>server</secondary></indexterm>
                <indexterm><primary>Kerberos</primary></indexterm>
                You may now perform final verification that communications between Samba-3 winbind and
                the Active Directory server is using Kerberos protocols. Execute the following:
<screen>
&rootprompt; net ads info
LDAP server: 192.168.2.123
LDAP server name: w2k3s
Realm: LONDON.ABMAS.BIZ
Bind Path: dc=LONDON,dc=ABMAS,dc=BIZ
LDAP port: 389
Server time: Sat, 03 Jan 2004 02:44:44 GMT
KDC server: 192.168.2.123
Server time offset: 2
</screen>
                It should be noted that Kerberos protocols are time-clock critical. You should
                keep all server time clocks synchronized using the network time protocol (NTP).
                In any case, the output we obtained confirms that all systems are operational.
                </para></step>

                <step><para>
                <indexterm><primary>net</primary><secondary>ads</secondary><tertiary>status</tertiary></indexterm>
                There is one more action you elect to take, just because you are paranoid and disbelieving,
                so you execute the following command:
<programlisting>
&rootprompt; net ads status -UAdministrator%not24get
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
objectClass: computer
cn: fran
distinguishedName: CN=fran,CN=Computers,DC=london,DC=abmas,DC=biz
instanceType: 4
whenCreated: 20040103092006.0Z
whenChanged: 20040103092006.0Z
uSNCreated: 28713
uSNChanged: 28717
name: fran
objectGUID: 58f89519-c467-49b9-acb0-f099d73696e
userAccountControl: 69632
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 127175965783327936
localPolicyFlags: 0
pwdLastSet: 127175952062598496
primaryGroupID: 515
objectSid: S-1-5-21-4052121579-2079768045-1474639452-1109
accountExpires: 9223372036854775807
logonCount: 13
sAMAccountName: fran$
sAMAccountType: 805306369
operatingSystem: Samba
operatingSystemVersion: 3.0.20-SUSE
dNSHostName: fran
userPrincipalName: HOST/fran@LONDON.ABMAS.BIZ
servicePrincipalName: CIFS/fran.london.abmas.biz
servicePrincipalName: CIFS/fran
servicePrincipalName: HOST/fran.london.abmas.biz
servicePrincipalName: HOST/fran
objectCategory: CN=Computer,CN=Schema,CN=Configuration,
                              DC=london,DC=abmas,DC=biz
isCriticalSystemObject: FALSE
-------------- Security Descriptor (revision: 1, type: 0x8c14)
owner SID: S-1-5-21-4052121579-2079768045-1474639452-512
group SID: S-1-5-21-4052121579-2079768045-1474639452-513
------- (system) ACL (revision: 4, size: 120, number of ACEs: 2)
------- ACE (type: 0x07, flags: 0x5a, size: 0x38, 
               mask: 0x20, object flags: 0x3)
access SID:  S-1-1-0
access type: AUDIT OBJECT
Permissions:
        [Write All Properties]
------- ACE (type: 0x07, flags: 0x5a, size: 0x38, 
               mask: 0x20, object flags: 0x3)
access SID:  S-1-1-0
access type: AUDIT OBJECT
Permissions:
        [Write All Properties]
------- (user) ACL (revision: 4, size: 1944, number of ACEs: 40)
------- ACE (type: 0x00, flags: 0x00, size: 0x24, mask: 0xf01ff)
access SID:  S-1-5-21-4052121579-2079768045-1474639452-512
access type: ALLOWED
Permissions: [Full Control]
------- ACE (type: 0x00, flags: 0x00, size: 0x18, mask: 0xf01ff)
access SID:  S-1-5-32-548
...
------- ACE (type: 0x05, flags: 0x12, size: 0x38, 
                mask: 0x10, object flags: 0x3)
access SID:  S-1-5-9
access type: ALLOWED OBJECT
Permissions:
        [Read All Properties]
-------------- End Of Security Descriptor
</programlisting>
                And now you have conclusive proof that your Samba-3 ADS domain member server
                called <constant>FRAN</constant> is able to communicate fully with the ADS
                domain controllers.
                </para></step>

        </procedure>


        <para>
        Your Samba-3 ADS domain member server is ready for use. During training sessions,
        you may be asked what is inside the <filename>winbindd_cache.tdb and winbindd_idmap.tdb</filename>
        files. Since curiosity just took hold of you, execute the following:
<programlisting>
&rootprompt; tdbdump /var/lib/samba/winbindd_idmap.tdb
{
key = "S-1-5-21-4052121579-2079768045-1474639452-501\00"
data = "UID 10001\00"
}
{
key = "UID 10005\00"
data = "S-1-5-21-4052121579-2079768045-1474639452-1111\00"
}
{
key = "GID 10004\00"
data = "S-1-5-21-4052121579-2079768045-1474639452-518\00"
}
{
key = "S-1-5-21-4052121579-2079768045-1474639452-502\00"
data = "UID 10003\00"
}
...

&rootprompt; tdbdump /var/lib/samba/winbindd_cache.tdb
{
key = "UL/LONDON"
data = "\00\00\00\00bp\00\00\06\00\00\00\0DAdministrator\0D
   Administrator-S-1-5-21-4052121579-2079768045-1474639452-500-
   S-1-5-21-4052121579-2079768045-1474639452-513\05Guest\05
   Guest-S-1-5-21-4052121579-2079768045-1474639452-501-
   S-1-5-21-4052121579-2079768045-1474639452-514\10
   SUPPORT_388945a0\10SUPPORT_388945a0.
   S-1-5-21-4052121579-2079768045-1474639452-1001-
   S-1-5-21-4052121579-2079768045-1474639452-513\06krbtgt\06
   krbtgt-S-1-5-21-4052121579-2079768045-1474639452-502-
   S-1-5-21-4052121579-2079768045-1474639452-513\03jht\10
   John H. Terpstra.S-1-5-21-4052121579-2079768045-1474639452-1110-
   S-1-5-21-4052121579-2079768045-1474639452-513"
}
{
key = "GM/S-1-5-21-4052121579-2079768045-1474639452-512"
data = "\00\00\00\00bp\00\00\02\00\00\00.
   S-1-5-21-4052121579-2079768045-1474639452-1110\03
   jht\01\00\00\00-S-1-5-21-4052121579-2079768045-1474639452-500\0D
   Administrator\01\00\00\00"
}
{
key = "SN/S-1-5-21-4052121579-2079768045-1474639452-513"
data = "\00\00\00\00xp\00\00\02\00\00\00\0CDomain Users"
}
{
key = "GM/S-1-5-21-4052121579-2079768045-1474639452-518"
data = "\00\00\00\00bp\00\00\01\00\00\00-
   S-1-5-21-4052121579-2079768045-1474639452-500\0D
   Administrator\01\00\00\00"
}
{
key = "SEQNUM/LONDON\00"
data = "xp\00\00C\92\F6?"
}
{
key = "U/S-1-5-21-4052121579-2079768045-1474639452-1110"
data = "\00\00\00\00xp\00\00\03jht\10John H. Terpstra.
   S-1-5-21-4052121579-2079768045-1474639452-1110-
   S-1-5-21-4052121579-2079768045-1474639452-513"
}
{
key = "NS/S-1-5-21-4052121579-2079768045-1474639452-502"
data = "\00\00\00\00bp\00\00-
   S-1-5-21-4052121579-2079768045-1474639452-502"
}
{
key = "SN/S-1-5-21-4052121579-2079768045-1474639452-1001"
data = "\00\00\00\00bp\00\00\01\00\00\00\10SUPPORT_388945a0"
}
{
key = "SN/S-1-5-21-4052121579-2079768045-1474639452-500"
data = "\00\00\00\00bp\00\00\01\00\00\00\0DAdministrator"
}
{
key = "U/S-1-5-21-4052121579-2079768045-1474639452-502"
data = "\00\00\00\00bp\00\00\06krbtgt\06krbtgt-
   S-1-5-21-4052121579-2079768045-1474639452-502-
   S-1-5-21-4052121579-2079768045-1474639452-513"
}
....
</programlisting>
        Now all is revealed. Your curiosity, as well as that of your team, has been put at ease.
        May this server serve well all who happen upon it.
        </para>

<example id="ch9-adssdm">
<title>Samba Domain Member &smb.conf; File for Active Directory Membership</title>
<smbconfblock>
<smbconfcomment>Global parameters</smbconfcomment>
<smbconfsection name="[global]"/>
<smbconfoption name="unix charset">LOCALE</smbconfoption>
<smbconfoption name="workgroup">LONDON</smbconfoption>
<smbconfoption name="realm">LONDON.ABMAS.BIZ</smbconfoption>
<smbconfoption name="server string">Samba 3.0.20</smbconfoption>
<smbconfoption name="security">ADS</smbconfoption>
<smbconfoption name="username map">/etc/samba/smbusers</smbconfoption>
<smbconfoption name="log level">1</smbconfoption>
<smbconfoption name="syslog">0</smbconfoption>
<smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
<smbconfoption name="max log size">50</smbconfoption>
<smbconfoption name="printcap name">CUPS</smbconfoption>
<smbconfoption name="ldap ssl">no</smbconfoption>
<smbconfoption name="idmap uid">10000-20000</smbconfoption>
<smbconfoption name="idmap gid">10000-20000</smbconfoption>
<smbconfoption name="template primary group">"Domain Users"</smbconfoption>
<smbconfoption name="template shell">/bin/bash</smbconfoption>
<smbconfoption name="winbind separator">+</smbconfoption>
<smbconfoption name="printing">cups</smbconfoption>

<smbconfsection name="[homes]"/>
<smbconfoption name="comment">Home Directories</smbconfoption>
<smbconfoption name="valid users">%S</smbconfoption>
<smbconfoption name="read only">No</smbconfoption>
<smbconfoption name="browseable">No</smbconfoption>

<smbconfsection name="[printers]"/>
<smbconfoption name="comment">SMB Print Spool</smbconfoption>
<smbconfoption name="path">/var/spool/samba</smbconfoption>
<smbconfoption name="guest ok">Yes</smbconfoption>
<smbconfoption name="printable">Yes</smbconfoption>
<smbconfoption name="browseable">No</smbconfoption>

<smbconfsection name="[print$]"/>
<smbconfoption name="comment">Printer Drivers</smbconfoption>
<smbconfoption name="path">/var/lib/samba/drivers</smbconfoption>
<smbconfoption name="admin users">root, Administrator</smbconfoption>
<smbconfoption name="write list">root</smbconfoption>
</smbconfblock>
</example>

        <sect3>
        <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 downside 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 with 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 an ADS domain environment is shown in <link linkend="sbe-idmapridex"/>.
        </para>

<example id="sbe-idmapridex">
<title>Example &smb.conf; File Using <constant>idmap_rid</constant></title>
<smbconfblock>
<smbconfcomment>Global parameters</smbconfcomment>
<smbconfsection name="[global]"/>
<smbconfoption name="workgroup">KPAK</smbconfoption>
<smbconfoption name="netbios name">BIGJOE</smbconfoption>
<smbconfoption name="realm">CORP.KPAK.COM</smbconfoption>
<smbconfoption name="server string">Office Server</smbconfoption>
<smbconfoption name="security">ADS</smbconfoption>
<smbconfoption name="allow trusted domains">No</smbconfoption>
<smbconfoption name="idmap backend">idmap_rid:KPAK=500-100000000</smbconfoption>
<smbconfoption name="idmap uid">500-100000000</smbconfoption>
<smbconfoption name="idmap gid">500-100000000</smbconfoption>
<smbconfoption name="template shell">/bin/bash</smbconfoption>
<smbconfoption name="winbind use default domain">Yes</smbconfoption>
<smbconfoption name="winbind enum users">No</smbconfoption>
<smbconfoption name="winbind enum groups">No</smbconfoption>
<smbconfoption name="winbind nested groups">Yes</smbconfoption>
<smbconfoption name="printer admin">"KPAK\Domain Admins"</smbconfoption>
</smbconfblock>
</example>

        <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 example, 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 results 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 because it depends on the type of failure that
                may have occurred. 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</command>, <command>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>

        </sect3>

        <sect3>
        <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-compliant
        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 example in <link linkend="sbeunxa"/> is for an ADS-style domain.
        </para>

<example id="sbeunxa">
<title>Typical ADS Style Domain &smb.conf; File</title>
<smbconfblock>
<smbconfcomment>Global parameters</smbconfcomment>
<smbconfsection name="[global]"/>
<smbconfoption name="workgroup">SNOWSHOW</smbconfoption>
<smbconfoption name="netbios name">GOODELF</smbconfoption>
<smbconfoption name="realm">SNOWSHOW.COM</smbconfoption>
<smbconfoption name="server string">Samba Server</smbconfoption>
<smbconfoption name="security">ADS</smbconfoption>
<smbconfoption name="log level">1 ads:10 auth:10 sam:10 rpc:10</smbconfoption>
<smbconfoption name="ldap admin dn">cn=Manager,dc=SNOWSHOW,dc=COM</smbconfoption>
<smbconfoption name="ldap idmap suffix">ou=Idmap</smbconfoption>
<smbconfoption name="ldap suffix">dc=SNOWSHOW,dc=COM</smbconfoption>
<smbconfoption name="idmap backend">ldap:ldap://ldap.snowshow.com</smbconfoption>
<smbconfoption name="idmap uid">150000-550000</smbconfoption>
<smbconfoption name="idmap gid">150000-550000</smbconfoption>
<smbconfoption name="template shell">/bin/bash</smbconfoption>
<smbconfoption name="winbind use default domain">Yes</smbconfoption>
</smbconfblock>
</example>

        <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 the chapter called "Reporting Bugs" in
        <quote>The Official Samba-3 HOWTO and Reference Guide, Second Edition</quote> (TOSHARG2).
        </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 cannot 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 because 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 and 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</command>, <command>winbind</command>, and <command>smbd</command> daemons in the order shown.
                </para></step>
        </procedure>


        <para>
        <indexterm><primary>diagnostic</primary></indexterm>
        Follow the diagnostic 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>

        </sect3>

        <sect3>
        <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 this section 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>
        An example &smb.conf; file is shown in <link linkend="sbewinbindex"/>.
        </para>

<example id="sbewinbindex">
<title>ADS Membership Using RFC2307bis Identity Resolution &smb.conf; File</title>
<smbconfblock>
<smbconfcomment>Global parameters</smbconfcomment>
<smbconfsection name="[global]"/>
<smbconfoption name="workgroup">BUBBAH</smbconfoption>
<smbconfoption name="netbios name">MADMAX</smbconfoption>
<smbconfoption name="realm">BUBBAH.COM</smbconfoption>
<smbconfoption name="server string">Samba Server</smbconfoption>
<smbconfoption name="security">ADS</smbconfoption>
<smbconfoption name="idmap uid">150000-550000</smbconfoption>
<smbconfoption name="idmap gid">150000-550000</smbconfoption>
<smbconfoption name="template shell">/bin/bash</smbconfoption>
<smbconfoption name="winbind use default domain">Yes</smbconfoption>
<smbconfoption name="winbind trusted domains only">Yes</smbconfoption>
<smbconfoption name="winbind nested groups">Yes</smbconfoption>
</smbconfblock>
</example>

        <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 instructions.
        </para>

        <para>
        The next step involves preparation on the ADS schema. This is briefly discussed in the remaining
        part of this chapter.
        </para>

                <sect4>
                <title>IDMAP, Active Directory, and MS Services for UNIX 3.5</title>

                <para>
                <indexterm><primary>SFU</primary></indexterm>
                The Microsoft Windows Service for UNIX 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>

                </sect4>

                <sect4>
                <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>

                </sect4>

        </sect3>

        </sect2>

        <sect2>
        <title>UNIX/Linux Client Domain Member</title>

        <para><indexterm>
            <primary>user credentials</primary>
          </indexterm>
        So far this chapter has been mainly concerned with the provision of file and print
        services for domain member servers. However, an increasing number of UNIX/Linux
        workstations are being installed that do not act as file or print servers to anyone
        other than a single desktop user. The key demand for desktop systems is to be able
        to log onto any UNIX/Linux or Windows desktop using the same network user credentials.
        </para>

        <para><indexterm>
            <primary>Single Sign-On</primary>
            <see>SSO</see>
          </indexterm>
        The ability to use a common set of user credential across a variety of network systems
        is generally regarded as a single sign-on (SSO) solution. SSO systems are sold by a
        large number of vendors and include a range of technologies such as:
        </para>

        <itemizedlist>
                <listitem><para>
                Proxy sign-on
                </para></listitem>

                <listitem><para>
                Federated directory provisioning
                </para></listitem>

                <listitem><para>
                Metadirectory server solutions
                </para></listitem>

                <listitem><para>
                Replacement authentication systems
                </para></listitem>
        </itemizedlist>

        <para><indexterm>
            <primary>Identity management</primary>
          </indexterm>
        There are really four solutions that provide integrated authentication and
        user identity management facilities:
        </para>

        <itemizedlist>
                <listitem><para>
                Samba winbind (free). Samba-3.0.20 introduced a complete replacement for Winbind that now
                provides a greater level of scalability in large ADS environments.
                </para></listitem>

                <listitem><para>
                <ulink url="http://www.padl.com">PADL</ulink> PAM and LDAP tools (free).
                </para></listitem>

                <listitem><para>
                <ulink url="http://www.vintela.com">Vintela</ulink> Authentication Services (commercial).
                </para></listitem>

                <listitem><para>
                <ulink url="http://www.centrify.com">Centrify</ulink> DirectControl (commercial). 
                Centrify's commercial product allows UNIX and Linux systems to use Active Directory
                security, directory and policy services.  Enhancements include a centralized ID mapping that 
                allows Samba, DirectControl and Active Directory to seamlessly work together.
                </para></listitem>
        </itemizedlist>

        <para>
        The following guidelines are pertinent to the deployment of winbind-based authentication
        and identity resolution with the express purpose of allowing users to log on to UNIX/Linux desktops
        using Windows network domain user credentials (username and password).
        </para>

        <para>
        You should note that it is possible to use LDAP-based PAM and NSS tools to permit distributed
        systems logons (SSO), providing user and group accounts are stored in an LDAP directory. This
        provides logon services for UNIX/Linux users, while Windows users obtain their sign-on
        support via Samba-3.
        </para>

        <para>
        <indexterm><primary>Windows Services for UNIX</primary><see>SUS</see></indexterm>
        On the other hand, if the authentication and identity resolution backend must be provided by
        a Windows NT4-style domain or from an Active Directory Domain that does not have the Microsoft
        Windows Services for UNIX installed, winbind is your best friend. Specific guidance for these
        situations now follows.
        </para>

        <para>
        <indexterm><primary>PAM</primary></indexterm>
        <indexterm><primary>Identity resolution</primary></indexterm>
        <indexterm><primary>NSS</primary></indexterm>
        To permit users to log on to a Linux system using Windows network credentials, you need to
        configure identity resolution (NSS) and PAM. This means that the basic steps include those
        outlined above with the addition of PAM configuration. Given that most workstations (desktop/client)
        usually do not need to provide file and print services to a group of users, the configuration
        of shares and printers is generally less important. Often this allows the share specifications
        to be entirely removed from the &smb.conf; file. That is obviously an administrator decision.
        </para>

                <sect3>
                <title>NT4 Domain Member</title>

                <para>
                The following steps provide a Linux system that users can log onto using
                Windows NT4 (or Samba-3) domain network credentials:
                </para>

                <procedure>
                        <step><para>
                        Follow the steps outlined in <link linkend="wdcsdm"/> and ensure that
                        all validation tests function as shown.
                        </para></step>

                        <step><para>
                        Identify what services users must log on to. On Red Hat Linux, if it is
                        intended that the user shall be given access to all services, it may be
                        most expeditious to simply configure the file 
                        <filename>/etc/pam.d/system-auth</filename>.
                        </para></step>

                        <step><para>
                        Carefully make a backup copy of all PAM configuration files before you
                        begin making changes. If you break the PAM configuration, please note
                        that you may need to use an emergency boot process to recover your Linux
                        system. It is possible to break the ability to log into the system if
                        PAM files are incorrectly configured. The entire directory 
                        <filename>/etc/pam.d</filename> should be backed up to a safe location.
                        </para></step>

                        <step><para>
                        If you require only console login support, edit the <filename>/etc/pam.d/login</filename>
                        so it matches <link linkend="ch9-pamwnbdlogin"/>.
                        </para></step>

                        <step><para>
                        To provide the ability to log onto the graphical desktop interface, you must edit
                        the files <filename>gdm</filename> and <filename>xdm</filename> in the 
                        <filename>/etc/pam.d</filename> directory.
                        </para></step>

                        <step><para>
                        Edit only one file at a time. Carefully validate its operation before attempting
                        to reboot the machine.
                        </para></step>
                </procedure>

                </sect3>

                <sect3>
                <title>ADS Domain Member</title>

                <para>
                This procedure should be followed to permit a Linux network client (workstation/desktop)
                to permit users to log on using Microsoft Active Directory-based user credentials.
                </para>

                <procedure>
                        <step><para>
                        Follow the steps outlined in <link linkend="adssdm"/> and ensure that
                        all validation tests function as shown.
                        </para></step>

                        <step><para>
                        Identify what services users must log on to. On Red Hat Linux, if it is
                        intended that the user shall be given access to all services, it may be
                        most expeditious to simply configure the file 
                        <filename>/etc/pam.d/system-auth</filename> as shown in <link linkend="ch9-rhsysauth"/>.
                        </para></step>

                        <step><para>
                        Carefully make a backup copy of all PAM configuration files before you
                        begin making changes. If you break the PAM configuration, please note
                        that you may need to use an emergency boot process to recover your Linux
                        system. It is possible to break the ability to log into the system if
                        PAM files are incorrectly configured. The entire directory 
                        <filename>/etc/pam.d</filename> should be backed up to a safe location.
                        </para></step>

                        <step><para>
                        If you require only console login support, edit the <filename>/etc/pam.d/login</filename>
                        so it matches <link linkend="ch9-pamwnbdlogin"/>.
                        </para></step>

                        <step><para>
                        To provide the ability to log onto the graphical desktop interface, you must edit
                        the files <filename>gdm</filename> and <filename>xdm</filename> in the 
                        <filename>/etc/pam.d</filename> directory.
                        </para></step>

                        <step><para>
                        Edit only one file at a time. Carefully validate its operation before attempting
                        to reboot the machine.
                        </para></step>
                </procedure>

                </sect3>

<example id="ch9-pamwnbdlogin">
<title>SUSE: PAM <filename>login</filename> Module Using Winbind</title>
<screen>
# /etc/pam.d/login

#%PAM-1.0
auth sufficient pam_unix2.so    nullok
auth sufficient pam_winbind.so use_first_pass use_authtok
auth required   pam_securetty.so
auth required   pam_nologin.so
auth required   pam_env.so
auth required   pam_mail.so
account sufficient      pam_unix2.so
account sufficient      pam_winbind.so user_first_pass use_authtok
password required       pam_pwcheck.so  nullok
password sufficient     pam_unix2.so    nullok use_first_pass use_authtok
password sufficient     pam_winbind.so  use_first_pass use_authtok
session sufficient      pam_unix2.so    none
session sufficient      pam_winbind.so  use_first_pass use_authtok
session required        pam_limits.so
</screen>
</example>

<example id="ch9-pamwbndxdm">
<title>SUSE: PAM <filename>xdm</filename> Module Using Winbind</title>
<screen>
# /etc/pam.d/gdm (/etc/pam.d/xdm)

#%PAM-1.0
auth     sufficient     pam_unix2.so     nullok
auth     sufficient     pam_winbind.so   use_first_pass use_authtok
account  sufficient     pam_unix2.so
account  sufficient     pam_winbind.so   use_first_pass use_authtok
password sufficient     pam_unix2.so
password sufficient     pam_winbind.so   use_first_pass use_authtok
session  sufficient     pam_unix2.so
session  sufficient     pam_winbind.so   use_first_pass use_authtok
session  required       pam_dev perm.so
session  required       pam_resmgr.so
</screen>
</example>

<example id="ch9-rhsysauth">
<title>Red Hat 9: PAM System Authentication File: <filename>/etc/pam.d/system-auth</filename> Module Using Winbind</title>
<screen>
#%PAM-1.0
auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        sufficient    /lib/security/$ISA/pam_winbind.so use_first_pass
auth        required      /lib/security/$ISA/pam_deny.so

account     required      /lib/security/$ISA/pam_unix.so
account     sufficient    /lib/security/$ISA/pam_winbind.so use_first_pass

password    required      /lib/security/$ISA/pam_cracklib.so retry=3 type=
# Note: The above line is complete. There is nothing following the '='
password    sufficient    /lib/security/$ISA/pam_unix.so \
                                             nullok use_authtok md5 shadow
password    sufficient    /lib/security/$ISA/pam_winbind.so use_first_pass
password    required      /lib/security/$ISA/pam_deny.so

session     required      /lib/security/$ISA/pam_limits.so
session     sufficient    /lib/security/$ISA/pam_unix.so
session     sufficient    /lib/security/$ISA/pam_winbind.so use_first_pass
</screen>
</example>

        </sect2>

        <sect2>
                <title>Key Points Learned</title>

                <para>
                The addition of UNIX/Linux Samba servers and clients is a common requirement. In this chapter, you
                learned how to integrate such servers so that the UID/GID mappings they use can be consistent
                across all domain member servers. You also discovered how to implement the ability to use Samba
                or Windows domain account credentials to log on to a UNIX/Linux client.
                </para>

                <para>
                The following are key points made in this chapter:
                </para>

                <itemizedlist>
                        <listitem><para>
                        Domain controllers are always authoritative for the domain.
                        </para></listitem>

                        <listitem><para>
                        Domain members may have local accounts and must be able to resolve the identity of 
                        domain user accounts. Domain user account identity must map to a local UID/GID. That 
                        local UID/GID can be stored in LDAP. This way, it is possible to share the IDMAP data 
                        across all domain member machines.
                        </para></listitem>

                        <listitem><para>
                        Resolution of user and group identities on domain member machines may be implemented 
                        using direct LDAP services or using winbind.
                        </para></listitem>

                        <listitem><para>
                        On NSS/PAM enabled UNIX/Linux systems, NSS is responsible for identity management 
                        and PAM is responsible for authentication of logon credentials (username and password).
                        </para></listitem>
                </itemizedlist>

        </sect2>

</sect1>

<sect1>
        <title>Questions and Answers</title>

        <para>
        The following questions were obtained from the mailing list and also from private discussions
        with Windows network administrators.
        </para>

        <qandaset defaultlabel="chap09qa" type="number">
        <qandaentry>
        <question>

                <para>
                We use NIS for all UNIX accounts. Why do we need winbind?
                </para>

        </question>
        <answer>

            <para>
                <indexterm><primary>NIS</primary></indexterm>
                <indexterm><primary>encrypted passwords</primary></indexterm>
                <indexterm><primary>smbpasswd</primary></indexterm>
                <indexterm><primary>tdbsam</primary></indexterm>
                <indexterm><primary>passdb backend</primary></indexterm>
                <indexterm><primary>Winbind</primary></indexterm>
                You can use NIS for your UNIX accounts. NIS does not store the Windows encrypted
                passwords that need to be stored in one of the acceptable passdb backends.
                Your choice of backend is limited to <parameter>smbpasswd</parameter> or
                <parameter>tdbsam</parameter>. Winbind is needed to handle the resolution of
                SIDs from trusted domains to local UID/GID values.
                </para>

            <para>
                <indexterm><primary>winbind trusted domains only</primary></indexterm>
                <indexterm><primary>getpwnam()</primary></indexterm>
                On a domain member server, you effectively map Windows domain users to local users
                that are in your NIS database by specifying the <parameter>winbind trusted domains
                only</parameter>. This causes user and group account lookups to be routed via
                the <command>getpwnam()</command> family of systems calls. On an NIS-enabled client,
                this pushes the resolution of users and groups out through NIS.
                </para>

                <para>
                As a general rule, it is always a good idea to run winbind on all Samba servers.
                </para>

        </answer>
        </qandaentry>

        <qandaentry>
        <question>

                <para>
                Our IT management people do not like LDAP but are looking at Microsoft Active Directory. 
              Which is better?<indexterm>
                <primary>Active Directory</primary>
              </indexterm>
                </para>

        </question>
        <answer>

            <para><indexterm>
                <primary>LDAP</primary>
                <secondary>server</secondary>
              </indexterm><indexterm>
                <primary>Kerberos</primary>
              </indexterm><indexterm>
                <primary>schema</primary>
              </indexterm>
                Microsoft Active Directory is an LDAP server that is intricately tied to a Kerberos
                infrastructure. Most IT managers who object to LDAP do so because
                an LDAP server is most often supplied as a raw tool that needs to be configured and
                for which the administrator must create the schema, create the administration tools, and
                devise the backup and recovery facilities in a site-dependent manner. LDAP servers
                in general are seen as a high-energy, high-risk facility.
                </para>

            <para><indexterm>
                <primary>management</primary>
              </indexterm>
                Microsoft Active Directory by comparison is easy to install and configure and
                is supplied with all tools necessary to implement and manage the directory. For sites
                that lack a lot of technical competence, Active Directory is a good choice. For sites
                that have the technical competence to handle Active Directory well, LDAP is a good
                alternative. The real issue is, What type of solution does
                the site want? If management wants a choice to use an alternative, they may want to
                consider the options. On the other hand, if management just wants a solution that works,
                Microsoft Active Directory is a good solution.
                </para>

        </answer>
        </qandaentry>

        <qandaentry>
        <question>

                <para>
                We want to implement a Samba PDC, four Samba BDCs, and 10 Samba servers. Is it possible 
                to use NIS in place of LDAP?
                </para>

        </question>
        <answer>

            <para><indexterm>
                <primary>NIS</primary>
              </indexterm><indexterm>
                <primary>LDAP</primary>
              </indexterm><indexterm>
                <primary>encrypted passwords</primary>
              </indexterm><indexterm>
                <primary>synchronized</primary>
              </indexterm><indexterm>
                <primary>secure account password</primary>
              </indexterm><indexterm>
                <primary>PDC</primary>
              </indexterm><indexterm>
                <primary>BDC</primary>
              </indexterm>
                Yes, it is possible to use NIS in place of LDAP, but there may be problems with keeping
                the Windows (SMB) encrypted passwords database correctly synchronized across the entire
                network. Workstations (Windows client machines) periodically change their domain
                membership secure account password. How can you keep changes that are on remote BDCs
                synchronized on the PDC?
                </para>

            <para><indexterm>
                <primary>centralized storage</primary>
              </indexterm><indexterm>
                <primary>management</primary>
              </indexterm><indexterm>
                <primary>network Identities</primary>
              </indexterm>
                LDAP is a more elegant solution because it permits centralized storage and management
                of all network identities (user, group, and machine accounts) together with all information
                Samba needs to provide to network clients and their users.
                </para>

        </answer>
        </qandaentry>

        <qandaentry>
        <question>

                <para>
                Are you suggesting that users should not log on to a domain member server? If so, why?
                </para>

        </question>
        <answer>

            <para><indexterm>
                <primary>security</primary>
              </indexterm><indexterm>
                <primary>data</primary>
                <secondary>integrity</secondary>
              </indexterm><indexterm>
                <primary>mapped drives</primary>
              </indexterm>
                Many UNIX administrators mock the model that the personal computer industry has adopted
                as normative since the early days of Novell NetWare. The old
                perception of the necessity to keep users off file and print servers was a result of
                fears concerning the security and integrity of data. It was a simple and generally
                effective measure to keep users away from servers, except through mapped drives.
                </para>

            <para><indexterm>
                <primary>user logins</primary>
              </indexterm><indexterm>
                <primary>risk</primary>
              </indexterm><indexterm>
                <primary>user errors</primary>
              </indexterm><indexterm>
                <primary>strategy</primary>
              </indexterm><indexterm>
                <primary>policy</primary>
              </indexterm>
                UNIX administrators are fully correct in asserting that UNIX servers and workstations
                are identical in terms of the software that is installed. They correctly assert that
                in a well-secured environment it is safe to store files on a system that has hundreds
                of users. But all network administrators must factor into the decision to allow or
                reject general user logins to a UNIX system that is principally a file and print
                server the risk to operations through simple user errors.
                Only then can one begin to appraise the best strategy and adopt a site-specific
                policy that best protects the needs of users and of the organization alike.
                </para>

            <para><indexterm>
                <primary>system level logins</primary>
              </indexterm>
                From experience, it is my recommendation to keep general system-level logins to a
                practical minimum and to eliminate them if possible. This should not be taken as a
                hard rule, though. The better question is, what works best for the site?
                </para>

        </answer>
        </qandaentry>

        <qandaentry>
        <question>

            <para><indexterm>
                <primary>trusted domains</primary>
              </indexterm><indexterm>
                <primary>domain</primary>
                <secondary>trusted</secondary>
              </indexterm><indexterm>
                <primary>winbind trusted domains only</primary>
              </indexterm><indexterm>
                <primary>domain members</primary>
              </indexterm>
                We want to ensure that only users from our own domain plus from trusted domains can use our
                Samba servers. In the &smb.conf; file on all servers, we have enabled the <parameter>winbind
                trusted domains only</parameter> parameter. We now find that users from trusted domains 
                cannot access our servers, and users from Windows clients that are not domain members
                can also access our servers. Is this a Samba bug?
                </para>

        </question>
        <answer>

            <para><indexterm>
                <primary>distributed</primary>
              </indexterm><indexterm>
                <primary>NIS</primary>
              </indexterm><indexterm>
                <primary>rsync</primary>
              </indexterm><indexterm>
                <primary>LDAP</primary>
              </indexterm><indexterm>
                <primary>winbindd</primary>
              </indexterm><indexterm>
                <primary>/etc/passwd</primary>
              </indexterm>
                The manual page for this <parameter>winbind trusted domains only</parameter> parameter says,
                <quote>This parameter is designed to allow Samba servers that are members of a Samba-controlled 
                domain to use UNIX accounts distributed vi NIS, rsync, or LDAP as the UIDs for winbindd users 
                in the hosts primary domain. Therefore,  the user <constant>SAMBA\user1</constant> would be 
                mapped to the account <constant>user1</constant> in <filename>/etc/passwd</filename> instead 
                of allocating a new UID for him or her.</quote> This clearly suggests that you are trying
                to use this parameter inappropriately.
                </para>

            <para><indexterm>
                <primary>valid users</primary>
              </indexterm>
                A far better solution is to use the <parameter>valid users</parameter> by specifying
                precisely the domain users and groups that should be permitted access to the shares. You could, 
                for example, set the following parameters:
<screen>
[demoshare]
        path = /export/demodata
        valid users = @"Domain Users", @"OTHERDOMAIN\Domain Users"
</screen>
                </para>


        </answer>
        </qandaentry>

        <qandaentry>
        <question>

                <para>
                What are the benefits of using LDAP for my domain member servers?
                </para>

        </question>
        <answer>

            <para><indexterm>
                <primary>LDAP</primary>
              </indexterm><indexterm>
                <primary>benefit</primary>
              </indexterm><indexterm>
                <primary>UID</primary>
              </indexterm><indexterm>
                <primary>GID</primary>
              </indexterm><indexterm>
                <primary>Domain Controllers</primary>
              </indexterm><indexterm>
                <primary>Domain Member servers</primary>
              </indexterm><indexterm>
                <primary>copy</primary>
              </indexterm><indexterm>
                <primary>replicate</primary>
              </indexterm><indexterm>
                <primary>identity</primary>
              </indexterm>
                The key benefit of using LDAP is that the UID of all users and the GID of all groups
                are globally consistent on domain controllers as well as on domain member servers.
                This means that it is possible to copy/replicate files across servers without
                loss of identity.
                </para>

            <para><indexterm>
                <primary>Identity resolution</primary>
              </indexterm><indexterm>
                <primary>winbind</primary>
              </indexterm><indexterm>
                <primary>IDMAP backend</primary>
              </indexterm><indexterm>
                <primary>LDAP</primary>
              </indexterm><indexterm>
                <primary>Domain Controllers</primary>
              </indexterm><indexterm>
                <primary>Domain Member</primary>
                <secondary>servers</secondary>
              </indexterm><indexterm>
                <primary>Posix</primary>
              </indexterm><indexterm>
                <primary>account information</primary>
              </indexterm>
                When use is made of account identity resolution via winbind, even when an IDMAP backend
                is stored in LDAP, the UID/GID on domain member servers is consistent, but differs
                from the ID that the user/group has on domain controllers. The winbind allocated UID/GID
                that is stored in LDAP (or locally) will be in the numeric range specified in the <parameter>
                idmap uid/gid</parameter> in the &smb.conf; file. On domain controllers, the UID/GID is
                that of the POSIX value assigned in the LDAP directory as part of the POSIX account information.
                </para>

        </answer>
        </qandaentry>

        <qandaentry>
        <question>

                <para>
                Is proper DNS operation necessary for Samba-3 plus LDAP? If so, what must I put into
                my DNS configuration?
                </para>

        </question>
        <answer>

            <para><indexterm>
                <primary>DNS</primary>
                <secondary>configuration</secondary>
              </indexterm><indexterm>
                <primary>DNS</primary>
                <secondary>lookup</secondary>
              </indexterm><indexterm>
                <primary>hosts</primary>
              </indexterm><indexterm>
                <primary>/etc/nsswitch.conf</primary>
              </indexterm><indexterm>
                <primary>NSS</primary>
              </indexterm><indexterm>
                <primary>/etc/hosts</primary>
              </indexterm><indexterm>
                <primary>WINS</primary>
                <secondary>lookup</secondary>
              </indexterm>
                Samba depends on correctly functioning resolution of hostnames to their IP address. Samba
                makes no direct DNS lookup calls, but rather redirects all name-to-address calls via the
                <command>getXXXbyXXX()</command> function calls. The configuration of the <constant>hosts</constant>
                entry in the NSS <filename>/etc/nsswitch.conf</filename> file determines how the underlying
                resolution process is implemented. If the <constant>hosts</constant> entry in your NSS
                control file says:
<screen>
hosts: files dns wins
</screen>
                this means that a hostname lookup first tries the <filename>/etc/hosts</filename>.
                If this fails to resolve, it attempts a DNS lookup, and if that fails, it tries a
                WINS lookup.
                </para>

            <para><indexterm>
                <primary>NetBIOS</primary>
              </indexterm><indexterm>
                <primary>TCP/IP</primary>
              </indexterm><indexterm>
                <primary>name resolution</primary>
              </indexterm>
                The addition of the WINS-based name lookup makes sense only if NetBIOS over TCP/IP has
                been enabled on all Windows clients. Where NetBIOS over TCP/IP has been disabled, DNS
                is the preferred name resolution technology. This usually makes most sense when Samba
                is a client of an Active Directory domain, where NetBIOS use has been disabled. In this
                case, the Windows 200x autoregisters all locator records it needs with its own DNS
                server or servers.
                </para>

        </answer>
        </qandaentry>

        <qandaentry>
        <question>

                <para>
                Our Windows 2003 Server Active Directory domain runs with NetBIOS disabled. Can we
                use Samba-3 with that configuration?
                </para>

        </question>
        <answer>

                <para>
                Yes.
                </para>

        </answer>
        </qandaentry>

        <qandaentry>
        <question>

            <para><indexterm>
                <primary>net</primary>
                <secondary>ads</secondary>
                <tertiary>join</tertiary>
              </indexterm><indexterm>
                <primary>net</primary>
                <secondary>rpc</secondary>
                <tertiary>join</tertiary>
              </indexterm>
                When I tried to execute net ads join, I got no output. It did not work, so
                I think that it failed. I then executed net rpc join and that worked fine.
                That is okay, isn't it?
                </para>

        </question>
        <answer>

            <para><indexterm>
                <primary>Kerberos</primary>
              </indexterm><indexterm>
                <primary>authentication</primary>
              </indexterm>
                No. This is not okay. It means that your Samba-3 client has joined the ADS domain as
                a Windows NT4 client, and Samba-3 will not be using Kerberos-based authentication.
                </para>

        </answer>
        </qandaentry>

        </qandaset>

</sect1>

</chapter>