Sponsored development rlm_ldap and ocsp

Kostas Kalevras kkalev at noc.ntua.gr
Wed Aug 25 09:51:44 CEST 2010

  On 24/8/2010 6:58 μμ, John Dennis wrote:
> On 08/24/2010 10:37 AM, Alan DeKok wrote:
>> John Dennis wrote:
>>> I think folks would appreciate the functionality in 2.1.10 so I would
>>> agree to adding it to 2.1.10. However I would argue that would be
>>> dependent on getting the schema reviewed first. Nothing worse than
>>> having a schema get out into the field, have folks start using it and
>>> then discover it needs to be modified.
>> Yup. But I don't think many people are competent to review the
>> schema. From what I know of LDAP, it looks reasonable.
>>> Does FreeRADIUS have a block of OID's?
>> Yes. The 11344 private enterprise code has been assigned to FreeRADIUS.
>>> Are the client values case sensitive?
>> The secret, nastype, nas password, and virtual server names are case
>> sensitive. The other fields are used only for printing, not for
>> lookups. So they can be case insensitive, as they don't matter.
> O.K. I'll update the 389_ds_schema.ldif to use the FreeRADIUS oid's 
> for *all* the attributes. Set the syntax to utf-8 and make the above 
> values case sensitive, the other insensitive for the new client stuff.
> There are other radius attributes in the schema which have been there 
> for a while, not sure where they originated. I wonder if they should 
> also be reviewed to check if they should be IA5 or UTF-8 and their 
> case sensitivity. I think you might have the best immediate 
> understanding of how these attributes are getting used with RADIUS and 
> if their definition is correct. For instance most of them are defined 
> to be IA5 ( IA5 is almost equivalent to 
> ASCII (see http://www.zytrax.com/tech/ia5.html). One would hope the 
> days of IA5 are behind us. Then there are other attributes which are 
> defined as IA5 strings which seems dubious to me, for example 
> IdleTimeout and a couple of port specifications (should be integer?) 
> and a number of attributes when appear to be booleans (but are defined 
> as strings).
> Finally are all these attributes still in use or are they legacy cruft?
All attribute values could use the syntax "<op> <value>" where <op> one 
of =,:=, += etc (it's been a while since i used it though, see 
ldap_pairget()). So it's probably a good idea to keep them that way.Why 
would you handle most RADIUS attribute values as UTF-8 instead of plain 

Kostas Kalevras
Network Operations Center, NTUA.GR

More information about the Freeradius-Devel mailing list