pdb_ldap.c, ldapsam_add_sam_account, existing poxisaccount

[John Allman]

spu at corman.be wrote:
> Hi John,
Hi, I got and responded to this mail this morning. I'm assuming that by
sending it to me again you want me to post to the list so here goes.
> 
> 1) your smbldap-tools is correctly configured ?
>       smbldap-useradd -a toto work ?
> 
Yep. All good for me

> 2) have you specified a ldap filter parameter in your smb.conf ?
>       if true, then try without ldap filter parameter or not use in filter
> objectClass=sambaSAMaccount.
>       Why : in code .. num_result =
> ldap_count_entries(ldap_state->smbldap_state->ldap_struct, result);
>       This line use ldap filter, if count line with sambaSAMAccount, smbd
> find no line !
> 

I was literally just looking at that code now. the problem i think is
not the ldap_count_entries but the following piece of code in
ldapsam_add_sam_account in passdb/pdb_ldap.c

        /* does the entry already exist but without a samba attributes?
           we need to return the samba attributes here */

        escape_user = escape_ldap_string_alloc( username );
        pstrcpy( filter, lp_ldap_filter() );
        all_string_sub( filter, "%u", escape_user, sizeof(filter) );
        SAFE_FREE( escape_user );

        rc = smbldap_search_suffix(ldap_state->smbldap_state,
                                   filter, attr_list, &result);

lp_ldap_filter simply gets the value set in the smb.conf. This section
of code should *not* be using that filter as it's supposed to be looking
for an ldap user that does not have samba attributes.

At least that's my understanding of it. The ldap filter is intended to
specify how to find samba users only. The documentation doesn't
explicitly say this but i don't see what else it could be for. This is
really for the developers to decide on.

With

     ldap filter = "(&(uid=%u)(objectclass=sambaSamAccount))"

in smb.conf, the code above fails to find the user in the ldap database
and hence tries to add it. With no ldap filter directive (i believe the
default value falls back to (uid=%u)) it finds the user and everything
works ok.

So the question is, what exactly is the ldap filter for? Is the
behaviour we're experiencing correct? If so it should probably be
mentioned in the documentation. If not perhaps a patch is required...

Thanks,

John