This has all been on a test machine that has access to OWA and the internal network, nothing production was touched :) I work with a very large network so I have a lot of resources to at my disposal. The config (it's been sanitized for confidentiality reasons): https_port 10.212.134.117:443 vhost protocol=http cert=/etc/squid/certs/mail.bar.com.san.pem https_port 10.212.134.119:443 vhost defaultsite=mail.foo.com protocol=http cert=/etc/squid/certs/foo.pem https_port 10.212.134.121:443 vhost protocol=http cert=/etc/squid/certs/domain.domain.com.san.pem https_port 10.212.134.123:443 vhost defaultsite=mail.domain2.com protocol=http cert=/etc/squid/certs/mail.domain2.com.pem https_port 10.212.134.123:8000 vhost defaultsite=domain3.domain3.com protocol=http cert=/etc/squid/certs/domain3.domain.pem https_port 10.212.134.125:443 vhost defaultsite=owa.domain4.com protocol=http cert=/etc/squid/certs/owa.domain4.pem cache_peer 10.212.133.52 parent 80 0 proxy-only no-query no-digest originserver front-end-https=on login=PASS cache_peer 10.212.133.102 parent 80 0 proxy-only no-query no-digest originserver front-end-https=on login=PASS cache_peer 10.212.133.131 parent 80 0 proxy-only no-query no-digest originserver front-end-https=on login=PASS cache_peer 10.212.133.56 parent 80 0 proxy-only no-query no-digest originserver front-end-https=on login=PASS cache_peer 192.168.12.44 parent 80 0 proxy-only no-query no-digest originserver front-end-https=on login=PASS cache_peer_domain 10.212.133.52 mail.bar.com cache_peer_domain 10.212.133.102 mail.foo.com cache_peer_domain 10.212.133.56 domain1.domain1.com domain2.domain2.com domain3.domain3.com cache_peer_domain 10.212.133.131 mail.domain5.com autodiscover.domain5.com cache_peer_domain 192.168.12.44 owa.domain4.com hierarchy_stoplist cgi-bin ? acl QUERY urlpath_regex cgi-bin \? cache deny QUERY acl apache rep_header Server ^Apache broken_vary_encoding allow apache access_log /var/log/squid/access.log squid refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern . 0 20% 4320 acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl to_localhost dst 127.0.0.0/8 acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT acl owa_access myport 80 443 8000 http_access allow all owa_access http_access allow manager localhost http_access deny manager http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost http_access deny all http_reply_access allow all icp_access allow all coredump_dir /var/spool/squid extension_methods RPC_IN_DATA RPC_OUT_DATA The fact that NTLM is supposed to always require domain is strange indeed. I can confirm that it is negotiating NTLM too, we sync ActiveSync phones off of the proxy, and they require NTLM for auth. -Chris -----Original Message----- From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx] Sent: Friday, October 17, 2008 10:31 PM To: Chris Natter Cc: squid-users@xxxxxxxxxxxxxxx Subject: Re: Authentication Issue with Squid and mixed BASIC/NTLM auth Um, something weird is going on. I'm a little scared by the double sets of bad news. Can you confirm that your in-use systems are okay. I haven't led you to a point where anything serious is broken? (ie this is all isolated on a test machine where its okay to break?) Chris Natter wrote: > Hmmm, strange. I tested 2.7STABLE4, but it doesn't seem to be stripping > the DOMAIN, it will still accept only DOMAIN\USERNAME. Perhaps I'm > missing something? I've looked at it closer. And the patches which I saw earlier were for a slightly different helper (mapping NTLM front-end auth to LDAP backend) Henrik informs me that NTLM always needs the domain. Which makes me wonder why you didn't in 3.0. > > I also tested squid-3.1-20081016, built with a spec file adopted from a > squid3.0STABLE7 Redhat package: > > configure \ > --exec_prefix=/usr \ > --bindir=%{_sbindir} \ > --libexecdir=%{_libdir}/squid \ > --localstatedir=/var \ > --datadir=%{_datadir} \ > --sysconfdir=/etc/squid \ > --disable-dependency-tracking \ > --enable-arp-acl \ > --enable-auth="basic,digest,ntlm,negotiate" \ > > --enable-basic-auth-helpers="LDAP,MSNT,NCSA,PAM,SMB,YP,getpwnam,multi-do > main-NTLM,SASL" \ > --enable-cache-digests \ > --enable-cachemgr-hostname=localhost \ > --enable-delay-pools \ > --enable-digest-auth-helpers="password" \ > --enable-epoll \ > > --enable-external-acl-helpers="ip_user,ldap_group,unix_group,wbinfo_grou > p" \ > --enable-icap-client \ > --enable-ident-lookups \ > --enable-linux-netfilter \ > --enable-ntlm-auth-helpers="SMB,fakeauth" \ > --enable-referer-log \ > --enable-removal-policies="heap,lru" \ > --enable-snmp \ > --enable-ssl \ > --enable-storeio="aufs,coss,diskd,,ufs" \ > --enable-useragent-log \ > --enable-wccpv2 \ > --with-default-user="squid" \ > --with-filedescriptors=16384 \ > --with-dl \ > --with-openssl=/usr/kerberos \ > --with-pthreads > > And it looks like NTLM could be broken (I don't want to make > assumptions). I was unable to pass credentials in either the > DOMAIN\USERNAME or USERNAME format to OWA through squid. It also forced > an NTLM prompt for Firefox that I had to escape out of before I could > authenticate with BASIC auth. > > I wasn't able to test spell-check as I couldn't authenticate to the OWA > server. That is a worry for us. Thanks for testing and finding the issue. This is the first bug report on connection pinning. for our info: did you have the "login=PASS" on the cache_peer line? and woudld you mind sharing the config? Amos > > Thanks! > -Chris > -----Original Message----- > From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx] > Sent: Thursday, October 16, 2008 5:37 AM > To: Chris Natter > Cc: squid-users@xxxxxxxxxxxxxxx > Subject: Re: Authentication Issue with Squid and mixed > BASIC/NTLM auth > > Chris Natter wrote: >> We were having issues with spell-check in 3.0, I haven't tried any of >> the development builds to see if it was resolved though in a later >> release. > > >> OWA spell-check just seems to hang when you attempt to spell-check an >> email, or gives the "try again later" prompt. I saw some previous >> postings on the archive of the mailing list, but most of them are very >> outdated. >> >> I'll have to build an RPM of squid 2.7 and check to see if that solves >> both issues. > > Ah, now that you mention it I vaguely recall the topic as it flew past a > > while back. > > Yes, 2.7 is likely the most dependable to have both combos of fixes you > need. > > Without knowing the cause the spellcheck issue _may_ have been resolved > in 3.1. Both of the MS workarounds and 'unknown method' support are now > > present. If you have a spare moment and are inclined to test it please > let us know the result. If you still hit bad news for 3.1, its > definitely a bug that needs looking into at some point. > > Amos > >> Thanks for the help. >> >> -----Original Message----- >> From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx] >> Sent: Wednesday, October 15, 2008 6:46 PM >> To: Chris Natter >> Cc: squid-users@xxxxxxxxxxxxxxx >> Subject: Re: Authentication Issue with Squid and mixed >> BASIC/NTLM auth >> >>> Hey all, >>> >>> >>> >>> I've got a tough situation I'm hoping someone can help me with. >>> >>> >>> >>> We 'downgraded' from an old 3.0PRE build that a predecessor had setup >> on a >>> reverse proxy, to squid 2.6.STABLE20. The proxy runs your standard > OWA >>> over Reverse Proxy setup, with login=PASS to an OWA backend running >> with >>> BASIC/NTLM auth. We have to have the NTLM for phones that sync with >>> ActiveSync. >>> >>> >>> >>> It seems like something fundamental has changed in the way squid >> handles >>> auth from 3.0 to squid 2.6. Using firefox on 2.6, I can auth with > just >>> 'USERNAME', with IE on 2.6 we have to type "DOMAINUSERNAME" or >>> "USER@DOMAIN" now. Previously, with squid 3.0, just 'USERNAME' would >> work >>> for auth. >>> >>> >>> >>> While this seems trivial, anything harder than just 'USERNAME' > boggles >> a >>> lot of users. I'm assuming this has something to do with 'attempting >> NTLM' >>> negotiation? Is there a way around it in squid 2.6? >>> >> The cleaner @DOMAIN handling was only added to Squid 2.7+ and 3.0+. > You >> will need an upgrade again to one of those versions at least. >> >> What caused you to downgrade though? perhapse its been fixed now in > 3.1? >> Amos > > -- Please use Squid 2.7.STABLE4 or 3.0.STABLE9
