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.
Alan DeKok wrote in gmane.comp.freeradius.devel:
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?
Yes, you have, because you cannot know the whole DN before you search for the object in question. Consider the following tree layout: uid=manager,dc=company,dc=com userPassword={clear}verysecure uid=foo,ou=users,ou=germany,dc=company,dc=com userPassword={clear}passw0rd uid=bar,ou=users,ou=france,dc=company,dc=com userPassword={clear}dontcare A static DN would not be enough the find all users. To make things worse: the DN may not contain the username at all, like so: cn=Sven Hartge,ou=users,ou=germany,dc=company,dc=com uid=s_hartge userPassword={clear}something So you _have_ to first search and filter, then use the gathered DN to either bind() or collect the password. There is no way around. Grüße, Sven. -- Sigmentation fault. Core dumped.
So you _have_ to first search and filter, then use the gathered DN to either bind() or collect the password. There is no way around.
Agreed. It is very common for ldap objects to be spread through the tree. Particularly in active directory, and Ldap-UserDN is still needed there for group search. -- Sent from my phone. Please excuse brevity and typos.
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
Alister Winfield wrote:
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.
OK. I'm looking at re-doing the LDAP module for 3.0. The new connection pool API makes it simpler. De-duplicating the code is a good idea, too. I wanted to make sure I understood it, and didn't break anything. What *will* likely go away is the eDir functionality. That code is *horrible*. I don't run eDirectory, so I can't test it, either. I'm OK with adding it back in again. But I can't do the work. Alan DeKok.
On 05/03/2012 03:03 AM, Alan DeKok wrote:
What *will* likely go away is the eDir functionality. That code is *horrible*. I don't run eDirectory, so I can't test it, either.
Agreed. It's non-standard, I think we should stick to RFC defined behavior that is portable across multiple implementations. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
On Thu, May 3, 2012 at 3:01 PM, John Dennis <jdennis@redhat.com> wrote:
On 05/03/2012 03:03 AM, Alan DeKok wrote:
What *will* likely go away is the eDir functionality. That code is *horrible*. I don't run eDirectory, so I can't test it, either.
Agreed. It's non-standard, I think we should stick to RFC defined behavior that is portable across multiple implementations.
I agree that RFC defined behaviour is better, but given that FreeRADIUS is shipped as a part of OES (SLES + eDir + other stuff) it mightn't be a bad idea at least reaching out to Novell on this. (Possibly it should be a different module, or just the old module with a different name?) Cheers -- Peter Nixon http://peternixon.net/ Normal people believe that if it ain't broke, don't fix it. Engineers believe that if it ain't broke, it doesn't have enough features yet - Scott Adams
Peter Nixon wrote:
I agree that RFC defined behaviour is better, but given that FreeRADIUS is shipped as a part of OES (SLES + eDir + other stuff) it mightn't be a bad idea at least reaching out to Novell on this. (Possibly it should be a different module, or just the old module with a different name?)
I'm OK with it being the same module. The eDir code is actually pretty similar to what's already there. What kills me is that it was a complete butcher job of "cut and paste". No common abstraction, no re-use of code, etc. I think with the new framework, adding eDir support should be rather a lot simpler. Alan DeKok.
participants (6)
-
Alan DeKok -
Alister Winfield -
John Dennis -
Peter Nixon -
Phil Mayers -
Sven Hartge