perl-ldap-dev

Re: start_tls and Net::LDAPS

[Graham B. <gb...@po...>]

On Tue, Oct 08, 2002 at 10:05:44PM +0100, Chris Ridd wrote:
> On 8/10/02 9:56 pm, Bing Du <du...@mo...> wrote:
> 
> > % perl -MNet::LDAP -e 'print $Net::LDAP::VERSION,"\n"'
> > 0.251
> 
> That's the overall package version, not the version of the file in CVS. I'm
> not sure how the two are related... Maybe Graham can remember?

$VERSION is updated manually whenever a release is done. The latest from
CPAN is 0.26

Graham.

Re: start_tls and Net::LDAPS

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

On 8/10/02 9:56 pm, Bing Du <du...@mo...> wrote:

> % perl -MNet::LDAP -e 'print $Net::LDAP::VERSION,"\n"'
> 0.251

That's the overall package version, not the version of the file in CVS. I'm
not sure how the two are related... Maybe Graham can remember?

Cheers,

Chris

Re: start_tls and Net::LDAPS

[Bing Du <du...@mo...>]

% perl -MNet::LDAP -e 'print $Net::LDAP::VERSION,"\n"'
0.251

So I guess we need to get a latest version of Net::LDAP?

==============
Net::LDAP=HASH(0x2e250) sending:
0000   29: SEQUENCE {
0002    1:   INTEGER = 1
0005   24:   [APPLICATION 23] {
0007   22:     [CONTEXT 0]
0009     :       31 2E 33 2E 36 2E 31 2E 34 2E 31 2E 31 34 36 36
1.3.6.1.4.1.146
6
0019     :       2E 32 30 30 33 37 __ __ __ __ __ __ __ __ __ __ .20037
001F     :   }
001F     : }
Net::LDAP=HASH(0x2e250) received:
0000   12: SEQUENCE {
0002    1:   INTEGER = 1
0005    7:   [APPLICATION 24] {
0007    1:     ENUM = 0
000A    0:     STRING = ''
000C    0:     STRING = ''
000E     :   }
000E     : }
start_tls return code 1-Operations error
Net::LDAP=HASH(0x2e250) sending:
0000   86: SEQUENCE {
0002    1:   INTEGER = 2
0005   81:   [APPLICATION 0] {
0007    1:     INTEGER = 3
000A   64:     STRING = 'uid=c24b18d4bb4afdf052330678af9a601d, ou=People,
dc=tam
u, dc=edu'
004C   10:     [CONTEXT 0]
004E     :       67 79 64 62 30 37 31 31 64 62 __ __ __ __ __ __
gydb0711db
0058     :   }
0058     : }
Net::LDAP=HASH(0x2e250) received:
0000    3: [UNIVERSAL 22]
0002     :   01 00 04 __ __ __ __ __ __ __ __ __ __ __ __ __ ...
84-decode error 16<=>30 at
/usr/local/perl/5.6.1/lib/site_perl/5.6.1/Convert/ASN
1/_decode.pm line 108.
================

Bing

Bing Du <bi...@ta..., 979-845-9577>
Texas A&M University, CIS, Operating Systems, Unix

On Tue, 8 Oct 2002, Chris Ridd wrote:

> On 8/10/02 5:50 pm, Bing Du <du...@mo...> wrote:
> > The result was:
> > ======
> > start_tls return code 1-Operations error
> > 84-decode error 16<=>30 at
> > /usr/local/perl/5.6.1/lib/site_perl/5.6.1/Convert/ASN
> > 1/_decode.pm line 108.
> 
> Interesting. It looks a bit like we're getting unexpected BER back from the
> server. Or we're sending the server something bad. Can you set
> $ldapcon->debug(12) before calling start_tls and send us the results?
> 
> Alternatively, what version of the LDAP.pm file do you have?
> 
> An error did slip in to start_tls a while ago relating to the message we
> were constructing (BER) to send to the server. We fixed it in version 1.32
> of Net::LDAP.pm, and I see Graham's got another start_tls fix in version
> 1.34 of the same file.
> 
> Cheers,
> 
> Chris
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> 

Re: start_tls and Net::LDAPS

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

On 8/10/02 5:50 pm, Bing Du <du...@mo...> wrote:
> The result was:
> ======
> start_tls return code 1-Operations error
> 84-decode error 16<=>30 at
> /usr/local/perl/5.6.1/lib/site_perl/5.6.1/Convert/ASN
> 1/_decode.pm line 108.

Interesting. It looks a bit like we're getting unexpected BER back from the
server. Or we're sending the server something bad. Can you set
$ldapcon->debug(12) before calling start_tls and send us the results?

Alternatively, what version of the LDAP.pm file do you have?

An error did slip in to start_tls a while ago relating to the message we
were constructing (BER) to send to the server. We fixed it in version 1.32
of Net::LDAP.pm, and I see Graham's got another start_tls fix in version
1.34 of the same file.

Cheers,

Chris

Re: start_tls and Net::LDAPS

[Clif H. <cl...@go...>]

Since you have the TLS extension in your server, it may be
that you have to use the vendor's api to use TLS.

That is the situation in our case, our directory supports
TLS but we have to use the vendors api(s) to get it to work.

Regards,

Clif


On Tue, Oct 08, 2002 at 11:50:07AM -0500, Bing Du wrote:
> Thanks Chris.  Actually I did try doing start_tls before bind after my
> first post.  But it was not getting any better.
> 
> =====

