AW: feature request: ldap enhancements

[Hachmer, Tobias]

-----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: Montag, 13. Januar 2014 22:32
An: FreeRadius users mailing list
Betreff: Re: feature request: ldap enhancements

>> 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.
> Yes, for now.

OK, I can work with this but it would be great to make some enhancements to rlm_ldap regarding reread radius client objects, e.g. periodically like every 30 minutes. This would be sufficient.

>> Ok, if I understand this correct I need for each RADIUS Client a separate ldap object in a different ou?
> Well it doesn't *have* to be in a different OU, but it's probably better to do that, and they don't have to be separate from the clients you load in with the LDAP module at startup.
>> 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 ?
> You ned two instance of the LDAP module because the configurations are quite different. One you'd set to filter on user objects, the other would be radiusClient objects.

I hope I understand now. I have to define a second ldap instance and configure it to find the radiusClient objects instead of real user objects as well as the correct group membership parameters.
Will test it.

> To search for the NAS you probably want to use shortname, and you'll need to make sure that's unique.
>        user {
>                #   Where to start searching in the tree for users
>                base_dn = "${..base_dn}"
>
>                #  Filter for user objects, should be specific enough
>                #  to identify a single user object.
>                filter = "(&(radiusClientShortname=%{client:shortname})(objectclass=radiusClient))"
>		...
>	}

> authorize {
>	user
>	nas
>	if ((NAS-LDAP-Group == 'foo' || NAS-LDAP-Group == 'bar') && (User-LDAP-Group == 'baz')) {
>	}
> }

So, the radius clients will be "treated" as users where username will be the clients shortname, right?
Hmm, I'm just thinking of the unlang conditions. I can just imagine to define one big if block like:

if((NAS-LDAP-Group == 'foo' || NAS-LDAP-Group == 'bar') && (User-LDAP-Group == 'baz')) {
	handled
}
elsif((NAS-LDAP-Group == 'foo2' || NAS-LDAP-Group == 'bar2') && (User-LDAP-Group == 'baz2')) {
	handled
}
elsif((NAS-LDAP-Group == 'foo' || NAS-LDAP-Group == 'bar2') && (User-LDAP-Group == 'baz3')) {
	handled
}
else {
	reject
}

Am I using the conditions here the right way or is there a better approach?

Regards,
Tobias Hachmer