perl-ldap-dev

Changing a user password via LDAP in Active Directory

[Edgington, J. A. <je...@um...>]

I can change everything else about a user via Net::LDAP except the password.
I haven't had much luck finding anything on the MS web site about this.

If someone has successfully done this via Net::LDAP, I would greatly
appreciate some guidance. 

Thanks.

jeff e.

Bug in SASL implementation in perl-ldap-0.22

[Simon W. <sx...@sx...>]

There appears to be a bug in Net::LDAP::Bind, with regards to how it passes 
server SASL credentials on to the relevant routines. Both the hash, and
the entry in the hash appear to be wrong.

Currently, $result->{saslCred} is used. I believe this should be replaced with
either 
$bind->{serverSaslCreds} or 
$result->{protocolOp}{bindResponse}{serverSaslCreds}

The attached patch fixes this, I've tested it with a GSSAPI based 
Authen::SASL module to successfully authenticate against OpenLDAP 2.0.7.

Cheers,

Simon

Bind Help (again)

[Shain M. <sm...@tv...>]

Hi,
I am running into yet another problem here ( everytime I think I know 
what I am doing...I find out I don't :-)  Anyway here is my code.   The 
first part CheckLogin works fine...the username is checked and if it is 
there it then goes to CheckPasswordHTML and tries to bind as that user.  
When I check the ldap log I see the the CheckLogin binds anonymously as 
it should.  The problem is that the log shows CheckPasswordHTML as and 
anonymous bind  too.  I have printed out the $userDNfinal variable and 
it shows the correct value..any ideas?
Thanks again
Shain
PS-Do I need the unbind statements in there...I have tried with both 
present and commented out and it did not seem to make a difference.

sub CheckLogin {
$ldap = new Net::LDAP('server');
$mesg = $ldap->bind();
$mesg = $ldap->search (
   base    =>    'dc=tvd,dc=com',
   scope    =>    'sub',
   filter => "uid=$UserName"
);

if ($mesg->count != 1)
{
$mesg = $ldap->unbind();
&BadLoginHTML;
} else {
$mesg = $ldap->unbind();
&CheckPasswordHTML;
}
}

sub CheckPasswordHTML {
$userDN1 = "uid=";
$userDN2 = ",ou=People,dc=tvd,dc=com";

$ldap = new Net::LDAP('server');

$userDNfinal = $userDN1 . $UserName . $userDN2;
$mesg = $ldap->bind (
   base    =>    $userDNfinal,
   password => $Password
);

if ($mesg->code() == 49)
{
&BadLoginHTML;
} else {
&ConfirmLoginHTML;
}
}

Re: Controling Referrals

[P.S.Saragiotis <ps...@au...>]

"P.S.Saragiotis" wrote:
> 
> Hello all,
>   I've searched the lists archives but i couldnt find anything about
> LDAP_CONTROL_REFERRALS and how can i use it. I 'm making a connection to
> my ldap server (netscape v 4.11) and i wish to manage (add , delete the
> ref: attribute) the referral entries. I used the following control in my
> search :
> my $ctrl = Net::LDAP::Control->new(
>         type    =>      LDAP_CONTROL_REFERRALS,
>         value   =>      0,
>         critical=>      0
> );
> 
> $mesg = $cldap->search (
>                 base    => "ou=$server,o=auth,c=gr",
>                 scope   => "base",
>                 filter  => "objectclass=*",
>                 control => [ $ctrl ]
>         );
> 
> It returns the referrals and code 10 instead of the actual entries.
> Should nt this work ? Am i on the wrong path ? Any sugestions ?
> 
> Thank you.


Dont bother i found a solution to my problem. When i wish to have the
actual referral entries, intead of the referrals i use :

my $ctrl = Net::LDAP::Control->new(
        type    =>      LDAP_CONTROL_MANAGEDSAIT,
);

$mesg = $cldap->search (
                 base    => $base
                 scope   => base
                 filter  => "objectclass=*",
                 control => [ $ctrl ]
         );

Re: LDAP bind

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

You can also check the Examples pod or html.

Clif


> 
> Doesn't anyone read the docs anymore?  :)
> 
> All LDAP operations in Net::LDAP return a Net::LDAP::Message object.
> Inside this object is a result code.
> If the result code is not 0 then there has been an error (except for
> compare which expects 5 & 6 as True & False). You can use something like
> this:
> die("bind failed with ",$mesg->code(),"\n") if $mesg->code();
> 
> if you read the docs for Net::LDAP::Util you'll see how to get a human
> readable string from such an error code.
> 
> Mark
> 
> Shain Miley wrote:
> 
> > Hi all,
> > I am almost finished in my quest to authenticate with perl-ldap...one
> > last question...how can I tell if the ldap->bind failed or not.
> > Thanks
> > Shain
> 
> 
> 

Re: LDAP bind

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

Doesn't anyone read the docs anymore?  :)

All LDAP operations in Net::LDAP return a Net::LDAP::Message object.
Inside this object is a result code.
If the result code is not 0 then there has been an error (except for
compare which expects 5 & 6 as True & False). You can use something like
this:
die("bind failed with ",$mesg->code(),"\n") if $mesg->code();

if you read the docs for Net::LDAP::Util you'll see how to get a human
readable string from such an error code.

Mark

Shain Miley wrote:

> Hi all,
> I am almost finished in my quest to authenticate with perl-ldap...one
> last question...how can I tell if the ldap->bind failed or not.
> Thanks
> Shain

LDAP bind

[Shain M. <sm...@tv...>]

Hi all,
I am almost finished in my quest to authenticate with perl-ldap...one 
last question...how can I tell if the ldap->bind failed or not.
Thanks
Shain

Re: LDAP AUTH

[Kurt D. Z. <Ku...@Op...>]

Just a general comment:

Note that the bind operation is the only mechanism
to authenticate a user to the directory.  Use of
other mechanisms may authenticate some user against
data held in the directory, but this is not the
same as authenticating the user to the directory.
One should note that the all (or any) of the
information used by the bind operation to
authentication a user may not be accessible by
other operations.

Kurt

Re: LDAP AUTH

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

Shain Miley wrote:

> Hi,
> I have two questions I am hoping you guys can help me with.
> 1)    I am trying to setup a web app to authenticate with perl-ldap
> (Net::LDAP). The user will submit a form that will contain their
> username and password.  I have written the perl code to contact the ldap
> server and it does the search...what I need to know is how to find out
> if the search was successful.  I don't need the server to return a list
> of usernames, I need to know if the username was found.  If is was found
> good...move on to the password if the username was not found then the
> does not need to check the password.