Stuff removed.

> > 
> > It is unusual to do the bind in the clear, and then turn on TLS afterwards.
> > That might be what you wanted, but normally you'd turn on TLS before issuing
> > any bind. That would be more similar to just making an LDAPS connection,
> > though incurring the extra overhead of the extended operation and result.
> > 
> > The second oddity is that you're not waiting for the bind to succeed. Try
> > checking for that before you call start_tls. Maybe there's an issue with
> > there being outstanding results on the socket when we try switching it, so
> > waiting for the bind result should address that.
> > 
> > Cheers,
> > 
> > Chris
> > 
> 

Re: start_tls and Net::LDAPS

[Bing Du <du...@mo...>]

Thanks Chris.  Actually I did try doing start_tls before bind after my
first post.  But it was not getting any better.

=====
#!/usr/local/bin/perl

use Net::LDAP;

$dn = "uid=c24b18d4bb4afdf052330678af9a601d, ou=People, dc=tamu, dc=edu";
$pw = 'mypass';

my $ldap_server = 'operator.tamu.edu';

my $ldcon = new Net::LDAP($ldap_server,version=>3) || die "Can't connect";

$mesg = $ldcon->start_tls();
print "start_tls return code ",$mesg->code,"-",$mesg->error,"\n";

$mesg = $ldcon->bind(dn => $dn,password => $pw);

if ($mesg->code)
{
 print $mesg->code,"-",$mesg->error,"\n";
} else {
         print "bind return code ",$mesg->code,"-",$mesg->error,"\n";
       }
=====

The result was:
======
start_tls return code 1-Operations error
84-decode error 16<=>30 at 
/usr/local/perl/5.6.1/lib/site_perl/5.6.1/Convert/ASN
1/_decode.pm line 108.
======

If I removed start_tls, bind was ok.

Bing

Bing Du <bi...@ta..., 979-845-9577>
Texas A&M University, CIS, Operating Systems, Unix

On Tue, 8 Oct 2002, Chris Ridd wrote:

> On 8/10/02 3:40 pm, Bing Du <du...@mo...> wrote:
> 
> > Now that Net::LDAPS works, does that mean our directory server supports
> > SSL but not necessarily supports TLS?
> > 
> > From my understanding after reading the description of Net::LDAPS:
> > 
> > "...
> > Note that the use of LDAPS is not recommended, because it is
> > not described by any IETF documents. Instead, you should
> > consider using LDAPv3 with the TLS extension defined in RFC
> > 2830. This will give you the same functionality as LDAPS,
> > but using recognized standards. See the start_tls entry in
> > the Net::LDAP manpage. ..."
> > 
> > Start_tls should at least do what Net::LDAPS can do.  Please correct me if
> > I'm wrong.  Thanks.
> 
> At the protocol level, they're rather different.
> 
> StartTLS is an LDAPv3 extended operation that servers must explicitly
> support. Because you can issue StartTLS at an arbitrary point in your
> connection to the server, it isn't the same as making an SSL connection to a
> given port.
> 
> Now one thing I noticed from your original snippet is:
> 
> my $ldcon = new Net::LDAP($ldap_server,version=>3) || die "Can't connect";
> 
> my $mesg = $ldcon->bind(dn => $dn,password => $pw);
> 
> $mesg = $ldcon->start_tls();
> print "start_tls: ",$mesg->error,"\n";
> 
> It is unusual to do the bind in the clear, and then turn on TLS afterwards.
> That might be what you wanted, but normally you'd turn on TLS before issuing
> any bind. That would be more similar to just making an LDAPS connection,
> though incurring the extra overhead of the extended operation and result.
> 
> The second oddity is that you're not waiting for the bind to succeed. Try
> checking for that before you call start_tls. Maybe there's an issue with
> there being outstanding results on the socket when we try switching it, so
> waiting for the bind result should address that.
> 
> Cheers,
> 
> Chris
> 

Re: start_tls and Net::LDAPS

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

On 8/10/02 3:40 pm, Bing Du <du...@mo...> wrote:

> Now that Net::LDAPS works, does that mean our directory server supports
> SSL but not necessarily supports TLS?
> 
> From my understanding after reading the description of Net::LDAPS:
> 
> "...
> Note that the use of LDAPS is not recommended, because it is
> not described by any IETF documents. Instead, you should
> consider using LDAPv3 with the TLS extension defined in RFC
> 2830. This will give you the same functionality as LDAPS,
> but using recognized standards. See the start_tls entry in
> the Net::LDAP manpage. ..."
> 
> Start_tls should at least do what Net::LDAPS can do.  Please correct me if
> I'm wrong.  Thanks.

At the protocol level, they're rather different.

StartTLS is an LDAPv3 extended operation that servers must explicitly
support. Because you can issue StartTLS at an arbitrary point in your
connection to the server, it isn't the same as making an SSL connection to a
given port.

Now one thing I noticed from your original snippet is:

my $ldcon = new Net::LDAP($ldap_server,version=>3) || die "Can't connect";

my $mesg = $ldcon->bind(dn => $dn,password => $pw);

$mesg = $ldcon->start_tls();
print "start_tls: ",$mesg->error,"\n";

It is unusual to do the bind in the clear, and then turn on TLS afterwards.
That might be what you wanted, but normally you'd turn on TLS before issuing
any bind. That would be more similar to just making an LDAPS connection,
though incurring the extra overhead of the extended operation and result.

