perl-ldap-dev

Re: Security risks of ldap

[<ma...@mj...>]

There was a presentation someone had at one time (sorry can't 
remember URL, but if you look at our FAQ or perhaps 
ldapguru.com or search on google you might turn it up).

Here's a brief list that I remember:
1) LDAP runs on 389, which requires you to be root on UNIX to 
start (of course the server can switch to a different user after it 
starts, but you still must be root to start it)

2) Many operations (in particular under LDAP 2 or if you're not 
using operational controls under LDAP 3) require you to be the 
directory super-user (or people take the path of least resistance 
and just do everything as directory super-user just like many 
people do everything as OS super-user). If you do this in a script, 
you probably put the password there as well. If someone sees the 
script, they now know the directory super user password. Of 
course even if you don't bind as directory super-user, the password 
for whomever you're binding as is still stored in the script.

3) Use of simple bind as authentication, in particular over non-
encrypted networks (that's easy to fix, just run everything over SSL 
;).

4) directory dump (e.g. db2ldif) dumps entire data out as plaintext (i 
guess you could do this to an encrypted filesystem or encrypt with 
pgp afterwards) this file can contain senstive information.

5) replication can occur over plaintext. security policy (e.g. ACLs) 
not guranteed to be shared between systems (ACL are not 
standardized)

Probably the biggest risk factor is number 2 (passwords stored in 
scripts). However, that's a risk not limited to LDAP, it goes for any 
script that is used to automate operations on a database. 

Also I didn't count in things that really aren't protocol specific such 
as problems with server software (e.g. buffer overflows), attacks 
from the OS/network level or simply leveraging people (or perhaps 
using the actual directory data to launch a social engineering 
attack against the organization. The latter is why I'm not for 
publicly publishing the directory). 

I'd say LDAP isn't any more vulnerable than any other protocol and 
that its benefits (in particular its potential use to improve the overall 
security of your organization), outweigh its security implications, 
but security is all about managing risk. How you manage that risk 
is what differentiates a secure organization from an insecure one. 
But then again, how well you manage risk overall is what seperates 
a successful company from a failed company.

Mark

On 6 Feb 01, at 2:18, Chris Ridd wrote:

> "Lambright, Linda (N-Averstar)" <lin...@lm...> wrote: >
> Thought I should resend this with the right title > >> ---------- >>
> From: 	Lambright, Linda (N-Averstar)[SMTP:lin...@lm...] >>
> Sent: 	Monday, February 05, 2001 4:38 PM >> To: 	Tom Jordan; 'Mark
> Wilcox' >> Cc: 	per...@li... >> Subject: 	RE:
> dynamic groups >> >> I need to write an explaination of the "security
> risks of ldap".  I have >> found it very difficult to find a good
> explaination of this anywhere and >> was >> wondering if anyone could
> point me at a good explaination. >> >> Thank you.
> 
> You could make a start by looking at all the "Security Considerations"
> in the LDAP RFCs.
> 
> They're probably what you'd expect of a system that stores sensitive
> personal information in a network database that is basically accessed
> in the clear. There is a standard mechanism (TLS) to encrypt the data
> in transit. There are no standards for pure-LDAP-only servers defining
> how to control access to the data, so that's an issue too.
> 
> Cheers,
> 
> Chris
> 
> 
> 


Mark Wilcox
ma...@mj...
Got LDAP?

Re: Does perl-ldap have a test mode

[<ma...@mj...>]

nope.

best bet is to setup a test server. That's a smart idea anyway.


Mark

On 6 Feb 01, at 9:05, mur...@po... wrote:

> Hi,
> I am writing some perl-ldap scripts and am wanting to test them
> without actually modifying data.  (like -n in ldapmodify & ldapdelete
> on Sun Directory Services)  Is there a way to get perl-ldap to "tell
> me what you will do but don't do it?"
> 
> Yes production data, my first scripts with perl-ldap and I am a tad
> nervous about hitting go... :-)
> 
> Thanks in advance for the help
> 
> regards
> Murray
> 
> **********************************************************************
> ************************** This email message and any attached files
> may contain information that is confidential and subject of legal
> privilege intended only for use by the individual or entity to whom
> they are addressed. If you are not the intended recipient or the
> person responsible for delivering the message to the intended
> recipient be advised that you have received this message in error and
> that any use, copying, circulation, forwarding, printing or
> publication of this message or attached files is strictly forbidden,
> as is the disclosure of the information contained therein. If you have
> received this message in error, please notify the sender immediately
> and delete it from your Inbox.
> **********************************************************************
> **************************
> 
> 
> 


