python-ldap-dev — discussion among developers

Re: unicode value

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

Alain Spineux wrote:
> 
> Are you using often '+' and '*'  (in real application, not ldap browser,
> nor editor tools) ?

In small scripts I'm explicitly requesting certain attribute types.

Hmm, not sure about some directory sync tools I wrote for customers
which have kind of a generic processing and low-level classes create
different entry objects.

> And that way, user keep control with explicit conversion.

But I suspect that most programmers use '*' in their home-grown scripts.

> >    The only clean solution would be something involving LDAP schema
> >    processing!
> 
> Yes but what about unknown field type ?

If you really want to dive into this look in directory
pylib/w2lapp/schema/ of web2ldap's source. It works for me but I did not
consider this whole framework mature enough to be incorporated into
python-ldap.

Ciao, Michael.

Re: unicode value

[Alain S. <asp...@gm...>]

On 5/24/07, Michael Str=F6der <mi...@st...> wrote:
>
> Alain Spineux wrote:
> >
> > On 5/24/07, *Michael Str=F6der* <mi...@st...
> > <mailto:mi...@st...>> wrote:
> >
> > Thanks for showing me my ignorance. I was not knowing about * and + !
> > Easy, only named attributes will be converted!
> > In this case maybe is it possible to use [ '*', u'givenName', u'sn' ]
> > to convert only 'givenName' and 'sn'
>
> But then you will not gain much! Still the application has to know which
> attributes have to be converted. =3D> It's not worth hiding the conversio=
n
> within python-ldap.


I don't spend  too much then I dont't expect too much too :-)
Are you using often '+' and '*'  (in real application, not ldap browser, no=
r
editor tools) ?
And that way, user keep control with explicit conversion.

>
> > class UnicodeLDAPObject(LDAPObject):
>
> Sorry, I consider ldap.ldapobject to be low-level.


:-(

The only clean solution would be something involving LDAP schema processing=
!


Yes but what about unknown field type ?

Ciao, Michael.
>

Your remarks help me, don't hesitate to share your feeling.


--=20
--
Alain Spineux
aspineux gmail com
May the sources be with you

Re: unicode value

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

Alain Spineux wrote:
> 
> On 5/24/07, *Michael Ströder* <mi...@st...
> <mailto:mi...@st...>> wrote:
> 
>     Alain Spineux wrote:
>     >
>     > On 5/24/07, Michael Ströder <mi...@st...
>     <mailto:mi...@st...>> wrote:
>     >>
> 
>     And how about specials like '*' and '+' in attrlist? 
> 
> Thanks for showing me my ignorance. I was not knowing about * and + !
> Easy, only named attributes will be converted!
> In this case maybe is it possible to use [ '*', u'givenName', u'sn' ]
> to convert only 'givenName' and 'sn'

But then you will not gain much! Still the application has to know which
attributes have to be converted. => It's not worth hiding the conversion
within python-ldap.

>     > I'start writin a wrapper for search() and modify() now.
>     >
>     > I send you my results as soon a possible.
> 
>     I'm not too keen to incorporate Unicode patches in python-ldap's
>     low-level API...
> 
> not low-level
> 
> Here is my work on progress
> 
> class UnicodeLDAPObject(LDAPObject):

Sorry, I consider ldap.ldapobject to be low-level.

The only clean solution would be something involving LDAP schema processing!

Ciao, Michael.

Re: unicode value

[Alain S. <asp...@gm...>]

On 5/24/07, Michael Str=F6der <mi...@st...> wrote:
>
> Alain Spineux wrote:
> >
> > On 5/24/07, Michael Str=F6der <mi...@st...> wrote:
> >>
>
> And how about specials like '*' and '+' in attrlist?


Thanks for showing me my ignorance. I was not knowing about * and + !
Easy, only named attributes will be converted!
In this case maybe is it possible to use [ '*', u'givenName', u'sn' ]
to convert only 'givenName' and 'sn'


> > Ops, I forgot the asynchronous side of ldap, but the msgid make the lin=
k
> > between both
> > the request and the result and a dictionary store in the ldapobject
> > could store the
> > unicode transcoding info used in the request. And then ldap.result(),
> > could use these
> > info to decode the value when user call it.
>
> Yes, you could do this. But IMO it's cumbersome.


YES and I hope you will integrate my patch in your mainstream source code
:-)


> I'start writin a wrapper for search() and modify() now.
> >
> > I send you my results as soon a possible.
>
> I'm not too keen to incorporate Unicode patches in python-ldap's
> low-level API...


not low-level

Here is my work on progress

class UnicodeLDAPObject(LDAPObject):

    expiration_delay=3D300

    def __init__(self, uri, **kwargs):
        LDAPObject.__init__(self, uri, **kwargs)
        self.unicode_decoder=3D{}
        self.unicode_decoder_expire=3D[]

    def search_ext(self,base,scope, **kwargs):
        #
filterstr=3D'(objectClass=3D*)',attrlist=3DNone,attrsonly=3D0,serverctrls=
=3DNone,clientctrls=3DNone,timeout=3D-1,sizelimit=3D0

        # convert filter
        try:
            kwargs['filter']=3Dunicode2utf8(kwargs['filter'])
        except KeyError:
            pass

        # convert arglist and keep a copy of original values for later
