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

Allan Bjorklund allan at umich.edu
Thu Jan 7 19:18:01 GMT 1999


On 07-Jan-99 Matt Chapman wrote:
> 
> Currently the sambaUser objectclass looks like this:
> 
> objectclass sambaUser

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

  Have there been a large number of changes that haven't been checked
in yet?  If so, when will they be?  I've encountered one minor fixable
bug, and one nasty one that I haven't been able to fix.  (Hopefully
you've caught and fixed them.)

  The minor bug is on line 174 of passdb/ldap.c which currently reads:

               if(ldap_get_attribute("ntuid", nt_name)) {

  It should be:

               if(!ldap_get_attribute("ntuid", nt_name)) {

  Without the "!" operator, it reports failure during success and
success during failure.

  The nasty bug is a SIGSEGV (signal 11) that occurs in this call
sequence in passdb/sampassldap.c:

          ldapsam_getsam()
          calls ldap_get_attribute("gidNumber", temp)
          calls ldap_get_values(ldap_struct, ldap_entry, attribute)

  The call to ldap_get_values results in the SIGSEGV.

  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?)

  The funny thing is that this sequence:

          ldapsam_getsam()
          calls ldap_getpw()
          makes many calls to ldap_get_attribute()
          which results in many calls to ldap_get_values()

  works just fine.  And this is only a couple of lines in front of the
sequence that produces the SIGSEGV.

  The box I'm working on is a RedHat 5.1, dual 180MHz with SMP turned
on, and the OpenLDAP 1.1.2 release.


> objectclass sambaUser
>     requires
>         objectClass
>         uid
>         uidNumber
>         ntuid
>         rid
>     allows
>         gidNumber
>         grouprid
>         acctFlags
>         lmPassword
>         ntPassword
>         pwdLastSet
>         pwdCanChange
>         pwdMustChange
>         cn
>         description
>         smbHome
>         homeDrive
>         script
>         profile
>         workstations
>         logonTime
>         logoffTime
>         kickoffTime

  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.


--Allan


  ===================================================================
  Allan Bjorklund                  |                  allan at umich.edu
  Systems Research Programmer      |           University of Michigan
  Information Technology Division  |               535 W. William St.
  1-(734)-763-9391                 |              Ann Arbor, MI 48103
  ===================================================================


More information about the samba-technical mailing list