perl-ldap-dev

Re: Convert::ASN1: RSA Public Keys

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

On 24/2/03 10:07 am, Lars Uffmann <la...@kn...> wrote:

> On Mon, Feb 24, 2003 at 07:22:34AM +0000, Chris Ridd wrote:
>> On 23/2/03 9:20 pm, Lars Uffmann <la...@kn...> wrote:
> 
> Hello Chris,
> 
> thanks for your help. The following ASN1 worked:
> 
> AlgorithmIdentifier ::= SEQUENCE {
> algorithm OBJECT IDENTIFIER,
> parameters ANY
> }
> SubjectPublicKeyInfo ::= SEQUENCE  {
> algorithm AlgorithmIdentifier,
> subjectPublicKey BIT STRING
> }
> -- from ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2.asn
> RSAPublicKey ::= SEQUENCE {
>  modulus          INTEGER,  -- (Usually large) n = p*q
>  publicExponent   INTEGER  -- (Usually small) e
> }
> 
> I attached an updated version of my script, this one only decodes the
> publick key in DER, but support for Convert::PEM schould be trivial.

Yes, just pass the SubjectPublicKeyInfo ASN.1 into Convert::PEM. Works great
here!

>> I'd be inclined to try telling Convert::ASN1 that the BIT STRING is actually
>> a [UNIVERSAL 3 IMPLICIT] OCTET STRING so you can get the raw bytes of the
>> bit string out, and then do a second parse using your original ASN.1 on that
>> octet string.
> 
> Actually BIT STRING worked fine.

You're quite right: I'd assumed Convert::ASN1 munged the bit string somehow,
but it doesn't really. It seems to convert into an array - [0] is the bytes
and [1] is the number of used bits.

Cheers,

Chris

Re: Convert::ASN1: RSA Public Keys

[Lars U. <la...@kn...>]

On Mon, Feb 24, 2003 at 07:22:34AM +0000, Chris Ridd wrote:
> On 23/2/03 9:20 pm, Lars Uffmann <la...@kn...> wrote:

Hello Chris,

thanks for your help. The following ASN1 worked:

AlgorithmIdentifier ::= SEQUENCE {
  algorithm OBJECT IDENTIFIER,
  parameters ANY
}
SubjectPublicKeyInfo ::= SEQUENCE  {
  algorithm AlgorithmIdentifier,
  subjectPublicKey BIT STRING
}
-- from ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2.asn
RSAPublicKey ::= SEQUENCE {
   modulus          INTEGER,  -- (Usually large) n = p*q
   publicExponent   INTEGER  -- (Usually small) e
}

I attached an updated version of my script, this one only decodes the
publick key in DER, but support for Convert::PEM schould be trivial.

> I don't think the ASN.1 of the public key looks like that. Using dumpasn1
> (grab from http://www.cs.auckland.ac.nz/~pgut001/) on the public.der file I
> get something like:
> 
>    0   92: SEQUENCE {
>    2   13:   SEQUENCE {
>    4    9:     OBJECT IDENTIFIER '1 2 840 113549 1 1 1'
>   15    0:     NULL
>          :     }
>   17   75:   BIT STRING, encapsulates {
>   20   72:     SEQUENCE {
>   22   65:       INTEGER
>          :         00 B9 79 14 11 64 33 67 A2 2D 8F 7A E0 F4 DD BD
>          :         1E 4E 3F 88 73 19 A5 FD D2 24 17 4F 0C 68 D8 52
>          :         A2 EA BB B5 00 ED 32 1A AF AA C2 B8 A1 97 1D 6D
>          :         99 4E C5 58 80 CE 8D 6A AC 7E 9C 6F D4 B5 49 E4
>          :         71
>   89    3:       INTEGER 65537
>          :       }
>          :     }
>          :   }
> 
> In other words there's some extra wrapper, and your encoded public key SEQ
> is actually inside a BIT STRING.
> 
> I'd be inclined to try telling Convert::ASN1 that the BIT STRING is actually
> a [UNIVERSAL 3 IMPLICIT] OCTET STRING so you can get the raw bytes of the
> bit string out, and then do a second parse using your original ASN.1 on that
> octet string.

Actually BIT STRING worked fine.

> But you can't have too many ASN.1 decoders as far as I'm concerned ;-)

I'll try dumpasn1, seems to be _really_ usefull.

regards,
	Lars

Re: Convert::ASN1: RSA Public Keys

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