if ($mesg->count)
{
    do something
}



>
>
> 2)I am thinking about using the compare feature of perl-ldap for the
> password check but I can not find much documentation on it...does anyone
> know a good spot to look?

Most of the time people don't use compare they do a search, get the user's
DN & then do a bind. If you use compare, you're assuming you have access to
read passwords on the server & that you know how the passwords are hashed.
Then you have to hash the password and then do the compare.

A compare works like this:
my $mesg = $ldap->compare(dn,attr,value)

if the result code is 6 then the result is True (or is 5 true and 6 is
false?). Thus if compare is not equal to "TRUE" then the compare failed.

I have a compare example in the contrib directory in the ismember.pl
script.

Mark



>
> Thank you in advance for any help you can provide.
> Shain

LDAP AUTH

[Shain M. <sm...@tv...>]

Hi,
I have two questions I am hoping you guys can help me with.
1)    I am trying to setup a web app to authenticate with perl-ldap 
(Net::LDAP). The user will submit a form that will contain their 
username and password.  I have written the perl code to contact the ldap 
server and it does the search...what I need to know is how to find out 
if the search was successful.  I don't need the server to return a list 
of usernames, I need to know if the username was found.  If is was found 
good...move on to the password if the username was not found then the 
does not need to check the password. 

2)I am thinking about using the compare feature of perl-ldap for the 
password check but I can not find much documentation on it...does anyone 
know a good spot to look?
Thank you in advance for any help you can provide.
Shain

Controling Referrals

[P.S.Saragiotis <ps...@au...>]

Hello all,
  I've searched the lists archives but i couldnt find anything about
LDAP_CONTROL_REFERRALS and how can i use it. I 'm making a connection to
my ldap server (netscape v 4.11) and i wish to manage (add , delete the
ref: attribute) the referral entries. I used the following control in my
search :
my $ctrl = Net::LDAP::Control->new(
        type    =>      LDAP_CONTROL_REFERRALS,
        value   =>      0,
        critical=>      0
);

$mesg = $cldap->search (
                base    => "ou=$server,o=auth,c=gr",
                scope   => "base",
                filter  => "objectclass=*",
                control => [ $ctrl ]
        );

It returns the referrals and code 10 instead of the actual entries.
Should nt this work ? Am i on the wrong path ? Any sugestions ?

Thank you.

Re: problem perl-ldap-0.22 working with OpenLDAP

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

