perl-ldap-dev

Re: User password changing

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

"Lambright, Linda (N-Averstar)" <lin...@lm...> wrote:
> I am trying to write a script to allow users to change their own passwords
> usingv Perl-ldap and the Netscape
> Directory Server.  Is it possible for users to change their own passwords
> using their own
> authentication or is it necessary to use the Directory Manager password in
> the background to make that change.
> 

That will depend entirely on the access controls set up by the directory
manager.

Cheers,

Chris

RE: User password changing

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

When I execute the code below I receive this error message, does anyone have
any ideas as to what's causing this?  I took this code almost completely out
of 
one of Graham Barr's emails.

usage: $fh->bind(NAME) or $fh->bind(PORT, ADDR) at ./perlpwchange line 6


#!/usr/local/bin/perl
use Net::LDAP;

$ldap = new Net::LDAP('122.197.44.555');

$ldap->bind (
               dn          => 'uid=kbosworth, ou=People, o=linda.lmco.com',
               password => 'oldpassword'
            ) || die $@;

 $ldap->modify ('uid=kbosworth,ou=People,o=linda.lmco.com',
                 replace=>{'userpassword'=> "newpassword"})
                 || "failed to edit entry. $!";

$ldap->unbind;


> ----------
> From: 	Lambright, Linda (N-Averstar)[SMTP:lin...@lm...]
> Sent: 	Wednesday, September 27, 2000 1:51 PM
> To: 	per...@li...
> Subject: 	User password changing
> 
> I am trying to write a script to allow users to change their own passwords
> usingv Perl-ldap and the Netscape
> Directory Server.  Is it possible for users to change their own passwords
> using their own
> authentication or is it necessary to use the Directory Manager password in
> the background to make that change.
> 

User password changing

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

I am trying to write a script to allow users to change their own passwords
usingv Perl-ldap and the Netscape
Directory Server.  Is it possible for users to change their own passwords
using their own
authentication or is it necessary to use the Directory Manager password in
the background to make that change.

Re: [Re: LDAP_REFERRAL return code]

[Mike M. <mmm...@ne...>]

Boy,  it's amazing how well everything works when you include all of the
symbols!  Thanks a bunch Graham!

I think I'll get back to banging my head on my desk now so I can get the old
brain cells going again.

Mike

Graham Barr <gb...@po...> wrote:
> perl -MNet::LDAP::Constant=LDAP_REFERRAL -e 'print LDAP_REFERRAL'
> 
> works fine for me. Did you import the symbol ?
> 
> Graham.
> 
> On Tue, Sep 26, 2000 at 03:31:55PM -0500, Mike Morris wrote:
> > I am unable to use the LDAP_REFERRAL constant inside my application.  I
am
> > able to refer to the numeric value successfully and my use of
LDAP_SUCCESS
> > appears to work fine.
> > 
> > For example, this works:
> > if ($mesg->code != LDAP_SUCCESS){
> >  $mesg->code == 10 ? &do_referral : print "Unable to modify
> > $dn\n".$mesg->error." Error Code(".$mesg->code.")\n";
> > }
> > 
> > But this doesn't: 
> > if ($mesg->code != LDAP_SUCCESS){
> >  $mesg->code == LDAP_REFERRAL ? &do_referral : print "Unable to modify
> > $dn\n".$mesg->error." Error Code(".$mesg->code.")\n";
> > }
> > 
> > 
> > Am I just an idiot, or is this a real problem?  BTW, I'm using v 0.20, so
if
> > it's fixed in a later release, please let me know.
> > 
> > Thanks,
> > 
> > Mike
> > 
> > ____________________________________________________________________
> > Get your own FREE, personal Netscape WebMail account today at
http://home.netscape.com/webmail


____________________________________________________________________
Get your own FREE, personal Netscape WebMail account today at http://home.netscape.com/webmail

Re: LDAP_REFERRAL return code

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

perl -MNet::LDAP::Constant=LDAP_REFERRAL -e 'print LDAP_REFERRAL'

works fine for me. Did you import the symbol ?

Graham.

On Tue, Sep 26, 2000 at 03:31:55PM -0500, Mike Morris wrote:
> I am unable to use the LDAP_REFERRAL constant inside my application.  I am
> able to refer to the numeric value successfully and my use of LDAP_SUCCESS
> appears to work fine.
> 
> For example, this works:
> if ($mesg->code != LDAP_SUCCESS){
>  $mesg->code == 10 ? &do_referral : print "Unable to modify
> $dn\n".$mesg->error." Error Code(".$mesg->code.")\n";
> }
> 
> But this doesn't: 
> if ($mesg->code != LDAP_SUCCESS){
>  $mesg->code == LDAP_REFERRAL ? &do_referral : print "Unable to modify
> $dn\n".$mesg->error." Error Code(".$mesg->code.")\n";
> }
> 
> 
> Am I just an idiot, or is this a real problem?  BTW, I'm using v 0.20, so if
> it's fixed in a later release, please let me know.
> 
> Thanks,
> 
> Mike
> 
> ____________________________________________________________________
> Get your own FREE, personal Netscape WebMail account today at http://home.netscape.com/webmail