decoding
        try:
            attrlist=3Dkwargs['attrlist']
            kwargs['attrlist']=3Dmap(unicode2utf8(kwargs['attrlist']))
        except KeyError:
            attrlist=3DNone

        mesgid=3DLDAPObject.search_ext(self,base,scope, **kwargs)

        if attrlist:
            self.unicode_decoder[mesgid]=3Dattrlist
            self.unicode_decoder_expire.append((mesgid,
datetime.datetime.now()+datetime.timedelta(seconds=3Dself.expiration_delay)=
))

        return mesgid

    def result3(self, **kwargs):
        # msgid=3D_ldap.RES_ANY,all=3D1,timeout=3DNone):
        rtype, rdata, rmsgid, decoded_serverctrls=3DLDAPObject.result3(self=
,
**kwargs)


Alain


--
Alain Spineux
aspineux gmail com
May the sources be with you

Re: unicode value

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

Alain Spineux wrote:
> 
> On 5/24/07, Michael Ströder <mi...@st...> wrote:
>>
>> "One cannot always assume UTF-8 encoded Unicode strings in
>> attribute values. Think of attributes jpegPhoto,
> 
> When writing my ldap.search() request I know jpegPhoto is raw data and
> not a string !
> This is why I will use 'jpegPhoto'  and not u'jpegPhoto' in the
> attribute list.

And how about specials like '*' and '+' in attrlist?

>> > what about the use of this kind of request ?
>> > ldap_con.search_s(base_dn, ldap.SCOPE_BASE, filter, ['cn', 'mail',
>> > u'givenName', u'sn' ])
>> >
>> > that way, python-lib know that attribute givenName and sn should be
>> > decoded into unicode  string.
>>
>> This will be cumbersome. You will have to pass these attributes into
>> method result() which in general has no knowledge about a particular
>> request it's receiving results for. And I'll keep it like this because I
> 
> Ops, I forgot the asynchronous side of ldap, but the msgid make the link
> between both
> the request and the result and a dictionary store in the ldapobject
> could store the
> unicode transcoding info used in the request. And then ldap.result(),
> could use these
> info to decode the value when user call it.

Yes, you could do this. But IMO it's cumbersome.

> I'start writin a wrapper for search() and modify() now.
> 
> I send you my results as soon a possible.

I'm not too keen to incorporate Unicode patches in python-ldap's
low-level API...

Ciao, Michael.

Re: unicode value

[Alain S. <asp...@gm...>]

On 5/24/07, Michael Str=F6der <mi...@st...> wrote:
> Alain Spineux wrote:
> > On 5/23/07, Michael Str=F6der <mi...@st...> wrote:
> >>
> >>
https://sourceforge.net/tracker/?func=3Ddetail&atid=3D352072&aid=3D616567&g=
roup_id=3D2072
> >
> > - First, encode data when sending request to ldap server.
> > Do you know an drawback to encode any unicode sting into utf-8 ?
>
> Did you read my comment in the tracker item above? I repeat it here:

Yes I did !

>
> "One cannot always assume UTF-8 encoded Unicode strings in
> attribute values. Think of attributes jpegPhoto,

When writing my ldap.search() request I know jpegPhoto is raw data and not =
a
string !
This is why I will use 'jpegPhoto'  and not u'jpegPhoto' in the attribute
list.
On the other hand, I will never use a unicode string for a jpegPhoto value
in ldap.modify() or ldap.add().

> userCertificate, etc. Therefore there's no generic way to
> handle that at the API level without knowledge about the
> syntax defined in the LDAP schema.
> (Note that this has been debated to death on python-ldap-dev
> mailing list.)"
>
> > -Second, decode data coming back from the server.
> > The only function to retrieve data is search(), right ?
>
> Not necessarily. Think of LDAP extended operations, like whoami_s().
>
> > what about the use of this kind of request ?
> > ldap_con.search_s(base_dn, ldap.SCOPE_BASE, filter, ['cn', 'mail',
> > u'givenName', u'sn' ])
> >
> > that way, python-lib know that attribute givenName and sn should be
> > decoded into unicode  string.
>
> This will be cumbersome. You will have to pass these attributes into
> method result() which in general has no knowledge about a particular
> request it's receiving results for. And I'll keep it like this because I

Ops, I forgot the asynchronous side of ldap, but the msgid make the link
between both
the request and the result and a dictionary store in the ldapobject could
store the
unicode transcoding info used in the request. And then ldap.result(), could
use these
info to decode the value when user call it.

> still have the idea for implementing a connection pool with less thread
> locking. Also it's not only a question of Unicode or not.

[OFF-TOPIC] You are speaking about thread, I used asynchat for 2 different
projects.
This could be an option for python-ldap

> It's very simple to implement a small wrapper class sufficient for
> simple applications. But I'm against doing this in the general
> python-ldap API.

Yes of course a wrapper around each function to convert input and output.
Thanks for your advice.

I'start writin a wrapper for search() and modify() now.

I send you my results as soon a possible.