Mark Wilcox
ma...@mj...
Got LDAP?

Re: Security risks of ldap

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

"Lambright, Linda (N-Averstar)" <lin...@lm...> wrote:
> Thought I should resend this with the right title
> 
>> ----------
>> From: 	Lambright, Linda (N-Averstar)[SMTP:lin...@lm...]
>> Sent: 	Monday, February 05, 2001 4:38 PM
>> To: 	Tom Jordan; 'Mark Wilcox'
>> Cc: 	per...@li...
>> Subject: 	RE: dynamic groups
>> 
>> I need to write an explaination of the "security risks of ldap".  I have
>> found it very difficult to find a good explaination of this anywhere and
>> was
>> wondering if anyone could point me at a good explaination.
>>
>> Thank you.

You could make a start by looking at all the "Security Considerations" in
the LDAP RFCs.

They're probably what you'd expect of a system that stores sensitive
personal information in a network database that is basically accessed in
the clear. There is a standard mechanism (TLS) to encrypt the data in
transit. There are no standards for pure-LDAP-only servers defining how to
control access to the data, so that's an issue too.

Cheers,

Chris

Re: Changes to perl-ldap schema code

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

Graham Barr <gb...@po...> wrote:
> On Mon, Feb 05, 2001 at 10:21:30AM -0600, Clif Harden wrote:
>> > 
>> > Clif Harden <ch...@po...> wrote:
>> > > + =item schema ( OPTIONS )
>> > > + 
>> > > + Request that a schema search be performed.  This can be used to
>> > > read  + schema information.
>> > > + 
>> > > + The result is an object of class
>> > > L<Net::LDAP::Schema|Net::LDAP::Schema>. + Read this documentation
>> > > for further information about methods that + can be preformed with
>> > > this object.
>> > > + 
>> > > + =over 4
>> > > + 
>> > > + =item dn
>> > > + 
>> > > + If a DN is supplied, it will become the base object entry from 
>> > > + which the search for schema information will be conducted.  If
>> > > + no DN is supplied the base object entry will be determined from
>> > > + the rootDSE entry.
>> > 
>> > The changes look OK. I'd like to see it returning cached Schema
>> > objects, because these are quite expensive to keep retrieving and
>> > parsing. My second change of last week implemented a cache, it was
>> > kinda hacky but generally the right sort of approach.
> 
> I don't think it is the place of Net::LDAP to do the caching. As you say
> these can be quite large and for Net::LDAP tp cache them could just be a
> waste on memory. It should eb up to the user application to cache the
> object returned.

OK, fair argument. I'm not sure how we could implement caching up in the
application though, since the read of the subentry is very much hidden
inside schema(). But we can address that later on if it becomes necessary.

Cheers,

Chris

Security risks of ldap

[Lambright, L. (N-Averstar) <lin...@lm...>]

Thought I should resend this with the right title

> ----------
> From: 	Lambright, Linda (N-Averstar)[SMTP:lin...@lm...]
> Sent: 	Monday, February 05, 2001 4:38 PM
> To: 	Tom Jordan; 'Mark Wilcox'
> Cc: 	per...@li...
> Subject: 	RE: dynamic groups
> 
> I need to write an explaination of the "security risks of ldap".  I have
> found it very difficult to find a good explaination of this anywhere and
> was
> wondering if anyone could point me at a good explaination.
> 
> Thank you.
> 
> 

Does perl-ldap have a test mode

[<mur...@po...>]

Hi,
I am writing some perl-ldap scripts and am wanting to test them without
actually modifying data.  (like -n in ldapmodify & ldapdelete on Sun
Directory Services)  Is there a way to get perl-ldap to "tell me what you
will do but don't do it?"

Yes production data, my first scripts with perl-ldap and I am a tad nervous
about hitting go... :-)

Thanks in advance for the help

regards
Murray

************************************************************************************************
This email message and any attached files may contain information that is 
confidential and subject of legal privilege intended only for use by the individual 
or entity to whom they are addressed. If you are not the intended recipient or the 
person responsible for delivering the message to the intended recipient be 
advised that you have received this message in error and that any use, copying, 
circulation, forwarding, printing or publication of this message or attached files is 
strictly forbidden, as is the disclosure of the information contained therein.
If you have received this message in error, please notify the sender immediately 
and delete it from your Inbox.
************************************************************************************************

RE: dynamic groups

[Lambright, L. (N-Averstar) <lin...@lm...>]

I need to write an explaination of the "security risks of ldap".  I have
found it very difficult to find a good explaination of this anywhere and was
wondering if anyone could point me at a good explaination.

