python-ldap-dev — discussion among developers

Re: Debugging SSL connections

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

Mike Orr wrote:
> On 6/20/06, Michael Str=F6der <mi...@st...> wrote:
>=20
>> If you're using self-signed server certificates I can only comment tha=
t
>> you SHOULD NOT do this.
>=20
> I have no control over the server.  And some organizations with tight
> budgets balk at paying $100 per year per domain to a company like
> Thawte that essentially does nothing.

Hint: You can run your own CA. Or there's also cacert.org.

>> > ldap_bind: Can't contact LDAP server (-1)
>> >         additional info: error:14090086:SSL
>> > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
>> >
>> > Is there an option for "just accept the certificate anyway"?
>>
>> Nope. That's by design of the OpenLDAP API.
>>
>> You can define the server certificate as CA certificate though. But
>> again, this undermines security measures of SSL/TLS.
>>
>> >  Is there
>> > a list of LDAP options anywhere?
>>
>> Why didn't you follow the advice in the e-mail you cited above:
>>
>> ldap.set_option( ldap.OPT_X_TLS_CACERTFILE , ..)
>=20
> Because I don't have a certificate file to point it to.

As I wrote above you can point to the server certificate file.

> I'm checking with the LDAP admins to see if they'll give us the
> certificate file.  If not, I don't know what else to do.

Simply grab it with openssl s_client.

Ciao, Michael.

Re: Debugging SSL connections

[Mike O. <slu...@gm...>]

On 6/20/06, Michael Str=F6der <mi...@st...> wrote:
> Mike Orr wrote:
> >
> > I couldn't find anything about SSL in the
> > python-ldap or openldap documentation, but a Google search found this
> > letter from 2003:
> > http://marc2.theaimsgroup.com/?l=3Dpython-ldap-dev&m=3D105298124425061&=
w=3D1
> > [..]
> > But I don't have a certificate to authenticate against.  Mozilla
> > Thunderbird works fine without it
>
> Are you sure that you never imported the appropriate CA certificate into
> Mozilla cert store? Or do you hit "Accept forever" on each unknown
> issuer? Bad idea!

Oh that's right, Mozilla did pop up an "Unknown certificate" dialog.

> >   "openssl s_client -connect
> > target:636" ends with:
> > "Verify return code: 19 (self signed certificate in certificate chain)"
> >
> > This is not surprising; our organization always uses self-signed
> > certificates.
>
> You have to install the CA certificate which issued the SSL server
> certificate available as trusted root certificate into each software
> using it.
>
> If you're using self-signed server certificates I can only comment that
> you SHOULD NOT do this.

I have no control over the server.  And some organizations with tight
budgets balk at paying $100 per year per domain to a company like
Thawte that essentially does nothing.

> > ldap_bind: Can't contact LDAP server (-1)
> >         additional info: error:14090086:SSL
> > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
> >
> > Is there an option for "just accept the certificate anyway"?
>
> Nope. That's by design of the OpenLDAP API.
>
> You can define the server certificate as CA certificate though. But
> again, this undermines security measures of SSL/TLS.
>
> >  Is there
> > a list of LDAP options anywhere?
>
> Why didn't you follow the advice in the e-mail you cited above:
>
> ldap.set_option( ldap.OPT_X_TLS_CACERTFILE , ..)

Because I don't have a certificate file to point it to.

I'm checking with the LDAP admins to see if they'll give us the
certificate file.  If not, I don't know what else to do.

--=20
Mike Orr <slu...@gm...>

Re: Debugging SSL connections

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

Mike Orr wrote:
> 
> I couldn't find anything about SSL in the
> python-ldap or openldap documentation, but a Google search found this
> letter from 2003:
> http://marc2.theaimsgroup.com/?l=python-ldap-dev&m=105298124425061&w=1
> [..]
> But I don't have a certificate to authenticate against.  Mozilla
> Thunderbird works fine without it

Are you sure that you never imported the appropriate CA certificate into
Mozilla cert store? Or do you hit "Accept forever" on each unknown
issuer? Bad idea!

>   "openssl s_client -connect
> target:636" ends with:
> "Verify return code: 19 (self signed certificate in certificate chain)"
> 
> This is not surprising; our organization always uses self-signed
> certificates.

