samba - Jul 2006 - ldapsam ignores "ldap user suffix" when doing username lookup

Greetings.

Since this is my first post to this list, hello everyone. Here's an
issue concerning the ldapsam backend.

I'm having a problem with the "ldap user suffix" param not being
honored as expected. Specifically, when a user logs on, the "ldap user
suffix" is ignored and the ldapsam backend attempts to lookup the user
doing a full subtree search in the context defined by the "ldap
suffix" param. This can easily be verified by setting the log level to
5, doing a domain logon, and then grepping for "smbldap_search_ext" in
the smbd log.

This issue has been raised before on this list, and has been answered
by referring to the 3.0.11 changelog, which states this: 

"If "ldap user suffix" or "ldap machine suffix" are
defined in
smb.conf, all user-accounts must reside below the user suffix,
and all machine and inter-domain trust-accounts must be located
below the machine suffix.  Previous Samba releases would fall
back to searching the 'ldap suffix' in some cases."

Well, all user accounts in my setup do reside below the user suffix,
and all machine accounts are below the machine suffix, yet it appears
Samba "falls back" by default, which looks like quite the opposite of
what said changelog entry claims.

Looking at the source provided some insight. Mind you, I suck at C, so
unfortunately I couldn't ever fix this issue (if it is one) myself, no
matter how much I'd love to. :-)

Here's the situation from my perspective: When looking up a user
account, in pdb_ldap.c, ldapsam_getsampwnam() invokes
ldapsam_search_suffix_by_name(), which in turn calls
smbldap_search_suffix() in smbldap.c.

smbldap_search_suffix() then invokes smbldap_search() with scope set
to lp_ldap_suffix(), which corresponds to the full "ldap suffix"
context.

I wonder why ldapsam_getsampwnam() doesn't invoke an LDAP search call
that is limited to the lp_ldap_user_suffix scope. Or do this first and
then another search in the lp_ldap_machine_suffix scope after that, if
for some reason the machine scope needs to be covered too.

As I'm sure you'll agree, the large-scope search is a non-issue if
your LDAP directory isn't huge, or if you have just one LDAP server,
or the entire directory is fully replicated to all slave servers which
any Samba DCs might talk to. However, if you have a large directory
where user accounts are scattered over multiple OUs and the tree is
heavily partitioned (as is not uncommon in Novell eDirectory setups),
then any unnecessary cross-partition query becomes a real performance
issue, especially if you have slow WAN links.

Since this issue has been around for some time (I've just reproduced
with 3.0.5, 3.0.14a and 3.0.20b -- I apologize for not having had time
to compile and install the latest SVN trunk), I'm almost certain
there's an obvious reason for this behavior, and/or an obvious
workaround. Which I must have missed. Could a helpful subscriber
enlighten me please?

Thanks a lot.

Best regards,
Florian

--
Mag.(FH) Florian G. Haas
Systemingenieur
Kapsch BusinessCom AG, Wienerbergstrasse 53, A-1121 Wien
phone: +43 (5) 0811 5361

The information contained in this e-mail message is privileged and
confidential and is for the exclusive use of the addressee. The person
who receives this message and who is not the addressee, one of his
employees or an agent entitled to hand it over to the addressee, is
informed that he may not use, disclose or reproduce the contents thereof.

hi,

what about using ACLs to restrict uid-searches in the base for samba admin?

greez

Haas Florian wrote:
> Greetings.
> 
> Since this is my first post to this list, hello everyone. Here's an
> issue concerning the ldapsam backend.
> 
> I'm having a problem with the "ldap user suffix" param not
being
> honored as expected. Specifically, when a user logs on, the "ldap user
> suffix" is ignored and the ldapsam backend attempts to lookup the user
> doing a full subtree search in the context defined by the "ldap
> suffix" param. This can easily be verified by setting the log level to
> 5, doing a domain logon, and then grepping for
"smbldap_search_ext" in
> the smbd log.
> 
> This issue has been raised before on this list, and has been answered
> by referring to the 3.0.11 changelog, which states this: 
> 
> "If "ldap user suffix" or "ldap machine suffix"
are defined in
> smb.conf, all user-accounts must reside below the user suffix,
> and all machine and inter-domain trust-accounts must be located
> below the machine suffix.  Previous Samba releases would fall
> back to searching the 'ldap suffix' in some cases."
> 
> Well, all user accounts in my setup do reside below the user suffix,
> and all machine accounts are below the machine suffix, yet it appears
> Samba "falls back" by default, which looks like quite the
opposite of
> what said changelog entry claims.
> 
> Looking at the source provided some insight. Mind you, I suck at C, so
> unfortunately I couldn't ever fix this issue (if it is one) myself, no
> matter how much I'd love to. :-)
> 
> Here's the situation from my perspective: When looking up a user
> account, in pdb_ldap.c, ldapsam_getsampwnam() invokes
> ldapsam_search_suffix_by_name(), which in turn calls
> smbldap_search_suffix() in smbldap.c.
> 
> smbldap_search_suffix() then invokes smbldap_search() with scope set
> to lp_ldap_suffix(), which corresponds to the full "ldap suffix"
> context.
> 
> I wonder why ldapsam_getsampwnam() doesn't invoke an LDAP search call
> that is limited to the lp_ldap_user_suffix scope. Or do this first and
> then another search in the lp_ldap_machine_suffix scope after that, if
> for some reason the machine scope needs to be covered too.
> 
> As I'm sure you'll agree, the large-scope search is a non-issue if
> your LDAP directory isn't huge, or if you have just one LDAP server,
> or the entire directory is fully replicated to all slave servers which
> any Samba DCs might talk to. However, if you have a large directory
> where user accounts are scattered over multiple OUs and the tree is
> heavily partitioned (as is not uncommon in Novell eDirectory setups),
> then any unnecessary cross-partition query becomes a real performance
> issue, especially if you have slow WAN links.
> 
> Since this issue has been around for some time (I've just reproduced
> with 3.0.5, 3.0.14a and 3.0.20b -- I apologize for not having had time
> to compile and install the latest SVN trunk), I'm almost certain
> there's an obvious reason for this behavior, and/or an obvious
> workaround. Which I must have missed. Could a helpful subscriber
> enlighten me please?
> 
> Thanks a lot.
> 
> Best regards,
> Florian
> 
> --
> Mag.(FH) Florian G. Haas
> Systemingenieur
> Kapsch BusinessCom AG, Wienerbergstrasse 53, A-1121 Wien
> phone: +43 (5) 0811 5361
> 
> The information contained in this e-mail message is privileged and
> confidential and is for the exclusive use of the addressee. The person
> who receives this message and who is not the addressee, one of his
> employees or an agent entitled to hand it over to the addressee, is
> informed that he may not use, disclose or reproduce the contents thereof.
>