AW: feature request: ldap enhancements

[Hachmer, Tobias]

Hello Arran,

thanks for your answer and sorry for my delay...

-----Ursprüngliche Nachricht-----
Von: freeradius-users-bounces+tobias.hachmer=stadt-frankfurt.de at lists.freeradius.org [mailto:freeradius-users-bounces+tobias.hachmer=stadt-frankfurt.de at lists.freeradius.org] Im Auftrag von Arran Cudbard-Bell
Gesendet: Mittwoch, 18. Dezember 2013 14:43
An: FreeRadius users mailing list
Betreff: Re: feature request: ldap enhancements

On 18 Dec 2013, at 07:42, Hachmer, Tobias <Tobias.Hachmer at stadt-frankfurt.de> wrote:
>> 1. reload all RADIUS clients stored in ldap on SIGHUP (bulk load)
>>   - 'radmin -e "hup ldap"' would be sufficient here
> That's difficult. You'll notice that non the of the modules which use a connection pool at marked as HUP safe.
> The reason for this is due to how HUP works. It first creates a new instance of every HUP safe module used by the server, and in doing so creates a new connection pool. The connection pool then opens X number of additional connections.
> After a period the old instance is freed and the old connections destroyed.
> Between the HUP and the old instance being freed the server would have double the number of connections open. This can cause issues where things like SQL and LDAP servers may have limits on the maximum number of clients.
> It should be possible to avoid recreating connection pools, and as an added bonus it might allow shared connection pools.
> I'd need Alan's feedback on whether it's acceptable to allow configuration changes to the module, whilst not allowing configuration changes with the connection pool before implementing such a change.
> You can use the dynamic clients server to load additional clients in without HUP or restart, in all current versions of the server (if this is all you require).

I know the dynamic client feature.  Here we're looking for the possibility to manage client ip ranges within ldap also. If using dynamic clients server the ip range clients come from must not be defined in clients.conf.
So I see, the only way to using the full management of radius clients in ldap is to restart fr server after adding client definitions in ldap.

>> 2. enhanced ldap support for storing and managing huntgroups Our goal 
>> is to restrict several users to one or more "NAS groups". It should be possible that the same NAS can be member of multiple huntgroups as well as to assign multiple huntgroups to a user.
>> To do this in ldap there have to be something like:  
>> a)      new object class for huntgroups to distinct these from other RADIUS related objects like RADIUS clients and RADIUS profiles. I think this approach is better than adding a multi-valued attribute to the RADIUS clients object class for better clarity.
>> b)      The existing RADIUS profile object class should be extended for a multi-valued attribute to assign multiple huntgroups to a user profile.

> This doesn't fit with the design of the server.
> The only information read in from a dynamic source and implicitly cached are the clients entries, and that is for performance reasons.
> None of the directory, database, datastore modules currently support caching data read from an external server.
> Where caching is required for performance or resilience, the rlm_cache module can be used.
> Modifications to rlm_ldap for v3.0.x allowed group membership information to be cached. That is all group information is retrieved from the LDAP directory for a particular object, and then written into control attributes.
> Those control attributes can then be cached with the rlm_cache module.
> When LDAP-Group == <value> is executed, the rlm_ldap module checks for the presence of these control attributes, and if they're found, they are used to determine membership instead of calling out to the server.
> The same system can be used to store group information about NAS.
> In your above example you would create an object to represent the NAS with an IP address attribute.
> You would treat this object as the 'user' (principal), and filter using IP address instead of User-Name. 
> Group membership can then be checked with the rlm_ldap instance specific pair comparison.
> ldap NAS {
> 	<config>
> }
> 
> if (NAS-Ldap-Group == 'group-1') {
> 
> }
Ok, if I understand this correct I need for each RADIUS Client a separate ldap object in a different ou?
And how can I join the "NAS groups" with the user objects in order to restrict access for user1 to NAS group 1+2 and for user2 to NAS group 2+3 ?

Regards,
Tobias Hachmer