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.

From: Stuart.Schneider@PacifiCorp.com 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 Stuart.Schneider@PacifiCorp.com -----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 ----------

From: Jeff Maaks <jmaaks@mdc.com> 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 <jmaaks@mdc.com>: 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?

From: Brad.Davis@online.disney.com 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.

Note that changing the code to return bless $obj, Mozilla::LDAP::Entry; does not work as intended, since the TIE functionality is lost.

I'm moving bug #1381 over to this bug, here's the bug report: Submitted by: "Ronan Cremin" <ronan.cremin@isocor.com> 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=Danial.McCullough@Wireless.isocor.com 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: Danial.McCullough@Wireless.isocor.com 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 leif@netscape.com 11/16/98 03:26 ------- From: "Stuart Grace" <sgrace@hotpop.com> 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 ?

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

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 <udell@monad.net> 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' => [ 'judell@WALNUT.UdellInc..com' ], 'rfc822Mailbox' => [ 'judell@WALNUT.UdellInc..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 leif@netscape.com 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.

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

"Ronan Cremin" <ronan.cremin@isocor.com> reported the same problems when using ISOCOR's LDAP server from an Solaris client.

Setting all current Open Critical and Major to M3

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

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.