Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 1 subscriber
  • Views 3069 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Web Filter Proxy Profiles not working as they should

BurtonComputerServices
I have two groups setup in Active Directory, one called "Filter-FullAccess" and one called "Filter-PayPal".  I then have under Filter Actions have a white list called "Websites For Everyone" and one called "PayPal".  Under filter assignments I have three assignments:  "Filter - PayPal" which is assigned the PayPal white list and Filter-PayPal group, "Filter - Full Access" which is assigned the Default Content Filter and the Filter-FullAccess group, and the last one called "Filter - Sites for Everyone" which is assigned to Authenticated users. 

Based on the help file I have a single Proxy Profile called "Access for Users" as I only have one subnet and the users are all in it.  In that profile I have my three filter assignments.  Sites for everyone is first, PayPal is second, and full access is third.  The default action is block.  Here is what it looks like (it is the only profile):

Transparent mode enabled
Source networks: Any
Filter Assigments: 
Filter - Sites Allowed For Everyone
Filter - PayPal
Filter - Full Access
Fallback action: Default content filter block action

Per the help file this should work but it doesn't.  I am using Transparent proxy mode with Agent authentication because AD-SSO would not work (https://community.sophos.com/products/unified-threat-management/astaroorg/f/55/t/45791).  I am logged in with a user in the "Full Access" group and I can verify the Astaro knows the user is in the right group (I have tested the users login against Definitions and Users -> Authentication Servers -> Servers).   If I try to go to google.com (which is definitely in the default content) I get this:

2013:02:24-18:39:11 Firewall1 httpproxy[6510]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="GET" srcip="10.0.0.23" dstip="" user="FullAccessUser" statuscode="403" cached="0" profile="REF_HttProFullAccesUsers (Access for Users)" filteraction="REF_HttCffSitesAllowFor (Sites Allowed For Everyone)" size="6475" request="0xaa87478" url="www.google.com/" exceptions="" error="" category="145" reputation="trusted" categoryname="Search Engines"

So it's not matching the first filter assignment.  So I try PayPal and get this:

2013:02:24-18:41:18 Firewall1 httpproxy[6510]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="GET" srcip="10.0.0.23" dstip="" user="FullAccessUser" statuscode="403" cached="0" profile="REF_HttProFullAccesUsers (Access for Users)" filteraction="REF_HttCffSitesAllowFor (Sites Allowed For Everyone)" size="6475" request="0xa9ae2d8" url="www.PayPal.com/" exceptions="" error="" category="145" reputation="trusted" categoryname="Search Engines"

Again it's not matching and since it's not in my "Sites allowed for everyone" group it gets blocked by default.  But if I try something that is in the sites allowed list it works fine (weather.com in this case):

2013:02:24-18:43:17 Firewall1 httpproxy[6510]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="GET" srcip="10.0.0.23" dstip="24.143.206.176" user="FullAccessUser" statuscode="200" cached="0" profile="REF_HttProFullAccesUsers (Access for Users)" filteraction="REF_HttCffSitesAllowFor (Sites Allowed For Everyone)" size="108585" request="0xaa6c330" url="www.weather.com/.../html" 


Any ideas why this wouldn't work?

-Allan


