2168 - Missing attributes when searching...

Status: RESOLVED FIXED

(Directory :: PerLDAP, defect, P1)

Description

[Leif Hedstrom]

Numerous reports on missing attributes when searching. I can't reproduce this,
but it seems to be primarily a problem on Windows/NT, and/or a problem with
rogue LDAP servers (not sure how).

More information from different people attached.

Comment 1

[Leif Hedstrom]

From: [e-mail]

   I think I've come across a problem either with your PerLDAP library or
with the Tie::Hash library on a Windows-NT system running ActiveState Perl5
build 506 (Perl 5.005_02).   I'm using the version of PerLDAP available on
ActiveState's Package library (which appears to be the most recent version
you have available).

   The problem is that when I execute a simple query against my LDAP server
(Microsoft Exchange Server v5.5, which works fine with the Net::LDAPapi
library), I don't get access to all of the data that is returned.  An
example script attached below shows the results of a simple query where I am
attempting to display the objectClass for a user.  Unless I access the
object behind the TieHash directly, I don't see the data.  This is the case
for about 60% of the attributes returned from the LDAP server (some of the
attributes do make it into the TieHash, but there doesn't seem to be a
pattern although the missing fields are the same for each query).

   Any insight you might be able to provide would be most useful.  I also no
not have access to the CVS system so can't check to see if there is a more
recent version of the modules available.  If you could either make a tarball
available somewhere or mail it to me, I might be able to debug a bit
further.

Thanks,
   Stuart Schneider
   [e-mail]

-----Sample Script-----
$ld{"host"}="pdxexc01";
$ld{"port"}=389;
$ld{"root"}="";
$ld{"scope"}="sub";

$search = "uid=P75412";

$conn = new Mozilla::LDAP::Conn(\%ld);
die "Could't connect to LDAP server $ld{host}" unless $conn;

$entry = $conn->search($ld{root}, $ld{scope}, $search, 0);
$conn->printError() if $conn->getErrorCode();

while ($entry) {
  print "objectClass=",join(",",@{ $entry->{objectClass} }),"\n";
  print "objectClass=",join(",",@{ $entry->{_self_obj_}->{objectClass}
}),"\n";
  $entry = $conn->nextEntry;
}

$conn->close if $conn;
----------

-----Script Output-----
objectClass=
objectClass=organizationalPerson,person,Top
----------

Comment 2

[Leif Hedstrom]

From: Jeff Maaks <[e-mail]>

For the boeingPerson object class, I've found that like Stuart Grace (see
http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=1328) I
can see the attributes when accessing the entry object directly.  Here's
some sample code that lets me see the attributes:
-------------------------------------------------------
use Mozilla::LDAP::Conn;

$root = "ou=people,o=boeing,c=us";
$conn = new Mozilla::LDAP::Conn("servername","port");

$entry =
$conn->search($root,"subtree","(boeingClockNumber=12345)", 0);

while($entry) {
  # this prints nothing after the =
  print "objectClass=",join(",",@{ $entry->{objectClass} }),"\n";

  # this prints the various object classes correctly (inetOrgPerson,
  #  boeingPerson, etc)
  print "objectClass=",join(",",@{ $entry->{_self_obj_}->{objectClass}
}),"\n";

  # this prints the various returned attributed correctly (including
  # the previously unprintable boeingPerson
  print "objectClass=",join(",",@{ $entry->{_self_obj_}->{_oc_order_}
}),"\n";

  # and this prints the attributes and values OK
  foreach $attr (@{$entry->{_self_obj_}->{_oc_order_} }) {
    grep((print "$attr: $_\n"), @{$entry->{_self_obj_}->{$attr}});
  }

  # this only prints cn,dn,mail, etc. - non-boeingPerson attributes
  $entry->printLDIF();

  $entry = $conn->nextEntry();
}

So, accessing the object internals works, but working through the
provided methods does not.

Thanks for any insight you could provide.....

----------------------------------------------------------------

More from Jeff Maaks <[e-mail]>:

I am running ActiveState Perl 5 build 506 (Perl 5.005_02).  I just
downloaded and installed build 508, and it didn't help.  I've been poking
around in Conn.pm's sub nextEntry, and a print "clocknum: ",
$obj->{boeingClockNumber}, "\n"; just before the ldap_ber_free at the
end of the routine correctly prints the value.

One more clue:in sub nextEntry from Comm.pm, if I change the last line:

return bless \%entry, Mozilla::LDAP::Entry;
to:
return bless $obj, Mozilla::LDAP::Entry;

..then everything seems to work great!  However, I'm not enough of a
Perl object/tie expert to know what this might be screwing up.  Does this
give you any ideas?

Comment 3

[Leif Hedstrom]

