FR 3.0.1 and LDAP group membership

[Arran Cudbard-Bell]

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

-------------- 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/20140527/16e80c33/attachment-0001.pgp>