RE: [squid-users] Authentication Issue with Squid and mixed BASIC/NTLM auth

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_at_treenet.co.nz]
Sent: Friday, October 17, 2008 10:31 PM
To: Chris Natter
Cc: squid-users_at_squid-cache.org
Subject: Re: [squid-users] 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_at_treenet.co.nz]
> Sent: Thursday, October 16, 2008 5:37 AM
> To: Chris Natter
> Cc: squid-users_at_squid-cache.org
> Subject: Re: [squid-users] 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_at_treenet.co.nz]
>> Sent: Wednesday, October 15, 2008 6:46 PM
>> To: Chris Natter
>> Cc: squid-users_at_squid-cache.org
>> Subject: Re: [squid-users] 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_at_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