Javier <te...@rd...> wrote:
> Hello guys!
> 
> I have found one problem with module LDAP.pm working with the LDAP server
> OpenLDAP.
> 
> When I try request the schema of the server, it don't answer, it is
> becouse in the subroutine of LDAP.pm
> 
> sub schema {
> 
> ...
> $mesg = $self->search(
>    base=>$base,
>    scope=>'base',
>    filter =>'(objectclass=*)',
>   );
> ....
> }
> 
> but OpenLDAP need to specify the name of attribute request. Then it anwer
> correctly. For this reason when I write a script how this:
> 
> $schema = $ldap->schema(); don't answer correctly , becouse OpenLDAP
> don't answer the attribute subschemasubentry if it don't request
> specifically.
> 
> Can somebody helpme?

The code is broken, I think.

If the Net::LDAP::schema() method is trying to read the subschema subentry
mentioned in the root DSE, then it should be doing this:

	$mesg = $self->search(
		base => "$base",
		scope => 'base',
		filter => '(objectclass=subschema)',
		attrs => [qw(attributeTypes objectClasses ldapSyntaxes)]
	);

in order to comply with the last paragraph of RFC 2251 section 3.2.2. It is
debatable whether the 'attrs' line has to be there; the specs do not
indicate either way.

However, there's another way to get at the schema. In LDAPv3 the schema is
accessible directly from every entry in operational attributes. So don't
use the Net::LDAP::schema() method. Just do a read (well, a base object
search) of the normal entry that your schema will be applying to, and
request the 'attributeTypes', 'objectClasses' and 'ldapSyntaxes' attributes
back. Then construct a schema object directly:

	$schema = Net::LDAP::Schema->new($entry);

This is somewhat less efficient than using a subschema subentry because you
cannot cache the schema. If you read the createTimestamp/modifyTimestamp
attributes from the subschema subentries you can avoid repeatedly reading
and parsing the schema.

But it will avoid you modifying the Net::LDAP code.

> I would like don' modify LDAP.pm to resolve this problem!

It's a bug though. The filter should be (objectclass=subschema), and
*probably* the three interesting schema attributes should be requested.

> Thanks for all!
> 
> 
> 
> 



Cheers,

Chris

problem perl-ldap-0.22 working with OpenLDAP

[Javier <te...@rd...>]

Hello guys!

I have found one problem with module LDAP.pm working with the LDAP 
server OpenLDAP.

When I try request the schema of the server, it don't answer, it is 
becouse in the subroutine of LDAP.pm

sub schema {

...
$mesg = $self->search(
   base=>$base,
   scope=>'base',
   filter =>'(objectclass=*)',
  );
....
}

but OpenLDAP need to specify the name of attribute request. Then it 
anwer correctly.
For this reason when I write a script how this:

$schema = $ldap->schema(); don't answer correctly , becouse OpenLDAP 
don't answer the attribute subschemasubentry if it don't request 
specifically.

Can somebody helpme?

I would like don' modify LDAP.pm to resolve this problem!

Thanks for all!

RE: Splitting a DN into RDN's

[Klunder, J. (Hans) <J.A...@rf...>]

Graham and Chris,

Thanks very much for the DN splitting code. Yes it would be very nice if it
was incorporated into Net::LDAP.

Mozilla's $entry->hasValue($attribute,$value,$options) checks if the given
attribute has the given value. The options specify if case sensitivity
should be applied.

Regards,

Hans


-----Oorspronkelijk bericht-----
Van: Chris Ridd [mailto:chr...@me...]
Verzonden: donderdag 21 december 2000 15:08
Aan: Klunder, JAA (Hans); LDAP Mailing List
Onderwerp: Re: Splitting a DN into RDN's


"Klunder, JAA (Hans)" <J.A...@rf...> wrote:
> Hello,
> 
> Is there a simple way to split a DN into RDN's. Just splitting on comma's
> is risky since the value of the RDN can contain a comma itself.
> 
> I'm looking for something similar to explode_dn in mozilla ldap.
> 
> Mozilla also has a $entry->hasValue method which can be quite convenient,
> is there an equivalent in Net::LDAP ?
> 
> Thanks in advance,
> 
> Hans Klunder

There isn't. (Net::LDAP doesn't provide much in the way of help
manipulating values from the directory. This is a case where syntax
handlers would be nice. If I could ever get around to finishing them!)

Anyway, something like this regex *nearly* works:

