RE: [squid-users] Squid, Exchange 2007 RPC, certificates and the rabbit hole

-----Original Message-----
From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
Sent: Thursday, January 28, 2010 9:21 AM
To: squid-users_at_squid-cache.org
Subject: Re: [squid-users] Squid, Exchange 2007 RPC, certificates and the rabbit hole

Arch Willingham wrote:
> I hope one of y'all is out there and can help. I am trying to replace ISA server with squid. I have followed every guide I can find to make this work (Exchange 2007 behind squid). I have tried multiple versions of squid, multiple versions of Linux, multiple versions of squid.conf, etc (I have tried the ones at http://wiki.squid-cache.org/ConfigExamples/Reverse/OutlookWebAccess and http://wiki.squid-cache.org/ConfigExamples/Reverse/ExchangeRpc ).
>
> I can't get it to work. I can more or less get into OWA (it gives me a funky log in screen that looks different than via the way it worked with ISA) ) but http over RPC just asks for the password over and over and over. If I bypass squid, and sent the 443 straight to the Exchange server, it works fine.
>
> There are so many variables it is frustrating and I want to duplicate a site someone has working. Can anyone help?
>

NOTE:
   The Squid wiki was written for Exchange 2003. I _know_ things have
changed somewhat for Exchange 2007.

If there is anyone out there who got this working or wants to try,
_please_ let us know what to update in the wiki.

> Questions:
>
> 1. What did you do about the certificates? I have a SAN Certificate and exported it from the exchange server and have put it in the appropriate lines in squid.conf. Some of the guides mention multiple certificates (one being a client and one being a server) but some guides shows all of them being the same one "/root/ssl/www.domain.com.crt key=/root/ssl/www.domain.com.key" - how and where did you get your certificate (I.E. did you export it from IIS in Exchange?)? I only have one certificate.

With HTTPS-Front_End AFAIK, the certificate generation is (a) Exchange,
since it is the one telling clients to auth, or (b) any random machine
you pick to use, its simply installed as a .pem for use
Squid->EmailClient (TLS style).

> 2. What is the deal on something called "Intermediate Certificates"?
> 3. On your Outlook clients, under "logon network security" do you have them set for "negotiate authentication", "Kerberos password authentication" or "password authentication (NTLM)"?

(NP: I'm doing this off the top of my head first thing in the am, so
double check it.)

There was some ranting about the meanings, what I picked up was:
  "negotiate authentication" == Kerberos authentication
  "Kerberos password authentication" == NTLMv2 authentication
  "password authentication (NTLM)" == NTLMv1 authentication / or was it
LanMan authentication? somethign old anyway.

> 4. On your Outlook clients, under "proxy authentication settings" do you have them set for "basic authentication" or "NTLM authentication"?

"basic" means clear-text base64 encoded almost universally in web-speak.
Pick one that matches your Exchange settings. (provided Squid can pass
it thru).

> 5. I come from the Windows world and I have not done diddly squat with apache on the squid server. I just let it build the default. Is that OK? Do I need to do anything with apache?

Meh. As long as whoever set it up knows what its about.
AFAIK its not involved with the Exchange RPC config.

> 6. I have the main firewall in the building forwarding all the 443 packets to the squid/apache server and nothing else (I.E. the squid/apache server does not face the internet...its gets packets forwarded to it from the firewall). Do you have any other ports hitting your squid server?

"forwarding" I do_ hope you really mean routing.
If DNAT / REDIRECT is involved things get useless fast.

>
> My squid is below.do you see anything wrong (it is using squid 3.1 on Fedora 12 and has the "connection-auth=off" added and the " RPC_IN_DATA RPC_OUT_DATA" dropped )?
>

extension_methods in Squid-3.1 is obsolete. All valid methods are
'supported' as in pass-thru.
HTTP non-conforming extension methods have undefined behavior. From
one-way connectivity up to and including instant connection termination
for the client.

connection-auth is required to be AUTO or ON for NTLM and Kerberos to work.

>
> # extensions for Exchange RPC over HTTPS
> # I dropped this line for squid 3.1??
> # extension_methods RPC_IN_DATA RPC_OUT_DATA

yes.

>
> # squid server is 10.0.1.135
> # Exchange server is 10.0.1.101
> # our external domain is ourexternaldomain.com
>
> # here comes the relay configuration
> # here comes the relay configuration
> # I added connection-auth=off for squid version 3.1
>
> https_port 10.0.1.135:443 connection-auth=off accel cert=/certifs/temp/cert.pem key=/certifs/temp/server.key defaultsite=ourexternaldomain.com vhost

aonnection-auth=of only if the Squid is handling authentication. If the
  backend needs to see it, this reduces support to basic or digest auth.