The second oddity is that you're not waiting for the bind to succeed. Try
checking for that before you call start_tls. Maybe there's an issue with
there being outstanding results on the socket when we try switching it, so
waiting for the bind result should address that.

Cheers,

Chris

Re: start_tls and Net::LDAPS

[Bing Du <du...@mo...>]

For testing if our directory supports TLS, I run the following script.

========
#!/usr/local/bin/perl

use Net::LDAP;

my $ldap_server = 'operator.tamu.edu';

my $ldcon = new Net::LDAP($ldap_server,version=>3) || die "Can't connect";

my $can_do_start_tls = 0;
my $r = $ldcon->root_dse();

foreach ($r->get_value("supportedExtension")) {
     $can_do_start_tls = 1 if $_ eq "1.3.6.1.4.1.1466.20037";
 }

print "can_do_start_tls is $can_do_start_tls\n";
exit;
========

The output is 'can_do_start_tls is 1'.

Now what?

Bing

Bing Du <bi...@ta..., 979-845-9577>
Texas A&M University, CIS, Operating Systems, Unix

On Tue, 8 Oct 2002, Bing Du wrote:

> Now that Net::LDAPS works, does that mean our directory server supports
> SSL but not necessarily supports TLS?
> 
> From my understanding after reading the description of Net::LDAPS:
> 
> "...
>  Note that the use of LDAPS is not recommended, because it is
>  not described by any IETF documents. Instead, you should
>  consider using LDAPv3 with the TLS extension defined in RFC
>  2830. This will give you the same functionality as LDAPS,
>  but using recognized standards. See the start_tls entry in
>  the Net::LDAP manpage. ..."
> 
> Start_tls should at least do what Net::LDAPS can do.  Please correct me if
> I'm wrong.  Thanks.
> 
> Bing
> 
> Bing Du <bi...@ta..., 979-845-9577>
> Texas A&M University, CIS, Operating Systems, Unix
> 
> On Mon, 7 Oct 2002, Clif Harden wrote:
> 
> > 
> > The first thing I would do is make sure your directory server
> > supports TLS operation.
> > 
> > Clif
> > 
> > 
> > 
> > Bing Du wrote:
> > > 
> > > I'd appreciate anybody providing any hints or pointing me to any online
> > > sources that would be helpful for fixing my problem with
> > > start_tls.  Briefly Net::LDAPS works fine but start_tls does not.  More
> > > details as shown below.
> > > 
> > > Net::LDAP version 0.251
> > > Net::LDAPS version 0.03
> > >
> > 
> 
> 

Re: start_tls and Net::LDAPS

[Bing Du <du...@mo...>]

Now that Net::LDAPS works, does that mean our directory server supports
SSL but not necessarily supports TLS?

From my understanding after reading the description of Net::LDAPS:

"...
 Note that the use of LDAPS is not recommended, because it is
 not described by any IETF documents. Instead, you should
 consider using LDAPv3 with the TLS extension defined in RFC
 2830. This will give you the same functionality as LDAPS,
 but using recognized standards. See the start_tls entry in
 the Net::LDAP manpage. ..."

Start_tls should at least do what Net::LDAPS can do.  Please correct me if
I'm wrong.  Thanks.

Bing

Bing Du <bi...@ta..., 979-845-9577>
Texas A&M University, CIS, Operating Systems, Unix

On Mon, 7 Oct 2002, Clif Harden wrote:

> 
> The first thing I would do is make sure your directory server
> supports TLS operation.
> 
> Clif
> 
> 
> 
> Bing Du wrote:
> > 
> > I'd appreciate anybody providing any hints or pointing me to any online
> > sources that would be helpful for fixing my problem with
> > start_tls.  Briefly Net::LDAPS works fine but start_tls does not.  More
> > details as shown below.
> > 
> > Net::LDAP version 0.251
> > Net::LDAPS version 0.03
> >
> 

Re: LDAP_OPERATIONS_ERROR :Server encountered an > internal error

[Graham B. <gb...@po...>]

OK, I think I know whats happeneing here.

When the IO error happens Net::LDAP is just returning without
populating the error code in the message object.

So when you call a method like ->code or ->error then $mesg object
will call sync. Which is where it sits and blocks.

Once an error like this happens on the input stream, it is almost
impossible to recover. So Net::LDAP should close the socket, causing
any subsequent request to fail immediately.

Graham.