Thank you.

Second attempt: Changes to perl-ldap schema code

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

This is a second attempt to send this message to the
per...@li... list.  It appears
that the first message got lost somewhere.  



Attached are 4 patch files that hopefully will fix
several concerns about the perl-ldap module's ability
to pull schema information correctly.  These patch files
were generated from version .22.

I have tested these changes against my Openldap 2.0.7
server, my x.500 servers, and Netscape 4.x server.
There were no problems pulling the schema or rootDSE
information.

I have not had a chance to test this against an Exchange
server or Active Directory server.  I hopefully will be
able to do this in the very near future.

I have not tested the functions that decode matchingRuleUse,
dITStructureRules, dITContentRules, or nameForms because I 
do not have access to any servers that have these structures.

About the patch files.

LDAP.pm.patch ->  I modified the schema function to use the
correct filters and added the attrs option to retrieve all of
the attributes associated with the rootDSE and subschemaSubentry.

LDAP.pod.patch -> I added documentation about the schema function
and root_dse function.  I added examples to show how to use
the schema function to retrieve objectClasses and attributes. 
Once these are understood pulling the other attributes 
(matchingRules, etc) is easy to do.

I added examples to show how to use the root_dse function and
how to use the get_value method to retrieve rootDSE attribute
information.

Schema.pm.patch -> I added code to comprehend the 
matchingRuleUse, dITStructureRules, dITContentRules,
nameForms attributes.

Schema.pod.patch -> I added documentation on the functions
that determine object type and retrieve attribute data for
matchingRuleUse, dITStructureRules, dITContentRules,
nameForms attributes.
  
Regards,

Clif Harden          ch...@po...

Re: Changes to perl-ldap schema code

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

On Mon, Feb 05, 2001 at 10:21:30AM -0600, Clif Harden wrote:
> > 
> > Clif Harden <ch...@po...> wrote:
> > > + =item schema ( OPTIONS )
> > > + 
> > > + Request that a schema search be performed.  This can be used to read 
> > > + schema information.
> > > + 
> > > + The result is an object of class L<Net::LDAP::Schema|Net::LDAP::Schema>.
> > > + Read this documentation for further information about methods that
> > > + can be preformed with this object.
> > > + 
> > > + =over 4
> > > + 
> > > + =item dn
> > > + 
> > > + If a DN is supplied, it will become the base object entry from 
> > > + which the search for schema information will be conducted.  If
> > > + no DN is supplied the base object entry will be determined from
> > > + the rootDSE entry.
> > 
> > The changes look OK. I'd like to see it returning cached Schema objects,
> > because these are quite expensive to keep retrieving and parsing. My second
> > change of last week implemented a cache, it was kinda hacky but generally
> > the right sort of approach.

I don't think it is the place of Net::LDAP to do the caching. As you say these
can be quite large and for Net::LDAP tp cache them could just be a waste
on memory. It should eb up to the user application to cache the object
returned.

> > I'd suggest one change to the documentation above, to the effect that the
> > DN is the name of a subschema *subentry* containing the schema. ie replace
> > the word entry with subentry. I think that clarifies what it is doing.
> > 
> 
> I will leave this up to Graham to decide.

Sounds fine to me.

