feature request: ldap enhancements

[Arran Cudbard-Bell]

On 18 Dec 2013, at 07:42, Hachmer, Tobias <Tobias.Hachmer at stadt-frankfurt.de> wrote:

> Hello Arran,
>  
> you asked if I have any feature requests. So, here are two points I want to discuss:
>  
> 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).

> 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.
>  
> Example:
> huntgroup-1               NAS-IP-Address == 192.0.2.5
> huntgroup-1               NAS-IP-Address == 192.0.2.6
> huntgroup-1               NAS-IP-Address == 192.0.2.7
>  
> huntgroup-2               NAS-IP-Address == 192.0.2.7
> huntgroup-2               NAS-IP-Address == 192.0.2.8
> huntgroup-2               NAS-IP-Address == 192.0.2.9
>  
> user1        Cleartext-Password := "password1", Huntgroup-Name == "huntgroup-1"
>                                          Service-Type = Administrative-User
>  
> user2        Cleartext-Password := "password2", Huntgroup-Name == "huntgroup-2"
>                                          Service-Type = Administrative-User
>  
> user3        Cleartext-Password := "password3", Huntgroup-Name == "huntgroup-1", Huntgroup-Name == "huntgroup-2"
>                                          Service-Type = Administrative-User
>  
> Please pardon if the huntgroup assignment here is incorrect, I did not use huntgroups at all for now.
>  
> 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') {

}

If you need to invalidate the cache, you can do it by setting the cache epoch appropriately using
the radmin command. This avoids HUPing the server, which is a potentially dangerous operation.

-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/20131218/5e52fbd5/attachment.pgp>