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.

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 ?

*** This bug has been marked as a duplicate of 2168 ***

test