Group checking in ldap authorization

[Robert Roll]

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 at lists.freeradius.org [freeradius-users-bounces+robert.roll=utah.edu at lists.freeradius.org] On Behalf Of Phil Mayers [p.mayers at imperial.ac.uk]
Sent: Wednesday, March 23, 2011 3:14 AM
To: freeradius-users at 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