Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 1 subscriber
  • Views 2072 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

Proxy profile not using user group membership on policies.

hckeith
Hi All,

(Using Firmware 9.201-25)

I seem to be running into problems again with the proxy profile filter.  Having taken the advice on this thread, I reconfigured my profiles and thought it was all working fine.
However, after some testing, it appears that the user group a user is a member of is not being used by the filter.

Here's my scenario:

I have two AD backend users, each a member of separate AD backend groups.  User 1 is 'John.Smith', and he is a member of group S.CustomerService (tested in Role1.png).  The second user is me Keith.Oakley, and am a member of S.IT (tested in Role2.png).

Based on the advice in my other thread, I have created a single filter profile to be applied to all of our internal networks (profiles.png).  This active filter profile has several policies in it for each of our departments (Policies.png).  These policies apply to a specific user group (there are ones there for S.IT and S.CustomerService).

What I'm seeing though, is that whatever policy is at number 2 in the list of policies is applying to both users.  Our S.CustomerService policy should be blocking youtube as a test, but user John.Smith (a member of S.CustomerService) is getting the S.IT policy applied to him, even though he isn't a member of that user group (see policy test image 'Test John Smith.png'), and is being allowed to browse to youtube.

If I move the S.Ecommerce policy to position2, then that policy is being applied to both users, again neither user is a member of the S.Ecommerce user group (see policy test images 'Test john Smith2.png' and 'Test Keith Oakley.png').

This behavior doesn't seem to follow the explanation given to me of how the web proxy policy filter operates.  My understanding is that the source network is used first to match a proxy profile (all internal networks), then the profile goes through the policy list top to bottom and then matches the first policy the user is a member of (in this case a user group a user is a member of).

Strange that the policy at position 1 (S.Despatch) that only has users in it, not user groups, isn't being matched first.  It's always whatever policy is at position 2 that's using groups that is matched.

Have I possibly got the configuration wrong somewhere? Could something be overriding the policies I've set?  Have I even discovered a bug?

Any help anyone could offer on this matter would be greatly appreciated!

Thanks [:)]