On Mon, Sep 16, 2002 at 10:22:35AM +0800, Woanning wrote:
> Hi Graham,
> Thanks for your reply. I really appreciate that.
> The msg I send previously is all the output I got.
> my code is a simply script as below :
> ==================================================
> #!d:\perl\bin\perl -w
> 
> use Net::LDAP;
> use Net::LDAP::Util qw( ldap_error_name
>                         ldap_error_text) ;
> 
> print "Content-type:text/html\n\n";
> 
> my ($ldap) = Net::LDAP->new('10.1.1.112',port=> 8404, debug => 3) or die
> "Can't bind to ldap: $!\n";
> 
> $mesg = $ldap->bind( version => 3, dn => 'cn=Directory Manager,o=cisco.com',
> password => 'passabc');         
> my ($mesg) = $ldap->search( base => "ou=Users,o=cisco.com", filter
> =>'(cn=oliver)', attrs => [ "*" ]);
> 
> $mesg->code && die "Code: ".$mesg->code."  Error:
> ".ldap_error_name($mesg->code).":".ldap_error_text($mesg->code)." ";
> 
> ############### the program will stop progress from here
> print "helo";
> 
> foreach $entry ($mesg->all_entries){
> 	$password = $entry->get('userPassword');
> 	print "password :  $password\n";
> }
> 
> $ldap->unbind;
> 
> exit;
> ==================================================
> 
> I've tried to trace back the code and the LDAP.pm file, I found out that the
> program is stop at the point where when the LDAP.pm called the
> "asn_read($sock, $pdu)" function.
> 
> and if I change the line of my code from:
> $mesg->code && die "Code: ".$mesg->code."  Error:
> ".ldap_error_name($mesg->code).":".ldap_error_text($mesg->code)." ";
> to:
> $mesg->code && die $mesg->error;
> 
> then I'll get this error message : I/O Error   
> 
> and I found out that the error message is generated from the asn_read
> function in the IO.pm file in the ASN1 module.
> 
> 
> Do you have any idea why I'm getting this? Is it because I run on the
> Windows 2000? does the ASN1 library compatible with the OS? Does anybody
> successfully run it before on Windows 2000?
> 
> Thanks. appreciate much.
> 
> 
> _____________________
> Woan Ning
> Vads Berhad
> * +603 - 7712 8331 (D/L)
> * wn...@va...
> 
> @}--\---
> 
> 
> 
> -----Original Message-----
> From: Graham Barr [mailto:gb...@po...]
> Sent: Friday, September 13, 2002 10:33 PM
> To: Woanning
> Cc: per...@li...
> Subject: Re: LDAP_OPERATIONS_ERROR :Server encountered an > internal
> error
> 
> 
> Is this all the output you got ? I dont see any trace of received
> packets. What does you script look like and how far did it
> get before you get this error ?
> 
> Graham.
> 
> On Fri, Sep 13, 2002 at 11:54:46AM +0800, Woanning wrote:
> > Hi,
> > Can anybody show me some lights here as I've work out this bugs for so
> long
> > and still cant' able to find the solution for it...
> > Thanks.
> > I'm using active perl in Windows 2000 to connect ot a LDAP server...
> > I'm getting this error message:
> > Return code: 1 Message: LDAP_OPERATIONS_ERROR :Server encountered an >
> > internal error 
> > and after I turn on the 'debug => 3' in my code as below:
> > $ldap = Net::LDAP->new('10.1.1.112',port=>8404, debug => 3) or die "$@"; 
> > I got the below debugs text:
> > Net::LDAP=HASH(0x8a7f174) sending:
> > 30 33 02 01 01 40 2E 02 01 03 04 20 63 6E 3D 44 03...@..... cn=D
> > 69 72 65 63 74 6F 72 79 20 4D 61 6E 61 67 65 72 irectory Manager
> > 2C 6F 3D 63 69 73 63 6F 2E 63 6F 6D 80 07 70 61 ,o=cisco.com..pa
> > 73 73 61 62 63 __ __ __ __ __ __ __ __ __ __ __ ssabc
> > Net::LDAP=HASH(0x8a7f174) sending:
> > 30 3D 02 01 02 43 38 04 14 6F 75 3D 55 73 65 72 0=...C8..ou=User
> > 73 2C 6F 3D 63 69 73 63 6F 2E 63 6F 6D 0A 01 02 s,o=cisco.com...
> > 0A 01 02 02 01 00 02 01 00 01 01 00 83 0C 04 02 ................
> > 63 6E 04 06 6F 6C 69 76 65 72 30 03 04 01 2A __ cn..oliver0...*
> > Code: 1  Error: LDAP_OPERATIONS_ERROR:Server encountered an internal error
> >   at test.cgi line 23.
> > 
> > Net::LDAP version I'm using is : $VERSION = 0.25;
> > ASN1 version I'm using is : $VERSION = '0.16';
> > but there's a commented code in the ASN1.pm read :
> > # $Id: ASN1.pm,v 1.23 2002/08/20 00:00:57 gbarr Exp $  
> > (so I"m not sure which version is ASN1 is correct.. either is 0.16 or
> 1.23?)
> > 
> > Thank you very much if anybody can provide me any help on this.....
> > 
> > 
> > 
> > _____________________
> > Woan Ning
> > Vads Berhad
> > * +603 - 7712 8331 (D/L)
> > * wn...@va...
> > 
> > @}--\---
> > 
> > ~Where there is pain, I wish you peace and mercy.~
> > ~Where there is self-doubting, I wish you a renewed confidence in your
> > ability to work through it.~
> > ~Where there is tiredness, or exhaustion, I wish you understanding,
> > patience, and renewed strength.~
> > ~Where there is fear, I wish you love, and courage.~
> > 
> > 

Re: Size limit

[Graham B. <gb...@po...>]

On Tue, Oct 08, 2002 at 10:57:31AM +0200, Carlos Fuentes Bermejo wrote:
> Hello everybody,
> 
> I have a problem with the Net::LDAP->add function. When  I use it,
> passing as second argument a hash whose length is bigger than
> 255 bytes, it fails. If I shorten the length of the hash, everything
> works fine. Is there any size limit? If so, why?

Can you please supply some example code so we can better understand the
situation.

Graham.

Size limit

[Carlos F. B. <car...@re...>]

Hello everybody,

