Re: start_tls using required

[Chris R. <chr...@ma...>]

On 11/11/02 2:08 pm, Michael Maier <mmn...@gm...> wrote:

> Hi!
> 
> I have a question concerning start_tls.
> When I use verify=>'required' and my LDAP Server does not know the start_tls
> extension, it sends me a "unsupported extended operation"-error as
> LDAPResult with errornumber 2 (at least Sun DirServ and OpenLDAP does). As
> far as I understood, in this case the following search request should not be
> started but it looks like the resultCode 2 is looked at as success.
> By the way, shouldn't a not supported extension result in a resultCode of
> 12?
> 
> Here is my code:
> use Net::LDAP;
> $ldap = Net::LDAP->new('localhost', version => 3, port => 389) or die "$@";
> $ldap->debug(12);
> $ldap->start_tls(verify => 'required', cafile => 'somefile') or die "$@";
> ...
> 
> 
> 
> And here the response to my start_tls from debug:
> 
> 42: SEQUENCE {
> 1:  INTEGER=1
> 37:  [APPLICATION 24] {
> 1:    ENUM = 2
> 0:    STRING = ''
> 30:    STRING = 'unsupported extended operation'
> :  }
> : }
> 
> 
> Thanks!
> Florian

The start_tls code returns (should return!) an error whenever the result
message it got back has a non-zero code value ("return $mesg if
$mesg->code"). Is this not happening?

According to RFC 2252 if the server doesn't recognize the request name, it
MUST return a protocol error. Unavailable critical extension is reserved for
LDAP controls which are marked as critical but which the server doesn't
recognize (or is unwilling to obey for whatever reason).

So I'd say the server's returning the right sort of result iff we're
screwing up the initial extended operation. What does that look like if you
turn on debugging?

Also check you've got the latest & greatest version of LDAP.pm, as some bugs
crept in to start_tls which have only recently been fixed.

Cheers,

Chris