perl-ldap-dev

Re: Convert::ASN1 example needed

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

On Tue, Aug 01, 2000 at 09:15:04AM +0100, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> 
> > On Mon, Jul 31, 2000 at 04:24:44PM +0100, Chris Ridd wrote:
> >> I couldn't persuade Convert::ASN1 from messing with the time strings.
> >> Replacing 'UTCTime' above with '[UNIVERSAL 23] IMPLICIT STRING' will get
> >> the correct unadulterated times back...
> >
> > You mean you want the string exactly as it appeasrs ?
> 
> Yes. It can sometimes be useful to get the 'raw' octets. (In this case, it 
> was useful because I could compare the values with the strings I could see 
> in the cert. But it's useful for when you care about what optional parts of 
> the value are present.)

We could change the configure options to be

  decode => { time => 'raw|unixtime|timezone' }

where `unixtime' is the default

> > If you do
> >
> >   $asn->configure( decode => { timezone => 1 } );
> >
> That only gives me the following error:
> 
> Can't use string ("decode") as a SCALAR ref while "strict refs" in use at 
> /usr/lib/perl5/site_perl/5.005/Convert/ASN1.pm line 107.
>         Convert::ASN1::configure('Convert::ASN1=HASH(0x8373cf0)', 'decode', 
> 'HASH(0x83b2efc)') called at ./testcert.pl line 20

Whoops, typo :)

Change like 107 to

        $self->{options}{"${type}_${what}"} = $value;

Graham.

Re: Convert::ASN1 example needed

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

Graham Barr <gb...@po...> wrote:

> On Mon, Jul 31, 2000 at 04:24:44PM +0100, Chris Ridd wrote:
>> I couldn't persuade Convert::ASN1 from messing with the time strings.
>> Replacing 'UTCTime' above with '[UNIVERSAL 23] IMPLICIT STRING' will get
>> the correct unadulterated times back...
>
> You mean you want the string exactly as it appeasrs ?

Yes. It can sometimes be useful to get the 'raw' octets. (In this case, it 
was useful because I could compare the values with the strings I could see 
in the cert. But it's useful for when you care about what optional parts of 
the value are present.)

> By default Convert::ASN1 will return a unix time (ie UTC) of the time in
> the cert.
>
> If you do
>
>   $asn->configure( decode => { timezone => 1 } );
>
> Then the time value will be an array of two elements, the unixtime value
> and the timezone offset that was specified.
>
> We could add other options to make it just return the string.
>
> Graham.

That only gives me the following error:

Can't use string ("decode") as a SCALAR ref while "strict refs" in use at 
/usr/lib/perl5/site_perl/5.005/Convert/ASN1.pm line 107.
        Convert::ASN1::configure('Convert::ASN1=HASH(0x8373cf0)', 'decode', 
'HASH(0x83b2efc)') called at ./testcert.pl line 20

Cheers,

Chris

Re: Convert::ASN1 example needed

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

On Mon, Jul 31, 2000 at 04:24:44PM +0100, Chris Ridd wrote:
> I couldn't persuade Convert::ASN1 from messing with the time strings. 
> Replacing 'UTCTime' above with '[UNIVERSAL 23] IMPLICIT STRING' will get 
> the correct unadulterated times back...

You mean you want the string exactly as it appeasrs ?

By default Convert::ASN1 will return a unix time (ie UTC) of the time in the cert.

If you do

  $asn->configure( decode => { timezone => 1 } );

Then the time value will be an array of two elements, the unixtime value and
the timezone offset that was specified.

We could add other options to make it just return the string.

Graham.

Re: Convert::ASN1 example needed

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

Graham Barr <gb...@po...> wrote:

> On Mon, Jul 31, 2000 at 03:57:33PM +0100, Chris Ridd wrote:
>> I just had a quick go, and am having problems.
>
> Like ?

Erm, I think I just had the ASN.1 wrong :-)

Well, here's an attempt at decoding the timestamps from a cert:

-----
#!/usr/bin/perl -w

use strict;
use Carp;
use Convert::ASN1;

my $cert;
{
    local $/ = undef;
    open CERT, "mycert.der" or die;
    $cert = <CERT>;
    close CERT;
}

my $asn = Convert::ASN1->new;

# Can't get this to work. Want to stop Convert::ASN1 from changing the
# UTCTime values...
#my %opts = (
#	    timezone => [0,0]
#	   );
#$asn->configure(decode => \%opts);

# Ignore pretty much everything
$asn->prepare(q<
	      SEQUENCE {
		  SEQUENCE {
		      version      [0] IMPLICIT INTEGER OPTIONAL,
		      serialNumber ANY,
		      signature    ANY,
		      issuer       ANY,
		      SEQUENCE {
			  notBefore UTCTime,
			  notAfter UTCTime
		      }
		      subject      ANY,
		      spkinfo      ANY,
		      issueruid    [1] IMPLICIT ANY OPTIONAL,
		      subjectuid   [2] IMPLICIT ANY OPTIONAL,
		      extensions   [3] ANY OPTIONAL
		  }
		  alg ANY OPTIONAL,
		  sig BIT STRING
	      }>) or die;

my $out = $asn->decode($cert) or die;

print "NotBefore: " . $out->{notBefore} . "\n";
print "NotAfter:  " . $out->{notAfter} . "\n";

----

I couldn't persuade Convert::ASN1 from messing with the time strings. 
Replacing 'UTCTime' above with '[UNIVERSAL 23] IMPLICIT STRING' will get 
the correct unadulterated times back...

Cheers,

Chris

Re: Convert::ASN1 example needed

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

On Mon, Jul 31, 2000 at 03:57:33PM +0100, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> 
> > Well looking in the sources for Net::LDAP will show how to use it.
> >
> > But do you have the ASN.1 definition for the certificate, it also has
> > to be implicitly encoded and with indefinate lengths. Although I
> 
>                                     ^definite?

Um, yes

> In other words, Convert::ASN1 will not decode a certificate encoded using 
> BER, though a cert encoded in DER will be OK.

Right. but as I said I do have a fix for the indefinate lengths, I just have
to verify it and release it.

> > do have a fix for indefinate lengths for Convert::ASN1
> >
> > Graham.
> 
> I just had a quick go, and am having problems.

Like ?

> How does Convert::ASN1 handle ANY, Graham? I don't fancy decoding the 
> *entire* certificate so want to put in placeholders for the bits I don't 
> care about.
> 
> eg
> 
> Foo ::= SEQUENCE {
>    version [0] INTEGER,
>    serialNumber ANY,
>    subject ANY,
>    ...
> }
> 
> will that do what I expect and let me decode past the bits I don't care 
> about (serialNumber and subject in the above case)?

It should do. serialNumber in the output has should be the encoded object
it skipped over, complete with it's tag.

Graham.

Re: Convert::ASN1 example needed

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

Graham Barr <gb...@po...> wrote:

> Well looking in the sources for Net::LDAP will show how to use it.
>
> But do you have the ASN.1 definition for the certificate, it also has
> to be implicitly encoded and with indefinate lengths. Although I

                                    ^definite?

In other words, Convert::ASN1 will not decode a certificate encoded using 
BER, though a cert encoded in DER will be OK.

> do have a fix for indefinate lengths for Convert::ASN1
>
> Graham.

I just had a quick go, and am having problems.

How does Convert::ASN1 handle ANY, Graham? I don't fancy decoding the 
*entire* certificate so want to put in placeholders for the bits I don't 
care about.

eg

Foo ::= SEQUENCE {
   version [0] INTEGER,
   serialNumber ANY,
   subject ANY,
   ...
}

will that do what I expect and let me decode past the bits I don't care 
about (serialNumber and subject in the above case)?

Cheers,

Chris

Re: Convert::ASN1 example needed

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

Well looking in the sources for Net::LDAP will show how to use it.

But do you have the ASN.1 definition for the certificate, it also has
to be implicitly encoded and with indefinate lengths. Although I
do have a fix for indefinate lengths for Convert::ASN1

Graham.

On Mon, Jul 31, 2000 at 03:57:14PM +0200, vi...@al... wrote:
> Hi all,
> 
> I would like to decode an ASN.1 string. In this string a digital
> certificate is stored.
> I'm able to retrieve the userCertificate attribute value from
> the Directory server, but I still don't know how to decode the
> ASN.1. The only thing I need is the creation timestamp of the
> certificate. I looked at the Convert::ASN.1 library, but I don't
> know how to use it.
> http://search.cpan.org/doc/GBARR/Convert-ASN1-0.07/htdocs/Convert/ASN1.html
> 
> Maybe somebody has a another example how to decode ASN.1 in Perl
> with Convert::ASN1?
> 
> Thanks!
> Vincent.
> 
> 
> 
> 
> 

Re: Release 0.20 -- NEARLY

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

For those who do not want to use CVS, I have placed a tarfile
on my site at

  http://www.pobox.com/~gbarr/beta/perl-ldap-1.19_01.tar.gz

Graham.

On Sun, Jul 30, 2000 at 09:57:03PM +0100, Graham Barr wrote:
> Well 0.20 is almost ready, those who want to take a look can get
> a copy from cvs on sourceforge. The RELEASE_NOTES are below. I
> would appriciate any feedback. If no problems are found I
> will release 0.20 before the end of the week.
> 
> * Added INSTALL and CREDITS files
> * Net::LDAP::Entry ->get and ->attributes methods now support options
> * Added Net::LDAP::DSML from Mark Wilcox
> * Added Net::LDAPS from Chris Ridd
> * Many documentation updates
> * Several fixes to ::Control::* classes, they should now work as intended.
> * Net::LDAP::Entry->get now always returns a scalar result as documented.
> 
> One note. CVS on sourceforge now contains a contrib module. This module
> will be included in the release as a contrib/ directory, replacing
> teh contrib directory that is there now. If anyone has a script
> they would like to have added, and others agree, I will add it to
> CVS and give the author permission to modify it themselves.
> 
> 

Convert::ASN1 example needed

[<vi...@al...>]

Hi all,

I would like to decode an ASN.1 string. In this string a digital
certificate is stored.
I'm able to retrieve the userCertificate attribute value from
the Directory server, but I still don't know how to decode the
ASN.1. The only thing I need is the creation timestamp of the
certificate. I looked at the Convert::ASN.1 library, but I don't
know how to use it.
http://search.cpan.org/doc/GBARR/Convert-ASN1-0.07/htdocs/Convert/ASN1.html

Maybe somebody has a another example how to decode ASN.1 in Perl
with Convert::ASN1?

Thanks!
Vincent.

Important question.

[Clif H. <c-h...@ti...>]

Graham,

When is .20 going to be released?

Regards,

Clif Harden           INTERNET:  c-h...@ti...

Re: ldap->ping?

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

On Mon, Jul 31, 2000 at 10:26:22AM +0100, Chris Ridd wrote:
> > Hm, I see your point. But could we make a more generic Net::LDAP::DSE ? Is
> > it worth it ?
> 
> Supporting other DSEs is tricky in LDAP because they're not really 
> described properly in the LDAP RFCs, and the mechanism for getting them 
> (via the manageDsaIT service control) is not a standard part of LDAP.
> 
> The only commonality between DSEs is an attribute called dseType. The value 
> is a named bitstring, eg "( entry $ admPoint )", or "( root )".
> 
> If you want a more generic Net::LDAP::DSE, then it would need to hold the 
> dseType, and construct the more specific RootDSE object if it found the 
> dseType contained 'root'.

Hm, I think just ::RootDSE would be fine.

> >> I don't think there's a way to find if the first mode's supported. You
> >> can't go by vendor names and product versions, because administrators
> >> might  feasibly disable LDAPS support.
> >
> > Sure there is. Just try to connect to the LDAPS port :)
> 
> Which one? The default one?

Yes, as you said there is no way to determine if they are supporting it,
so you can only try the default port.

Graham.

Re: ldap->ping?

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

Graham Barr <gb...@po...> wrote:

> On Mon, Jul 31, 2000 at 09:44:56AM +0100, Chris Ridd wrote:
>> Mark Wilcox <mew...@un...> wrote:
>>
>> > What's listed here needs to be split into 2 objects.
>> >
>> > To test for connectity, it could be Net::LDAP::isUp($ldap,[callback =>
>> > \&callback]). by default it could try with anonymous bind. $ldap is an
>> > open Net::LDAP connection. callback is an user defined function to
>> > determine LDAP connection status.
>>
>> I'm sort of nervous about this because of the side-effects. How can we
>> implement this without side-effects?
[...]
> connection is still live.  Personally I would say just catch the errors
> to any operation and re-connect if you need to.

I agree.

>> > As for things like what supported version,SASL,controls, etc. This all
>> > should be in the server's root DSE (assuming it's LDAP 3, but an LDAP 2
>> > server can't give you this info).
>> >
>> > Thus we could have an object like Net::LDAP::DSE.
>>
>> No, that's too generic - servers have lots of DSEs and you are only
>> talking  about the root one. Net::LDAP::RootDSE would IMHO be a better
>> choice.
>
> Hm, I see your point. But could we make a more generic Net::LDAP::DSE ? Is
> it worth it ?

Supporting other DSEs is tricky in LDAP because they're not really 
described properly in the LDAP RFCs, and the mechanism for getting them 
(via the manageDsaIT service control) is not a standard part of LDAP.

The only commonality between DSEs is an attribute called dseType. The value 
is a named bitstring, eg "( entry $ admPoint )", or "( root )".

If you want a more generic Net::LDAP::DSE, then it would need to hold the 
dseType, and construct the more specific RootDSE object if it found the 
dseType contained 'root'.

>> I don't think there's a way to find if the first mode's supported. You
>> can't go by vendor names and product versions, because administrators
>> might  feasibly disable LDAPS support.
>
> Sure there is. Just try to connect to the LDAPS port :)

Which one? The default one?

> Graham.

Cheers,

Chris

Re: ldap->ping?

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

On Mon, Jul 31, 2000 at 09:44:56AM +0100, Chris Ridd wrote:
> Mark Wilcox <mew...@un...> wrote:
> 
> > What's listed here needs to be split into 2 objects.
> >
> > To test for connectity, it could be Net::LDAP::isUp($ldap,[callback =>
> > \&callback]). by default it could try with anonymous bind. $ldap is an
> > open Net::LDAP connection. callback is an user defined function to
> > determine LDAP connection status.
> 
> I'm sort of nervous about this because of the side-effects. How can we 
> implement this without side-effects?

I too had the same concern. First I thought we could just document the
possible side effects, but I fear that is not enough. For example some
servers do not allow multiple binds, so using an anon bind is useless
as afterwards you will have to reconnect anyway. Plus if you are already
bound, you will loose that binding.

But then someone suggested doing a simple search. This could work with
minimal side effects. But the sync/async-ness troubles me. I suppose by
nature ->ping is a sync operation as you are trying to determine if the
connection is still live.  Personally I would say just catch the errors
to any operation and re-connect if you need to.

> > As for things like what supported version,SASL,controls, etc. This all
> > should be in the server's root DSE (assuming it's LDAP 3, but an LDAP 2
> > server can't give you this info).
> >
> > Thus we could have an object like Net::LDAP::DSE.
> 
> No, that's too generic - servers have lots of DSEs and you are only talking 
> about the root one. Net::LDAP::RootDSE would IMHO be a better choice.

Hm, I see your point. But could we make a more generic Net::LDAP::DSE ? Is
it worth it ?

> > Now for SSL connectivity. I don't know how to easily test for that until
> > we get Net::LDAPS rolled into to Net::LDAP. Because Net::LDAPS does
> > require a C compiler (well Net::LDAPS doesn't but the underlying SSL
> > modules it builds upon do), we don't really want to make this a required
> > object.
> 
> Servers support SSL in two ways. The first is by listening on a separate 
> port (default 636) and requiring SSL connections on that port. That's what 
> Net::LDAPS uses.
> 
> The second is using the *normal* LDAP port (default 389) and allowing the 
> user to switch into SSL mode (actually, TLS mode) using the startTLS 
> extended operation. This is the recommended way of using SSL (er, TLS) with 
> a directory, and is standardized in RFC 2830.
> 
> To find out if the second mode is supported, check the supportedExtension 
> attribute contains the startTLS OID (1.3.6.1.4.1.1466.20037)
> 
> I don't think there's a way to find if the first mode's supported. You 
> can't go by vendor names and product versions, because administrators might 
> feasibly disable LDAPS support.

Sure there is. Just try to connect to the LDAPS port :)

Graham.

Re: ldap->ping?

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

Mark Wilcox <mew...@un...> wrote:

> What's listed here needs to be split into 2 objects.
>
> To test for connectity, it could be Net::LDAP::isUp($ldap,[callback =>
> \&callback]). by default it could try with anonymous bind. $ldap is an
> open Net::LDAP connection. callback is an user defined function to
> determine LDAP connection status.

I'm sort of nervous about this because of the side-effects. How can we 
implement this without side-effects?

> As for things like what supported version,SASL,controls, etc. This all
> should be in the server's root DSE (assuming it's LDAP 3, but an LDAP 2
> server can't give you this info).
>
> Thus we could have an object like Net::LDAP::DSE.

No, that's too generic - servers have lots of DSEs and you are only talking 
about the root one. Net::LDAP::RootDSE would IMHO be a better choice.

Good idea though.

> Now for SSL connectivity. I don't know how to easily test for that until
> we get Net::LDAPS rolled into to Net::LDAP. Because Net::LDAPS does
> require a C compiler (well Net::LDAPS doesn't but the underlying SSL
> modules it builds upon do), we don't really want to make this a required
> object.
>
> Mark

Servers support SSL in two ways. The first is by listening on a separate 
port (default 636) and requiring SSL connections on that port. That's what 
Net::LDAPS uses.

The second is using the *normal* LDAP port (default 389) and allowing the 
user to switch into SSL mode (actually, TLS mode) using the startTLS 
extended operation. This is the recommended way of using SSL (er, TLS) with 
a directory, and is standardized in RFC 2830.

To find out if the second mode is supported, check the supportedExtension 
attribute contains the startTLS OID (1.3.6.1.4.1.1466.20037)

I don't think there's a way to find if the first mode's supported. You 
can't go by vendor names and product versions, because administrators might 
feasibly disable LDAPS support.

Cheers,

Chris

Re: ldap->ping?

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

On Thu, Jul 27, 2000 at 09:33:18PM -0500, Mark Wilcox wrote:
> What's listed here needs to be split into 2 objects.
> 
> To test for connectity, it could be Net::LDAP::isUp($ldap,[callback =>
> \&callback]). by default it could try with anonymous bind. $ldap is an open
> Net::LDAP connection. callback is an user defined function to determine LDAP
> connection status.

I think I would like to keep it called `ping'

