Skip Menu |

This queue is for tickets about the perl-ldap CPAN distribution.

Report information
The Basics
Id: 98257
Status: rejected
Priority: 0/
Queue: perl-ldap
People
Owner: Nobody in particular
Requestors: nick [...] miletwo.net
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Fri Aug 22 11:51:19 2014 nick [...] miletwo.net - Ticket created
Subject: Possible Bug in Net::LDAP
Date: Fri, 22 Aug 2014 08:51:10 -0700
To: bug-perl-ldap [...] rt.cpan.org
From: Nick Anderson <nick [...] miletwo.net>
Hello There, While using the Net::LDAP module, I noticed a possible bug where some attributes are missing from the search results. A full description of my issue can be found at StackOverflow. http://stackoverflow.com/questions/25450825/perl-ldap-search-not-returning-all-rows Regards, ------------------------------ Nicholas Anderson nick@miletwo.net Desk: 503-532-9174 Mobile: 714-307-2073
  Sun Aug 31 03:21:27 2014 MARSCHAP [...] cpan.org - Status changed from 'new' to 'rejected'
  Sun Aug 31 03:46:31 2014 MARSCHAP [...] cpan.org - Correspondence added
Hi, sorry this is not a bug in perl-ldap. If you do not specify the attributes you want in the search() call, then an LDAPv3 conforming server will return all non-operational attributes which the bound user is allowed to read. I guess badPasswordTime is an operational attribute and hence not returned automatically. You may try to include all operational attributes in the search by additionall passing attrs => [ '*', '+' ] to the search() call. If Active Directory supports the '+' to return all operational attributes, then you're set. Otherwise ask for the attribute directly using attrs => [ '*', 'badPasswordTime' ] I doubt whether ActiveDirectory fully conforms to the LDAPv3 standard. If it does, you can search the schema for the operational attributes by looking for all attributes that have the NO-USER-MODIFICATION resp. 'USAGE directoryOperation' properties set in the schema. Best Peter