From: [e-mail]

I'm working on a web page that will allow non technical people to update
personal info like phone and room numbers in an LDAP database and trying to use
PerlLDAP to do so.

My main problem is that the following code is in the following code:

$conn = new Mozilla::LDAP::Conn("mailhub", "389", "cn=Manager, ou=Online,
o=Disney, c=US", "asdfasdf");
if (!$conn) { die "Could't connect to LDAP server $ld{host}" };

$entry = $conn->search($query->param('DN'), "base", "(objectclass=*)", 0,
@attr);

if ($conn->getErrorCode())
 { print "Error: " . $conn->printError(); }

print $entry->printLDIF();

Which should produce roughly the same output as the command line tool ldapsearch
called as follows:

ldapsearch -p 389 -b "ou=Online,o=disney,c=US" -D "cn=Manager, ou=Online,
o=Disney, c=US" -w asdfasdf -h mailhub -v "cn=Brad Davis"

But instead I get a remarkably small subset of the information, containing only
the cn, sn, info and mail attributes.  I hope I'm not being merely dense.  Any
ideas?

------------------------------------------------------

And more from Brad:

Thanks for the response.  The C-SDK was the lastest release of the Netscape 3.0
dir sdk for Unix, the client platform was Solaris 2.7, and the server platform
was Solaris 2.6.  The PerlLDAP version was the most recent ZIP file in the
mozilla ftp server (I'm not quite up to speed with CVS).  The server in question
is the LDAP portion of an integrated enterprise mail product by Control Data
Corp, called Mailhub (or Intrastore, depending on how much of the product you
buy).

I'm also working on my own OO encapsulation classes for LDAP in C++ using the
STL libraries and when I compile those against the same SDK on the same platform
or on my NT box (using the NT version of the same C-SDK) I get normal results. I
only reverted to PERL for the web page interface because of a possible shorter
development cycle with a non-interpreted language and also because I didn't want
to have to have to intergrate CGI handling into C++.  If there is anything I can
to help you isolate this bug, let me know.

Comment 4

[Leif Hedstrom]

Note that changing the code to

   return bless $obj, Mozilla::LDAP::Entry;

does not work as intended, since the TIE functionality is lost.

Comment 5

[Leif Hedstrom]

I'm moving bug #1381 over to this bug, here's the bug report:


Submitted by: "Ronan Cremin" <[e-mail]>

Hi Leif,

First of all, great stuff - a really nice extension to Perl. Seconldy, if you
are not the person to talk to about this I
appologize.

I have an LDAP v3 directory (ISOCOR GDS) with objects of the following form:

Top
Person
organizationalPerson
inetOrgPerson
gtePerson


If I do an LDAP search on the directory using the standard command line tools I
see the following data for each user:

cn=Danial.McCullough, ou=internetworking, o=GTE, c=US
objectClass=top
objectClass=person
objectClass=organizationalPerson
objectClass=inetOrgPerson
objectClass=gtePerson
cn=McCullough, Danial P
cn=Danial.McCullough
sn=McCullough
title=Customer Care Specialist
telephoneNumber=617-843-2515
givenName=Danial
initials=P
mail=[e-mail]
createTimeStamp=19981112003735.002Z
modifyTimeStamp=19981112003735.002Z
creatorsName=cn=manager
modifiersName=cn=manager
employeeNumber=2476
gteAlias=dmccull.lastname

But if I use PerLDAP to implement the same search as follows:

my $result = $conn->search("ou=internetworking, o=gte, c=us", "one", "cn=*");
$result->printLDIF();

I see only the following attributes:

dn: cn=Danial.McCullough, ou=internetworking, o=GTE, c=US
cn: McCullough, Danial P
cn: Danial.McCullough
sn: McCullough
title: Customer Care Specialist
initials: P
mail: [e-mail]

Do you know why I can't see all of the returned attributes when using PerLDAP? I
can see from my directory log file that the
attributes *are* actually requested by PerlLDAP and they *are* all returned by
the directory.

I would appreciate any help you could give me with this.


------- Additional Comments From [e-mail]  11/16/98 03:26 -------
From:  "Stuart Grace" <[e-mail]>

Apparently this happens with other servers as well, from Stuart:


I am experiencing a problem in using PerLDAP on NT.

The setup is as follows:
Windows NT4 sp3
ICL I500 v8 X.500 Directory Service with LDAP V3.X LDAP server interface.
Perl 5.004_02
PerLDAP v1.0

I can use the ldapsearch.exe and ldapmodify.exe (v3.0) binaries to perform
read, search and updates against the directory without problems.  For
example, the results I get from a simple search are as follows:
ldapsearch -h ,host> -p <port> -b "ou=People, o=XYZ, c=GB" "(cn=fred smith)"
dn: CN=fred smith, ou=People, o=XYZ, c=GB
objectClass: person
objectClass: organizationalPerson
commonName: fred smith
surname: smith
mail: fred . smith @ XYZ . co. uk
createTimeStamp: 19981113142229Z
modifyTimeStamp: 19981113142229Z
creatorsName: CN=DSAmanager
modifiersName: CN=DSAmanager

I have installed the PreLDAP binaries and I can also perform searches and
directory updates without problems from within PERL :-)

However, I see a problem with the PerLDAP install when I try and read
attribute values.  I find the entry OK and I can read the 'mail' attribute
OK but can't read any of the other attributes, including the 'cn'.  I see
the same effect when I call the printLDIF method, i.e. only the dn and mail
details are returned.

My code looks like:
if ( ! ( $ldapconn = Mozilla::LDAP::Conn->new ( $ldap_host, $ldap_port, "",
"" ) ) ) {
    &fatalerr ( "No LDAP Connection Created." );
}

$cdbase = 'ou=people,o=xyz,c=gb';
$filter = '(cn=fred smith)'; # setup the filter...
@attributes = ( "cn", "mail" );
$foundentry = $ldapconn->search ( $cdbase, 'subtree', $filter, 0,
@attributes );

if ( $ldapconn->getErrorCode () ) {    # return now if error
    $ldapconn->printError ();
    return 0;
}

if ( ! $foundentry ) {       # return now if nothing found
    &logmsg ( "No entries found in I500 with filter $filter." );
    return 0;
}

# -- Getting the DN works OK
$dn = $foundentry->getDN ();
&logmsg ( "Found: $dn" );

# -- Displays only the users mail and dn OK, fails to get other attributes
inc the cn
$foundentry->printLDIF ();

# -- the following fails to return the cn, the mail attribute is returned
&logmsg ( "commonname: $foundentry->{cn}[0]" );
&logmsg ( "mail: $foundentry->{mail}[0]" );

foreach $attribute ( @attributes ) {
    $entrydetails{$attribute} = $foundentry->{$attributes}[0];
}

$ldapconn->close;

The user objects have other attributes also propulated but I get the same
problem, i.e. I can't read them.
What am I doing wrong ?

Comment 6

[Leif Hedstrom]

*** Bug 1381 has been marked as a duplicate of this bug. ***

Comment 7

[Leif Hedstrom]

Merging in another bug report, this looks very promising, I suspect it has
something to do with case sensitivity in the servers(?).


From: Jon Udell <[e-mail]>

Hi Leif,

I've just been poking around in an Exchange Server with PerLDAP. Was
puzzled to see that PrintLDIF was only reporting all lowercase
attributes, not any mixed-case attributes. I haven't figured out why,
but I did notice that although the top level of the $entry structure
exhibited this pathology, its internal _self_obj_ looked OK. So I
changed to

     grep((print "$attr: $_\n"), @{$self->{_self_obj_}->{$attr}});

from

     grep((print "$attr: $_\n"), @{$self->{$attr}});

in ::Entry::PrintLDIF. Which seems to work, but I know there's got to be
more to the story. I'm attaching a Data::Dumper dump of $entry following
a search. As you can see, all non-lowercase attributes at the root level
of $entry are undef. I've only just noticed this because, working with
Netscape Directory Server, I think I've only been seeing lowercase
attributes. Exchange uses mixed-case attributes.

I can't find the place in your Perl code where this is happening, but
it's got to be there. Because in Conn::nextEntry, I can do

        @vals = ldap_get_values_len($self->{"ld"}, $self->{"ldentry"}, $attr);
        print "$attr: $vals[0]\n";

and see all the attributes. So they're coming back OK from the LDAP API
level. I guess one set of attributes mirrors the other, for
change-tracking purposes? I dunno, you sort of lost me with that
multilevel blessed object sleight of hand....

This is, by the way, using the Win32 ActiveState PerlDAP module, if that
matters (it shouldn't, I don't think).

Regards,

--
Jon Udell - http://udell.roninhouse.com/


$VAR1 = bless( {
                 'sn' => [
                           'Udell'
                         ],
                 '_self_obj_' => bless( {
                                          'title' => [
                                                       'foo'
                                                     ],
                                          'mail' => [

'[e-mail]..com'
                                                    ],
                                          'rfc822Mailbox' => [

'[e-mail]..com'
                                                             ],
                                          'rdn' => [
                                                     'judell'
                                                   ],
                                          'Hide-From-Address-Book' => [

'FALSE'
                                                                      ],
                                          'st' => [
                                                    'NH'
                                                  ],
                                          '_oc_order_' => [

'objectClass',
                                                            'rdn',
                                                            'cn',

'distinguishedName',

'Hide-From-Address-Book',

'rfc822Mailbox',
                                                            'mail',

'textEncodedORaddress',

'otherMailbox',

'postalAddress',

'conferenceInformation',

'mailPreferenceOption',

'department',
                                                            'givenName',
                                                            'Home-MTA',
                                                            'l',

'physicalDeliveryOfficeName',

'postalCode',
                                                            'st',
                                                            'sn',

'telephoneNumber',
                                                            'title'
                                                          ],
                                          'l' => [
                                                   'Keene'
                                                 ],
                                          'telephoneNumber' => [

'555-1212'
                                                               ],
                                          'objectClass' => [

'organizationalPerson',
                                                             'person',
                                                             'Top'
                                                           ],
                                          'postalCode' => [
                                                            '03431'
                                                          ],
                                          'physicalDeliveryOfficeName'
=> [

'home office'

],
                                          'otherMailbox' => [

'MS$UDELLINC/WALNUT/JUDELL',

'CCMAIL$Udell, Jon2 at WALNUT'
                                                            ],
                                          'cn' => [
                                                    'Jon Udell'
                                                  ],
                                          'dn' =>
'cn=judell,cn=Recipients,ou=WALNUT,o=Udell Inc.',
                                          'department' => [
                                                            'no dept.'
                                                          ],
                                          'distinguishedName' => [

'cn=judell,cn=Recipients,ou=WALNUT,o=Udell Inc.'
                                                                 ],
                                          'Home-MTA' => [
                                                          'cn=Microsoft
MTA,cn=INTERGRAPH,cn=Servers,cn=Configuration,ou=WALNUT,o=Udell Inc.'
                                                        ],
                                          'postalAddress' => [
                                                               '31
Walnut St'
                                                             ],
                                          'givenName' => [
                                                           'Jon'
                                                         ],
                                          'mailPreferenceOption' => [

'0'
                                                                    ],
                                          'conferenceInformation' => [

'/'
                                                                     ],
                                          'textEncodedORaddress' => [

'c=US;a= ;p=Udell Inc.;o=WALNUT;s=Udell2;g=Jon;'
                                                                    ]
                                        }, 'Mozilla::LDAP::Entry' ),
                 'sn' => $VAR1->{'sn'},
                 '_self_obj_' => $VAR1->{'_self_obj_'},
                 'title' => $VAR1->{'_self_obj_'}{'title'},
                 'mail' => $VAR1->{'_self_obj_'}{'mail'},
                 'rfc822Mailbox' => undef,
                 'rdn' => $VAR1->{'_self_obj_'}{'rdn'},
                 'Hide-From-Address-Book' => undef,
                 'st' => $VAR1->{'_self_obj_'}{'st'},
                 '_oc_order_' => $VAR1->{'_self_obj_'}{'_oc_order_'},
                 'l' => $VAR1->{'_self_obj_'}{'l'},
                 'telephoneNumber' => undef,
                 'objectClass' => undef,
                 'postalCode' => undef,
                 'physicalDeliveryOfficeName' => undef,
                 'otherMailbox' => undef,
                 'cn' => $VAR1->{'_self_obj_'}{'cn'},
                 'dn' => 'cn=judell,cn=Recipients,ou=WALNUT,o=Udell
Inc.',
                 'department' => $VAR1->{'_self_obj_'}{'department'},
                 'distinguishedName' => undef,
                 'Home-MTA' => undef,
                 'postalAddress' => undef,
                 'givenName' => undef,
                 'mailPreferenceOption' => undef,
                 'conferenceInformation' => undef,
                 'textEncodedORaddress' => undef
               }, 'Mozilla::LDAP::Entry' );


------- Additional Comments From [e-mail]  12/03/98 02:25 -------
More from Jon:

That's good. I have no further info. Where it stands: I'm not sure which of the
two attribute structures is canonical. I am pretty sure that arbitrarily
switching from one to the other, to work around the problem I cited, can't be
the right thing to do.

Comment 8

[Leif Hedstrom]

*** Bug 1389 has been marked as a duplicate of this bug. ***

Comment 9

[Leif Hedstrom]

"Ronan Cremin" <[e-mail]>  reported the same problems when using
ISOCOR's LDAP server from an Solaris client.

Comment 10

[leger]

Setting all current Open Critical and Major to M3

Comment 11

[leger]

Clearing "M" field since Directory product is not used for 5.0 specific project
bug metrics and will mess up our queries on milestones.

Comment 12

[Leif Hedstrom]

I hope/believe this is resolved with all the other bug fixes that got into
PerLDAP v1.2. Please reopen the bug if it's still a problem.