Re^3: Peculiar problem with Net::LDAPS and AD LDAP

I am convinced now it's a bug, that Net::LDAP::Filter's regexes are inadvertently matching things in the binary data causing the ->new() call to fail and return undef, but I found a work-around. When I looked up the objectGUID reference at LDAPWiki the proper way to create the search term for LDAP is (objectGUID=\12\34\56\78\9a\bc\de\f1) as a kind of escaped byte code.

When I hand-constructed a searchfilter from a 'broken' objectGUID, the search worked

So I wrote the following bit of code to turn the binary objectGUID into a hex string matching that format and I now can properly get all the info for the extant accounts.

sub enc_hex {
        my @h = split(//,unpack('H*',(shift));
        my ($i, $out, $first);
        foreach $i(@h) {if (!$first){$out.="\\$i"; $first=1;} else {$o
+ut.=$i;$first='';}}
        return $out;
        }
[download]

Plugging that into my actual module that gets a sAMAccountName from a stored uuencoded objectGUID worked.

There is probably some Perl Master way to write this as a one-liner, but I'll be able to look at this three years from now and understand what I'm doing, so it'll do!

Thanks again for the help!

Comment on Re^3: Peculiar problem with Net::LDAPS and AD LDAP Download Code

Replies are listed 'Best First'.
Re^4: Peculiar problem with Net::LDAPS and AD LDAP by jcb (Parson) on Feb 21, 2021 at 04:32 UTC
Assuming that you need to change '`ABCD`' into '`\AB\CD`', there should be an easier way: `sub enc_hex { my $out = unpack('H*', (shift)); $out =~ s/\G(..)/\\$1/g; return $out; }` [download] This uses the regex engine to advance through the string two characters at a time, inserting backslashes before each pair in the output. See perlre and perlop for more details.	[reply] [d/l]