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

Backend Group membership based on Container

addrockk
I'm switching from eDir SSO to AD SSO, and I'm having some difficulty with group processing. In eDir, I could make a group with backend membership, and point it at an eDir Organization Unit, and everything worked. 
If I try to do that in AD, it simply doesn't work. It only works when I point it at a group object. Do I really have to maintain a separate group for every OU, or is there a way to get it to recognize OU's for backend membership groups when using AD?

TIA,
Adam


This thread was automatically locked due to age.
  • 0
    You are correct, Adam - only manually-created AD Security Groups can be used for Backend Group definitions.  I haven't seen a situation where proxy access was determined by OU - perhaps you could explain why you were doing that with eDir-SSO (which I haven't used/installed).

    Please consult HTTP-S Proxy Access with AD-SSO and make suggestions for improvement.

    Cheers - Bob
    PS Version - 8.310?
  • 0 in reply to BAlfson
    I haven't seen a situation where proxy access was determined by OU - perhaps you could explain why you were doing that with eDir-SSO (which I haven't used/installed)


    My directory is set up as:
    Users
    -Staff
    -Students
    --2014
    --2015
    --2016
    --etc (By Graduation year)...


    I had a Students group in the UTM that pointed to the Students OU, which included all OUs underneath it, and a Staff group that pointed at the Staff OU. Needing to maintain a separate group for an entire OU kind of defeats the purpose of OU's/Containers, IMO.  Since AD doesn't support Dynamic Groups, It looks like I'll be hacking together an awkward script to build a "shadow" group. [:(]
  • 0
    If you have a Staff Group, aren't the Students, by default, all in the other group?  You could use an AD-SSO Profile with a Staff Filter Assignment first, and a Filter Assignment with no names or group second.  Only the Staff will qualify for the first Assignment and everyone else logged into AD will qualify for the second one.

    That leaves you the ability to use the default profile (the first three tabs of Web Filtering) in Transparent mode for guests that have no AD login.

    Can that simplify your task?

    Cheers - Bob
    PS That said, if that capability exists for eDir-SSO, it should make an easy feature to add for AD-SSO.
    PPS If you haven't already, you might consider what I call Rule #6:

    There are only three reasons to sync users from AD to the ASG/UTM:

    • The user should be able to log on to a Remote Access VPN that uses certificates to authenticate the user.
    • Email Protection is enabled and the user should receive Quarantine Reports and be able to manage personal black/whitelists and/or use Email Encryption/Signing.
    • You want to do Reporting by Department for Web Protection (and I consider it a bug to require this when doing AD-SSO).

    There's no other reason to sync users to WebAdmin - certainly not with AD-SSO.

  • 0 in reply to BAlfson
    If you have a Staff Group, aren't the Students, by default, all in the other group?  You could use an AD-SSO Profile with a Staff Filter Assignment first, and a Filter Assignment with no names or group second.  Only the Staff will qualify for the first Assignment and everyone else logged into AD will qualify for the second one.



    I don't have a Staff AD Group, I have a Staff Group in the UTM that used to point to the staff OU. Now I have to create an AD group to point it at. Same problems as the Students. 

    The biggest issue I have with this is that I don't always create users, and others that don't do it often forget to put people in the right groups, or to use the user templates set up. It adds a layer that relies on humans remembering that the process that has worked for 15 years has changed.
    Also, students accounts are automatically generated when they are enrolled in our student management system. Currently, they aren't added to any groups when they are created, and I'm not sure if I do that automatically. 


    That leaves you the ability to use the default profile (the first three tabs of Web Filtering) in Transparent mode for guests that have no AD login.


    I can configure a fallback action of Default filter action and it will change the operation mode to transparent as well? Even if the network-based profile mode is set to standard mode?


    PS That said, if that capability exists for eDir-SSO, it should make an easy feature to add for AD-SSO.


    Thanks; I'll add one now. 


    PPS If you haven't already, you might consider what I call Rule #6:

    There are only three reasons to sync users from AD to the ASG/UTM:

    • The user should be able to log on to a Remote Access VPN that uses certificates to authenticate the user.
    • Email Protection is enabled and the user should receive Quarantine Reports and/or be able to manage personal black/whitelists and/or use Email Encryption/Signing.
    • You want to do Reporting by Department for Web Protection (and I consider it a bug to require this when doing AD-SSO).

    There's no other reason to sync users to WebAdmin - certainly not with AD-SSO.



    I'm not syncing/creating users on the UTM unless they log into the user portal (which only VPN users would be doing). I made that mistake with eDir when I first set it up and had 4000 users and user networks to load everytime I brought up a definitions list. It was awful. ;-)
  • 0
    Feature request is Here if anyone is interested.
  • 0
    I can configure a fallback action of Default filter action and it will change the operation mode to transparent as well? Even if the network-based profile mode is set to standard mode?

    No, you must create a separate Profile using Transparent.  I usually just use the default for that.

    In the model I suggested, the students don't need to be in a group.  Everyone with an AD login will be selected for the first profile.  Those in the Staff Group will be selected for the first Filter Assignment in the Profile.  Everyone else configured for Standard mode will qualify for the second group.  Anyone not configured for Standard will not qualify for the Profile.

    Cheers - Bob
  • 0 in reply to BAlfson
    No, you must create a separate Profile using Transparent.  I usually just use the default for that.

    In the model I suggested, the students don't need to be in a group.  Everyone with an AD login will be selected for the first profile.  Those in the Staff Group will be selected for the first Filter Assignment in the Profile.  Everyone else configured for Standard mode will qualify for the second group.  Anyone not configured for Standard will not qualify for the Profile.

    Cheers - Bob


    So both profiles would be configured for the same network, with the first setup as standard. If users don't explicitly point at the proxy, they are dropped through to the transparent profile (or else back to the default)? Am I understanding that correctly?
  • 0
    Correct, so your Fallback for the AD-SSO Profile can be the Default Block Action.

    Cheers - Bob
  • 0 in reply to BAlfson
    Correct, so your Fallback for the AD-SSO Profile can be the Default Block Action.

    Cheers - Bob


    OK one last question about this:
    What's the difference between "Default Filter Action" and "Default content filter block action"?
  • 0
    The "Default Filter Action" is defined on the first three tabs in 'Web Filtering' (and some on the 'Advanced' tab).

    The "Default content filter block action" that blocks everything is auto-created by the installation wizard and is found on the 'Filter Action' tab of 'Web Filtering Profiles'.

    Cheers - Bob