LDAP stuff (was Re: LDAP client requires smbpasswd encrypt tool)

Matt Chapman m.chapman at student.unsw.edu.au
Fri Jan 8 02:39:24 GMT 1999

Allan Bjorklund wrote:

> > objectclass sambaUser
>   The current code in the cvs tree still refers to sambaAccount.

Oops, I did mean *sambaAccount*. I was thinking along the lines of user, group,

>   The minor bug is on line 174 of passdb/ldap.c which currently reads:
>                if(ldap_get_attribute("ntuid", nt_name)) {

Yep, I already fixed that one, it just hasn't been committed yet (I don't have
cvs write access and most of the Samba team have been on holidays).

>   At first I thought it was because these lines,
> /* Internal state */
> LDAP *ldap_struct;
> LDAPMessage *ldap_results;
> LDAPMessage *ldap_entry;
> in the head of passdb/sampassldap.c were not declared extern (the
> originals being in passdb/ldap.c).  But changing them to extern had no
> effect. (But shouldn't they, just for clairty, be decalred extern
> anyways?)

Cut and paste error (but most linkers merge them anyway).

>   Why not add all of the fields from the USER_INFO_3 struct?  From what
> I can tell it holds all the possible fields that Windows will want to
> query and all of the other USER_INFO_xxx structs are subsets of it.
> Then we would only need to worry about SAMBA specific needs.

Eventually yes; I was documenting the attributes that are currently useable by
Samba (given the present password database API only allows for
USER_INFO_21-style information).

> Another minor bug, is that the OpenLDAP
> libraries export a symbol for ldap_close_connection.  gcc doesn't like
> that and the build stops.

OK, I've changed ldap_open_connection and ldap_close_connection to ldap_connect
and ldap_disconnect respectively. The ldap_ prefix probably wasn't such a good
idea after all...

>   I figured out the nasty SIGSEGV problem.  In passdb/ldap.c near the
> end of ldap_getpw() there is a call to ldap_next_entry.  This results
> in the global variable ldap_entry getting set to NULL.  Since the
> following ldap_get_attribute needs ldap_entry we get the SIGSEGV.

Oops. Fixed.

>   The first bug was that the groupdb_ops structure in
> groupdb/groupldap.c was incomplete.  It was missing entries for
> del_group_entry, add_group_member, and del_group_member.  I placed NULL
> place holders in for them and was then able to get further along to
> ldap_search() before encountering another SIGSEGV.

Yep, I'd already fixed this - by implementing the new functions :-)

>   I added a check for struct_ldap being NULL in
> ldapgroup_getusergroups() and if it is, call ldap_open_connection and
> set a flag so the connection gets closed before leaving the function.

As far as I can see ldapgroup_getusergroups should *always* open the connection.
(I'd better check I didn't leave out ldap_connect anywhere else...)

> It appears to work as I'm now able to log in from Win95 and NT 4.0.


> I'll put together some patches and send them out tomorrow.  I've
> been here way too long today.

I've already fixed all of the above on my version so I will make sure it all
gets committed.

Sorry about the bugs (I've been on holidays & didn't have an NT workstation to
test against), and thanks for all your help!


Matt Chapman
m.chapman at student.unsw.edu.au

More information about the samba-technical mailing list