On 23/2/03 9:20 pm, Lars Uffmann <la...@kn...> wrote:

> Hello,
> 
> I tried to decode an ASN1 encoded RSA public key using Convert::ASN1 and
> Convert::PEM. The key-pair was generated using openssl. I can decode
> the private key either way, but not the public key:
> 
> Public Key (PEM)
> decode error 30<=>02 at
> /usr/local/share/perl/5.6.1/Convert/ASN1/_decode.pm line 108.
>       ...caught at rsa_pem.pl line 63.
> 0000  111: [APPLICATION 3]
> 0002     :   6E 76 65 72 74 3A 3A 41 53 4E 31 3D 48 41 53 48
> nvert::ASN1=HASH
> 0012     :   28 30 78 31 30 31 62 32 32 31 30 29 __ __ __ __
> (0x101b2210)
> 
> I got the ASN1 from ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2.asn:
> my $rsa_public_key = q<
> RSAPublicKey ::= SEQUENCE {
>  modulus          INTEGER,  -- (Usually large) n = p*q
>  publicExponent   INTEGER  -- (Usually small) e
> }
>> ;
> 
> Attacht is my test script. It uses openssl to generate a key pair, PEM
> and DER encoded. It then tries to ASN-decode the key using either
> Convert::PEM or Convert::ASN1.
> 
> regards,
> Lars

I don't think the ASN.1 of the public key looks like that. Using dumpasn1
(grab from http://www.cs.auckland.ac.nz/~pgut001/) on the public.der file I
get something like:

   0   92: SEQUENCE {
   2   13:   SEQUENCE {
   4    9:     OBJECT IDENTIFIER '1 2 840 113549 1 1 1'
  15    0:     NULL
         :     }
  17   75:   BIT STRING, encapsulates {
  20   72:     SEQUENCE {
  22   65:       INTEGER
         :         00 B9 79 14 11 64 33 67 A2 2D 8F 7A E0 F4 DD BD
         :         1E 4E 3F 88 73 19 A5 FD D2 24 17 4F 0C 68 D8 52
         :         A2 EA BB B5 00 ED 32 1A AF AA C2 B8 A1 97 1D 6D
         :         99 4E C5 58 80 CE 8D 6A AC 7E 9C 6F D4 B5 49 E4
         :         71
  89    3:       INTEGER 65537
         :       }
         :     }
         :   }

In other words there's some extra wrapper, and your encoded public key SEQ
is actually inside a BIT STRING.

I'd be inclined to try telling Convert::ASN1 that the BIT STRING is actually
a [UNIVERSAL 3 IMPLICIT] OCTET STRING so you can get the raw bytes of the
bit string out, and then do a second parse using your original ASN.1 on that
octet string.

You could also try using 'openssl asn1parse' or of course Convert::ASN1's
asn_dump (you need to 'use Convert::ASN1::Debug' first) instead of dumpasn1.
But you can't have too many ASN.1 decoders as far as I'm concerned ;-)

Cheers,

Chris

LDAP.pm patch

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

Graham,

While working with the LDIF.pm and LDAP.pm I discovered 
a problem with LDAP.pm in the subroutine modify when using
an Entry object.  

The variable arg was not pointing to the correct hash 
when checking for changes.

Attached is a patch file that will correct this problem with
a miminum of changes.

Regards,

Clif Harden          ch...@po...

Convert::ASN1: RSA Public Keys

[Lars U. <la...@kn...>]

Hello,

I tried to decode an ASN1 encoded RSA public key using Convert::ASN1 and
Convert::PEM. The key-pair was generated using openssl. I can decode
the private key either way, but not the public key:

Public Key (PEM)
decode error 30<=>02 at
/usr/local/share/perl/5.6.1/Convert/ASN1/_decode.pm line 108.
        ...caught at rsa_pem.pl line 63.
	0000  111: [APPLICATION 3]
	0002     :   6E 76 65 72 74 3A 3A 41 53 4E 31 3D 48 41 53 48
	nvert::ASN1=HASH
	0012     :   28 30 78 31 30 31 62 32 32 31 30 29 __ __ __ __
	(0x101b2210)

I got the ASN1 from ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2.asn:
my $rsa_public_key = q<
RSAPublicKey ::= SEQUENCE {
   modulus          INTEGER,  -- (Usually large) n = p*q
   publicExponent   INTEGER  -- (Usually small) e
}
>;