> As for things like what supported version,SASL,controls, etc. This all should
> be in the server's root DSE (assuming it's LDAP 3, but an LDAP 2 server can't
> give you this info).
> 
> Thus we could have an object like Net::LDAP::DSE.
> 
> You could get it by calling:
> my $dse = $ldap->get_dse();
> 
> this could have methods like this:
> $dse->version() #returns version
> $dse->sasl() #returns an array of SASL elements
> $dse->schema() #returns an array of names of schema entries
> $dse->controls() #returns array of OIDS of supported controls
> $dse->contexts() #return an array of contexts on the server
> $dse->get("dse attribute") #returns an array of elements that for the attribute
> passed to get

I like this idea. And as root_dse already returns an entry and Net::LDAP::DSE
could just be a subclass of Net::LDAP::Entry it would also be backwards compatable.

Graham.

Re: ldap->ping?

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

Hi all (again),

>> containing functions/objects/whatever that query the ldap server to find
>> out what it's capable of?
>> ie:
>> is it "up"? - with an anonymous bind
>> is is "up"? - with a malformed packet request
>
>Do you really want to give the user control over what type of check to do ?

Why not... the best API is one that is simple to use with plenty of
defaults, but open enough to allow the user to use advanced options if they
prefer/require...  That's also the perl way of thinking isn't it?  I think
Marks suggestion is great, allow an optional call back, default to a decent
one(or more) if it's not provided... like:

