Thanks for helping me to understand this. I think the way this really works has more utility than what I was thinking. I can actually accomplish what I want using two ldap instance authorizations. One for the User look up, then one for the Group VLAN setting. There were going to be two ldap queries in any case... Thanks, Robert ________________________________________ From: freeradius-users-bounces+robert.roll=utah.edu@lists.freeradius.org [freeradius-users-bounces+robert.roll=utah.edu@lists.freeradius.org] On Behalf Of Phil Mayers [p.mayers@imperial.ac.uk] Sent: Wednesday, March 23, 2011 3:14 AM To: freeradius-users@lists.freeradius.org Subject: Re: Group checking in ldap authorization On 03/22/2011 06:15 PM, Robert Roll wrote:
This does seem to work differently than I thought..
Yeah, like I say: it's a virtual attribute that does the group search when you "compare" it.
My model was something like ntlm_auth, which allows an authentication, but one can also require membership in a group at the same time...
i.e. ntlm_auth ... --require-membership-of={SID|Name}
Nope, different.
What I was really hoping is that I could look someone up in the directory in the user tree, but also then require they be in a particular group. The group would actually have a specific replyItem attribute that would return a VLAN if the user was part of the group...
There are other ways of accomplishing this ....
I think you may want the LDAP "profiles" stuff? Or, use an xlat: update reply { Tunnel-Private-Group-Id = "%{ldap:<ldap query url here>}" } - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html