LDAP_REFERRAL return code

[Mike M. <mmm...@ne...>]

I am unable to use the LDAP_REFERRAL constant inside my application.  I am
able to refer to the numeric value successfully and my use of LDAP_SUCCESS
appears to work fine.

For example, this works:
if ($mesg->code != LDAP_SUCCESS){
 $mesg->code == 10 ? &do_referral : print "Unable to modify
$dn\n".$mesg->error." Error Code(".$mesg->code.")\n";
}

But this doesn't: 
if ($mesg->code != LDAP_SUCCESS){
 $mesg->code == LDAP_REFERRAL ? &do_referral : print "Unable to modify
$dn\n".$mesg->error." Error Code(".$mesg->code.")\n";
}


Am I just an idiot, or is this a real problem?  BTW, I'm using v 0.20, so if
it's fixed in a later release, please let me know.

Thanks,

Mike

____________________________________________________________________
Get your own FREE, personal Netscape WebMail account today at http://home.netscape.com/webmail

RE: Message: LDAP_REFERRAL

[Jay Z. <jz...@ed...>]

Thank you all,
	 $mesg->referrals was exactly what I needed.. Couldn't find what the
new URL was.  I was already binding as version=>3.  Once more thank you for
the VERY VERY prompt reply and help.

Jay Zeemer

-----Original Message-----
From: Graham Barr [mailto:gb...@po...]
Sent: Tuesday, September 26, 2000 10:19 AM
To: Jay Zeemer
Cc: per...@li...
Subject: Re: Message: LDAP_REFERRAL


Can you show us some code.

When you get this code, you should be able to get a list
of URLs with  $mesg->referrals

Graham.

On Tue, Sep 26, 2000 at 09:56:28AM -0400, Jay Zeemer wrote:
> Salutations all,
> 	Great module does everything I have needed it to do so far.
> Although I am having a problem getting it to do one last thing.  I am
trying
> to query a customers ldap server and according to them the branch I need
to
> protected via a firewall.  I can feed an LDAP url into Netscape and see
the
> info, but when I query it using the perl module I get this error back: 
> 
> Return code: 10
> Message: LDAP_REFERRAL : The server is referring the client to another
> server. The response will contain a list of URL's MessageID: 2
> 
> but no new url.  Can anyone offer me information, urls, or a good prayer
;)
> 
> Thank you	
> 	Jay Zeemer

Re: Message: LDAP_REFERRAL

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

Jay Zeemer <jz...@ed...> wrote:
> Salutations all,
>	 Great module does everything I have needed it to do so far.
> Although I am having a problem getting it to do one last thing.  I am
> trying to query a customers ldap server and according to them the branch
> I need to protected via a firewall.  I can feed an LDAP url into Netscape
> and see the info, but when I query it using the perl module I get this
> error back: 
> 
> Return code: 10
> Message: LDAP_REFERRAL : The server is referring the client to another
> server. The response will contain a list of URL's MessageID: 2
> 
> but no new url.  Can anyone offer me information, urls, or a good prayer
> ;)
> 
> Thank you	
>	 Jay Zeemer

You have to bind using LDAPv3 (the default version is LDAPv2!) in order to
get legal referrals back. Netscape will still try to return referrals to
LDAPv2 clients, which might be confusing Net::LDAP. (This would be a
Netscape bug rather than a Net::LDAP bug IMHO.)

Check you are binding using LDAPv3.

If you are, then create the connection with debug set to 2 (or 8.) This
will dump out the packets returned from the server in hex (or
pretty-printed). This may help debugging the problem.

Cheers,

Chris

Re: Message: LDAP_REFERRAL

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

Can you show us some code.

When you get this code, you should be able to get a list
of URLs with  $mesg->referrals

Graham.

On Tue, Sep 26, 2000 at 09:56:28AM -0400, Jay Zeemer wrote:
> Salutations all,
> 	Great module does everything I have needed it to do so far.
> Although I am having a problem getting it to do one last thing.  I am trying
> to query a customers ldap server and according to them the branch I need to
> protected via a firewall.  I can feed an LDAP url into Netscape and see the
> info, but when I query it using the perl module I get this error back: 
> 
> Return code: 10
> Message: LDAP_REFERRAL : The server is referring the client to another
> server. The response will contain a list of URL's MessageID: 2
> 
> but no new url.  Can anyone offer me information, urls, or a good prayer ;)
> 
> Thank you	
> 	Jay Zeemer

Message: LDAP_REFERRAL

[Jay Z. <jz...@ed...>]

Salutations all,
	Great module does everything I have needed it to do so far.