Net::LDAP::isUp($ldap,[callback =>\&callback|callback
=>'anonymous'|callback =>'malformed']). 

>IIRC, This is all avaliable from the root DSE. But I guess you are looking
>for a simpler approach than
>
>  $dse = $ldap->root_dse;
>  $dse->get('supportedVersions'); # I forget the attribute name

The fact that you forget the attribute name is a perfect reason for
allowing a simpler approach.

I'm hopeless at remembering standard attribute names,etc..and why should I
have to?  If it's used frequently enough, include it as an option/default.
eg: $dse->getSupportedVersions();
I know in this case the code is trivial, and probably not a good candidate
for it, but you see my point don't you?

>> P.S. regarding the Ldap::Cooked (or whatever)...  I for one like the option
>> of a simple "foolproof" API that is smart enough to figure out things like
>> the ldap version to talk with(currently 3 falling back to 2),
>
>You should bind to the version of which feature you need. If you don't use
>version 3 features bind as version 2. If you want v3 feature, falling back
to binding as
>v2 is the wrong thing to do.

What if I have the situation where I would prefer a secure connection to
keep away potential prying eyes, but I want the connection to succeed even
if that's not possible. (ie prefer a ssl connection using the version 3
protocol, but be happy to fall-back to version 2 on an unencrypted channel
if I have no other option) 

