I've looked at using unpack in a similar fashion (as that is officially the LDAP Way to do that filter https://ldapwiki.com/wiki/ObjectGUID ) but I thought this was something that Net::LDAP::Filter handles without me needing to do that; and it does handle it properly most of the time (it works roughly 90% of the time based on scanning ~700 records in our active directory).
I have been using these functions for quite a while and it wasn’t until I used them in sweep of the matching table that I encountered this issue. If I convert the binary to a hex string using unpack, then format the bytes as per the ldapwiki entry above it works: $searchFilter= '(objectGUID=\1d\54\2c\2e\5c\1c\19\40\9d\c7\93\69\32\23\46\49)’; does produce the correct record for either a ‘good’ or ‘bad’ objectGUID. As a workaround I’m going to modify my original guid2uname method to use that format for searching. (using the search filter in the format you suggest does not return the expected LDAP records.) However since it works with the binary form of the value *most* of the time, I suspect it’s something in the regexes used in the Net::LDAP::Filter module matching something specific in the binary sent as the value, causing it to fail over. So I do think this is a bug in the Net::LDAP::Filter module. Hard to figure out since it is intermittent and dependent on the variable data passed to the function. I’ve searched the perl-ldap documentation and found nothing specific to this issue or anything about encoding binary objects in any special fashion. -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs
