> 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. >
Doh, here I was still thinking along the lines of you doing auth in squid. Now I've got me head straight. For the config below the only thing that I think matters to auth in usage is the passthru behavior. OWA itself must kick off a domain controller authentication with the client which just funnels through squid on its way back to OWA. Which leaves me stumped as to why the behavior change happened. > 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 Did you elide the defaultsite= parameter from here? > 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. 'needs' is relative to the end authenticator. It can be supplied by any of the intermediaries by adding to the headers. Small sites often set it in samba and default it. Various of the helpers is squid do the same thing, replacing whats given. But you are not using those, which confused me earlier thinking you were. > -Chris > > -----Original Message----- > From: Amos Jeffries [mailto:[EMAIL PROTECTED] > Sent: Friday, October 17, 2008 10:31 PM > To: Chris Natter > Cc: squid-users@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:[EMAIL PROTECTED] >> Sent: Thursday, October 16, 2008 5:37 AM >> To: Chris Natter >> Cc: squid-users@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:[EMAIL PROTECTED] >>> Sent: Wednesday, October 15, 2008 6:46 PM >>> To: Chris Natter >>> Cc: squid-users@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 >>>> "[EMAIL PROTECTED]" 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 >
