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 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. With this assumption radiusd could read all defined huntgroups on startup (reread on SIGHUP;-) ) and do the matching in authorize section after the user profile is read from ldap. Would be glad if you can give your thoughts on this or maybe some hints if this could be achieved already different. Hope this two points are not very far-fetched ;-) Regard, Tobias