Although I am having a problem getting it to do one last thing.  I am trying
to query a customers ldap server and according to them the branch I need to
protected via a firewall.  I can feed an LDAP url into Netscape and see the
info, but when I query it using the perl module I get this error back: 

Return code: 10
Message: LDAP_REFERRAL : The server is referring the client to another
server. The response will contain a list of URL's MessageID: 2

but no new url.  Can anyone offer me information, urls, or a good prayer ;)

Thank you	
	Jay Zeemer

Re: [Slightly OT] Checking access rights

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

Sim...@wi... wrote:
> 
> Hi all,
> 
>       This may not be strictly on topic but as I'm doing it with
>        Net::LDAP.......
> 
>       I am running Net::LDAP 0.19 on RedHat Linux 6.2 against a Novell
>        eDirectory for Linux.
> 
>       I am working on a self-service application to allow our users to
>       update their directory information via a web form.
> 
>       Some users have more rights than other users & what I want to do
>       check their rights when building the form and only give them
>        text-boxes for the attributes that they can change.
> 
>       Does anyone know how I can get either:
> 
>       a)  A list of attribute => access level pairs; or
> 
>       b)  Check an individual attribute right ?
> 
>       which I can then use to build the form.
> 
>       All guidance & URL's & leads greatly accepted !
> 
>       Regards,
> 
>       Simon Wilcox
>       Intranet Development Manager
>       Williams Lea Group
>       sim...@wi...

In general this is not possible.

DAP (the X.500 access protocol which LDAP is a lightweight version of) has
a feature called modifyRightsRequest (in the Read operation) which will
make the server return information about what may be changed in the entry.
This does not give information about what may be read, searched, compared,
etc, but nevertheless it is useful.

You could ask your vendor if they support access to this feature of DAP,
over LDAP. Since Novell has been known to claim their directory is X.500
compliant (cough) you might hope for a positive response :-)

Cheers,

Chris

[Slightly OT] Checking access rights

[<Sim...@wi...>]

Hi all,

      This may not be strictly on topic but as I'm doing it with
       Net::LDAP.......

      I am running Net::LDAP 0.19 on RedHat Linux 6.2 against a Novell
       eDirectory for Linux.

      I am working on a self-service application to allow our users to update
       their directory information via a web form.

      Some users have more rights than other users & what I want to do check
       their rights when building the form and only give them text-boxes for the
       attributes that they can change.

      Does anyone know how I can get either:

      a)  A list of attribute => access level pairs; or

      b)  Check an individual attribute right ?

      which I can then use to build the form.

      All guidance & URL's & leads greatly accepted !

      Regards,

      Simon Wilcox
      Intranet Development Manager
      Williams Lea Group
      sim...@wi...





______________________________________________________________________


   This email contains proprietary information some or all of which may be
   legally privileged.  It is for the intended recipient only. If an addressing
   or transmission error has misdirected this email, please notify the author by
   replying to this email. If you are not the intended recipient you must not
   use, disclose, distribute, copy, print, or reply on this email.

Re: [Fwd] Net::LDAP question

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

peter furmonavicius <pet...@ya...> wrote:
> At 8:36 AM +0100 9/22/00, Chris Ridd wrote:
>> Jim Harle <ha...@us...> wrote:
>>  > Peter, just use $ENV{'REMOTE_ADDR'} to get this.  --Jim Harle
>>> 
>> 
>> Right, but that doesn't do the second part of what Peter wanted - he
>> would appear to have access controls based on the client's network
>> address, and so wants the web server to proxy the LDAP connection to the
>> server making it *appear* that the connection is coming from the machine
>> the user is running their web browser on.
> 
> Hi.  First of all, thanks to everyone who took the time to write, I
> really appreciate it.
> 
> Chris speculated correctly.  I have ACLs that take care of 'direct' LDAP
> queries.  These ACLs are based upon the requesters IP addresss or DNS
> names.  This works fine except when we open up our LDAP directory to the
> 'world' through a WWW gateway.  Then it appears as if everyone is coming
> in locally since the LDAP directory server sees the IP address of the
> machine that the Perl cgi is running on.
> 
> Here is the 'solution' that I came up with, tell me what you think. I
> changed the ldap cgi gateway to check the $ENV{'REMOTE_ADDR'} variable.
> If it is an IP address 'local' to the Yale University domain, then I bind
> to the LDAP server with one "dn".  If the IP address is not 'local' to
> the Yale University domain, then I bind to the LDAP server with another
> different "dn".  Then I changed the LDAP server ACLs to account for
> permissions based upon the "dn" of the requestor.  This seems to work
> just fine.
> 
> Comments?
> -- 
> -------------------------------------------------------------------------
> -- Yale University                   Peter Furmonavicius
> Information Technology Services   Senior Research Programmer
> 175 Whitney Avenue                mailto:pet...@ya...
> P.O. Box 208276                   http://pantheon.yale.edu/~peter
> New Haven, CT  06520-8276         phone: 203.432.6691   fax: 203.432.9216