Best regards.

Alain

--
Alain Spineux
aspineux gmail com
May the sources be with you

Re: unicode value

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

Alain Spineux wrote:
> On 5/23/07, Michael Ströder <mi...@st...> wrote:
>>
>> https://sourceforge.net/tracker/?func=detail&atid=352072&aid=616567&group_id=2072
> 
> - First, encode data when sending request to ldap server.
> Do you know an drawback to encode any unicode sting into utf-8 ?

Did you read my comment in the tracker item above? I repeat it here:

"One cannot always assume UTF-8 encoded Unicode strings in
attribute values. Think of attributes jpegPhoto,
userCertificate, etc. Therefore there's no generic way to
handle that at the API level without knowledge about the
syntax defined in the LDAP schema.
(Note that this has been debated to death on python-ldap-dev
mailing list.)"

> -Second, decode data coming back from the server.
> The only function to retrieve data is search(), right ?

Not necessarily. Think of LDAP extended operations, like whoami_s().

> what about the use of this kind of request ?
> ldap_con.search_s(base_dn, ldap.SCOPE_BASE, filter, ['cn', 'mail',
> u'givenName', u'sn' ])
> 
> that way, python-lib know that attribute givenName and sn should be
> decoded into unicode  string.

This will be cumbersome. You will have to pass these attributes into
method result() which in general has no knowledge about a particular
request it's receiving results for. And I'll keep it like this because I
still have the idea for implementing a connection pool with less thread
locking. Also it's not only a question of Unicode or not.

It's very simple to implement a small wrapper class sufficient for
simple applications. But I'm against doing this in the general
python-ldap API.

Ciao, Michael.

Re: unicode value

[Alain S. <asp...@gm...>]

On 5/23/07, Michael Str=F6der <mi...@st...> wrote:
> Alain Spineux wrote:
> > Why does python-ldap not convert automatically any unicode string into
> > UTF-8 before
> > to call the raw function ?
> >
> > Is-it by design or just a lack of time ?
>
> Kind of a FAQ. Feel free to propose a patch with a good(!) solution.
>
> https://sourceforge.net/tracker/?func=3Ddetail&atid=3D352072&aid=3D616567=
&group_id=3D2072
>
> Being the author of a schema-aware LDAP client based on python-ldap I
> know in how many detail problems you can run into...

They are two problems:

- First, encode data when sending request to ldap server.
 Do you know an drawback to encode any unicode sting into utf-8 ?
-Second, decode data coming back from the server.
 The only function to retrieve data is search(), right ?
 what about the use of this kind of request ?
 ldap_con.search_s(base_dn, ldap.SCOPE_BASE, filter, ['cn', 'mail',
u'givenName', u'sn' ])

 that way, python-lib know that attribute givenName and sn should be
decoded into unicode  string.

Do you see any other problems ?


>
> Ciao, Michael.
>


--=20
--
Alain Spineux
aspineux gmail com
May the sources be with you

Re: unicode value

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

Alain Spineux wrote:
> Why does python-ldap not convert automatically any unicode string into
> UTF-8 before
> to call the raw function ?
> 
> Is-it by design or just a lack of time ?

Kind of a FAQ. Feel free to propose a patch with a good(!) solution.

https://sourceforge.net/tracker/?func=detail&atid=352072&aid=616567&group_id=2072

Being the author of a schema-aware LDAP client based on python-ldap I
know in how many detail problems you can run into...

Ciao, Michael.

unicode value

[Alain S. <asp...@gm...>]

Why does python-ldap not convert automatically any unicode string into
UTF-8 before
to call the raw function ?

Is-it by design or just a lack of time ?

The idea is to replace any argument using this function.

def convert2raw(st):
    if isinstance(st, types.UnicodeType)
        return st.encode('utf-8')
    else
        return st

Easy for the filter argument of the "search" function, more work for
structure used
by "modify" and other, but still easy ?

This way we keep compatibility with older code.

Any comment ?

Ops: don't forget to make the the decoding of ldap result :-)


Best regards

-- 
--
Alain Spineux
aspineux gmail com
May the sources be with you

Re: Debian patches

[Matej V. <ve...@de...>]

Michael Str=F6der <mi...@st...> writes:

> Matej Vela wrote:
>
>> If you'd like to compile your own, apply the Debian patch from
>> <http://ftp.debian.org/debian/pool/main/p/python-ldap/python-ldap_2.3-2.=
diff.gz>.
>
> This is quite a large patch set. I worry that somebody here claims to
> use python-ldap 2.3 but it's heavily patched like this.

I'm not sure how closely you looked, but most of it is packaging-related
-- the equivalent of an RPM .spec file.

debian/patches/openldap_2.1.diff is the one exception, and it's less that
3 KB.  Apart from disabling unsupported option flags (LDAP_OPT_X_TLS_*),
I don't think it significantly alters functionality.

> =3D> I won't give support to Debian users anymore. I simply can't overlook
> all the changes made therein.

I understand.  Feel free to direct queries from Debian and Ubuntu users to
<pyt...@pa...>.  As you can see, I already keep an eye
on python-ldap-dev.