You have to install the CA certificate which issued the SSL server
certificate available as trusted root certificate into each software
using it.

If you're using self-signed server certificates I can only comment that
you SHOULD NOT do this.

> ldap_bind: Can't contact LDAP server (-1)
>         additional info: error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
> 
> Is there an option for "just accept the certificate anyway"?

Nope. That's by design of the OpenLDAP API.

You can define the server certificate as CA certificate though. But
again, this undermines security measures of SSL/TLS.

>  Is there
> a list of LDAP options anywhere?

Why didn't you follow the advice in the e-mail you cited above:

ldap.set_option( ldap.OPT_X_TLS_CACERTFILE , ..)

> Is there a HOWTO anywhere for using python-ldap with SSL?

See demo script Demo/initialize.py in python-ldap's source distribution.

Ciao, Michael.

Re: Debugging SSL connections

[Mike O. <slu...@gm...>]

Hi.  I have a Python application that uses LDAP to authenticate users.
 Today our organization moved the server to one that uses LDAP-SSL,
and I can't connect to it.  I couldn't find anything about SSL in the
python-ldap or openldap documentation, but a Google search found this
letter from 2003:
http://marc2.theaimsgroup.com/?l=python-ldap-dev&m=105298124425061&w=1

David Casti wrote:
> >
> > import ldap
> > l = ldap.initialize( 'ldaps://target:636' )
> > [..]
> > ldap.SERVER_DOWN: {'info': 'error:14090086:SSL
> > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed', 'desc':
> > "Can't contact LDAP server"}
>
> The message is pretty clear. The server's certificate cannot be verified.
>
> > ldap.set_option( ldap.OPT_X_TLS_CACERTFILE, '/path/ca.crt' )
>
> This is the right thing to do.
>
> Can you please try something like
>
> openssl s_client -connect target:636 -CAfile /path/ca.crt
>
> and carefully examime its output?

But I don't have a certificate to authenticate against.  Mozilla
Thunderbird works fine without it   "openssl s_client -connect
target:636" ends with:
"Verify return code: 19 (self signed certificate in certificate chain)"

This is not surprising; our organization always uses self-signed
certificates.  The ldapsearch program refuses to run, saying:

TLS certificate verification: Error, self signed certificate in
certificate chain
tls_write: want=7, written=7
  0000:  15 03 01 00 02 02 30                               ......0
TLS trace: SSL3 alert write:fatal:unknown CA
TLS trace: SSL_connect:error in SSLv3 read server certificate B
TLS trace: SSL_connect:error in SSLv3 read server certificate B
TLS: can't connect.
ldap_perror
ldap_bind: Can't contact LDAP server (-1)
        additional info: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Is there an option for "just accept the certificate anyway"?  Is there
a list of LDAP options anywhere?  I couldn't find one.

Is there a HOWTO anywhere for using python-ldap with SSL?  I only
discovered ldaps: by guessing maybe it works like https:.

-- 
Mike Orr <slu...@gm...>

Re: problem binding to AD with known-good credentials

[jacob m. <mar...@gm...>]

I forgot to add I am using python2.3-ldap 2.0.4-1 on a debian 3.1 system.

thanks,
jacob