I have a problem with the Net::LDAP->add function. When  I use it,
passing as second argument a hash whose length is bigger than
255 bytes, it fails. If I shorten the length of the hash, everything
works fine. Is there any size limit? If so, why?

Regards Carlos
--=20
 ______________               __          _____________________________
                             /_/
 Carlos Fuentes Bermejo __            __   car...@re...
 RedIRIS/CSIC          /_/  RedIRIS  /_/   Tel:   + 34 915855124
 Serrano,142                 __            Fax:   + 34 915855146
 28006  Madrid              /_/            http://www.rediris.es
 SPAIN                                     Sistemas de Informaci=F3n -=20
                                           Redes Tem=E1ticas=20
					   Co-Responsable de Correo
					   Electr=F3nico=09
____________ Spanish Academic & Research Network ___________________

Re: start_tls and Net::LDAPS

[Clif H. <ch...@po...>]

The first thing I would do is make sure your directory server
supports TLS operation.

Clif



Bing Du wrote:
> 
> I'd appreciate anybody providing any hints or pointing me to any online
> sources that would be helpful for fixing my problem with
> start_tls.  Briefly Net::LDAPS works fine but start_tls does not.  More
> details as shown below.
> 
> Net::LDAP version 0.251
> Net::LDAPS version 0.03
>

Re: Authen::SASL possible bug in LOGIN mechanism

[Graham B. <gb...@po...>]

On Mon, Oct 07, 2002 at 08:13:32PM -0700, Michael de Beer wrote:
> On Mon, Oct 07, 2002 at 10:22:11PM +0100, Graham Barr wrote:
> > On Mon, Oct 07, 2002 at 06:47:12PM -0700, Michael de Beer wrote:
> > > It looks to me the Authen::SASL code put the MIME'd username on the
> > > same line as 'AUTH LOGIN'  But what is expected is that it is on its
> > > own line.  Here is another example SMTP conversation:
> > >   http://www.thecabal.org/~devin/postfix/smtp-auth.txt
> > 
> > Ah, I remember something about this. I think both are valid. Anyway try this patch
> > to LOGIN.pm (untested)
> 
> I tested this patch -- the AUTH login works fine now.
> 
> Will this patch be in the next Authen::SASL release?

Yes. I will try to do that this week.

Graham.

Re: Authen::SASL possible bug in LOGIN mechanism

[Michael de B. <mad...@ap...>]

On Mon, Oct 07, 2002 at 10:22:11PM +0100, Graham Barr wrote:
> On Mon, Oct 07, 2002 at 06:47:12PM -0700, Michael de Beer wrote:
> > It looks to me the Authen::SASL code put the MIME'd username on the
> > same line as 'AUTH LOGIN'  But what is expected is that it is on its
> > own line.  Here is another example SMTP conversation:
> >   http://www.thecabal.org/~devin/postfix/smtp-auth.txt
> 
> Ah, I remember something about this. I think both are valid. Anyway try this patch
> to LOGIN.pm (untested)

I tested this patch -- the AUTH login works fine now.

Will this patch be in the next Authen::SASL release?

Thanks,
Michael

Re: Authen::SASL possible bug in LOGIN mechanism

[Graham B. <gb...@po...>]

On Mon, Oct 07, 2002 at 06:47:12PM -0700, Michael de Beer wrote:
> It looks to me the Authen::SASL code put the MIME'd username on the
> same line as 'AUTH LOGIN'  But what is expected is that it is on its
> own line.  Here is another example SMTP conversation:
>   http://www.thecabal.org/~devin/postfix/smtp-auth.txt

Ah, I remember something about this. I think both are valid. Anyway try this patch
to LOGIN.pm (untested)

Index: lib/Authen/SASL/Perl/LOGIN.pm
===================================================================
RCS file: /cvsroot/perl-ldap/sasl/lib/Authen/SASL/Perl/LOGIN.pm,v
retrieving revision 1.1
diff -u -u -r1.1 LOGIN.pm
--- lib/Authen/SASL/Perl/LOGIN.pm	28 May 2002 13:36:25 -0000	1.1
+++ lib/Authen/SASL/Perl/LOGIN.pm	7 Oct 2002 21:24:40 -0000
@@ -7,7 +7,7 @@
 use strict;
 use vars qw($VERSION @ISA);
 