This thread was automatically locked due to age.
Policies.zip
Parents
  • 0
    Thanks for the pointers guys.  I've been working off site today, and again tomorrow, so It's likely to be Friday when I'm able to get this information.
    One thing I did notice was that the 'policy test' appears to be correct with the information it gives me.  If I put the S.CustomerService policy at position 2, it did indeed block youtube for all group users running through the proxy rather than just the members of the s.customerservice group.  I'll do some more testing to confirm this.

    Bob, Apologies for the ZIP.  The forum seems to restrict post attachments to only 5.  In future, I'll split the initial post across a couple posts and attach the images separately to make things clearer.  I've had a look at rule#6, and yes we do sync our AD backend users to the UTM, we sync each night too, but from the sound of this we don't require it.  I guess if I needed to use an AD user anywhere in the config, I'd just create the user manually and set 'remote authentication' for the user (I really only use AD users in rules where I'm testing). We also are planning to do departmental reports, but they're not necessary at the moment.  The two users in S.Dispatch are synced AD users.

    I've just seemed to remember this working previously on this firmware, as when we started to add departments to the proxy a couple weeks back, the 'proxy test' feature was reporting that the correct policy was being applied to the correct user.  Perhaps something else has changed as Michael suggested and may not be something with the proxy, but with determining the AD group membership.

    Anyway, please bear with me until Friday when I should be able to get the information you have both requested.

    Thanks again!
  • 0 in reply to hckeith
    Hi Guys,

    I've attached the screenshots that Michael requested.

    Here's a couple log lines from today showing a couple users accessing via the proxy:

    [FONT="Courier New"]2014:06:20-15:58:43 UKMANPUTM01-2 httpproxy[16077]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="GET" srcip="172.17.50.62" dstip="54.244.39.18" user="PINSTRIPE\roxanne.nejad" statuscode="200" cached="0" profile="REF_HttProContaItvla (All Internal Networks)" filteraction="REF_HttCffSit (S.IT)" size="1027" request="0xb25f6aa0" url="ads.socialbakers.com/.../menu

    Roxanne.Nejad is a memeber of our S.Marketing group, not S.IT.

    [FONT="Courier New"]2014:06:20-16:00:02 UKMANPUTM01-2 httpproxy[16077]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="GET" srcip="172.17.50.38" dstip="37.58.96.130" user="PINSTRIPE\danika.walker" statuscode="204" cached="0" profile="REF_HttProContaItvla (All Internal Networks)" filteraction="REF_HttCffSit (S.IT)" size="0" request="0x105e0660" url="pfa.levexis.com/.../

    Danika.Walker is a member of our S.Ecommerce group, again, not S.IT.

    In both of the above cases, the policy set to match S.IT users is at position 2, below a policy at position 1 that only has users in it.


    Our domain is currently a 2003 one.  The internal domain is named after our original parent company that has since been disbanded, and hence is different to our external domain(s) (we dont' really have a way around this at the moment).  The UTM has been joined to this internal domain on the SSO tab.
    Our AD structure consists of users, split out into seperate OU's underneath a 'boohoo' OU.  Each separate OU is that of the department that user is working in.  Each department has a security group (ie, S.Ecommerce) contained within a 'groups' OU.  These security groups are used for mapping drives and determining access to various systems we have internally.  We also use these security groups in various areas in the UTM (such as the SSL VPN to determine who can use it).


    I also had a look through the log file Michael suggested and found these types of logs repeated through it.  Not sure if these indicate a problem or not?  I've attached an additional screenshot of how I have the groups set up under 'users and groups'.  unfortunately these logs mean nothing to me!

    [FONT="Courier New"]2014:06:20-00:19:33 UKMANPUTM01-2 [daemon:notice] ad-sid-sync.pl[20532]:  [ad-sid-sync] Syncing 1 Active Directory sid(s)
    2014:06:20-00:19:33 UKMANPUTM01-2 [daemon:warning] ad-sid-sync.pl[20532]:  [ad-sid-sync] Error in LDAP->search(): 0000208F: NameErr: DSID-031001F7, problem 2006 (BAD_NAME), data 8350, best match of:
    2014:06:20-00:19:33 UKMANPUTM01-2 [user:notice]         'S.Despatch'
    2014:06:20-00:19:33 UKMANPUTM01-2 [daemon:notice] ad-sid-sync.pl[20532]:  [ad-sid-sync] Syncing 1 Active Directory sid(s)
    2014:06:20-00:19:33 UKMANPUTM01-2 [daemon:warning] ad-sid-sync.pl[20532]:  [ad-sid-sync] Error in LDAP->search(): 0000208F: NameErr: DSID-031001F7, problem 2006 (BAD_NAME), data 8350, best match of:[/FONT]

    I hope this information is of use.  If there is anything else you think it would be useful to know, please just let me know what, and I'll try and get it for you.

    Thanks!

    EDIT:  Have just noticed that there is a firmware update available today (9.202-33) with this in the bugfixes:
    31386 Regression: Wrong AD SSO backend group matching since 9.200

    I wonder if that could resolve the problem...
Reply
  • 0 in reply to hckeith
    Hi Guys,

    I've attached the screenshots that Michael requested.

    Here's a couple log lines from today showing a couple users accessing via the proxy:

    [FONT="Courier New"]2014:06:20-15:58:43 UKMANPUTM01-2 httpproxy[16077]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="GET" srcip="172.17.50.62" dstip="54.244.39.18" user="PINSTRIPE\roxanne.nejad" statuscode="200" cached="0" profile="REF_HttProContaItvla (All Internal Networks)" filteraction="REF_HttCffSit (S.IT)" size="1027" request="0xb25f6aa0" url="ads.socialbakers.com/.../menu

    Roxanne.Nejad is a memeber of our S.Marketing group, not S.IT.

    [FONT="Courier New"]2014:06:20-16:00:02 UKMANPUTM01-2 httpproxy[16077]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="GET" srcip="172.17.50.38" dstip="37.58.96.130" user="PINSTRIPE\danika.walker" statuscode="204" cached="0" profile="REF_HttProContaItvla (All Internal Networks)" filteraction="REF_HttCffSit (S.IT)" size="0" request="0x105e0660" url="pfa.levexis.com/.../

    Danika.Walker is a member of our S.Ecommerce group, again, not S.IT.

    In both of the above cases, the policy set to match S.IT users is at position 2, below a policy at position 1 that only has users in it.


    Our domain is currently a 2003 one.  The internal domain is named after our original parent company that has since been disbanded, and hence is different to our external domain(s) (we dont' really have a way around this at the moment).  The UTM has been joined to this internal domain on the SSO tab.
    Our AD structure consists of users, split out into seperate OU's underneath a 'boohoo' OU.  Each separate OU is that of the department that user is working in.  Each department has a security group (ie, S.Ecommerce) contained within a 'groups' OU.  These security groups are used for mapping drives and determining access to various systems we have internally.  We also use these security groups in various areas in the UTM (such as the SSL VPN to determine who can use it).


    I also had a look through the log file Michael suggested and found these types of logs repeated through it.  Not sure if these indicate a problem or not?  I've attached an additional screenshot of how I have the groups set up under 'users and groups'.  unfortunately these logs mean nothing to me!

    [FONT="Courier New"]2014:06:20-00:19:33 UKMANPUTM01-2 [daemon:notice] ad-sid-sync.pl[20532]:  [ad-sid-sync] Syncing 1 Active Directory sid(s)
    2014:06:20-00:19:33 UKMANPUTM01-2 [daemon:warning] ad-sid-sync.pl[20532]:  [ad-sid-sync] Error in LDAP->search(): 0000208F: NameErr: DSID-031001F7, problem 2006 (BAD_NAME), data 8350, best match of:
    2014:06:20-00:19:33 UKMANPUTM01-2 [user:notice]         'S.Despatch'
    2014:06:20-00:19:33 UKMANPUTM01-2 [daemon:notice] ad-sid-sync.pl[20532]:  [ad-sid-sync] Syncing 1 Active Directory sid(s)
    2014:06:20-00:19:33 UKMANPUTM01-2 [daemon:warning] ad-sid-sync.pl[20532]:  [ad-sid-sync] Error in LDAP->search(): 0000208F: NameErr: DSID-031001F7, problem 2006 (BAD_NAME), data 8350, best match of:[/FONT]

    I hope this information is of use.  If there is anything else you think it would be useful to know, please just let me know what, and I'll try and get it for you.

    Thanks!

    EDIT:  Have just noticed that there is a firmware update available today (9.202-33) with this in the bugfixes:
    31386 Regression: Wrong AD SSO backend group matching since 9.200

    I wonder if that could resolve the problem...
Children
No Data