Menu
▾
▴
perl-ldap-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(200) |
Jun
(129) |
Jul
(184) |
Aug
(204) |
Sep
(106) |
Oct
(79) |
Nov
(72) |
Dec
(54) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(83) |
Feb
(123) |
Mar
(84) |
Apr
(184) |
May
(106) |
Jun
(111) |
Jul
(104) |
Aug
(91) |
Sep
(59) |
Oct
(99) |
Nov
(100) |
Dec
(37) |
| 2002 |
Jan
(148) |
Feb
(88) |
Mar
(85) |
Apr
(151) |
May
(80) |
Jun
(110) |
Jul
(85) |
Aug
(43) |
Sep
(64) |
Oct
(89) |
Nov
(59) |
Dec
(42) |
| 2003 |
Jan
(129) |
Feb
(104) |
Mar
(162) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ewa S. <Ewa...@un...> - 2002-05-09 14:10:48
|
Hello, Can anyone tell me how to setup perl-LDAP script to use TLS/SSL connection? Since a few days I'm trying to start TLS connection in my perl-ldap scripts but without success. I use start_tls function like this ldap->start_tls(verify => "none", sslversion => "sslv3"); First I won't to verify client certificates. I use openldap 2.0.23 and start slapd on default 389 port (non-secure). In slapd.conf file I set TLSCertificateKeyFile /usr/local/openldap2/etc/openldap/server.key TLSCertificateFile /usr/local/openldap2/etc/openldap/server.crt When I use openldap's function ldapsearch with -Z option I have correct TLS/SSL connection and get correct search result, but when I run my perl-ldap script I get following error: ldap_start_tls: Error 1: Operations error. In slapd's log I have lines: TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data tls_read: want=5 error=Resource temporarily unavailable TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL3 alert read:fatal:bad certificate TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept. TLS: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate s3_pkt.c:985 connection_read(9): TLS accept error error=-1 id=28, closing I try to use LDAPS instead LDAP/start_tls but also without success. Does anyone have any suggestions? Ewa -- Ewa Skrenty Information & Communication Technology Centre Nicholas Copernicus University Chopina 12/18, 87-100 Torun, Poland |
|
From: Graham B. <gb...@po...> - 2002-05-08 16:59:33
|
You can add user => sub { '' } into the argument to SASL->new
This is unfortunate historic mistake that should be deprecated
Graham.
On Wed, May 08, 2002 at 09:25:00AM -0700, Kurt D. Zeilenga wrote:
> At 08:30 AM 2002-05-08, Norbert Klasen wrote:
>
>
> >--On Dienstag, 7. Mai 2002 13:38 +0100 Graham Barr <gb...@po...> wrote:
> >
> >>The reason it was using user, was for compatability with previous SASL
> >>implementation.
> >
> >How am I supposed to call Authen::SASL->new and Net::LDAP->bind if I don't want to do proxy auth (ie. not specify an authorization identity with the user callback)?
> >
> >I'm asking this because in Net/LDAP.pm line 242 "user" defaults to
> >'dn: <DN>', where <DN> is the first parameter to NET::LDAP::bind():
> > # Tell the SASL object our user identifier
> > $sasl->callback( user => "dn: $stash{name}")
> > unless $sasl->callback('user');
>
> that's bad. The bind name, SASL authentication identity
> (where applicable), and SASL authorization identity (where
> applicable and desired) should be provided separately
> by the application. It is inappropriate for the API to
> assume any particular relationship between them.
>
> I note as well, that "dn: cn=foo" is an invalid LDAP
> authzid. There should be no space after the ":".
>
> >BTW how is a server to respond, if it receives different authCids in the name and credentials component of a bind request?
>
> Generally speaking, when SASL is being used, the clients should
> not provide a bind name and server should ignore the bind name
> if present. RFC 2829 wasn't exactly clear on this, but the
> LDAPbis revised specification (a work in progress) should be.
>
|
|
From: Kurt D. Z. <Ku...@Op...> - 2002-05-08 16:25:12
|
At 08:30 AM 2002-05-08, Norbert Klasen wrote:
>--On Dienstag, 7. Mai 2002 13:38 +0100 Graham Barr <gb...@po...> wrote:
>
>>The reason it was using user, was for compatability with previous SASL
>>implementation.
>
>How am I supposed to call Authen::SASL->new and Net::LDAP->bind if I don't want to do proxy auth (ie. not specify an authorization identity with the user callback)?
>
>I'm asking this because in Net/LDAP.pm line 242 "user" defaults to
>'dn: <DN>', where <DN> is the first parameter to NET::LDAP::bind():
> # Tell the SASL object our user identifier
> $sasl->callback( user => "dn: $stash{name}")
> unless $sasl->callback('user');
that's bad. The bind name, SASL authentication identity
(where applicable), and SASL authorization identity (where
applicable and desired) should be provided separately
by the application. It is inappropriate for the API to
assume any particular relationship between them.
I note as well, that "dn: cn=foo" is an invalid LDAP
authzid. There should be no space after the ":".
>BTW how is a server to respond, if it receives different authCids in the name and credentials component of a bind request?
Generally speaking, when SASL is being used, the clients should
not provide a bind name and server should ignore the bind name
if present. RFC 2829 wasn't exactly clear on this, but the
LDAPbis revised specification (a work in progress) should be.
|
|
From: Norbert K. <nor...@da...> - 2002-05-08 15:32:21
|
--On Dienstag, 7. Mai 2002 13:38 +0100 Graham Barr <gb...@po...> wrote:
> The reason it was using user, was for compatability with previous SASL
> implementation.
How am I supposed to call Authen::SASL->new and Net::LDAP->bind if I don't=20
want to do proxy auth (ie. not specify an authorization identity with the=20
user callback)?
I'm asking this because in Net/LDAP.pm line 242 "user" defaults to
'dn: <DN>', where <DN> is the first parameter to NET::LDAP::bind():
# Tell the SASL object our user identifier
$sasl->callback( user =3D> "dn: $stash{name}")
unless $sasl->callback('user');
So without an explicit "user" callback, perl-ldap will emit the following=20
bind request:
30 1c 02 01 01 60 17 02 01 03 04 00 a3 10 04 08 0....`..........
45 58 54 45 52 4e 41 4c 04 04 64 6e 3a 20 EXTERNAL..dn:
Similar for PLAIN:
30 2a 02 01 01 60 25 02 01 03 04 00 a3 1e 04 05 0*...`%.........
50 4c 41 49 4e 04 15 64 6e 3a 20 00 63 6e 3d 61 PLAIN..dn: .cn=3Da
75 74 68 63 32 00 73 65 63 72 65 74 uthc2.secret
I think the default callback for user should only be set, if $stash{name}=20
actually contains a value:
# Tell the SASL object our user identifier
$sasl->callback( user =3D> "dn: $stash{name}")
unless $sasl->callback('user') || !$stash{name}
This would allow
my $sasl =3D Authen::SASL->new( mechanism =3D> 'EXTERNAL' );
and
$mesg =3D $ldap->bind( '', sasl =3D> $sasl );
or
$mesg =3D $ldap->bind( $proxydn, sasl =3D> $sasl );
BTW how is a server to respond, if it receives different authCids in the=20
name and credentials component of a bind request? With the following code,=20
perl-ldap will emit such a request.
my $sasl =3D Authen::SASL->new(
mechanism =3D> 'PLAIN',
callback =3D> {
pass =3D> 'secret',
user =3D> 'cn=3Dauthz',
authname =3D> 'cn=3Dauthc2',
}
);
$mesg =3D $ldap->bind( 'cn=3Dauthc1', sasl =3D> $sasl );
30 37 02 01 01 60 32 02 01 03 04 09 63 6e 3d 61 07...`2.....cn=3Da
75 74 68 63 31 a3 22 04 05 50 4c 41 49 4e 04 19 uthc1."..PLAIN..
63 6e 3d 61 75 74 68 7a 00 63 6e 3d 61 75 74 68 cn=3Dauthz.cn=3Dauth
63 32 00 73 65 63 72 65 74 c2.secret
--=20
Dipl.-Inform. Norbert Klasen
DAASI International GmbH phone: +49 7071 29 70336
Wilhelmstr. 106 fax: +49 7071 29 5114
72074 T=FCbingen email: nor...@da...
Germany web: http://www.daasi.de
|
|
From: Norbert K. <nor...@da...> - 2002-05-08 07:33:52
|
--On Dienstag, 7. Mai 2002 10:42 -0700 "Kurt D. Zeilenga"=20 <Ku...@Op...> wrote: >> Hi, >> RFC2222 says that in the EXTERNAL mechanism "The client sends an initial >> response with the authorization identity." > > It also says: > If the client sends the empty string as the authorization identity... > > Unless the client is attempting proxy authorization, the client > should send an empty string. This has been discussed in great > detail on the iet...@im... mailing list. Seems I mixed up the terminology. Just to be sure: authname =3D authENTICATION identity user =3D authORIZATION identity Correct? Nevertheless, the EXTERNAL mechanism has only one round trip so that the=20 authorize-id needs to be send in client_start. client_step will never get=20 called and can be removed. Also, the noanonymous flag can be set. See=20 attached patch. --=20 Dipl.-Inform. Norbert Klasen DAASI International GmbH phone: +49 7071 29 70336 Wilhelmstr. 106 fax: +49 7071 29 5114 72074 T=FCbingen email: nor...@da... Germany web: http://www.daasi.de |
|
From: Jim H. <ha...@us...> - 2002-05-07 20:26:38
|
Do you want to delete it from the LDAP server or from the current entry.
To delete it from the server use
$ldap->modify ($dn, delete => {$attribute => $attval});
To delete it just from an entry then your method seems to be quite
reasonable.
On Tue, 7 May 2002, Joseph Kezar wrote:
> I have a strange request. An abbreviated entry looks like this
>
> ________________________
> cn: Joe Smith
> mail: js...@do...
> memberOfGroup: cn=All Staff,ou=Groups,o=Vermont Department of Corrections,c=US
> memberOfGroup: cn=MIS,ou=Groups,o=Vermont Department of Corrections,c=US
> memberOfGroup: cn=Security,ou=Groups,o=Vermont Department of Corrections,c=US
> memberOfGroup: cn=Root,ou=Groups,o=Vermont Department of Corrections,c=US
> _________________________
>
> What I want to do is remove a single memberOfGroup attribute(eg cn=Root). I don't think what I am looking for is $entry->delete('memberOfGroup') as this will erase all of my attributes called memberOfGroup.
>
> Is there a method I am missing to aid me in removing a very precise attribute. Or do I need to script it by hand liek this?:
>
> @memberships = $entry->get_value('memberOfGroup');
> $entry->delete('memberOfGroup');
> foreach (@memberships) {
> $entry->add(memberOfGroup=>"$_") if ($_ ne "cn=Root,ou=Groups,o=Vermont Department of Corrections,c=US");
> }
>
> Is this the most efficient way?
>
|
|
From: Joseph K. <jk...@do...> - 2002-05-07 19:53:43
|
I have a strange request. An abbreviated entry looks like this
________________________
cn: Joe Smith
mail: js...@do...
memberOfGroup: cn=3DAll Staff,ou=3DGroups,o=3DVermont Department of =
Corrections,c=3DUS
memberOfGroup: cn=3DMIS,ou=3DGroups,o=3DVermont Department of =
Corrections,c=3DUS
memberOfGroup: cn=3DSecurity,ou=3DGroups,o=3DVermont Department of =
Corrections,c=3DUS
memberOfGroup: cn=3DRoot,ou=3DGroups,o=3DVermont Department of =
Corrections,c=3DUS
_________________________
What I want to do is remove a single memberOfGroup attribute(eg =
cn=3DRoot). I don't think what I am looking for is =
$entry->delete('memberOfGroup') as this will erase all of my attributes =
called memberOfGroup.
Is there a method I am missing to aid me in removing a very precise =
attribute. Or do I need to script it by hand liek this?:
@memberships =3D $entry->get_value('memberOfGroup');
$entry->delete('memberOfGroup');
foreach (@memberships) {
$entry->add(memberOfGroup=3D>"$_") if ($_ ne =
"cn=3DRoot,ou=3DGroups,o=3DVermont Department of Corrections,c=3DUS");
}
Is this the most efficient way?
|
|
From: Kurt D. Z. <Ku...@Op...> - 2002-05-07 17:42:20
|
At 02:36 AM 2002-05-07, Norbert Klasen wrote: >Hi, >RFC2222 says that in the EXTERNAL mechanism "The client sends an initial response with the authorization identity." It also says: If the client sends the empty string as the authorization identity... Unless the client is attempting proxy authorization, the client should send an empty string. This has been discussed in great detail on the iet...@im... mailing list. Kurt |
|
From: Chris R. <chr...@me...> - 2002-05-07 14:02:02
|
Graham Barr <gb...@po...> wrote: > On Tue, May 07, 2002 at 11:36:04AM +0200, Norbert Klasen wrote: >> Hi, >> RFC2222 says that in the EXTERNAL mechanism "The client sends an initial >> response with the authorization identity." The attached patch does this. >> An authorization identity can be set with the 'authname' callback. > > Have you tried this, as it does not look right to me, But Chris could > confirm as he wrote the original. You have changed this from sending > the auth as a response to sending it with the initial request. > > The reason it was using user, was for compatability with previous SASL > implementation. Yup, that's the exact reason I did the original version that way. I had one report that it worked correctly... Cheers, Chris |
|
From: Norbert K. <nor...@da...> - 2002-05-07 13:45:35
|
--On Dienstag, 7. Mai 2002 13:38 +0100 Graham Barr <gb...@po...> wrote: >> RFC2222 says that in the EXTERNAL mechanism "The client sends an initial >> response with the authorization identity." The attached patch does this. >> An authorization identity can be set with the 'authname' callback. > > Have you tried this, as it does not look right to me, Yes, it works with OpenLDAP 2.1.0. (Well I do get a 'not authorized' when=20 using a authorization identity that is different from the authentication=20 identity but but that is an OpenLDAP issue. I have yet to setup=20 saslAuthTo/From). > But Chris could > confirm as he wrote the original. You have changed this from sending > the auth as a response to sending it with the initial request. I also checked with ssldump. In the old version, the authorization identity = does not get send, because EXTERNAL has only one roudtrip. > The reason it was using user, was for compatability with previous SASL > implementation. > > Also, it needs to work the same as the Authen::SASL::Cyrus package > (I have CC'd the author), so if someone can confirm how that works, > we can make it match. --=20 Dipl.-Inform. Norbert Klasen DAASI International GmbH phone: +49 7071 29 70336 Wilhelmstr. 106 fax: +49 7071 29 5114 72074 T=FCbingen email: nor...@da... Germany web: http://www.daasi.de |
|
From: Graham B. <gb...@po...> - 2002-05-07 12:39:49
|
On Tue, May 07, 2002 at 11:36:04AM +0200, Norbert Klasen wrote:
> Hi,
> RFC2222 says that in the EXTERNAL mechanism "The client sends an initial
> response with the authorization identity." The attached patch does this. An
> authorization identity can be set with the 'authname' callback.
Have you tried this, as it does not look right to me, But Chris could
confirm as he wrote the original. You have changed this from sending
the auth as a response to sending it with the initial request.
The reason it was using user, was for compatability with previous SASL
implementation.
Also, it needs to work the same as the Authen::SASL::Cyrus package
(I have CC'd the author), so if someone can confirm how that works,
we can make it match.
Graham.
> --- /archiv/cvs/perl-ldap/sasl/lib/Authen/SASL/Perl/EXTERNAL.pm Thu Jan 24 13:04:16 2002
> +++ EXTERNAL.pm Tue May 7 11:30:49 2002
> @@ -24,12 +24,16 @@
> sub mechanism { 'EXTERNAL' }
>
> sub client_start {
> - ''
> -}
> + my $self = shift;
>
> -sub client_step {
> - shift->_call('user');
> + my $v = $self->_call('authname');
> + defined($v) ? $v : ''
> }
> +
> +#sub client_step {
> +# shift->_call('user');
> +# ''
> +#}
>
> 1;
>
|
|
From: Norbert K. <nor...@da...> - 2002-05-07 11:34:41
|
Hi, RFC2222 says that in the EXTERNAL mechanism "The client sends an initial=20 response with the authorization identity." The attached patch does this. An = authorization identity can be set with the 'authname' callback. --=20 Dipl.-Inform. Norbert Klasen DAASI International GmbH phone: +49 7071 29 70336 Wilhelmstr. 106 fax: +49 7071 29 5114 72074 T=FCbingen email: nor...@da... Germany web: http://www.daasi.de |
|
From: Atif G. <agh...@de...> - 2002-05-06 18:38:02
|
hi all, I have been using Net::LDAP since a few years and just now subscribed to the list. 2 things about this. 1. DOH 2. Net::LDAP is tooooo eazy Anyway, I wrote a small utility today that I needed for a project and want to share it with you. its called ldifgrep http://atifghaffar.com/sections/softwares/ldap/ldifgrep/ldifgrep.pl.txt Usage: ldifgrep objectclass top <ldiffile this will get you all entries that have the objectclass top or ldifgrep dn uid <ldiffile this will get all entries that has the string "uid" in its DN or ldifgrep -v objectclass ipNetwork <ldiffile this will get all entries that do not (-v ala grep) have an objectclass of ipNetwork defined. Hopefully this utility will help someone.. best regards. -- Atif Ghaffar ---------------------------. +41 78 845 31 64 ¦ tel agh...@de... ¦ email http://atifghaffar.com ¦ www 8206786 ¦ icq |
|
From: Norbert K. <nor...@da...> - 2002-05-06 16:03:17
|
Hi,
Net::LDAP::LDIF chokes on the following LDIF file:
version: 1
dn: o=3Dtest
objectclass: organization
o: test
It interpretes the version-spec as being an entry if followed by more than=20
one newline. This patch just reads the next entry if that is the case.
--- /usr/lib/perl5/site_perl/5.6.1/Net/LDAP/LDIF.pm Tue Apr 23 12:57:09 =
2002
+++ LDIF.pm Mon May 6 17:22:36 2002
@@ -109,6 +109,10 @@
if (@ldif and $ldif[0] =3D~ /^version:\s+(\d+)/) {
$self->{version} =3D $1;
shift @ldif;
+ if (@ldif =3D=3D 0) {
+ @ldif =3D $self->_read_lines;
+ return unless @ldif;
+ }
}
if (@ldif <=3D 1) {
P.S.: Besides LF, the line separator can also be CR LF.
--=20
Dipl.-Inform. Norbert Klasen
DAASI International GmbH phone: +49 7071 29 70336
Wilhelmstr. 106 fax: +49 7071 29 5114
72074 T=FCbingen email: nor...@da...
Germany web: http://www.daasi.de
|
|
From: Torsten F. <tor...@gm...> - 2002-05-06 15:30:19
|
Hi
I am using Net::LDAP::LDIF version 0.09 to read in the output of
OpenLDAP's ldapsearch utility.
ldapsearch generates a comment before every entry like this:
# DbagItb-bf-geo-st-bauwerk-gleis-bahnsteigabschnitt, oc, config, itb, db-sta
tion, db-ag, de
dn: oc=DbagItb-bf-geo-st-bauwerk-gleis-bahnsteigabschnitt,conf=oc,soa=config,s
ys=itb,ou=db-station,o=db-ag,c=de
...
If the comment is continued as shown on the next line Net::LDAP::LDIF
returns an error: First line of LDIF entry does not begin with 'dn:'".
Simply exchanging 2 lines of the code of sub _read_lines fixed the
problem:
sub _read_lines {
my $self = shift;
my @ldif;
{
local $/ = "";
my $fh = $self->{'fh'};
my $ln = $self->{_next_lines} || scalar <$fh>;
unless ($ln) {
$self->{_next_lines} = '';
$self->{_current_lines} = '';
$self->eof(1);
return;
}
########################################################
# I have exchanged the next 2 lines.
$ln =~ s/\n //sg;
$ln =~ s/^#.*\n//mg;
########################################################
chomp($ln);
$self->{_current_lines} = $ln;
chomp(@ldif = split(/^/, $ln));
$self->{_next_lines} = scalar <$fh> || '';
$self->eof(1) unless $self->{_next_lines};
}
@ldif;
}
|
|
From: Bob G. <go...@at...> - 2002-05-05 06:14:19
|
Are you using an authenticated bind()? If so, are you authenticating as
an account that has access write to userPassword? This sounds like a
security issue rather than an iPlanet server problem.
B
Markus Preller wrote:
>
> Hello,
>
> when I try to retrieve the userPassword attribute
> (which is in crypt format by the way) from a iPlanet-
> based directory using the Net::LDAP::Entry->attributes
> and Net::LDAP::Entry->get_value function I get an undefined
> result. Checking the existence of the attribute I get a
> positive feedback.
>
> Doing the same thing on a OpenLDAP-based directory I get
> the expected result in a way of {crypt}somekindohash.
>
> What's the problem with the iPlanet server ?
>
> Could anybody help me out of this ?
>
> bye
> Markus Preller
>
>
> _______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for download mirrors. We supply
> the hardware. You get the recognition. Email Us: ban...@so...
--
Bob Goolsby
go...@at...
The only thing with more energy than a puppy with a bone is a puppy with
*two* bones.
|
|
From: Jim H. <ha...@us...> - 2002-05-04 02:14:41
|
This is done by doing a search, setting the base to the dn and using a filter of objectclass=*, which always succeeds. $mesg = $ldap->search ( base => $dn, filter => "objectclass=*") or die; $entry = $mesg->entry(0); --Jim Harle On Fri, 3 May 2002, Joseph Kezar wrote: > I want to retrieve a single LDAP::Entry based on it's DN. I can't find a method to allow me to do this. > > I want something like: > > $entry = $ldap->get_entry(DN); > > Is anything like this in existance? > |
|
From: <ma...@mj...> - 2002-05-04 01:38:16
|
Hi,
Most likely it's a permission problem. By default with IPlanet, only
the directory administrator account can read userPassword.
Which leads to my next point. Why in the @#%!@#% are you
trying to read the userPassword?
If it's for authentication, that's a bad road to follow. You should be
using a bind instead.
Reading the password causes you to transport the encrypted user
password across the network and it also means you're avoiding
using any of the LDAP server's authentication safeguards (for
example with IPlanet, you can do things like account expiration
that are only enforced on a bind).
Mark
On 4 May 02, at 1:54, Markus Preller wrote:
> Hello,
>
> when I try to retrieve the userPassword attribute
> (which is in crypt format by the way) from a iPlanet-
> based directory using the Net::LDAP::Entry->attributes
> and Net::LDAP::Entry->get_value function I get an undefined
> result. Checking the existence of the attribute I get a
> positive feedback.
>
> Doing the same thing on a OpenLDAP-based directory I get
> the expected result in a way of {crypt}somekindohash.
>
> What's the problem with the iPlanet server ?
>
> Could anybody help me out of this ?
>
> bye
> Markus Preller
>
>
> _______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for download mirrors. We
> supply the hardware. You get the recognition. Email Us:
> ban...@so...
>
>
Mark Wilcox
ma...@mj...
Got LDAP?
|
|
From: <Mar...@t-...> - 2002-05-03 23:59:30
|
Hello,
when I try to retrieve the userPassword attribute
(which is in crypt format by the way) from a iPlanet-
based directory using the Net::LDAP::Entry->attributes
and Net::LDAP::Entry->get_value function I get an undefined
result. Checking the existence of the attribute I get a
positive feedback.
Doing the same thing on a OpenLDAP-based directory I get
the expected result in a way of {crypt}somekindohash.
What's the problem with the iPlanet server ?
Could anybody help me out of this ?
bye
Markus Preller
|
|
From: Joseph K. <jk...@do...> - 2002-05-03 18:50:59
|
I want to retrieve a single LDAP::Entry based on it's DN. I can't find = a method to allow me to do this. I want something like: $entry =3D $ldap->get_entry(DN); Is anything like this in existance? |
|
From: Claeson Nancy-P. <Nan...@gd...> - 2002-05-03 13:36:06
|
Given the right validations, I was able to access W2K Active Directory information from a Perl script running on Sun 2.6, I added modules from cpan, perl-ldap-0.25, Convert-ASN1-0.15, Convert-BER-1.31 to my Perl installation. The key was finding bind parameters needed to access each LDAP container, I do not know LDAP, I needed the knowledge of the W2K Active Directory implementers to complete the work. The sample Perl programs from the internet for accessing LDAP were very helpful. Thank You Nancy -----Original Message----- From: Graham Barr [mailto:gb...@po...] Sent: Tuesday, April 09, 2002 12:53 PM To: LDAP Mailing List Cc: Claeson Nancy-P28600 Subject: [Fwd] Help using Net::LDAP to communicate between Sun and W2k ----- Forwarded message from Claeson Nancy-P28600 <Nan...@gd...> ----- Date: Tue, 9 Apr 2002 12:53:03 -0700 To: "'gb...@po...'" <gb...@po...> From: Claeson Nancy-P28600 <Nan...@gd...> Subject: Help using Net::LDAP to communicate between Sun and W2k I have not trouble using Net::LDAP to get LDAP information from a Sun but when I go to get information from a W2K Active Directory, the $ldap->search fails to find an entry that I know is there. Would you have any examples of Net::LDAP running on Sun, retrieving information from W2K active directory? Any ideas would help. This in new the corporation and any help would be appreciated very much. Thank You Nancy Claeson 480-441-8316 USA ----- End forwarded message ----- |
|
From: Chris R. <chr...@me...> - 2002-05-02 11:07:18
|
Norbert Klasen <nor...@da...> wrote: > Hi, > does somebody have some sample code to hande a protocol mismatch? I want > to use LDAPv3 by default and downgrade to v2 if necessary. >=20 > --=20 > Norbert Klasen, Dipl.-Inform. > DAASI International GmbH phone: +49 7071 29 70335 > Wilhelmstr. 106 fax: +49 7071 29 5114 > 72074 T=FCbingen email: nor...@da... > Germany web: http://www.daasi.de I think just checking $res->code after the bind for LDAP_PROTOCOL_ERROR will work. There's some code which does this in the package - look in bin/ldapsearch.pl or thereabouts. I haven't tried it for a while... Cheers, Chris |
|
From: Graham B. <gb...@po...> - 2002-05-02 11:02:31
|
On Thu, May 02, 2002 at 12:46:58PM +0200, Norbert Klasen wrote:
> Hi,
> does somebody have some sample code to hande a protocol mismatch? I want to
> use LDAPv3 by default and downgrade to v2 if necessary.
If your server does not support v3 then a bind for v3 should
return a code of LDAP_PROTOCOL_ERROR. So you could trap that
and then try a v2 bind instead.
$mesg = $ldap->bind(version => 3, ....);
if($mesg->code == LDAP_PROTOCOL_ERROR) {
$mesg = $ldap->bind(version => 2, ...);
}
# Process any other error code here.
Graham.
|
|
From: Graham B. <gb...@po...> - 2002-05-02 10:58:22
|
On Thu, May 02, 2002 at 12:50:35PM +0200, Norbert Klasen wrote: > Hi, > does NET::LDAP support ARRAYREF callbacks like in Authen::SASL? No. For Net::LDAP the callback is always a CODEREF Graham. |
|
From: Norbert K. <nor...@da...> - 2002-05-02 10:50:41
|
Hi, does NET::LDAP support ARRAYREF callbacks like in Authen::SASL? --=20 Norbert Klasen, Dipl.-Inform. DAASI International GmbH phone: +49 7071 29 70335 Wilhelmstr. 106 fax: +49 7071 29 5114 72074 T=FCbingen email: nor...@da... Germany web: http://www.daasi.de |
7902 messages has been excluded from this view by a project administrator.