-$VERSION = "1.00";
+$VERSION = "1.01";
 @ISA	 = qw(Authen::SASL::Perl);
 
 my %secflags = (
@@ -23,7 +23,7 @@
 
 sub client_start {
   my $self = shift;
-  $self->_call('user');
+  '';
 }
 
 sub client_step {
@@ -31,7 +31,9 @@
 
   $string =~ /password/i
     ? $self->_call('pass')
-    : '';
+    : $string =~ /username/i
+      ? $self->_call('user')
+      : '';
 }
 
 1;

Graham.

start_tls and Net::LDAPS

[Bing Du <du...@mo...>]

I'd appreciate anybody providing any hints or pointing me to any online
sources that would be helpful for fixing my problem with
start_tls.  Briefly Net::LDAPS works fine but start_tls does not.  More
details as shown below.

Net::LDAP version 0.251
Net::LDAPS version 0.03

Using start_tls with Net::LDAP:
-----
#!/usr/local/bin/perl

use Net::LDAP;

$dn = "uid=c24b18d4bb4afdf052330678af9a601d, ou=People, dc=tamu, dc=edu";
$pw = 'mypass';

my $ldap_server = 'operator.tamu.edu';

my $ldcon = new Net::LDAP($ldap_server,version=>3) || die "Can't connect";

my $mesg = $ldcon->bind(dn => $dn,password => $pw);

$mesg = $ldcon->start_tls();
print "start_tls: ",$mesg->error,"\n";

$version = $ldcon->version;
print "version is $version\n";

$mesg = $ldcon->cipher();
print "cipher is ",$mesg,"\n";
-----

Outputs are:
-----
start_tls: Operations error
version is 3
cipher is
-----

Is there any way to check if TLS is currently established on the
connection?

Using Net::LDAPS:
-----
#!/usr/local/bin/perl

use Net::LDAPS;

$dn = "uid=c24b18d4bb4afdf052330678af9a601d, ou=People, dc=tamu, dc=edu";
$pw = 'gydb0711db';

my $ldap_server = 'operator.tamu.edu';
my $PEOPLE_BASEDN = "ou=people,dc=tamu,dc=edu";

my $ldcon = new Net::LDAPS($ldap_server) || die "Can't connect";

my $mesg = $ldcon->bind(dn => $dn,password => $pw, version=>3);

$version = $ldcon->version;
print "version is $version\n";

#$mesg = $ldcon->start_tls();
#print "start_tls: ",$mesg->error,"\n";

$mesg = $ldcon->cipher();
print "cipher is ",$mesg,"\n";
-----

Outputs (as expected) are:
-----
version is 3
cipher is EXP1024-RC4-SHA
-----

Bing

Bing Du <bi...@ta..., 979-845-9577>
Texas A&M University, CIS, Operating Systems, Unix

Re: Authen::SASL possible bug in LOGIN mechanism

[Michael de B. <mad...@ap...>]

On Mon, Oct 07, 2002 at 09:05:09PM +0100, Graham Barr wrote:
> On Mon, Oct 07, 2002 at 05:46:13PM -0700, Michael de Beer wrote:
> > [ In Authen::SASL and Net::SMTP ]
> > 
> > When I force the module to use the PLAIN mechanism,
> > my AUTH work.  But when I let the module automagically pick 
> > a mechanism, it uses the LOGIN mechanism and fails. 
> 
> Odd
> 
> > Have other people gotten the LOGIN mechanism to work correctly,
> > or is it possible there is a bug in it?
> 
> I cannot remember who tested it for me when I wrote it, but it worked
> for them.
> 
> Do you have other applications that use LOGIN ? If so try monitoring the
> network as you login and see what they pass.

When exim uses LOGIN to authenticate against the remote SMTP server,
it passes what I put below.

note, I changed the 'Base64' version of my password.
Also The line breaks are not really there -- only for each of
differentiating between [C]lient and [S]erver.

-------------
S: 20 www.fastmail.fm ESMTP

C: EHLO localhost.localdomain

S: 250-www.fastmail.fm
S: 250-PIPELINING
S: 250-SIZE 10120000
S: 250-ETRN
S: 250-STARTTLS
S: 250-AUTH OTP LOGIN PLAIN
S: 250-AUTH=OTP LOGIN PLAIN
S: 250-XVERP
S: 250 8BITMIME

c: AUTH LOGIN

s: 334 VXNlcm5hbWU6

c: ZGViZWVy

s: 334 ABCaaaaaaaaa

c: abcdefghij==

s: 235 Authentication successful
-------------

It looks to me the Authen::SASL code put the MIME'd username on the
same line as 'AUTH LOGIN'  But what is expected is that it is on its
own line.  Here is another example SMTP conversation:
  http://www.thecabal.org/~devin/postfix/smtp-auth.txt

> > p.s. I'm posting here because the man page for Authen::SASL said to 
> > post bugs here.
> 
> Huge plus points for someone who actually reads the man pages. The number of
> mails I get directly due to people not reading is huge, so thank you.
> 
> However, this page is wrong :) Authen::SASL is not disributed with perl-ldap
> anymore, so probably should not be reported here. But I dont mind :)

Thanks.

I'm now not sure where to post it - so I guess I'll just reply 
to this list. I'll respond to whoever you CC in response to me ;)

best,
Michael

Re: Authen::SASL possible bug in LOGIN mechanism

[Graham B. <gb...@po...>]

On Mon, Oct 07, 2002 at 05:46:13PM -0700, Michael de Beer wrote:
> Hi,
> 
> I am writing a perl script to send mail via SMTP, using the
> Net::SMTP module (which uses the Authen::SASL module).
> 
> I am using the most recent CPAN version of each.
> 
> When I force the module to use the PLAIN mechanism,
> my AUTH work.  But when I let the module automagically pick 
> a mechanism, it uses the LOGIN mechanism and fails. 

Odd

> Have other people gotten the LOGIN mechanism to work correctly,
> or is it possible there is a bug in it?

I cannot remember who tested it for me when I wrote it, but it worked
for them.

Do you have other applications that use LOGIN ? If so try monitoring the
network as you login and see what they pass.

> p.s. I'm posting here because the man page for Authen::SASL said to 
> post bugs here.

Huge plus points for someone who actually reads the man pages. The number of
mails I get directly due to people not reading is huge, so thank you.

However, this page is wrong :) Authen::SASL is not disributed with perl-ldap
anymore, so probably should not be reported here. But I dont mind :)

Graham.

Re: Authen::SASL possible bug in LOGIN mechanism

[Michael de B. <mad...@ap...>]