I'm big on fail-safes and fall backs..I like scripts to keep on working no
matter what goes wrong.... 

>> whether ssl
>> is supported on the server end (with a fall-back if its not),
>
>This is dangerous. If you want SSL it is normally for a reason, so falling
>back is REALLY the wrong thing.

As above, I like scripts to keep on working no matter what goes wrong.
Which is worse.. having thousands of users that can't log in because a
script failed to update their LDAP settings (sorry attributes) correctly,
or having a potentially unsecure connection to do it?    I guess it depends
on the situation.

>
>> if searches
>> are limited then automatically do multiple searches invisibly, etc etc.
>
>The Net::LDAPiranah module did this but I don't think it works with the
>latest version. But we will get it going again.

I'd Love to see it as an advanced option to the standard search function/s.

my 2c.
David.





--------------------------------------------------------------------
David Bussenschutt          Email: D.B...@ma...
Senior Computing Support Officer & Systems Administrator/Programmer
Location: Griffith University. Information Technology Services
          Brisbane Qld. Aust.  (TEN bldg. rm 1.33) Ph: (07)38757079
--------------------------------------------------------------------

Sever Control OIDS for ActiveDir?

[Eric N. <eni...@cp...>]

Does anyone know or have documentation on LDAP server controls for
ActiveDirectory?  I haven't found anything relating to what each function is
an how it relates to the OIDs.
Thanks
Eric

