On 18 Dec 2013, at 07:42, Hachmer, Tobias <Tobias.Hachmer@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@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2