ldap backend and Realm

[Chris]

On Nov 17, 2008, at 8:50 AM, Mustapha Bouikhif wrote:

> tnt at kalik.net wrote:
>>> radiusd: FreeRADIUS Version 2.1.1, for host i686-pc-linux-gnu
>>>
>>>
>>
>> Then ldap is not in radiusd.conf. ldap is now in raddb/modules/ldap.
>> authorize in not in radiusd.conf either. It's in
>> raddb/sites-enabled/default. Are you trying to use new version with a
>> copy of old radiusd.conf?
>>
>> Post the whole debug from server startup.
>>
>> Ivan Kalik
>> Kalik Informatika ISP
>>
>> -
>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>>
>>
> Here is the debug of radiusd (attached file)
> rlm_ldap: bind as uid=Manager,%{control:My-BaseDN}/sirc2 to  
> ldapauth.cnrs-gif.fr:389
> rlm_ldap: waiting for bind result ...
> rlm_ldap: uid=Manager,%{control:My-BaseDN} bind to ldapauth.cnrs- 
> gif.fr:389 failed Invalid DN syntax
> rlm_ldap: (re)connection attempt failed

It is my understanding that few of the ldap configuration parameters  
are variable-expanded at bind and search time.

I had no luck getting basedn to expand, but filter expands okay.  I  
ended up defining different LDAP modules with the different basedn  
settings I needed and used unlang to call the proper one:

ldap ldap-basedn1 {
	basedn = ou=org1
	...
}

ldap ldap-basedn2 {
	basedn = ou=org2
	...
}

authorize {
switch "%{Realm}" {
	case realm1 {
		...
		ldap-basedn1
	}
	case realm2 {
		...
		ldap-basedn2
	}
}

No, it is not as elegant as I'd like, but basedn doesn't expand so I  
felt I had no choice.  It works.