Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

LDAP troubles

31 views
Skip to first unread message

Gerhard Reithofer

unread,
Apr 14, 2007, 2:53:35 AM4/14/07
to
Hi TCLers,
I've tried to retrieve data from an Active Directory server (Windows
2003 Server) using the tcllib ldap client.

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/

Michael Schlenker

unread,
Apr 14, 2007, 6:17:51 AM4/14/07
to
Gerhard Reithofer schrieb:

> Hi TCLers,
> I've tried to retrieve data from an Active Directory server (Windows
> 2003 Server) using the tcllib ldap client.
>
> 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?

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

Gerhard Reithofer

unread,
Apr 15, 2007, 11:39:16 AM4/15/07
to
Hallo 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.

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.

Michael Schlenker

unread,
Apr 18, 2007, 3:36:30 PM4/18/07
to
Gerhard Reithofer schrieb:

> Hallo 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.
Sure. No problem, you can install the ldap and asn package from cvs
alongside the older version.

>
>> 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.
It won't help in this case, as it is a missing feature with referral
handling, but in general you can use the newer ldap.tcl version even
with older versions. It depends on a recent asn lib, but thats it.

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

0 new messages