Hi,

I am writing a perl script to send mail via SMTP, using the
Net::SMTP module (which uses the Authen::SASL module).

I am using the most recent CPAN version of each.

When I force the module to use the PLAIN mechanism,
my AUTH work.  But when I let the module automagically pick 
a mechanism, it uses the LOGIN mechanism and fails. 

Here is an example of the (failing) conversation, when using the
username 'debeer'

Net::SMTP=GLOB(0x8575474)<<< 220 www.fastmail.fm ESMTP
Net::SMTP=GLOB(0x8575474)>>> EHLO localhost.localdomain
Net::SMTP=GLOB(0x8575474)<<< 250-www.fastmail.fm
Net::SMTP=GLOB(0x8575474)<<< 250-PIPELINING
Net::SMTP=GLOB(0x8575474)<<< 250-SIZE 10120000
Net::SMTP=GLOB(0x8575474)<<< 250-ETRN
Net::SMTP=GLOB(0x8575474)<<< 250-STARTTLS
Net::SMTP=GLOB(0x8575474)<<< 250-AUTH OTP LOGIN PLAIN
Net::SMTP=GLOB(0x8575474)<<< 250-AUTH=OTP LOGIN PLAIN
Net::SMTP=GLOB(0x8575474)<<< 250-XVERP
Net::SMTP=GLOB(0x8575474)<<< 250 8BITMIME
Net::SMTP=GLOB(0x8575474)>>> AUTH LOGIN ZGViZWVy
Net::SMTP=GLOB(0x8575474)<<< 535 Error: authentication failed
ERROR: Authentication failed.

Have other people gotten the LOGIN mechanism to work correctly,
or is it possible there is a bug in it?

thanks,
Michael

p.s. I'm posting here because the man page for Authen::SASL said to 
post bugs here.

p.p.s Here is a slightly modified Net::SMTP::auth function called
Net::SMTP::ext_auth() that lets me choose which mechanism to use.  I
used this to narrow down the problem to only occuring in the LOGIN
mechanism.

package Net::SMTP;
sub ext_auth { # taken from Net::SMTP, only modify $mechanisms
    my ($self, $username, $password, $mechanisms) = @_;

    require MIME::Base64;
    require Authen::SASL;

    my $m = $self->supports('AUTH',500,["Command unknown: 'AUTH'"]);
    return unless defined $m;
    my $sasl;

    if (ref($username) and UNIVERSAL::isa($username,'Authen::SASL')) {
      $sasl = $username;
      $sasl->mechanism($mechanisms);
    }
    else {
      die "auth(username, password)" if not length $username;
      $sasl = Authen::SASL->new(mechanism=> $mechanisms,
				callback => { user => $username,
                                              pass => $password,
					      authname => $username,
                                            });
    }
    my $client = $sasl->client_new('smtp',${*$self}{'net_smtp_host'},0);
    my $str    = $client->client_start;

    # We dont support sasl mechanisms that encrypt the socket traffic.
    # todo that we would really need to change the ISA hierarchy
    # so we dont inherit from IO::Socket, but instead hold it in an attribute

    my @cmd = ("AUTH", $client->mechanism, MIME::Base64::encode_base64($str,''));
    my $code;

    while (($code = $self->command(@cmd)->response()) == CMD_MORE) {
      @cmd = (MIME::Base64::encode_base64(
	$client->client_step(
	  MIME::Base64::decode_base64(
	    ($self->message)[0]
	  )
	), ''
      ));
    }

    $code == CMD_OK;
}

Re: Adding a Net::LDAP::Entry object to a directory.

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

On 4/10/02 9:34 pm, Shiva Persaud-Deolall <sh...@us...> wrote:

> Hi,
> 
> I just started using the perl-ldap modules. I'm trying to add an entry to a
> directory and I create it as follows:
> 
> $spdentry = Net::LDAP::Entry->new;
> 
> And I try to add it as follows:
> 
> $spdentry->dn("cn=shiva");

The Net::LDAP::Entry manpage says this:

"dn ( [ DN ] )

"Set or get the DN for the entry. With no arguments dn will return the
current DN. If an argument is given then it will change the DN for the entry
and return the previous value.

"NOTE: these changes are local to the client and will not appear on the
directory server until the update method is called."

> $spdentry->add(
>  'entry' => '777',
>  'openeddate' => 'Aug 5'
> );
> $mesg = $ldap->add($spdentry);

I think the problem here is that you need to call update() instead of add().

You are also quite likely to need more attributes in your entry than just
the ones in your example (like objectClass), but your initial problem is not
calling update().

Cheers,

Chris

Adding a Net::LDAP::Entry object to a directory.

[Shiva Persaud-D. <sh...@us...>]

Hi,

I just started using the perl-ldap modules. I'm trying to add an entry to a
directory and I create it as follows:

$spdentry = Net::LDAP::Entry->new;

And I try to add it as follows:

$spdentry->dn("cn=shiva");

$spdentry->add(
   'entry' => '777',
   'openeddate' => 'Aug 5'
);
$mesg = $ldap->add($spdentry);
LDAPerror("Adding", $mesg);

I get the following output:
Adding
Return code: 32 Message: LDAP_NO_SUCH_OBJECT :The server cannot find an
object specified in the request
MessageID: 2    DN:

How do I specify what object type I would like to add this entry as? Any
suggestions would be useful.




Thanks,
Shiva Persaud