Release 0.20 -- NEARLY

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

Well 0.20 is almost ready, those who want to take a look can get
a copy from cvs on sourceforge. The RELEASE_NOTES are below. I
would appriciate any feedback. If no problems are found I
will release 0.20 before the end of the week.

* Added INSTALL and CREDITS files
* Net::LDAP::Entry ->get and ->attributes methods now support options
* Added Net::LDAP::DSML from Mark Wilcox
* Added Net::LDAPS from Chris Ridd
* Many documentation updates
* Several fixes to ::Control::* classes, they should now work as intended.
* Net::LDAP::Entry->get now always returns a scalar result as documented.

One note. CVS on sourceforge now contains a contrib module. This module
will be included in the release as a contrib/ directory, replacing
teh contrib directory that is there now. If anyone has a script
they would like to have added, and others agree, I will add it to
CVS and give the author permission to modify it themselves.

Re: Net::LDAP modify examples typo

[Mark W. <mew...@un...>]

+1 require

mark

Graham Barr wrote:

> Well there is sonething that needs to be fixed. I am in two minds to
> either require the [] or allow them to be dropped if the value is a single
> value.
>
> Graham.
>
> On Fri, Jul 28, 2000 at 06:16:04PM +0200, Arvid Requate wrote:
> > Hi,
> >
> > Some time ago I asked about a problem with the $ldap->modify command
> > in combination with the "changes" syntax, resulting in "incorrect PDU structure"
> > messages. Now I got it working and found that there seems to be a typo
> > in the perldoc of Net:LDAP, where it reads in the examples section
> > of the modify command:
> >
> > -----------------------------------------------------------------------
> > $ldap->modify( $dn,
> >   changes => [
> >     add     => [ sn => 'Barr' ],              # Add sn=Barr
> >     delete  => [ faxNumber => []],            # Delete all fax numbers
> >     delete  => [ telephoneNumber => ['911']], # delete phone number 911
> >     replace => [ email => 'gb...@po...']  # change email address
> >   ]
> > );
> > -----------------------------------------------------------------------
> >
> > I guess there should be brakets around the values 'Barr' and the email-
> > address, as it is stated in the preceding text that arrayreferences
> > are expected here.
> >
> > Best regards
> >
> >  Arvid Requate
> >

