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....@lists.freeradius.org
[freeradius-users-bounces+robert.roll=utah....@lists.freeradius.org] On Behalf
Of Phil Mayers [p.may...@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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
