YES!!!!!!!!!!!!!!! HOT DOGGIES!!!!!!!!!!!!!!!!!!!!! I think I fixed it. The problem - Squid worked at my test site - it did not popup a login window, but instead used Ssamba's ntlm helper program to get credentials from IE. But at my customer site it did (improperly) popup a login window. The squid.conf files were almost identical - even to the point where my working test site incorrectly had my customer's visible hostname. But on (much) closer examination - this is an extract from the problem squid.conf: . . (From the template) . #auth_param basic program <uncomment and complete this line> auth_param basic children 5 #auth_param basic realm Squid proxy-caching web server #auth_param basic credentialsttl 2 hours auth_param basic casesensitive off # Customer specific configs auth_param ntlm program /usr/local/samba/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp auth_param ntlm children 30 auth_param ntlm max_challenge_reuses 0 auth_param ntlm max_challenge_lifetime 2 minutes auth_param basic program /usr/local/samba/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 auth_param basic casesensitive off . . . Here is the relevant part from a diff between the working squid.conf and the problem squid.conf: [root@infra-fw gregs]# diff greg-squid.conf customer-squid.conf 1,4c1,4 . . . 1280c1280 < #auth_param basic children 5 --- > auth_param basic children 5 1283c1283,1285 < #auth_param basic casesensitive off --- > auth_param basic casesensitive off > > # Customer specific configs 1294,1309d1295 < auth_param basic casesensitive off Notice that the working squid.conf had those template items commented out. The problem squid.conf did not - they were live! So the problem squid.conf had a couple of auth_param basic lines, then a bunch of auth_param ntlm lines, and then some more auth_param basic lines. Once I commented out those top auth_param basic lines, the customer system worked as advertised. It seems the order in which those auth_param lines appear is important. Based on the pain I've experienced the past several days, I conclude that the auth_param ntlm lines must be above the auth_param basic lines. The auth_param ntlm and auth_param basic lines also should be together with each other. I would really like to understand why we need both sections and in this order... But the good news is... IT WORKS NOW!!!!!!!!!!! - Greg Scott GregScott@xxxxxxxxxxxxxxxxxxx -----Original Message----- From: Greg Scott [mailto:GregScott@xxxxxxxxxxxxxxxx] Sent: Monday, April 04, 2005 2:25 AM To: squid-users@xxxxxxxxxxxxxxx; samba@xxxxxxxxxxxxxxx; support@xxxxxxxxxxxxxxxxxxx Cc: Fredy Hernandez; Scott Anderson Subject: [squid-users] IE improperly prompts for credentials; ntlm_auth with Samba 3.0.13, Squid 2.5.STABLE7, RedHat Linux 9.0, SmartFilter 4.01 This turned into the mother of all system integration exercises and I **almost** have it working. I am trying to set up proxy authorization using: RedHat Linux 9.0, MIT Kerberos 1.4 built from source, Samba 3.0.13 built from source, Squid 2.5.STABLE7 built from source SmartFilter 4.01. Active Directory with Windows 2003 Why not use RPMs? Well - ADS support for Windows 2003 needs Kerberos 1.3 or newer. But RedHat 9.0 has Kerberos 1.2.7 and zillions of RedHat packages depend on it. So I need krb5 1.4 in another tree and everything pretty much flows from that. See below for details on how I built all this, with attributions to everyone who has helped so far. Once this is up and running, I'll update my step by step instructions and post them. So below is a snapshot as of right now and will likely change in a few hours. Here is, I think, my last remaining problem getting this into production. Whenever I launch IE on a client PC, IE prompts the user for credentials. IE is supposed to just pass the credentials to Squid without annoying the user for this, but it doesn't and this is making me nuts. If the user enters domain\username password s(he) gets to the desired website via Squid/SmartFilter and I assume I can set appropriate SmartFilter policies to regulate usage. But it is not acceptable for a user to always enter credentials and this combination of software is supposed to eliminate that hassle. I must be missing something... >From Windows, I can browse to the Linux box via My Network Places and view its Samba shares. >From Linux, getent passwd returns all the A/D usernames and getent group returns all the A/D groups. >From Linux, /usr/local/samba/bin/wbinfo -g, /usr/local/samba/bin/wbinfo -u, and /usr/local/samba/bin/wbinfo -t work as advertised and return my A/D groups, users, and verify the trust relationship. /usr/local/samba/bin/ntlm_auth --username=[USERNAME] works as advertised - success if a good username/password, failure otherwise. Similarly, /usr/local/samba/bin/ntlm_auth --helper-protocol=squid-2.5-basic works as advertised and returns OK if a good username/password, ERR otherwise. Running /usr/local/samba/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp returns output I don't understand, but the Squid FAQ says you can't really test this one by hand anyway. This all suggests Samba is good. Here are the relevant lines from /usr/local/etc/squid.conf . . . # TAG: auth_param # This is used to define parameters for the various authentication # schemes supported by Squid. # # format: auth_param scheme parameter [setting] # # The order in which authentication schemes are presented to the client is . . . auth_param basic children 5 #auth_param basic realm Squid proxy-caching web server #auth_param basic credentialsttl 2 hours auth_param basic casesensitive off # Site specific configs auth_param ntlm program /usr/local/samba/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp auth_param ntlm children 30 auth_param ntlm max_challenge_reuses 0 auth_param ntlm max_challenge_lifetime 2 minutes auth_param basic program /usr/local/samba/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 . . . # # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # Example rule allowing access from your local networks. Adapt # to list your (internal) IP networks from where browsing should # be allowed #acl our_networks src 192.168.1.0/24 192.168.2.0/24 #http_access allow our_networks ##acl my_network src 175.10.0.0/16 ##http_access allow my_network acl AuthorizedUsers proxy_auth REQUIRED http_access allow all AuthorizedUsers ##acl password proxy_auth REQUIRED ##http_access allow password # And finally deny all other access to this proxy http_access deny all . . . This spawns another question - why do I need an auth_param for both ntlm and basic authentication? What's the difference? Lots of documentation all over the place says I need both and in this order but I haven't found anything that says why. Could this be a key to my problem? Thanks - Greg Scott GregScott@xxxxxxxxxxxxxxxxxxx Here are the build notes - remember, this is a snapshot in time, useful right now for debugging. Below is a work in progress. For Squid authentication with an Active Directory domain, we need Samba, set up with Kerberos. Redhat Linux 9.0 ships with Kerberos version 5, revision 1.2.7-10. Unfortunately, we need at least rev 1.3 to work with Windows 2003. See this URL for a discussion: http://lists.samba.org/archive/samba/2004-July/090137.html The fc3 RPM directory has rev 1.3 RPMs. Unfortunately, several dozen components in RedHat 9.0 depend on the 1.2.7 RPMs installed, especially the Kerberos libraries. So we need to build a copy of Kerberos from source and put it in an alternate directory. Then we'll build a copy of Samba using this Kerberos build. We get the latest and greatest Kerberos from MIT. For the MIT Kerberos download, see: http://web.mit.edu/kerberos/www/ FOr release notes, see: http://web.mit.edu/kerberos/www/krb5-1.4/README-1.4.txt FOr the Installation Guide see: http://web.mit.edu/kerberos/www/krb5-1.4/krb5-1.4/doc/krb5-install.html# Building%20Kerberos%20V5 First, put a copy of the download into /usr/src cp krb5-1.4-signed.tar /usr/src Do this to unpack the download. cd /usr/src tar -xvf krb5-1.4-signed.tar This extracts these two files: krb5-1.4.tar.gz - the actual software krb5-1.4.tar.gz.asc - a signature Now do this to unpack the Kerberos software: tar -xvzf krb5-1.4.tar.gz Now build it. By default, Kerberos will install the package's files rooted at `/usr/local' as in `/usr/local/bin', `/usr/local/sbin', etc. (Pasted from the Installation Guide). We will need this later on when we build Samba. cd /usr/src/krb5-1.4 cd src ./configure make make install Some notes: Make sure /etc/hosts has the FQDN of this system in place, similar to below: [root@infra-fw src]# more /etc/hosts # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 squidtest.infrasupportetc.com localhost.localdomain localhost 10.10.10.2 squidtest.infrasupportetc.com Test the build like this: cd /usr/src/krb5-1.4/src make check Fix any problems it calls out and keep running until it finishes cleanly. ************************************************************************ *************************** Now to build Samba from source to take advantage of the newest Kerberos Download samba-3.0.13.tar.gz from here: http://us4.samba.org/samba/ Put the saveset in the source directory: cp samba-3.0.13.tar.gz /usr/src Unpack it cd /usr/src tar -xvzf samba-3.0.13.tar.gz Now build it with the Kerberos flavor installed earlier cd /usr/src/samba-3.0.13/source ./configure --with-ads --with-krb5=/usr/local make make install ************************************************************************ ************************** Configure Samba to work with Kerberos Set up smb.conf and krb5.conf. (The paths are /usr/local/samba/lib/smb.conf and /etc/krb5.conf.) (Extracted from the email Chris Cinnamo from Secure Computing sent.) Edit the smb.conf --------------------------- smb.conf realm = <YOUR DOMAIN> ex. support.com workgroup = <DOMAIN> ex. support security = ADS encrypt passwords = yes password server = 192.168.100.12 # idmap uid and idmap gid are aliases for # winbind uid and winbid gid, respectively idmap uid = 10000-20000 idmap gid = 10000-20000 winbind enum users = yes winbind enum groups = yes [test] comment = Samba functionality test directory path = /home/ryan/ read only = no browsable = yes writable = yes guest ok = yes valid users = @SUPPORT\"Domain Users" ------------------------- krb5.conf (Note that Kerberos uses realms named the same as the A/D domain name. BUt --IMPORTANT-- the realm name must be in all UPPER CASE. So infrasupportetc.com becomes INFRASUPPORTETC.COM) [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = SUPPORT.COM dns_lookup_realm = false dns_lookup_kdc = false [realms] SUPPORT.COM = { kdc = 192.168.100.12:88 admin_server = 192.168.100.12:749 default_domain = SUPPORT.com } [domain_realm] .centralpower.com = SUPPORT.COM centralpower.com = SUPPORT.COM #[kdc] # profile = /var/kerberos/krb5kdc/kdc.conf [appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false } Add following entries in nssswitch.conf: passwd: files winbind group: files winbind Samba uses a daemon called winbindd that handles the authentication between Windows and Linux. When a Windows system tries to look at a share on the Samba server, it passes credentials. The Samba server needs to know where to look to validate the credentials. The above entries tell the Samba server to first check the local passwd file and if not there, then have Winbindd look back in the Windows AD. It turns out, there is more to the story. In order for the Samba server to have a clue how to tell winbindd what to do, we need to put some Samba libraries in the right place. As of 4/3/2005, the documentation in the Samba-HOWTO-Collection is wrong. Use this script provided by Doug VanLeuven to set up the libraries: #!/bin/sh # Save this script in /home/gregs or someplace convenient. # cd /usr/src/samba-3.0.13/source and run this script from there. echo "Copying nsswitch modules to system library" CWD=`pwd` cd /lib rm -f libnss_winbind.so libnss_winbind.so.1 libnss_winbind.so.2 rm -f libnss_wins.so libnss_wins.so.1 libnss_wins.so.2 cd /usr/lib rm -f libnss_winbind.so libnss_wins.so cd $CWD cp -f nsswitch/libnss_winbind.so /lib cp -f nsswitch/libnss_wins.so /lib cd /lib ln -sf libnss_winbind.so libnss_winbind.so.1 ln -sf libnss_winbind.so libnss_winbind.so.2 ln -sf libnss_wins.so libnss_wins.so.1 ln -sf libnss_wins.so libnss_wins.so.2 cd /usr/lib ln -sf ../../lib/libnss_winbind.so libnss_winbind.so ln -sf ../../lib/libnss_wins.so libnss_wins.so /sbin/ldconfig We need a place for log files. The smb.conf template points here: mkdir /var/log/samba (Also look in the already existing directory, /usr/local/samba/var for logfiles.) Since we are building from source, we need a script to fire up the daemons, like this: #!/bin/sh /usr/local/samba/sbin/nmbd /usr/local/samba/sbin/smbd /usr/local/samba/sbin/winbindd Save this script someplace convenient, perhaps /firewall-scripts. Now join this system to the Win2003 domain. Here is an extract: [root@infra-fw gregs]# /usr/local/samba/bin/net ads join -S 10.10.10.100 -U administrator administrator's password: Using short domain name -- INFRASUPPORTETC Joined 'SQUIDTEST' to realm 'INFRASUPPORTETC.COM' Here are a few useful commands for testing: kinit username@xxxxxxxxxxxxx Use Kerberos to get a ticket (prompts for password) klist -e Lists cached kerberos tickets /usr/local/samba/bin/wbinfo -t Check the trust relationship /usr/local/samba/bin/wbinfo -g Enumerate groups in the AD domain /usr/local/samba/bin/wbinfo -u Enumerate users in the AD domain /usr/bin/ntlm_auth --username=[username] This example will be useful later. Squid will use this Samba program as an authentication helper. [root@Stylmark-fw etc]# /usr/local/samba/bin/ntlm_auth --username=gregs password: NT_STATUS_WRONG_PASSWORD: Wrong Password (0xc000006a) [root@Stylmark-fw etc]# [root@Stylmark-fw etc]# [root@Stylmark-fw etc]# /usr/local/samba/bin/ntlm_auth --username=gregs password: NT_STATUS_OK: Success (0x0) ************************************************************************ *************************** Now rebuild Squid (The following modified from the explanation from Secure Computing Tech Support) cd /usr/local/squid/src/squid-2.5.STABLE7 ./configure \ --enable-smartfilter \ --enable-async-io \ --enable-linux-netfilter \ --enable-underscores \ --prefix=/usr/local/squid \ --enable-auth="ntlm,basic" \ --enable-external-acl-helpers="wbinfo_group" \ --with-samba-sources=/usr/src/samba-3.0.13 make clean make all make install For Samba 3.n, Squid will use the authentication helpers with Samba. No need to build any Squid authentication helpers. In fact, the squid FAQ says it won't work with Samba 3.0. See: http://www.squid-cache.org/Doc/FAQ/FAQ-23.html#winbind Put the following changes into /usr/local/squid/etc/squid.conf: auth_param ntlm program /usr/local/samba/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp auth_param ntlm children 30 auth_param ntlm max_challenge_reuses 0 auth_param ntlm max_challenge_lifetime 2 minutes auth_param basic program /usr/local/samba/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 change group ownership for the Samba winbindd files: chgrp squid /usr/local/samba/var/locks/winbindd_privileged -R change file ownership on squid files: cd /usr/local/squid chown squid.squid * -R create cache dirs and then start squid: su squid /usr/local/squid/sbin/squid -z killall -name squid -9 /usr/local/squid/sbin/squid ----------------------------------- from a pc logged into AD you should now be able to point ie to your squid proxy and NOT be prompted for username and password -----------------------------------