while ($dn =~ m{
    \s*
    (\d[0-9\.]+|[a-zA-Z][a-zA-Z0-9-]+)                # type
    =
    (\#[a-fA-F0-9]+|                                  # hex value
     "[^"\\]*(?:\\.[^"\\]*)*"|                        # v2 quoted value
     [^\\,;+]*(?:\\[a-zA-Z0-9][a-zA-Z0-9][^\\,;+]*)*) # normal value
    ([,;+]?)                                          # separator
}gx) {
    print "type $1\n";
    print "value $2\n";
    print "separator $3\n";
}

For some reason, this always stops matching before the penultimate RDN, eg
"cn=Chris Ridd,ou=Engineering,o=MessagingDirect,c=CA" prints out the cn and
ou.

Can any regex wizards spot the problem?

Would the equivalent of the $entry->hasValue thing be Net::LDAP's get
method returning undef? I can't remember if this is what Net::LDAP does,
and I don't know what the Mozzilla library does.

Cheers,

Chris

================================================
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en 
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht 
onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en 
de afzender direct te informeren door het bericht te retourneren. 
================================================
The information contained in this message may be confidential 
and is intended to be exclusively for the addressee. Should you 
receive this message unintentionally, please do not use the contents 
herein and notify the sender immediately by return e-mail.

Re: Splitting a DN into RDN's

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

"Klunder, JAA (Hans)" <J.A...@rf...> wrote:
> Hello,
> 
> Is there a simple way to split a DN into RDN's. Just splitting on comma's
> is risky since the value of the RDN can contain a comma itself.
> 
> I'm looking for something similar to explode_dn in mozilla ldap.
> 
> Mozilla also has a $entry->hasValue method which can be quite convenient,
> is there an equivalent in Net::LDAP ?
> 
> Thanks in advance,
> 
> Hans Klunder

There isn't. (Net::LDAP doesn't provide much in the way of help
manipulating values from the directory. This is a case where syntax
handlers would be nice. If I could ever get around to finishing them!)

Anyway, something like this regex *nearly* works:

while ($dn =~ m{
    \s*
    (\d[0-9\.]+|[a-zA-Z][a-zA-Z0-9-]+)                # type
    =
    (\#[a-fA-F0-9]+|                                  # hex value
     "[^"\\]*(?:\\.[^"\\]*)*"|                        # v2 quoted value
     [^\\,;+]*(?:\\[a-zA-Z0-9][a-zA-Z0-9][^\\,;+]*)*) # normal value
    ([,;+]?)                                          # separator
}gx) {
    print "type $1\n";
    print "value $2\n";
    print "separator $3\n";
}

For some reason, this always stops matching before the penultimate RDN, eg
"cn=Chris Ridd,ou=Engineering,o=MessagingDirect,c=CA" prints out the cn and
ou.

Can any regex wizards spot the problem?

Would the equivalent of the $entry->hasValue thing be Net::LDAP's get
method returning undef? I can't remember if this is what Net::LDAP does,
and I don't know what the Mozzilla library does.

Cheers,

Chris

Re: Splitting a DN into RDN's

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

Attached is a raw script with what I was doing. Something like
this probably should be added to perl-ldap

Graham.

On Thu, Dec 21, 2000 at 01:02:57PM +0000, Graham Barr wrote:
> Hm, I wrote somethig to do just this a while back. I will
> see if I can find it.
> 
> Graham.
> 
> On Thu, Dec 21, 2000 at 01:40:03PM +0100, Klunder, JAA (Hans) wrote:
> > Hello,
> > 
> > Is there a simple way to split a DN into RDN's. Just splitting on comma's is
> > risky since the value of the RDN can contain a comma itself.
> > 
> > I'm looking for something similar to explode_dn in mozilla ldap.
> > 
> > Mozilla also has a $entry->hasValue method which can be quite convenient, is
> > there an equivalent in Net::LDAP ?
> > 
> > Thanks in advance,
> > 
> > Hans Klunder
> 

Re: Splitting a DN into RDN's

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

Hm, I wrote somethig to do just this a while back. I will
see if I can find it.

Graham.

On Thu, Dec 21, 2000 at 01:40:03PM +0100, Klunder, JAA (Hans) wrote:
> Hello,
> 
> Is there a simple way to split a DN into RDN's. Just splitting on comma's is
> risky since the value of the RDN can contain a comma itself.
> 
> I'm looking for something similar to explode_dn in mozilla ldap.
> 
> Mozilla also has a $entry->hasValue method which can be quite convenient, is
> there an equivalent in Net::LDAP ?
> 
> Thanks in advance,
> 
> Hans Klunder

Splitting a DN into RDN's

[Klunder, J. (Hans) <J.A...@rf...>]

Hello,

Is there a simple way to split a DN into RDN's. Just splitting on comma's is
risky since the value of the RDN can contain a comma itself.

I'm looking for something similar to explode_dn in mozilla ldap.

Mozilla also has a $entry->hasValue method which can be quite convenient, is
there an equivalent in Net::LDAP ?

Thanks in advance,

Hans Klunder




================================================
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en 
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht 
onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en 
de afzender direct te informeren door het bericht te retourneren. 
================================================
The information contained in this message may be confidential 
and is intended to be exclusively for the addressee. Should you 
receive this message unintentionally, please do not use the contents 
herein and notify the sender immediately by return e-mail.

Re: [Fwd] inconsistency / bug / something in Net::LDAP.

[Kurt D. Z. <Ku...@Op...>]

At 07:19 AM 12/18/00 +0000, Graham Barr wrote:
>To: gb...@po...
>From: as...@uf...
>Subject: inconsistency / bug / something in Net::LDAP.
>Date: Sun, 17 Dec 2000 21:32:18 -0500
>
>I've been having some problems using Net::LDAP against an OpenLDAP server of
>moderately recent version (Sorry, I don't know precisely which version).

I suggest you determine exactly which version of OpenLDAP you
are using (updating if appropriate) and file an issue report
with OpenLDAP <http://www.openldap.org/its/> (providing relevant
details, of course).  If you have other data which confirms that
this problem is apparent with OpenLDAP provided tools, please
provide this.


>I have determined that the problem is due to an arguably "wrong" behavior by
>the server, which is nonetheless apparently within the LDAP spec;  To wit, on
>query after succesful bind, the first packet returned is the bind success.

I would not argue that the behavior you describe is within
specification.


>So it goes
>
>>>  Bind req
><<  Bind OK.
>>>  Search filter
><<  Bind OK.
>
>[ protocol error ] 
>
>I'll include the output from a debug => 15 session for an example below.
>
>I took a look at the network traffic for a similar session for the ldapsearch
>client that comes with OpenLDAP, and determined that their ldapsearch discards
>"Answers to messages we're not expecting answers for".

The C API supports asking for what is expected and holding that
which is not asked for until asked.  Some applications never
bother to ask for all that is returned.  Even for simple
applications, such as ldapsearch(1), this is dangerous as one
may not detect and report unsolicited notifications.

>>>  Bind req
><<  Bind OK.
>>>  Search filter
><<  Bind OK.
>[ that's useless, I'll ditch it. ] 
><<  Search results
>
>
>
>After some noodling around in your code, I came up with the following patch
>which imitates that behavior, asking for another answer if the answer received
>is to a different question than I asked.
>
>*** /space/CPAN/build/perl-ldap-0.22/blib/lib/Net/LDAP.pm       Thu Sep 14 14:53:39 2000
>--- ./LDAP.pm   Sun Dec 17 21:20:31 2000
>***************
>*** 618,623 ****
>--- 618,629 ----
>  
>      my $mid = $result->{messageID};
>  
>+     if ( $mid != $what ) 
>+       {
>+       print STDERR "this ($mid) is not the message ($what) you're looking for.\n" if $debug;
>+       next;
>+       }
>+ 
>      my $mesg = $ldap->{net_ldap_mesg}->{$mid} or
>        return LDAP_PROTOCOL_ERROR;
>
>
>
>....  I thought pretty long and hard before deciding to suggest that you make
>this addition, because I see your fatal exception to "You answered a different
>question than I asked" as one reasonable interpretation of the RFC.  However,
>I decided to submit the patch anyway, following the theory of being generous
>in what you accept, and rigid in what you emit.  I think the OpenLDAP server
>is not being a great neighbor by tossing whatever answer it has close to hand
>in this case, but I do not think they actually violate the spec; After all,
>it's reasonable for them to presume that "That's why we've got message IDs in
>all the communications; the client should be aware of it".  Rude, but
>reasonable.

I suspect this to be a bug in the server.  It should be reported
so that it can be properly investigated.

I would not suggest any changes to net::LDAP to work around this
bug.  It's much better to fix the server than to propagate changes
which might have undesirable side effects.

>So, I respectfully submit this patch as making Net::LDAP more flexible without
>damaging its' utility.
>
>Thanks for your consideration.
>
>
>- Allen S. Rout
>
>
>
>
>
>Failed session example (yes, I've since changed my password. :) -- 
>
>[asr@rah perl]$ ./getattrauth.pl 
>Net::LDAP=HASH(0x80e4a44) sending:
>
>30 3E 02 01 01 60 39 02 01 02 04 25 63 6E 3D 61 0>...`9....%cn=a
>73 72 2C 20 6F 3D 55 6E 69 76 65 72 73 69 74 79 sr, o=University
>20 6F 66 20 46 6C 6F 72 69 64 61 2C 20 63 3D 55  of Florida, c=U
>53 80 0D 50 6F 64 64 79 54 72 61 69 6E 69 6E 67 S..PoddyTraining
>
>0000 30   62: SEQUENCE {
>0002 02    1:   INTEGER = 1
>0005 60   57:   [APPLICATION 0] {
>0007 02    1:     INTEGER = 2
>000A 04   37:     STRING = 'cn=asr, o=University of Florida, c=US'
>0031 80   13:     [CONTEXT 0]
>0033        :       50 6F 64 64 79 54 72 61 69 6E 69 6E 67 __ __ __ PoddyTraining
>0040        :   }
>0040        : }
>Net::LDAP=HASH(0x80e4a44) received:
>
>30 0C 02 01 01 61 07 0A 01 00 04 00 04 00 __ __ 0....a........
>
>0000 30   12: SEQUENCE {
>0002 02    1:   INTEGER = 1
>0005 61    7:   [APPLICATION 1] {
>0007 0A    1:     ENUM = 0
>000A 04    0:     STRING = ''
>000C 04    0:     STRING = ''
>000E        :   }
>000E        : }
>Net::LDAP=HASH(0x80e4a44) sending:
>
>30 40 02 01 02 63 3B 04 1D 6F 3D 55 6E 69 76 65 0@...c;..o=Unive
>72 73 69 74 79 20 6F 66 20 46 6C 6F 72 69 64 61 rsity of Florida
>2C 20 63 3D 55 53 0A 01 02 0A 01 02 02 01 00 02 , c=US..........
>01 00 01 01 00 A3 09 04 02 63 6E 04 03 61 73 72 .........cn..asr
>30 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ 0.
>
>0000 30   64: SEQUENCE {
>0002 02    1:   INTEGER = 2
>0005 63   59:   [APPLICATION 3] {
>0007 04   29:     STRING = 'o=University of Florida, c=US'
>0026 0A    1:     ENUM = 2
>0029 0A    1:     ENUM = 2
>002C 02    1:     INTEGER = 0
>002F 02    1:     INTEGER = 0
>0032 01    1:     BOOLEAN = FALSE
>0035 A3    9:     [CONTEXT 3] {
>0037 04    2:       STRING = 'cn'
>003B 04    3:       STRING = 'asr'
>0040        :     }
>0040 30    0:     SEQUENCE {
>0042        :     }
>0042        :   }
>0042        : }
>Net::LDAP=HASH(0x80e4a44) received:
>
>30 0C 02 01 01 61 07 0A 01 00 04 00 04 00 __ __ 0....a........
>
>0000 30   12: SEQUENCE {
>0002 02    1:   INTEGER = 1
>0005 61    7:   [APPLICATION 1] {
>0007 0A    1:     ENUM = 0
>000A 04    0:     STRING = ''
>000C 04    0:     STRING = ''
>000E        :   }
>000E        : }
>Protocol error at ./getattrauth.pl line 31.
>[asr@rah perl]$ 
>
>End Failed session example -- 
>
>
>----- End forwarded message -----

Re: [Fwd] inconsistency / bug / something in Net::LDAP.

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

> Greetings, sir.
> 
> I've been having some problems using Net::LDAP against an OpenLDAP server of
> moderately recent version (Sorry, I don't know precisely which version).
> 
> I have determined that the problem is due to an arguably "wrong" behavior by
> the server, which is nonetheless apparently within the LDAP spec;  To wit, on
> query after succesful bind, the first packet returned is the bind success.
> 
> So it goes
> 
> >>  Bind req
> <<  Bind OK.
> >>  Search filter
> <<  Bind OK.

Odd.

> I'll include the output from a debug => 15 session for an example below.

Thanks.

> I took a look at the network traffic for a similar session for the ldapsearch
> client that comes with OpenLDAP, and determined that their ldapsearch discards
> "Answers to messages we're not expecting answers for".   
> 
> >>  Bind req
> <<  Bind OK.
> >>  Search filter
> <<  Bind OK.
> [ that's useless, I'll ditch it. ] 
> <<  Search results

OK.

> After some noodling around in your code, I came up with the following patch
> which imitates that behavior, asking for another answer if the answer received
> is to a different question than I asked.
> 
> *** /space/CPAN/build/perl-ldap-0.22/blib/lib/Net/LDAP.pm       Thu Sep 14 14:53:39 2000
> --- ./LDAP.pm   Sun Dec 17 21:20:31 2000
> ***************
> *** 618,623 ****
> --- 618,629 ----
>   
>       my $mid = $result->{messageID};
>   
> +     if ( $mid != $what ) 
> +       {
> +       print STDERR "this ($mid) is not the message ($what) you're looking for.\n" if $debug;
> +       next;
> +       }
> + 
>       my $mesg = $ldap->{net_ldap_mesg}->{$mid} or
>         return LDAP_PROTOCOL_ERROR;

Um no. That will break several other things, for one $what is not always
defined. The fix should probably be to just change 

       my $mesg = $ldap->{net_ldap_mesg}->{$mid} or
-         return LDAP_PROTOCOL_ERROR;
+         next;

Graham.

[Fwd] inconsistency / bug / something in Net::LDAP.

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

----- Forwarded message from as...@uf... -----

To: gb...@po...
From: as...@uf...
Subject: inconsistency / bug / something in Net::LDAP.
Date: Sun, 17 Dec 2000 21:32:18 -0500



Greetings, sir.

I've been having some problems using Net::LDAP against an OpenLDAP server of
moderately recent version (Sorry, I don't know precisely which version).

I have determined that the problem is due to an arguably "wrong" behavior by
the server, which is nonetheless apparently within the LDAP spec;  To wit, on
query after succesful bind, the first packet returned is the bind success.

So it goes

>>  Bind req
<<  Bind OK.
>>  Search filter
<<  Bind OK.

[ protocol error ] 

I'll include the output from a debug => 15 session for an example below.

I took a look at the network traffic for a similar session for the ldapsearch
client that comes with OpenLDAP, and determined that their ldapsearch discards
"Answers to messages we're not expecting answers for".   

>>  Bind req
<<  Bind OK.
>>  Search filter
<<  Bind OK.
[ that's useless, I'll ditch it. ] 
<<  Search results



After some noodling around in your code, I came up with the following patch
which imitates that behavior, asking for another answer if the answer received
is to a different question than I asked.

*** /space/CPAN/build/perl-ldap-0.22/blib/lib/Net/LDAP.pm       Thu Sep 14 14:53:39 2000
--- ./LDAP.pm   Sun Dec 17 21:20:31 2000
***************
*** 618,623 ****
--- 618,629 ----
  
      my $mid = $result->{messageID};
  
+     if ( $mid != $what ) 
+       {
+       print STDERR "this ($mid) is not the message ($what) you're looking for.\n" if $debug;
+       next;
+       }
+ 
      my $mesg = $ldap->{net_ldap_mesg}->{$mid} or
        return LDAP_PROTOCOL_ERROR;



....  I thought pretty long and hard before deciding to suggest that you make
this addition, because I see your fatal exception to "You answered a different
question than I asked" as one reasonable interpretation of the RFC.  However,
I decided to submit the patch anyway, following the theory of being generous
in what you accept, and rigid in what you emit.  I think the OpenLDAP server
is not being a great neighbor by tossing whatever answer it has close to hand
in this case, but I do not think they actually violate the spec; After all,
it's reasonable for them to presume that "That's why we've got message IDs in
all the communications; the client should be aware of it".  Rude, but
reasonable.

So, I respectfully submit this patch as making Net::LDAP more flexible without
damaging its' utility.

Thanks for your consideration.


- Allen S. Rout





Failed session example (yes, I've since changed my password. :) -- 

[asr@rah perl]$ ./getattrauth.pl 
Net::LDAP=HASH(0x80e4a44) sending:

30 3E 02 01 01 60 39 02 01 02 04 25 63 6E 3D 61 0>...`9....%cn=a
73 72 2C 20 6F 3D 55 6E 69 76 65 72 73 69 74 79 sr, o=University
20 6F 66 20 46 6C 6F 72 69 64 61 2C 20 63 3D 55  of Florida, c=U
53 80 0D 50 6F 64 64 79 54 72 61 69 6E 69 6E 67 S..PoddyTraining

0000 30   62: SEQUENCE {
0002 02    1:   INTEGER = 1
0005 60   57:   [APPLICATION 0] {
0007 02    1:     INTEGER = 2
000A 04   37:     STRING = 'cn=asr, o=University of Florida, c=US'
0031 80   13:     [CONTEXT 0]
0033        :       50 6F 64 64 79 54 72 61 69 6E 69 6E 67 __ __ __ PoddyTraining
0040        :   }
0040        : }
Net::LDAP=HASH(0x80e4a44) received:

30 0C 02 01 01 61 07 0A 01 00 04 00 04 00 __ __ 0....a........

0000 30   12: SEQUENCE {
0002 02    1:   INTEGER = 1
0005 61    7:   [APPLICATION 1] {
0007 0A    1:     ENUM = 0
000A 04    0:     STRING = ''
000C 04    0:     STRING = ''
000E        :   }
000E        : }
Net::LDAP=HASH(0x80e4a44) sending:

30 40 02 01 02 63 3B 04 1D 6F 3D 55 6E 69 76 65 0@...c;..o=Unive
72 73 69 74 79 20 6F 66 20 46 6C 6F 72 69 64 61 rsity of Florida
2C 20 63 3D 55 53 0A 01 02 0A 01 02 02 01 00 02 , c=US..........
01 00 01 01 00 A3 09 04 02 63 6E 04 03 61 73 72 .........cn..asr
30 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ 0.

0000 30   64: SEQUENCE {
0002 02    1:   INTEGER = 2
0005 63   59:   [APPLICATION 3] {
0007 04   29:     STRING = 'o=University of Florida, c=US'
0026 0A    1:     ENUM = 2
0029 0A    1:     ENUM = 2
002C 02    1:     INTEGER = 0
002F 02    1:     INTEGER = 0
0032 01    1:     BOOLEAN = FALSE
0035 A3    9:     [CONTEXT 3] {
0037 04    2:       STRING = 'cn'
003B 04    3:       STRING = 'asr'
0040        :     }
0040 30    0:     SEQUENCE {
0042        :     }
0042        :   }
0042        : }
Net::LDAP=HASH(0x80e4a44) received:

30 0C 02 01 01 61 07 0A 01 00 04 00 04 00 __ __ 0....a........

0000 30   12: SEQUENCE {
0002 02    1:   INTEGER = 1
0005 61    7:   [APPLICATION 1] {
0007 0A    1:     ENUM = 0
000A 04    0:     STRING = ''
000C 04    0:     STRING = ''
000E        :   }
000E        : }
Protocol error at ./getattrauth.pl line 31.
[asr@rah perl]$ 

End Failed session example -- 


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

Perl Sciipts for LDAP

[Ausaf A. <au...@ya...>]

Hello!
Basically we are an ISP in Paksitan. We are using the
LDAP of Netscape with Steel Belted Radius. What we are
looking for is that are Radius get the Caller Line
Identification(CLI) but doesnot passed to the LDAP. Is
there any scripts in perl so that LDAP can pass
through are CLI for option for authentication.
Thanks 
Ausaf


__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

Re: uid's associated with a particular orgranizational unit

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

Yes and no.

Educause (it's a consortium of educational IT professionals) have developed a
Eduperson schema at
http://www.educause.edu/eduperson/
It's now in draft 1.0 stage (don't know much beyond that since I'm not a member).

At UNT I'm using Netscape dynamic groups for class rosters (owners are instructors),
plus I keep the DN to these groups in the student's entries so that I can easily see
what classes they're enrolled in when I retrieve their entry (I put the registrar's
course ID as the RDN for the course).

Mark


Jim Harle wrote:

> Is there a standard attribute for course enrollment.  I want to start
> populating that in our directory soon.
>   --Jim Harle
>
> On Thu, 14 Dec 2000, Mark Wilcox wrote:
>   ...
> > 3 -- I use dynamic groups to maintain course rosters (because they change a lot
> > and some of them are quite large -- several hundred, it makes maintainence
> > easier because the membership changes when we update the student's entry)

Re: uid's associated with a particular orgranizational unit

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

Is there a standard attribute for course enrollment.  I want to start
populating that in our directory soon.
  --Jim Harle

On Thu, 14 Dec 2000, Mark Wilcox wrote:
  ...
> 3 -- I use dynamic groups to maintain course rosters (because they change a lot
> and some of them are quite large -- several hundred, it makes maintainence
> easier because the membership changes when we update the student's entry)

Re: uid's associated with a particular orgranizational unit

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

Mark Wilcox <mew...@un...> wrote:
> I think the problem is that you're trying to treat LDAP as an RDBMS.
> 
> An OrganizationalUnit can be an entry (ie an entry of objectclass type
> OrganizationalUnit) and an attribute (the ou attribute, available in the
> person objectclass).

Actually ou is not an attribute of the person object class, it is an
attribute of the organizationalPerson object class.

Cheers,

Chris