>
> cache_peer 127.0.0.1 parent 443 0 no-query no-digest originserver login=PASS ssl sslflags=DONT_VERIFY_PEER sslcert=/certifs/temp/cert.pem sslkey=/certifs/temp/server.key name=webServer
> cache_peer 10.0.1.101 parent 443 0 no-query no-digest originserver login=PASS front-end-https=on ssl sslflags=DONT_VERIFY_PEER sslcert=/certifs/temp/cert.pem sslkey=/certifs/temp/server.key name=exchangeServer
>
>
>
> # List of acceptable URLs to send to the Exchange server
> acl exch_url url_regex -i ourexternaldomain.com/exchange
> acl exch_url url_regex -i ourexternaldomain.com/exchweb
> acl exch_url url_regex -i ourexternaldomain.com/public
> acl exch_url url_regex -i ourexternaldomain.com/iisadmpwd
> acl exch_url url_regex -i ourexternaldomain.com/oma
> acl exch_url url_regex -i ourexternaldomain.com/microsoft-server-activesync
> acl exch_url url_regex -i ourexternaldomain.com/rpc
> acl exch_url url_regex -i ourexternaldomain.com/rpcwithcert
> acl exch_url url_regex -i ourexternaldomain.com/exadmin
> acl exch_url url_regex -i ourexternaldomain.com/owa
> acl exch_url url_regex -i ourexternaldomain.com/autodiscover
> acl exch_url url_regex -i ourexternaldomain.com/oab
> acl exch_url url_regex -i ourexternaldomain.com/ews
>
>
> # Send the Exchange URLs to the Exchange server
> cache_peer_access exchangeServer allow exch_url
>
> # Send everything else to the webserver
> cache_peer_access webServer deny exch_url
>
> # This is to protect ourselves
> never_direct allow exch_url
>
> #acl chunked dstdomain owa.ourexternaldomain.com
> #header_access Accept-Encoding deny chunked
>
>
> #acl EXCH dstdomain owa.ourexternaldomain.com
> #cache_peer_access exchangeServer allow EXCH
> #cache_peer_access webServer deny EXCH
> #never_direct allow EXCH
>
> # settings caching and logging  optional
> redirect_rewrites_host_header off
> cache_mem 32 MB
> maximum_object_size_in_memory 128 KB
> #cache_log none
> #cache_store_log none
>
> #access_log /var/log/squid/access.log squid
> acl all src

?WTF. Kill the above. "all" is built-in now.

> acl to_local dst 127.0.0.1/32
> acl to_wsrv dst 10.0.1.135/32
>
>
>
>
> # Allow everyone through, internal and external connections
> http_access allow all
> miss_access allow all
>
>
>
> http_port 3128
>
>
> hierarchy_stoplist cgi-bin ?
>
>
>
> # Recommended minimum configuration:
> #
> acl manager proto cache_object
> acl localhost src 127.0.0.1/32
> acl localhost src ::1/128
> acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
> acl to_localhost dst ::1/128
>
> # Example rule allowing access from your local networks.
> # Adapt to list your (internal) IP networks from where browsing
> # should be allowed
> acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
> acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
> acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
> acl localnet src fc00::/7 # RFC 4193 local private network range
> acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines
>
> 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
>
> #
> # Recommended minimum Access Permission configuration:
> #
> # Only allow cachemgr access from localhost
> http_access allow manager localhost
> http_access deny manager
>
> # Deny requests to certain unsafe ports
> http_access deny !Safe_ports
>
> # Deny CONNECT to other than secure SSL ports
> http_access deny CONNECT !SSL_ports
>
>
>
> #-------------------------------------------------------------------------------end-----------------------------------
>

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE7 or 3.0.STABLE21
   Current Beta Squid 3.1.0.15
Amos and Brett:
Thanks for responding!
I have read as much as I could but still don't grasp a lot of the stuff in squid so please bear with me with some of my dumb questions.
1. The certificate question. I saw your answer but at http://wiki.squid-cache.org/ConfigExamples/Reverse/ExchangeRpc there are two lines that mention a certificate. One being  SSL Certificate to present to Exchange Server (/path/to/certificate) and one being SSL certificate to present to Clients (/path/to/clientcertificate). Here is what they used in the example:
Publish the RPCoHTTP service via SSL
https_port ip_of_squid:443 cert=/path/to/clientcertificate defaultsite=rpc_domain_name
cache_peer ip_of_exchange_server parent 443 0 no-query originserver login=PASS ssl sslcert=/path/to/certificate name=exchangeServer
I had no idea what they were talking about so I just used the certificate I exported from Exchange for both lines but that was a SWAG and something tells me I was wrong. Can you or Brett offer some guidance on how you have done it in an install that worked?
2. On the Apache question - the example has a place that says " defaultsite=rpc_domain_name " and I was not sure if the " defaultsite" refered to an Apache site on the same server or something else.
3. The connection-auth=off question - I saw where you said "only if the Squid is handling authentication. If the 
  backend needs to see it, this reduces support to basic or digest auth." And if you heard the sound "woosh" that was the comment going over my head. I don't know the answer...with Exchange 2007, what am I supposed to use? Brett...what did you use?
4. The question about ""forwarding" I do_ hope you really mean routing. If DNAT / REDIRECT is involved things get useless fast.".....hmmm. I have a product called "Ebox" running on the firewall (sits on Ubuntu). I picked the option called "port forwarding". How would I tell? That server's /etc/iptables.up.rules has two lines like this:
-A fredirects -d 192.168.10.2 -i eth0 -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A PREROUTING -d 65.25.30.23 -i eth0 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.10.2
Thakns so much for y'all's help!
Arch