perl-ldap-dev

Re: userpassword

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

On Wed, Jul 04, 2001 at 10:35:11AM +0100, Graham Barr wrote:
> On Wed, Jul 04, 2001 at 10:26:50AM +0100, Chris Ridd wrote:
> > Graham Barr <gb...@po...> wrote:
> > > On Wed, Jul 04, 2001 at 09:58:37AM +0100, Chris Ridd wrote:
> > >> Graham Barr <gb...@po...> wrote:
> > >> > On Wed, Jul 04, 2001 at 09:12:01AM +0100, Chris Ridd wrote:
> > >> IIRC, IO::Socket::SSL needs to support send() and recv(), which I
> > >> imagined would mean it (and by extension Net::SSLeay) needed rewriting
> > >> to use openssl's non-blocking I/O.
> > > 
> > > Is this because Net::LDAP currently uses send() and recv() ?
> > 
> > Yes. I thought it was doing that in case we wanted to support CLDAP (a
> > version of LDAP over UDP) at some point.
> 
> There are always other ways to solve that. And right now I would
> rather support LDAPS than CLDAP
> 
> > > Is the Net::LDAPS in CVS upto date ?
> > 
> > Yes.
> 
> OK, I will make the changes.

OK, I have commited the changes to CVS, please check that I have not broken
Net::LDAPS

It seems to ne we can add this to Net::LDAP

sub start_tls {
  my $ldap = shift;

  require IO::Socket::SSL;
  IO::Socket::SSL::startTLS($ldap->socket);
}

yes ?


Graham.

Re: userpassword

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

On Wed, Jul 04, 2001 at 10:26:50AM +0100, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> > On Wed, Jul 04, 2001 at 09:58:37AM +0100, Chris Ridd wrote:
> >> Graham Barr <gb...@po...> wrote:
> >> > On Wed, Jul 04, 2001 at 09:12:01AM +0100, Chris Ridd wrote:
> >> IIRC, IO::Socket::SSL needs to support send() and recv(), which I
> >> imagined would mean it (and by extension Net::SSLeay) needed rewriting
> >> to use openssl's non-blocking I/O.
> > 
> > Is this because Net::LDAP currently uses send() and recv() ?
> 
> Yes. I thought it was doing that in case we wanted to support CLDAP (a
> version of LDAP over UDP) at some point.

There are always other ways to solve that. And right now I would
rather support LDAPS than CLDAP

> > Is the Net::LDAPS in CVS upto date ?
> 
> Yes.

OK, I will make the changes.

Graham.

Re: userpassword

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

Graham Barr <gb...@po...> wrote:
> On Wed, Jul 04, 2001 at 09:58:37AM +0100, Chris Ridd wrote:
>> Graham Barr <gb...@po...> wrote:
>> > On Wed, Jul 04, 2001 at 09:12:01AM +0100, Chris Ridd wrote:
>> >> If the server is storing hashed passwords, you should be
>> >> binding/comparing with the plain text passwords. Consider using LDAPS
>> >> or LDAPv3 startTLS if you want to prevent people from sniffing those
>> >> passwords on your network.
>> > 
>> > This reminds me. What needs to be done for Net::LDAP to support
>> > startTLS ?
>> > 
>> > Graham.
>> 
>> IIRC, IO::Socket::SSL needs to support send() and recv(), which I
>> imagined would mean it (and by extension Net::SSLeay) needed rewriting
>> to use openssl's non-blocking I/O.
> 
> Is this because Net::LDAP currently uses send() and recv() ?

Yes. I thought it was doing that in case we wanted to support CLDAP (a
version of LDAP over UDP) at some point.

> If so I am planning to change that so that Net::LDAPS does not
> need its own _sendmesg.

That would be good.

> I am also going to split the actual connect out out new(), so Net::LDAPS
> will not need to duplicate that, but just provide a connect sub.

That sounds sensible.

