strong bind fails
Dieter Kluenter
I'am using
perl-5.10.0
Net::LDAP version 0.39
Authen::SASL version 2.12
My script does not initiate a strong bind, while a strong bind with
ldapsearch succeeds, what is wrong with my script? Or with perl-5.10,
as am not sure but I think this script has been working with perl-5.8
My script:
,----[ perl script ]
| $ldap = Net::LDAP->new("$host",
| async => 1,
| version => 3
| ) or die "$@";
|
| $sasl = Authen::SASL->new(
| mechanism => 'DIGEST-MD5',
| debug => 4,
| callback => {
| user => 'dieter',
| pass => 'secret'
| }
| ) or die "$@";
| $msg = $ldap->bind(sasl => $sasl);
| $msg->code && $msg->error;
|
| $result = $ldap->search(
| base => $basedn,
| scope => $scope,
| filter => $filter,
| attrs => ["$attrs[0]","$attrs[1]","$attrs[2]","$attrs[3]" ]
| );
| ....
`----
The output of perl debugging shows
,----[ Debugging ]
| DB<19> x $ldap
| 0 Net::LDAP=HASH(0xfee860)
| 'net_ldap_async' => 1
| 'net_ldap_debug' => 0
| 'net_ldap_host' => 'localhost'
| 'net_ldap_port' => 389
| 'net_ldap_refcnt' => 1
| 'net_ldap_resp' => HASH(0x1117638)
| empty hash
| 'net_ldap_scheme' => 'ldap'
| 'net_ldap_socket' => IO::Socket::INET=GLOB(0x128cd40)
| -> *Symbol::GEN0
| FileHandle({*Symbol::GEN0}) => fileno(3)
| 'net_ldap_uri' => 'localhost'
| 'net_ldap_version' => 3
|
| DB<22> x $sasl
| 0 Authen::SASL=HASH(0x128ce60)
| 'callback' => HASH(0x104bf90)
| 'pass' => 'secret'
| 'user' => 'dieter'
| 'debug' => 4
| 'mechanism' => 'DIGEST-MD5'
| DB<23> !22
`----
My slapd log file does not show a sasl bind operation, in fact no bind
operation at all. This is the log of a successful sasl bind of
ldapsearch with the same credentials as the perl script:
,----[ successful sasl bind ]
| conn=0 fd=15 ACCEPT from IP=127.0.0.1:59521 (IP=0.0.0.0:389)
| conn=0 op=0 BIND dn="" method=163
| do_bind: dn () SASL mech DIGEST-MD5
| ==> sasl_bind: dn="" mech=DIGEST-MD5 datalen=0
| SASL [conn=0] Debug: DIGEST-MD5 server step 1
| send_ldap_sasl: err=14 len=185
| send_ldap_response: msgid=1 tag=97 err=14
| conn=0 op=1 BIND dn="" method=163
| do_bind: dn () SASL mech DIGEST-MD5
| ==> sasl_bind: dn="" mech=<continuing> datalen=271
| SASL [conn=0] Debug: DIGEST-MD5 server step 2
| SASL Canonicalize [conn=0]: authcid="dieter"
| slap_sasl_getdn: conn 0 id=dieter [len=6]
| => ldap_dn2bv(16)
| <= ldap_dn2bv(uid=dieter,cn=DIGEST-MD5,cn=auth)=0
| do_bind: SASL/DIGEST-MD5 bind: dn="cn=dieter kluenter,ou=partner,o=avci,c=de" sasl_ssf=128
`----
And here the log of an anonymous search resulting from my script:
conn=0 fd=15 ACCEPT from IP=127.0.0.1:42123 (IP=0.0.0.0:389)
daemon: epoll: listen=7 active_threads=0 tvp=zero
daemon: epoll: listen=8 active_threads=0 tvp=zero
...
Here starts the search, without any prior bind operation
SRCH "cn=Mailinglisten,cn=Dieter Kluenter,ou=Partner,o=avci,c=de" 1 2
And now checking the access rules, due to my ACL anonymous read is not
allowed, thus error 32.
<= check a_dn_pat: *
<= acl_mask: [3] applying none(=0) (stop)
<= acl_mask: [3] mask: none(=0)
=> slap_access_allowed: search access denied by none(=0)
=> access_allowed: no more rules
send_ldap_result: conn=0 op=0 p=3
send_ldap_result: err=32 matched="" text=""
-Dieter
--
Dieter Klünter | Systemberatung
http://www.dpunkt.de/buecher/2104.html
sip: +49.180.1555.7770535
GPG Key ID:8EF7B6C6
53°08'09,95"N
10°08'02,42"E
Graham Barr
> Hi,
> I'am using
> perl-5.10.0
> Net::LDAP version 0.39
> Authen::SASL version 2.12
>
> My script does not initiate a strong bind, while a strong bind with
> ldapsearch succeeds, what is wrong with my script? Or with perl-5.10,
> as am not sure but I think this script has been working with perl-5.8
>
> My script:
> ,----[ perl script ]
> | $ldap = Net::LDAP->new("$host",
> | async => 1,
> | version => 3
> | ) or die "$@";
> |
> | $sasl = Authen::SASL->new(
> | mechanism => 'DIGEST-MD5',
> | debug => 4,
> | callback => {
> | user => 'dieter',
> | pass => 'secret'
> | }
> | ) or die "$@";
> | $msg = $ldap->bind(sasl => $sasl);
> | $msg->code && $msg->error;
You do not say how far your script gets, but if bind fails that is not
going to tell you. did you mean $msg->code && die $msg->error;
> | $result = $ldap->search(
> | base => $basedn,
> | scope => $scope,
> | filter => $filter,
> | attrs => ["$attrs[0]","$attrs[1]","$attrs[2]","$attrs[3]" ]
> | );
> | ....
> `----
>
> The output of perl debugging shows
perl debug is not very useful in this case. Try adding $ldap->debug(1);
Graham.
Dieter Kluenter
> On Jan 17, 2009, at 10:01 AM, Dieter Kluenter wrote:
>> Hi,
>> I'am using
>> perl-5.10.0
>> Net::LDAP version 0.39
>> Authen::SASL version 2.12
>
> You do not say how far your script gets, but if bind fails that is not
> going to tell you. did you mean $msg->code && die $msg->error;
[...]
> perl debug is not very useful in this case. Try adding $ldap->debug(1);
OK, this is my complete script,
,----[ searchList.pl ]
| $ldap = Net::LDAP->new("$host",
| async => 1,
| version => 3
| ) or die "$@";
| $debug=$ldap->debug(1);
|
| $sasl = Authen::SASL->new(
| mechanism => 'DIGEST-MD5',
| debug => 4,
| callback => {
| user => 'dieter',
| pass => 'secret'
| }
| ) or die "$@";
| $msg = $ldap->bind(sasl => $sasl);
| $msg->code && $msg->error_text;
|
| $result = $ldap->search(
| base => $basedn,
| scope => $scope,
| filter => $filter,
| attrs => ["$attrs[0]","$attrs[1]","$attrs[2]","$attrs[3]" ]
| );
| if ( $result->code ){
| LDAPerror ( "Searching",$result );
| }
| sub LDAPerror
| {
| my ($from,$result) =@_;
| print "Fehlermeldung: ",$result->code;
| print ":",$result->error_text;
| }
| foreach $entry ($result->entries){
| $entry->dump;
| }
| $msg = $ldap->unbind;
`----
And this is the output of ldap debug
,----[ debug code ]
| dieter@rubin: perlscripts% perl searchList.pl
| Net::LDAP=HASH(0xc86a08) sending:
|
| 30 81 86 02 01 02 63 81 80 04 3A 63 6E 3D 4D 61 0.....c...:cn=Ma
| 69 6C 69 6E 67 6C 69 73 74 65 6E 2C 63 6E 3D 44 ilinglisten,cn=D
| 69 65 74 65 72 20 4B 6C 75 65 6E 74 65 72 2C 6F ieter Kluenter,o
| 75 3D 50 61 72 74 6E 65 72 2C 6F 3D 61 76 63 69 u=Partner,o=avci
| 2C 63 3D 64 65 0A 01 01 0A 01 02 02 01 00 02 01 ,c=de...........
| 00 01 01 00 A3 09 04 02 63 6E 04 03 69 62 6D 30 ........cn..ibm0
| 28 04 02 63 6E 04 0A 4C 69 73 74 65 6E 4E 61 6D (..cn..ListenNam
| 65 04 0A 6D 79 4C 69 73 74 4E 61 6D 65 04 0A 61 e..myListName..a
| 75 74 68 50 68 72 61 73 65 __ __ __ __ __ __ __ uthPhrase
|
| Net::LDAP=HASH(0x7bf980) received:
| Fehlermeldung: 32:The server cannot find an object specified in the request
| Net::LDAP=HASH(0xc86a08) sending:
|
| 30 05 02 01 03 42 00 __ __ __ __ __ __ __ __ __ 0....B.
`----
This is a search request and the result code 32 indicates that there
is no sufficient access to the database (at least with regard to
openldap).
Graham Barr
On Jan 18, 2009, at 8:37 AM, Dieter Kluenter wrote:
>
> OK, this is my complete script,
>
> ,----[ searchList.pl ]
>
> | $msg = $ldap->bind(sasl => $sasl);
> | $msg->code && $msg->error_text;
Again, you are not checking the bind call for any failure
Graham.
Dieter Kluenter
I checked it on the server side, and no bind operation was
inititated.
There must be something fundamental wrong with my scripts, but I don't
see the forest.
I tried starttls and EXTERNAL mechanism
,----[ start_tls ]
| my $ldap = Net::LDAP->new("$host",
| async => 1,
| version => 3,
| debug => 8
| ) or die "$@";
|
| my $msg = $ldap->start_tls(
| verifiy => 'require',
| clientcert => $tls_cert,
| clientkey => $tls_key,
| cafile => $tls_cacert
| );
| $msg->code && die $msg->error;
|
| my $sasl = Authen::SASL->new(
| mechanism => 'EXTERNAL',
| callback => {user => '' }
| ) or die "$@";
|
| $msg = $ldap->bind(sasl => $sasl);
`----
I tried EXTERNAL mechanism over ldapi
,----[ external over ldapi ]
| my $host = 'ldapi://%2Fvar%2Frun%2Fslapd%2Fldapi';
| my $ldap = Net::LDAP->new("$host",
| async => 1,
| version => 3,
| debug => 4
| ) or die "$@";
|
| my $sasl = Authen::SASL->new(
| mechanism => 'EXTERNAL',
| callback => {user => '' }
| ) or die "$@";
|
| my $msg = $ldap->bind(sasl => $sasl);
`----
I solved my problem in the end using Net::LDAPapi, that did what it
should do,
,----[ LDAPapi ]
| $ld = new Net::LDAPapi(
| -uri=>"$url");
|
| $ld->sasl_parms(
| -mech=> "$mech",
| -flag=>LDAP_SASL_QUIET);
|
| $ld->bind_s("$sasl_name","$passwd",LDAP_AUTH_SASL);
`----
Quanah Gibson-Mount
<die...@dkluenter.de> wrote:
> I tried starttls and EXTERNAL mechanism
>
> ,----[ start_tls ]
>| my $ldap = Net::LDAP->new("$host",
>| async => 1,
>| version => 3,
>| debug => 8
>| ) or die "$@";
Have you tried not using async operations first? I found with async I had
to put in sleep's between the new, bind, and search operations.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Dieter Kluenter
> --On Monday, January 19, 2009 12:41 PM +0100 Dieter Kluenter
> <die...@dkluenter.de> wrote:
>
>
>> I tried starttls and EXTERNAL mechanism
>>
>> ,----[ start_tls ]
>>| my $ldap = Net::LDAP->new("$host",
>>| async => 1,
>>| version => 3,
>>| debug => 8
>>| ) or die "$@";
>
>
> Have you tried not using async operations first? I found with async I
> had to put in sleep's between the new, bind, and search operations.
Yes I did, but with no avail. I have modified the error handling now
$msg = $ldap->bind( sasl => $sasl);
if ( $msg->code ) { print "Fehler: "."$msg \n" };
which gives now fowllowing results:
dieter@rubin:% perl sasl-suche-liste.pl
Fehler: Net::LDAP::Bind=HASH(0xc08260)
Fehlermeldung: 32:The server cannot find an object specified in the request
-Dieter
Bill Costa
After lurking for a very long time on this list, I have a
question of my own. I'm trying to dump the schema from an Oracle
Internet Directory LDAP, a.k.a. OID. After successfully
connecting and binding to the LDAP server here's the code snippet
in question:
119 print(STDERR "\nLoading schema...\n\n");
120 my $schema = $ldap->schema(); # Works for OpenLDAP
121 if (not defined($schema)) # But not for OID
122 {
123 my $baseDN = $ldap->root_dse->get_value('subSchemaSubentry');
124 print("BASEDN = <$baseDN>\n");
125 my $result = $ldap->search(
126 base => $baseDN,
127 scope => 'base',
128 filter => '(objectclass=subSchema)',
129 );
130
131 ldapAssert($result, "failed to find subSchema from root DSE");
132 my $entry = $result->entry();
133 my $entryDN = $entry->dn();
134 print("ENTRYDN = <$entryDN>\n");
135 $schema = $ldap->schema(dn => $entryDN);
136 die if (not defined($schema));
137 }
As the comment in line 120 says, a simple call to the schema
method works fine with an OpenLDAP server, but for OID, it
returns undefined. The code above reflects my attempt to
dynamically find out what the correct DN should be to feed to the
schema method. Here's the output:
Loading schema...
BASEDN = <cn=subschemasubentry>
ENTRYDN = <cn=subschemasubentry>
Cannot parse [( 1.3.6.1.1.1.1.22 NAME 'macAddress' DESC 'MAC address in maximal, colon separated hex notation, eg. 00:00:92:90:ee:e2' EQUALITY caseIgnoreIA5Match SYNTAX '1.3.6.1.4.1.1466.115.121.1.27'{128} )] {{128}} at /usr/lib/perl5/site_perl/5.8.5/Net/LDAP/Schema.pm line 355, <DATA> line 466.
...propagated at ./dump-schema.pl line 136, <DATA> line 466.
Now here's the really weird part. In line 135 the schema comes
back undefined. (Fine, I'm probably doing something wrong.) But
the "Cannot parse" error message is being generated by the naked
die statement in line 136. If that die statement is removed, the
program continues to execute and this parse error is not
displayed at all. I've never seen this bit of Perl magic before.
In any case I'm looking for advise on how to get the schema
method to work with this flavor of LDAP server. But I'm also
curious how a module's own error message can be piggybacked on
the caller's own die() statement as appears to be happening here.
Test Environment for the above:
Operating System: Red Hat Enterprise Linux AS release 4
Perl: 5.8.5 built for i386-linux-thread-multi
Net::LDAP: 0.39
- - - - - - - - - - - - - - - - - - -
One last question -- in the "LDAP SCHEMA RETRIEVAL" section of:
http://search.cpan.org/~gbarr/perl-ldap/lib/Net/LDAP/Examples.pod
I don't understand the '$self' variable in
$mesg = $self->search ( base => $dn,
scope => 'base',
filter => '(objectClass=subschema)',
);
This variable seems like a non sequitur when seen in the context
of all the other surround code. Should '$self' really be '$ldap'
in this example?
...BC
--
+-------------------------[ Bill....@UNH.EDU ]---+
| Bill Costa | No good
| 1 Leavitt Lane Voice: | deed...
| CIS/Telecom -- 2nd Floor +1-603-862-3056 |
| University of New Hampshire | Goes
| Durham, NH 03824 USA | unpunished.
+---------------[ http://pubpages.unh.edu/~wfc/ ]--+
Chris Ridd
I think the problem's in the way Oracle's representing the SYNTAX oid
value. RFC 4512 does not appear to permit quotes around the value for
SYNTAX; and any quotes present for other kinds of values need to be
around the *entire* value not just part of it. RFC 2252 seems to have
a compatible definition here.
Note the error reported says {{128}}.
So there are a couple of bugs in the server. Net::LDAP tries to handle
the quotes that shouldn't be there in the first place, but then gets
tripped up because the trailing quote is in the wrong place.
You could ask Oracle how to configure the server to return valid schema.
> Now here's the really weird part. In line 135 the schema comes
> back undefined. (Fine, I'm probably doing something wrong.) But
> the "Cannot parse" error message is being generated by the naked
> die statement in line 136. If that die statement is removed, the
> program continues to execute and this parse error is not
> displayed at all. I've never seen this bit of Perl magic before.
>
> In any case I'm looking for advise on how to get the schema
> method to work with this flavor of LDAP server. But I'm also
> curious how a module's own error message can be piggybacked on
> the caller's own die() statement as appears to be happening here.
I'm afraid my brain starts hurting when I look at Schema.pm :-)
>
> Test Environment for the above:
>
> Operating System: Red Hat Enterprise Linux AS release 4
> Perl: 5.8.5 built for i386-linux-thread-multi
> Net::LDAP: 0.39
>
> - - - - - - - - - - - - - - - - - - -
>
> One last question -- in the "LDAP SCHEMA RETRIEVAL" section of:
>
> http://search.cpan.org/~gbarr/perl-ldap/lib/Net/LDAP/Examples.pod
>
> I don't understand the '$self' variable in
>
> $mesg = $self->search ( base => $dn,
> scope => 'base',
> filter => '(objectClass=subschema)',
> );
>
> This variable seems like a non sequitur when seen in the context
> of all the other surround code. Should '$self' really be '$ldap'
> in this example?
Yes, it should be.
Cheers,
Chris
Bill Costa
Chris Ridd recently wrote (in part):
> I think the problem's in the way Oracle's representing the
> SYNTAX oid value. RFC 4512 ... You could ask Oracle how to
> configure the server to return valid schema.
After looking at the RFC's you referenced, as well as
http://www.openldap.org/doc/admin23/schema.html
I would have to agree (with what little I know on the subject)
that it doesn't look like Oracle is following the spec. On
the other hand the V3.2 of LDAPsoft's LDAP Admin Tool appears
to consume the schema definitions without problems.
I'll try submitting a bug report to Oracle, but given past
experience with this company, I'm not optimistic.
As for correctly handling schema errors, how can the error()
method (as described in Net::LDAP::Schema documentation) be
used if the value being returned by the schema method is
undefined?
Chris Ridd
On 8 Jul 2009, at 17:12, Bill....@unh.edu wrote:
>
> Chris Ridd recently wrote (in part):
>
>> I think the problem's in the way Oracle's representing the
>> SYNTAX oid value. RFC 4512 ... You could ask Oracle how to
>> configure the server to return valid schema.
>
> After looking at the RFC's you referenced, as well as
>
> http://www.openldap.org/doc/admin23/schema.html
>
> I would have to agree (with what little I know on the subject)
> that it doesn't look like Oracle is following the spec. On
> the other hand the V3.2 of LDAPsoft's LDAP Admin Tool appears
> to consume the schema definitions without problems.
You could try changing the "die" when checking the extra {128} token
into a "warn". Looks like the die on line 355 (ie without the "Drop of
end of list" comment) is the culprit - try that and see.
>
> I'll try submitting a bug report to Oracle, but given past
> experience with this company, I'm not optimistic.
>
> As for correctly handling schema errors, how can the error()
> method (as described in Net::LDAP::Schema documentation) be
> used if the value being returned by the schema method is
> undefined?
If I'm trying to analyze schema parsing problems I create a schema
object first, and then call parse with the contents of a subschema
subentry. Something like:
$dn = $ldap->root_dse()->get_value("subschemaSubentry");
$res = $ldap->search(base => $dn,
scope => 'base',
filter => '(objectclass=subschema)',
attrs => ['objectClasses', 'attributeTypes']);
die "Search failed " . $res->code . "\n" if $res->code;
$schema = Net::LDAP::Schema->new;
$schema->parse($res->entry(0)) or print "Schema parse failed with " .
$schema->error . "\n";
Cheers,
Chris
Bill Costa
> $schema = Net::LDAP::Schema->new;
> $schema->parse($res->entry(0)) or print "Schema parse failed with " .
> $schema->error . "\n";
Excellent! That's exactly the hint I needed for sane use of
the schema services. Thanks Chris!
I submitted a bug report to Oracle and (surprise) they
responded right away with a useful answer. They did indeed
admit that there was a syntax error, it's been reported to
the developers, and the support rep sent back instructions
on how to fix it in our server. So good news all around.
...BC
--
+-------------------------[ Bill....@UNH.EDU ]---+
| Bill Costa | No good
| 1 Leavitt Lane Voice: | deed...
| CIS/Telecom -- 1st Floor +1-603-862-3056 |