python-ldap-dev

Re: python-ldap, Zope, and NDS

[Michael <mi...@st...>]

Timothy Wilson wrote:
> 
> On Sat, 24 Jun 2000, David Leonard wrote:
> 
> > How did it go? Did Michael's answer help?
> 
> I took Michael's advice, but it didn't change anything.

Does one-level browsing with web2ldap work?

> It turns out that the bug I found (wherever its source) only manifests
> itself when I use the 'browse' feature of Jeffrey Shell's ZLDAPConnection
> product for Zope.

I don't know this module. If you reimplement one-level browsing in a
primitive test program and it works you have to dig into
ZLDAPConnection. Do you have any debugging messages in your server
logs? It would be helpful to observe the DNs, scope and search
filter it receives.

> > If it didn't then the problem may lie somewhere in the LDAP C library,
> > since python is simply reporting the errors that it finds.  Are you using
> > OpenLDAP, or solaris or netscape's ldap or...?
> 
> I suspect that the problem is a result of a bug in the LDAP C library as 
> you
> suggest or a case of < 100% compliance to the ldap standard on the part of
> Novell's NDS.

I'm not really sure that this is a bug in the OpenLDAP lib. I
experienced exactly the same error when doing LDAP-queries with
postfix-MTA (build with OpenLDAP libs) against a Lotus Domino
server. But browsing and searching this server with web2ldap
(python-ldap build with OpenLDAP lib) works just fine except some
strange things Domino is doing (e.g. case-sensitive mail
attributes). IMHO you have to take care about canonifying the DN.
There are e.g. some strange things with LDAPv2- and LDAPv3-DN
conversion.

Ciao, Michael.

P.S.: Please, let's stay on the mailing list with this discussion.

Re: python-ldap, Zope, and NDS

[Timothy W. <wi...@vi...>]

On Sat, 24 Jun 2000, Michael [iso-8859-1] Ströder wrote:

> Does one-level browsing with web2ldap work?

Yes it did. I searched an ou that has some of those pesky bindery objects,
and web2ldap seemed fine.

> > It turns out that the bug I found (wherever its source) only manifests
> > itself when I use the 'browse' feature of Jeffrey Shell's ZLDAPConnection
> > product for Zope.
> 
> I don't know this module. If you reimplement one-level browsing in a
> primitive test program and it works you have to dig into
> ZLDAPConnection. Do you have any debugging messages in your server
> logs? It would be helpful to observe the DNs, scope and search
> filter it receives.

The code I posted in my original post showed that using ldap.SCOPE_ONELEVEL
fails when searching 'ou's that have the troublesome bindery objects.

Here it is again:

Python 1.5.2 (#0, Apr  3 2000, 14:46:48)  [GCC 2.95.2 20000313 (Debian
GNU/Linux)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import ldap
>>> l = ldap.open("206.131.108.2",389)
>>> l.simple_bind_s("ou=do,o=isd_197","")
>>> test = l.search_s("ou=do,o=isd_197", ldap.SCOPE_SUBTREE,
"objectclass=*")
>>> test2 = l.search_s("ou=do,o=isd_197", ldap.SCOPE_ONELEVEL,
"objectclass=*")
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ldap.INVALID_DN_SYNTAX: {'desc': 'Invalid DN syntax'}
>>> 

> I'm not really sure that this is a bug in the OpenLDAP lib. I
> experienced exactly the same error when doing LDAP-queries with
> postfix-MTA (build with OpenLDAP libs) against a Lotus Domino
> server. But browsing and searching this server with web2ldap
> (python-ldap build with OpenLDAP lib) works just fine except some
> strange things Domino is doing (e.g. case-sensitive mail
> attributes). IMHO you have to take care about canonifying the DN.
> There are e.g. some strange things with LDAPv2- and LDAPv3-DN
> conversion.

I'm more convinced than ever that this is an NDS issue. The presence of
those bindery objects in the NDS tree is really just a kludge to prevent
breaking legacy apps that depend on the pre-NDS technology.

I'm not sure what you mean by "canonifying the DN." Care to expand on that?

Thanks for the help.

-Tim

--
Tim Wilson      | Visit Sibley online:         | Check out:
Henry Sibley HS | http://www.isd197.k12.mn.us/ | http://www.zope.org/
W. St. Paul, MN |                              | http://slashdot.org/
wi...@vi... |   <dtml-var pithy_quote>     | http://linux.com/