Re: Net::LDAP modify examples typo

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

Well there is sonething that needs to be fixed. I am in two minds to
either require the [] or allow them to be dropped if the value is a single
value.

Graham.

On Fri, Jul 28, 2000 at 06:16:04PM +0200, Arvid Requate wrote:
> Hi,
> 
> Some time ago I asked about a problem with the $ldap->modify command
> in combination with the "changes" syntax, resulting in "incorrect PDU structure"
> messages. Now I got it working and found that there seems to be a typo
> in the perldoc of Net:LDAP, where it reads in the examples section
> of the modify command:
> 
> -----------------------------------------------------------------------
> $ldap->modify( $dn,
>   changes => [
>     add     => [ sn => 'Barr' ],              # Add sn=Barr
>     delete  => [ faxNumber => []],            # Delete all fax numbers
>     delete  => [ telephoneNumber => ['911']], # delete phone number 911
>     replace => [ email => 'gb...@po...']  # change email address
>   ]
> );
> -----------------------------------------------------------------------
> 
> I guess there should be brakets around the values 'Barr' and the email-
> address, as it is stated in the preceding text that arrayreferences
> are expected here.
> 
> Best regards
> 
>  Arvid Requate
> 

Re: [Fwd] Re: (no subject)

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

Graham Barr <gb...@po...> wrote:

