Did you try the ‚cafile‘ option of start_tls?
http://search.cpan.org/~marschap/perl-ldap/lib/Net/LDAP.pod#start_tls
Regards,
Daniel
Am 11.09.2014 um 17:58 schrieb Natxo Asenjo :
> hi,
>
> in my host (fedora 20)I have imported the root CA certificate of our
> corporate AD domain. Using ldapsear
displayeName should read displayName.
Regards,
Daniel
John Arends schrieb:
Thanks for the suggestions so far but I'm still not having any luck. I
cleaned up the script a bit based on several of the suggestions.
I decided to take the password bit out for now. I can't create an
account with no
Graham Barr wrote:
Can you help me to understand the reason for the reuse of the request
message object for holding the response message?
Again, where do you see it reusing the request message for holding the
response ? There are no request message objects, per se. The process of
sending a me
Chris Ridd wrote:
The only thing I can imagine might be a potential problem is that the
IntermediateResponse sequence uses responseName/responseValue, so if
there's code trying to deal with both in the same way, that will fail.
Is there such code?
You are right. The problem is that the response
Chris Ridd wrote:
The only difference is in the field name, and as it is not part of the
encoding I see no particular reason to change anything.
The field name is part of the _decoding_. That means the attribute
"response" is now "responseValue" in the Message object and the accessor
for "respo
Hi all,
I wonder if the condition for the sync() calls in LDAP::Extension is
correct. It checks for the existence of $self->{Code}. Shouldn't that be
$self->{resultCode} ?
In general, I am not sure, if calling sync() based on the existence of
resultCode is correct when sending messages asyn
Hi all,
according to RFC 4511 an ExtendedResponse has the following format:
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
responseValue[11] OCTET STRING OPTIONAL }
RFC 4511 obsoletes
Hi all,
Message::decode calls LDAP::_forgetmesg
as far as I understand the architecture of Net::LDAP this should not be
done for IntermediateResponse messages. Is that correct?
Thank you.
Kind regards,
Daniel
--- Message.pm.orig 2008-07-16 10:01:18.0 +0200
+++ Message.pm 2008-07
Thanks for the help. I have switched to a patched server now.
The converter fails now on the next pdu. I can't find the
The type should be:
responseValue ::= SEQUENCE {
eventType INTEGER,
resultCode INTEGER,
eventData OCTET STRING OPTIONAL }
and eventData has the following structure:
gene
Graham Barr schrieb:
What server are you using ?
It's a Novell eDirectory 8.7.X
I'm trying to use Novell LDAP Extensions.
Kind regards,
Daniel
Here we go:
30 81 83 02 01 03 79 7E 0A 01 00 04 00 04 00 80 0.y~
1D 32 2E 31 36 2E 38 34 30 2E 31 2E 31 31 33 37 .2.16.840.1.1137
31 39 2E 31 2E 32 37 2E 31 30 30 2E 38 31 81 56 19.1.27.100.81.V
30 84 00 00 00 50 02 01 64 02 01 00 63 84 00 00 0P..d...c...
00 44 81 04 48 6D E0 AA 8
Hi all,
I am trying to implement an Net::LDAP::Extension and hit the wall, when
the first LDAPResponse from the server arrives.
ASN1::_decode returns an error, when it is called on that LDAPResponse,
which should contain an ExtendedResponse.
I extended Net::LDAP to write the pdu to a file bef
12 matches
Mail list logo