This thread was automatically locked due to age.
  • 0
    If I understand correctly you want to have the "Sites Allowed for Everyone" filter assignment to be applied to all users and then additional access based on if the user is a member of the other two filter assignments?

    The UTM will apply only the first filter assignment that matches the user and will not apply additional filter assignments in a cumulative fashion. Based on this you might have to reconfigure how you have your filter assignments configured.
  • 0
    You are correct so I reversed the order:

    Filter - Full Access
    Filter - PayPal
    Filter - Sites Allowed For Everyone

    But it still is not working.  I have 6 users in the "Full Access" group, 2 in the "PayPal" group, then everyone in the last group (authenticated users).  So based on the help file it should process in the correct order but it's not...it's still saying everyone is in the last group.  But I see the names in the web filter log.

    I'm guessing that since I'm using the AAA I cannot use a AD backend group even though it validates and the name shows up in the web filter log.  At least that's what I'm going to go with.  I'll have to figure out how to manually add each user in.
  • 0
    Allan, this all will be extremely easy and elegant once you figure out what was causing your problem with SSO.

    However, I expect that you also would have the current problem because of an issue with the Backend Groups.  Please [Go Advanced] below and attach a picture of an edit of the "Full Access" group definition.

    Cheers - Bob
  • 0
    It doesn't make any sense Bob.  AD-SSO definitely didn't see the users...at least the Agent does.  I'm positive the groups are setup correctly....I can verify that a user authenticates correctly...it simply doesn't work for actual access.  

    So I tried this...I went to Definitions and Users -> Authentication Servers -> Advanced and under "Prefetch directory users" I selected my "Filter-FullAccess" and "Filter-PayPal" groups from AD then clicked Prefetch Now.  Sure enough all the users in these two groups came through and are listed under "Users and Groups" and each one says:

    Remotely authenticated 
    synced from adirectory

    under it with the proper user ID and email address.  I turned on Prefetch for once a day then created new "groups" directly on the Astaro and put these now "local" users into them.  Hopefully I can try that tonight and see if it will finally recognize that the user is in those groups.  If not my only option left is to give out static IP addresses and assign access from that.  The customer isn't very pleased with how long this is taking and it doesn't help that the company they purchased the Astaro from is of no use (they gave up without even looking into the config, which they have access to, and told me to contact Astaro directly).

    -Allan
  • 0
    Well the above works.....prefetching the users then putting them into "local" groups on the Astaro and assigning those local groups to the filter assignments.  So it's a work around at least....
  • 0
    It doesn't make any sense Bob. AD-SSO definitely didn't see the users

    You need another set of eyes on this - this has worked well for many years.

    I expected that the new approach with synced users and local groups would work if the filters were assigned correctly.

    Cheers - Bob
  • 0 in reply to BAlfson
    You need another set of eyes on this - this has worked well for many years.

    I expected that the new approach with synced users and local groups would work if the filters were assigned correctly.

    Cheers - Bob


    Post just for your info Bob.  I'm positive the groups were setup right as again I can validate a user against them and it works properly.  It just doesn't work for Web Filtering.  So in the first attachment is my "Full Access" group set to AD backend.  In the second you can see me test a user and they show up in both the Full Access from AD group and the Full Access "local" group.  However the web filter WILL NOT WORK using the AD group even though the user validates against it.  The "local" group in which I added the user (using prefetch) works perfectly.

    I don't disagree with you that the same issue I was having where the users weren't pulling up using AD-SSO is the reason it's still not working.  The problem is I did everything I was supposed to, multiple times, and simple can't get it to work which the Agent at least is validating the users and allowing the local groups to work. 

    -Allan
  • 0
    Since that looks correct, it's more likely the configuration of 'Proxy Settings' in your Windows clients.  Do you see "auth_adir_auth_crap_callback" in the Web Filtering log when you're trying AD-SSO?  If so, replace the numeric IP of your UTM with an FQDN that resolves to the local IP; this forces the use of kerberos instead of NTLM.

    Cheers - Bob
  • 0
    The proxy setup is pretty straight forward and again I'm positive it was correct.  "Use a proxy server" was checked and the FQDN of the Astaro was entered along with port 8080.  Pyass proxy server for local addresses was entered with the local subnet.  Use the same proxy for all protocols was also checked.  All these settings were set through GPO.  The Astaro's FQDN was entered into DNS and as mentioned before it was able to join the domain correctly and showed up in the computer OU.

    I never saw a "auth_adir_auth_crap_callback" in the Web Filter log....I only saw the actual access messages with allowed or blocked with no user name (user="") which makes sense why the groups didn't work.  Weird that "Authenticated Users" did work but the groups based on backend AD didn't.
  • 0
    Side note as a just in case:  The customer isn't very big and they have a single server (AD, DHCP, DNS, Email, file, printers, everything) running Server 2003 but the domain and forest are both in Server 2000 mode.  Not sure if that makes a difference or might be causing a issue since we are dealing with authentication stuff.