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

Bypass blocking doesn't work for backend groups?

FormerMember
FormerMember
Hi - I searched and didn't find this addressed. I'm preparing to allow users to bypass blocking to (for example) YouTube. I created a group in AD, created a matching group name in the Astaro and specified "remote" authentication. When I place a user in the AD group, and they try to unblock the URL, it gives them "Invalid username and password." However, if I create a matching user on the Astaro and specify "remote" authentication, it lets them log in and bypass the URL. Is there some "trick" to getting groups to do the same thing? I've tried this with the "backend sync" both selected and deselected.
Thanks!


This thread was automatically locked due to age.
  • This is a known issue in 8.201-8.203 that can happen if the Domain Controller becomes unresponsive.  This causes a lock on the AUA cache.  You should be able to solve this temporarily with a reboot.  Code has been added in 8.300, which will avoid the cache locking on the Astaro.

    If you choose, you can install the soft-release at https://community.sophos.com/products/unified-threat-management/astaroorg/f/52/t/28261 of wait until 8.300 GA is released, shortly after the new year begins.
  • FormerMember
    0 FormerMember
    That's good information and very helpful! Thanks.
  • FormerMember
    0 FormerMember
    Hi, just revisiting this finally, after our ASG625's were updated to 8.300 (successfully!) and it still appears that the feature to bypass blocking doesn't work on backend groups. It's not a case where "the" domain controller becomes unresponsive, because we have 5 domain controllers, 2 of which are defined in the Astaro as an availability group. Now, I'm beginning to think it is only supposed to work for locally-authenticated users and groups.
    So, with that in mind, how do I create 4500 user accounts on the Astaro without sacrificing performance and also is there a danger that if the Astaro starts authenticating users using its local user cache, will it start failing with users who have just changed their Windows passwords? Does anyone have any advice in this respect?
    Thanks in advance...
  • turn on the user prefetch inside the AD sso section.  That will populate the users for you.  Set the prefetch for daily so the Astaro will at least daily keep itself updated with your domain's users list.
  • Gary, I'm confused.  Why would you have two different domain controllers in an availability group?  That might be the root of your problem.

    Cheers - Bob
  • FormerMember
    0 FormerMember
    thanks for the suggestion William. I'm just concerned if the ASG625 will suffer a performance hit by syncing all 4k or so users. But I can see how that would allow this to work. BAlfson, simply because it makes sense for redundancy to have not just one dedicated DC, but instead, point authentication to an availability group containing more than one DC. Then, if one is not responding, the next one does. (Or is that not what is implied by use of an Availability Group?) Any correction to a misconception is welcome!
  • Well, if your DCs are configured correctly, they will perform this function automatically for domain authentication requests.  I'm not an MCSE, so I can't give you detailed instructions on how to accomplish this, but I know that that's how Astaro expects to see things.

    If you suspect that you do have your trust relationships correctly configured, you might try to replace the Availability Group with a simple Host definition for the "nearest" DC, being sure to leave 'Interface: >' instead of binding this (or any Host/Network!) defintion to a specific interface.

    Cheers - Bob
  • Then again, if you're using AD-SSO, the Availability Group should have no effect.  SSO depends on the domain join, not on any AD server defined on the 'Servers' tab.

    Please post a picture of your group definition.  Also, watch the AUA Live Log when attempting to bypass as a Backend Group member - what do you see?  Does the GPO for Proxy Settings specify the internal FQDN of the Astaro or a fixed IP?

    Cheers - Bob
  • FormerMember
    0 FormerMember
    Thanks again, BAlfson. There's nothing wrong with our AD at all. And our configuration is working properly for authentication in every respect, and the tests on the Authentication Servers node work fine.  What I found out through some experimentation is that the only way the Bypass feature works is if you have a user account on the Astaro (even if that user account is a remotely authenticated one.) Creating a backend-authenticated group and adding members in AD doesn't work.

    I created a backend-authenticated group called "BypassBlock" on the Astaro, and then in AD, I added a test user. When trying to unblock as that user, it would not recognize my authentication. I then created the user on the Astaro, authenticated remotely. When I added the user to the group in AD again, it worked fine.

    I then set up the automatic synchronization of user accounts on an overnight interval. The next day, I repeated the test with several new test AD accounts, and adding the test users to the "Bypass Block" AD group allowed them to unblock URL's. So, my conclusion is that the user accounts must exist locally on the Astaro for this to properly work. I'm okay with that. Thanks for your suggestions! They did lead me to the answer. My next project is to determine how I can make these unblocks temporary (so that they aren't just always unblocked forever for each user).
  • Thanks, Gary, for posting the results of your test.  I also tested this with 8.300, and it worked fine.  Afterwords, I confirmed that the user had not been created on the Astaro, so this was purely a backend group membership.

    What did the User Authentication log show when the AD user wasn't allowed to bypass?

    Cheers - Bob