From: Christoph N. <en...@ap...> - 2001-11-19 21:10:30
|
I think I may have found part of the source of my troubles...I believe start_tls is failing. Has anyone else have trouble with start_tls and Active Directory? --- Code ------------- $ldaps = Net::LDAP->new($ad_server, version => 3, debug => 3) || die "failed: $@"; $mesg = $ldaps->start_tls(); if ( $mesg-> code() ) { die "LDAP Error: ", $mesg->error, "\n"; } --- Output ----------- Net::LDAP=HASH(0x845b730) sending: 30 1D 02 01 01 77 18 80 16 31 2E 33 2E 36 2E 31 0....w...1.3.6.1 2E 34 2E 31 2E 31 34 36 36 2E 32 30 30 33 37 __ .4.1.1466.20037 Net::LDAP=HASH(0x845b730) received: 30 84 00 00 00 16 02 01 01 78 84 00 00 00 0D 30 0........x.....0 84 00 00 00 07 0A 01 02 04 00 04 00 __ __ __ __ ............ LDAP Error: decode error 30<=>0a at /usr/lib/perl5/site_perl/5.005/Convert/ASN1/_decode.pm line 112. ---------------------- On Mon, 19 Nov 2001, Christopher A Bongaarts wrote: > As Christoph Neumann once put it so eloquently: > > > I know this is from a very old post, but I don't see if this problem was > > ever solved. Now I'm running into the same problem with Active Directory. > > Here's what I use to update the AD password: > > # done; now, if there's still a unicodePwd, then UTF-16(?) it > # and base64 encode it and make sure it gets sent that way. > my $opw = $entry->get_value('unicodePwd'); > if (defined $opw) { > my $upw = pack "v*", unpack "C*", qq("$opw"); > &change_changes($entry, 'replace', 'unicodePwd', $upw); > } > > > &change_changes is a hack to actually change a previous "replace" > operation in an Entry object, rather than adding a second "replace" > operation (else the original one will fail with WILL_NOT_PERFORM). > > %% Christopher A. Bongaarts %% ca...@tc... %% > %% Internet Services %% http://umn.edu/~cab %% > %% University of Minnesota %% +1 (612) 625-1809 %% > > |