--On Friday, February 19, 2021 11:15 PM + Bruce Johnson
wrote:
Implemented it as follows:
Glad you got it working. :)
I had a typo in my script that left out one of the hyphens. This *should*
work (although I don't have any AD system to test against) if you fix this
line in the
Implemented it as follows:
sub guid2uname {
use MIME::Base64 qw(decode_base64);
sub enc_hex {
my @h = split(//,unpack('H*',decode_base64(shift)));
my ($i, $out, $first);
foreach $i(@h) {if (!$first){$out.="\\$i"; $first=1;} else
{$out.=$i;$first='';}}
return $out;
}
my $gu = enc_hex(shift);
my $a
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 r
--On Friday, February 19, 2021 7:04 PM + Bruce Johnson
wrote:
my $goodFilter = '(objectGUID =
'.decode_base64('XrfAr5bivU61wz1WCgsxWA==').')';
my $badFilter = '(objectGUID =
'.decode_base64('6CncwjzJ/Umi4iIdB88efw==').')';
I would suggest converting these to data more easibly usabl
I think this is a bug in Net::LDAP::Filter
From a suggestion on Perl Monks, I've narrowed the issue to the
Net::LDAP::Filter module
https://www.perlmonks.org/?node_id=11128565
‘Bad’ objectGUID values seem to break this, and they return ‘undef’ for the
filter object.
Code demonstrating the iss
On Feb 17, 2021, at 11:24 AM, Bruce Johnson
mailto:[email protected]>> wrote:
I've written two subroutines for getting sAMAccountName by objectGUID and vice
versa; the main purpose is to manage a database table that stores the
objectGUID as a Base64 encoded string. (the purpose of