Attacht is my test script. It uses openssl to generate a key pair, PEM
and DER encoded. It then tries to ASN-decode the key using either
Convert::PEM or Convert::ASN1.

regards,
	Lars

Re: Net::LDAP::Entry::clone() ?

[Kartik S. <sub...@co...>]

Graham Barr wrote:
>>Given that you approve of the clone() function, I was thinking it might 
>>be convenient for me to check in the clone code into CVS. Let me know if 
>>there's a specific process I should follow when doing this.
> 
> 
> Go ahead. All I ask of those with commit permission is that they discuss
> things on the list first to see if there is a broad concensus.

I have checked in Dave's clone() function into Entry.pm. I also updated 
Entry.pod with a little documentation and also the CREDITS file.

Cheers,

	-Kartik

Re: [Fwd] Can Net::LDAP handle UTF8?

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

On 21/2/03 1:34 am, Thomas Stripling <tst...@ho...> wrote:
> Hi,
> 
> I'm wondering if Net::LDAP can read characters with the UTF8 encoding.  If
> not, are there any plans to add this soon?  If there is a better place to
> send this email, please redirect me.
> 
> Regards,
> Tom Stripling

Net::LDAP can handle attribute values containing arbitrary bytes, so there
is no trouble handling UTF-8.

There's no automagic conversion of the values you're passing to Net::LDAP's
methods into UTF-8, or automagic conversion of the values you're getting
back, either.

Getting raw bytes into and back from the protocol is a really useful feature
of Net::LDAP that I for one would hate to lose, and any automagic conversion
would have to be switchable. (I'm also not sure how you could do it without
a lot more knowledge of the schema than LDAP servers provide.)

In what way were you expecting Net::LDAP to handle UTF-8 strings?

Cheers,

Chris

[Fwd] Can Net::LDAP handle UTF8?

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

----- Forwarded message from Thomas Stripling <tst...@ho...> -----

Date: Thu, 20 Feb 2003 18:07:56 -0600
To: gb...@po...
From: Thomas Stripling <tst...@ho...>
Subject: Can Net::LDAP handle UTF8?

Hi,

I'm wondering if Net::LDAP can read characters with the UTF8 encoding.  If 
not, are there any plans to add this soon?  If there is a better place to 
send this email, please redirect me.

Regards,
Tom Stripling


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

Re: Change password leads to insufficient access

[Christoph H. <em...@ch...>]

On Thu, Feb 20, 2003 at 10:17:33AM -0800, Todd Rosenberry wrote:
>    Try adding a line like this after your modify:
> print "LDAP error: ", $ldap_result->error, " (", $ldap_result->code,")\n";

Actually the line is there - I just didn't paste it here.

> My guess would be that you are getting an insufficient access error
> which means you should review any ACIs attached to
> ou=people,ou=proxy,o=ov or ou=proxy,o=ov to make sure your admin user
> really has full access.  You may have conflicting ACIs that lead to
> unexpected results.

Just found my mistake. The default slapd.conf (for OpenLDAP) which is
provided with the Debian package looks like follows:

===
access to attribute=userPassword
	by dn="" write
	by anonymous auth
	by self write
	by * none

access to *
	by dn="cn=admin,ou=proxy,o=ov" write
	by * read
===

I thout that the "cn=admin" account was allowed to write to any fields.
However I found out that the attribute "userPassword" is not handled as
"*" in this case. After I put the "by dn=cn=admin..." line in the first
block it worked. Shame on me. Thanks for your help. Another time that a
problem gets solved by explaining it. :)

 Christoph

-- 
~
~
".signature" [Modified] 3 lines --100%--                3,41         All

Re: Change password leads to insufficient access

[Todd R. <Tod...@xi...>]

    Try adding a line like this after your modify:
print "LDAP error: ", $ldap_result->error, " (", $ldap_result->code,")\n";
or look in your access log (thats what its called on iPlanet servers 
anyway) to see what the actual error is.  My guess would be that you are 
getting an insufficient access error which means you should review any 
ACIs attached to ou=people,ou=proxy,o=ov or ou=proxy,o=ov to make sure 
your admin user really has full access.  You may have conflicting ACIs 
that lead to unexpected results.

- Todd

Christoph Haas wrote:

>Hi, folks...
>
>whenever I try to change a userPassword entry I get an "insufficient
>access" error even when I bind to the LDAP tree as "admin". I can though
>other fields like "sn". The admin is allowed to write everything in the
>slapd.conf. This is the code I used:
>
>===
>use Net::LDAP qw(:all);
>
>my $ldap = Net::LDAP->new('localhost') or die "ldap open error $@";
>$ldap->bind('cn=admin,ou=proxy,o=ov',password=>'secretpassword');
>
>my $ldap_result = $ldap->modify(
>	'cn=username,ou=people,ou=proxy,o=ov',
>	replace => { userPassword => 'test' }
>);
>===
>
>Any ideas?
>
> Christoph
>
>  
>

moddn seems to kill orginal Entry on failure

[Enrico R. <re...@cn...>]

if I call

moddn($entry_ref, newrdn => $newrdn,newsuperior => $newROOT)

with an invalid rdn (class violating) it fails with message
"Object class violation" and the "new" entry does not "appear",
wich is ok.

But the original entry disappears, wich is not so ok :-(

"deleteoldrdn => 0" didn't solved the problem.

is there anything I can do to secure my data against such problems.
(like the requested clone-function) ?

thank you

- Enni

Change password leads to insufficient access

[Christoph H. <em...@ch...>]

Hi, folks...

whenever I try to change a userPassword entry I get an "insufficient
access" error even when I bind to the LDAP tree as "admin". I can though
other fields like "sn". The admin is allowed to write everything in the
slapd.conf. This is the code I used:

=3D=3D=3D
use Net::LDAP qw(:all);

my $ldap =3D Net::LDAP->new('localhost') or die "ldap open error $@";
$ldap->bind('cn=3Dadmin,ou=3Dproxy,o=3Dov',password=3D>'secretpassword');

my $ldap_result =3D $ldap->modify(
	'cn=3Dusername,ou=3Dpeople,ou=3Dproxy,o=3Dov',
	replace =3D> { userPassword =3D> 'test' }
);
=3D=3D=3D

Any ideas?

 Christoph

--=20
~
~
".signature" [Modified] 3 lines --100%--                3,41         All

Re: Large Searches / Asynchronous operations

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

On Thu, Feb 20, 2003 at 10:13:27AM +1100, Teo de Hesselle wrote:
> Hello all.
> 
> I am trying to do a large search (around 50,000 entries total, each
> around 3k when represented as LDIF. When I perform a search, the perl
> process grows to about 1gb of memory while running this search.
> 
> The code I am using is very very similar to the "callback" example in
> the FAQ. Oddly, my callback code only seems to get called when ALL
> entries have been returned! Surely something is going wrong... The code
> is at the bottom of this email.

it may be similar, but the changes you made cause the problem.

> Now.. Second question:
> 
> What I would like to do is this:
> 
> 1 - Connect to N LDAP servers simultaneously
> 2 - Search for a particular entry on each LDAP server
> 3 - Update each entry
> 
> ... each stage should ideally take a fraction of a second, though around
> here it is not uncommon for one server to be down, which causes all
> sorts of problems with PerlDAP. 
> 
> I would like to do each of stages 1 to 3 simultaneously, and each stage
> must have a time limit imposed.  
> 
> Is this possible with perl-ldap ? Either I'm doing something wrong, or
> the "asynchronous" mode simply defers processing until later...

I would suggest you develop you code as synchronous first, then look
into making it asynchronous and doing multiple at a time.

> Code:
> 
> sub processMessage($;$)
> {
>         my ($message, $entry) = @_;
>         return unless ($message->code == LDAP_SUCCESS);

There is your problem. The code is not known until that last packet
is received.

Graham.

>         return unless ($entry);
> 
>         print $entry->dn . "\n";
> 
>         $message->pop_entry;
> }
> 
> my $r;
> 
> my $ldap = Net::LDAP->new( "ldap.domain.edu.au", version=>3, timeout=>10, async => 0);
> $r = $ldap->bind("cn=Directory Manager", password=> "secret");
> $r->sync; $r->code and die " Can't Connect ";
> 
> print "bind: ". $r->code ."\n";
> 
> $r = $ldap->search (
>         base => 'o=UTS',
>         scope=> 'subtree',
>         filter => '(uid=*)',
>         callback => \&processMessage);
> 
> print "done". $r->done ."\n";
> 
> $r->sync;
> 
> print "search ". $r->code ."\n";
> print "done". $r->done ."\n";
> 
> 
> -- 
> Teo de Hesselle,                                      It's nice to be loved,
> Unix Systems Administrator,                          but there's a lot to be
> University of Technology, Sydney.                 said for terrified respect
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge

Large Searches / Asynchronous operations

[Teo de H. <tde...@ut...>]

Hello all.

I am trying to do a large search (around 50,000 entries total, each
around 3k when represented as LDIF. When I perform a search, the perl
process grows to about 1gb of memory while running this search.

The code I am using is very very similar to the "callback" example in
the FAQ. Oddly, my callback code only seems to get called when ALL
entries have been returned! Surely something is going wrong... The code
is at the bottom of this email.

Currently we are using PerlDAP, but have decided to try to replace it,
as it is showing it's age more and more... (lack of SSL support...)

Now.. Second question:

What I would like to do is this:

1 - Connect to N LDAP servers simultaneously
2 - Search for a particular entry on each LDAP server
3 - Update each entry

... each stage should ideally take a fraction of a second, though around
here it is not uncommon for one server to be down, which causes all
sorts of problems with PerlDAP. 

I would like to do each of stages 1 to 3 simultaneously, and each stage
must have a time limit imposed.  

Is this possible with perl-ldap ? Either I'm doing something wrong, or
the "asynchronous" mode simply defers processing until later...


Code:

sub processMessage($;$)
{
        my ($message, $entry) = @_;
        return unless ($message->code == LDAP_SUCCESS);
        return unless ($entry);

        print $entry->dn . "\n";

        $message->pop_entry;
}

my $r;

my $ldap = Net::LDAP->new( "ldap.domain.edu.au", version=>3, timeout=>10, async => 0);
$r = $ldap->bind("cn=Directory Manager", password=> "secret");
$r->sync; $r->code and die " Can't Connect ";

print "bind: ". $r->code ."\n";

$r = $ldap->search (
        base => 'o=UTS',
        scope=> 'subtree',
        filter => '(uid=*)',
        callback => \&processMessage);

print "done". $r->done ."\n";

$r->sync;

print "search ". $r->code ."\n";
print "done". $r->done ."\n";


-- 
Teo de Hesselle,                                      It's nice to be loved,
Unix Systems Administrator,                          but there's a lot to be
University of Technology, Sydney.                 said for terrified respect

Re: [Fwd] Wrong sintax ??

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

On 17/2/03 6:40 pm, Graham Barr <gb...@po...> wrote:

> ----- Forwarded message from Davi Baldin / Moeller Electric
> <da...@mo...> -----
> 
> Date: Mon, 17 Feb 2003 16:38:11 -0300
> To: <gb...@po...>
> From: "Davi Baldin / Moeller Electric" <da...@mo...>
> Subject: Wrong sintax ??
> 
> This script don`t work.
> 
> My LDAP server is Windows 2000.
> 
> Help me please !
> 
> tanks!!
> 
> davi
> 
> use Net::LDAP qw(:all);
> # Two syntaxes for initialization.  Choose one.
> $ldap = new Net::LDAP('192.168.16.14') or die "$@";
> $ldap->bind( version => 3);

Try adding:

    anonymous => 1

to the bind arguments. See the documentation!

> $mesg = $ldap->search ( base => "OU=moeller,DC=moeller,DC=com,DC=br",
>                       filter => "dn=*",
>                     ) or die ("Failed on search.$!");
> $count = $mesg->count;
> print "object numbers: $count\n";
> foreach $entry ($mesg->all_entries)
> {
>  $entry->dump;
> }
> $ldap->unbind;
> ----- End forwarded message -----

You might also want to explain what you wanted the script to do, and which
part is failing.

What server are you using on Windows 2000?

Cheers,

Chris

[Fwd] Wrong sintax ??

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

----- Forwarded message from Davi Baldin / Moeller Electric <da...@mo...> -----

Date: Mon, 17 Feb 2003 16:38:11 -0300
To: <gb...@po...>
From: "Davi Baldin / Moeller Electric" <da...@mo...>
Subject: Wrong sintax ??

This script don`t work.

My LDAP server is Windows 2000.

Help me please !

tanks!!

davi

use Net::LDAP qw(:all);
# Two syntaxes for initialization.  Choose one.
$ldap = new Net::LDAP('192.168.16.14') or die "$@";
$ldap->bind( version => 3);
$mesg = $ldap->search ( base => "OU=moeller,DC=moeller,DC=com,DC=br",
                        filter => "dn=*",
                      ) or die ("Failed on search.$!");
$count = $mesg->count;
print "object numbers: $count\n";
foreach $entry ($mesg->all_entries)
{
   $entry->dump;
}
$ldap->unbind;
----- End forwarded message -----

RE: search hangs around forever

[Hirmke M. <Mic...@ar...>]

Hi,

> Actually Exchange 5.5 creates a single thread process for the search. 
>  If the search results is over say 10,000 Exchange will drive up the 
> memory on the search, run out of resources and the search will die. If 
> your not careful other Exchange services will shut down as a result.

uhm, I don't see any ressource problem on the Exchange machine. In task
manager cpu und ram usage does not increase significantly when starting
my search.

> I would suggest setting your limit to something reasonable (Say 100, NOT 
> zero) and use Net::LDAP::Control::Paged; set at 100 per page.  This 
> trims the thread to 100 records and saves resources.  I've 
> returned as many as 160,000 objects with this method.

Tried that with 1000 hits per page. I used the example from the man page
for Control::Paged. It seems to work somehow, but I get an error saying

Can't call method "cookie" without a package or object reference

Any idea what might cause that? It happens with 0.251 and with 0.2701.
Is it a bug in the module or is it my fault?

> 
> Eric

Bye.
Michael.

RE: search hangs around forever

[Hirmke M. <Mic...@ar...>]

Hi again,

[...]
> (I suspect
> > this is the idle disconnect time configured in Exchange).
> 
> >   my( $LDAPDBG ) = 0;
> 
> What do you see if you set this to 15 ?

with LDAP 0.251 I get the following output:

---------------------------< schnipp schnapp >--------------------------
new ok
Net::LDAP=HASH(0x8490e1c) sending:

30 3A 02 01 01 60 35 02 01 03 04 23 63 6E 3D XX 0:...`5....#cn=X
XX XX XX XX XX XX XX XX XX XX 2C 63 6E 3D XX XX XXXXXXXXXX,cn=XX
XX XX XX XX XX XX 2C 63 6E 3D 41 64 6D 69 6E 80 XXXXXX,cn=Admin.
0B XX XX XX XX XX XX XX XX XX XX XX __ __ __ __ .XXXXXXXXXXX

0000   58: SEQUENCE {
0002    1:   INTEGER = 1
0005   53:   [APPLICATION 0] {
0007    1:     INTEGER = 3
000A   35:     STRING = 'cn=XXXXXXXXXXX,cn=XXXXXXXX,cn=Admin'
002F   11:     [CONTEXT 0]
0031     :       45 78 63 68 61 6E 67 65 35 2E 35 __ __ __ __ __ XXXXXXXXXXX
003C     :   }
003C     : }
Net::LDAP=HASH(0x8490e1c) received:

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

0000   12: SEQUENCE {
0002    1:   INTEGER = 1
0005    7:   [APPLICATION 1] {
0007    1:     ENUM = 0
000A    0:     STRING = ''
000C    0:     STRING = ''
000E     :   }
000E     : }
bind ok
Net::LDAP=HASH(0x8490e1c) sending:

30 81 9A 02 01 02 63 81 94 04 1B 6F 3D XX XX XX 0.....c....o=XXX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
XX XX XX XX XX XX 0A 01 02 0A 01 02 02 01 00 02 XXXXXX..........
01 00 01 01 00 A3 23 04 0B 6F 62 6A 65 63 74 43 ......#..objectC
6C 61 73 73 04 14 6F 72 67 61 6E 69 7A 61 74 69 lass..organizati
6F 6E 61 6C 50 65 72 73 6F 6E 30 41 04 0D 72 66 onalPerson0A..rf
63 38 32 32 4D 61 69 6C 62 6F 78 04 0C 6F 74 68 c822Mailbox..oth
65 72 4D 61 69 6C 62 6F 78 04 16 48 69 64 65 2D erMailbox..Hide-
46 72 6F 6D 2D 41 64 64 72 65 73 73 2D 42 6F 6F From-Address-Boo
6B 04 0A 49 73 2D 44 65 6C 65 74 65 64 __ __ __ k..Is-Deleted

0000  154: SEQUENCE {
0003    1:   INTEGER = 2
0006  148:   [APPLICATION 3] {
0009   27:     STRING = 'o=XXXXXXXXXXXXXXXXXXXXXXXXX'
0026    1:     ENUM = 2
0029    1:     ENUM = 2
002C    1:     INTEGER = 0
002F    1:     INTEGER = 0
0032    1:     BOOLEAN = FALSE
0035   35:     [CONTEXT 3] {
0037   11:       STRING = 'objectClass'
0044   20:       STRING = 'organizationalPerson'
005A     :     }
005A   65:     SEQUENCE {
005C   13:       STRING = 'rfc822Mailbox'
006B   12:       STRING = 'otherMailbox'
0079   22:       STRING = 'Hide-From-Address-Book'
0091   10:       STRING = 'Is-Deleted'
009D     :     }
009D     :   }
009D     : }
search ok
hits: 0
Net::LDAP=HASH(0x8490e1c) sending:

30 05 02 01 03 42 00 __ __ __ __ __ __ __ __ __ 0....B.

0000    5: SEQUENCE {
0002    1:   INTEGER = 3
0005    0:   [APPLICATION 2]
0007     : }
---------------------------< schnipp schnapp >--------------------------

> 
> Graham.
> 

Bye.
Michael.

RE: search hangs around forever

[Hirmke M. <Mic...@ar...>]

Hi,

[...]
> (I suspect
> > this is the idle disconnect time configured in Exchange).
> 
> >   my( $LDAPDBG ) = 0;
> 
> What do you see if you set this to 15 ?

before solving my original problem, I first have to find a solution
for this one:

I often use code similar to the one in LDAP.pod:

 my $schema = $ldap->schema();
 # get objectClasses
 @ocs = $schema->objectclasses();
 # Get the attributes
 @atts = $schema->attributes();

This used to work as expected in vesion 0.25 - but stopped working
in 0.2701. I always get

Can't locate object method "attributes" via package "Net::LDAP::Schema"

Same with method "objectclasses". Since it is still in the docs, I
supposed there were no changes, but ...
Is there a replacement for these methods?

> 
> Graham.
> 

TIA.

Bye.
Michael.

delete values from attributes

[Christoph H. <em...@ch...>]

Hi...

This posting is dealing with a topic which Todd Rosenberry brought up
two weeks ago. He was asking why the delete method of Net::LDAP::Entry
can only act on attributes and not specific values.

I struggled with this problem for two days. Finally I went mano-a-mano
with the spaghetti sources and found out that the delete method can do
more than specified in the man page. What I am doing is group based
authorisation based on LDAP groups. These groups are "groupOfNames"
objects which contain all the users in that group as "member"
attributes. That means that there is not only a single (unique)
attribute but many. What I needed is to remove a single user from the
member attribute list.

To cut it short: this is how I did it:

$ldap_search->entry->delete (
	'member' ,
	['cn=username,ou=people,o=company']
	);

$ldap_search->entry->update($ldap);

Joseph Kezar posted a reply on this topic and was completely right. If
you specify a reference to an array like above then the ->delete method
treats the deletion completely different and in the end does a modify to
remove this value.

Suggestion: Please correct the man page because it only says that the
syntax is "delete ( [ ATTR [, ATTR2 ... ]] )" which is not complete!

Thanks for reading.

 Christoph

-- 
~
~
".signature" [Modified] 3 lines --100%--                3,41         All

Code

[NGOC H. <ngo...@ya...>]

   Can you introduce web trang or book about source
code of accessing data from LDAP with Perl. Some
examples..

     Thank

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

RE: Net::LDAP::Entry::get_LDIF() ?

[FALTERMIER,DAVID (HP-PaloAlto,ex1) <dav...@hp...>]

> From: Graham Barr [mailto:gb...@po...]
> Sent: Thursday, February 13, 2003 3:56 PM

> LDIF generation belongs in the LDIF module, not Entry. If you want
> something to generate ldif into a string then we should reorg
> the code in ::LDIF so that is available. eg
> 
>   $ldif = Net::LDAP::LDIF->entry2ldif($entry);
> 
> As thats a bit ugly we could have ::LDIF or ::Util export 
> ldap_entry2ldif
> 
> Graham.

Thanks for the feedback, Graham.

I like the idea of putting the class/instance method into Net::LDAP::LDIF.
I'll take a closer look at the internals of the package and see if I can
come up with some coding suggestions that are more inline with the direction
you are suggesting.

-David

Re: Net::LDAP::Entry::clone() ?

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

On Fri, Feb 14, 2003 at 09:08:06AM -0500, Kartik Subbarao wrote:
> Cool. Confession time -- Dave and I work on the same team (HP's 
> Directory Services team). Dave's written many internal scripts that 
> heavily use Net::LDAP, and he's got some interesting ideas for 
> enhancements. I encouraged him to post to the list and see what you thought.

Great, welcome aboard Dave

> 
> Given that you approve of the clone() function, I was thinking it might 
> be convenient for me to check in the clone code into CVS. Let me know if 
> there's a specific process I should follow when doing this.

Go ahead. All I ask of those with commit permission is that they discuss
things on the list first to see if there is a broad concensus.

Graham.

Re: search hangs around forever

[Eric N. <eri...@di...>]

Actually Exchange 5.5 creates a single thread process for the search. 
 If the search results is over say 10,000 Exchange will drive up the 
memory on the search, run out of resources and the search will die.  If 
your not careful other Exchange services will shut down as a result.  I 
would suggest setting your limit to something reasonable (Say 100, NOT 
zero) and use Net::LDAP::Control::Paged; set at 100 per page.  This 
trims the thread to 100 records and saves resources.  I've returned as 
many as 160,000 objects with this method.

Eric
www.dir-wizards.com


Hirmke Michael wrote:

>Hi,
>
>I try to get all smtp addresses from an Exchange 5.5 directory using
>Perl::LDAP 0.2701. The search, though, either hangs around forever or
>returns after about ten minutes without giving any results (I suspect
>this is the idle disconnect time configured in Exchange).
>
>System is SuSE Linux 8.1 with kernel 2.4.19 and Perl::LDAP 0.2701.
>Btw. the same query with ldapsearch from the OpenLDAP package works as
>expected.
>
>The maximum result limit in the Exchange LDAP protocol ist configured to
>250000 and we have about 150000 entries in our directory.
>
>Here is the according code snippet:
>
>---------------------------< schnipp schnapp >--------------------------
>#!/usr/bin/perl -w
>
>use strict;
>use Net::LDAP 0.27;
>use LibUtil;
>
>  my( $ret_val );
>  my( $LDAPSRV ) = "my.exchange.machine";
>  my( $LDAPPORT ) = 389;
>  my( $LDAPVER ) = 3;
>  my( $LDAPDBG ) = 0;
>  my( $AUTHDN ) = "cn=myaccount,cn=mydomain,cn=Admin";
>  my( $AUTHPASS ) = "mypasswd";
>  my( $sBase ) = "o=myexchangeorg";
>  my( $sFilter ) = '(objectClass=*)';
>  my( @lAttrs, %hSearch, $oLDAP, $lohEntries );
>
>  $sFilter = &Latin1UTF8( $sFilter ) if( $sFilter && $LDAPVER >= 3 );
>  @lAttrs = ( "rfc822Mailbox", "otherMailbox", "Hide-From-Address-Book", "Is-Deleted" );
>
>  $oLDAP = new Net::LDAP( $LDAPSRV,
>                 version => $LDAPVER,
>                 port    => $LDAPPORT,
>                 debug   => $LDAPDBG,
>           ) or die $@;
>  print "new ok\n";
>  $ret_val = $oLDAP->bind( $AUTHDN,
>                           version => $LDAPVER,
>                           password => $AUTHPASS
>                         );
>  die ldap_error_text( $ret_val->code ) if( $ret_val->code );
>  print "bind ok\n";
>
>  %hSearch = (
>    scope    => "sub",
>    base     => $sBase,
>  );
>  $hSearch{ "filter" } = $sFilter if( $sFilter );
>  $hSearch{ "attrs" } = [ @lAttrs ] if( @lAttrs );
>
>  $lohEntries = $oLDAP->search( %hSearch ) || die $@;
>  print "search ok\n";
>
>  print "hits: ", $lohEntries->count, "\n";
>
>  $oLDAP->unbind;
>---------------------------< schnipp schnapp >--------------------------
>
>
>I can see in the Exchange Servers log that the client has connected and it
>even tells me, what attributes the script had requested. But that is the
>last log file entry before disconnecting.
>
>
>
>Any idea?
>
>TIA.
>
>Bye.
>Michael.
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
>are you planning your Web Server Security? Click here to get a FREE
>Thawte SSL guide and find the answers to all your  SSL security issues.
>http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
>  
>

Re: search hangs around forever

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

On Fri, Feb 14, 2003 at 01:39:12PM +0100, Hirmke Michael wrote:
> Hi,
> 
> I try to get all smtp addresses from an Exchange 5.5 directory using
> Perl::LDAP 0.2701. The search, though, either hangs around forever or
> returns after about ten minutes without giving any results (I suspect
> this is the idle disconnect time configured in Exchange).

>   my( $LDAPDBG ) = 0;

What do you see if you set this to 15 ?

Graham.