> Is the Net::LDAPS in CVS upto date ?

Yes.

> Graham.
> 

Cheers,

Chris

Re: userpassword

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

On Wed, Jul 04, 2001 at 09:58:37AM +0100, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> > On Wed, Jul 04, 2001 at 09:12:01AM +0100, Chris Ridd wrote:
> >> If the server is storing hashed passwords, you should be
> >> binding/comparing with the plain text passwords. Consider using LDAPS or
> >> LDAPv3 startTLS if you want to prevent people from sniffing those
> >> passwords on your network.
> > 
> > This reminds me. What needs to be done for Net::LDAP to support startTLS ?
> > 
> > Graham.
> 
> IIRC, IO::Socket::SSL needs to support send() and recv(), which I imagined
> would mean it (and by extension Net::SSLeay) needed rewriting to use
> openssl's non-blocking I/O.

Is this because Net::LDAP currently uses send() and recv() ?

If so I am planning to change that so that Net::LDAPS does not
need its own _sendmesg.

I am also going to split the actual connect out out new(), so Net::LDAPS will
not need to duplicate that, but just provide a connect sub.

Is the Net::LDAPS in CVS upto date ?

Graham.

Re: userpassword

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

Graham Barr <gb...@po...> wrote:
> On Wed, Jul 04, 2001 at 09:12:01AM +0100, Chris Ridd wrote:
>> If the server is storing hashed passwords, you should be
>> binding/comparing with the plain text passwords. Consider using LDAPS or
>> LDAPv3 startTLS if you want to prevent people from sniffing those
>> passwords on your network.
> 
> This reminds me. What needs to be done for Net::LDAP to support startTLS ?
> 
> Graham.

IIRC, IO::Socket::SSL needs to support send() and recv(), which I imagined
would mean it (and by extension Net::SSLeay) needed rewriting to use
openssl's non-blocking I/O.

Cheers,

Chris

Re: userpassword

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

On Wed, Jul 04, 2001 at 09:12:01AM +0100, Chris Ridd wrote:
> If the server is storing hashed passwords, you should be binding/comparing
> with the plain text passwords. Consider using LDAPS or LDAPv3 startTLS if
> you want to prevent people from sniffing those passwords on your network.

This reminds me. What needs to be done for Net::LDAP to support startTLS ?

Graham.

Re: userpassword

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

David Bussenschutt <d.b...@ma...> wrote:
> Of course, the easiest way to do a password compare without having to 
> worry about the encoding, or UTF, or any other directory specific stuff
> is  to try doing a bind as that user.
> If you can bind, then the password was OK. 
> Isn't that easier than the other options given?

Yes and no. When you send a bind to the server, internally it issues a
compare operation against the userPassword attribute etc, so bind and
compare should basically both work and fail identically when given the same
input.

The reason you might want to use compare instead of bind is because some
servers will close the TCP connection when you unbind, which is a pain if
you're trying to have your authentication code embedded in a long lived
process, eg mod_perl.

Also of course, it might be possible to bind as the manager of the server
and then bind as user 'A', but not bind as user 'A' and then bind as user
'B' due to access controls.

For a short-lived CGI script you can get away with creating a connection
and doing a bind over it, but for a long-lived embedded script you want to
keep the connection open as long as possible and therefore should bind once
as the manager (or something equivalent) and then issue compare operations
on demand.

> David.

> I assume that '_properly_encoded_password' is the encripted password held 
> by
> the directory server because
> the plain text password does not provide LDAP_COMPARE_TRUE.
> 
> Is it possible to obtain username / password validation using perl-ldap
> if  I
> have the plain text password.
> I can use normal prompt for user / password for the CGI portion of my
> program, but I also need to validate the user as part of a daemon request.
> My security folks  feel that passing the encripted password to the daemon
> only proves that I was able to access the directory server and ask for the
> encripted password.

