summaryrefslogtreecommitdiff
path: root/docs/Samba-Guide/Chap10b-DomainAppsSupport.xml
diff options
context:
space:
mode:
authorJelmer Vernooij <jelmer@samba.org>2004-06-20 12:43:16 +0000
committerGerald W. Carter <jerry@samba.org>2008-04-23 08:45:56 -0500
commit83a17815a7689f1f6f7ca57161a0e804277c75f9 (patch)
treee1cec10510da7038e843f71c9ba95a0e6bc5f494 /docs/Samba-Guide/Chap10b-DomainAppsSupport.xml
parent9eb45e211cbc28bbd28837a17dcec3df29d6f455 (diff)
downloadsamba-83a17815a7689f1f6f7ca57161a0e804277c75f9.tar.gz
samba-83a17815a7689f1f6f7ca57161a0e804277c75f9.tar.bz2
samba-83a17815a7689f1f6f7ca57161a0e804277c75f9.zip
New structure for the docs:
- Same name for a doc everywhere (howto -> Samba-HOWTO-Collection, etc) - Shorter and more clearly structured Makefile - Make it possible to change the paths for the images (This used to be commit 96f6c05f25acc8a9bb1977b8bd5cc97ce511b6b1)
Diffstat (limited to 'docs/Samba-Guide/Chap10b-DomainAppsSupport.xml')
-rw-r--r--docs/Samba-Guide/Chap10b-DomainAppsSupport.xml1100
1 files changed, 1100 insertions, 0 deletions
diff --git a/docs/Samba-Guide/Chap10b-DomainAppsSupport.xml b/docs/Samba-Guide/Chap10b-DomainAppsSupport.xml
new file mode 100644
index 0000000000..7188e7747d
--- /dev/null
+++ b/docs/Samba-Guide/Chap10b-DomainAppsSupport.xml
@@ -0,0 +1,1100 @@
+<?xml version="1.0" encoding="iso-8859-1"?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+
+ <!-- Stuff for xincludes -->
+ <!ENTITY % xinclude SYSTEM "../entities/xinclude.dtd">
+ %xinclude;
+
+ <!-- entities files to use -->
+ <!ENTITY % global_entities SYSTEM '../entities/global.entities'>
+ %global_entities;
+
+]>
+
+<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. They
+ already have 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 their 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 their 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 all of their 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 under-performed 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</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 uninstalled 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.1 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.1) nor Heimdal (0.6) 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> only allows
+ specifying a single KDC, even there if there is more than one. Using the DNS lookup
+ allows the KRB5 libraries to use whichever KDCs are available.
+ </para>
+
+ <procedure>
+ <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 it can alternately be 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, as
+ this has the necessary components to interface with Active Directory.
+ </para>
+
+ <procedure>
+ <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><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. Alternately, 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>
+
+ <procedure>
+ <step><para>
+ Edit your <filename>/etc/nsswitch.conf</filename> file so it has the parameters shown
+ in <link linkend="ch10-etcnsscfg"/>.
+ </para></step>
+ </procedure>
+
+<smbconfexample id="ch10-smbconf">
+<title>Samba Configuration &smbmdash; File: <filename>/etc/samba/smb.conf</filename></title>
+<smbconfsection>[global]</smbconfsection>
+<smbconfoption><name>workgroup</name><value>LONDON</value></smbconfoption>
+<smbconfoption><name>netbios name</name><value>W2K3S</value></smbconfoption>
+<smbconfoption><name>realm</name><value>LONDON.ABMAS.BIZ</value></smbconfoption>
+<smbconfoption><name>security</name><value>ads</value></smbconfoption>
+<smbconfoption><name>encrypt passwords</name><value>yes</value></smbconfoption>
+<smbconfoption><name>password server</name><value>w2k3s.london.abmas.biz</value></smbconfoption>
+
+<smbconfcomment>separate domain and username with '/', like DOMAIN/username</smbconfcomment>
+<smbconfoption><name>winbind separator</name><value>/</value></smbconfoption>
+
+<smbconfcomment>use UIDs from 10000 to 20000 for domain users</smbconfcomment>
+<smbconfoption><name>idmap uid</name><value>10000-20000</value></smbconfoption>
+# use GIDs from 10000 to 20000 for domain groups
+<smbconfoption><name>idmap gid</name><value>10000-20000</value></smbconfoption>
+
+<smbconfcomment>allow enumeration of winbind users and groups</smbconfcomment>
+<smbconfoption><name>winbind enum users</name><value>yes</value></smbconfoption>
+<smbconfoption><name>winbind enum groups</name><value>yes</value></smbconfoption>
+<smbconfoption><name>winbind user default domain</name><value>yes</value></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>
+ <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 GBytes 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 the fact 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 has had to develop tools and facilities that deliver that. 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/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/validation facilities.
+ Samba-3 includes glue modules that help provide interoperability between MS Windows clients and UNIX/Linux
+ servers and client. 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 switcher 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>
+