LDAP module

[Alister Winfield]

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