That is true, if the hash algorithm used doesn't use any 'salt'. For
example a password hashed using SHA-1 or MD5 will always hash to the same
value, but a password hashed using the traditional Unix crypt algorithm
will hash to different values each time because of the extra randomness
stirred in by the algorithm.

If the server is storing hashed passwords, you should be binding/comparing
with the plain text passwords. Consider using LDAPS or LDAPv3 startTLS if
you want to prevent people from sniffing those passwords on your network.

Cheers,

Chris

Re: userpassword

[David B. <d.b...@ma...>]

Of course, the easiest way to do a password compare without having to 
worry about the encoding, or UTF, or any other directory specific stuff is 
to try doing a bind as that user.
If you can bind, then the password was OK. 
Isn't that easier than the other options given?

David.





"Odell, Chauncey (Dyncorp)" <COd...@DT...>
Sent by: per...@li...
07/04/01 05:24 AM

 
        To:     "'per...@li...'" 
<per...@li...>
        cc: 
        Subject:        userpassword


I found in the archives from last August (with slight modification to
protect the fish)
================
to do a compare:
 use Net::LDAP::Constant;
$mesg = $ldap->compare($dn,"userpassword",_properly_encoded_password);

if ($mesg->code() == LDAP_COMPARE_TRUE)
{
       auth success
}
==================

I assume that '_properly_encoded_password' is the encripted password held 
by
the directory server because
the plain text password does not provide LDAP_COMPARE_TRUE.

Is it possible to obtain username / password validation using perl-ldap if 
I
have the plain text password.
I can use normal prompt for user / password for the CGI portion of my
program, but I also need to validate the user as part of a daemon request.
My security folks  feel that passing the encripted password to the daemon
only proves that I was able to access the directory server and ask for the
encripted password.

Thanks,
chauncey

Re: AD password change with Net::LDAP

[Christopher A B. <ca...@tc...>]

As Graham Barr once put it so eloquently:

> $ldap->modify($DN,
>   changes => [
>     delete => [$attr => []],
>     add => [ $attr => $value ]
>   ]
> );
[...]

Actually, this inspired me to a more "correct" solution for my problem 
below: instead of doing $entry->update, do something like

  my @changes = $entry->changes();
  &munge_changes(\@changes);
  $ldap->modify($entry, changes => \@changes);

> > > > What I really want to do is "change the changes", not add a 
> > > new change
> > > > to the list of changes.  My temporary workaround will likely be to
> > > > muck with the "changes" array directly.  But I'm open to better
> > > > solutions.  I see there is an (undocumented?) "changes" method that
> > > > returns the contents of the changes array.  Perhaps if it returned a
> > > > reference to the array I could muck with it without depending on the
> > > > internal representation of the Entry object.

%%  Christopher A. Bongaarts  %%  ca...@tc...       %%
%%  Internet Services         %%  http://umn.edu/~cab  %%
%%  University of Minnesota   %%  +1 (612) 625-1809    %%

Re: AD password change with Net::LDAP

[Christopher A B. <ca...@tc...>]

As Dave Mills once put it so eloquently:

> On the same note, has anyone been able to get password changing using
> Net::LDAP working against AD?  I have been able able to get it working
> via a C program running on FreeBSD, but I haven't been able to get the
> password change (NOT password set) functionality to work.  According to
> http://support.microsoft.com/support/kb/articles/Q269/1/90.ASP?LN=EN-US&
> SD=gn&FR=0&qry=change%20password%20ldap&rnk=3&src=DHCS_MSPSS_gn_SRCH&SPR
> =WIN2000 you have to have a delete and add operation in a single modify
> request.  I'm using 128-bit SSL encryption and formatting the data as
> the article specified....  Any tips would be appreciated.

The article is correct in that you have to have an SSL connection
(Net::LDAPS works great), but it lies about only working in certain
operations.  I've had it succeed in entry-adds and entry-modifies with 
other attibutes.

