summaryrefslogtreecommitdiff
path: root/docs/Samba3-ByExample/SBE-DomainAppsSupport.xml
diff options
context:
space:
mode:
authorJelmer Vernooij <jelmer@samba.org>2005-06-10 20:29:09 +0000
committerGerald W. Carter <jerry@samba.org>2008-04-23 08:46:44 -0500
commit06aa63b6f19131071800985746b445dee42d91eb (patch)
tree5f7aaa77fc7375919463ae40d05933d44688f071 /docs/Samba3-ByExample/SBE-DomainAppsSupport.xml
parentb82eb1abe3641a80ad6f431dd2fd625dc229eaed (diff)
downloadsamba-06aa63b6f19131071800985746b445dee42d91eb.tar.gz
samba-06aa63b6f19131071800985746b445dee42d91eb.tar.bz2
samba-06aa63b6f19131071800985746b445dee42d91eb.zip
Large number of small fixes to the layout and the build system.
(This used to be commit 73fac0653c774a8ed8654b064fd63d4e486f6b0f)
Diffstat (limited to 'docs/Samba3-ByExample/SBE-DomainAppsSupport.xml')
-rw-r--r--docs/Samba3-ByExample/SBE-DomainAppsSupport.xml916
1 files changed, 916 insertions, 0 deletions
diff --git a/docs/Samba3-ByExample/SBE-DomainAppsSupport.xml b/docs/Samba3-ByExample/SBE-DomainAppsSupport.xml
new file mode 100644
index 0000000000..eefc9c9fb2
--- /dev/null
+++ b/docs/Samba3-ByExample/SBE-DomainAppsSupport.xml
@@ -0,0 +1,916 @@
+<?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="DomApps">
+<title>Integrating Additional Services</title>
+
+ <para>
+ <indexterm><primary>authentication</primary></indexterm>
+ <indexterm><primary>backends</primary></indexterm>
+ <indexterm><primary>smbpasswd</primary></indexterm>
+ <indexterm><primary>ldapsam</primary></indexterm>
+ <indexterm><primary>Active Directory</primary></indexterm>
+ You've come a long way now. You have pretty much mastered Samba-3 for
+ most uses it can be put to. Up until now, you have cast Samba-3 in the leading
+ role, and where authentication was required, you have used one or another of
+ Samba's many authentication backends (from flat text files with smbpasswd
+ to LDAP directory integration with ldapsam). Now you can design a
+ solution for a new Abmas business. This business is running Windows Server
+ 2003 and Active Directory, and these are to stay. It's time to master
+ implementing Samba and Samba-supported services in a domain controlled by
+ the latest Windows authentication technologies. Let's get started &smbmdash; this is
+ leading edge.
+ </para>
+
+<sect1>
+ <title>Introduction</title>
+
+ <para>
+ Abmas has continued its miraculous growth; indeed, nothing seems to be able
+ to stop its diversification into multiple (and seemingly unrelated) fields.
+ Its latest acquisition is Abmas Snack Foods, a big player in the snack-food
+ business.
+ </para>
+
+ <para>
+ With this acquisition comes new challenges for you and your team. Abmas Snack
+ Foods is a well-developed business with a huge and heterogeneous network. It
+ already has Windows, NetWare, and Proprietary UNIX, but as yet no Samba or Linux.
+ The network is mature and well-established, and there is no question of its chosen
+ user authentication scheme being changed for now. You need to take a wise new
+ approach.
+ </para>
+
+ <para>
+ You have decided to set the ball rolling by introducing Samba-3 into the network
+ gradually, taking over key services and easing the way to a full migration and,
+ therefore, integration into Abmas's existing business later.
+ </para>
+
+ <sect2>
+ <title>Assignment Tasks</title>
+
+ <para>
+ <indexterm><primary>web</primary><secondary>proxying</secondary></indexterm>
+ <indexterm><primary>web</primary><secondary>caching</secondary></indexterm>
+ You've promised the skeptical Abmas Snack Foods management team
+ that you can show them how Samba can ease itself and other Open Source
+ technologies into their existing infrastructure and deliver sound business
+ advantages. Cost cutting is high on their agenda (a major promise of the
+ acquisition). You have chosen Web proxying and caching as your proving ground.
+ </para>
+
+ <para>
+ <indexterm><primary>bandwidth</primary></indexterm>
+ <indexterm><primary>Microsoft ISA</primary></indexterm>
+ Abmas Snack Foods has several thousand users housed at its head office
+ and multiple regional offices, plants, and warehouses. A high proportion of
+ the business's work is done online, so Internet access for most of these
+ users is essential. All Internet access, including for all regional offices,
+ is funneled through the head office and is the job of the (now your) networking
+ team. The bandwidth requirements were horrific (comparable to a small ISP), and
+ the team soon discovered proxying and caching. In fact, they became one of
+ the earliest commercial users of Microsoft ISA.
+ </para>
+
+ <para>
+ <indexterm><primary>Active Directory</primary></indexterm>
+ <indexterm><primary>authenticated</primary></indexterm>
+ <indexterm><primary>proxy</primary></indexterm>
+ The team is not happy with ISA. Because it never lived up to its marketing promises,
+ it underperformed and had reliability problems. You have pounced on the opportunity
+ to show what Open Source can do. The one thing they do like, however, is ISA's
+ integration with Active Directory. They like that their users, once logged on,
+ are automatically authenticated against the proxy. If your alternative to ISA
+ can operate completely seamlessly in their Active Directory domain, it will be
+ approved.
+ </para>
+
+ <para>
+ This is a hands-on exercise. You build software applications so
+ that you obtain the functionality Abmas needs.
+ </para>
+
+ </sect2>
+</sect1>
+
+<sect1>
+<title>Dissection and Discussion</title>
+
+ <para>
+ The key requirements in this business example are straightforward. You are not required
+ to do anything new, just to replicate an existing system, not lose any existing features,
+ and improve performance. The key points are:
+ </para>
+
+ <itemizedlist>
+ <listitem><para>
+ Internet access for most employees
+ </para></listitem>
+ <listitem><para>
+ Distributed system to accommodate load and geographical distribution of users
+ </para></listitem>
+ <listitem><para>
+ Seamless and transparent interoperability with the existing Active Directory domain
+ </para></listitem>
+ </itemizedlist>
+
+
+ <sect2>
+ <title>Technical Issues</title>
+
+ <para>
+ <indexterm><primary>browsing</primary></indexterm>
+ <indexterm><primary>Squid proxy</primary></indexterm>
+ <indexterm><primary>proxy</primary></indexterm>
+ <indexterm><primary>authentication</primary></indexterm>
+ <indexterm><primary>Internet Explorer</primary></indexterm>
+ <indexterm><primary>winbind</primary></indexterm>
+ <indexterm><primary>NTLM</primary></indexterm>
+ <indexterm><primary>NTLM authentication daemon</primary></indexterm>
+ <indexterm><primary>authentication</primary></indexterm>
+ <indexterm><primary>daemon</primary></indexterm>
+ <indexterm><primary>Active Directory</primary></indexterm>
+ <indexterm><primary>domain</primary><secondary>Active Directory</secondary></indexterm>
+ <indexterm><primary>Kerberos</primary></indexterm><indexterm><primary>token</primary></indexterm>
+ Functionally, the user's Internet Explorer requests a browsing session with the
+ Squid proxy, for which it offers its AD authentication token. Squid hands off
+ the authentication request to the Samba-3 authentication helper application
+ called <command>ntlm_auth</command>. This helper is a hook into winbind, the
+ Samba-3 NTLM authentication daemon. Winbind enables UNIX services to authenticate
+ against Microsoft Windows domains, including Active Directory domains. As Active
+ Directory authentication is a modified Kerberos authentication, winbind is assisted
+ in this by local Kerberos 5 libraries configured to check passwords with the Active
+ Directory server. Once the token has been checked, a browsing session is established.
+ This process is entirely transparent and seamless to the user.
+ </para>
+
+ <para>
+ Enabling this consists of:
+ </para>
+
+ <itemizedlist>
+ <listitem><para>
+ Preparing the necessary environment using preconfigured packages
+ </para></listitem>
+
+ <listitem><para>
+ Setting up raw Kerberos authentication against the Active Directory domain
+ </para></listitem>
+
+ <listitem><para>
+ Configuring, compiling, and then installing the supporting Samba-3 components
+ </para></listitem>
+
+ <listitem><para>
+ Tying it all together
+ </para></listitem>
+ </itemizedlist>
+
+ </sect2>
+
+
+ <sect2>
+ <title>Political Issues</title>
+
+ <para>
+ You are a stranger in a strange land, and all eyes are upon you. Some would even like to see
+ you fail. For you to gain the trust of your newly acquired IT people, it is essential that your
+ solution does everything the old one did, but does it better in every way. Only then
+ will the entrenched positions consider taking up your new way of doing things on a
+ wider scale.
+ </para>
+
+ </sect2>
+
+</sect1>
+
+<sect1>
+ <title>Implementation</title>
+
+ <para>
+ <indexterm><primary>Squid</primary></indexterm>
+ First, your system needs to be prepared and in a known good state to proceed. This consists
+ of making sure that everything the system depends on is present and that everything that could
+ interfere or conflict with the system is removed. You will be configuring the Squid and Samba-3
+ packages and updating them if necessary. If conflicting packages of these programs are installed,
+ they must be removed.
+ </para>
+
+ <para>
+ <indexterm><primary>Red Hat Linux</primary></indexterm>
+ The following packages should be available on your Red Hat Linux system:
+ </para>
+
+ <itemizedlist>
+ <listitem><para>
+ <indexterm><primary>krb5</primary></indexterm>
+ <indexterm><primary>Kerberos</primary></indexterm>
+ krb5-libs
+ </para></listitem>
+
+ <listitem><para>
+ krb5-devel
+ </para></listitem>
+
+ <listitem><para>
+ krb5-workstation
+ </para></listitem>
+
+ <listitem><para>
+ krb5-server
+ </para></listitem>
+
+ <listitem><para>
+ pam_krb5
+ </para></listitem>
+ </itemizedlist>
+
+ <para>
+ <indexterm><primary>SUSE Linux</primary></indexterm>
+ In the case of SUSE Linux, these packages are called:
+ </para>
+
+ <itemizedlist>
+ <listitem><para>
+ heimdal-lib
+ </para></listitem>
+
+ <listitem><para>
+ heimdal-devel
+ </para></listitem>
+
+ <listitem><para>
+ <indexterm><primary>Heimdal</primary></indexterm>
+ heimdal
+ </para></listitem>
+
+ <listitem><para>
+ pam_krb5
+ </para></listitem>
+ </itemizedlist>
+
+ <para>
+ If the required packages are not present on your system, you must install
+ them from the vendor's installation media. Follow the administrative guide
+ for your Linux system to ensure that the packages are correctly updated.
+ </para>
+
+ <note><para>
+ <indexterm><primary>MS Windows Server 2003</primary></indexterm>
+ <indexterm><primary>Kerberos</primary></indexterm>
+ <indexterm><primary>MIT</primary></indexterm>
+ If the requirement is for interoperation with MS Windows Server 2003, it
+ will be necessary to ensure that you are using MIT Kerberos version 1.3.1
+ or later. Red Hat Linux 9 ships with MIT Kerberos 1.2.7 and thus requires
+ updating.
+ </para>
+
+ <para>
+ <indexterm><primary>Heimdal</primary></indexterm>
+ <indexterm><primary>SUSE Enterprise Linux Server</primary></indexterm>
+ Heimdal 0.6 or later is required in the case of SUSE Linux. SUSE Enterprise
+ Linux Server 8 ships with Heimdal 0.4. SUSE 9 ships with the necessary version.
+ </para></note>
+
+ <sect2 id="ch10-one">
+ <title>Removal of Pre-Existing Conflicting RPMs</title>
+
+ <para>
+ <indexterm><primary>Squid</primary></indexterm>
+ If Samba and/or Squid RPMs are installed, they should be updated. You can
+ build both from source.
+ </para>
+
+ <para>
+ <indexterm><primary>rpm</primary></indexterm>
+ <indexterm><primary>samba</primary></indexterm>
+ <indexterm><primary>squid</primary></indexterm>
+ Locating the packages to be un-installed can be achieved by running:
+<screen>
+&rootprompt; rpm -qa | grep -i samba
+&rootprompt; rpm -qa | grep -i squid
+</screen>
+ The identified packages may be removed using:
+<screen>
+&rootprompt; rpm -e samba-common
+</screen>
+ </para>
+
+ <sect2>
+ <title>Kerberos Configuration</title>
+
+ <para>
+ <indexterm><primary>Kerberos</primary></indexterm>
+ <indexterm><primary>Active Directory</primary><secondary>server</secondary></indexterm>
+ <indexterm><primary>ADS</primary></indexterm>
+ <indexterm><primary>KDC</primary></indexterm>
+ The systems Kerberos installation must be configured to communicate with
+ your primary Active Directory server (ADS KDC).
+ </para>
+
+ <para>
+ Strictly speaking, MIT Kerberos version 1.3.4 currently gives the best results,
+ although the current default Red Hat MIT version 1.2.7 gives acceptable results
+ unless you are using Windows 2003 servers.
+ </para>
+
+ <para>
+ <indexterm><primary>MIT</primary></indexterm>
+ <indexterm><primary>Heimdal</primary></indexterm>
+ <indexterm><primary>Kerberos</primary></indexterm>
+ <indexterm><primary>/etc/krb5.conf</primary></indexterm>
+ <indexterm><primary>DNS</primary><secondary>SRV records</secondary></indexterm>
+ <indexterm><primary>KDC</primary></indexterm>
+ <indexterm><primary>DNS</primary><secondary>lookup</secondary></indexterm>
+ Officially, neither MIT (1.3.4) nor Heimdal (0.63) Kerberos needs an <filename>/etc/krb5.conf</filename>
+ file in order to work correctly. All ADS domains automatically create SRV records in the
+ DNS zone <constant>Kerberos.REALM.NAME</constant> for each KDC in the realm. Since both
+ MIT and Heimdal, KRB5 libraries default to checking for these records, so they
+ automatically find the KDCs. In addition, <filename>krb5.conf</filename> allows
+ specifying only a single KDC, even if there is more than one. Using the DNS lookup
+ allows the KRB5 libraries to use whichever KDCs are available.
+ </para>
+
+ <procedure>
+ <title>Kerberos Configuration Steps</title>
+
+ <step><para>
+ <indexterm><primary>krb5.conf</primary></indexterm>
+ If you find the need to manually configure the <filename>krb5.conf</filename>, you should edit it
+ to have the contents shown in <link linkend="ch10-krb5conf"/>. The final fully qualified path for this file
+ should be <filename>/etc/krb5.conf</filename>.
+ </para></step>
+
+ <step><para>
+ <indexterm><primary>Kerberos</primary></indexterm>
+ <indexterm><primary>realm</primary></indexterm>
+ <indexterm><primary>case-sensitive</primary></indexterm>
+ <indexterm><primary>KDC</primary></indexterm>
+ <indexterm><primary>synchronization</primary></indexterm>
+ <indexterm><primary>initial credentials</primary></indexterm>
+ <indexterm><primary>Clock skew</primary></indexterm>
+ <indexterm><primary>NTP</primary></indexterm>
+ <indexterm><primary>DNS</primary><secondary>lookup</secondary></indexterm>
+ <indexterm><primary>reverse DNS</primary></indexterm>
+ <indexterm><primary>NetBIOS name </primary></indexterm>
+ <indexterm><primary>/etc/hosts</primary></indexterm>
+ <indexterm><primary>mapping</primary></indexterm>
+ The following gotchas often catch people out. Kerberos is case sensitive. Your realm must
+ be in UPPERCASE, or you will get an error: <quote>Cannot find KDC for requested realm while getting
+ initial credentials</quote>. Kerberos is picky about time synchronization. The time
+ according to your participating servers must be within 5 minutes or you get an error:
+ <quote>kinit(v5): Clock skew too great while getting initial credentials</quote>.
+ Clock skew limits are, in fact, configurable in the Kerberos protocols (the default is
+ 5 minutes). A better solution is to implement NTP throughout your server network.
+ Kerberos needs to be able to do a reverse DNS lookup on the IP address of your KDC.
+ Also, the name that this reverse lookup maps to must either be the NetBIOS name of
+ the KDC (i.e., the hostname with no domain attached) or the
+ NetBIOS name followed by the realm. If all else fails, you can add a
+ <filename>/etc/hosts</filename> entry mapping the IP address of your KDC to its
+ NetBIOS name. If Kerberos cannot do this reverse lookup, you will get a local error
+ when you try to join the realm.
+ </para></step>
+
+ <step><para>
+ <indexterm><primary>kinit</primary></indexterm>
+ You are now ready to test your installation by issuing the command:
+<screen>
+&rootprompt; kinit [USERNAME@REALM]
+</screen>
+ You are asked for your password, which you should enter. The following
+ is a typical console sequence:
+<screen>
+&rootprompt; kinit ADMINISTRATOR@LONDON.ABMAS.BIZ
+Password for ADMINISTRATOR@LONDON.ABMAS.BIZ:
+</screen>
+ Make sure that your password is accepted by the Active Directory KDC.
+ </para></step>
+ </procedure>
+
+<example id="ch10-krb5conf">
+<title>Kerberos Configuration &smbmdash; File: <filename>/etc/krb5.conf</filename></title>
+<screen>
+[libdefaults]
+ default_realm = LONDON.ABMAS.BIZ
+
+[realms]
+ LONDON.ABMAS.BIZ = {
+ kdc = w2k3s.london.abmas.biz
+ }
+</screen>
+</example>
+
+ <para><indexterm>
+ <primary>klist</primary>
+ </indexterm>
+ The command
+<screen>
+&rootprompt; klist -e
+</screen>
+ shows the Kerberos tickets cached by the system.
+ </para>
+
+ <sect3>
+ <title>Samba Configuration</title>
+
+ <para>
+ <indexterm><primary>Active Directory</primary></indexterm>
+ Samba must be configured to correctly use Active Directory. Samba-3 must be used, since it
+ has the necessary components to interface with Active Directory.
+ </para>
+
+ <procedure>
+ <title>Securing Samba-3 With ADS Support Steps</title>
+
+ <step><para>
+ <indexterm><primary>Red Hat Linux</primary></indexterm>
+ <indexterm><primary>Samba Tea</primary></indexterm>
+ <indexterm><primary>Red Hat Fedora Linux</primary></indexterm>
+ <indexterm><primary>MIT KRB5</primary></indexterm>
+ <indexterm><primary>ntlm_auth</primary></indexterm>
+ Download the latest stable Samba-3 for Red Hat Linux from the official Samba Team
+ <ulink url="http://ftp.samba.org">FTP site.</ulink> The official Samba Team
+ RPMs for Red Hat Fedora Linux contain the <command>ntlm_auth</command> tool
+ needed, and are linked against MIT KRB5 version 1.3.1 and therefore are ready for use.
+ </para>
+
+ <para>
+ <indexterm><primary>SerNet</primary></indexterm>
+ <indexterm><primary>RPMs</primary></indexterm>
+ The necessary, validated RPM packages for SUSE Linux may be obtained from
+ the <ulink url="ftp://ftp.sernet.de/pub/samba">SerNet</ulink> FTP site that
+ is located in Germany. All SerNet RPMs are validated, have the necessary
+ <command>ntlm_auth</command> tool, and are statically linked
+ against suitably patched Heimdal 0.6 libraries.
+ </para></step>
+
+ <step><para>
+ Using your favorite editor, change the <filename>/etc/samba/smb.conf</filename>
+ file so it has contents similar to the example shown in <link linkend="ch10-smbconf"/>.
+ </para></step>
+
+ <step><para>
+ <indexterm><primary>computer account</primary></indexterm>
+ <indexterm><primary>Active Directory</primary></indexterm>
+ <indexterm><primary>net</primary><secondary>ads</secondary><tertiary>join</tertiary></indexterm>i
+ <indexterm><primary>Kerberos ticket</primary></indexterm>
+ <indexterm><primary>ticket</primary></indexterm>
+ Next you need to create a computer account in the Active Directory.
+ This sets up the trust relationship needed for other clients to
+ authenticate to the Samba server with an Active Directory Kerberos ticket.
+ This is done with the <quote>net ads join -U [Administrator%Password]</quote>
+ command, as follows:
+<screen>
+&rootprompt; net ads join -U administrator%vulcon
+</screen>
+ </para></step>
+
+ <step><para>
+ <indexterm><primary>smbd</primary></indexterm>
+ <indexterm><primary>nmbd</primary></indexterm>
+ <indexterm><primary>winbindd</primary></indexterm>
+ <indexterm><primary>Active Directory</primary></indexterm>
+ <indexterm><primary>Samba</primary></indexterm>
+ Your new Samba binaries must be started in the standard manner as is applicable
+ to the platform you are running on. Alternatively, start your Active Directory-enabled Samba with the following commands:
+<screen>
+&rootprompt; smbd -D
+&rootprompt; nmbd -D
+&rootprompt; winbindd -B
+</screen>
+ </para></step>
+
+ <step><para>
+ <indexterm><primary>winbind</primary></indexterm>
+ <indexterm><primary>Active Directory</primary><secondary>domain</secondary></indexterm>
+ <indexterm><primary>wbinfo</primary></indexterm>
+ <indexterm><primary>enumerating</primary></indexterm>
+ <indexterm><primary>Active Directory</primary><secondary>tree</secondary></indexterm>
+ We now need to test that Samba is communicating with the Active
+ Directory domain; most specifically, we want to see whether winbind
+ is enumerating users and groups. Issue the following commands:
+<screen>
+&rootprompt; wbinfo -t
+checking the trust secret via RPC calls succeeded
+</screen>
+ This tests whether we are authenticating against Active Directory:
+<screen>
+&rootprompt; wbinfo -u
+LONDON+Administrator
+LONDON+Guest
+LONDON+SUPPORT_388945a0
+LONDON+krbtgt
+LONDON+jht
+LONDON+xjht
+</screen>
+ This enumerates all the users in your Active Directory tree:
+<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>
+ This enumerates all the groups in your Active Directory tree.
+ </para></step>
+
+ <step><para>
+ <indexterm><primary>Squid</primary></indexterm>
+ <indexterm><primary>ntlm_auth</primary></indexterm>
+ Squid uses the <command>ntlm_auth</command> helper build with Samba-3.
+ You may test <command>ntlm_auth</command> with the command:
+<screen>
+&rootprompt; /usr/bin/ntlm_auth --username=jht
+password: XXXXXXXX
+</screen>
+ You are asked for your password, which you should enter. You are rewarded with:
+<screen>
+&rootprompt; NT_STATUS_OK: Success (0x0)
+</screen>
+ </para></step>
+
+ <step><para>
+ <indexterm><primary>ntlm_auth</primary></indexterm>
+ <indexterm><primary>authenticate</primary></indexterm>
+ <indexterm><primary>winbind</primary></indexterm>
+ <indexterm><primary>privileged pipe</primary></indexterm>
+ <indexterm><primary>squid</primary></indexterm>
+ <indexterm><primary>chgrp</primary></indexterm>
+ <indexterm><primary>chmod</primary></indexterm>
+ <indexterm><primary>failure</primary></indexterm>
+ The <command>ntlm_auth</command> helper, when run from a command line as the user
+ <quote>root</quote>, authenticates against your Active Directory domain (with
+ the aid of winbind). It manages this by reading from the winbind privileged pipe.
+ Squid is running with the permissions of user <quote>squid</quote> and group
+ <quote>squid</quote> and is not able to do this unless we make a vital change.
+ Squid cannot read from the winbind privilege pipe unless you change the
+ permissions of its directory. This is the single biggest cause of failure in the
+ whole process. Remember to issue the following command (for Red Hat Linux):
+<screen>
+&rootprompt; chgrp squid /var/cache/samba/winbindd_privileged
+&rootprompt; chmod 750 /var/cache/samba/winbindd_privileged
+</screen>
+ For SUSE Linux 9, execute the following:
+<screen>
+&rootprompt; chgrp squid /var/lib/samba/winbindd_privileged
+&rootprompt; chmod 750 /var/lib/samba/winbindd_privileged
+</screen>
+ </para></step>
+
+ </procedure>
+ </sect3>
+
+ <sect3>
+ <title>NSS Configuration</title>
+
+ <para>
+ <indexterm><primary>NSS</primary></indexterm>
+ <indexterm><primary>winbind</primary></indexterm>
+ <indexterm><primary>authentication</primary></indexterm>
+ For Squid to benefit from Samba-3, NSS must be updated to allow winbind as a valid route to user authentication.
+ </para>
+
+ <para>
+ Edit your <filename>/etc/nsswitch.conf</filename> file so it has the parameters shown
+ in <link linkend="ch10-etcnsscfg"/>.
+ </para>
+
+<smbconfexample id="ch10-smbconf">
+<title>Samba Configuration &smbmdash; File: <filename>/etc/samba/smb.conf</filename></title>
+<smbconfsection name="[global]"/>
+<smbconfoption name="workgroup">LONDON</smbconfoption>
+<smbconfoption name="netbios name">W2K3S</smbconfoption>
+<smbconfoption name="realm">LONDON.ABMAS.BIZ</smbconfoption>
+<smbconfoption name="security">ads</smbconfoption>
+<smbconfoption name="encrypt passwords">yes</smbconfoption>
+<smbconfoption name="password server">w2k3s.london.abmas.biz</smbconfoption>
+
+<smbconfcomment>separate domain and username with '/', like DOMAIN/username</smbconfcomment>
+<smbconfoption name="winbind separator">/</smbconfoption>
+
+<smbconfcomment>use UIDs from 10000 to 20000 for domain users</smbconfcomment>
+<smbconfoption name="idmap uid">10000-20000</smbconfoption>
+# use GIDs from 10000 to 20000 for domain groups
+<smbconfoption name="idmap gid">10000-20000</smbconfoption>
+
+<smbconfcomment>allow enumeration of winbind users and groups</smbconfcomment>
+<smbconfoption name="winbind enum users">yes</smbconfoption>
+<smbconfoption name="winbind enum groups">yes</smbconfoption>
+<smbconfoption name="winbind user default domain">yes</smbconfoption>
+</smbconfexample>
+
+<example id="ch10-etcnsscfg">
+<title>NSS Configuration File Extract &smbmdash; File: <filename>/etc/nsswitch.conf</filename></title>
+<screen>
+passwd: files winbind
+shadow: files
+group: files winbind
+</screen>
+</example>
+
+ </sect3>
+
+ <sect3>
+ <title>Squid Configuration</title>
+
+ <para>
+ <indexterm><primary>Squid</primary></indexterm>
+ <indexterm><primary>Active Directory</primary><secondary>authentication</secondary></indexterm>
+ Squid must be configured correctly to interact with the Samba-3
+ components that handle Active Directory authentication.
+ </para>
+
+ </sect3>
+
+ </sect2>
+
+ <sect2>
+ <title>Configuration</title></sect2>
+
+ <procedure>
+ <title>Squid Configuration Steps</title>
+
+ <step><para>
+ <indexterm><primary>SUSE Linux</primary></indexterm>
+ <indexterm><primary>Squid</primary> </indexterm>
+ <indexterm><primary>helper agent</primary></indexterm>
+ If your Linux distribution is SUSE Linux 9, the version of Squid
+ supplied is already enabled to use the winbind helper agent. You
+ can therefore omit the steps that would build the Squid binary
+ programs.
+ </para></step>
+
+ <step><para>
+ <indexterm><primary>nobody</primary></indexterm>
+ <indexterm><primary>squid</primary></indexterm>
+ <indexterm><primary>rpms</primary></indexterm>
+ <indexterm><primary>/etc/passwd</primary></indexterm>
+ <indexterm><primary>/etc/group</primary></indexterm>
+ Squid, by default, runs as the user <constant>nobody</constant>. You need to
+ add a system user <constant>squid</constant> and a system group
+ <constant>squid</constant> if they are not set up already (if the default
+ Red Hat squid rpms were installed, they will be). Set up a
+ <constant>squid</constant> user in <filename>/etc/passwd</filename>
+ and a <constant>squid</constant> group in <filename>/etc/group</filename> if these aren't there already.
+ </para></step>
+
+ <step><para>
+ <indexterm><primary>permissions</primary></indexterm>
+ <indexterm><primary>chown</primary></indexterm>
+ You now need to change the permissions on Squid's <constant>var</constant>
+ directory. Enter the following command:
+<screen>
+&rootprompt; chown -R squid /var/cache/squid
+</screen>
+ </para></step>
+
+ <step><para>
+ <indexterm><primary>logging</primary></indexterm>
+ <indexterm><primary>Squid</primary></indexterm>
+ Squid must also have control over its logging. Enter the following commands:
+<screen>
+&rootprompt; chown -R chown squid:squid /var/log/squid
+&rootprompt; chmod 770 /var/log/squid
+</screen>
+ </para></step>
+
+ <step><para>
+ Finally, Squid must be able to write to its disk cache!
+ Enter the following commands:
+<screen>
+&rootprompt; chown -R chown squid:squid /var/cache/squid
+&rootprompt; chmod 770 /var/cache/squid
+</screen>
+ </para></step>
+
+ <step><para>
+ <indexterm><primary>/etc/squid/squid.conf</primary></indexterm>
+ The <filename>/etc/squid/squid.conf</filename> file must be edited to include the lines from
+ <link linkend="etcsquidcfg"/> and <link linkend="etcsquid2"/>.
+ </para></step>
+
+ <step><para>
+ <indexterm><primary>cache directories</primary></indexterm>
+ You must create Squid's cache directories before it may be run. Enter the following command:
+<screen>
+&rootprompt; squid -z
+</screen>
+ </para></step>
+
+ <step><para>
+ Finally, start Squid and enjoy transparent Active Directory authentication.
+ Enter the following command:
+<screen>
+&rootprompt; squid
+</screen>
+ </para></step>
+ </procedure>
+
+<example id="etcsquidcfg">
+<title>Squid Configuration File Extract &smbmdash; <filename>/etc/squid.conf</filename> [ADMINISTRATIVE PARAMETERS Section]</title>
+<screen>
+ cache_effective_user squid
+ cache_effective_group squid
+</screen>
+</example>
+
+<example id="etcsquid2">
+<title>Squid Configuration File extract &smbmdash; File: <filename>/etc/squid.conf</filename> [AUTHENTICATION PARAMETERS Section]</title>
+<screen>
+ auth_param ntlm program /usr/bin/ntlm_auth \
+ --helper-protocol=squid-2.5-ntlmssp
+ auth_param ntlm children 5
+ auth_param ntlm max_challenge_reuses 0
+ auth_param ntlm max_challenge_lifetime 2 minutes
+ auth_param basic program /usr/bin/ntlm_auth \
+ --helper-protocol=squid-2.5-basic
+ auth_param basic children 5
+ auth_param basic realm Squid proxy-caching web server
+ auth_param basic credentialsttl 2 hours
+ acl AuthorizedUsers proxy_auth REQUIRED
+ http_access allow all AuthorizedUsers
+</screen>
+</example>
+
+ </sect2>
+
+ <sect2>
+ <title>Key Points Learned</title>
+
+ <para>
+ <indexterm><primary>Web browsers</primary></indexterm>
+ <indexterm><primary>services</primary></indexterm>
+ <indexterm><primary>authentication protocols</primary></indexterm>
+ <indexterm><primary>Web</primary><secondary>proxy</secondary><tertiary>access</tertiary></indexterm>
+ <indexterm><primary>NTLMSSP</primary></indexterm>
+ Microsoft Windows networking protocols permeate the spectrum of technologies that Microsoft
+ Windows clients use, even when accessing traditional services such as Web browsers. Depending
+ on whom you discuss this with, this is either good or bad. No matter how you might evaluate this,
+ the use of NTLMSSP as the authentication protocol for Web proxy access has some advantages over
+ the cookie-based authentication regime used by all competing browsers. It is Samba's implementation
+ of NTLMSSP that makes it attractive to implement the solution that has been demonstrated in this chapter.
+ </para>
+
+ </sect2>
+
+</sect1>
+
+<sect1>
+ <title>Questions and Answers</title>
+
+ <para>
+ <indexterm><primary>ntlm_auth</primary></indexterm>
+ <indexterm><primary>SambaXP conference</primary></indexterm>
+ <indexterm><primary>Goettingen</primary></indexterm>
+ <indexterm><primary>Italian</primary></indexterm>
+ The development of the <command>ntlm_auth</command> module was first discussed in many Open Source circles
+ in 2002. At the SambaXP conference in Goettingen, Germany, Mr. Francesco Chemolli demonstrated the use of
+ <command>ntlm_auth</command> during one of the late developer meetings that took place. Since that time, the
+ adoption of <command>ntlm_auth</command> has spread considerably.
+ </para>
+
+ <para>
+ The largest report from a site that uses Squid with <command>ntlm_auth</command>-based authentication
+ support uses a dual processor server that has 2 GB of memory. It provides Web and FTP proxy services for 10,000
+ users. Approximately 2,000 of these users make heavy use of the proxy services. According to the source, who
+ wishes to remain anonymous, the sustained transaction load on this server hovers around 140 hits/sec. The following
+ comments were made with respect to questions regarding the performance of this installation:
+ </para>
+
+ <blockquote><para>
+ [In our] EXTREMELY optimized environment . . . [the] performance impact is almost [nothing]. The <quote>almost</quote>
+ part is due to the brain damage of the ntlm-over-http protocol definition. Suffice to say that its worst-case
+ scenario triples the number of hits needed to perform the same transactions versus basic or digest auth[entication].
+ </para></blockquote>
+
+ <para>
+ You would be well-advised to recognize that all cache-intensive proxying solutions demand a lot of memory.
+ Make certain that your Squid proxy server is equipped with sufficient memory to permit all proxy operations to run
+ out of memory without invoking the overheads involved in the use of memory that has to be swapped to disk.
+ </para>
+
+ <qandaset defaultlabel="chap10bqa" type="number">
+ <qandaentry>
+ <question>
+
+ <para>
+ What does Samba have to do with Web proxy serving?
+ </para>
+
+ </question>
+ <answer>
+
+ <para>
+ <indexterm><secondary>transparent inter-operability</secondary></indexterm>
+ <indexterm><primary>Windows clients</primary></indexterm>
+ <indexterm><primary>network</primary><secondary>services</secondary></indexterm>
+ <indexterm><primary>authentication</primary></indexterm>
+ <indexterm><primary>wrapper</primary></indexterm>
+ To provide transparent interoperability between Windows clients and the network services
+ that are used from them, Samba had to develop tools and facilities that deliver that feature. The benefit
+ of Open Source software is that it can readily be reused. The current <command>ntlm_auth</command>
+ module is basically a wrapper around authentication code from the core of the Samba project.
+ </para>
+
+ <para>
+ <indexterm><primary>plain-text</primary></indexterm>
+ <indexterm><primary>authentication</primary><secondary>plain-text</secondary></indexterm>
+ <indexterm><primary>Web</primary><secondary>proxy</secondary></indexterm>
+ <indexterm><primary>FTP</primary><secondary>proxy</secondary></indexterm>
+ <indexterm><primary>NTLMSSP</primary></indexterm>
+ <indexterm><primary>logon credentials</primary></indexterm>
+ <indexterm><primary>Windows explorer</primary></indexterm>
+ <indexterm><primary>Internet Information Server</primary></indexterm>
+ <indexterm><primary>Apache Web server</primary></indexterm>
+ The <command>ntlm_auth</command> module supports basic plain-text authentication and NTLMSSP
+ protocols. This module makes it possible for Web and FTP proxy requests to be authenticated without
+ the user being interrupted via his or her Windows logon credentials. This facility is available with
+ MS Windows Explorer and is one of the key benefits claimed for Microsoft Internet Information Server.
+ There are a few open source initiatives to provide support for these protocols in the Apache Web server
+ also.
+ </para>
+
+ <para>
+ <indexterm><primary>wrapper</primary></indexterm>
+ The short answer is that by adding a wrapper around key authentication components of Samba, other
+ projects (like Squid) can benefit from the labors expended in meeting user interoperability needs.
+ </para>
+
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+
+ <para>
+ What other services does Samba provide?
+ </para>
+
+ </question>
+ <answer>
+
+ <para>
+ <indexterm><primary>winbindd</primary></indexterm>
+ <indexterm><primary>Identity resolver</primary></indexterm>
+ <indexterm><primary>daemon</primary></indexterm>
+ <indexterm><primary>smbd</primary></indexterm>
+ <indexterm><primary>file and print server</primary></indexterm>
+ Samba-3 is a file and print server. The core components that provide this functionality are <command>smbd</command>,
+ <command>nmbd</command>, and the identity resolver daemon, <command>winbindd</command>.
+ </para>
+
+ <para>
+ <indexterm><primary>SMB/CIFS</primary></indexterm>
+ <indexterm><primary>smbclient</primary></indexterm>
+ Samba-3 is an SMB/CIFS client. The core component that provides this is called <command>smbclient</command>.
+ </para>
+
+ <para>
+ <indexterm><primary>modules</primary></indexterm>
+ <indexterm><primary>utilities</primary></indexterm>
+ <indexterm><primary>validation</primary></indexterm>
+ <indexterm><primary>inter-operability</primary></indexterm>
+ <indexterm><primary>authentication</primary></indexterm>
+ Samba-3 includes a number of helper tools, plug-in modules, utilities, and test and validation facilities.
+ Samba-3 includes glue modules that help provide interoperability between MS Windows clients and UNIX/Linux
+ servers and clients. It includes Winbind agents that make it possible to authenticate UNIX/Linux access attempts
+ as well as logins to an SMB/CIFS authentication server backend. Samba-3 includes name service switch (NSS) modules
+ to permit identity resolution via SMB/CIFS servers (Windows NT4/200x, Samba, and a host of other commercial
+ server products).
+ </para>
+
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+
+ <para>
+ Does use of Samba (<command>ntlm_auth</command>) improve the performance of Squid?
+ </para>
+
+ </question>
+ <answer>
+
+ <para>
+ Not really. Samba's <command>ntlm_auth</command> module handles only authentication. It requires that
+ Squid make an external call to <command>ntlm_auth</command> and therefore actually incurs a
+ little more overhead. Compared with the benefit obtained, that overhead is well worth enduring. Since
+ Squid is a proxy server, and proxy servers tend to require lots of memory, it is good advice to provide
+ sufficient memory when using Squid. Just add a little more to accommodate <command>ntlm_auth</command>.
+ </para>
+
+ </answer>
+ </qandaentry>
+ </qandaset>
+
+</sect1>
+
+</chapter>
+