Sounds like a reasonable solution to me.

Cheers,

Chris

Re: [Fwd] Net::LDAP question

[peter f. <pet...@ya...>]

At 8:36 AM +0100 9/22/00, Chris Ridd wrote:
>Jim Harle <ha...@us...> wrote:
>  > Peter, just use $ENV{'REMOTE_ADDR'} to get this.  --Jim Harle
>>
>
>Right, but that doesn't do the second part of what Peter wanted - he would
>appear to have access controls based on the client's network address, and
>so wants the web server to proxy the LDAP connection to the server making
>it *appear* that the connection is coming from the machine the user is
>running their web browser on.

Hi.  First of all, thanks to everyone who took the time to write, I 
really appreciate it.

Chris speculated correctly.  I have ACLs that take care of 'direct' 
LDAP queries.  These ACLs are based upon the requesters IP addresss 
or DNS names.  This works fine except when we open up our LDAP 
directory to the 'world' through a WWW gateway.  Then it appears as 
if everyone is coming in locally since the LDAP directory server sees 
the IP address of the machine that the Perl cgi is running on.

Here is the 'solution' that I came up with, tell me what you think. 
I changed the ldap cgi gateway to check the $ENV{'REMOTE_ADDR'} 
variable.  If it is an IP address 'local' to the Yale University 
domain, then I bind to the LDAP server with one "dn".  If the IP 
address is not 'local' to the Yale University domain, then I bind to 
the LDAP server with another different "dn".  Then I changed the LDAP 
server ACLs to account for permissions based upon the "dn" of the 
requestor.  This seems to work just fine.

Comments?
-- 
---------------------------------------------------------------------------
Yale University                   Peter Furmonavicius
Information Technology Services   Senior Research Programmer
175 Whitney Avenue                mailto:pet...@ya...
P.O. Box 208276                   http://pantheon.yale.edu/~peter
New Haven, CT  06520-8276         phone: 203.432.6691   fax: 203.432.9216

Re: [Fwd] Net::LDAP question

[John B. <joh...@ne...>]

On Fri, 22 Sep 2000, Chris Ridd wrote:

> Jim Harle <ha...@us...> wrote:
> > Peter, just use $ENV{'REMOTE_ADDR'} to get this.  --Jim Harle
> > 
> 
> Right, but that doesn't do the second part of what Peter wanted - he would
> appear to have access controls based on the client's network address, and
> so wants the web server to proxy the LDAP connection to the server making
> it *appear* that the connection is coming from the machine the user is
> running their web browser on. 
> 
> I'm not sure that's really something that an application like Net::LDAP can
> do, it is more of a firewall/proxy thing. (Insert hand waving here.) There
> may be other perl modules you could involve to do this however.
> 
> I'm even less sure that it is a secure thing to do. Can't IP addresses be
> faked quite easily in HTTP requests? If so, you've just opened up your
> directory to the outside world.

Barring application-level authentication or fun things like IP source
routing (hopefully turned off on any routers between you and the outside
world), the remote IP address (as returned by 'getpeername') is probably
the most trustworthy piece of information an application has about who is
talking to it *for TCP*.

There are caveats here with regard to TCP sequence number attacks - but
the basic idea is that you trust your IP routing infrastructure to send
data back to that IP address - hence not to an attacker. You don't
necessarily trust the data that comes to you *from* that IP address.

Hence its OK to authenticate a search based on IP address - its a little
more dodgy to authenticate an add/modify/delete since the attacker may not
care about the result - they just want the effect of the operation.

The upshot of this is that I don't see how an application (perl) can spoof
the source IP address of a TCP connection. If you want to proxy privileges
I think you need application-level authentication - which LDAP is
fortunately quite well provided for.

regards,

jb

Re: [Fwd] Net::LDAP question

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

Jim Harle <ha...@us...> wrote:
> Peter, just use $ENV{'REMOTE_ADDR'} to get this.  --Jim Harle
> 

Right, but that doesn't do the second part of what Peter wanted - he would
appear to have access controls based on the client's network address, and
so wants the web server to proxy the LDAP connection to the server making
it *appear* that the connection is coming from the machine the user is
running their web browser on. 

I'm not sure that's really something that an application like Net::LDAP can
do, it is more of a firewall/proxy thing. (Insert hand waving here.) There
may be other perl modules you could involve to do this however.

I'm even less sure that it is a secure thing to do. Can't IP addresses be
faked quite easily in HTTP requests? If so, you've just opened up your
directory to the outside world.

