ldap filter gone and sambadomainnname not checked
pierre.filippone at retail-sc.com
Wed Mar 8 08:50:32 GMT 2006
Volker Lendecke <vlendec at sernet.de> wrote on 06.03.2006 18:24:10:
> On Mon, Mar 06, 2006 at 11:09:18AM +0100, Pierre Filippone wrote:
> > IMHO the cleanest solution is the "ldap filter" option, samba used to
> > have.
> We have deliberately deleted the ldap filter option because
> it has caused inconsistent behaviour at many sites. This is
> just asking for trouble.
Sorry, if I did not make it clear.
What I was asking for, is a filter which would give at least a few
customisation possibilities, like for example the former "ldap filter"
gave. When we integrated our samba domain into our directory, we had to
make many tests, because for us it was not obvious when which filter and
searchbase was used. Together with simultanuous nss_ldap queries,
understanding the ldap queries for samba was not simple, which made the
integration difficult. For us, the former "ldap filter" was useful, even
if it was not used consistently.
> The problem is that Samba not only has a single LDAP query,
> a stupid query that is probably giving misleading results is
> the search for smbldap_search:
> $ grep smbldap_search pdb_ldap.c|wc -l
I know that. What I was asking for is a filter parameter which is &-ed to
all queries, if defined. If not defined, all queries stay the same.
> This means that we are asking the LDAP in potentially 37
> different ways with different filters. How many of those do
> you want to expose to the user?
Not 37, but optional filter parameters which are &-ed to user and group
queries for example, together with the one that is &-ed to all queries,
would give users a lot of flexibility, if they need it. I count 328 global
samba parameters, of which we use 20-25 for our domain controllers. I can
live perfectly with all the others on default, without understanding or
even knowing all of them. One of the big advantages of samba is its
flexibility. That's the reason, why we use it.
> So in the sense of clarity we have chosen to remove this
> option, in particular as LDAP offers other possibilities to
> achieve the same goal, as simo has nicely shown.
Again, thank you for your suggestions and I will definitely use one of
them, but this does not change my opinion that an application, which uses
LDAP should have customizable filters. I know, it's simple to make
suggestions, if you don't know the reasons why things are implemented as
they are, but maybe you just take my opinion into account (as one of many)
when implementing samba 4.
More information about the samba-technical