> > We still need a mechanism for retrieving subschema given the DN of a plain
> > entry (, which is by far and away the *best* way of getting schema. (Maybe
> > we can add this to Net::LDAP::Entry?)
> > 
> 
> I will leave this function for someone else to contribute.

Patches welcome.

Graham.

> 
> I have been using the objectClass attribute for this function since you
> can not be sure that a subschemaSubentry attribute will exist for any
> given entry.  Since I use the caching method described above it works
> great for me.  It may or may not work for anyone else.
> 
> 
> > Cheers,
> > 
> > Chris
> > 
> 
> 

Re: Changes to perl-ldap schema code

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

> 
> Clif Harden <ch...@po...> wrote:
> > + =item schema ( OPTIONS )
> > + 
> > + Request that a schema search be performed.  This can be used to read 
> > + schema information.
> > + 
> > + The result is an object of class L<Net::LDAP::Schema|Net::LDAP::Schema>.
> > + Read this documentation for further information about methods that
> > + can be preformed with this object.
> > + 
> > + =over 4
> > + 
> > + =item dn
> > + 
> > + If a DN is supplied, it will become the base object entry from 
> > + which the search for schema information will be conducted.  If
> > + no DN is supplied the base object entry will be determined from
> > + the rootDSE entry.
> 
> The changes look OK. I'd like to see it returning cached Schema objects,
> because these are quite expensive to keep retrieving and parsing. My second
> change of last week implemented a cache, it was kinda hacky but generally
> the right sort of approach.


When you do the $schema = $ldap->schema() function call, the $schema
object stays around until you destroy it.  This is the way I have been
doing caching and I still use the schema methods to retrieve 
information when I need it.  I do not have to write any new code.

> 
> I'd suggest one change to the documentation above, to the effect that the
> DN is the name of a subschema *subentry* containing the schema. ie replace
> the word entry with subentry. I think that clarifies what it is doing.
> 

I will leave this up to Graham to decide.

> We still need a mechanism for retrieving subschema given the DN of a plain
> entry (, which is by far and away the *best* way of getting schema. (Maybe
> we can add this to Net::LDAP::Entry?)
> 

I will leave this function for someone else to contribute.

I have been using the objectClass attribute for this function since you
can not be sure that a subschemaSubentry attribute will exist for any
given entry.  Since I use the caching method described above it works
great for me.  It may or may not work for anyone else.


> Cheers,
> 
> Chris
> 

Re: Changes to perl-ldap schema code

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

Clif Harden <ch...@po...> wrote:
> + =item schema ( OPTIONS )
> + 
> + Request that a schema search be performed.  This can be used to read 
> + schema information.
> + 
> + The result is an object of class L<Net::LDAP::Schema|Net::LDAP::Schema>.
> + Read this documentation for further information about methods that
> + can be preformed with this object.
> + 
> + =over 4
> + 
> + =item dn
> + 
> + If a DN is supplied, it will become the base object entry from 
> + which the search for schema information will be conducted.  If
> + no DN is supplied the base object entry will be determined from
> + the rootDSE entry.

The changes look OK. I'd like to see it returning cached Schema objects,
because these are quite expensive to keep retrieving and parsing. My second
change of last week implemented a cache, it was kinda hacky but generally
the right sort of approach.

I'd suggest one change to the documentation above, to the effect that the
DN is the name of a subschema *subentry* containing the schema. ie replace
the word entry with subentry. I think that clarifies what it is doing.

We still need a mechanism for retrieving subschema given the DN of a plain
entry (, which is by far and away the *best* way of getting schema. (Maybe
we can add this to Net::LDAP::Entry?)

Cheers,

Chris

Changing userPassword via Mozilla::LDAP::Conn

[Billy J. <bid...@ya...>]

     Hi,

I've seen the subject above up for discussion but aplogize if the 
conclusion escaped me, so here it is again.

I am trying to write a CGI for our users to change their LDAP password via 
web, and a piece of the code follows:

use Mozilla::LDAP::Conn;
require "ldap-lib.pl";

...

    $ld=&LdapOpen($ldaphost,$ldapport,$dnmanager,$dnpassword);
     $Entry= $ld->search($basedn,'sub',$user,0);
     while ($Entry) {
       $Entry->{userpassword}[0]= $lpass;
       $ld->update($Entry);
       $my_dn= $Entry->{cn}[0];
       print h2("Password Changed!");
       print p("Your LDAP password is changed!");
       print p("Use you browser's BACK button for other menus");
       $Entry= $ld->nextEntry();
     }

Tried to bind both as the user itself and the dnmanager (above), but 
failed. My slapd logs does show the bind and search ops, but not the 
update/mod.

Any pointers/suggestions will be greatly appreciated.

Cheers,
Billy

Changes to perl-ldap schema code

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

Attached are 4 patch files that hopefully will fix
several concerns about the perl-ldap module's ability
to pull schema information correctly.  These patch files
were generated from version .22.

I have tested these changes against my Openldap 2.0.7
server, my x.500 servers, and Netscape 4.x server.
There were no problems pulling the schema or rootDSE
information.

I have not had a chance to test this against an Exchange
server or Active Directory server.  I hopefully will be
able to do this in the very near future.

I have not tested the functions that decode matchingRuleUse,
dITStructureRules, dITContentRules, or nameForms because I 
do not have access to any servers that have these structures.

About the patch files.

LDAP.pm.patch ->  I modified the schema function to use the
correct filters and added the attrs option to retrieve all of
the attributes associated with the rootDSE and subschemaSubentry.

LDAP.pod.patch -> I added documentation about the schema function
and root_dse function.  I added examples to show how to use
the schema function to retrieve objectClasses and attributes. 
Once these are understood pulling the other attributes 
(matchingRules, etc) is easy to do.

I added examples to show how to use the root_dse function and
how to use the get_value method to retrieve rootDSE attribute
information.

Schema.pm.patch -> I added code to comprehend the 
matchingRuleUse, dITStructureRules, dITContentRules,
nameForms attributes.

Schema.pod.patch -> I added documentation on the functions
that determine object type and retrieve attribute data for
matchingRuleUse, dITStructureRules, dITContentRules,
nameForms attributes.
  
Regards,

Clif Harden          ch...@po...

game player 510

[<GaM...@ao...>]

can you help me find the master s/n password for the computer I am using 
please I am in a bind and I will be in trouble if I don't find it e-mail me 
if you can help please ASAP thank you

Re: search sub-set of ou's

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

Another option ,if your server supports LDAPv3 extensible
matching, is to search <dc=tamu,dc=edu> for
 (|(ou:dn:=dept1)(ou:dn:=dept2))

Kurt

PS: OpenLDAP does not yet support this

At 02:18 PM 2/2/01 -0600, Bing Du wrote:
>We do not have 'ou' as attribute in people's entries.  It's just an
>structural part of the dn.  Searching 'dc=tamu,dc=edu' definitely would
>take a very long time.  Multiple searches work fine if there are not
>many ou's, say two or three, to be searched.  What if there are ten or
>more?  I had lived with multiple searches before I posted the question. 
>Just wondering if there is any better solutions.
>
>Thanks very much for the input.
>
>Bing
>
>Bing Du <bi...@ta..., 979-845-9577>
>Texas A&M University, CIS, Operating Systems, Unix
>
>>>> Jim Harle <ha...@us...> 02/02/01 02:02PM >>>
>This depends on wheter or not your user objects also happen to have an
>ou
>attribute in addition to the structural part of the dn.  We populate
>all
>of our users with an ou attribute corresponding to their lowest ou, so
>somebody might have "ou=Mathematic Department".  If so, you can build
>that
>into the filter (|(ou=dept1)(ou=dept2)).  If you don't hae such or if
>you
>are looking higher than is reflected, then you would need to either do
>multiple searches with multiple bases or search "dc=tamu,dc=edu" and
>then
>do something like
>  $dn = $entry-dn;
>  next unless ( ($dn =~ /ou\=dept1/) or ($dn =~ /ou\=dept2) );
>
>--Jim Harle
>
>
>On Fri, 2 Feb 2001, Bing Du wrote:
>
>> There are quita a few ou's under "dc=tamu,dc=edu".  How should I
>specify
>> the base to just search in two ou's.  For instance, what should the
>> $basedn be if I just want to look up "cn=john smith" in
>> 'ou=dept1,dc=tamu,dc=edu" and 'ou=dept2,dc=tamu,dc=edu"?
>>
>> $mesg = $ld->search(base => $basedn,scope => 'sub',filter =>
>"(cn=john
>> smith)",attrs => [],typesonly => 0);
>>
>> Thanks,
>>
>> Bing
>>
>> Bing Du <bi...@ta..., 979-845-9577>
>> Texas A&M University, CIS, Operating Systems, Unix
>>
>>

Re: search sub-set of ou's

[Bing D. <Bi...@ci...>]

We do not have 'ou' as attribute in people's entries.  It's just an
structural part of the dn.  Searching 'dc=tamu,dc=edu' definitely would
take a very long time.  Multiple searches work fine if there are not
many ou's, say two or three, to be searched.  What if there are ten or
more?  I had lived with multiple searches before I posted the question. 
Just wondering if there is any better solutions.

Thanks very much for the input.

Bing

Bing Du <bi...@ta..., 979-845-9577>
Texas A&M University, CIS, Operating Systems, Unix

>>> Jim Harle <ha...@us...> 02/02/01 02:02PM >>>
This depends on wheter or not your user objects also happen to have an
ou
attribute in addition to the structural part of the dn.  We populate
all
of our users with an ou attribute corresponding to their lowest ou, so
somebody might have "ou=Mathematic Department".  If so, you can build
that
into the filter (|(ou=dept1)(ou=dept2)).  If you don't hae such or if
you
are looking higher than is reflected, then you would need to either do
multiple searches with multiple bases or search "dc=tamu,dc=edu" and
then
do something like
  $dn = $entry-dn;
  next unless ( ($dn =~ /ou\=dept1/) or ($dn =~ /ou\=dept2) );

--Jim Harle


On Fri, 2 Feb 2001, Bing Du wrote:

> There are quita a few ou's under "dc=tamu,dc=edu".  How should I
specify
> the base to just search in two ou's.  For instance, what should the
> $basedn be if I just want to look up "cn=john smith" in
> 'ou=dept1,dc=tamu,dc=edu" and 'ou=dept2,dc=tamu,dc=edu"?
>
> $mesg = $ld->search(base => $basedn,scope => 'sub',filter =>
"(cn=john
> smith)",attrs => [],typesonly => 0);
>
> Thanks,
>
> Bing
>
> Bing Du <bi...@ta..., 979-845-9577>
> Texas A&M University, CIS, Operating Systems, Unix
>
>

Re: search sub-set of ou's

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

This depends on wheter or not your user objects also happen to have an ou
attribute in addition to the structural part of the dn.  We populate all
of our users with an ou attribute corresponding to their lowest ou, so
somebody might have "ou=Mathematic Department".  If so, you can build that
into the filter (|(ou=dept1)(ou=dept2)).  If you don't hae such or if you
are looking higher than is reflected, then you would need to either do
multiple searches with multiple bases or search "dc=tamu,dc=edu" and then
do something like
  $dn = $entry-dn;
  next unless ( ($dn =~ /ou\=dept1/) or ($dn =~ /ou\=dept2) );

--Jim Harle


On Fri, 2 Feb 2001, Bing Du wrote:

> There are quita a few ou's under "dc=tamu,dc=edu".  How should I specify
> the base to just search in two ou's.  For instance, what should the
> $basedn be if I just want to look up "cn=john smith" in
> 'ou=dept1,dc=tamu,dc=edu" and 'ou=dept2,dc=tamu,dc=edu"?
>
> $mesg = $ld->search(base => $basedn,scope => 'sub',filter => "(cn=john
> smith)",attrs => [],typesonly => 0);
>
> Thanks,
>
> Bing
>
> Bing Du <bi...@ta..., 979-845-9577>
> Texas A&M University, CIS, Operating Systems, Unix
>
>

Re: schema attributes method

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

> 
> On Fri, Feb 02, 2001 at 08:40:28AM -0000, Chris Ridd wrote:
> > Justin <da...@io...> wrote:
> > > Greetings!
> > > 
> > > 
> > > I am using version 0.22 of the perl library and Netscape Directory Server 
> > > version 4.12.  Whenver I retrieve the list of attributes using something
> > > like:
> > > 
> > >       my $schema = $ldap->schema("cn=Schema");
> > >       my @atts = $schema->attributes();
> > > 
> > > the array returned from attributes() is all upper case.  However, the
> > > values returned from the MUST and MAY listings for an object class,
> > > obtained by:
> > > 
> > >       my @may = $schema->item($oid, "may");
> > > 
> > > Returns a listing that is in Mixed Case, as it is returned from the
> > > directory.
> > > 
> > > 
> > > Can anyone explain why $schema->attributes does not return a mixed case
> > > listing?
> > 
> > Attribute names are of course not case-sensitive, so returning them in all
> > upper-case does not really matter.
> > 
> > But it is curious that it is inconsistent between the calls. Possibly the
> > attributes() call is returning the names after they've been internally
> > canonicalized, and the item call isn't. I think I can see this being done
> > in the _fixup_entry routine. Well, there are a bunch of calls to 'uc' in
> > there which weren't in the Schema module in perl-ldap 0.20, which returns
> > mixed case attributes from both calls.
> > 
> > Does calling $schema->item($oid) return upper- or lower-case stuff?
> 
> Calling $schema->item($att, "name") returns mixed case, which is what I want.
> (where $att is one of @att, returned from $schema->attributes()).
> 
> However!
> 
> The Netscape Directory Server 4.12 has multiple attributetype entries for
> a given OID.  "cn" and "CommonName" for example, share an OID.  I believe
> this is allowed as per rfc2251 section 4.1.4.
> 
> So calling $schema->item($att, "name"), while it returns a mixed case name
> as I like, will only ever return "CommonName" and never "cn" (or both).
> 
> 
> Justin
> > 
> > Cheers,
> > 
> > Chris
> 
> 


You can get the alias name(s) by retrieving the "aliases"
from the schema object.

Do something like the following;

my $oid = $schema->name2oid( "<attribute, objectclass, or matchingrule name>" );
@item = $schema->item( $oid, "aliases" );

print "aliases: @item\n";

If you want to see how many and what items are
associated with a retrieved "oid" do the following;

my @items = $schema->items( "$oid" );
print "@items\";

Regards,

Clif Harden           INTERNET:  c-h...@ti...
Texas Instruments                
Directory Services
6500 Chase Oaks Blvd, M/S 8412  
Plano, TX 75023        
                         Voice:  972-575-0855
                           FAX:  972-575-2418

search sub-set of ou's

[Bing D. <Bi...@ci...>]

There are quita a few ou's under "dc=tamu,dc=edu".  How should I specify
the base to just search in two ou's.  For instance, what should the
$basedn be if I just want to look up "cn=john smith" in
'ou=dept1,dc=tamu,dc=edu" and 'ou=dept2,dc=tamu,dc=edu"?

$mesg = $ld->search(base => $basedn,scope => 'sub',filter => "(cn=john
smith)",attrs => [],typesonly => 0);

Thanks,

Bing

Bing Du <bi...@ta..., 979-845-9577>
Texas A&M University, CIS, Operating Systems, Unix

Re: schema attributes method

[Justin <da...@io...>]

> >> Does calling $schema->item($oid) return upper- or lower-case stuff?
> > 
> > Calling $schema->item($att, "name") returns mixed case, which is what I
> > want. (where $att is one of @att, returned from $schema->attributes()).
> > 
> > However!
> > 
> > The Netscape Directory Server 4.12 has multiple attributetype entries for
> > a given OID.  "cn" and "CommonName" for example, share an OID.  I believe
> > this is allowed as per rfc2251 section 4.1.4.
> 
> Yes. Attributes have zero or more names.

Thanks for the clarification.

Shouldn't $schema->item($attribute_oid, "name") return a list of names then?

I tried @fullnames = $schema->item($attribute_oid, "name"); since the item()
function is aware of list vs. syntax context but it only ever seemed to 
return one name per OID.


Thanks for the help,
 Justin

Re: schema attributes method

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

Justin <da...@io...> wrote:
> On Fri, Feb 02, 2001 at 08:40:28AM -0000, Chris Ridd wrote:
>> Justin <da...@io...> wrote:
>> > Greetings!
>> > 
>> > 
>> > I am using version 0.22 of the perl library and Netscape Directory
>> > Server  version 4.12.  Whenver I retrieve the list of attributes using
>> > something like:
>> > 
>> >       my $schema = $ldap->schema("cn=Schema");
>> >       my @atts = $schema->attributes();
>> > 
>> > the array returned from attributes() is all upper case.  However, the
>> > values returned from the MUST and MAY listings for an object class,
>> > obtained by:
>> > 
>> >       my @may = $schema->item($oid, "may");
>> > 
>> > Returns a listing that is in Mixed Case, as it is returned from the
>> > directory.
>> > 
>> > 
>> > Can anyone explain why $schema->attributes does not return a mixed case
>> > listing?
>> 
>> Attribute names are of course not case-sensitive, so returning them in
>> all upper-case does not really matter.
>> 
>> But it is curious that it is inconsistent between the calls. Possibly the
>> attributes() call is returning the names after they've been internally
>> canonicalized, and the item call isn't. I think I can see this being done
>> in the _fixup_entry routine. Well, there are a bunch of calls to 'uc' in
>> there which weren't in the Schema module in perl-ldap 0.20, which returns
>> mixed case attributes from both calls.
>> 
>> Does calling $schema->item($oid) return upper- or lower-case stuff?
> 
> Calling $schema->item($att, "name") returns mixed case, which is what I
> want. (where $att is one of @att, returned from $schema->attributes()).
> 
> However!
> 
> The Netscape Directory Server 4.12 has multiple attributetype entries for
> a given OID.  "cn" and "CommonName" for example, share an OID.  I believe
> this is allowed as per rfc2251 section 4.1.4.

Yes. Attributes have zero or more names.

> So calling $schema->item($att, "name"), while it returns a mixed case name
> as I like, will only ever return "CommonName" and never "cn" (or both).

Cheers,

Chris

Re: schema attributes method

[Justin <da...@io...>]

On Fri, Feb 02, 2001 at 08:40:28AM -0000, Chris Ridd wrote:
> Justin <da...@io...> wrote:
> > Greetings!
> > 
> > 
> > I am using version 0.22 of the perl library and Netscape Directory Server 
> > version 4.12.  Whenver I retrieve the list of attributes using something
> > like:
> > 
> >       my $schema = $ldap->schema("cn=Schema");
> >       my @atts = $schema->attributes();
> > 
> > the array returned from attributes() is all upper case.  However, the
> > values returned from the MUST and MAY listings for an object class,
> > obtained by:
> > 
> >       my @may = $schema->item($oid, "may");
> > 
> > Returns a listing that is in Mixed Case, as it is returned from the
> > directory.
> > 
> > 
> > Can anyone explain why $schema->attributes does not return a mixed case
> > listing?
> 
> Attribute names are of course not case-sensitive, so returning them in all
> upper-case does not really matter.
> 
> But it is curious that it is inconsistent between the calls. Possibly the
> attributes() call is returning the names after they've been internally
> canonicalized, and the item call isn't. I think I can see this being done
> in the _fixup_entry routine. Well, there are a bunch of calls to 'uc' in
> there which weren't in the Schema module in perl-ldap 0.20, which returns
> mixed case attributes from both calls.
> 
> Does calling $schema->item($oid) return upper- or lower-case stuff?

Calling $schema->item($att, "name") returns mixed case, which is what I want.
(where $att is one of @att, returned from $schema->attributes()).

However!

The Netscape Directory Server 4.12 has multiple attributetype entries for
a given OID.  "cn" and "CommonName" for example, share an OID.  I believe
this is allowed as per rfc2251 section 4.1.4.

So calling $schema->item($att, "name"), while it returns a mixed case name
as I like, will only ever return "CommonName" and never "cn" (or both).


Justin






> 
> Cheers,
> 
> Chris

Re: schema attributes method

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

Justin <da...@io...> wrote:
> Greetings!
> 
> 
> I am using version 0.22 of the perl library and Netscape Directory Server 
> version 4.12.  Whenver I retrieve the list of attributes using something
> like:
> 
>       my $schema = $ldap->schema("cn=Schema");
>       my @atts = $schema->attributes();
> 
> the array returned from attributes() is all upper case.  However, the
> values returned from the MUST and MAY listings for an object class,
> obtained by:
> 
>       my @may = $schema->item($oid, "may");
> 
> Returns a listing that is in Mixed Case, as it is returned from the
> directory.
> 
> 
> Can anyone explain why $schema->attributes does not return a mixed case
> listing?

Attribute names are of course not case-sensitive, so returning them in all
upper-case does not really matter.

But it is curious that it is inconsistent between the calls. Possibly the
attributes() call is returning the names after they've been internally
canonicalized, and the item call isn't. I think I can see this being done
in the _fixup_entry routine. Well, there are a bunch of calls to 'uc' in
there which weren't in the Schema module in perl-ldap 0.20, which returns
mixed case attributes from both calls.

Does calling $schema->item($oid) return upper- or lower-case stuff?

Cheers,

Chris

Re: missing entries from queries

[David B. <D.B...@ma...>]

Apologies - it's not strictly Net::LDAP related....

I don't know if it's related, but I have a novell (5.1) LDAP server that no
matter what I do I can't get it to return more than 500 entries (tried 4
different clients including Net::LDAP).  
It has a default setting of returning a max of 500, but seems to completely
ignore it when I change that to anything else..I've tried
501,1000,5000,10000 with no difference.
You see, I have about 10000 user objects (sorry inetorg objects) across ~20
ou's, and frequently more than 500 objects in an ou.  
(rebooting and/or reloading the NLM's doesn't help)
I have worked around the problem in Net::LDAP with code like:

foreach $ou (@oulist){
  foreach $letter (@alphabet) {
    (search for all names beginning with $letter)
  }
}
...which works because I always have less than 500 smiths in an ou!

Any Novell-ites seen similar?... and got a solution? then e-mail me off-list.

David.

At 08:25 PM 2/1/01 +1100, Pete wrote:
>Hi everyone,
>
>I have come across a strange issue and am hoping others may 
>have something to offer as we can't figure out why it is happening.
>
>Firstly, the server is setup to return 1000 entries on a query.
>
>Now when querying sn=me*, only 113 names are returned, there 
>should be in the realm of 240.  The problem was highlighted when 
>looking for sn values of met* there should be 10, but we only get 1 
>back.  So that was the next query we did, sn=met*, which returns 
>the right number.
>
>I think it has something to do with the server rather than the client 
>(we have tried perl ldap and two other ldap clients and the results 
>are the same).
>
>Like I said, I'm hoping someone may have seen this before and can 
>offer a pointer as we have spent ages on this with no idea where to 
>look next.
>
>Thanks,
>
>
>Pete.
>
>
>

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

schema attributes method

[Justin <da...@io...>]

Greetings!


I am using version 0.22 of the perl library and Netscape Directory Server 
version 4.12.  Whenver I retrieve the list of attributes using something like:

      my $schema = $ldap->schema("cn=Schema");
      my @atts = $schema->attributes();

the array returned from attributes() is all upper case.  However, the values
returned from the MUST and MAY listings for an object class, obtained by:

      my @may = $schema->item($oid, "may");

Returns a listing that is in Mixed Case, as it is returned from the directory.


Can anyone explain why $schema->attributes does not return a mixed case
listing?


Thanks!

Justin