> On Thu, 21 Sep 2000, Graham Barr wrote:
> 
>> ----- Forwarded message from peter furmonavicius
>> <pet...@ya...> -----
>> 
>> Date: Thu, 21 Sep 2000 11:35:16 -0400
>> To: Graham Barr <gb...@po...>
>> From: peter furmonavicius <pet...@ya...>
>> Subject: Net::LDAP question
>> 
>> Graham, great stuff.  I was using your code from within a cgi 
>> application.  Is there any way to pass to to the LDAP server the IP 
>> address of the cgi caller, as opposed to the ip address of the 
>> machine running the cgi application (so I could use the LDAP acl's I 
>> wrote that check for local vs. remote/off-site LDAP lookups)?  In any 
>> case, thanks again for putting together such a terrific Perl module 
>> (which I also use under MacPerl by the way).
>> -- 
>> ------------------------------------------------------------------------
>> --- Yale University                   Peter Furmonavicius
>> Information Technology Services   Senior Research Programmer
>> 175 Whitney Avenue                mailto:pet...@ya...
>> P.O. Box 208276                   http://pantheon.yale.edu/~peter
>> New Haven, CT  06520-8276         phone: 203.432.6691   fax: 203.432.9216
>> 
>> ----- End forwarded message -----
>> 
> 



Cheers,

Chris

Re: [Fwd] Net::LDAP question

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

Peter, just use $ENV{'REMOTE_ADDR'} to get this.  --Jim Harle


On Thu, 21 Sep 2000, Graham Barr wrote:

> ----- Forwarded message from peter furmonavicius <pet...@ya...> -----
> 
> Date: Thu, 21 Sep 2000 11:35:16 -0400
> To: Graham Barr <gb...@po...>
> From: peter furmonavicius <pet...@ya...>
> Subject: Net::LDAP question
> 
> Graham, great stuff.  I was using your code from within a cgi 
> application.  Is there any way to pass to to the LDAP server the IP 
> address of the cgi caller, as opposed to the ip address of the 
> machine running the cgi application (so I could use the LDAP acl's I 
> wrote that check for local vs. remote/off-site LDAP lookups)?  In any 
> case, thanks again for putting together such a terrific Perl module 
> (which I also use under MacPerl by the way).
> -- 
> ---------------------------------------------------------------------------
> Yale University                   Peter Furmonavicius
> Information Technology Services   Senior Research Programmer
> 175 Whitney Avenue                mailto:pet...@ya...
> P.O. Box 208276                   http://pantheon.yale.edu/~peter
> New Haven, CT  06520-8276         phone: 203.432.6691   fax: 203.432.9216
> 
> ----- End forwarded message -----
> 

[Fwd] Net::LDAP question

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

----- Forwarded message from peter furmonavicius <pet...@ya...> -----

Date: Thu, 21 Sep 2000 11:35:16 -0400
To: Graham Barr <gb...@po...>
From: peter furmonavicius <pet...@ya...>
Subject: Net::LDAP question

Graham, great stuff.  I was using your code from within a cgi 
application.  Is there any way to pass to to the LDAP server the IP 
address of the cgi caller, as opposed to the ip address of the 
machine running the cgi application (so I could use the LDAP acl's I 
wrote that check for local vs. remote/off-site LDAP lookups)?  In any 
case, thanks again for putting together such a terrific Perl module 
(which I also use under MacPerl by the way).
-- 
---------------------------------------------------------------------------
Yale University                   Peter Furmonavicius
Information Technology Services   Senior Research Programmer
175 Whitney Avenue                mailto:pet...@ya...
P.O. Box 208276                   http://pantheon.yale.edu/~peter
New Haven, CT  06520-8276         phone: 203.432.6691   fax: 203.432.9216

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

Re: (no subject)

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

Sure this could be added, it's just a case of someone writing a Net::LDAP::Control::ProxyAuth
module to support it.