You *do* have to format it the way they want, though; quoted and in
UTF-16(?) format (16 bits per character, little-endian):

  # 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');  # plaintext actual pw
  if (defined $opw) {
    my $upw = pack "v*", unpack "C*", qq("$opw");
    &change_changes($entry, 'replace', 'unicodePwd', $upw);
  }

Failing to do this results in an error (probably WILL_NOT_PERFORM or
CONSTRAINT_ATT_TYPE). 

This is assuming you're doing it with Administratorish permissions,
too; all bets are off if you're binding as the user.

%%  Christopher A. Bongaarts  %%  ca...@tc...       %%
%%  Internet Services         %%  http://umn.edu/~cab  %%
%%  University of Minnesota   %%  +1 (612) 625-1809    %%

Re: AD password change with Net::LDAP

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

Try this

$ldap->modify($DN,
  changes => [
    delete => [$attr => []],
    add => [ $attr => $value ]
  ]
);

There is an explaination of this in the pod

Graham.

On Tue, Jul 03, 2001 at 01:20:10PM -0700, Dave Mills wrote:
> On the same note, has anyone been able to get password changing using
> Net::LDAP working against AD?  I have been able able to get it working
> via a C program running on FreeBSD, but I haven't been able to get the
> password change (NOT password set) functionality to work.  According to
> http://support.microsoft.com/support/kb/articles/Q269/1/90.ASP?LN=EN-US&
> SD=gn&FR=0&qry=change%20password%20ldap&rnk=3&src=DHCS_MSPSS_gn_SRCH&SPR
> =WIN2000 you have to have a delete and add operation in a single modify
> request.  I'm using 128-bit SSL encryption and formatting the data as
> the article specified....  Any tips would be appreciated.
> 
> Thanks,
> Dave
> 
> > -----Original Message-----
> > From: Graham Barr [mailto:gb...@po...] 
> > Sent: Tuesday, July 03, 2001 12:22 PM
> > To: Christopher A Bongaarts
> > Cc: per...@li...
> > Subject: Re: changing Net::LDAP::Entry changes
> > 
> > 
> > You could dive into the changes structure directly, but I 
> > would not reccomentd it.
> > 
> > If it is just attribute names that need changing, why not 
> > write a filter script which reads the ldif and outputs a 
> > modified ldif file for use with Active Directory ?
> > 
> > Graham.
> > 
> > On Thu, Jun 28, 2001 at 05:27:00PM -0500, Christopher A 
> > Bongaarts wrote:
> > > The situation: we're populating MS Active Directory from a UNIX box 
> > > using LDAPS.  Our strategy is:
> > > 
> > > (1) Read changes from an LDIF-formatted file using Net::LDAP::LDIF's
> > >     read_cmd() method
> > > (2) Tweak the changes to make them work with Active Directory
> > > (3) Send the changes to AD using Net::LDAP::Entry's update() method
> > > 
> > > (1) and (3) work beautifully.  (2) has become the stumbling block, 
> > > specifically for "modify" requests.
> > > 
> > > Active Directory is particular about the format of the unicodePwd 
> > > attribute.  So I'm taking the value from the LDIF file and 
> > converting 
> > > it to the format that AD wants, then using 
> > Net::LDAP::Entry::replace() 
> > > to ditch the old value and plug in the new one.  
> > Unfortunately, this 
> > > results in the internal "changes" array having *two* replace
> > > operations: the original replace operation read in from the 
> > LDIF file,
> > > and the new one I put in there.  AD barfs on the first one as
> > > expected.
> > > 
> > > What I really want to do is "change the changes", not add a 
> > new change
> > > to the list of changes.  My temporary workaround will likely be to
> > > muck with the "changes" array directly.  But I'm open to better
> > > solutions.  I see there is an (undocumented?) "changes" method that
> > > returns the contents of the changes array.  Perhaps if it returned a
> > > reference to the array I could muck with it without depending on the
> > > internal representation of the Entry object.
> > > 
> > > %%  Christopher A. Bongaarts  %%  ca...@tc...       %%
> > > %%  Internet Services         %%  http://umn.edu/~cab  %%
> > > %%  University of Minnesota   %%  +1 (612) 625-1809    %%
> > > 
> > 
> > 
> 

