alister at ticklers.org
Wed May 2 17:45:20 CEST 2012
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
More information about the Freeradius-Devel