Sometimes you just don't want to hard code the DN.... normally its when you have a reasonably large set of possible DNs to choose from especially if there isn't the appetite to remap/rebuild the structure of the LDAP directory to conform to a RADIUS friendly way of structuring things. Also its a really easy to filter out users based on attributes of their entry in the directory. eg a filter like ((cn=%user%) (status=active) (class=radiususer)) isn't an unusual thing to consider having. On 2 May 2012, at 15:55, Alan DeKok wrote:
I'm taking a look at the LDAP module. It's rather more complicated than I like. I'm thinking of moving it to use the new connection pools.
I have a first draft which uses the connection pool to open the sockets. But... the behavior of the module is hard to understand. I'll start off with my thoughts:
1) connection pool is working. They don't *do* anything, but they connect
2) authentication. The "bind as user" code is simple. But what's with the "perform_search" and "filter" stuff? Why not use have a statically configured user DN?
I'd like to avoid some of the complexity of the current code.
So is the user DN really some arbitrarily changing value? Do you really have to search over the entire DB for "uid=username" in order to find the user?
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html