>  print "$entry->dump\n";

That would work better as:

   print $entry->dump, "\n";

Cheers,

Chris

Re: [Fwd] Re: (no subject)

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

I know we have talked about this before, but this needs to be fixed.
There should be a method which will always return something.

Or Net::LDAP::Util needs to be referenced by the docs in ::Message
for ->code, but whatever this needs to be made easier to find.

Graham.

On Fri, Jul 28, 2000 at 05:15:12PM -0400, Jim Harle wrote:
> Use 
>   $results->code && die Net::LDAP::Util::ldap_error_text($results->code)
> instead of
>   $results->code && die $results->error;
> to get the correct error text
> 
>   --Jim Harle
> 
> On Fri, 28 Jul 2000, Graham Barr wrote:
> 
> > ----- Forwarded message from Alex Kilimnik <sac...@ya...> -----
> > 
> > I have come to another roadblock and have not found
> > any documentation on the error I am receiving from
> > Perl during the execution of the script. The error I
> > am receiving from perl is "Died at ldap.pl line 9".
> > 
> > Below is a copy of my code which I modeled after
> > your example in the perldoc.  I apologize for
> > bothering
> > you, I am new to LDAP.
> > 
> > use Net::LDAP;
> > 
> > $ldap = Net::LDAP->new('x.x.x.x') or die "$@";
> > $ldap->bind;
> > $results = $ldap->search( base => "o=xxxxxx.com",
> >                           filter => ="(&(sn=Jones))"
> >                         );
> > $results->code && die $results->error;
> > foreach $entry ($results->entries) {
> >  print "$entry->dump\n";
> > }
> > $ldap->unbind;
> > 
> > 
> > Thanks in advance for any assistance.
> > 
> > Regards,
> > Alex
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Kick off your party with Yahoo! Invites.
> > http://invites.yahoo.com/
> > 
> > 
> > ----- End forwarded message -----
> > 
> > 
> 
> 

Re: AuthNetLDAP

[wiLL <wol...@sk...>]

Thanks ! this one helped me a lot , now I can continue with my work ...