> Note that even OpenLDAP 2.2 is set to historic status by its developers.
> 2.1 is unmaintained since years. So there are currently no more fixes to
> OpenLDAP 2.2 and prior versions anymore. This also affects the client lib=
s.
>
> Instead of putting so much effort into preserving backwards compability
> of python-ldap to OpenLDAP 2.1 you should rather do the work to
> consequenty update all Debian packages to use OpenLDAP 2.3. There have
> been so many important fixes in the client libs.

I know.  Hopefully this will be fixed in the next release.

Cheers,

Matej

Re: possible bug(s) in python-ldap sasl code

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

Ino Pua wrote:
> 
> Is there some other way to trace whats going on that would make any
> sense to any of us? Im running this on OS X 10.4.9, with the lastest
> python-ldap (2.3) built against OpenLDAP 2.3.34.

Did you also build OpenLDAP from scratch? With which SASL libs?

Ciao, Michael.

Debian patches (was: error when build and install)

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

Matej Vela wrote:
> 
> If you'd like to compile your own, apply the Debian patch from
> <http://ftp.debian.org/debian/pool/main/p/python-ldap/python-ldap_2.3-2.diff.gz>.

This is quite a large patch set. I worry that somebody here claims to
use python-ldap 2.3 but it's heavily patched like this.
=> I won't give support to Debian users anymore. I simply can't overlook
all the changes made therein.

Note that even OpenLDAP 2.2 is set to historic status by its developers.
2.1 is unmaintained since years. So there are currently no more fixes to
OpenLDAP 2.2 and prior versions anymore. This also affects the client libs.

Instead of putting so much effort into preserving backwards compability
of python-ldap to OpenLDAP 2.1 you should rather do the work to
consequenty update all Debian packages to use OpenLDAP 2.3. There have
been so many important fixes in the client libs.

Ciao, Michael.

Re: error when build and install

[Matej V. <ve...@de...>]

"Einar N=E6ss Jensen" <ein...@gm...> writes:

> trying to build on debian etch, with ssl, I get this error:
> ldap-python version is 2.3
> python-version is 2.4.4
> openssl and sasl are installed
>
> Modules/constants.c: In function *LDAPinit_constants*:
> Modules/constants.c:178: error: *LDAP_OPT_X_TLS_CRLCHECK* undeclared
> (first use in this function)
[...]
>
> I have an earlier version of python-ldap, 2.0-pre19 (I I remember
> correctly) which is no trouble at all installing.

The current version of python-ldap requires version 2.3.0 of OpenLDAP
libraries, while Etch provides 2.1.30.  (AFAIK, this is mostly due to
compatibility problems that would arise if an application simultaneously
used differing versions of libldap and libnss-ldap.  Etch does ship with
slapd 2.3.30.)

If you don't mind using a slightly older version (2.2.1), simply install
the Debian package:

    # apt-get install python-ldap

If you'd like to compile your own, apply the Debian patch from
<http://ftp.debian.org/debian/pool/main/p/python-ldap/python-ldap_2.3-2.dif=
f.gz>.

Cheers,

Matej

error when build and install

[<ein...@gm...>]

trying to build on debian etch, with ssl, I get this error:
ldap-python version is 2.3
python-version is 2.4.4
openssl and sasl are installed

Modules/constants.c: In function =E2LDAPinit_constants=E2:
Modules/constants.c:178: error: =E2LDAP_OPT_X_TLS_CRLCHECK=E2 undeclared (f=
irst
use in this function)
Modules/constants.c:178: error: (Each undeclared identifier is reported onl=
y
once
Modules/constants.c:178: error: for each function it appears in.)
Modules/constants.c:179: error: =E2LDAP_OPT_X_TLS_CRL_NONE=E2 undeclared (f=
irst
use in this function)
Modules/constants.c:180: error: =E2LDAP_OPT_X_TLS_CRL_PEER=E2 undeclared (f=
irst
use in this function)
Modules/constants.c:181: error: =E2LDAP_OPT_X_TLS_CRL_ALL=E2 undeclared (fi=
rst
use in this function)
Modules/constants.c:207: error: =E2LDAP_AVA_NULL=E2 undeclared (first use i=
n
this function)
error: command 'gcc' failed with exit status 1

I have an earlier version of python-ldap, 2.0-pre19 (I I remember correctly=
)
which is no trouble at all installing.

any help apreciated

Best regards

--=20
--=20
Einar N=E6ss Jensen
http://einarblog.homemade.no/einarblog
http://www.homemade.no
tlf: +47 90990249
(\__/)
(=3D'.'=3D)This is Bunny. Copy and paste bunny into your
(")_(")signature to help him gain world domination.

Re: possible bug(s) in python-ldap sasl code

[Ino P. <in...@gm...>]

<<Im sorry of this comes up as a double post, but I dont seem to get =20
the messages from the mailing list even though Im subscribed, and the =20=

web gui doesnt work... is sf.net having a lot of problems lately?>>

Thanks a lot for your swift response, I hope you can bear with me =20
with my somewhat funky and ugly code, and appreciate all help/advice/=20
pointers I can get :)