AD password change with Net::LDAP

[Dave M. <dm...@ju...>]

On the same note, has anyone been able to get password changing using
Net::LDAP working against AD?  I have been able able to get it working
via a C program running on FreeBSD, but I haven't been able to get the
password change (NOT password set) functionality to work.  According to
http://support.microsoft.com/support/kb/articles/Q269/1/90.ASP?LN=3DEN-US=
&
SD=3Dgn&FR=3D0&qry=3Dchange%20password%20ldap&rnk=3D3&src=3DDHCS_MSPSS_gn=
_SRCH&SPR
=3DWIN2000 you have to have a delete and add operation in a single =
modify
request.  I'm using 128-bit SSL encryption and formatting the data as
the article specified....  Any tips would be appreciated.

Thanks,
Dave

> -----Original Message-----
> From: Graham Barr [mailto:gb...@po...]=20
> Sent: Tuesday, July 03, 2001 12:22 PM
> To: Christopher A Bongaarts
> Cc: per...@li...
> Subject: Re: changing Net::LDAP::Entry changes
>=20
>=20
> You could dive into the changes structure directly, but I=20
> would not reccomentd it.
>=20
> If it is just attribute names that need changing, why not=20
> write a filter script which reads the ldif and outputs a=20
> modified ldif file for use with Active Directory ?
>=20
> Graham.
>=20
> On Thu, Jun 28, 2001 at 05:27:00PM -0500, Christopher A=20
> Bongaarts wrote:
> > The situation: we're populating MS Active Directory from a UNIX box=20
> > using LDAPS.  Our strategy is:
> >=20
> > (1) Read changes from an LDIF-formatted file using Net::LDAP::LDIF's
> >     read_cmd() method
> > (2) Tweak the changes to make them work with Active Directory
> > (3) Send the changes to AD using Net::LDAP::Entry's update() method
> >=20
> > (1) and (3) work beautifully.  (2) has become the stumbling block,=20
> > specifically for "modify" requests.
> >=20
> > Active Directory is particular about the format of the unicodePwd=20
> > attribute.  So I'm taking the value from the LDIF file and=20
> converting=20
> > it to the format that AD wants, then using=20
> Net::LDAP::Entry::replace()=20
> > to ditch the old value and plug in the new one. =20
> Unfortunately, this=20
> > results in the internal "changes" array having *two* replace
> > operations: the original replace operation read in from the=20
> LDIF file,
> > and the new one I put in there.  AD barfs on the first one as
> > expected.
> >=20
> > What I really want to do is "change the changes", not add a=20
> new change
> > to the list of changes.  My temporary workaround will likely be to
> > muck with the "changes" array directly.  But I'm open to better
> > solutions.  I see there is an (undocumented?) "changes" method that
> > returns the contents of the changes array.  Perhaps if it returned a
> > reference to the array I could muck with it without depending on the
> > internal representation of the Entry object.
> >=20
> > %%  Christopher A. Bongaarts  %%  ca...@tc...       %%
> > %%  Internet Services         %%  http://umn.edu/~cab  %%
> > %%  University of Minnesota   %%  +1 (612) 625-1809    %%
> >=20
>=20
>=20

Re: userpassword

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

On Tue, Jul 03, 2001 at 03:24:16PM -0400, Odell, Chauncey (Dyncorp) wrote:
> I found in the archives from last August (with slight modification to
> protect the fish)
> ================
> to do a compare:
>  use Net::LDAP::Constant;
> $mesg = $ldap->compare($dn,"userpassword",_properly_encoded_password);

