FR 3.0.1 and LDAP group membership

[Arran Cudbard-Bell]

On 30 May 2014, at 02:39, Brendan Kearney <bpk678 at gmail.com> wrote:

> 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?

The update block in the LDAP module config.

update {
	reply: += 'replyItem'
}

There's already an example line, you just need to uncomment it.

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140530/49f384ba/attachment.pgp>