RE: [squid-users] RDP, Certificates and Squid

I am not certain with my response, but I have some ideas.

- Your ACL ordering, that is often the case, is most likely to blame.
Squid applies ACL's in order, top-down, and checks each ACL in their
order when "http_access" is being applied.
- I believe the ACL blocking access may be the 'PURGE' ACL, since the
server could be sending them "no-cache" headers. -- I may need
clarification on this behavior from another person, but you can attempt
to comment it out to see if this is true, or add something such as
"http_access allow PURGE GoDaddy".
- Any of your explicit "src / dstdomain" allows will not log usernames
returned by the "InternetUsers" ACL.
- Does the "Internet_Denied" and/or "FacebookUsers" nt_groups involve a
login prompt, or blind authentication?
- All Explicit allows / deny's should be placed _before_ authentication
routines.

>>> Damian Teasdale <damte_at_oppy.com> 2/23/2011 1:27 PM >>>
This is the whole list from what I can tell.

acl PURGE method PURGE
acl pdr dstdomain clients.performanceobjects.com
acl Blackberry src 192.168.x.3
acl Citrix src 192.168.x.34
acl InternetDenied external nt_group Internet_Denied
acl FacebookUsers external nt_group FacebookUsers
acl Facebook dstdomain .facebook.com
acl InternetUsers proxy_auth REQUIRED
acl Itrade dstdomain .itradenetwork.com
acl WindowsUpdate dstdomain .windowsupdate.microsoft.com
.windowsupdate.com .download.microsoft.com .update.microsoft.com
codecs.microsoft.com activex.microsoft.com crl.microsoft.com
c.microsoft.com
acl BusinessObjects dstdomain elmexternal.businessobjects.com
acl Auditors src 192.168.x.122 192.168.x.126 192.168.x.128
192.168.x.108
acl MapInfo src 192.168.5.139
acl MindLeaders dstdomain .mindleaders.com
acl DiscoverLink dstdomain .discoverlink.com
acl Knotia dstdomain .knotia.ca
acl Chep dstdomain .chep.com
acl GC dstdomain .gc.ca
acl GoDaddy dstdomain .godaddy.com

http_access deny InternetDenied
no_cache deny Itrade
http_access allow PURGE localhost
http_access deny PURGE
http_access allow GC
http_access allow Facebook FacebookUsers
http_access deny Facebook
http_access allow Blackberry
http_access allow Citrix
http_access allow WindowsUpdate
http_access allow BusinessObjects
http_access allow MapInfo
http_access allow MindLeaders
http_access allow DiscoverLink
http_access allow Knotia
http_access allow Chep
http_access allow Auditors
http_access allow pdr
http_access allow GoDaddy
http_access allow InternetUsers

# And finally deny all other access to this proxy
http_access deny all

Thanks

Damian Teasdale

-----Original Message-----
From: Chad Naugle [mailto:Chad.Naugle_at_travimp.com]
Sent: February/23/2011 10:19 AM
To: Damian Teasdale; 'squid-users_at_squid-cache.org'
Subject: Re: [squid-users] RDP, Certificates and Squid

In order to troubleshoot, we will need your entire ACL / http_access
portions copy/pasted, with sensitive portions edited, if need be.

>>> Damian Teasdale <damte_at_oppy.com> 2/23/2011 1:12 PM >>>
Here is our environment:

LAN users all go through the proxy for internet access, works fine. A
few users need access to RDP to an external partners Terminal Server.
The terminal server has a Certificate issued by GoDaddy.com. When the
users on the LAN attempt to connect to the external Terminal Server I
don't think that they can authenticate the certificate. I watch the
access.log and I see these lines written:

1297896161.739 70 192.168.x.xTCP_DENIED/407 1962 GET
http://certificates.godaddy.com/repository/gd_intermediate.crt -
NONE/- text/html
1297896161.742 0 192.168.x.x TCP_DENIED/407 2158 GET
http://certificates.godaddy.com/repository/gd_intermediate.crt -
NONE/- text/html
1297896161.745 2 192.168.x.x TCP_DENIED/407 1962 GET
http://certificates.godaddy.com/repository/gd_intermediate.crt -
NONE/- text/html
1297896162.086 319 192.168.x.x TCP_DENIED/407 2055 GET
http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab

- NONE/- text/html
1297896162.089 0 192.168.x.x TCP_DENIED/407 2251 GET
http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab

- NONE/- text/html
1297896162.091 2 192.168.x.x TCP_DENIED/407 2055 GET
http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab

- NONE/- text/html

I have tried putting in some acl's for this but it doesn't seem to
make
a difference, here are the acl's as I have them setup:

acl GoDaddy dstdomain .godaddy.com

http_access allow GoDaddy

There are a lot of other acl's that we have setup but did not include
them all, but could if needed. Any ideas about how to get this
working?
As a work around I have put in a separate ACL to allow that LAN
computers IP address direct access and it works, but this is not
ideal.

The Oppenheimer Group ---- CONFIDENTIAL

This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete
the original. Any other use of the email by you is prohibited.

Travel Impressions made the following annotations
-------------------------------------------------------------
"This message and any attachments are solely for the intended
recipient
and may contain confidential or privileged information. If you are
not
the intended recipient, any disclosure, copying, use, or distribution
of
the information included in this message and any attachments is
prohibited. If you have received this communication in error, please
notify us by reply e-mail and immediately and permanently delete this
message and any attachments.
Thank you."

The Oppenheimer Group ---- CONFIDENTIAL

This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete
the original. Any other use of the email by you is prohibited.

Travel Impressions made the following annotations
-------------------------------------------------------------
"This message and any attachments are solely for the intended recipient
and may contain confidential or privileged information. If you are not
the intended recipient, any disclosure, copying, use, or distribution of
the information included in this message and any attachments is
prohibited. If you have received this communication in error, please
notify us by reply e-mail and immediately and permanently delete this
message and any attachments.
Thank you."
Received on Wed Feb 23 2011 - 18:56:03 MST