That should be

 $mesg = $ldap->compare($dn, attr => "userpassword", value => _properly_encoded_password);

Graham.

>       
> if ($mesg->code() == LDAP_COMPARE_TRUE)
> {
>        auth success
> }
> ==================
> 
> I assume that '_properly_encoded_password' is the encripted password held by
> the directory server because
> the plain text password does not provide LDAP_COMPARE_TRUE.
> 
> Is it possible to obtain username / password validation using perl-ldap if I
> have the plain text password. 
> I can use normal prompt for user / password for the CGI portion of my
> program, but I also need to validate the user as part of a daemon request.
> My security folks  feel that passing the encripted password to the daemon
> only proves that I was able to access the directory server and ask for the
> encripted password.
> 
> Thanks,
> chauncey
> 
> 
> 

Re: ldifsort.pl

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

Thanks, I have added it into the contrib directory

Graham.

On Sat, Jun 23, 2001 at 01:46:24PM -0400, Kartik Subbarao wrote:
> Here's another tool I'd like to contribute to Net::LDAP. Attached to
> this message is ldifsort.pl, which sorts LDIF files by a specified key
> attribute. It's pretty fast -- orders of magnitude faster than
> server-side sorting in many cases. For example, it can sort a 300MB LDIF
> file (with approximately 160K entries) in about 3 minutes.
> 
> Examples:
> 
> To sort an LDIF file of people entries by cn:
> 
> ldifsort.pl -k cn people.ldif > people.sorted.ldif
> 
> To sort an LDIF file containing multiple types of entries by dn:
> 
> ldifsort.pl -k dn entries.ldif > entries.sorted.ldif
> 
> 
> Any feedback is appreciated.
> 
> Regards,
> 
>         -Kartik

userpassword

[Odell, C. (Dyncorp) <COd...@DT...>]

I found in the archives from last August (with slight modification to
protect the fish)
================
to do a compare:
 use Net::LDAP::Constant;
$mesg = $ldap->compare($dn,"userpassword",_properly_encoded_password);
      
if ($mesg->code() == LDAP_COMPARE_TRUE)
{
       auth success
}
==================

I assume that '_properly_encoded_password' is the encripted password held by
the directory server because
the plain text password does not provide LDAP_COMPARE_TRUE.

Is it possible to obtain username / password validation using perl-ldap if I
have the plain text password. 
I can use normal prompt for user / password for the CGI portion of my
program, but I also need to validate the user as part of a daemon request.
My security folks  feel that passing the encripted password to the daemon
only proves that I was able to access the directory server and ask for the
encripted password.

Thanks,
chauncey

Re: changing Net::LDAP::Entry changes

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

You could dive into the changes structure directly, but I would not
reccomentd it.

If it is just attribute names that need changing, why not write a filter
script which reads the ldif and outputs a modified ldif file for use
with Active Directory ?

Graham.

On Thu, Jun 28, 2001 at 05:27:00PM -0500, Christopher A Bongaarts wrote:
> The situation: we're populating MS Active Directory from a UNIX box
> using LDAPS.  Our strategy is:
> 
> (1) Read changes from an LDIF-formatted file using Net::LDAP::LDIF's
>     read_cmd() method
> (2) Tweak the changes to make them work with Active Directory
> (3) Send the changes to AD using Net::LDAP::Entry's update() method
> 
> (1) and (3) work beautifully.  (2) has become the stumbling block,
> specifically for "modify" requests.
> 
> Active Directory is particular about the format of the unicodePwd
> attribute.  So I'm taking the value from the LDIF file and converting
> it to the format that AD wants, then using Net::LDAP::Entry::replace()
> to ditch the old value and plug in the new one.  Unfortunately, this
> results in the internal "changes" array having *two* replace
> operations: the original replace operation read in from the LDIF file, 
> and the new one I put in there.  AD barfs on the first one as
> expected.
> 
> What I really want to do is "change the changes", not add a new change 
> to the list of changes.  My temporary workaround will likely be to
> muck with the "changes" array directly.  But I'm open to better
> solutions.  I see there is an (undocumented?) "changes" method that
> returns the contents of the changes array.  Perhaps if it returned a
> reference to the array I could muck with it without depending on the
> internal representation of the Entry object.
> 
> %%  Christopher A. Bongaarts  %%  ca...@tc...       %%
> %%  Internet Services         %%  http://umn.edu/~cab  %%
> %%  University of Minnesota   %%  +1 (612) 625-1809    %%
> 

