On Mon, Aug 15, 2011 at 3:05 PM, Alan DeKok <aland@deployingradius.com> wrote:

> Each element sends a heartbeat packet to FR once a second to make sure
> it's still alive which we capture very early on in the authorize second
> and send a reject.

That's a REALLY bad idea. See RFC 2865 for why keep-alives are
harmful. See RFC 5997 for a better approach.

No arguments here with that... I'll have a read through the RFC's and escalate to our hardware vendor.. But I don't like my chances :(

> Our dynamic clients config is:
>
> server dynamic_client_server {
> authorize {
> if
> ("%{ldap:ldap:///ou=Elements,o=Identities?ou?sub?cn=%{Packet-Src-IP-Address}}")

This can be cached in a temporary variable:

update control {
Tmp-String-0 = "%{ldap:....}"
}

if (Tmp-String-0 != "") {
update control {
...
FreeRADIUS-Client-Shortname = "%{control:Tmp-String-0}"
...
}
}

The changes it from three LDAP lookup to one.

Cheers for that, I need to query two attributes from the object, one for the shared secret and the other for the client shortname. So I could reduce it from 3 to 2 queries. rlm_ldap doesn't seem to support multi-valued attributes as per http://wiki.freeradius.org/Rlm_ldap
I could store both valued in a single attribute then used a # or something as a delimiter then I could use a regex to split the string... Might look into that.

> Is the dynamic clients ldap lookups only single threaded, or have I done
> something incorrect with the configuration?

The dynamic client lookups are single threaded. Changing that is hard.

Yup.. I thought so... :(

Is there any limit on the file size of the clients.conf and how many entries? or it will just take as long as it will take and get re-read each time I HUP the server.

Many thanks for your insightful answers Alan :)

Cheers

Peter