But in the meantime you can do it the hard way. Not this will only
work for DN's that are less than 125 characters in length

  $ldap->search( ... 
    control => [
      {
        type => "2.16.840.1.113730.3.4.12,",
        value => pack("CCCCA*",0x30,2+length($dn),4,length($dn),$dn),
        critical => $critical
      }
   );

Graham.

On Wed, Sep 20, 2000 at 07:30:27PM +0200, Alexander.Jung1 wrote:
> Hello,
> 
> first a great thank you for the perl-ldap library, we're building a 
> quite nice Organigramm-Application on top of it.
> 
> In this application we hit a problem:
> In order to change his own entry a user has to be authenticated to the
> directory. We use Challenge/Response to get the users NT-Login,
> which has exactly the same uid as stored in our directory. 
> That far things work nicely, but we only get the username, not the
> password from the IIS-webserver, so we have a problem to authenticate
> in our script on behalf of the user asking.
> I found in Netscape's documentation a "proxy authentication" which would
> just do what we need: The perlscript would authenticate as script-user, but
> proxy for the real user and thus expierencing the ACLs that real user has.
> But I could not find any reference to proxied authentication in the perl-ldap
> documentation. The only meaningful reference I found is here:
> http://home.netscape.com/eng/server/directory/4.1/technotes/proxyauth.html
> 
> Could this option to bind be implemented somehow? It would fix an ugly
> kludge we are using right now.
> 
> Thanks in advance,
> 
> Alexander

Re: (no subject)

[Mark W. <mew...@un...>]

to do this you have to implement the Proxy Authorization control in
Net::LDAP.

Mark

On Wed, 20 Sep 2000, Alexander.Jung1 wrote:

> Hello,
> 
> first a great thank you for the perl-ldap library, we're building a 
> quite nice Organigramm-Application on top of it.
> 
> In this application we hit a problem:
> In order to change his own entry a user has to be authenticated to the
> directory. We use Challenge/Response to get the users NT-Login,
> which has exactly the same uid as stored in our directory. 
> That far things work nicely, but we only get the username, not the
> password from the IIS-webserver, so we have a problem to authenticate
> in our script on behalf of the user asking.
> I found in Netscape's documentation a "proxy authentication" which would
> just do what we need: The perlscript would authenticate as script-user, but
> proxy for the real user and thus expierencing the ACLs that real user has.
> But I could not find any reference to proxied authentication in the perl-ldap
> documentation. The only meaningful reference I found is here:
> http://home.netscape.com/eng/server/directory/4.1/technotes/proxyauth.html
> 
> Could this option to bind be implemented somehow? It would fix an ugly
> kludge we are using right now.
> 
> Thanks in advance,
> 
> Alexander
> 

(no subject)

[Alexander.Jung1 <Ale...@Al...>]

Hello,

first a great thank you for the perl-ldap library, we're building a 
quite nice Organigramm-Application on top of it.

In this application we hit a problem:
In order to change his own entry a user has to be authenticated to the
directory. We use Challenge/Response to get the users NT-Login,
which has exactly the same uid as stored in our directory. 
That far things work nicely, but we only get the username, not the
password from the IIS-webserver, so we have a problem to authenticate
in our script on behalf of the user asking.
I found in Netscape's documentation a "proxy authentication" which would
just do what we need: The perlscript would authenticate as script-user, but
proxy for the real user and thus expierencing the ACLs that real user has.
But I could not find any reference to proxied authentication in the perl-ldap
documentation. The only meaningful reference I found is here:
http://home.netscape.com/eng/server/directory/4.1/technotes/proxyauth.html

Could this option to bind be implemented somehow? It would fix an ugly
kludge we are using right now.

Thanks in advance,

Alexander

Re: Copying an entry

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

Well  cannot duplicate it. I have just tried


$mesg = $ldap->search(base => $BASEDN,
                      filter => '(&(sn=jensen)(cn=Barbara*))',
                      callback => sub {
                        return unless $_[1];
                        my $newentry = $_[1];
                        my $dn = $newentry->dn;

                        $dn =~ s/=/=xx/;
                        $newentry->dn($dn);

                        print "attempting to add entry ",$newentry->dn,"\n";
                        $mesg = $ldap->add($newentry);
                        print "returned ", $mesg->code,"\n";
                      });

And the first time I got

$ perl -Ilib dummy
attempting to add entry cn=xxBarbara Jensen, ou=Information Technology Division, ou=People, o=University of Michigan, c=US
returned 0

The next time I got

perl -Ilib dummy
attempting to add entry cn=xxBarbara Jensen, ou=Information Technology Division, ou=People, o=University of Michigan, c=US
attempting to add entry cn=xxxxBarbara Jensen, ou=Information Technology Division, ou=People, o=University of Michigan, c=US
returned 0
returned 68

Now the order of the output may seem strange, but it is correct.

Graham.

On Wed, Sep 20, 2000 at 08:44:41AM -0400, Jim Harle wrote:
> I haven't yet gotten any nibbles on this.  I will add some clarification
> and a line of code.  The 3 lines :
>   print "attempting to add entry ",$newentry->dn,"\n" if $testing;
>   $mesg = $ldap->add($newentry);
>   print "returned ", $mesg->code,"\n";
> result in "attempting to add" being printed twice with no "returned'.  If
> I run with perl -d and put breakpoints at the two prints above, the second
> one is never caught and after the second, it loops so tightly that I can't
> even use Ctl-C to get out.  Any ideas?
> 
>   --Jim Harle
> 
> 
> On Tue, 19 Sep 2000, Jim Harle wrote:
> 
> > I'm attempting to move an entry to another container via copy and delete
> > since my server (Novell NDS eDirectory) apparently won't allow a moddn to
> > a different one.  I am using perl-ldap-0.19 and perl 5.005_03 on one
> > Solaris system and perl-ldap-0.22 on another. Strange things are happening
> > with both versions.  In executing the code below, which is a callback from
> > a search, it prints the "attempting to add" message for both things found
> > in the search, but never prints either "Add fail" or "attempting to
> > delete", which seems like an impossibility.  It goes into some sort of
> > catatonic state after printing the 2 "attempting to add" messages.  It
> > also neither adds nor deletes.
> > 
> > Any ideas of what I should try?
> > 
> > Here is the code I am using:
> > 
> > sub process_entry {
> > # execute this once for each entry found in searchldap
> >   my $uid;
> >   my ( $search, $entry ) = @_ ;
> >   return unless $search;
> >   return unless $entry;
> >   $dn = $entry->dn;                 # get the dn for this one;
> > #set the dn for the corresponding disabled place
> >   my $newdn = $dn;
> >   $dn =~ /^\w+\=(\w+)/;             # the first thing in the dn is what we
> > want
> >   $uid = $1;                        # the uid
> >   $newdn =~ s/o\s*\=\s*usna/ou\=usna\,o\=disabled/i; 
> >   my $newentry = Net::LDAP::Entry->new;
> >   $newentry = $entry;
> >   $newentry->dn($newdn);
> >   print "attempting to add entry ",$newentry->dn,"\n" if $testing;
> >   $mesg = $ldap->add($newentry);
> >   if ($mesg->code) {
> >     print "Add fail for $newdn\n  ",
> >            Net::LDAP::Util::ldap_error_name($mesg->code), "\n" if
> > $testing;
> >     print ERROR "Add fail for $newdn\n  ",
> >            Net::LDAP::Util::ldap_error_name($mesg->code), "\n";
> >   } else {
> >     print "attempting to delete $dn\n" if $testing;
> >     $mesg = $ldap->delete($dn); #delete old entry
> >     print LOG "moved to $newdn\n";
> >     if ($mesg->code) {
> >       print "Delete fail for $dn\n  ",
> >            Net::LDAP::Util::ldap_error_name($mesg->code), "\n" if
> > $testing;
> >       print ERROR "Delete fail for $dn\n  ",
> >            Net::LDAP::Util::ldap_error_name($mesg->code), "\n";
> >     } else {
> >       if ($testing) {
> >          print "would have sent deluser for $uid\n";
> >       } else {
> >         system "senddeluser $uid";
> >       }
> >     }
> >   }
> >   $search->pop_entry;
> > }
> > 
> > 
> > --Jim Harle
> > 
> > 
> > 
> 
> 

Re: Copying an entry

[Mark W. <mew...@un...>]

Have you sent Graham a dump of debug(3)?

Mark


On Wed, 20 Sep 2000, Jim Harle wrote:

> I haven't yet gotten any nibbles on this.  I will add some clarification
> and a line of code.  The 3 lines :
>   print "attempting to add entry ",$newentry->dn,"\n" if $testing;
>   $mesg = $ldap->add($newentry);
>   print "returned ", $mesg->code,"\n";
> result in "attempting to add" being printed twice with no "returned'.  If
> I run with perl -d and put breakpoints at the two prints above, the second
> one is never caught and after the second, it loops so tightly that I can't
> even use Ctl-C to get out.  Any ideas?
> 
>   --Jim Harle
> 
> 
> On Tue, 19 Sep 2000, Jim Harle wrote:
> 
> > I'm attempting to move an entry to another container via copy and delete
> > since my server (Novell NDS eDirectory) apparently won't allow a moddn to
> > a different one.  I am using perl-ldap-0.19 and perl 5.005_03 on one
> > Solaris system and perl-ldap-0.22 on another. Strange things are happening
> > with both versions.  In executing the code below, which is a callback from
> > a search, it prints the "attempting to add" message for both things found
> > in the search, but never prints either "Add fail" or "attempting to
> > delete", which seems like an impossibility.  It goes into some sort of
> > catatonic state after printing the 2 "attempting to add" messages.  It
> > also neither adds nor deletes.
> > 
> > Any ideas of what I should try?
> > 
> > Here is the code I am using:
> > 
> > sub process_entry {
> > # execute this once for each entry found in searchldap
> >   my $uid;
> >   my ( $search, $entry ) = @_ ;
> >   return unless $search;
> >   return unless $entry;
> >   $dn = $entry->dn;                 # get the dn for this one;
> > #set the dn for the corresponding disabled place
> >   my $newdn = $dn;
> >   $dn =~ /^\w+\=(\w+)/;             # the first thing in the dn is what we
> > want
> >   $uid = $1;                        # the uid
> >   $newdn =~ s/o\s*\=\s*usna/ou\=usna\,o\=disabled/i; 
> >   my $newentry = Net::LDAP::Entry->new;
> >   $newentry = $entry;
> >   $newentry->dn($newdn);
> >   print "attempting to add entry ",$newentry->dn,"\n" if $testing;
> >   $mesg = $ldap->add($newentry);
> >   if ($mesg->code) {
> >     print "Add fail for $newdn\n  ",
> >            Net::LDAP::Util::ldap_error_name($mesg->code), "\n" if
> > $testing;
> >     print ERROR "Add fail for $newdn\n  ",
> >            Net::LDAP::Util::ldap_error_name($mesg->code), "\n";
> >   } else {
> >     print "attempting to delete $dn\n" if $testing;
> >     $mesg = $ldap->delete($dn); #delete old entry
> >     print LOG "moved to $newdn\n";
> >     if ($mesg->code) {
> >       print "Delete fail for $dn\n  ",
> >            Net::LDAP::Util::ldap_error_name($mesg->code), "\n" if
> > $testing;
> >       print ERROR "Delete fail for $dn\n  ",
> >            Net::LDAP::Util::ldap_error_name($mesg->code), "\n";
> >     } else {
> >       if ($testing) {
> >          print "would have sent deluser for $uid\n";
> >       } else {
> >         system "senddeluser $uid";
> >       }
> >     }
> >   }
> >   $search->pop_entry;
> > }
> > 
> > 
> > --Jim Harle
> > 
> > 
> > 
> 
> 
> 

Re: Access Control

[Mark W. <mew...@un...>]

It depends upon the LDAP server. For example the IPlanet directory server
the access controls are stored as attributes in the directory. Many other
servers require you to update the server access controls are stored
outside of the directory.

Mark

On Wed, 20 Sep 2000, spencer wrote:

> Hi,
> Does anyonne know if perl-ldap has any function call which allows for
> manipulation of Access Control of directory tree? I don't remember seeing
> this topic being discussed before. Please kindly point out.
> 
> Many thanks.
> 
> spencer
> 
> 

Re: Copying an entry

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

I haven't yet gotten any nibbles on this.  I will add some clarification
and a line of code.  The 3 lines :
  print "attempting to add entry ",$newentry->dn,"\n" if $testing;
  $mesg = $ldap->add($newentry);
  print "returned ", $mesg->code,"\n";
result in "attempting to add" being printed twice with no "returned'.  If
I run with perl -d and put breakpoints at the two prints above, the second
one is never caught and after the second, it loops so tightly that I can't
even use Ctl-C to get out.  Any ideas?

  --Jim Harle


On Tue, 19 Sep 2000, Jim Harle wrote:

> I'm attempting to move an entry to another container via copy and delete
> since my server (Novell NDS eDirectory) apparently won't allow a moddn to
> a different one.  I am using perl-ldap-0.19 and perl 5.005_03 on one
> Solaris system and perl-ldap-0.22 on another. Strange things are happening
> with both versions.  In executing the code below, which is a callback from
> a search, it prints the "attempting to add" message for both things found
> in the search, but never prints either "Add fail" or "attempting to
> delete", which seems like an impossibility.  It goes into some sort of
> catatonic state after printing the 2 "attempting to add" messages.  It
> also neither adds nor deletes.
> 
> Any ideas of what I should try?
> 
> Here is the code I am using:
> 
> sub process_entry {
> # execute this once for each entry found in searchldap
>   my $uid;
>   my ( $search, $entry ) = @_ ;
>   return unless $search;
>   return unless $entry;
>   $dn = $entry->dn;                 # get the dn for this one;
> #set the dn for the corresponding disabled place
>   my $newdn = $dn;
>   $dn =~ /^\w+\=(\w+)/;             # the first thing in the dn is what we
> want
>   $uid = $1;                        # the uid
>   $newdn =~ s/o\s*\=\s*usna/ou\=usna\,o\=disabled/i; 
>   my $newentry = Net::LDAP::Entry->new;
>   $newentry = $entry;
>   $newentry->dn($newdn);
>   print "attempting to add entry ",$newentry->dn,"\n" if $testing;
>   $mesg = $ldap->add($newentry);
>   if ($mesg->code) {
>     print "Add fail for $newdn\n  ",
>            Net::LDAP::Util::ldap_error_name($mesg->code), "\n" if
> $testing;
>     print ERROR "Add fail for $newdn\n  ",
>            Net::LDAP::Util::ldap_error_name($mesg->code), "\n";
>   } else {
>     print "attempting to delete $dn\n" if $testing;
>     $mesg = $ldap->delete($dn); #delete old entry
>     print LOG "moved to $newdn\n";
>     if ($mesg->code) {
>       print "Delete fail for $dn\n  ",
>            Net::LDAP::Util::ldap_error_name($mesg->code), "\n" if
> $testing;
>       print ERROR "Delete fail for $dn\n  ",
>            Net::LDAP::Util::ldap_error_name($mesg->code), "\n";
>     } else {
>       if ($testing) {
>          print "would have sent deluser for $uid\n";
>       } else {
>         system "senddeluser $uid";
>       }
>     }
>   }
>   $search->pop_entry;
> }
> 
> 
> --Jim Harle
> 
> 
>