perl-ldap-dev

Re: LDAP server connection question

[<rg...@di...>]

Some of the gurus (Graham, Chris, etc.) may have a slicker way of doing this,
than what I do, but my method works well for me in doing web pages where
I desire fast responses (if possible).

What I do is:

  use an array of hosts to do the 'init' against, keeping my returned objects
  in a hash.  Hosts that can't answer the init get skipped... i.e. they don't
  get put into the hash.

  the bind operation works on the hash, and unsuccessful binds, get removed
  from the hash and the old ldap object get removed.

  queries are then put against 1 or more of the ldap objects in the hash,
   depending on what I want to do.  When checking for DSA busy, I usually have
   a piece of 'delay/retry' code that gets around this, as DSA busy is not
   considered fatal until you continue to fail consistently.
   (well I don't consider it fatal :)


  I've found that doing it this way, gives me greater options and flexibility.
  example, I could use it to make modifications of the same object on two
  different LDAP servers.  Although this is not my current use for it.

  My methodology also includes some fore thought on the servers in my array...
  I use the closest(physically) server and work my way back to the 'master'.


Again, this may not work for you, but it's worked well enough for me that I
wrote a module to handle the work and include it into all my web code.




-- 

	
Russell Biggs	(Rusty)		Internet: r-...@ti...
6500 Chase Oaks Blvd, M/S 8412
Texas Instruments
Plano Tx	75023	

	Phone:  (972) 575-0826
	Fax:	(972) 575-4853
	Home Page: http://dirtest3.itg.ti.com/~rgb
	Calendar:  http://dirtest3.itg.ti.com/cgi-bin/synchronize.cgi?name=Russell+Biggs

	"I sense much NT in you... 
	 NT leads to bluescreen... 
	 Bluescreen leads to downtime...
	 Downtime leads to suffering... 
	 NT is the path to the darkside..."
			...Unknown UNIX Jedi 

LDAP server connection question

[<CZa...@wi...>]

Hello all,  I like to know is there a way using the Net::LDAP module within
a perl/cgi script to connect to an alternate LDAP server if the primary is
either down, not available, or busy?

Thanks

Re: set-password extended operation encoding error

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

Darryl C Price <da...@co...> wrote:
> I Think I figured out the problem.  The ldap implementation under test
> returns  an error if the userIdentity or old password fields are present
> in the  request.  This sort of sucks.  If I only pass the newpass to the
> encode method  (for passwordModReq) It works (i.e. changes the password)
> but I get a BER  decoding error and the script hangs with an unexpected
> PDU:

I've run the ldappasswd program from OpenLDAP 2.0.22 against a server using
the '-s secret' mode (which just sets newpasswd), and I've run a perl-ldap
script using the correct ASN.1 with just a newpasswd, and the protocol I
can see using a packet sniffer (ethereal) is *identical*.

The server I tested against doesn't support this extended operation, so in
both cases the operation failed, but my point is that the perl script is
sending the same bytes as the ldappasswd program. If one works, so must the
other :-)

The "Unexpected" PDU

0000   62: SEQUENCE {
0006    1:   INTEGER = 0
0009   53:   [APPLICATION 24] {
000F    1:     ENUM = 0
0012    0:     STRING = ''
0014   20:     STRING = 'BER decoding problem'
002A   22:     [CONTEXT 10]
002C     :       31 2E 33 2E 36 2E 31 2E 34 2E 31 2E 31 34 36 36 
1.3.6.1.4.1.1466
003C     :       2E 32 30 30 33 36 __ __ __ __ __ __ __ __ __ __ .20036
0042    0:     [CONTEXT 11]
0044     :   }
0044     : }
Unexpected PDU, ignored

is the server sending a standard disconnection notification (RFC 2251
4.4.1), ie "pulling the plug" on the client because it sent it bad
protocol. Bad client, no biscuit. Net::LDAP should probably handle these
notifications in some graceful way. I would expect that calling a
client-provided callback would be useful here.

Cheers,

Chris

Re: set-password extended operation encoding error

[Darryl C P. <da...@co...>]

I Think I figured out the problem.  The ldap implementation under test returns 
an error if the userIdentity or old password fields are present in the 
request.  This sort of sucks.  If I only pass the newpass to the encode method 
(for passwordModReq) It works (i.e. changes the password) but I get a BER 
decoding error and the script hangs with an unexpected PDU:

30 56 02 01 01 60 51 02 01 03 04 42 63 6E 3D 50 0V...`Q....Bcn=P
61 75 6C 20 43 65 7A 61 6E 6E 65 2C 20 64 63 3D aul Cezanne, dc=
43 6C 69 65 6E 74 31 2C 20 64 63 3D 56 65 6E 64 Client1, dc=Vend
6F 72 31 2C 20 64 63 3D 4D 6F 64 69 66 79 2C 20 or1, dc=Modify, 
64 63 3D 49 4D 43 2C 20 64 63 3D 6F 72 67 80 08 dc=IMC, dc=org..
50 61 75 6C 30 30 30 35 __ __ __ __ __ __ __ __ Paul0005

0000   86: SEQUENCE {
0002    1:   INTEGER = 1
0005   81:   [APPLICATION 0] {
0007    1:     INTEGER = 3
000A   66:     STRING = 'cn=Paul Cezanne, dc=Client1, dc=Vendor1, dc=Modify, 
dc=IMC, dc=org'
004E    8:     [CONTEXT 0]
0050     :       50 61 75 6C 30 30 30 35 __ __ __ __ __ __ __ __ Paul0005
0058     :   }
0058     : }
Net::LDAP=HASH(0x82e89f8) received:

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

0000   16: SEQUENCE {
0006    1:   INTEGER = 1
0009    7:   [APPLICATION 1] {
000F    1:     ENUM = 0
0012    0:     STRING = ''
0014    0:     STRING = ''
0016     :   }
0016     : }
Net::LDAP=HASH(0x82e89f8) sending:

30 2D 02 01 02 77 28 80 17 31 2E 33 2E 36 2E 31 0-...w(..1.3.6.1
2E 34 2E 31 2E 34 32 30 33 2E 31 2E 31 31 2E 31 .4.1.4203.1.11.1
81 0D 30 0B 83 09 53 65 63 72 65 74 6D 64 35 __ ..0...Secretmd5

0000   45: SEQUENCE {
0002    1:   INTEGER = 2
0005   40:   [APPLICATION 23] {
0007   23:     [CONTEXT 0]
0009     :       31 2E 33 2E 36 2E 31 2E 34 2E 31 2E 34 32 30 33 
1.3.6.1.4.1.4203
0019     :       2E 31 2E 31 31 2E 31 __ __ __ __ __ __ __ __ __ .1.11.1
0020   13:     [CONTEXT 1]
0022     :       30 0B 83 09 53 65 63 72 65 74 6D 64 35 __ __ __ 0...Secretmd5
002F     :   }
002F     : }
Net::LDAP=HASH(0x82e89f8) received:

30 84 00 00 00 3E 02 01 00 78 84 00 00 00 35 0A 0....>...x....5.
01 00 04 00 04 14 42 45 52 20 64 65 63 6F 64 69 ......BER decodi
6E 67 20 70 72 6F 62 6C 65 6D 8A 16 31 2E 33 2E ng problem..1.3.
36 2E 31 2E 34 2E 31 2E 31 34 36 36 2E 32 30 30 6.1.4.1.1466.200
33 36 8B 00 __ __ __ __ __ __ __ __ __ __ __ __ 36..

0000   62: SEQUENCE {
0006    1:   INTEGER = 0
0009   53:   [APPLICATION 24] {
000F    1:     ENUM = 0
0012    0:     STRING = ''
0014   20:     STRING = 'BER decoding problem'
002A   22:     [CONTEXT 10]
002C     :       31 2E 33 2E 36 2E 31 2E 34 2E 31 2E 31 34 36 36 
1.3.6.1.4.1.1466
003C     :       2E 32 30 30 33 36 __ __ __ __ __ __ __ __ __ __ .20036
0042    0:     [CONTEXT 11]
0044     :   }
0044     : }
Unexpected PDU, ignored



---- Original message ----
>Date: Tue, 18 Jun 2002 16:18:00 +0100
>From: Graham Barr <gb...@po...>  
>Subject: Re: set-password extended operation encoding error  
>To: Darryl C Price <da...@co...>
>Cc: LDAP Mailing List <per...@li...>
>
>On Tue, Jun 18, 2002 at 10:56:32AM -0400, Darryl C Price wrote:
>> 
>> Here is the hex dump of a ldappasswd request that succeeds:
>> 
>> 30 2c 02 01 02 77 27 80  17 31 2e 33 2e 36 2e 31   0,...w'..1.3.6.1  
>> 2e 34 2e 31 2e 34 32 30  33 2e 31 2e 31 31 2e 31   .4.1.4203.1.11.1  
>> 81 0c 30 0a 82 08 50 61  75 6c 30 30 30 35         ..0...Paul0005 
>> 
>> And here is one that fails from the extension method in Net::LDAP
>> 
>> 30 2D 02 01 02 77 28 80 17 31 2E 33 2E 36 2E 31 0-...w(..1.3.6.1
>> 2E 34 2E 31 2E 34 32 30 33 2E 31 2E 31 31 2E 31 .4.1.4203.1.11.1
>> 81 0D 30 0B 81 09 53 65 63 72 65 74 6D 64 35 __ ..0...Secretmd5
>> 
>> This does look like an encoding error to me.
>
>You have used a different password in each case. In ldappasswd
>it has Paul0005 but in Net::LDAP it has Secretmd5
>
>Graham.
>
Darryl C Price
Conversant Systems, LLC
Email:  da...@co...
Phone:  (513)768-3120
Mobile: (513)225-8528
Web:    http://www.convsys.com

Re: set-password extended operation encoding error

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

Graham Barr <gb...@po...> wrote:
> On Tue, Jun 18, 2002 at 10:56:32AM -0400, Darryl C Price wrote:
>> 
>> Here is the hex dump of a ldappasswd request that succeeds:
>> 
>> 30 2c 02 01 02 77 27 80  17 31 2e 33 2e 36 2e 31   0,...w'..1.3.6.1  
>> 2e 34 2e 31 2e 34 32 30  33 2e 31 2e 31 31 2e 31   .4.1.4203.1.11.1  
>> 81 0c 30 0a 82 08 50 61  75 6c 30 30 30 35         ..0...Paul0005 
>> 
>> And here is one that fails from the extension method in Net::LDAP
>> 
>> 30 2D 02 01 02 77 28 80 17 31 2E 33 2E 36 2E 31 0-...w(..1.3.6.1
>> 2E 34 2E 31 2E 34 32 30 33 2E 31 2E 31 31 2E 31 .4.1.4203.1.11.1
>> 81 0D 30 0B 81 09 53 65 63 72 65 74 6D 64 35 __ ..0...Secretmd5
>> 
>> This does look like an encoding error to me.
> 
> You have used a different password in each case. In ldappasswd
> it has Paul0005 but in Net::LDAP it has Secretmd5

More than that: if you decode the PasswdModifyRequestValue in both you'll
spot that the first example (that succeeds) only sets the newPasswd field,
and the second example (that doesn't) only sets the oldPasswd field.

Cheers,

Chris

Re: set-password extended operation error

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

On Tue, Jun 18, 2002 at 03:56:14AM -0400, Darryl C Price wrote:

I think the problem is in your encoding that you are sending

>    $passwdModReq = Convert::ASN1->new;
>    $passwdModReq->prepare(q<SEQUENCE {
>                        userIdentity [1] STRING OPTIONAL,
>                        newPasswd    [2] STRING OPTIONAL

userIdentity should be [0], RFC 30962 shows

   PasswdModifyRequestValue ::= SEQUENCE {
     userIdentity    [0]  OCTET STRING OPTIONAL
     oldPasswd       [1]  OCTET STRING OPTIONAL
     newPasswd       [2]  OCTET STRING OPTIONAL }


Graham.

Re: set-password extended operation encoding error

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

On Tue, Jun 18, 2002 at 10:56:32AM -0400, Darryl C Price wrote:
> 
> Here is the hex dump of a ldappasswd request that succeeds:
> 
> 30 2c 02 01 02 77 27 80  17 31 2e 33 2e 36 2e 31   0,...w'..1.3.6.1  
> 2e 34 2e 31 2e 34 32 30  33 2e 31 2e 31 31 2e 31   .4.1.4203.1.11.1  
> 81 0c 30 0a 82 08 50 61  75 6c 30 30 30 35         ..0...Paul0005 
> 
> And here is one that fails from the extension method in Net::LDAP
> 
> 30 2D 02 01 02 77 28 80 17 31 2E 33 2E 36 2E 31 0-...w(..1.3.6.1
> 2E 34 2E 31 2E 34 32 30 33 2E 31 2E 31 31 2E 31 .4.1.4203.1.11.1
> 81 0D 30 0B 81 09 53 65 63 72 65 74 6D 64 35 __ ..0...Secretmd5
> 
> This does look like an encoding error to me.

You have used a different password in each case. In ldappasswd
it has Paul0005 but in Net::LDAP it has Secretmd5

Graham.

set-password extended operation encoding error

[Darryl C P. <da...@co...>]

I Stripped the ldap portion of the script to make the extended 
request look like the one ldappasswd.c (from the OpenLDAP distribution)
is sending so it's now just:

   $mesg = $ld->bind($LDAP_ENTRYDN, password => $OLD_PASSWORD);
   if ($mesg->code)
   {
      print STDERR "UNDEF ............ $prgname (Bind failed. ",$mesg->error,")
\n";
      admind_close();
      exit;
   }

   $passwdModReq = Convert::ASN1->new;
   $passwdModReq->prepare(q<SEQUENCE {
                       newPasswd    [1] STRING OPTIONAL
                       }>);

   $passwdModRes = Convert::ASN1->new;
   $passwdModRes->prepare(q<SEQUENCE {
                       genPasswd    [0] STRING OPTIONAL
                       }>);

   # Now construct the arguments
   $val = $passwdModReq->encode( newPasswd => 'Secretmd5' );

   # Now send the operation
   $res = $ld->extension(name => '1.3.6.1.4.1.4203.1.11.1', value => $val);
   


Here is the hex dump of a ldappasswd request that succeeds:

30 2c 02 01 02 77 27 80  17 31 2e 33 2e 36 2e 31   0,...w'..1.3.6.1  
2e 34 2e 31 2e 34 32 30  33 2e 31 2e 31 31 2e 31   .4.1.4203.1.11.1  
81 0c 30 0a 82 08 50 61  75 6c 30 30 30 35         ..0...Paul0005 

And here is one that fails from the extension method in Net::LDAP

30 2D 02 01 02 77 28 80 17 31 2E 33 2E 36 2E 31 0-...w(..1.3.6.1
2E 34 2E 31 2E 34 32 30 33 2E 31 2E 31 31 2E 31 .4.1.4203.1.11.1
81 0D 30 0B 81 09 53 65 63 72 65 74 6D 64 35 __ ..0...Secretmd5

This does look like an encoding error to me.


--Darryl
Darryl C Price
Conversant Systems, LLC
Email:  da...@co...
Phone:  (513)768-3120
Mobile: (513)225-8528
Web:    http://www.convsys.com

set-password extended operation

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

At the request of some, and based on code posted by Chris I have created
a set-password extended operation package.

I have not used this operation, and thus have not tested the code so
I would appriciate others testing it.

It is used like


use Net::LDAP::Extension::SetPassword;



$mesg = $ldap->set_password(
  user => $user,
  oldpasswd => $old,
  newpasswd => $nwe
);

$gen = $mesg->gen_password;

If this works, and someone who knows about this extension writes a simple POD
I will include it in the next release.

Graham.

Re: set-password extended operation error

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

Darryl C Price <da...@co...> wrote:
> I have a script that I'm running to test support for the set-password
> extended  operation.  Funny thing is that OpenLDAP always seems to return
> an error and  I'm beginning to think the encoding is incorrect.  When I
> look at the hex  encoded (identical) request from the ldappassword tool
> that comes with  openldap it looks like:
> 
> 30 56 02 01 01 60 51 02  01 03 04 42 63 6e 3d 50   0V...`Q....Bcn=P  
> 61 75 6c 20 43 65 7a 61  6e 6e 65 2c 20 64 63 3d   aul Cezanne, dc=  
> 43 6c 69 65 6e 74 31 2c  20 64 63 3d 56 65 6e 64   Client1, dc=Vend  
> 6f 72 31 2c 20 64 63 3d  4d 6f 64 69 66 79 2c 20   or1, dc=Modify,   
> 64 63 3d 49 4d 43 2c 20  64 63 3d 6f 72 67 80 08   dc=IMC, dc=org..  
> 50 61 75 6c 30 30 30 35                            Paul0005     
> 
> 
> But when I look at the message sent by the extension method I see:
> 
> 30 56 02 01 01 60 51 02 01 03 04 42 63 6E 3D 50 0V...`Q....Bcn=P
> 61 75 6C 20 43 65 7A 61 6E 6E 65 2C 20 64 63 3D aul Cezanne, dc=
> 43 6C 69 65 6E 74 31 2C 20 64 63 3D 56 65 6E 64 Client1, dc=Vend
> 6F 72 31 2C 20 64 63 3D 4D 6F 64 69 66 79 2C 20 or1, dc=Modify, 
> 64 63 3D 49 4D 43 2C 20 64 63 3D 6F 72 67 80 08 dc=IMC, dc=org..
> 50 61 75 6C 30 30 30 35 __ __ __ __ __ __ __ __ Paul0005
> 
> Looks like 8 extra bytes of pad data that got slipped in here somehow.

The underscore characters are just there to pad out Convert::ASN1's
display, ie they aren't sent across the wire.

Given that, I can't see any differences between what ldappassword's sending
and what your script's sending...

> Am I  doing something wrong? Is there any way of avoiding this?
> ldappasswd always  succeeds, by the way.  I've attached the script ...
> ignore the sock stuff, it's  just configuration commands for mirapoint's
> administration protocol.

If you look at a complete transcript of the packets sent by the
ldappassword program, and your script, can you spot any obvious
differences? Like what other operations is ldappassword doing before using
this extension?

> 
> ===Darryl
> 
> Darryl C Price
> Conversant Systems, LLC
> Email:  da...@co...
> Phone:  (513)768-3120
> Mobile: (513)225-8528
> Web:    http://www.convsys.com



Cheers,

Chris

set-password extended operation error

[Darryl C P. <da...@co...>]

I have a script that I'm running to test support for the set-password extended 
operation.  Funny thing is that OpenLDAP always seems to return an error and 
I'm beginning to think the encoding is incorrect.  When I look at the hex 
encoded (identical) request from the ldappassword tool  that comes with 
openldap it looks like:

30 56 02 01 01 60 51 02  01 03 04 42 63 6e 3d 50   0V...`Q....Bcn=P  
61 75 6c 20 43 65 7a 61  6e 6e 65 2c 20 64 63 3d   aul Cezanne, dc=  
43 6c 69 65 6e 74 31 2c  20 64 63 3d 56 65 6e 64   Client1, dc=Vend  
6f 72 31 2c 20 64 63 3d  4d 6f 64 69 66 79 2c 20   or1, dc=Modify,   
64 63 3d 49 4d 43 2c 20  64 63 3d 6f 72 67 80 08   dc=IMC, dc=org..  
50 61 75 6c 30 30 30 35                            Paul0005     


