perl-ldap-dev

RE: LDIF.pm and schemaUpdateNow

[Robbie A. <ra...@ci...>]

> -----Original Message-----
> From: Chris Ridd [mailto:chr...@me...]
> Sent: Friday, April 06, 2001 8:58 AM
> To: Robbie Allen
> Cc: per...@li...
> Subject: Re: LDIF.pm and schemaUpdateNow
> 
> 
> Robbie Allen <ra...@ci...> wrote:
> > Active Directory's schema cache may be updated by setting the
> > operational attribute 'schemaUpdateNow' to 1.  This is 
> typically done in
> > LDIF files that modify the schema in which a reference 
> needs to be made
> > to a class or attribute that was created in the same LDIF 
> file.  If the
> > schema cache isn't updated, the server may reject the change.
> > 
> > More information is available here:
> > http://msdn.microsoft.com/library/psdk/adsi/glschemex_378l.htm
> > 
> > It looks like this in an LDIF file:
> > 
> > dn:
> > changetype: modify
> > add: schemaUpdateNow
> > schemaUpdateNow: 1
> > -
> 
> That's OK, because I think that your change record is 
> affecting the root DSE, which has a DN of "".

That's correct.


> > Turns out that Net::LDAP::LDIF doesn't like this very much. 
>  It expects something after the dn.  The following change would fix 
> this issue, but
> > I was curious if it might break something else.  The entry object
> > created will not have a distinguishedname attribute, but 
> everything else seems to work fine.
> 
> A minor quibble: the "dn" line does not indicate an attribute called
> distinguishedName, but actually the DN of the entry being 
> modified. (The DN of an entry is not held in an attribute of the
entry.)

Actually it is in Active Directory.  It is called distinguishedName.


> > LDIF.pm
> > 73c73
> > <   return unless @ldif > 1 && $ldif[0] =~ s/^dn:(:?) //;
> > ---
> >>   return unless @ldif > 1 && $ldif[0] =~ s/^dn:(:?)( ?)//;
> > 
> > Robbie Allen
> > 
> 
> A slightly better change would be:
> 
>     return unless @ldif > 1 && $ldif[0] =~ s/^dn:(:?) *//;
> 
> because the LDIF ABNF says the dn line is this:
> 
> dn-spec = "dn:" (FILL distinguishedName /
>                  ":" FILL base64-distinguishedName)
> 
> FILL    = *SPACE
> 

That's fine.  What does it take to get this change incorporated into
LDIF.pm?

Robbie Allen

AuthNetLDAP + AuthUserFile?

[Eamon D. <ea...@fa...>]

Am I completely off my rocker or did I not once have a Location
protected so that I could auth against a htpasswd file if the LDAP
auth failed? I can't find a single trace of my old httpd.conf, but
I /swear/ I had it working at some point. Has anyone else done
this?

<Location />
AuthName "Internal"
AuthType Basic
AuthUserFile conf/htpasswd.list

PerlAuthenHandler Apache::AuthNetLDAP
PerlSetVar LDAPServer xxx.xxx.xxx.xxx
PerlSetVar LDAPPort 389
PerlSetVar BaseDN "ou=xxxxx,ou=xxxxx,o=xxxxx"
PerlSetVar UIDAttr cn

order deny,allow
deny from all
allow from 10.
allow from 127.0.0.1
require user guest_pass
require valid-user
satisfy any
</Location>

That results in:

[Fri Apr  6 17:24:51 2001] [error] access to /internal/ failed for
216.17.138.248, reason: user guest_pass: user entry not found for filter:
cn=xxxxx

and a 401 error. Am I out of my mind?

______________________________
Eamon Daly
FastWeb, Inc.
847 568 6410

RE: LDIF.pm and schemaUpdateNow

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

Robbie Allen <ra...@ci...> wrote:
>> -----Original Message-----
>> From: Chris Ridd [mailto:chr...@me...]
>> A minor quibble: the "dn" line does not indicate an attribute called
>> distinguishedName, but actually the DN of the entry being 
>> modified. (The DN of an entry is not held in an attribute of the
> entry.)
> 
> Actually it is in Active Directory.  It is called distinguishedName.

Ugh.

> That's fine.  What does it take to get this change incorporated into
> LDIF.pm?

Get one of the the maintainer's (Graham, Clif, Mark, me) attention, and if
no-one objects to the change, they will integrate it. 

It looks a harmless enough change to integrate; I've gone ahead and done it.

> Robbie Allen

Thanks for the original bug-fix.

Cheers,

Chris