Re: python-ldap, Zope, and NDS

[Michael <mi...@st...>]

Timothy Wilson wrote:
> 
> Python 1.5.2 (#0, Apr  3 2000, 14:46:48)  [GCC 2.95.2 20000313 (Debian
> GNU/Linux)] on linux2
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> import ldap
> >>> l = ldap.open("206.131.108.2",389)
> >>> l.simple_bind_s("ou=do,o=isd_197","")
                       ^^^^^^^^^^^^^^^^^^^
Please read the doc of ldapmodule again. The DN is meant for binding
as this object (e.g. an entry describing a user) and is used for
authentication/authorization. If doing a anonymous bind you can
simply use an empty DN.

> >>> test = l.search_s("ou=do,o=isd_197", ldap.SCOPE_SUBTREE,
> "objectclass=*")
> >>> test2 = l.search_s("ou=do,o=isd_197", ldap.SCOPE_ONELEVEL,
> "objectclass=*")
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> ldap.INVALID_DN_SYNTAX: {'desc': 'Invalid DN syntax'}
> >>>

Hmm. And this very special search works with web2ldap?

> I'm more convinced than ever that this is an NDS issue.

But if it works with the more complex web2ldap it should work with
your simple source too since both uses ldapmodule. There's not extra
voodoo in web2ldap. E.g. web2ldap works with ldap://nldap.com which
is a (rather ancient) NDS server.

> those bindery objects in the NDS tree is really just a kludge to prevent
> breaking legacy apps that depend on the pre-NDS technology.

> I'm not sure what you mean by "canonifying the DN." Care to expand on that?

In your simple case it means removing whitespaces around the comma.
In more complex situations it also means handling escape sequences
for special characters like + , ; etc.

Ciao, Michael.

Re: python-ldap, Zope, and NDS

[Timothy W. <wi...@vi...>]

On Sun, 25 Jun 2000, Michael [iso-8859-1] Ströder wrote:

> > Python 1.5.2 (#0, Apr  3 2000, 14:46:48)  [GCC 2.95.2 20000313 (Debian
> > GNU/Linux)] on linux2
> > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> > >>> import ldap
> > >>> l = ldap.open("206.131.108.2",389)
> > >>> l.simple_bind_s("ou=do,o=isd_197","")
>                        ^^^^^^^^^^^^^^^^^^^
> Please read the doc of ldapmodule again. The DN is meant for binding
> as this object (e.g. an entry describing a user) and is used for
> authentication/authorization. If doing a anonymous bind you can
> simply use an empty DN.

Aha! Changing to l.simple_bind_s("", "") makes everything work fine. (At
least as far as my simple example goes.) I will go through the source for
ZLDAP and try to determine how it's being done there.

-Tim

--
Tim Wilson      | Visit Sibley online:         | Check out:
Henry Sibley HS | http://www.isd197.k12.mn.us/ | http://www.zope.org/
W. St. Paul, MN |                              | http://slashdot.org/
wi...@vi... |   <dtml-var pithy_quote>     | http://linux.com/

Re: python-ldap, Zope, and NDS

[Michael <mi...@st...>]

Timothy Wilson wrote:
> 
> On Sun, 25 Jun 2000, Michael [iso-8859-1] Ströder wrote:
> 
> > > Python 1.5.2 (#0, Apr  3 2000, 14:46:48)  [GCC 2.95.2 20000313 (Debian
> > > GNU/Linux)] on linux2
> > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> > > >>> import ldap
> > > >>> l = ldap.open("206.131.108.2",389)
> > > >>> l.simple_bind_s("ou=do,o=isd_197","")
> >                        ^^^^^^^^^^^^^^^^^^^
> > Please read the doc of ldapmodule again. The DN is meant for binding
> > as this object (e.g. an entry describing a user) and is used for
> > authentication/authorization. If doing a anonymous bind you can
> > simply use an empty DN.
> 
> Aha! Changing to l.simple_bind_s("", "") makes everything work fine

Well, LDAP hosts should assume anonymous bind if password is empty.
So it's a little bit of a NDS issue.

> (At
> least as far as my simple example goes.) I will go through the source for
> ZLDAP and try to determine how it's being done there.

If they put a bind-dn in a simple_bind() call although you did not
tell the module doing so it's definitely a bug in ZLDAP.

Ciao, Michael.