perl-ldap-dev

multi-valued userPassword attributes.

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

I have a question for the gurus of ldap.

Does any one use multi-valued userPasswords?
If multi-valued userPasswords are used could
they have different encrption tags; {crypt}, {SHA}, etc.

Regards,

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

Re: multi-valued userPassword attributes.

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

Clif Harden <cl...@di...> wrote:
> 
> 
> I have a question for the gurus of ldap.
> 
> Does any one use multi-valued userPasswords?
> If multi-valued userPasswords are used could
> they have different encrption tags; {crypt}, {SHA}, etc.

The only real contraint the standards impose is that all values of an
attribute must compare different for equality.

Since the use of hashed password values is somewhat non-standard (they are
only loosely defined in an informational RFC) it is really something you
will need to ask your vendor about.

Off the top of my head there are two ways a server could implement hashed
password values:

1) by using special syntax handlers which were aware of the hashing
mechanisms

2) by doing simple textual comparisons on the values

For case 1) since it is impossible to compare two values using different
hashing schemes (eg {sha}1234 and {crypt}1234) unless you know the
plaintext values it is *probable* that your server will say these are
different values and hence permit one userPassword attribute to contain
multiple differently-hashed values.

In case 2) you can probably see it is going to work just fine, except that
some algorithms using salts (eg traditional Unix crypt) with the keys will
produce different hashed strings for the same value at different times so
some problems might arise.

Cheers,

Chris

Re: multi-valued userPassword attributes.

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

On Apr 8,  2:54pm, Chris Ridd wrote:
> Subject: Re: multi-valued userPassword attributes.
> Clif Harden <cl...@di...> wrote:
> >
> >
> > I have a question for the gurus of ldap.
> >
> > Does any one use multi-valued userPasswords?
> > If multi-valued userPasswords are used could
> > they have different encrption tags; {crypt}, {SHA}, etc.
>
> The only real contraint the standards impose is that all values of an
> attribute must compare different for equality.
>
> Since the use of hashed password values is somewhat non-standard (they are
> only loosely defined in an informational RFC) it is really something you
> will need to ask your vendor about.

What about RFC 3112?

Yes, asking the vendor, and then testing the heck out of their product.

>
> Off the top of my head there are two ways a server could implement hashed
> password values:
>
> 1) by using special syntax handlers which were aware of the hashing
> mechanisms
>
> 2) by doing simple textual comparisons on the values
>
> For case 1) since it is impossible to compare two values using different
> hashing schemes (eg {sha}1234 and {crypt}1234) unless you know the
> plaintext values it is *probable* that your server will say these are
> different values and hence permit one userPassword attribute to contain
> multiple differently-hashed values.
>
> In case 2) you can probably see it is going to work just fine, except that
> some algorithms using salts (eg traditional Unix crypt) with the keys will
> produce different hashed strings for the same value at different times so
> some problems might arise.
>
> Cheers,
>
> Chris
>
>-- End of excerpt from Chris Ridd



-- 

	
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 

Re: multi-valued userPassword attributes.

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

Rusty Biggs <rg...@di...> wrote:
> On Apr 8,  2:54pm, Chris Ridd wrote:
>> Subject: Re: multi-valued userPassword attributes.
>> Clif Harden <cl...@di...> wrote:
>> > 
>> > 
>> > I have a question for the gurus of ldap.
>> > 
>> > Does any one use multi-valued userPasswords?
>> > If multi-valued userPasswords are used could
>> > they have different encrption tags; {crypt}, {SHA}, etc.
>> 
>> The only real contraint the standards impose is that all values of an
>> attribute must compare different for equality.
>> 
>> Since the use of hashed password values is somewhat non-standard (they
>> are only loosely defined in an informational RFC) it is really something
>> you will need to ask your vendor about.
> 
> What about RFC 3112?

That describes a new attribute (authPassword) and syntaxes
(authPasswordMatch etc) though, and Clif was asking about userPassword.

> Yes, asking the vendor, and then testing the heck out of their product.

:-)

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...>]

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

[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...>]

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: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.