Re: Authen::SASL fixed

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

Please send a patch and I will inlcude it.

Graham.

On Tue, Jul 03, 2001 at 03:01:19PM -0400, Adam Saltsman wrote:
> If anyone here is interested, one of the developers i work with was able to fix
> the Authen::SASL source so that it works with OpenLDAP 2.0.7 - i think we're
> making a download available shortly.
> 
> Adam Saltsman
> Internet2/UCAID
> 
> 

Authen::SASL fixed

[Adam S. <asa...@um...>]

If anyone here is interested, one of the developers i work with was able to fix
the Authen::SASL source so that it works with OpenLDAP 2.0.7 - i think we're
making a download available shortly.

Adam Saltsman
Internet2/UCAID

Re: Version 3 Anonymous Bind Failure...

[Todd P. <tc...@mt...>]

Never mind, I can't believe I did that.  I was doing $ldap->unbind();
immediately followed by $ldap->bind(anonymous=>1, version=>3);  So, duh,
I/O Error 'cuz the connection is gone.

Thanks anyway...I'm gonna go get more coffee...sheesh.

-- 
Regards,

 ------------------------------------------------------------
| Todd Piket                        | Email: tc...@mt... |
| Programmer/Analyst                | Phone: (906) 487-1720  |
| Distributed Computing Services    |                        |
| Michigan Technological University |                        |
 ------------------------------------------------------------

Version 3 Anonymous Bind Failure...

[Todd P. <tc...@mt...>]

Hi,

	I'm trying to bind anonymously to my iPlanet Directory Server version
4.13 using Net::LDAP version 0.23.  I've tried it with the following:

1.) $ldap->bind(version=>3);
2.) $ldap->bind(anonymous=>1, version=>3);

When using method 1, I get an LDAP_INAPPROPRIATE_AUTH, error code 48.
$mesg->server_error is: No AUTH Supplied

When using method 2, I get an LDAP_OPERATIONS_ERROR, error code 1.
$mesg->server_error is: I/O Error.

What am I doing wrong?  The version 2 bind works just fine.

-- 
Regards,

 ------------------------------------------------------------
| Todd Piket                        | Email: tc...@mt... |
| Programmer/Analyst                | Phone: (906) 487-1720  |
| Distributed Computing Services    |                        |
| Michigan Technological University |                        |
 ------------------------------------------------------------

Re: Working Referral Example?

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

Also have you contacted the OpenLdap group about this, this
could be a LDAP server issue.

From their web page I believe you can search their open 
problem reports.

Clif

> 
> Can you send an example piece of code and the error that you are seeing.
> 
> Also adding $ldap->debug(15) just before the call to $ldap->search
> will create some useful output on STDERR
> 
> Graham.
> 
> On Mon, Jun 25, 2001 at 10:17:44AM -0500, Jim Dutton wrote:
> > I have attempted to use the Net::LDAP::Reference POD example, but keep
> > coming up with an empty/null "$opt" variable. Does anyone have any
> > working example of handling referral objects and following referrals?
> > 
> > Thanks.
> > 
> > 
> 
> 

Re: Perl load times with Net::LDAP

[John B. <joh...@ne...>]

> The reason is simple: Net::LDAP is a lot of pure perl code. This takes awhile
> for Perl to compile. The only way around this is to utilize a caching
> mechanism such as FastCGI or mod_perl.