But when I look at the message sent by the extension method I see:

30 56 02 01 01 60 51 02 01 03 04 42 63 6E 3D 50 0V...`Q....Bcn=P
61 75 6C 20 43 65 7A 61 6E 6E 65 2C 20 64 63 3D aul Cezanne, dc=
43 6C 69 65 6E 74 31 2C 20 64 63 3D 56 65 6E 64 Client1, dc=Vend
6F 72 31 2C 20 64 63 3D 4D 6F 64 69 66 79 2C 20 or1, dc=Modify, 
64 63 3D 49 4D 43 2C 20 64 63 3D 6F 72 67 80 08 dc=IMC, dc=org..
50 61 75 6C 30 30 30 35 __ __ __ __ __ __ __ __ Paul0005

Looks like 8 extra bytes of pad data that got slipped in here somehow.  Am I 
doing something wrong? Is there any way of avoiding this?  ldappasswd always 
succeeds, by the way.  I've attached the script ... ignore the sock stuff, it's 
just configuration commands for mirapoint's administration protocol.


===Darryl

Darryl C Price
Conversant Systems, LLC
Email:  da...@co...
Phone:  (513)768-3120
Mobile: (513)225-8528
Web:    http://www.convsys.com

Return value of $ldap->extension(name,value);

[Murugan K G <mur...@ya...>]

Hi
    What is the return value of  $ldap->extension
function. I closely looked in to the  extension
function in LDAP.PM version 0.25. But i found the
following . Am i using the correct version. I am
confused.
   If i use like this , it is giving the following
error
    $mesg = $ldap->extension( name => $oid, value =>
    $value);
     $mesg->response_name gives undefined value error.

   But the same time 
     $mesg=$ldap->_sendmesg($mesg);# with proper
encoding  including oid and value 
    $mesg->response_name  gives the correct
response_name . 
   Which usage is correct . 
   

###### code copied form LDAP.PM #########
# which is sending message . Is it returning any value
###################################
   
sub extension {
  my $ldap = shift;
  my $arg  = &_options;

  require Net::LDAP::Extension;
  my $mesg = $ldap->message('Net::LDAP::Extension' =>
$arg);

  return _error($ldap, $mesg, LDAP_LOCAL_ERROR,
"ExtendedRequest requires LDAPv3")
    if $ldap->{net_ldap_version} < 3;

  $mesg->encode(
    extendedRequest => {
      requestName  => $arg->{name},
      requestValue => $arg->{value}
    },
    controls => $arg->{control}
  ) or return _error($ldap, $mesg,
LDAP_ENCODING_ERROR,"$@");

  $ldap->_sendmesg($mesg);
}

Regards
K.Murugan



--- Graham Barr <gb...@po...> wrote:
> Currently Net::LDAP only gives a skeleton access to
> the extended operation.
> 
> You must encode the value yourself and pass in with
> 
>   $mesg = $ldap->extension( name => $oid, value =>
> $value);
> 
> Then you can call
> 
>   $mesg->response_name
>   $mesg->response
> 
> to get the names and value of the response.
> 
> The intent is that as "standard" extensions get
> defined we would define
> classes for them so that you could do
> 
>   $mesg = $ldap->extension( type => 'set-password',
> ... args for set password );
> 
> And the class of the object returned will be a
> sub-class of Net::LDAP::Extension
> with methods that are of use to 'set-password'. We
> could even go as far as
> 
>   use Net::LDAP::Extension qw(set_password);
> 
>   $mesg = $ldap->set_password( ... );
> 
> Graham.
> 
> On Fri, Jun 14, 2002 at 03:17:27PM +0100, Graham
> Barr wrote:
> > ----- Forwarded message from Darryl C Price
> <da...@co...> -----
> > 
> > Date: Fri, 14 Jun 2002 10:13:12 -0400
> > To: gb...@po...
> > From: Darryl C Price <da...@co...>
> > Subject: Documentation for Net::LDAP::Extension
> > 
> > Hello Graham,
> > 
> > I am trying to figure out how to use the
> set-password ldapv3 extension but 
> > can't find the documentation for
> Net::LDAP::Extension or any examples.  Your 
> > help would be greatly appreciated.
> > 
> > --Darryl
> > Darryl C Price
> > Conversant Systems, LLC
> > Email:  da...@co...
> > Phone:  (513)768-3120
> > Mobile: (513)225-8528
> > Web:    http://www.convsys.com
> > 
> > ----- End forwarded message -----
> 
>
_______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application
> Developer's Conference
> August 25-28 in Las Vegas -
>
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
> 


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Set-password extension example

[Darryl C P. <da...@co...>]

Does anyone have a working example of a script that uses the set-password 
extension 1.3.6.1.4.1.4203.1.11.1?

--Darryl
Darryl C Price
Conversant Systems, LLC
Email:  da...@co...
Phone:  (513)768-3120
Mobile: (513)225-8528
Web:    http://www.convsys.com

Re: [Fwd] Documentation for Net::LDAP::Extension

[Darryl C P. <da...@co...>]

Does anyone have a practical example of how this is ued? 

---- Original message ----
>Date: Fri, 14 Jun 2002 15:28:34 +0100
>From: Graham Barr <gb...@po...>  
>Subject: Re: [Fwd] Documentation for Net::LDAP::Extension  
>To: LDAP Mailing List <per...@li...>, Darryl C Price 
<da...@co...>
>
>Currently Net::LDAP only gives a skeleton access to the extended operation.
>
>You must encode the value yourself and pass in with
>
>  $mesg = $ldap->extension( name => $oid, value => $value);
>
>Then you can call
>
>  $mesg->response_name
>  $mesg->response
>
>to get the names and value of the response.
>
>The intent is that as "standard" extensions get defined we would define
>classes for them so that you could do
>
>  $mesg = $ldap->extension( type => 'set-password', ... args for set 
password );
>
>And the class of the object returned will be a sub-class of 
Net::LDAP::Extension
>with methods that are of use to 'set-password'. We could even go as far as
>
>  use Net::LDAP::Extension qw(set_password);
>
>  $mesg = $ldap->set_password( ... );
>
>Graham.
>
>On Fri, Jun 14, 2002 at 03:17:27PM +0100, Graham Barr wrote:
>> ----- Forwarded message from Darryl C Price <da...@co...> -----
>> 
>> Date: Fri, 14 Jun 2002 10:13:12 -0400
>> To: gb...@po...
>> From: Darryl C Price <da...@co...>
>> Subject: Documentation for Net::LDAP::Extension
>> 
>> Hello Graham,
>> 
>> I am trying to figure out how to use the set-password ldapv3 extension but 
>> can't find the documentation for Net::LDAP::Extension or any examples.  
Your 
>> help would be greatly appreciated.
>> 
Darryl C Price
Conversant Systems, LLC
Email:  da...@co...
Phone:  (513)768-3120
Mobile: (513)225-8528
Web:    http://www.convsys.com

Re: [Fwd] Documentation for Net::LDAP::Extension

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

On 14/6/02 3:17 pm, Graham Barr <gb...@po...> wrote:

> ----- Forwarded message from Darryl C Price <da...@co...> -----
> 
> Date: Fri, 14 Jun 2002 10:13:12 -0400
> To: gb...@po...
> From: Darryl C Price <da...@co...>
> Subject: Documentation for Net::LDAP::Extension
> 
> Hello Graham,
> 
> I am trying to figure out how to use the set-password ldapv3 extension but
> can't find the documentation for Net::LDAP::Extension or any examples.  Your
> help would be greatly appreciated.
> 
> --Darryl
> Darryl C Price
> Conversant Systems, LLC
> Email:  da...@co...
> Phone:  (513)768-3120
> Mobile: (513)225-8528
> Web:    http://www.convsys.com

Funnily enough, a similar question just came up this last week. This
extension is documented in RFC 3062; I've taken the ASN.1 from there.

use Convert::ASN1;
my $passwdModReq = Convert::ASN1->new;
$passwdModReq->prepare(q<SEQUENCE {
                       userIdentity [1] STRING OPTIONAL,
                       oldPasswd    [2] STRING OPTIONAL,
                       newPasswd    [3] STRING OPTIONAL
                       }>);
my $passwdModRes = Convert::ASN1->new;
$passwdModRes->prepare(q<SEQUENCE {
                       genPasswd    [0] STRING OPTIONAL
                       }>);
# Now construct the arguments
my $val = $passwdModReq->encode(userIdentity => 'foo',
                                oldPasswd => 'old',
                                newPasswd => 'new')
# Now send the operation
my $res = $ldap->extension(name => '1.3.6.1.4.1.4203.1.11.1',
                           value => $val);
# Now wait for the result
my $name = $res->response_name;
my $out = $passwdModRes->decode($res->response);
# Now look at $out->{genPasswd}

Cheers,

Chris

Re: [Fwd] Documentation for Net::LDAP::Extension

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

Currently Net::LDAP only gives a skeleton access to the extended operation.

You must encode the value yourself and pass in with

  $mesg = $ldap->extension( name => $oid, value => $value);

Then you can call

  $mesg->response_name
  $mesg->response

to get the names and value of the response.

The intent is that as "standard" extensions get defined we would define
classes for them so that you could do

  $mesg = $ldap->extension( type => 'set-password', ... args for set password );

And the class of the object returned will be a sub-class of Net::LDAP::Extension
with methods that are of use to 'set-password'. We could even go as far as

  use Net::LDAP::Extension qw(set_password);

  $mesg = $ldap->set_password( ... );

Graham.

On Fri, Jun 14, 2002 at 03:17:27PM +0100, Graham Barr wrote:
> ----- Forwarded message from Darryl C Price <da...@co...> -----
> 
> Date: Fri, 14 Jun 2002 10:13:12 -0400
> To: gb...@po...
> From: Darryl C Price <da...@co...>
> Subject: Documentation for Net::LDAP::Extension
> 
> Hello Graham,
> 
> I am trying to figure out how to use the set-password ldapv3 extension but 
> can't find the documentation for Net::LDAP::Extension or any examples.  Your 
> help would be greatly appreciated.
> 
> --Darryl
> Darryl C Price
> Conversant Systems, LLC
> Email:  da...@co...
> Phone:  (513)768-3120
> Mobile: (513)225-8528
> Web:    http://www.convsys.com
> 
> ----- End forwarded message -----

Re: ldif reading/writing problem

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

On Thu, Jun 13, 2002 at 05:38:52PM +0100, Chris Ridd wrote:
> Right, but as Andrew points out that doesn't work. The code:
> 
> 	$entry->delete('foo', 'bar');
> 
> fails, despite the documentation ;-) I'm not sure what people really want
> to do with this method (as I mentioned I've not really used it before) so
> this may really be a documentation bug. How about this instead:
> 
> 	delete ( ATTR [ => VALUE [, ATTR2 => VALUE2 ... ] )
> 
> 		Delete one or more attributes from the entry. Each value must either be a
> scalar variable or a reference to an array (an empty array means delete all
> the values). As a special case to delete a single attribute completely,
> just pass the name of the attribute. The following two examples are
> equivalent:
> 
> 		$entry->delete( 'mail' );
> 		$entry->delete( 'mail' => [ ] );

The reason the first works is because undef passed as the value is
treated the same as [] being passed.

Doc patch welcome.

Graham.

[Fwd] Documentation for Net::LDAP::Extension

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

----- Forwarded message from Darryl C Price <da...@co...> -----

Date: Fri, 14 Jun 2002 10:13:12 -0400
To: gb...@po...
From: Darryl C Price <da...@co...>
Subject: Documentation for Net::LDAP::Extension

Hello Graham,

I am trying to figure out how to use the set-password ldapv3 extension but 
can't find the documentation for Net::LDAP::Extension or any examples.  Your 
help would be greatly appreciated.

--Darryl
Darryl C Price
Conversant Systems, LLC
Email:  da...@co...
Phone:  (513)768-3120
Mobile: (513)225-8528
Web:    http://www.convsys.com

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

Re: ldif reading/writing problem

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

Graham Barr <gb...@po...> wrote:
> On Thu, Jun 13, 2002 at 05:01:33PM +0100, Chris Ridd wrote:
>> > Am I missing a typo there somewhere?  The next thing I thought was, "oh
>> > yeah, I should be passing a reference to that list"; this is what the
>> > perl-ldap docs suggest (the documentation for the delete method says
>> > 'delete ( [ ATTR [, ATTR2 ... ]] )'), is that incorrect, or am I
>> > misunderstanding something?  So I tried passing a reference to that
>> > anonymous array, like so,
>> 
>> Yes, that's confusing. Do the outer square brackets indicate optional
>> parameters, or literally square brackets?
> 
> Optional parameters. But if someone wants to provide a patch to make
> things more clear .....
> 
> Graham.
> 

Right, but as Andrew points out that doesn't work. The code:

	$entry->delete('foo', 'bar');

fails, despite the documentation ;-) I'm not sure what people really want
to do with this method (as I mentioned I've not really used it before) so
this may really be a documentation bug. How about this instead:

	delete ( ATTR [ => VALUE [, ATTR2 => VALUE2 ... ] )

		Delete one or more attributes from the entry. Each value must either be a
scalar variable or a reference to an array (an empty array means delete all
the values). As a special case to delete a single attribute completely,
just pass the name of the attribute. The following two examples are
equivalent:

		$entry->delete( 'mail' );
		$entry->delete( 'mail' => [ ] );

Cheers,

Chris

Re: ldif reading/writing problem

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

On Thu, Jun 13, 2002 at 05:01:33PM +0100, Chris Ridd wrote:
> > Am I missing a typo there somewhere?  The next thing I thought was, "oh
> > yeah, I should be passing a reference to that list"; this is what the
> > perl-ldap docs suggest (the documentation for the delete method says
> > 'delete ( [ ATTR [, ATTR2 ... ]] )'), is that incorrect, or am I
> > misunderstanding something?  So I tried passing a reference to that
> > anonymous array, like so,
> 
> Yes, that's confusing. Do the outer square brackets indicate optional
> parameters, or literally square brackets?

Optional parameters. But if someone wants to provide a patch to make things
more clear .....

Graham.

Re: ldif reading/writing problem

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

Andrew Tristan <atr...@ac...> wrote:
> Whoops, transcription error on my part.  I tried a bunch of different
> things; when I typed that message, I mistakenly combined several
> different things.  I should have just cut/pasted my actual code rather
> than typing it out.  
> 
> One of the things I'm trying to do is to remove openLDAP's time stamp
> attributes.  The first thing I did was,
> 
> $ldifEntry->delete('creatorsname','modifiersname',
> 			'createtimestamp','modifytimestamp');

Well you aren't allowed to do that on a server anyway, since those
attributes are classed as not user modifiable. (This is irrespective of
access controls.)

It'll work using an LDIF file of course.

> which results in,
> 
> Can't use string ("modifiersname") as an ARRAY ref while "strict refs" 
> in use at /inst/pkg-ver/perl-5.6.1/lib/site_perl/Net/LDAP/Entry.pm line
> 179, <GEN0> line 2.
> 
> Am I missing a typo there somewhere?  The next thing I thought was, "oh
> yeah, I should be passing a reference to that list"; this is what the
> perl-ldap docs suggest (the documentation for the delete method says
> 'delete ( [ ATTR [, ATTR2 ... ]] )'), is that incorrect, or am I
> misunderstanding something?  So I tried passing a reference to that
> anonymous array, like so,

Yes, that's confusing. Do the outer square brackets indicate optional
parameters, or literally square brackets?

> $ldifEntry->delete(['creatorsname',...]);
> 
> this runs without error, but also doesn't remove those attributes.  

The guts of the delete method is a loop that takes pairs of things from the
argument list, a type and a value. So try this:

	$ldifEntry->delete('creatorsname' => [],
			   'createtimestamp' => []);

That seems to work for me.

I've never really used Net::LDAP::Entry objects like this myself, so there
may be a much better way to do it.

Cheers,

Chris

Re: ldif reading/writing problem

[Andrew T. <atr...@ac...>]

Whoops, transcription error on my part.  I tried a bunch of different
things; when I typed that message, I mistakenly combined several
different things.  I should have just cut/pasted my actual code rather
than typing it out.  

One of the things I'm trying to do is to remove openLDAP's time stamp
attributes.  The first thing I did was,

$ldifEntry->delete('creatorsname','modifiersname',
			'createtimestamp','modifytimestamp');

which results in,

Can't use string ("modifiersname") as an ARRAY ref while "strict refs" 
in use at /inst/pkg-ver/perl-5.6.1/lib/site_perl/Net/LDAP/Entry.pm line 179,
<GEN0> line 2.

Am I missing a typo there somewhere?  The next thing I thought was, "oh
yeah, I should be passing a reference to that list"; this is what the
perl-ldap docs suggest (the documentation for the delete method says
'delete ( [ ATTR [, ATTR2 ... ]] )'), is that incorrect, or am I
misunderstanding something?  So I tried passing a reference to that
anonymous array, like so,

$ldifEntry->delete(['creatorsname',...]);

this runs without error, but also doesn't remove those attributes.  

For a time, I thought that I needed to do something with update(), but
deleting the attributes individually doesn't require it, so I suppose
that that's not the problem.  Although the task is done (by deleting
individually), I'm still puzzled.

Thanks Chris, I appreciate you taking the time to reply.
Best,
Andrew

-- On Jun 13,  9:07am, Chris Ridd wrote:
> Subject: Re: ldif reading/writing problem
> On 13/6/02 12:13 am, Andrew Tristan <atr...@ac...> wrote:
> 
> > I'm writing some code to take a dump of our LDAP server, perform some
> > modifications, and then write out the result as input to slapadd (I'm
> > actually outputting it to a file at the moment).
> > 
> > So, I read in an ldif entry, perform some modifications, and then write
> > it out to a new ldif file.  The problem is that while,
> >  $ldifEntry->delete([qw(attr1,attr2,attr3)]);
> > does absolutely nothing (not what I expected),
> >  $ldifEntry->delete('attr1');
> >  $ldifEntry->delete('attr2');
> >  $ldifEntry->delete('attr3');
> > results in those attributes being removed from the new ldif entries.
> > Am I doing something wrong?
> 
> Yup, The qw operator (man perlop) splits the contents into separate values
> at whitespace, not commas (ie a single attribute called
> "attr1,attr2,attr3"). You are then passing the results of qw inside an array
> and passing a reference to that array (via the [ ]) as the argument to
> delete. The delete method just takes an array of attributes, not a reference
> to an array.
> 
> This might work better:
> 
> $ldifEntry->delete(qw(attr1 attr2 attr3));
> 
> As might this:
> 
> $ldifEntry->delete('attr1', 'attr2', 'attr3');
> 
> Cheers,
> 
> Chris
-- End of excerpt from Chris Ridd --



-- 
and...@uc...                Unix Systems Group UC, Riverside

Re: ldif reading/writing problem

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

On 13/6/02 12:13 am, Andrew Tristan <atr...@ac...> wrote:

> I'm writing some code to take a dump of our LDAP server, perform some
> modifications, and then write out the result as input to slapadd (I'm
> actually outputting it to a file at the moment).
> 
> So, I read in an ldif entry, perform some modifications, and then write
> it out to a new ldif file.  The problem is that while,
>  $ldifEntry->delete([qw(attr1,attr2,attr3)]);
> does absolutely nothing (not what I expected),
>  $ldifEntry->delete('attr1');
>  $ldifEntry->delete('attr2');
>  $ldifEntry->delete('attr3');
> results in those attributes being removed from the new ldif entries.
> Am I doing something wrong?

Yup, The qw operator (man perlop) splits the contents into separate values
at whitespace, not commas (ie a single attribute called
"attr1,attr2,attr3"). You are then passing the results of qw inside an array
and passing a reference to that array (via the [ ]) as the argument to
delete. The delete method just takes an array of attributes, not a reference
to an array.

This might work better:

$ldifEntry->delete(qw(attr1 attr2 attr3));

As might this:

$ldifEntry->delete('attr1', 'attr2', 'attr3');

Cheers,

Chris

Re: is this error a code issue on my part or a bug with perl-ldap?

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

On 12/6/02 7:48 pm, Kent Perrier <kpe...@ev...> wrote:

> I am attempting to use perl-ldap (both 0.25 and 0.251) to search and display
> the results.  I working with perl 5.005_03 on a Solaris 8 box and perl
> 5.6.1, Activestate build 631 on a Win2K machine.  First, here is my code:
> 
> #!/usr/bin/perl -w
> 
> use Net::LDAP;
> use Net::LDAP::LDIF;
> 
> my $server="idev.dobson.net";
> my $port="18251";
> my
> $binddn="uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot";
> my $passwd="admin";
> my $basedn="o=dobson.net";
> my $scope="sub";
> 
> my $c = Net::LDAP->new($server, port => $port) or
>   die "Unable to connect to $server: $@\n";
> 
> $c->bind ($binddn, password => $passwd) or
>   die "Unable to bind: $@\n";

That is not the right way to detect bind failure or success. The bind method
returns an object that contains the bind results (from the server), and you
need to test the result code held in that object.

You may also want to bind using LDAPv3 instead of LDAPv2.

my $res = $c->bind($binddn, password => $passwd, version => 3);
die "Unable to bind: " . ldap_error_name($res->code) . "\n" if $res->code;

> my $searchobj = $c->search(base => $basedn, scope => $scope,
>                          filter => $ARGV[0]);
> die "Bad search, errorcode #".$searchobj->code() if $searchobj->code( );
> 
> # process the return values from search ( )
> if ($searchobj) {
>   my $ldif =  new Net::LDAP::LDIF("-");
>   $ldif->write($searchobj->entries( ));

New Net::LDAP::LDIF objects are by default opened read-only. (perldoc
Net::LDAP::LDIF). Try:

my $ldif = new Net::LDAP::LDIF "-", "w";

(This is assuming you pass a valid filter to the script, as per your second
email.)

Cheers,

Chris

ldif reading/writing problem

[Andrew T. <atr...@ac...>]

I'm writing some code to take a dump of our LDAP server, perform some
modifications, and then write out the result as input to slapadd (I'm
actually outputting it to a file at the moment).

So, I read in an ldif entry, perform some modifications, and then write
it out to a new ldif file.  The problem is that while,
   $ldifEntry->delete([qw(attr1,attr2,attr3)]);
does absolutely nothing (not what I expected),
   $ldifEntry->delete('attr1');
   $ldifEntry->delete('attr2');
   $ldifEntry->delete('attr3');
results in those attributes being removed from the new ldif entries. 
Am I doing something wrong?
Best,
Andrew


-- 
and...@uc...                Unix Systems Group UC, Riverside