Re: LDAP_OPERATIONS_ERROR :Server encountered an > internal error

[Graham B. <gb...@po...>]

On Mon, Sep 16, 2002 at 10:22:35AM +0800, Woanning wrote:
> Hi Graham,
> Thanks for your reply. I really appreciate that.
> The msg I send previously is all the output I got.
> my code is a simply script as below :

Sorry for taling so long.

> 
> I've tried to trace back the code and the LDAP.pm file, I found out that the
> program is stop at the point where when the LDAP.pm called the
> "asn_read($sock, $pdu)" function.
> 
> and if I change the line of my code from:
> $mesg->code && die "Code: ".$mesg->code."  Error:
> ".ldap_error_name($mesg->code).":".ldap_error_text($mesg->code)." ";
> to:
> $mesg->code && die $mesg->error;
> 
> then I'll get this error message : I/O Error   

Without looking at the code I would say that this signifies a bug. It sounds
as if asn_read is being called after there was an error, and then it is just
blocking. I will try to take a closer look to see if I can spot the problem.

> and I found out that the error message is generated from the asn_read
> function in the IO.pm file in the ASN1 module.
> 
> Do you have any idea why I'm getting this? Is it because I run on the
> Windows 2000? does the ASN1 library compatible with the OS? Does anybody
> successfully run it before on Windows 2000?

It should work fine on any OS.

Graham.

Re: Modifying the RDN

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

On 2/10/02 10:53 am, Ayman Alashquar <as...@at...> wrote:

> Thanks alot for your reply.
> 
> The error says that I cannot change the RDN for a non-leaf object.
> 
> Any ideas?
> 
> Regards,
> Ayman

Either get a server that supports what you want to do, or copy the entire
subtree across and then delete the old subtree.

Cheers,

Chris

RE: Modifying the RDN

[Ayman A. <as...@at...>]

Thanks alot reinhard,

One thing here, in the example you mentioned, do I have to loop for a=
ll the
entries in the ou=3Dfirst, o=3Dworld to change their parent to ou=
=3Dsecond,
o=3Dworld, or can I do the change for all the leaf objects in one sho=
t.

Let me put the problem here if you have another solution, what I am r=
ying to
do is to allow an external application to authenticate users in the
ou=3Dfirst,o=3Dworld from 5am to 5pm, and I do not want the users to =
be
authenticated after 5pm, so I am trying to move the ou=3Dfirst,o=3Dwo=
rld to
another place in the LDAP tree so that the external application canno=
t do
the authentication. Is there another way of doing this other than ren=
aming
the ou, e.g. is there a time-based access, or can I put a password on=
 the
ou=3Dfirst,o=3Dworld that disallow applications from authenticating u=
sers in
this subtree?


Regards,
Ayman

-----Original Message-----
=46rom: Voglmaier, Reinhard Erich [mailto:rv...@Gl...=
]
Sent: 26 =D1=CC=C8, 1423 10:55 =D5
To: 'Ayman Alashquar'; per...@li...
Subject: RE: Modifying the RDN


Ayman,

this cannot work. I think you get an error message saying something l=
ike:
=09subtree rename not supported.

the problem is that you try to move an entire subtree. since
dn: ou=3Dfirst,o=3Dworld    has children, that have the names

dn: cn=3Dchild1, ou=3Dfirst,o=3Dworld
dn: cn=3Dchild1, ou=3Dfirst,o=3Dworld

ecc. they should change name also.in cn=3Dchild1, ou=3Dsecond, o=3Dwo=
rld

new superior does not mean that the children of this entry should cha=
nge,
but that the entry change its parent.
in your case it would mean that you give ou=3Dfirst, o=3Dworld a new =
daddy, but
this is not your case.

now back to your example, you should
*=09add the new entry
=09=09dn: ou=3Dsecond, o=3Dworld
*=09change rdn of all children
=09=09here you have to be very exact !!!
=09=09dn: cn=3Dchild1, ou=3Dfirst, o=3Dworld
=09=09changetype: modrdn
=09=09newrdn: child1
=09=09deleterdn: 0
=09=09newsuperior: ou=3Dsecond, o=3Dworld

cheers
reinhard


btw:
exactly this case I gave as example in my upcoming book about LDAP.

( the title is not yet quite clear, but if you are interested in, dro=
p me an
e-mail )

> -----Original Message-----
> From:=09Ayman Alashquar [SMTP:as...@at...]
> Sent:=09mercoled=EC 2 ottobre 2002 00:23
> To:=09p...@li...
> Subject:=09Modifying the RDN
>
> Hi all,
>
> Does any one know how to change the RDN withing a DN , e.g., the DN=
=3D
> ou=3Dfirst,o=3Dworld need to be changed to ou=3Dsecond,o=3Dworld kn=
owing that the
> original ou=3Dfirst has children entries that should not be deleted=
. We are
> using iPlanet LDAP server 4.x
>
> I have tried the following LDIF file using ldapmmodify  but it didn=
ot
> work:
>
> dn: ou=3Dfirst,o=3Dworld
> changetype: modrdn
> newrdn: ou=3Dsecond
> deleteoldrdn: 0
> newsuperior: o=3Dworld
>
>
> Best Regards,
>
> Ayman Alashquar
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: DEDICATED SERVERS only $89!
> Linux or FreeBSD, FREE setup, FAST network. Get your own server
> today at http://www.ServePath.com/indexfm.htm