Those sorts of mechanisms should work. There is an additional reason why
this step is slow, however. At module load time, the textual
representation of the ASN.1 (Net/LDAP/ASN.pm) is parsed into a memory
representation needed by Convert::ASN1 - this was the single biggest time
user when I looked at this a while back.

I got as far as putting together dump/restore methods for Convert::ASN1
which would effectively save the results of this parsing effort (since at
the time I cared about startup time) and got some significant (to me)
speedups, but the opinion on the list was that it was really only of use
in a CGI environment, where solutions such as those you have described are
more effective anyway.

As an argument against "but it doesn't hurt, why not add it?" there is the
effort of maintaining the code, which as anyone who has used or updated
the problematic stuff I left behind in Net::LDAP::Schema.pm can tell you
is not to be ignored :-)

If you have real problems getting the mod_perl etc to work for you we
could have another discussion on the list about this - I might even still
have the patch around in a dusty corner somewhere.

regards,

jb

Re: Minor documentation patches

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

On Sat, Jun 30, 2001 at 11:18:07PM +0200, Viktor Leijon wrote:
> Hello all.
> 
> I have been giving a course on Net::LDAP, and in preparing the material I found a few things 
> with the documentation that I thought might be wrong. I am attaching a few diff:s with 
> suggestions for changes. I am not at all sure that the changes are correct, but I thought that 
> I might as well share them.

Thanks.

> Index: Filter.pod
> ===================================================================
> RCS file: /cvsroot/perl-ldap/ldap/lib/Net/LDAP/Filter.pod,v
> retrieving revision 1.2
> diff -r1.2 Filter.pod
> 29,34c29
> < Parse FILTER. The next call to ber will return this filter encoded.
> < 
> < =item asn
> < 
> < Return the data structure suitable for passing directly to L<Convert::ASN1>
> < to encode a filter object.
> ---
> > Parse FILTER. The next use of this object vill use this filter.

Why are you removing the definition of asn ? All that was needed here
was s/ber/asn/

Graham.

Re: Working Referral Example?

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

Can you send an example piece of code and the error that you are seeing.

Also adding $ldap->debug(15) just before the call to $ldap->search
will create some useful output on STDERR

Graham.

On Mon, Jun 25, 2001 at 10:17:44AM -0500, Jim Dutton wrote:
> I have attempted to use the Net::LDAP::Reference POD example, but keep
> coming up with an empty/null "$opt" variable. Does anyone have any
> working example of handling referral objects and following referrals?
> 
> Thanks.
> 
> 

[Fwd] [ perl-ldap-Bugs-436535 ] Referral problem with openldap 2.0.7

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

Can anyone else confirm this ?

Graham.

----- Forwarded message from no...@so... -----

Date: Tue, 26 Jun 2001 15:11:23 -0700
To: no...@so...
From: no...@so...
Subject: [ perl-ldap-Bugs-436535 ] Referral problem with openldap 2.0.7

Bugs item #436535, was opened at 2001-06-26 15:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105050&aid=436535&group_id=5050

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Garrigues (cwg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Referral problem with openldap 2.0.7

Initial Comment:
I just upgraded from openldap 1.2.11 to openldap 2.0.7
and suddenly I can't follow referrals any more.

The implementation of referrals changed in openldap, so
I suppose that might be related.

What my code did that worked under 1.x was to compare
$msg->code to LDAP_PARTIAL_RESULTS and if matched, I
parsed the redirection out of $msg->error.

The problem is that the redirection returned by ->error
is missing part of the URL and only lists the host that
we're pointing at, not the new base to search from.  I
tried looking at ->referrals, but that returns an empty
list.

I've just sent a request to get on the mailing list, so
I will repeat this request there when/ sourceforge
confirms my subscription.

Chris


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105050&aid=436535&group_id=5050

----- End forwarded message -----