For viewing (dis)pleasure, I nested my response:

On 04 May 2007, at 23:09, Michael Str=F6der wrote:

> Ino Heatwave wrote:
>>
>> Im currently testing out python-ldap and Im connecting to an active
>> directory service.
>>
>> Binding works ok, but searching usually (usually as in I cant =20
>> remember
>> if it has worked at one point in time or not) ends with an error
>> ("00000000: LdapErr: DSID-0C090627, comment: In order to perform this
>> operation a successful bind must be completed on the connection., =20
>> data
>> 0, vece").
>
> Yes. For most entries there is no anonymous access allowed in the
> default installation of Active Directory.

Well, the problem is that I've already bound as a user with the =20
needed rights to search (even tried with Administrator, and I still =20
get the error).

>
> Some entries are accessible even with anon access. But without knowing
> how your code looks like it's hard to tell what happens.

You certainly may be at the heart of the problem here, but is there =20
any way, using the python-ldap api to ignore errors like that? Like =20
saying: "ok, I realize I might not have access to everything in the =20
directory as this user, but at least return what I have access to"?

>
>> I could provide sample code that gives me this behaviour.
>
> Yes, please provide simple test code demonstrating your issue.

Below is an ugly example I've cooked up for the purpose:

[[ look for attachment named ldap_simple_test.py ]]

>
>> But my main problem is: I cant bind with two different LDAPObjects on
>> the same server.
>
> Are your sure? I'm doing this all the time with web2ldap.
>
>> E.g creating two connections to the same server, using
>> sasl bind (digest-md5). The latter bind operation always raises
>> "ldap.INVALID_CREDENTIALS: {'info': '00090313: LdapErr: =20
>> DSID-0C09043E,
>> comment: AcceptSecurityContext error, data 0, vece', 'desc': 'Invalid
>> credentials'}", even though the username/password are identical. =20
>> Again,
>> I could provide some sample code that shows this behaviour if you're
>> interested.
>
> Please provide a simple example demostrating the problem.
>
> The following code works for me with OpenLDAP 2.3.35:

And the exact same code (modified only to fit with my server =20
parameters of course) bails out with the exception. I've attached the =20=

code I ran and the results, seen from the command line with =20
trace_level =3D 3.

I've done some further testing, and using two different python =20
processes to make two connections to the same server at the same time =20=

works ok, so there definately is something going on here.

Is there some other way to trace whats going on that would make any =20
sense to any of us? Im running this on OS X 10.4.9, with the lastest =20
python-ldap (2.3) built against OpenLDAP 2.3.34. The AD servers Im =20
trying against are Windows server 2003 instances.

Re: possible bug(s) in python-ldap sasl code

[Ino P. <in...@gm...>]

Thanks a lot for your swift response, I hope you can bear with me =20
with my somewhat funky and ugly code, and appreciate all help/advice/=20
pointers I can get :)

For viewing (dis)pleasure, I nested my response:

On 04 May 2007, at 23:09, Michael Str=F6der wrote:

> Ino Heatwave wrote:
>>
>> Im currently testing out python-ldap and Im connecting to an active
>> directory service.
>>
>> Binding works ok, but searching usually (usually as in I cant =20
>> remember
>> if it has worked at one point in time or not) ends with an error
>> ("00000000: LdapErr: DSID-0C090627, comment: In order to perform this
>> operation a successful bind must be completed on the connection., =20
>> data
>> 0, vece").
>
> Yes. For most entries there is no anonymous access allowed in the
> default installation of Active Directory.

Well, the problem is that I've already bound as a user with the =20
needed rights to search (even tried with Administrator, and I still =20
get the error).

>
> Some entries are accessible even with anon access. But without knowing
> how your code looks like it's hard to tell what happens.

You certainly may be at the heart of the problem here, but is there =20
any way, using the python-ldap api to ignore errors like that? Like =20
saying: "ok, I realize I might not have access to everything in the =20
directory as this user, but at least return what I have access to"?

>
>> I could provide sample code that gives me this behaviour.
>
> Yes, please provide simple test code demonstrating your issue.

Below is an ugly example I've cooked up for the purpose:

[[ look for attachment named ldap_simple_test.py ]]

>
>> But my main problem is: I cant bind with two different LDAPObjects on
>> the same server.
>
> Are your sure? I'm doing this all the time with web2ldap.
>
>> E.g creating two connections to the same server, using
>> sasl bind (digest-md5). The latter bind operation always raises
>> "ldap.INVALID_CREDENTIALS: {'info': '00090313: LdapErr: =20
>> DSID-0C09043E,
>> comment: AcceptSecurityContext error, data 0, vece', 'desc': 'Invalid
>> credentials'}", even though the username/password are identical. =20
>> Again,
>> I could provide some sample code that shows this behaviour if you're
>> interested.
>
> Please provide a simple example demostrating the problem.
>
> The following code works for me with OpenLDAP 2.3.35:

And the exact same code (modified only to fit with my server =20
parameters of course) bails out with the exception. I've attached the =20=

code I ran and the results, seen from the command line with =20
trace_level =3D 3.

I've done some further testing, and using two different python =20
processes to make two connections to the same server at the same time =20=

works ok, so there definately is something going on here.

Is there some other way to trace whats going on that would make any =20
sense to any of us? Im running this on OS X 10.4.9, with the lastest =20
python-ldap (2.3) built against OpenLDAP 2.3.34. The AD servers Im =20
trying against are Windows server 2003 instances.

Re: possible bug(s) in python-ldap sasl code

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

Ino Heatwave wrote:
> 
> Im currently testing out python-ldap and Im connecting to an active
> directory service.
> 
> Binding works ok, but searching usually (usually as in I cant remember
> if it has worked at one point in time or not) ends with an error
> ("00000000: LdapErr: DSID-0C090627, comment: In order to perform this
> operation a successful bind must be completed on the connection., data
> 0, vece").

Yes. For most entries there is no anonymous access allowed in the
default installation of Active Directory.

> The data, however is received when I use the library
> asynchronously.
>( I.e it sends me the search results, then raises the
> exception).

Some entries are accessible even with anon access. But without knowing
how your code looks like it's hard to tell what happens.

> I could provide sample code that gives me this behaviour.

Yes, please provide simple test code demonstrating your issue.

> Writing a custom search method that masks this error works great though,
> but feels kinda ugly...

???

> But my main problem is: I cant bind with two different LDAPObjects on
> the same server.

Are your sure? I'm doing this all the time with web2ldap.

> E.g creating two connections to the same server, using
> sasl bind (digest-md5). The latter bind operation always raises
> "ldap.INVALID_CREDENTIALS: {'info': '00090313: LdapErr: DSID-0C09043E,
> comment: AcceptSecurityContext error, data 0, vece', 'desc': 'Invalid
> credentials'}", even though the username/password are identical. Again,
> I could provide some sample code that shows this behaviour if you're
> interested.

Please provide a simple example demostrating the problem.

The following code works for me with OpenLDAP 2.3.35:

--------------------------- snip ---------------------------
import ldap,ldap.sasl

trace_level=2

ldapcon1 = ldap.initialize('ldap://localhost:1390',trace_level=trace_level)
#ldapcon1.simple_bind_s('cn=Fred
Feuerstein,ou=Testing,dc=stroeder,dc=de','fredsecret')
sasl_auth = ldap.sasl.sasl({
      ldap.sasl.CB_AUTHNAME    :'fred',
      ldap.sasl.CB_PASS        :'fredsecret',
},'DIGEST-MD5')
ldapcon1.sasl_interactive_bind_s("", sasl_auth)
ldapcon1.search_s('',ldap.SCOPE_BASE)

ldapcon2 = ldap.initialize('ldap://localhost:1390',trace_level=trace_level)
#ldapcon2.simple_bind_s('uid=anna,ou=Testing,dc=stroeder,dc=de','annasecret')
sasl_auth = ldap.sasl.sasl({
      ldap.sasl.CB_AUTHNAME    :'anna',
      ldap.sasl.CB_PASS        :'annasecret',
},'DIGEST-MD5')
ldapcon2.sasl_interactive_bind_s("", sasl_auth)
ldapcon1.search_s('',ldap.SCOPE_BASE)
--------------------------- snip ---------------------------

> Any ideas?

Use trace_level to examine what your code really does... ;-)

Ciao, Michael.

possible bug(s) in python-ldap sasl code

[Ino H. <in...@gm...>]

Hi,

Im currently testing out python-ldap and Im connecting to an active
directory service.

Binding works ok, but searching usually (usually as in I cant remember if it
has worked at one point in time or not) ends with an error ("00000000:
LdapErr: DSID-0C090627, comment: In order to perform this operation a
successful bind must be completed on the connection., data 0, vece"). The
data, however is received when I use the library asynchronously. (I.e it
sends me the search results, then raises the exception). I could provide
sample code that gives me this behaviour. Writing a custom search method
that masks this error works great though, but feels kinda ugly...

But my main problem is: I cant bind with two different LDAPObjects on the
same server. E.g creating two connections to the same server, using sasl
bind (digest-md5). The latter bind operation always raises "
ldap.INVALID_CREDENTIALS: {'info': '00090313: LdapErr: DSID-0C09043E,
comment: AcceptSecurityContext error, data 0, vece', 'desc': 'Invalid
credentials'}", even though the username/password are identical. Again, I
could provide some sample code that shows this behaviour if you're
interested.

Connecting with two ldapobjects to the same server and binding works fine
with TLS though, but it would certainly be a lot better if we could have
support for this through sasl.

Any ideas?

Re: Parsing a .schema file

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

Aurynn Shaw wrote:
> 
> I'm trying to parse a foo.schema file, which appears to be in the
> 
> attributetype ( 1.3.6.1.4.1.11940.1
> 	NAME 'startDate'
> 	DESC 'Flash Code user subscription start date'
> 	EQUALITY caseIgnoreMatch
> 	SUBSTR caseIgnoreSubstringsMatch
> 	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
> 
> style format, instead of LDIF.
> 
> ldap.schema seems to indicate that it can parse LDAP schemas. Is that  
> in this format, or does it require a connection to the LDAP server?

Mind the line-wrapping:

Python 2.5.1 (r251:54863, Apr 19 2007, 12:23:24)
[GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a="""attributetype ( 1.3.6.1.4.1.11940.1
... NAME 'startDate'
... DESC 'Flash Code user subscription start date'
... EQUALITY caseIgnoreMatch
... SUBSTR caseIgnoreSubstringsMatch
... SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
... """
>>> import ldap.schema
>>> at=ldap.schema.AttributeType(a[len('attributetype
'):].replace('\n',' '))
>>> at
<ldap.schema.models.AttributeType instance at 0xb779ee6c>
>>> dir(at)
['__doc__', '__init__', '__module__', '__str__', '_set_attrs',
'collective', 'desc', 'equality', 'get_id', 'key_attr', 'key_list',
'names', 'no_user_mod', 'obsolete', 'oid', 'ordering',
'schema_attribute', 'set_id', 'single_value', 'substr', 'sup', 'syntax',
'syntax_len', 'token_defaults', 'usage']

Same for other schema elements.

Ciao, Michael.

Parsing a .schema file

[Aurynn S. <au...@gm...>]

Hi, everyone;

I'm trying to parse a foo.schema file, which appears to be in the

attributetype ( 1.3.6.1.4.1.11940.1
	NAME 'startDate'
	DESC 'Flash Code user subscription start date'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

style format, instead of LDIF.

ldap.schema seems to indicate that it can parse LDAP schemas. Is that  
in this format, or does it require a connection to the LDAP server?

Could I get some examples on how to do what I'm looking for?
I'm wanting to generate SQL CREATE TABLE statements directly from the  
LDAP schema, which will hopefully save a lot of time in migrating my  
backend to postgres.

Thank you,
Aurynn

Re: [Fwd: Active directory signature]

[Sylvain <syl...@lo...>]

FYI, I'v fixed the problem which was actually due to auto chasing for
referal, causing an anonymous connection to be open.
Thank you

On Wednesday 02 May à 15:21, Sylvain Thénault wrote:
> On Wednesday 02 May à 09:13, Garland, Ken R wrote:
> > On 5/2/07, Sylvain Thénault <syl...@lo...> wrote:
> > >forwarding this message since I'm now subscribed.
> > >
> > >----- Forwarded message from Sylvain Thénault 
> > ><syl...@lo...> -----
> > >
> > >> From: Sylvain Thénault <syl...@lo...>
> > >> To: pyt...@li...
> > >> Date: Wed, 2 May 2007 13:10:39 +0200
> > >> Subject: Active directory signature
> > >>
> > >> Hi there !
> > >>
> > >> I've some customer code which has been recently broken, since they
> > >> upgraded to AD3. It's some basic authentication code using python-ldap
> > >> (I'm not sure which version is installed on their servers). Their
> > >> microsoft expert told them it was because they changed the "Domain
> > >> controller: LDAP server signing requirements" option to "Require 
> > >signing",
> > 
> > 
> > basically saying they now require authentication. you just need to
> > determine what credentials have been setup to allow whatev er task it
> > is you want to accomplish, then specify them inside your python-ldap
> > program. something similar to:
> > 
> >                l=ldap.initialize("ldap://your.server.com")
> >                l.bind('cn=the_cn_you_use,dc=server,dc=com', 'password')
> > 
> > change 'cn' to 'uid' or whatever it is that your bind requires. set
> > that to a user which has permissions to do whatever it is you are
> > trying to do, simple searches, modifying entries, etc.
> 
> This is already what is done. Basically the code is only doing
> authentification, no more, and works that way, given a login/password 
> to authenticate:
> 1. search in AD the DN corresponding to the login, using an
>    authenticated connection (using an admin dn/password)
> 2. try to connect using the found DN and the given password (using
>    simple_bind_s) to validate the password
> 
> Maybe this is not the right way to do AD/LDAP authentication though ?

-- 
Sylvain Thénault                               LOGILAB, Paris (France)
Formations Python, Zope, Plone, Debian:  http://www.logilab.fr/formations
Développement logiciel sur mesure:       http://www.logilab.fr/services
Python et calcul scientifique:           http://www.logilab.fr/science

Re: [Fwd: Active directory signature]

[Sylvain <syl...@lo...>]

On Wednesday 02 May à 09:13, Garland, Ken R wrote:
> On 5/2/07, Sylvain Thénault <syl...@lo...> wrote:
> >forwarding this message since I'm now subscribed.
> >
> >----- Forwarded message from Sylvain Thénault 
> ><syl...@lo...> -----
> >
> >> From: Sylvain Thénault <syl...@lo...>
> >> To: pyt...@li...
> >> Date: Wed, 2 May 2007 13:10:39 +0200
> >> Subject: Active directory signature
> >>
> >> Hi there !
> >>
> >> I've some customer code which has been recently broken, since they
> >> upgraded to AD3. It's some basic authentication code using python-ldap
> >> (I'm not sure which version is installed on their servers). Their
> >> microsoft expert told them it was because they changed the "Domain
> >> controller: LDAP server signing requirements" option to "Require 
> >signing",
> 
> 
> basically saying they now require authentication. you just need to
> determine what credentials have been setup to allow whatev er task it
> is you want to accomplish, then specify them inside your python-ldap
> program. something similar to:
> 
>                l=ldap.initialize("ldap://your.server.com")
>                l.bind('cn=the_cn_you_use,dc=server,dc=com', 'password')
> 
> change 'cn' to 'uid' or whatever it is that your bind requires. set
> that to a user which has permissions to do whatever it is you are
> trying to do, simple searches, modifying entries, etc.

This is already what is done. Basically the code is only doing
authentification, no more, and works that way, given a login/password 
to authenticate:
1. search in AD the DN corresponding to the login, using an
   authenticated connection (using an admin dn/password)
2. try to connect using the found DN and the given password (using
   simple_bind_s) to validate the password

Maybe this is not the right way to do AD/LDAP authentication though ?

-- 
Sylvain Thénault                               LOGILAB, Paris (France)
Formations Python, Zope, Plone, Debian:  http://www.logilab.fr/formations
Développement logiciel sur mesure:       http://www.logilab.fr/services
Python et calcul scientifique:           http://www.logilab.fr/science

Re: [Fwd: Active directory signature]

[Garland, K. R <gar...@gm...>]

On 5/2/07, Sylvain Th=E9nault <syl...@lo...> wrote:
> forwarding this message since I'm now subscribed.
>
> ----- Forwarded message from Sylvain Th=E9nault <sylvain.thenault@logilab=
.fr> -----
>
> > From: Sylvain Th=E9nault <syl...@lo...>
> > To: pyt...@li...
> > Date: Wed, 2 May 2007 13:10:39 +0200
> > Subject: Active directory signature
> >
> > Hi there !
> >
> > I've some customer code which has been recently broken, since they
> > upgraded to AD3. It's some basic authentication code using python-ldap
> > (I'm not sure which version is installed on their servers). Their
> > microsoft expert told them it was because they changed the "Domain
> > controller: LDAP server signing requirements" option to "Require signin=
g",


basically saying they now require authentication. you just need to
determine what credentials have been setup to allow whatev er task it
is you want to accomplish, then specify them inside your python-ldap
program. something similar to:

                l=3Dldap.initialize("ldap://your.server.com")
                l.bind('cn=3Dthe_cn_you_use,dc=3Dserver,dc=3Dcom', 'passwor=
d')

change 'cn' to 'uid' or whatever it is that your bind requires. set
that to a user which has permissions to do whatever it is you are
trying to do, simple searches, modifying entries, etc.

> > which I can beleive... Is this supported by python-ldap ? If so does
> > someone has an idea about what should I change to make it work again ?
> >
> > Sorry if this question has already been asked but all I get from sf
> > servers hosting mailing list archives is internal server error :(
> >
> > PS: please CC me I'm not subscribed to the list
> > --
> > Sylvain Th=E9nault                               LOGILAB, Paris (France=
)
> > Formations Python, Zope, Plone, Debian:  http://www.logilab.fr/formatio=
ns
> > D=E9veloppement logiciel sur mesure:       http://www.logilab.fr/servic=
es
> > Python et calcul scientifique:           http://www.logilab.fr/science
> >
>
> ----- End forwarded message -----
>
> --
> Sylvain Th=E9nault                               LOGILAB, Paris (France)
> Formations Python, Zope, Plone, Debian:  http://www.logilab.fr/formations
> D=E9veloppement logiciel sur mesure:       http://www.logilab.fr/services
> Python et calcul scientifique:           http://www.logilab.fr/science
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>

[Fwd: Active directory signature]

[Sylvain <syl...@lo...>]

forwarding this message since I'm now subscribed.

----- Forwarded message from Sylvain Thénault <syl...@lo...> -----

> From: Sylvain Thénault <syl...@lo...>
> To: pyt...@li...
> Date: Wed, 2 May 2007 13:10:39 +0200
> Subject: Active directory signature
> 
> Hi there !
> 
> I've some customer code which has been recently broken, since they
> upgraded to AD3. It's some basic authentication code using python-ldap
> (I'm not sure which version is installed on their servers). Their
> microsoft expert told them it was because they changed the "Domain
> controller: LDAP server signing requirements" option to "Require signing", 
> which I can beleive... Is this supported by python-ldap ? If so does
> someone has an idea about what should I change to make it work again ?
> 
> Sorry if this question has already been asked but all I get from sf
> servers hosting mailing list archives is internal server error :(
> 
> PS: please CC me I'm not subscribed to the list
> -- 
> Sylvain Thénault                               LOGILAB, Paris (France)
> Formations Python, Zope, Plone, Debian:  http://www.logilab.fr/formations
> Développement logiciel sur mesure:       http://www.logilab.fr/services
> Python et calcul scientifique:           http://www.logilab.fr/science
> 

----- End forwarded message -----

-- 
Sylvain Thénault                               LOGILAB, Paris (France)
Formations Python, Zope, Plone, Debian:  http://www.logilab.fr/formations
Développement logiciel sur mesure:       http://www.logilab.fr/services
Python et calcul scientifique:           http://www.logilab.fr/science