At 11:23 PM 7/28/00 , Graham Barr wrote:
>I guess from the error report it also has DynaLoader in @ISA which
>probably is not needed anymore either.
>
>Graham.
>
>On Fri, Jul 28, 2000 at 10:02:14AM -0500, Mark Wilcox wrote:
>> Oh, that's a 'bug' caused by the fact that I turned on the wrong swith
>> when I created the module.
>> 
>> There is a line in AuthNetLDAP.pm that says:
>> bootstrap Apache::AuthNetLDAP $VERSION;
>> 
>> Comment out this line and you'll no longer get this message.
>> 
>> The next version of AuthNetLDAP won't have this.
>> 
>> Mark
>> 
>> On Fri, 28 Jul 2000, wiLL wrote:
>> 
>> > Hello Again!
>> > 
>> > At last I got this thing working with my Apache, I just really needed to
>> > upgrade my apache ..
>> > but here's another error_log I just encountered again, I checked out the
>> > directories and Autnetldap is there ..            
>> > 
>> > [Fri Jul 28 17:42:35 2000] [error] Can't locate loadable object for
module
>> > Apache::AuthNetLDAP in @INC (@INC contains:
>> > /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5/5.00503
>> > /usr/lib/perl5/site_perl/5.005/i386-linux
/usr/lib/perl5/site_perl/5.005 .
>> > /etc/httpd/ /etc/httpd/lib/perl) at (eval 5) line 3
>> > 
>> > 
>> > 
>> > 
>> > FROM: Mark Wilcox
>> >            DATE: 07/26/2000 11:12:09
>> >             SUBJECT: RE:  AuthNetLDAP
>> >              
>> >             This sounds like your mod_perl install is screwed up or you
>> > don`t have
>> >             your Apache configured so that you can change that
authentication
>> >             mechanisms in your .htaccess file.
>> > 
>> > 
>> >             Mark
>> > 
>> >             On Wed, 26 Jul 2000, wiLL wrote:
>> > 
>> >             > 
>> >             > I have installed AuthNetLDAP on my server with no problem,
>> > edited the
>> >             > .htaccess file  but I got the ff. errors when I tried to
>> > access the
>> >             > directory, here is ther error_log:
>> >             > 
>> >             > .... /home/httpd/html/casper/.htaccess: Invalid command
>> > `PerlSetVar`,
>> >             > perhaps mis-spelled or defined by a module not included in
>> > the server
>> >             > configuration
>> >             > 
>> >             > I`m new to this one and I dont know if  i`m missing
something
>> > out ?  thanks
>> >             > for any help ...
>> >             > 
>> >             > wiLL
>> >             > 
>> >             > -------------------------------------
>> >             > wiLL S. Olivete Jr.
>> >             > wol...@sk...
>> >             > pgp key id : 0x2D85D7BF
>> >             > office voice: 63.74.443.5657
>> >             > mobile: 0917.972.6384
>> >             > pager: ec 963576 
>> >             > 
>> >             > 
>> > 
>> > 
>> > 
>> > 
>> > -------------------------------------
>> > wiLL S. Olivete Jr.
>> > wol...@sk...
>> > pgp key id : 0x2D85D7BF
>> > office voice: 63.74.443.5657
>> > mobile: 0917.972.6384
>> > pager: ec 963576 
>> > 
>> > 
>> 
>> 
>> 
> 

-------------------------------------
wiLL S. Olivete Jr.
wol...@sk...
pgp key id : 0x2D85D7BF
office voice: 63.74.443.5657
mobile: 0917.972.6384
pager: ec 963576 

Re: ldap->ping?

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

Graham Barr <gb...@po...> wrote:

> IIRC, This is all avaliable from the root DSE. But I guess you are looking
> for a simpler approach than
>
>   $dse = $ldap->root_dse;
>   $dse->get('supportedVersions'); # I forget the attribute name

Yeah, close. RFC 2251 specifies supportedLDAPVersion (and supportedControl 
etc) so reading that attribute should suffice. If it ain't there the server 
almost certainly doesn't support LDAPv3 so you've pretty much got no way to 
work out what it does do.

(It might support LDAPv3 but prevent read access to that attribute. 
Unlikely perhaps, but permitted.)

>
>> Mind you, if this was written, it'd be very tempting to include something
>> to test for "type" of ldap server eg Netscape/openldap/novell and
>> introduce server specific tests too.... is this a good or a bad thing?
>
> I am not sure there is a way to determine the server type. Not reliably
> anyway.

There isn't. There was an Internet draft recently which specified a place 
to put a vendor string, but with the strict instructions that clients 
weren't to make use of it to switch behaviours. So that's out - I think the 
draft got stomped on anyway.

>> whether ssl
>> is supported on the server end (with a fall-back if its not),
>
> This is dangerous. If you want SSL it is normally for a reason, so falling
> back is REALLY the wrong thing.

Absolutely this is a bad way to fall back. You should never fall back and 
change security silently.

Cheers,

Chris

Re: [Fwd] Re: (no subject)

[Jim H. <ha...@us...>]

Use 
  $results->code && die Net::LDAP::Util::ldap_error_text($results->code)
instead of
  $results->code && die $results->error;
to get the correct error text

  --Jim Harle

On Fri, 28 Jul 2000, Graham Barr wrote:

> ----- Forwarded message from Alex Kilimnik <sac...@ya...> -----
> 
> I have come to another roadblock and have not found
> any documentation on the error I am receiving from
> Perl during the execution of the script. The error I
> am receiving from perl is "Died at ldap.pl line 9".
> 
> Below is a copy of my code which I modeled after
> your example in the perldoc.  I apologize for
> bothering
> you, I am new to LDAP.
> 
> use Net::LDAP;
> 
> $ldap = Net::LDAP->new('x.x.x.x') or die "$@";
> $ldap->bind;
> $results = $ldap->search( base => "o=xxxxxx.com",
>                           filter => ="(&(sn=Jones))"
>                         );
> $results->code && die $results->error;
> foreach $entry ($results->entries) {
>  print "$entry->dump\n";
> }
> $ldap->unbind;
> 
> 
> Thanks in advance for any assistance.
> 
> Regards,
> Alex
> 
> __________________________________________________
> Do You Yahoo!?
> Kick off your party with Yahoo! Invites.
> http://invites.yahoo.com/
> 
> 
> ----- End forwarded message -----
> 
>