On 6/17/06, jacob martinson <mar...@gm...> wrote:
> I am unable to bind to an Active Directory system using python-ldap.
>
> I created a user in AD with search rights and am able to do a simple
> bind with the java-based "LDAP Browser" and search/browse the
> directory with those credentials.
>
> When I try to do a simple bind to the directory with python-ldap I
> don't get an exception, but when I try to perform the search, I get an
> exception indicating I didn't bind successfully:
>
> Traceback (most recent call last):
>   File "./tmp", line 29, in ?
>     search_ad(email='us...@do...',password='passwd')
>   File "./tmp", line 20, in search_ad
>     result_type, result_data = l.result(ldap_result_id, 0)
>   File "/usr/lib/python2.3/site-packages/ldap/ldapobject.py", line
> 399, in result
>     res_type,res_data,res_msgid = self.result2(msgid,all,timeout)
>   File "/usr/lib/python2.3/site-packages/ldap/ldapobject.py", line
> 405, in result2
>     return self._ldap_call(self._l.result2,msgid,all,timeout)
>   File "/usr/lib/python2.3/site-packages/ldap/ldapobject.py", line 94,
> in _ldap_call
>     result = func(*args,**kwargs)
> ldap.OPERATIONS_ERROR: {'info': '00000000: LdapErr: DSID-0C090627,
> comment: In order to perform this operation a successful bind must be
> completed on the connection., data 0, vece', 'desc': 'Operations
> error'}
>
> I am attaching the script that generated this exception.  Am I missing
> something?
>
> Thanks!
>
> jacob
>
>
>

problem binding to AD with known-good credentials

[jacob m. <mar...@gm...>]

I am unable to bind to an Active Directory system using python-ldap.

I created a user in AD with search rights and am able to do a simple
bind with the java-based "LDAP Browser" and search/browse the
directory with those credentials.

When I try to do a simple bind to the directory with python-ldap I
don't get an exception, but when I try to perform the search, I get an
exception indicating I didn't bind successfully:

Traceback (most recent call last):
  File "./tmp", line 29, in ?
    search_ad(email='us...@do...',password='passwd')
  File "./tmp", line 20, in search_ad
    result_type, result_data = l.result(ldap_result_id, 0)
  File "/usr/lib/python2.3/site-packages/ldap/ldapobject.py", line
399, in result
    res_type,res_data,res_msgid = self.result2(msgid,all,timeout)
  File "/usr/lib/python2.3/site-packages/ldap/ldapobject.py", line
405, in result2
    return self._ldap_call(self._l.result2,msgid,all,timeout)
  File "/usr/lib/python2.3/site-packages/ldap/ldapobject.py", line 94,
in _ldap_call
    result = func(*args,**kwargs)
ldap.OPERATIONS_ERROR: {'info': '00000000: LdapErr: DSID-0C090627,
comment: In order to perform this operation a successful bind must be
completed on the connection., data 0, vece', 'desc': 'Operations
error'}

I am attaching the script that generated this exception.  Am I missing
something?

Thanks!

jacob

Re: Simple test failing

[Marc L. <sys...@me...>]

Michael Str=F6der wrote:
> Marc Lanctot wrote:
>=20
>>I'm trying to get pykota working with LDAP and running into problem=
s
>>connecting to the LDAP server.
>=20
>=20
> Which LDAP server? Which version?
>=20

LOL, sorry... I expected it to be quite a common problem.

I'm running OpenLDAP server on a 32-bit RHES 3 (Taroon Update 5). I=
=20
installed it from the usual up2date:

[mlanct2@zephyr mlanct2]$ rpm -qa | grep openldap
openldap-devel-2.0.27-20
openldap-2.0.27-20
openldap-servers-2.0.27-20
openldap-clients-2.0.27-20
[mlanct2@zephyr mlanct2]$

Weird, I was quite sure I had an version 3 server ... my clients can=
=20
connect fine using pam_ldap around the dept.

>>self._ldap_call(self._l.simple_bind,who,cred,serverctrls,clientctrl=
s)
>>  File "/usr/lib64/python2.3/site-packages/ldap/ldapobject.py", lin=
e 94,
>>in _ldap_call
>>    result =3D func(*args,**kwargs)
>>ldap.ENCODING_ERROR: {'desc': 'Encoding error'}
>>tsunami:~ #
>=20
>=20
> Which version of python-ldap are you using and which OpenLDAP libs =
are
> used by python-ldap?

The client script runs on a Suse (x86_64) 9.2 machine. Version

tsunami:~ # cat /etc/SuSE-release
SuSE Linux 9.2 (x86-64)
VERSION =3D 9.2
tsunami:~ # rpm -qa | grep ldap
ldapcpplib-0.0.3-28
openldap2-client-2.2.15-5.3
pam_ldap-169-29.2
nss_ldap-215-60.2
openldap2-2.2.15-5.1
yast2-ldap-2.10.4-2
yast2-ldap-client-2.10.7-2
python-ldap-2.0.2-2.1
php4-ldap-4.3.8-8.2
tsunami:~ #

Weird, the clients also list as v2 here ... but in the desc. it says =
v3.=20
  Also, the ldap* commands work fine from this machine.

> You simply have to pass the clear-text password to the simple_bind(=
)
> method call. (You probably want to use simple_bind_s() though.)

Ok, but will it use the "password: md5" setting from /etc/ldap.conf t=
o=20
encrypt the password?

And, can you tell me what "encoding error" means?

Thanks,
Marc

--=20
"The ships hung in the sky in much the same way that bricks don't."
   -- Douglas Adams

Re: Simple test failing

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

Marc Lanctot wrote:
> 
> I'm trying to get pykota working with LDAP and running into problems
> connecting to the LDAP server.

Which LDAP server? Which version?

> self._ldap_call(self._l.simple_bind,who,cred,serverctrls,clientctrls)
>   File "/usr/lib64/python2.3/site-packages/ldap/ldapobject.py", line 94,
> in _ldap_call
>     result = func(*args,**kwargs)
> ldap.ENCODING_ERROR: {'desc': 'Encoding error'}
> tsunami:~ #

Which version of python-ldap are you using and which OpenLDAP libs are
used by python-ldap?

> I'm using MD5 hashes for my passwords. Could this be why? How can I tell
> Python-LDAP to use MD5 hashing? I find in the docs what the error means,
> but I don't see anything about fixing it, nor not supporting those
> hashing mechanisms...

You simply have to pass the clear-text password to the simple_bind()
method call. (You probably want to use simple_bind_s() though.)

Ciao, Michael.

Simple test failing

[Marc L. <sys...@me...>]

Hello,

I'm trying to get pykota working with LDAP and running into problems 
connecting to the LDAP server.

So, using the code I found on the website I ran testldap.py (see 
attached), and the output I get is:

tsunami:~ # ./testldap.py
Traceback (most recent call last):
   File "./testldap.py", line 18, in ?
     l.simple_bind(username, password)
   File "/usr/lib64/python2.3/site-packages/ldap/ldapobject.py", line 
169, in simple_bind
     return 
self._ldap_call(self._l.simple_bind,who,cred,serverctrls,clientctrls)
   File "/usr/lib64/python2.3/site-packages/ldap/ldapobject.py", line 
94, in _ldap_call
     result = func(*args,**kwargs)
ldap.ENCODING_ERROR: {'desc': 'Encoding error'}
tsunami:~ #

I'm using MD5 hashes for my passwords. Could this be why? How can I tell 
Python-LDAP to use MD5 hashing? I find in the docs what the error means, 
but I don't see anything about fixing it, nor not supporting those 
hashing mechanisms...

Thanks,
Marc

Re: python-ldap, compare_s() return only true in all cases

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

Fernando Ribeiro wrote:
> 
>>>    While using ldap_slave.compare_s("dc=domain,dc=com,dc=br",
>>> "objectClass", "top");
>>>    It return true.
>>>    But look in ldap_slave don't have the 'objectClass: top'.
>>
>> Every structural object class is implicitly derived from 'top'. So I'd
>> expect this to evaluate to True each time.
> 
> It return true to all objectClasses.
> With others atribute (except objectClass) it work fine.
> I have tested with C too, and it return the same result.

Can you please post the LDAP filter strings you tested with?

Can you reproduce the same results with OpenLDAP's command-line tool
ldapcompare? If yes, please discuss the question on the
OpenLDAP-Software mailing list (see http://www.openldap.org/lists/)
detailing your tests.

>    Exists other way to compare entries?

What exactly do you mean with comparing entries? Please describe in
slightly more detail what you are trying to achieve.

You can off course simply retrieve entries with a search request and
compare attributes in your Python application.

Ciao, Michael.

Re: python-ldap, compare_s() return only true in all cases

[Fernando R. <fer...@ge...>]

Hi Michael,

Michael Ströder wrote:
> Fernando Ribeiro wrote:
>   
>>    I'm studing the python, and begin with python-ldap. But i have a
>> little problem with ldap.compare_s(dn, attr, value) function.
>>     
>
> Please subscribe and post to python-ldap-dev list (Cc:-ed).
>
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>
>   
subscribed, thanks.
>>    While using ldap_slave.compare_s("dc=domain,dc=com,dc=br",
>> "objectClass", "top");
>>    It return true.
>>    But look in ldap_slave don't have the 'objectClass: top'.
>>     
>
> Every structural object class is implicitly derived from 'top'. So I'd
> expect this to evaluate to True each time.
>   
It return true to all objectClasses.
With others atribute (except objectClass) it work fine.
I have tested with C too, and it return the same result.
Its "ignoring" the objectClass to compare.

> What exactly are you trying to achieve?
>
> Could you please verify with another attribute?
>
> Ciao, Michael.
>
>   
    Exists other way to compare entries?

    Thank you a million by attention.


Best Regards,
Fernando Ribeiro

-- 
--------------------------------------------------
- Fernando Ribeiro - GPG-KEY: 0x8D7255F4
- Linux Counter: #273768 - ICQ: 175630330
- RHCE - Red Hat Certified Engineer
- LPIC-2 - Advanced Linux
- CCSA - CheckPoint Cert. Security Admin.
- phone: +55 61 9115 4852
- http://www.musb.org
--------------------------------------------------
Firthunands (firthu quer dizer "paz", nands
significa audaz. Dessa maneira, a tradução seria:
"Aquele que se atreve a tudo para conservar a Paz"

Re: python-ldap, compare_s() return only true in all cases

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

Fernando Ribeiro wrote:
> 
>    I'm studing the python, and begin with python-ldap. But i have a
> little problem with ldap.compare_s(dn, attr, value) function.

Please subscribe and post to python-ldap-dev list (Cc:-ed).

https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

>    While using ldap_slave.compare_s("dc=domain,dc=com,dc=br",
> "objectClass", "top");
>    It return true.
>    But look in ldap_slave don't have the 'objectClass: top'.

Every structural object class is implicitly derived from 'top'. So I'd
expect this to evaluate to True each time.

What exactly are you trying to achieve?

Could you please verify with another attribute?

Ciao, Michael.

Re: ldap_passwd.diff

[Timur I. <Tim...@oi...>]

On Tue, Apr 18, 2006 at 01:18:08PM +0200, Michael Str=F6der wrote:
> Ok, I've committed the patch below. Please test.

It is working. Thank you!

--=20
Timur Izhbulatov
OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia
P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:Tim...@oi...
Building Successful Supply Chains - One Solution At A Time.
www.oilspace.com

Re: ldap_passwd.diff

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

Timur Izhbulatov wrote:
> On Sun, Apr 16, 2006 at 12:46:44PM +0200, Michael Str=F6der wrote:
>=20
>>Timur Izhbulatov wrote:
>>
>>>On Thu, Apr 13, 2006 at 07:47:05PM +0200, Michael Str=F6der wrote:
>>>
>>>>2. Personally I'd like avoid to turn arguments user,oldpw,newpw of
>>>>passwd() into optional key-word arguments (and we can't do that for o=
nly
>>>>user and oldpw, see 1.). I'd rather prefer the application developer =
to
>>>>really know what he's doing. But I'm open to other opinions.
>>>
>>>In this case the application developer won't be able to do some import=
ant
>>>things. For example, changing other users's passwords will be impossib=
le even if
>>>tha application is bound with root DN.
>>
>>The developer could simply pass value None to passwd() for user and old=
pw.
>=20
> Passing None is OK as long as l_ldap_passwd() allows this. So I suggest=
 applying
> my changes only to Modules/LDAPObject.c.

Ok, I've committed the patch below. Please test.

Ciao, Michael

Index: Modules/LDAPObject.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/python-ldap/python-ldap/Modules/LDAPObject.c,v
retrieving revision 1.74
diff -u -r1.74 LDAPObject.c
--- Modules/LDAPObject.c        5 Apr 2006 22:40:14 -0000       1.74
+++ Modules/LDAPObject.c        18 Apr 2006 11:12:24 -0000
@@ -1179,7 +1179,7 @@
     int msgid;
     int ldaperror;

-    if (!PyArg_ParseTuple( args, "s#s#s#|OO", &user.bv_val, &user_len,
&oldpw.bv_val, &oldpw_len, &newpw.bv_val, &newpw_len, &serverctrls,
&clientctrls ))
+    if (!PyArg_ParseTuple( args, "z#z#z#|OO", &user.bv_val, &user_len,
&oldpw.bv_val, &oldpw_len, &newpw.bv_val, &newpw_len, &serverctrls,
&clientctrls ))
        return NULL;

     user.bv_len =3D (ber_len_t) user_len;
@@ -1201,7 +1201,13 @@
     }

     LDAP_BEGIN_ALLOW_THREADS( self );
-    ldaperror =3D ldap_passwd( self->ldap, &user, &oldpw, &newpw,
server_ldcs, client_ldcs, &msgid );
+    ldaperror =3D ldap_passwd( self->ldap,
+            user.bv_val !=3D NULL ? &user : NULL,
+            oldpw.bv_val !=3D NULL ? &oldpw : NULL,
+            newpw.bv_val !=3D NULL ? &newpw : NULL,
+            server_ldcs,
+            client_ldcs,
+            &msgid );
     LDAP_END_ALLOW_THREADS( self );

     LDAPControl_List_DEL( server_ldcs );

Re: ldap_passwd.diff

[Timur I. <Tim...@oi...>]

On Sun, Apr 16, 2006 at 12:46:44PM +0200, Michael Str=F6der wrote:
> Timur Izhbulatov wrote:
> > On Thu, Apr 13, 2006 at 07:47:05PM +0200, Michael Str=F6der wrote:
> >=20
> >>1. As long as returning a server-generated password is not implemented
> >>it does not make sense to make newpw optional and/or accept None as val=
ue.
> >=20
> > Agree. I just blindly followed the RFC.
>=20
> If we can't make newpw an optional key-word argument we also can't make
> user and oldpw to optional key-word arguments.

Yes, now I see. At this moment there is no point in making any of the
arguments optional.

> >>2. Personally I'd like avoid to turn arguments user,oldpw,newpw of
> >>passwd() into optional key-word arguments (and we can't do that for only
> >>user and oldpw, see 1.). I'd rather prefer the application developer to
> >>really know what he's doing. But I'm open to other opinions.
> >=20
> > In this case the application developer won't be able to do some importa=
nt
> > things. For example, changing other users's passwords will be impossibl=
e even if
> > tha application is bound with root DN.
>=20
> The developer could simply pass value None to passwd() for user and oldpw.

Passing None is OK as long as l_ldap_passwd() allows this. So I suggest app=
lying
my changes only to Modules/LDAPObject.c.

Cheers,

--=20
Timur Izhbulatov
OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia
P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:Tim...@oi...
Building Successful Supply Chains - One Solution At A Time.
www.oilspace.com

Re: ldap_passwd.diff

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

Timur Izhbulatov wrote:
> On Thu, Apr 13, 2006 at 07:47:05PM +0200, Michael Str=F6der wrote:
>=20
>>1. As long as returning a server-generated password is not implemented
>>it does not make sense to make newpw optional and/or accept None as val=
ue.
>=20
> Agree. I just blindly followed the RFC.

If we can't make newpw an optional key-word argument we also can't make
user and oldpw to optional key-word arguments.

>>2. Personally I'd like avoid to turn arguments user,oldpw,newpw of
>>passwd() into optional key-word arguments (and we can't do that for onl=
y
>>user and oldpw, see 1.). I'd rather prefer the application developer to
>>really know what he's doing. But I'm open to other opinions.
>=20
> In this case the application developer won't be able to do some importa=
nt
> things. For example, changing other users's passwords will be impossibl=
e even if
> tha application is bound with root DN.

The developer could simply pass value None to passwd() for user and oldpw=
.

Ciao, Michael.

Re: ldap_passwd.diff

[Timur I. <Tim...@oi...>]

On Thu, Apr 13, 2006 at 07:47:05PM +0200, Michael Str=F6der wrote:
> Timur, thanks for your patch.
>=20
> 1. As long as returning a server-generated password is not implemented
> it does not make sense to make newpw optional and/or accept None as value.

Agree. I just blindly followed the RFC.

> 2. Personally I'd like avoid to turn arguments user,oldpw,newpw of
> passwd() into optional key-word arguments (and we can't do that for only
> user and oldpw, see 1.). I'd rather prefer the application developer to
> really know what he's doing. But I'm open to other opinions.

In this case the application developer won't be able to do some important
things. For example, changing other users's passwords will be impossible ev=
en if
tha application is bound with root DN.

And if you really don't like changing the passwd() method I suggest adding =
new
method or overriding the existing on in subclass. Of course, this implies my
patch for LDAPObject.c.

WDYT?

--=20
Timur Izhbulatov
OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia
P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:Tim...@oi...
Building Successful Supply Chains - One Solution At A Time.
www.oilspace.com

Re: ldap_passwd.diff

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

Timur Izhbulatov wrote:
>=20
> On Fri, Apr 07, 2006 at 11:31:40AM +0200, Michael Str=F6der wrote:
>=20
>>Timur Izhbulatov wrote:
>=20
>>>Also I would like to ask you to pay your attention to the issue I repo=
rted some
>>>time ago:
>>>http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1440151&g=
roup_id=3D2072&atid=3D102072.
>=20
>>So if it's urgent for you to get your issue done I'd like to encourage
>>you to submit a patch. Even if your patch is not perfect this makes it
>>easier for me to start working on it.
>=20
> My patch for HEAD is attached. And, yes, it's not perfect, just a quick=
 fix. For
> example the ldap.ldapobject.SimpleLDAPObject.passwd method still doesn'=
t return
> server generated password if the newpw argument is omitted.

Timur, thanks for your patch.

1. As long as returning a server-generated password is not implemented
it does not make sense to make newpw optional and/or accept None as value=
.

2. Personally I'd like avoid to turn arguments user,oldpw,newpw of
passwd() into optional key-word arguments (and we can't do that for only
user and oldpw, see 1.). I'd rather prefer the application developer to
really know what he's doing. But I'm open to other opinions.

> For those who are interested. More details can be found in my previous =
report:
> http://sourceforge.net/mailarchive/forum.php?thread_id=3D9546124&forum_=
id=3D4346

Ciao, Michael.

Re: python-ldap

[Timur I. <Tim...@oi...>]

Michael,

Thanks for answering!

On Fri, Apr 07, 2006 at 11:31:40AM +0200, Michael Str=F6der wrote:
> Timur Izhbulatov wrote:

> > Also I would like to ask you to pay your attention to the issue I repor=
ted some
> > time ago:
> > http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1440151&gr=
oup_id=3D2072&atid=3D102072.

> So if it's urgent for you to get your issue done I'd like to encourage
> you to submit a patch. Even if your patch is not perfect this makes it
> easier for me to start working on it.

My patch for HEAD is attached. And, yes, it's not perfect, just a quick fix=
=2E For
example the ldap.ldapobject.SimpleLDAPObject.passwd method still doesn't re=
turn
server generated password if the newpw argument is omitted.

> Maybe your requirement could be solved in the Python wrapper module
> ldap.ldapobject. Not sure about it though.

Not only in ldap.ldapobject. The problem is also in Modules/LDAPObject.c: l=
_ldap_passwd

> Please, stay tuned to the python-ldap-dev mailing list. I'm reading it
> and will answer there. Maybe someone else on the list feels like taking
> over the task.

For those who are interested. More details can be found in my previous repo=
rt:
http://sourceforge.net/mailarchive/forum.php?thread_id=3D9546124&forum_id=
=3D4346

Cheers,

--=20
Timur Izhbulatov
OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia
P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:Tim...@oi...
Building Successful Supply Chains - One Solution At A Time.
www.oilspace.com

ANN: python-ldap-2.2.0

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

Find a new release of python-ldap:

  http://python-ldap.sourceforge.net/

python-ldap provides an object-oriented API to access LDAP directory
servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for
that purpose. Additionally it contains modules for other LDAP-related
stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema).

----------------------------------------------------------------
Released 2.2.0 2006-04-10

Changes since 2.0.11:

* OpenLDAP 2.2+ required now to build.

Modules/
* Dropped all occurences of '#ifdef #LDAP_VENDOR_VERSION'.
* Fixed wrong tuple size in l_ldap_result3() (see SF#1368108)
* Fixed get_option(ldap.OPT_API_INFO) (see SF#1440165)
* Fixed memory leak in l_ldap_result3() when all=0
  (see SF#1457325)
* Fixed memory leak in l_ldap_result3() in error cases
  (see SF#1464085)

Lib/
* Fixed ldap.schema.models.DITStructureRule.__str__() to
  separate SUP rule-ids with a single space instead of ' $ '
* Fixed ldap.async.Dict
* Added ldap.async.IndexedDict
* ldap.schema.subentry.SubSchema.attribute_types() has new
  key-word argument ignore_dit_content_rule

FYI: python-ldap and web2ldap at OpenLDAP booth, Linuxtag 2006

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

HI!

once again OpenLDAP will be presented by a team of volunteers

  at Linuxtag 2006
  in Wiesbaden, Germany
  from Wednesday, 2006-05-03
  until Saturday, 2006-05-06

  http://www.linuxtag.org/2006/

Several deployment scenarios based on OpenLDAP will be demonstrated with
various LDAP clients.

I will also present web2ldap and answer questions about python-ldap too.
I'd be glad to meet members of the community personally there.

See you at booth #11 in hall no. 9!

Ciao, Michael.

--=20
Michael Str=F6der
E-Mail: mi...@st...
http://www.stroeder.com

PEP 353 - preparation for Python 2.5

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

HI!

I'm very short on spare time at the moment.

Could someone please check python-ldap to support PEP 353 (see
http://www.python.org/dev/peps/pep-0353/) and create a patch for the
changes required?

See also:

http://groups.google.com/group/comp.lang.python/tree/browse_frm/thread/7e55ac8f0ca175a0/69951264453fdfb2?rnum=1&_done=%2Fgroup%2Fcomp.lang.python%2Fbrowse_frm%2Fthread%2F7e55ac8f0ca175a0%2F69951264453fdfb2%3F#doc_69951264453fdfb2

http://svn.effbot.python-hosting.com/stuff/sandbox/python/ssizecheck.py

Many thanks in advance.

Ciao, Michael.

Re: [PATCH] Plug two leaks in python-ldap

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

Xin LI wrote:
> 
> Here is a patch that corrects two memory leaks in python-ldap.  Tracker
> #1464085.

I've committed this patch. Not sure when it will appear in anon CVS
since SF has some problems with CVS service.

Ciao, Michael.

Re: Planning python-ldap release 2.2.0

[<pk...@gm...>]

Jens Vagelpohl wrote:
>=20
> On 4 Apr 2006, at 11:50, Michael Str=F6der wrote:
>>> Yes, I expect these people to request support for OpenLDAP 2.0.x. But=

>>> people not willing to use a C compiler probably will have to stick to=

>>> older python-ldap releases anyway. ;-)
>=20
> Yes, absolutely, I just fear those people who have this irrational urge=

> to upgrade just for upgrading's sake if something new is released, and =
a
> lot of them don't like answers such as "If you're on OL 2.0.27, please
> use python-ldap versions <=3D 2.0.10 because the newest versions won't =
run
> against your antique OpenLDAP". :P
>=20
> jens
Let's hope that the "irrational urge to upgrade" will solve the OL 2.0.x
issue for them as well.

cheers
 Paul

Re: Planning python-ldap release 2.2.0

[Xin LI <de...@de...>]

=E5=9C=A8 2006-04-04=E4=BA=8C=E7=9A=84 12:27 +0200=EF=BC=8CMichael Str=C3=
=B6der=E5=86=99=E9=81=93=EF=BC=9A
> Xin LI wrote:
> >=20
> >>>BTW.  Is there any plan to release a new version soon?
> >>
> >>I could release a new version very soon. (Despite that SF sucks and
> >>again I can't contact the CVS repository via SSH at the moment.)
> >>
> >>Note that as already stated in CVS version of CHANGES upcoming
> >>python-ldap 2.2.0 will require OpenLDAP libs 2.2.x or later for the bui=
ld.
> >=20
> > Glad to hear that :-)  Thanks!
>=20
> How soon would you need a new release version in your project?

It's kind of you, Michael.  For my own project it's not an urgent need
as I can deploy patched version to fulfill my need, but I would happy to
see if you guys would release a new release, so we can update the
FreeBSD port (currently it's 2.0.10) without adding "local patchset" to
the FreeBSD ports repository.

Cheers,
--=20
Xin LI <delphij delphij net>    http://www.delphij.net/