FR 3.0.1 and LDAP group membership

[Brendan Kearney]

On Tue, 2014-05-27 at 22:04 +0100, Arran Cudbard-Bell wrote:
> On 27 May 2014, at 21:18, Brendan Kearney <bpk678 at gmail.com> wrote:
> 
> > On Tue, 2014-05-27 at 20:37 +0100, Arran Cudbard-Bell wrote:
> > 
> >> Without code patches you'd need to add radiusreplyItem attributes directly
> >> to the groups objects. The group objects and the profile objects would be 
> >> one and the same.
> >> 
> >> Arran Cudbard-Bell <a.cudbardb at freeradius.org>
> >> FreeRADIUS Development Team
> > 
> > what you say contradicts what you have stated previously:
> 
> No, it doesn't.
> 
> > Groups don't return replyItems only profiles do. Groups are only 
> > used for checking membership, they cannot contain attributes themselves.
> 
> An object in LDAP can belong to multiple objectClasses.
> 
> Without an objectClass an object is is just an object, it's not a 
> group it's not a profile.
> 
> No an object which is just a member of the posixGroup class can't 
> contain replyItems, or checkItems or any other RADIUS attributes.
> 
> Yes an object which is a member of the radiusprofile class can 
> contain replyItems, and checkItems and generic radius attributes.
> 
> Being a member of posixGroup does not mean that the object cannot 
> also be a member of radiusprofile.
> 
> As I said, to do what you want to do, you actually want the group 
> object to also be a radiusprofile object.
> 
> Here's the order of operations, hopefully it'll clear things up:
> 
> 1. enter mod_authorize
> 2. search in user.base_dn with scope user.scope with filter user.filter
>    Requesting attributes:
>    user.access_attribute (if set)
>    profile.attribute
>    all attributes on the right hand side of the update section
> Assuming user is found
> 3. store dn
> 4. check access_attribute value
> 5. apply update section mappings
> 6. foreach of the profile.attribute values
>    Search in profile.attibute.value with filter profile.filter
>    Requesting attributes:
>    all attributes on the right hand side of the update section
>    if object found apply update section mappings
> 7. return from mod_authorize
> 
> I'm telling you to set profile.attribute to be 'memberOf' so that the 
> profile code will iterate over all the group objects (which may also 
> happen to be radiusprofile objects), performing attribute mappings.
> 
> Note: Your memberOf attribute values must be DNs instead of group CN 
> (or whichever attribute you use as group.name_attribute).
> 
> If you want to iterate over a subset of the group objects (which also 
> happen to be radiusprofile objects), then set an appropriate filter 
> for profile.filter.
> 
> Hint: Profile filter can contain XLAT expansions %{}.
> 
> > Note that your profile attribute could be the same as your group
> > attribute i.e. memberOf, in which case you'd just need to add the
> > group objects to the radiusprofile object.
> > 
> > am i to understand that 3.0.3 changes things or have i again missed
> > something important?
> 
> Not dramatically since 3.0.0, i've tried my best to forget how the 
> v2.x.x module worked. It's a traumatic experience looking over that
> code, I don't want to relive it again and again.
> 
> Read: The v2.0.x code is a rats nest, I have no idea how, why or if
> it works correctly.
> 
> In theory the same thing should work just fine for v2.0.x, but I don't
> know, and if it doesn't, you're on your own.
> 
> -Arran
> 
> Arran Cudbard-Bell <a.cudbardb at freeradius.org>
> FreeRADIUS Development Team
> 
> FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

ok.  i took what you said too literally.  i thought that groups and
profiles had to be separate.  with the group created and the additional
objectclass of radiusprofile added to the group, i now have the group
created in the way you said.

i started a packet capture, then started radiusd -X and tried to sign
into my switch.  the switch requested a specific VSA, radius looked up
my group memberships, found all of them, including the one with the
radiusreplyitem, and replies with an Access-Accept.  what is missing is
the radiusreplyitem value/string in the Access-Accept message.  the
group i am member of has the attribute, and the value is correct, but
radius is not replying with it.  where am supposed to tell radius to
reply with the replyitem?