I'm doing:
ldap::connect - no error
ldap::bind - no error
ldap::search - error message:
unexpected application number (19 != 4 or 5)
Also after studing the corresponding RFCs I could not find an
explanation which helps.
Has anyone experienced a similar bevahiour?
... or better, has anyone found a solution for this problem?
TIA
--
Gerhard Reithofer
Tech-EDV Support Forum - http://www.tech-edv.co.at/vcms/
Which exakt Version of the ldap package are you using? Please try the
latest from tcllib cvs at:
http://tcllib.cvs.sourceforge.net/tcllib/tcllib/modules/ldap/
and also get the newest asn package:
http://tcllib.cvs.sourceforge.net/tcllib/tcllib/modules/asn/
There were some errors in the released Tcllib 1.9 package, on having
todo with a broken abandon command, which may be a problem you see.
I don't have an ActiveDirectory server to test with, so it may be some
Microsoft specific problem.
The ldap package does not currently handle the case when the server
sends an SearchResultReference instead of a direct result.
http://www.ietf.org/rfc/rfc2251.txt Section 4.5.2/4.5.3
SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
-- at least one LDAPURL element must be present
So its a missing feature. A patch to add it would be nice ;-)
Basically it would involve adding something like this to ldap.tcl 1.6.8
just before line 1422...
} elseif {$appNum == 19} {
trace "Search Response ResultReference"
#----------------------------------------------------------
# unmarshal search data packet
#----------------------------------------------------------
asnGetOctetString response referral
set result [list $referral]
and then some postprocessing according to Section 4.5.3 to recursivly
query the referenced ldap servers, which could be done in code using the
ldap lib.
Michael
On Sat, 14 Apr 2007, Michael Schlenker wrote:
> Gerhard Reithofer schrieb:
> > Hi TCLers,
> > I've tried to retrieve data from an Active Directory server (Windows
...
> Which exakt Version of the ldap package are you using? Please try the
It's from ActiveTCL 8.4.13, tcllib is 1.8, ldap version is 1.2.1 (rather
outdated I'm afraid).
As it is the tcl environment of the customer, I can't change it as I
want.
> latest from tcllib cvs at:
> http://tcllib.cvs.sourceforge.net/tcllib/tcllib/modules/ldap/
> and also get the newest asn package:
> http://tcllib.cvs.sourceforge.net/tcllib/tcllib/modules/asn/
I will build a test package including the new versions and try these
ones.
> There were some errors in the released Tcllib 1.9 package, on having
...
> I don't have an ActiveDirectory server to test with, so it may be some
> Microsoft specific problem.
Same to me :-(
> The ldap package does not currently handle the case when the server
> sends an SearchResultReference instead of a direct result.
...
>
> http://www.ietf.org/rfc/rfc2251.txt Section 4.5.2/4.5.3
>
> SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
> -- at least one LDAPURL element must be present
>
> So its a missing feature. A patch to add it would be nice ;-)
...
I will try to analyze my problem first (e.g. by trying a connect via
PHP), maybe there will be a reason to work out the patch later if it is
required for AD access.
Thank's for your answer.
Maybe also look at the newer ldapx package, it makes some ldap stuff
much nicer with a snit based wrapper.
>> The ldap package does not currently handle the case when the server
>> sends an SearchResultReference instead of a direct result.
>
> ...
>
>> http://www.ietf.org/rfc/rfc2251.txt Section 4.5.2/4.5.3
>>
>> SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
>> -- at least one LDAPURL element must be present
>>
>> So its a missing feature. A patch to add it would be nice ;-)
>
> ...
>
> I will try to analyze my problem first (e.g. by trying a connect via
> PHP), maybe there will be a reason to work out the patch later if it is
> required for AD access.
After looking it to the problem a bit, I'm quite sure i could come up
with a patch rather easily (and put it into the Tcllib cvs as a new
official version ldap 1.7). It would require some extra care when
processing the search results (as you may get ldap referral urls as
result instead of the result itself and would have to resolve those for
the full result set).
Basically this happens:
- you send a query
- the server responds with some SearchResults (ASN Tag APPLICATION 4)
and with some SearchResultReferences (ASN Tag APPLICATION 19) and
finishes with an ASN APPLICATION 5 package, as end of results.
- The ldap package does not expect the 19er tag and breaks
The simple fix is to add the handling (decode the asn sequence into a
list of urls and return as result) for this case into the decoding proc,
i just can't test it here as i don't have a server with referrals.
If your interested in trying it out, contact me by mail and i could try
to come up with probably working code.
Michael