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

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.
Parents
  • 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?
  • 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. [:(]
Reply
  • 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. [:(]
Children
No Data